AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 4. Relational Database Management Systems (RDBMS) Security Configurations

10.8.4  Relational Database Management Systems (RDBMS) Security Configurations

10.8.4.1  (02-21-2008)
Purpose

  1. This transmits Internal Revenue Manual (IRM) 10.8 Section 4, Relational Database Management Systems (RDBMS) Security Configurations.

10.8.4.1.1  (02-21-2008)
Overview

  1. This document shall be used with the appropriate Operating (OS) System Internal Revenue Manual (IRM) as well as other IRM-related requirements of any applications accessing the database.

  2. This document further details many of the existing requirements identified in IRS IRM 10.8.1, Information Technology (IT) Security Policy and Guidance, specific to IRS DBMS systems.

  3. Data stored within a database management system (DBMS) has frequently become a target of attack for malicious users. The effect of such an attack can result in identity and/or credit card theft, financial loss, loss of privacy, a breach of national security or any other type of corruption that can result from unauthorized access to sensitive data. This IRM presents the security configuration items, vulnerabilities, and issues required to be addressed by IRS policy. In addition to this IRM, compliance validation tools and checklists are available to IRS employees and contractors to assist in the efforts to implement the required configuration.

10.8.4.1.2  (02-21-2008)
Scope

  1. This IRM applies to all organizations, including IRS contractors and outsourcing providers, which operate database software containing IRS data on behalf of the IRS.

  2. All requirements stated in this policy, apply to all IRS databases, regardless of vendor product or version. IRS requirements specific to a particular product, such as Oracle Database Server, Microsoft SQL Server, and IBM DB2 implementations, are covered in individual exhibits.

  3. Databases not specifically covered in this IRM shall be secured according to the general guidance of this IRM as well as vendor-recommended security configurations and application of all vendor-supplied security patches.

  4. Operating system-specific considerations are supplied for the primary platforms in place at the IRS.

10.8.4.1.3  (02-21-2008)
IRM Section Topics

  1. This IRM contains information on the following subjects:

    • Authority

    • General Policy

    • Management Controls

    • Operational Controls

    • Technical Controls

    • Deviations

    • Related Publications ( See Exhibit 10.8.4-1. )

    • Oracle Specific Policy and Implementation ( See Exhibit 10.8.4-2.)

    • Microsoft SQL Server Specific Policy and Implementation ( See Exhibit 10.8.4-3.)

    • IBM DB2 Universal Database Specific Policy ( See Exhibit 10.8.4-4.)

    • Oracle Database IRM Compliance Configuration ( See Exhibit 10.8.4-5.)

    • Microsoft SQL Server Database IRM Compliance Configuration ( See Exhibit 10.8.4-6.)

    • Glossary ( See Exhibit 10.8.4-7.)

    • References ( See Exhibit 10.8.4-8.)

10.8.4.1.4  (02-21-2008)
Authority

  1. This IRM supplements the management, operational, and technical controls as defined in IRM 10.8.1, IT Security Policy and Guidance, to include comprehensive guidance on RDBMS Security Configurations. If there is a conflict with or variance from this IRM , IRM 10.8.1 shall take precedence.

  2. In addition to the requirements and configuration setting identified in this IRM, database naming standards and design must comply with IRM 2.5.7, Data Name Standards, and IRM 2.5.13, Database Design Techniques and Deliverables.

10.8.4.2  (02-21-2008)
General Policy

  1. All DBMS installations operated by the IRS, or operated by an IRS contractor on behalf of the IRS, shall comply with the provisions of this IRM.

  2. All IRS DBMS installations shall undergo a security review at least annually using the High Priority DBMS Compliance Checklist described in the next section as a source of IRS policy requirements.

  3. DBMS product-specific configuration requirements described in the Exhibits of this IRM shall be implemented on all applicable platforms.

  4. IRS DBMS installations shall undergo certification and accreditation (C&A) activities, in accordance with IRM 10.8.1 , in conjunction with either a major application C&A or general support system C&A that the DBMS is intended to support. Any DBMS not included in the C&A of another system shall undergo its own C&A.

10.8.4.2.1  (02-21-2008)
Roles and Responsibilities

  1. IRM 10.8.2, Information Technology Security Roles and Responsibilities , defines IRS-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. The supplemental roles and responsibilities identified below are specific to IRS DBMS installations.

