ASD ISM 1276 Use safe database query methods
What it says
Parameterised queries or stored procedures, instead of dynamically generated queries, are used by software for database interactions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware should use parameterised queries or stored procedures to safely access databases.
When software needs to access a database, it's crucial to use safe methods like parameterised queries or stored procedures. Doing this prevents hackers from manipulating your database with harmful queries. If you don't, you risk exposing sensitive business or customer data, which can lead to financial and reputational harm.
Free. Save your status, tasks and notes.
Why it matters
Not using parameterised queries or stored procedures can enable SQL injection, leading to unauthorised data access, data loss, and service disruption.
How to implement
Database administrators should ensure all software uses parameterised queries instead of building database queries from scratch.
This can be achieved by teaching developers how to use programming libraries and frameworks that support this feature.
IT teams need to review all software that interacts with the database to confirm it uses stored procedures for data access.
Stored procedures should be developed and tested to handle expected data and scenarios, reducing the risk of unexpected database commands.
Software developers should work with database specialists to convert existing database access code into parameterised queries or stored procedures.
This involves identifying parts of code where database queries are created, then refactoring these to use secure methods.
Project managers should schedule regular training sessions for developers on secure coding practices, including the use of parameterised queries.
Practical workshops are effective, focusing on real examples where input validation reduces risks.
Management should enforce a policy where new software or updates must be reviewed by a security expert before being deployed.
This ensures every piece of software adheres to the best practices in accessing databases safely.
Keep it running
Review application code and ORM usage to ensure all SQL uses parameterised queries or stored procedures; test for SQL injection in CI and during releases.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of applications that interact with databases.
Look at
Their documentation to check whether parameterised queries or stored procedures are used for each database interaction. Good practice is a documented process showing parameterised queries are the standard approach.
- Check 2 of 5What an auditor asks for
Look at
Whether these samples match best practices for using parameterised queries and avoid direct query string construction.
Good evidence
Is code that makes use of libraries known for their secure query capabilities.
- Check 3 of 5What an auditor asks for
Ask for
Policy documents regarding database access methods. Look to see if there's a clear mandate to use parameterised queries and stored procedures.
Good evidence
Sign is a policy with detailed procedures and examples, approved and up to date.
- Check 4 of 5What an auditor asks for
Ask for
Training records regarding secure database access methods.
Look at
Evidence that developers attended and understood secure coding practices, with a focus on parameterised queries. A positive sign is a record of regular session attendance and post-training assessments.
- Check 5 of 5What an auditor asks for
Ask for
To see logs or records of software changes related to database access.
Look at
Notes or comments indicating that the database interactions have been updated to use safe methods.
Good evidence
Is a detailed change log reflecting conscious updates to secure interactions.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-1276 requires a specific secure implementation pattern for database access: parameterised queries or stored procedures instead of dynamic query generation. Annex A 8.25 requires an organisation to establish and apply rules for secure development of software and systems, under which standards and patterns like safe database query methods would be defined and enforced. ISM-1276 represents one concrete rule that would sit inside the broader secure development rule-set required by Annex A 8.25.
This control partially meets A.8.28.
ISM-1276 requires software to use parameterised queries or stored procedures (rather than dynamically generated queries) for database interactions to prevent injection-style flaws. Annex A 8.28 requires secure coding practices to be applied across software development, which typically includes input handling and preventing injection (including SQL injection) via safe query construction. ISM-1276 is a specific secure-coding requirement focused on database query methods, while Annex A 8.28 is broader and covers many other secure coding topics beyond database access.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.