Skip to main content

This section of the ISM provides guidance on databases.

Database register

Without knowledge of all the databases in an organisation, and the information they contain, an organisation will be unable to appropriately protect their assets.

Security Control: 1243; Revision: 4; Updated: Aug-19; Applicability: O, P, S, TS
A database register is maintained and regularly audited.

Protecting database contents

Database contents can be protected from unauthorised copying and subsequent offline analysis by applying file-based access controls to database files.

Security Control: 1256; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
File-based access controls are applied to database files.

Protecting authentication credentials in databases

Storing authentication credentials such as usernames and passphrases as plaintext in databases poses a significant security risk. An adversary that manages to gain access to a database’s contents could extract these authentication credentials to gain access to users’ accounts. In addition, it is possible that a user could have reused a username and passphrase for their workstation posing an additional security risk.

Security Control: 1252; Revision: 3; Updated: Jun-19; Applicability: O, P, S, TS
Passphrases stored in databases are hashed with a uniquely salted Australian Signals Directorate Approved Cryptographic Algorithm.

Protecting database contents

Database administrators and database users should know the sensitivity or classification associated with a database and its contents to ensure that sufficient security controls are applied. In cases where all of a database’s contents are the same sensitivity or classification an organisation may choose to classify the entire database at this level. Alternatively, in cases where a database’s contents are of varying sensitivity or classification levels, and database users have differing levels of access to such information, an organisation may choose to apply classifications at a more granular level within the database.

Limiting database user’s ability to access, insert, modify or remove content from databases based on their work duties ensures the need-to-know principle is applied and the likelihood of unauthorised modifications is reduced.

Security Control: 0393; Revision: 7; Updated: Apr-19; Applicability: O, P, S, TS
Databases and their contents are classified based on the sensitivity or classification of information that they contain.

Security Control: 1255; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
Database users’ ability to access, insert, modify and remove content in databases is restricted based on their work duties.

Security Control: 1268; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
The need-to-know principle is enforced for database contents through the application of minimum privileges, database views and database roles.

Aggregation of database contents

Where concerns exist that the sum, or aggregation, of separate pieces of information from within databases could lead to an adversary determining more sensitive or classified information, database views in combination with database user access roles should be implemented. Alternatively, the information of concern could be separated by implementing multiple databases, each with restricted data sets. If implemented properly, this will ensure an adversary cannot access the sum of information components leading to the aggregated information.

Security Control: 1258; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
Where concerns exist that the sum, or aggregation, of separate pieces of information from within databases could lead to a database user determining more sensitive or classified information, database views in combination with database user access roles are implemented.

Separation of production, test and development databases

Using information from production databases in test or development databases could result in inadequate protection being applied to the information.

Security Control: 1274; Revision: 4; Updated: Sep-18; Applicability: O, P, S, TS
Information in production databases is not used in testing or development databases unless the testing or development environments are secured to the same level as the production environment.

Web application interaction with databases

SQL injection is a significant threat to the confidentiality, integrity and availability of database contents. SQL injections can allow an adversary to steal information from databases, modify database contents, delete an entire database or even in some circumstances gain control of the underlying database server. Furthermore, when database queries from web applications fail they may display detailed error information about the database schema to users of the web application. This can be used by an adversary to tailor SQL injection attempts.

Security Control: 1275; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
All queries to databases from web applications are filtered for legitimate content and correct syntax.

Security Control: 1276; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
Parameterised queries or stored procedures are used for database interaction instead of dynamically generated queries.

Security Control: 1278; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
Web applications are designed to provide as little error information as possible to users about database schemas.

Further information

Further information on logging and auditing of database events can be found in the event logging and auditing section of the Guidelines for System Monitoring.