10.8.4.2.1.1  (02-21-2008)
Information System Owner

  1. The Information System Owner has ultimate responsibility for information systems, including DBMS software and data, which support the Information System Owner’s assigned IRS business mission, per IRM 10.8.2.

  2. The Information System Owner is responsible for ensuring that DBMS environments comply with the security change management requirements listed in the Operational Controls section of IRM 10.8.1. Specifically, Information System Owners shall ensure that changes to DBMSs are documented and tracked using a formal change request process.

10.8.4.2.1.2  (02-21-2008)
Database Administrator (DBA)

  1. The Database Administrator (DBA) shall perform all activities related to maintaining a correctly performing and secure database environment. Responsibilities include design (in conjunction with application developers), implementation, and maintenance of the database system as described throughout this IRM.

10.8.4.2.1.3  (02-21-2008)
Information Systems Security Officer (ISSO)

  1. The ISSO is responsible for coordinating activities that facilitate ensuring the confidentiality, integrity, and availability of assigned IRS systems as defined in IRM 10.8.2. The ISSO is further responsible for providing the necessary coordination to ensure that compliance plans for bringing existing DBMSs into compliance with this IRM are developed and communicated to IRS management.

10.8.4.2.1.4  (02-21-2008)
Security Specialist (SecSpec)

  1. The IT SecSpec is concerned with the security and integrity of the database and is responsible for ensuring that the requirements of this IRM are met. All SecSpec responsibilities identified in this IRM shall be in addition to the SecSpec responsibilities defined in IRM 10.8.1.

  2. The SecSpec is responsible for ensuring that DBAs, System Administrators (SAs), and others having daily operational responsibilities for IRS databases comply with the security requirements of this IRM. In general, the SecSpec is not expected to personally implement the requirements, but rather ensure that others do so.

  3. SecSpecs shall report IRM non-compliance issues initially to DBAs and SAs for resolution, and escalate non-compliance reporting to IRS management officials (such as the ISSO and Information System Owner) as necessary to bring systems into compliance with this IRM.

10.8.4.2.1.5  (02-21-2008)
Training Requirement

  1. Individuals assigned security responsibilities for DBMS environments, including the SecSpec and DBA, shall obtain database security technical training necessary to implement the requirements of this IRM. The training shall cover the security features specific to the DBMS products the individuals are required to support.

10.8.4.2.2  (02-21-2008)
High-Priority DBMS Compliance Checklist

  1. The following list provides a summary of the high-level priority "checklist" items that should be implemented first in maintenance efforts to strengthen the security of existing IRS DBMS systems and are discussed throughout this document:

    1. Only DBMS products and platforms identified in the IRS Enterprise Architecture (EA) shall be used. Products and associated platforms not approved in the EA shall require a formal written EA waiver.

    2. All vendor-recommended security patches for the DBMS and the underlying operating system platform shall be installed.

    3. The principle of least privilege shall be implemented for all DBMS users, applications, and database objects.

    4. All default (vendor-provided) DBMS accounts not explicitly needed by an IRS database application shall be locked and disabled.

    5. All DBMS user passwords shall be changed every 90 days or more frequently.

    6. Database auditing shall be configured and implemented on all DBMS systems that generate, store, process, display, or transmit sensitive data.

    7. DBMS software used for development purposes on Unix-based and Windows platforms shall be run on separate physical hosts from production DBMS systems.

10.8.4.3  (02-21-2008)
Management Controls

  1. The IRS shall implement management security controls to mitigate risk of IT applications and electronic information loss in order to protect the organization's mission. See IRM 10.8.1 for general information on computer security management control requirements.

  2. Additional management controls specific to RDBMS Security Configurations are provided below in the following areas:

    1. Planning

    2. System and Services Acquisition

    3. Certification, Accreditation, and Security Assessments

10.8.4.3.1  (02-21-2008)
Planning

  1. DBAs, in coordination with Security Specialists, shall develop a compliance plan and schedule for bringing existing DBMSs into compliance with this IRM.

  2. Security Specialists shall monitor the progress of compliance plan implementation, and report the status of implementation of the requirements of this IRM to the ISSO and other management officials as appropriate.

10.8.4.3.2  (02-21-2008)
System and Services Acquisition

  1. DBMS products shall be acquired, accounted for, and inventoried in accordance with IRM 10.8.1.

  2. DBMS products shall adhere to the System Development Life Cycle in accordance with IRM 10.8.1.

