Example of Database Security Policy

1. Purpose

The purpose of this Policy is to preserve the confidentiality, integrity and availability of the XXX’s information assets
by restricting access to enterprise application databases that store XXX’s data

2. Scope

1. This database security policy applies to database platforms. If the role is outsourced to a vendor, the vendor must ensure compliance with the identified standards.
2. Security controls should be implemented based on the level of confidentiality of the data determined by Data Owner.
3. Database management system should provide accurate and reliable business data as well as preventing unauthorized data modification.
4. XXX should ensure the roles and responsibilities of Database Administrator is established and formalized. Only authorized users are allowed to access business data.

3. Policy

3.1 General

1 Storage of Data Base Usernames and Passwords

• Database usernames and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writable.
• Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code.
• Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.
• Database credentials may not reside in the documents tree of a web server.
• Passwords or pass phrases used to access a database must adhere to the Password Policy.

2 Retrieval of Database User Names and Passwords

• If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared.
• The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.
• For languages that execute from source code, the credentials’ source file must not reside in the same browsable or executable file directory tree in which the executing body of code resides.

3 Access to Database Usernames and Passwords

• Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed.
• Database passwords used by programs are system-level passwords as defined by the Password Policy.
• Developer groups must have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.
• Users and/or software accessing sensitive data must be subjected to proper access control and should not be able to perform privileged operations that are out of scope of said user and/or software.

3.2 Information Classification

Data is classified to its sensitivity level. This sensitivity level is the level of risk to the Organization if the data is lost or disclosed to unauthorized parties.

3.3 Access control

1 Authorization, Access Rights and Privilege

1. All system installation and database files with directories must be protected to prevent unauthorized access.
2. The respective System Owner shall authorize all user access to database.
3. The database server and its network components shall be physically secured.
4. Select privilege grants a user’s access on views and tables should be limited to authorized personnel.
5. All users’ access privileges of database is based on the Application Access Matrix (according to duties segregation), owned by the Data Owner and endorsed by the senior management.

2 Audit Trails

1. Database audit data shall be archived according to the following requirements:-
   • Daily Back-ups are retained for a minimum of 1 month,
   • Monthly Back-ups are retained for every 7 years and
   • Yearly Back-ups are retained for 7 years.
2. ll requests to link database should formally be approved by IT Security Department and relevant parties. Database maintenance utilities that bypass controls should be adequately restricted and monitored.
3. Minimum Audit Information: The minimum audit trail for a database must be able to provide information on access to a database at any point of time. The following scenarios will require minimum audit trails.
   • Multi-site access (Connections from different IP or point of access) to a database is needed to be audited. The access is through a system (i.e. application server accessing a database server).
     • Failed login
     • Database exceptions
   • Multi-user ID accessing a database. This connection is mainly by individual user (through database client i.e. SQL Plus, Toad or log on locally to the database server)

The following audits are suggested.

• Who logged into the database
• Successful login and failed login (authorization failure/non existent users).
• Where the connection was initiated from (source)
• When the connection was made
• What client was used to access the database
• What was performed during the connection

3. Availability, Backup and Recovery

1. Database Administrator shall monitor the database periodically to ensure its availability and maintaining the performance.
2. Data Administrator should determine the level of required backup and strategy being used (e.g. Full backup, incremental, online or offline backup) for different databases.
3. Backup files for all databases must be sent to an offsite location for storage.
4. The DBA shall backup the database periodically according to documented procedures.
5. Where possible, the database redundancy should be implemented whereby the archive and redundancy are written to multiple physical locations for recovery purposes.
6. Recovery testing of the off-site backup tapes shall be carrying out o a half yearly basis.

4. Database User Management

1.Privileged Accounts

1. Database Administrator (DBA) shall not have system administrator rights to the operating system for any server on which a database is installed.

2. User Accounts

