Database authentication credentials are a necessary part of authorizing applications to connect to internal databases. However, incorrect use, storage, and transmission of such credentials could compromise sensitive assets and be a springboard to wider compromise within the organization.
This policy states the requirements for securely storing and retrieving database usernames and passwords (i.e., database credentials) for use by a program that will access a database running on one of eCuras’s networks.
Software applications running on eCuras’s networks may require access to one of the many internal database servers. To access these databases, a program must authenticate to the database by presenting acceptable credentials. If the credentials are improperly stored, the credentials may be compromised, leading to a compromise of the database.
This policy is directed at all system implementers and/or software engineers who may be coding applications that will access a production database server on the eCuras Network. This policy applies to all software (programs, modules, libraries, or APIS that will access a eCuras, multi-user production database. It is recommended that similar requirements be in place for non-production servers and lap environments since they don’t always use sanitized information.
To maintain the security of eCuras’s internal databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program’s source code in clear text. Database credentials must not be stored in a location that can be accessed through a web server.
Storage of Database 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.
- Pass through authentication (i.e., Oracle OPS$ authentication) must not allow access to the database based solely upon a remote user’s authentication on the remote host.
- Passwords or passphrases used to access a database must adhere to the Password Policy.
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 containing the credentials must have no other code but the credentials (i.e., the username and password) and any functions, routines, or methods used to access the credentials.
- For languages that execute from source code, the credentials’ source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.
Access to Database Usernames and Passwords
- Every program or every collection of programs implementing a single business function must have unique database credentials. The 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 to ensure that database passwords are controlled and changed according to the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.
5. Policy Compliance
5.1. Compliance Measurement
The Infosec team will verify compliance with this policy through various methods, including but not limited to business tool reports, internal and external audits, and feedback to the policy owner.
The Infosec team must approve any exception to the policy in advance.
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 eCuras.
Any program code or application that is found to violate this policy must be remediated within 90 days.
6. Related Standards, Policies, and Processes
Revised: March 14th, 2018
Table of Content
- Acceptable Encryption Policy
- Acceptable Use Policy
- Clean Desc Policy
- Data Breach Response Policy
- Disaster Recovery Plan Policy
- Digital Signature Acceptance Policy
- Email Policy
- Ethics Policy
- Pandemic Response Planning Policy
- Password Construction Guidelines
- Password Protection Policy
- Security Response Plan Policy
- End User Encryption Key Protection Policy
- Acquisition Assessment Policy
- Bluetooth Baseline Requirements Policy
- Remote Access Policy
- Remote Access Tools Policy
- Router and Switch Security Policy
- Wireless Communication Policy
- Wireless Communication Standard
- Database Credentials Policy
- Technology Equipment Disposal Policy
- Information Logging Standard
- Lab Security Policy
- Server Security Policy
- Software Installation Policy
- Workstation Security (For HIPAA) Policy
- Web Application Security Policy
- Analog/ISDN Line Security Policy
- Anti-Virus Guidelines
- Server Audit Policy
- Automatically Forwarded Email Policy
- Communications Equipment Policy
- Dial In Access Policy
- Extranet Policy
- Internet DMZ Equipment Policy
- Internet Usage Policy
- Mobile Device Encryption Policy
- Personal Communication Devices and Voicemail Policy
- Removable Media Policy
- Risk Assessment Policy
- Server Malware Protection Policy
- Social Engineering Awareness Policy
- DMZ Lab Security Policy
- Email Retention Policy
- Employee Internet Use Monitoring and Filtering Policy
- Lab Anti Virus Policy
- Mobile Employee Endpoint Responsibility Policy
- Remote Access Mobile Computing Storage
- Virtual Private Network Policy