10.8.4.3.3  (02-21-2008)
Certification, Accreditation, and Security Assessments

  1. IRS DBMS installations shall undergo C&A activities, in accordance with IRM 10.8.1, in conjunction with either a major application C&A or general support system GSS C&A that the DBMS is intended to support.

  2. The risk assessment portion of a C&A involving DBMS software shall address the requirements of See IRM 10.8.4.3.1. above.

  3. All IRS DBMS installations shall undergo a security review at least annually using the High Priority DBMS Compliance Checklist section of this IRM as a source of IRS policy requirements.

  4. Risk assessments shall be performed on DBMS installations as a part of C&A activities as defined in IRM 10.8.1.

  5. Risk assessment activities for DBMS components shall include, at a minimum, an analysis of the compliance of the DBMS components to the High-Priority DBMS Compliance Checklist of this IRM.

  6. If an IRS GSS has a current risk assessment that includes an analysis of GSS DBMSs against the High Priority DBMS Compliance Checklist section of this IRM, then IRS major application risk assessments can simply reference the GSS risk assessment findings. If a major application's applicable GSS risk assessment does not address the High Priority DBMS Compliance Checklist, then the major application's risk assessment shall provide an analysis against the requirements of the checklist.

10.8.4.4  (02-21-2008)
Operational Controls

  1. The IRS shall implement operational security controls, which are primarily implemented and executed by personnel for each information system. See IRM 10.8.1 for general information and computer security operational control requirements.

  2. Additional operational controls specific to RDBMS Security Configurations are provided below in the following areas:

    1. Personnel Security

    2. Physical and Environmental Protection

    3. Contingency Planning

    4. Configuration Management

    5. Maintenance

    6. System and Information Integrity

    7. Media Protection

    8. Incident Response

    9. Awareness and Training

10.8.4.4.1  (02-21-2008)
Personnel Security

  1. IRS personnel, contractors, and other personnel accessing databases containing IRS data shall be categorized, screened, terminated, and transferred in accordance with IRM 10.8.1.

  2. Personnel that have not been screened in accordance with IRM 10.8.1 shall not be permitted access to databases containing IRS data.

10.8.4.4.2  (02-21-2008)
Physical and Environmental Protection

  1. Refer to IRM 10.8.1 for requirements related to the physical protection of databases containing IRS data.

10.8.4.4.3  (02-21-2008)
Contingency Planning

  1. Contingency plans for databases containing IRS data shall be developed, maintained, and tested in accordance with IRM 10.8.1 .

10.8.4.4.4  (02-21-2008)
Configuration Management

  1. System procedures for archiving audit log files and associated database files shall include procedures to archive log files using a scheduled service or job. SAs for the systems in question shall be responsible for developing and implementing the archiving procedures.

  2. Archival of audit log files and associated database files shall be maintained in the same format and context as the operating system which created the audit files.

10.8.4.4.4.1  (02-21-2008)
General Requirements

  1. Databases containing IRS data shall be inventoried in accordance with IRM 10.8.1.

  2. Configuration settings for Oracle, Microsoft SQL Server, and IBM DB2 DBMS software shall be implemented as described in the exhibits of this IRM.

  3. A database baseline software configuration shall be maintained in accordance with the Database Software Baseline section of this IRM.

  4. Databases shall be backed up in accordance with the Database File Backup and Recovery section of this IRM.

10.8.4.4.4.2  (02-21-2008)
DBMS Software/Object Modification

  1. Production DBMS software (i.e. DBMS software being used to support business operations of the IRS), shall be appropriately controlled to prevent unauthorized modification. See See Exhibit 10.8.4-7. Glossary for the definition of "Unauthorized modification." The policies listed below regarding software monitoring and modification shall be observed on all production DBMS systems.

    1. DBMS software OS-level executable files and configuration files installed on the host system shall be monitored at a minimum once monthly or more frequently for unauthorized modification.

    2. Host systems shall have their systems baselined after application installation to collect data on application directories and files for future comparison in order to determine unauthorized modification.

    3. Third party application software, if installed on the database server, shall be installed on separate logical or physical storage partitions from the database software to provide separate resource controls and security contexts.

    4. DBMS application objects including but not limited to functions and procedures shall be monitored monthly for unauthorized modification. Like the host system, a baseline of application objects is both necessary and required in order to detect unauthorized changes such as procedure recompiles or object restructuring.

    5. Auditing of modification of or access to application data shall be performed in accordance with IRM 10.8.3, Audit Logging Security Standards.

    6. IRS software configuration management policies and practices shall be implemented and strictly enforced on production database systems to ensure unauthorized software is not implemented.

    7. Database applications shall not use DDL statements unless used for temporary tables that are limited to the work of one user or session; any other DDL statements that are needed shall be formally requested in writing.

    8. The DBA shall provide to the SA a list of database software directories to be included in software backup, baselining, and monitoring.