1. Where possible, all database users should have a unique user account within the database
2. The use of shared user accounts in the database application is not allowed.
3. The Database Administrator (DBA) shall not transfer or share administrator account privileges with unauthorized users.
4. Where possible, database session timeout for accounts should be implemented to mitigate the risk of unauthorized access when the terminal is left unattended.
5. In the event of changes in job function of the user, the access rights of the user accounts shall be reviewed to ensure that minimum access rights are granted.
6. All user accounts that have been inactive for 90 days shall be disabled.

3. Default Accounts

1. Default fault accounts shall be deleted disabled or removed from the production database management systems.

4. Creation of Accounts

1. Requests for creating user accounts and granting access privileges shall be approved by the respective Data Owner.

5. Deletion of Accounts

1. All user accounts should be deleted immediately after the user leaves the Organization, unless requested and approved otherwise.

6. Application and System Development

1. The database production and development environments shall be segregated.
2. Developers shall not have an access to the production database.

7. Operating System security

1. The operating system where the database is installed shall be secured according to XXX platform-specific operating system technical control guideline.

8. Data Confidentiality Controls

1. Where possible, database passwords and other relevant authentication information should be appropriately encrypted.
2. Where possible, “Classified” data (e.g. Customer PIN and Credit Card number) in the database should be stored in encrypted form.
3. Where possible, database links or connection (e.g. Oracle SSL) should be encrypted.

 3.4 Change Control

1. Any database changes shall be approved by the Data Owner and the relevant parties and a notification concerning about the changes will be sent to the IT Security Department for an updates on the changes made.
2. Both outsourcer and XXX IT Security Department shall assess database changes that are not specific to business application.
3. The changes specific to business application data (e.g. Database tables, data) shall be tested on the development system prior to implementation on the production system and shall be approved ahead of making any changes.
4. Changes to the audit trail settings highlighted in this policy shall require assessment from both outsourcer and XXX IT Security Department.

3.5 Monitoring and Review

1.Access Control Matrix Review

The Data Owner on a half yearly basis shall review the access control matrix. Updated access matrix should be forwarded to the outsourcer.

2 Audit Trail Reviews

1. The integrity of business data should be upheld by providing assurance of accuracy and reliability of the database management system as well as preventing unauthorised modification of data.
2. For all databases, audit trail, error logs and access violation review shall be performed by the Database Administrator periodically and as needed in accordance with the standards.
3. An independent party who does not have access to the same database shall review audit trails of Database Administrator and Database Security Officer Activities.

3 Security Patches

1. The Database Administrator shall monitor the availability of database updates and patches releases by the vendors.
2. Once done with the evaluation on impact on the database, database Administrator shall apply these database updates and prepare the impact analysis documentation to the Data Administrator for concurrence and acceptance.

3.6 Data Base Administrator Roles and Responsibilities

1. A database administrator is responsible for the usage, accuracy, efficiency, security, maintenance, administration and development of an organization’s computerized database(s), providing support to some or all departments depending on the size of the organization.
2. Typical responsibilities are likely to include:-

1. Ensuring that the database(s) is updated accurately and regularly
2. Controlling the access, performance monitoring and tuning
3. Assisting development staff with application design
4. Identifying and resolving user’s problem
5. Developing and implementing maintenance procedures
6. Collaborating in the design and development of database to meet new user needs and respond to/anticipate technological innovations
7. Facilitating and negotiating the increasing demand for access to data-increasingly via an organization’s intranet or website
8. Devising, developing and implementing disaster recovery and archiving procedures
9. Supporting users by talking then through a search or by customizing the ‘front ends’ to incorporate new fields for data entry
10. Capacity planning
11. Working closely with IT project managers and database programmers
12. Liaising with web developers to enable on-line database access and resolve associated problems
13. Planning and coordinating database security measures
14. Communicating regularly with internal technical, applications and operational staff to ensure the database integrity and security
15. Commissioning and installing new applications.

4.0 Policy Compliance

4.1 Compliance Measurement
The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the IT team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. A violation of this policy by a temporary worker, contractor or vendor may result in the termination of their contract or assignment with .