10.8.4.4.4.3  (02-21-2008)
Unused Database Software/Components

  1. DBMS software suites provided by commercial vendors typically are "feature rich" and contain many software components that are seldom or never used in IRS business processes. Such unused software presents potential vulnerabilities to the confidentiality and integrity of IRS and taxpayer data, since unused software is a potential source of software attacker exploits. Enterprise Life Cycle (ELC) projects planning to use DBMS software as part of the implementation shall identify needed and unneeded software components.

  2. All binary files, database accounts, database objects, and application code stored in the database that are solely associated with an unused or decommissioned application or database component shall be removed from or disabled on the database and host system. Failure to remove such files, objects, or codes allows unnecessary vulnerabilities associated with them to remain in the database. In addition such remnants result in increased administrative overhead in maintaining such unused software. DBAs shall take precautions to remove any objects or components that are no longer required and that a backup of the database and applications is current.

    1. The development team shall identify unneeded DBMS software components as early as possible in the ELC development cycle, and no later than the Integration phase of the ELC.

    2. The development team shall notify appropriate DBA staff of DBMS software components unneeded by the ELC project (For example, an ELC project application may have no need for web server software that is bundled in the vendor’s DBMS software distribution.) If multiple projects share one DBMS, the DBA shall confirm that none of the projects are using the software components in question.

    3. The DBA shall uninstall unneeded DBMS software components, in coordination with the development team, prior to the completion of testing activities of the ELC project requiring use of the DBMS; The vendor’s recommended uninstaller and procedures shall be used to accomplish to component removal (E.g., the Oracle Installer in the case of Oracle products).

    4. Components that are used for the internal maintenance of the database, such as partitioning utilities, may be retained at the discretion of the DBA if such components are determined to have potential future value for database maintenance purposes.

    5. The DBA shall ensure, during the deployment and operations phases of the ELC, that unused database components (including database software executables) and any associated database objects are removed from the database and host system.

10.8.4.4.4.4  (02-21-2008)
Database Software Baseline

  1. Every DBMS shall have a good backup of the database software configuration, which is performed correctly and completely. An operating system " baseline" backup of the database software configuration shall be performed every time the DBMS software is upgraded, immediately after the configuration settings required by this IRM are applied.

    1. The SA, with the support of the DBA, shall backup the database software configuration after every database software upgrade.

10.8.4.4.4.5  (02-21-2008)
Database File Backup and Recovery

  1. A tested and verifiable data backup strategy shall be implemented for all databases. Backup and recovery procedures shall be documented. The DBA shall coordinate with application owners to implement data backup and recovery procedures that meet the business requirements of the application users.

  2. Each site hosting DBMS software shall have a contingency processing plan/disaster recovery plan that includes DBMS databases. The contingency plan shall be periodically tested in accordance with IRM 10.8.1.

10.8.4.4.4.6  (02-21-2008)
Multiple Services on Host Systems

  1. The installation of a DBMS on a host platform introduces additional vulnerabilities and resource requirements to the host. Additionally, vendor DBMS software distributions frequently offer additional functionality, such as web servers and directory server software, on the same installation media that the DBMS is provided on. Since it is a best security practice to separate or partition services offered to different audiences, any DBMS should be installed on a host system dedicated to its support and offering as few services as possible to other clients. For this reason, a DBMS shall not be installed on a host system that also provides web services, directory services, directory naming services, etc. In particular, DBMS software shall not be installed on Microsoft Windows domain controllers or backup domain controllers under any circumstances.

  2. An exception to the requirement of disallowing multiple services on one machine shall be permitted when an IRS mission-required database application, such as a Commercial Off The Shelf (COTS) or Government Off The Shelf (GOTS) software product, requires the use of other services (e.g., a web server) on the same host as the DBMS software. In such cases, the minimal number of additional services required to support the mission-required application shall be permitted to run on the DBMS host, and non-mission essential software services shall be disabled.

10.8.4.4.5  (02-21-2008)
DBMS Maintenance Requirements

  1. DBMS maintenance requirements follow.

10.8.4.4.5.1  (02-21-2008)
Database Software Development

  1. Database software development introduces unknown vulnerabilities to the database system. Software development shall not be done on production databases, per the guidance provided in IRM 10.8.1. Development databases shall be configured in accordance with all security requirements for production databases with the exception of specifically noted differences. This ensures that the application is developed within the boundaries of good security.

  2. On IRS mainframes, development databases shall run on separate logical partitions from production databases. On all other operating system platforms, development databases shall NOT co-reside with production databases.

  3. No database links shall be created or used between production and development database systems. Applications and databases under development shall not access production databases.

  4. Development databases created from production databases must be cleaned to remove sensitive data immediately after import to the development database in accordance with IRM 2.5.16, Use of Live Data in Testing. This includes database account passwords and deletion or modification of sensitive data such as personnel or financial, etc. information. Use sanitized live data if simulated data would not be effective or is not reasonably available or use unsanitized live data if neither simulated data nor sanitized live data would be effective or reasonably available. The DBA shall ensure that imported passwords and sensitive data are protected from view in a development database.

    1. The SA shall ensure that software configuration management policies are implemented and strictly enforced to ensure untested software is not inadvertently loaded to production systems.

    2. The DBA shall ensure that development databases do not co-reside on the same hosts as production databases on Unix-based and Windows operating system platforms.

    3. Live data contained on any form of media will be removed and/or destroyed by or in the presence of an IRS employee or contractor with approved access in such a manner that the information is totally unrecoverable.

10.8.4.4.5.2  (02-21-2008)
Ad Hoc Queries

  1. Ad hoc queries allow the user to submit an untested request to the database. Such unrestricted access may have a negative impact on system performance or be used to exploit unknown vulnerabilities. Ad hoc queries shall not be used on production systems when canned queries can suffice. Ad hoc queries can be used as necessary to directly support IRS business operations only when those procedures are approved by the cognizant DBA such as when required to operate in a data warehouse environment. Therefore, DBMS users shall create and store frequently used queries in procedures instead of using ad-hoc queries. In some types of databases such as data warehouses, ad hoc queries may be required. Procedures and approval for such queries shall be obtained from the cognizant DBA and a record of such approval shall be maintained by the DBA for such period as specified by the data owner.

    1. The SA shall monitor the OS performance of DBMS host platforms to ensure that use of ad hoc queries does not overwhelm other system resources such as CPU and disk space utilization.

    2. The DBA shall personally refrain from using untested queries on production systems, and test DBMS maintenance queries on development systems instead.

    3. The DBA shall ensure any user that can do ad hoc queries has least privilege access.

10.8.4.4.6  (02-21-2008)
System and Information Integrity

  1. The integrity of DBMS software depends in part upon the integrity of its supporting host system software. Operating system integrity is covered in each OS IRM and will not be duplicated in this document.

  2. Application software that utilizes data stored in a DBMS must be evaluated independently from the DBMS. However, DBMS policy declared in this IRM shall be followed.

  3. The operational integrity of the OS is the primary concern of the SA. The operational integrity of the DBMS is the concern of the DBA.

10.8.4.4.6.1  (02-21-2008)
Current DBMS Version

  1. The integrity of the DBMS software executables and data files is crucial to the optimal and correct operation of all applications using the DBMS. To protect the DBMS environment, the DBA shall ensure that the DBMS patch level is current. Systems and databases unable to keep patches current require a deviation. The risk for the deviation shall be assigned to the Designated Accrediting Authority (DAA) for mitigation or other disposition. The DBMS host system shall be an approved/accredited platform.

    1. Each organization responsible for the management of a database shall ensure that unsupported DBMS software is removed or upgraded to a supported version prior to a vendor dropping support.

    2. Each organization responsible for the management of a database shall ensure there is a formal migration plan for removing or upgrading DBMS systems prior to the date the vendor drops security patch support.

    3. Each organization responsible for the management of a database shall ensure that the DBMS version has all appropriate patches applied. Bug Fix Patches should be applied as needed.

    4. Each organization responsible for the management of a database shall ensure that patch level upgrades are applied through a planned upgrade process.

    5. The SecSpec shall oversee the activities to ensure security is maintained.

10.8.4.4.6.2  (02-21-2008)
Data Integrity

  1. Database security shall provide controlled, protected access to the contents of your database and, in the process, preserve the integrity, consistency, and overall quality of your data.

  2. Some of the duties that shall be performed to promote data integrity are as follows:

    1. Correct and successful physical backup of all database data

    2. Correct and successful logical backup of all database data

    3. Recovery operations

    4. Database performance analysis

    5. Auditing enabling and audit data analysis in accordance with IRM 10.8.3

10.8.4.4.6.3  (02-21-2008)
Database File Integrity

  1. To protect the integrity of the database files, database COTS software authorizations shall not be modified from installation defaults to be more permissive. All permissions on directories and files created as the result of an installation of the DBMS software shall comply with IRS requirements, if available, or to the vendor recommended permissions if not. Permissions to change directory names, file permissions, or group information associated with the database software shall be restricted to SAs and DBAs. Third party application software shall be installed on a separate partition and all associated files and directories shall be owned by the third-party application account.

    1. The SA shall ensure that permissions to database software comply with specifications identified in the exhibits to this IRM. If a specific configuration setting or parameter is unaddressed by this IRM, then the permissions for that setting or parameter shall be set to comply with vendor recommended permissions.

    2. The SA shall ensure that all directories created by the installation of the DBMS are protected in accordance with specifications identified in the exhibits of this IRM. If unavailable, DBMS directory permissions shall be set to comply with vendor recommendations.

    3. The SA shall ensure that files used to populate a database with business data (i.e.,"imported" data) are stored in a secure location.

    4. The SA shall ensure that all file permissions created by the installation of a DBMS are modified as necessary to comply with security evaluation specifications identified in the exhibits of this IRM. If unavailable, DBMS file permissions shall be set to comply with vendor recommended permissions.

    5. The SA shall ensure that permissions to change directory names, file permissions, or group information associated with the database software are restricted to SAs and DBAs.

    6. The SA shall ensure that all third-party database application software is installed in a logical partition separate from the DBMS software and data files.

    7. The SA shall ensure that all DBMS and third-party database application software files and directories are owned by the application software account and are protected from access by more than the minimal number of users required.

    8. The development team for an ELC project that uses DBMS software shall develop a contingency plan that addresses contingency activities for DBMS data, in accordance with IRM 10.8.1.

    9. The DBA shall ensure that a tested and verifiable database backup strategy is implemented on all databases.

    10. The DBA shall ensure that documented backup and recovery procedures exist and are followed.

10.8.4.4.6.4  (02-21-2008)
Protection of Sensitive Data

  1. Sensitive data or information, as defined in IRM 10.8.1, or determined to be sensitive by the data owner, may be stored within data objects within the database and may require additional protection. Encryption of specific data items can protect data from unauthorized viewing. Sensitive data shall be encrypted within the database.

    1. The SecSpec shall ensure that sensitive data is identified by the data owner and, if encryption is required, configured for encryption by the DBA.

10.8.4.4.6.5  (02-21-2008)
Protection of Stored Applications

  1. Custom application and GOTS application software source code objects shall be encrypted within the database, where available as a DBMS feature, in accordance with industry (cissecurity.org) and government (csrc.nist.gov/pcig) best practice recommendations.

    1. The DBA shall ensure that custom application and GOTS source code objects are encrypted within the database when possible.

10.8.4.4.7  (02-21-2008)
Media Protection

  1. Database media outputs, such as printouts, shall be marked and protected in accordance with IRM 10.8.1.

  2. When a database host is decommissioned, all data (including configuration data) shall be sanitized from the host in accordance with IRM 2.14.1.

10.8.4.4.8  (02-21-2008)
Incident Response

  1. DBAs, Security Specialists, and other individuals involved in the operation of DBMSs shall maintain familiarity with the requirements and procedures defined in the Cybersecurity, Computer SecurityIncident Reporting & Response Procedures.

  2. If a DBA or Security Specialists suspects that a security incident has occurred on a DBMS, the IRS Computer Security Incident Response Center (CSIRC).

10.8.4.4.9  (02-21-2008)
Awareness and Training

  1. Database users shall attend an annual computer security awareness briefing, in accordance with IRM 10.8.1.

  2. DBAs, Security Specialists, and other individuals having DBMS security responsibilities shall obtain specialized database security training as specified in the Roles and Responsibilities section of this IRM.

10.8.4.5  (02-21-2008)
Technical Controls

  1. The IRS shall implement technical security controls and ensure the design of IT systems that process, store, or transmit all information shall include, at a minimum, the technical security requirements discussed in this IRM. See IRM 10.8.1 for general information and computer security technical control requirements.

  2. Additional technical controls specific to RDBMS Security Configurations are provided below in the following areas:

    1. Identification and Authentication

    2. Access Control

    3. Audit and Accountability

    4. System and Communications Protection

10.8.4.5.1  (02-21-2008)
Identification and Authentication

  1. IRS policy requires unique identification for each system user. A user is either an individual or an executing process/service that accesses a computer resource. Actions performed by a user within the database shall be traceable to an individual database account.

  2. IRS policy requires that permissions and privileges granted to individuals within an automated information system follow the concept of least privilege. Authorized database accounts shall be granted access only to the resources needed to accomplish the mission. Authorized database accounts shall have roles assigned that contain the minimum privileges necessary to perform each of their job functions. All database accounts shall be protected by a certificate, password, or other approved authentication method in accordance with IRM 10.8.1.

    1. The DBA shall ensure that all database actions are traceable to an individual user.

    2. The DBA shall ensure that all database accounts are granted roles containing the minimum set of privileges required for the application.

    3. The DBA shall configure all database accounts to be protected by a password, certificate, or other approved authentication method.

    4. The DBA shall ensure that use of shared database accounts are justified and documented in appropriate ELC documentation.

10.8.4.5.1.1  (02-21-2008)
Authentication

  1. Databases shall comply with authentication guidance in IRM 10.8.1.

  2. Public Key Infrastructure (PKI)-based authentication or other strong authentication technologies may be used, provided that the technologies utilized are compatible with the IRS EA.

    1. Use of other strong authentication technologies, shall be based on risk assessment and approval by MITS Enterprise Architecture (EA) and Cybersecurity.

    2. The DBA, with support from the SA and the SecSpec, shall ensure that use of strong authentication technologies; (such as PKI) for database authentications are compatible with IRS EA specifications.

10.8.4.5.1.2  (02-21-2008)
Password Guidelines

  1. Passwords must be protected from being accessed by unauthorized users in accordance with IRM 10.8.1. When an account is created for a user, that user shall be given a temporary password. Database users shall be adhere to IRS password policy and implementation of password protection in accordance with IRM 10.8.1 .

  2. All database passwords shall be stored in an encrypted format. The database account name and password shall not be visible to the host or client operating system when stored within the database.

  3. Where available, database account logons shall be limited to three failed logons before they become locked. This requirement reduces the ability for password cracking programs to be used successfully. The DBA shall set the duration of the lock time to a specific length in accordance with IRM 10.8.1 or require a manual reset. The duration should be set appropriately for the environment; keeping in mind that the longer the duration, the more protected the accounts will be from password cracking programs.

  4. Default passwords for the database accounts created during installation of DBMS software, DBMS optional software, or other COTS database software shall be changed immediately after installation in accordance with IRM 10.8.1.

    1. The DBA shall assign a temporary database account password at database account creation.

    2. The DBA shall ensure that database account passwords conform to IRS password policy and each user is briefed on the policy on receiving a temporary password.

    3. The DBA shall ensure that database account passwords are stored in an encrypted format.

    4. The DBA shall ensure that database account passwords comply with IRM 10.8.1.

    5. The DBA shall ensure that database administrator account passwords are changed every 60 days or more frequently and shall implement scripts, profiles, or other controls as necessary to enforce this requirement.

    6. The DBA shall ensure that database user account passwords are changed every 90 days or more frequently and shall implement scripts, profiles, or other controls as necessary to enforce this requirement.

    7. The DBA shall ensure that database account passwords are not reused within three password changes.

    8. The DBA shall ensure that application database account passwords are changed at least once a year and anytime an application administrator is reassigned.

    9. The DBA shall change all default database account passwords for database accounts created during DBMS installation and used by DBMS processes immediately after installation.

    10. Where available, the DBA shall limit database account logons to three failed logons before they become locked.

    11. Where available, the DBA shall set the length of database account lock time to a minimum consistent with the operating system standards.

10.8.4.5.1.3  (02-21-2008)
Certificate Guidelines