10.8.6  Secure Application Development

Manual Transmittal

September 30, 2014

Purpose

(1) This transmits the revised Internal Revenue Manual (IRM) 10.8.6, Information Technology (IT) Security, Secure Application Development.

Background

This IRM establishes comprehensive Information Technology (IT) security policies and provides guidance to all IRS organizations developing or modifying application code for use within the IRS. This IRM shall be used in conjunction with coding guidelines found in:

  1. IRM 2.5.3, Systems Development, Programming and Source Code Standards.

  2. Application Development's Final Secure Coding Guidelines document.

Federal Information Processing Standards (FIPS) 200 mandates the use of National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, as an initial set of baseline security controls for the creation of agency IT security policy.

IRM 10.8.6 is part of the Security, Privacy and Assurance policy family, IRM Part 10 series for IRS Information Technology Cybersecurity.

Material Changes

(1) The following sections have been updated/clarified with this version of policy:

  1. Restructured Manual Transmittal, introductory sections, and the Risk Acceptance and Risk-Based Decisions section, as well as the Exhibits, including the Glossary and Acronyms (now combined) to match standardized Security Policy language.

  2. Updated links throughout the document to reflect new organizational links.

  3. Clarified details in the Roles and Responsibilities section.

(2) Editorial changes (including grammar, spelling, and minor clarification) were made throughout the IRM.

Effect on Other Documents

This IRM supersedes all prior versions of IRM 10.8.6. This IRM supplements IRM 10.8.1, Information Technology (IT) Security Policy and Guidance; IRM 10.8.2, Information Technology Security Roles and Responsibilities; and IRM 10.8.3, Information Technology Audit Logging Security Standards.

Audience

IRM 10.8.6 shall be distributed to all personnel responsible for the code development or modification of commercial off-the-shelf (COTS) and government off-the-shelf (GOTS) software for use within the IRS. This IRM is not intended as a primer for novice program developers/programmers. The reader is expected to be well-versed and experienced in general systems engineering, software development, and software testing practices. The reader should have a thorough understanding of and experience with the development of software applications and web services and of the technologies involved. This policy applies to all employees, contractors, and vendors of the IRS.

Effective Date

(09-30-2014)

Terence V. Milholland
Chief Technology Officer

10.8.6.1  (09-30-2014)
Overview

  1. This IRM lays the foundation to implement and manage security for application development within the IRS.

10.8.6.1.1  (09-30-2014)
Purpose

  1. This IRM establishes the minimum baseline security policy and requirements for all IRS information technology (IT) assets in order to:

    1. Protect the critical infrastructure and assets of the IRS against attacks that exploit IRS assets.

    2. Prevent unauthorized access to IRS assets.

    3. Enable IRS IT computing environments that meet the security requirements of this policy and support the business needs of the organization.

  2. It is acceptable to configure settings to be more restrictive than those defined in this IRM.

  3. To configure less restrictive controls requires a risk-based decision. See the Risk Acceptance and Risk-Based Decisions section within this IRM for additional guidance.

10.8.6.1.2  (09-30-2014)
Authority

  1. IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance, establishes the security program and the policy framework for the IRS.

10.8.6.1.3  (09-30-2014)
Scope

  1. This IRM covers the creation and modification of commercial-off-the-shelf (COTS) and government off-the-shelf (GOTS) programs and applications.

  2. The provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS, and are to be applied.

    2. Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.

    3. All IRS information and information systems. For information systems that store, process, or transmit classified information, please refer to IRM 10.9.1, National Security Information, for additional procedures for protecting classified information.

  3. The IRS shall ensure that the product (e.g., software, hardware) and version selected is in accordance with IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) that dictates the official products and versions within the IRS.

  4. The IRS shall ensure the application or system version is a version for which the vendor offers continued technical support, and any new IRS applicable security requirements are communicated to the vender for upcoming releases.

  5. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 takes precedence, unless the security controls/requirements in this policy are more restrictive or otherwise noted.

10.8.6.1.4  (09-30-2014)
Risk Acceptance and Risk-Based Decisions

  1. Any exception to this policy requires that the Authorizing Official (AO) make a Risk-Based Decision (RBD).

  2. Risk-Based Decision requests shall be submitted in accordance with IRM 10.8.1 and use Form 14201, Risk Acceptance Request, as described in Risk Acceptance Request and Risk-Based Decision standard operating procedures (SOPs), available on the Enterprise FISMA Compliance SharePoint site via the Risk Acceptance Requests link at:
    http://it.web.irs.gov/cybersecurity/Divisions/SRM/Policy_Guidance/risk_acceptance.htm.

  3. Refer to IRM 10.8.1 for additional guidance on risk acceptance.

10.8.6.2  (09-30-2014)
Roles and Responsibilities

  1. IRM 10.8.2, Information Technology (IT) Security, IT 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.

10.8.6.3  (09-30-2014)
IT Security Controls

  1. Refer to IRM 10.8.1 for the other security control families other than those described in this IRM.

  2. The security controls in this IRM supplement the requirements defined in IRM 10.8.1.

10.8.6.3.1  (09-30-2014)
AC - Access Control

  1. Access to format strings used by the application shall be restricted to authorized users. (DISA: APP3450)

  2. An application shall not write to the system root directory (e.g., c:). (IRS-defined control)

  3. Only application files shall reside in an applications root directory (e.g., c:\Program Files\<application>). (IRS-defined control)

    1. Standard users shall only have read access to the application's root directory.

  4. An application shall not rely solely on a resource name to control access to a resource. (DISA: APP3460)

  5. Application resources (i.e., configuration and executable files) shall be protected with permission sets that only allow an application administrator to modify these configuration and files. (DISA: APP3450)

  6. Access control shall be performed in the business layer, not only the presentation layer. (OWASP)

  7. Buttons and links for functions and assets that are not authorized for the user shall not be displayed. (OWASP)

  8. The application shall not rely on "security through obscurity" in lieu of proper defense-in-depth techniques to protect application data, resources, and executable(s). Security through obscurity techniques should be used only as a "nice to have" addition to adequate defense-in-depth techniques that on their own reduce risk to the maximum acceptable level. (OWASP)

  9. The intended restricted directory access policy shall be enforced to prevent attackers from accessing unauthorized files inside and outside the restricted directory. (OWASP)

  10. The security policy for the application shall deny by default all permissions and access privileges. The application shall be designed to require the application’s authorized administrator to explicitly assign all permissions and access privileges to both human users and software processes, regardless of whether those permissions and privileges are granted individually, to user groups, or associated with roles or other attributes. (OWASP)

  11. The application shall not allow any user other than the authorized administrator to authorize or change privileges assigned to users. (IRS-defined)

  12. The application shall not allow any user to gain access to the application without first being positively authenticated by the application’s authentication mechanism, unless the application is a public access application. (IRS-defined)

  13. The application shall not allow any unauthorized user to gain access to restricted functions. For example, an attacker should not be able to access a restricted function simply by entering the pathname (i.e., Uniform Resource Locator (URL)/Uniform Resource Identifier (URI)) that points to that function. (IRS-defined)

  14. All interfaces and connections relied on by the application shall function correctly and securely. (IRS-defined)

    1. During application testing, verify that all secure interfaces and connections relied on by the application (from network physical layer up to application layer) function correctly and are connected to the intended systems.

  15. Database management system and host files system shall have access control to prevent unauthorized users from modifying any of the metadata associated with the database objects or Extensible Markup Language (XML) document. (IRS-defined)

    1. The application’s host file system and database management system (Database Management System (DBMS), if any) access controls shall be configured to prevent unauthorized users from modifying any of the metadata associated with a database object or XML document.

  16. An application shall not connect to a database using administrative credentials or other privileged database accounts. (DISA: APP3190)

  17. An application shall not allow direct access to the database management system and ensure that no features shall be exploited to bypass database management system access controls. (OWASP)

    1. An application that provides access to a database shall not contain features that can be exploited by a user to bypass the database management system’s access controls in order to directly modify the file system objects (files, directories) containing the database entries/records. The access controls of the file system directory containing those objects must be configured to prevent access by any role except the appropriate privileged role (e.g., database administrator).

    2. An application that provides access to a database shall not contain features that can be exploited by a user in order to assume the identity and permissions of a privileged user role (e.g., the database administrator) in order to access database objects in ways that the user’s own role would not permit.

    3. The access controls relied upon by a database or record management application shall be configured to prevent unauthorized users from modifying or deleting any established associations, reference links, or other relationships between database objects or records accessible via the application.

    4. The application shall ensure that every entity is authorized, through granting of appropriate privileges, to perform the functions it attempts to perform, and to access the resources/data it attempts to access in the specific way it attempts to access them.

    5. The application’s authorization service shall assign privileges to all entities based on a Role-Based Access Control (RBAC) scheme that is implemented and enforced by the discretionary and mandatory access controls that protect the application’s data and resources. At a minimum, privileged accounts (e.g., the administrator account) must be assigned unique roles.

    6. If the application’s authorization service supports the creation of group accounts, it shall also enable the assignment of privileges to group accounts.

    7. The application’s authorization service shall ensure that every entity relinquishes the privilege it has been granted as soon as it finishes performing the function for which the privilege was required. The application shall be designed so that its own processes relinquish their privileges as soon as they complete the operations for which those privileges were required. Even if an entity or process will need the same privilege later, the privilege must be assigned only at the time it is needed, and must be relinquished immediately when it is no longer needed.

    8. The access controls relied on by the application must be configured to prevent unauthorized entities from reading, modifying, augmenting, deleting, moving, or (in the case of executables) executing:
      1. The data written by the application.
      2.The configuration and security data used by the application.
      3.The application’s executables.

  18. The application shall not rely solely on database views or portal pages for access control. (OWASP)

    1. The following techniques shall not be relied upon to control access to data in a database or on a web server:
      1. Absence of certain data from a database view.
      2.Absence of certain web links from a portal page or web page.

    2. The application shall prevent an unauthorized user from modifying, overwriting, or augmenting the privileges assigned to an individual account, group account, or role.

    3. The application shall not be able to be used to override any of the file system or database access controls configured for a data object that is made accessible by the application. Specifically, the application must not allow a user to perform any unauthorized operation to a data object if the database/file system access controls protecting that data object are configured to prevent the user (or the user’s role) from performing that operation. Furthermore, if a user attempts to use the application to perform any unauthorized operation, the application must issue a warning message to the user informing him/her that he/she is attempting to perform an unauthorized operation. The application shall prevent any entity from performing application functions that entity’s authorizations do not explicitly permit it to perform.

    4. The application shall prevent any entity from performing application functions that entity’s authorizations do not explicitly permit it to perform.

    5. The application shall prevent an entity from performing any functions which the entity’s role is not explicitly granted permissions to perform.

    6. A portal/web application’s access controls shall not be implemented so that the user identification and authentication (I&A) dialog is only invoked when the user clicks on a link on the portal/web page, but should also be invoked when the user enters the URL/URI by typing it into the browser’s "Location" , "Address" , "Open" , etc. line or choosing it from a list of saved bookmarks. Regardless of the method used by the user to enter a URL/URI, the application must invoke the necessary user I&A dialog before granting the user access to the resource indicated by the URL/URI.

    7. Non-privileged processes shall not be granted access to privileged functions or data associated with privileged functions (e.g., security configuration files, security directories and databases, critical security parameters). Furthermore, non-privileged processes must not be granted any privileges associated with privileged roles.

    8. The application shall contain few or no processes that require privileged roles. The only processes that require privileged roles should be those that:
      1.Perform critical security functions, such as I&A, authorization, auditing, etc.
      2.Invoke external security functions (e.g., cryptographic modules).
      3.Access security data stores via trusted interfaces.

    9. Clients or proxy agents shall not be allowed to invoke privileged application processes.

    10. The application host’s file system access controls, discretionary and mandatory, shall ensure that entities are granted or denied access to the application’s executable(s), data, and resources based only on the privileges authorized to those entities under the application’s RBAC scheme.

    11. The access controls of the file system or data store to which the application writes user-created data shall prevent all users except the data’s creator from assigning or changing the discretionary access properties (read, write, delete) of the data he/she created while using the application.

    12. Privileged roles shall be granted only those privileges they need to perform their privileged functions. Entities that need to perform both privileged and non-privileged functions should be assigned two different accounts, one for the privileged role, and one for the non-privileged role. It should not be possible to perform non-privileged functions when logged into the privileged account, or to perform privileged functions when logged into the non-privileged account.

    13. Access control matrix shall be used to plan specific rules.

    14. The application shall not disclose actual object identifiers:
      1.Define a clear approach for protecting each type of object.
      2.Design a solution for masking actual object references.

    15. The account used to access the database shall have the minimum amount of privilege required by the application.

    16. Database references shall not expose primary/foreign keys, column and table names. Object references through session object shall be used.

    17. Where clause shall be used to enforce access control to ensure that expected relationships remain true (e.g., current user is owner of referenced object).

  19. The application shall verify that the actual results match the expected results criteria. (IRS-defined)

    1. For defense-in-depth, it is important to verify that the results match (e.g., if a single record is expected, ensure only one record is returned).

  20. Use Data Access Application Program Interfaces (APIs) to abstract and encapsulate all access to the data source. (IRS-defined)

  21. Any remote procedure call (RPC) issued by an application process to an execution environment component or to a remote application component shall not cause that remote component to perform any unauthorized or unexpected actions that could compromise the data, configuration files, security files, or executables owned or used by the remote component. (IRS-defined)

  22. An application shall verify any environment variables for correctness and report any deficiencies to the administrator. (IRS-defined)

    1. Before acting on an environment variable, the application shall verify the correctness of that variable (in terms of having an expected value), and shall report to the administrator any deficiencies in the variable (e.g., an unexpected value). The application shall verify that the resources and conditions expressed by the environment variable are:
      1.Present.
      2.Adequate.
      3.Operational.
      4.Correct, as necessary to ensure secure operation and interaction between the application and the environment component/function.

  23. An application acting as web front-end to a database or other data store shall grant users only read-only access to the backend database/data store. (IRS-defined)

    1. Users shall not be able to directly read or delete from the database/data store.

    2. To prevent the possibility of Structured Query Language (SQL) injection or other command injection attacks, an application that acts as a web frontend to a database or other data store shall grant users only read-only access to the backend database/data store. Users shall not be allowed to directly write to or delete from the database/data store. Instead, all user requests to update/delete should be made via user input in Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), or XML forms implemented by the front-end application, then converted by that application into a syntax (e.g., SQL) that can be understood by the backend database/data store. The web database front-end application should reject any user input that contains expressions in SQL, a scripting language, or a procedural language.

    3. For additional guidance, see to the SQL Injection Prevention Cheat Sheet by OWASP:
      https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

  24. Application execution shall not cause any file system objects that belong to any entity other than the application itself to be modified, deleted, overwritten, or substituted. In addition, the application should not contain vulnerabilities that could be exploited by an attacker to perform any such unauthorized modifications, deletions, overwriting, or substitutions. (IRS-defined)

    1. Privileged processes in custom-developed components shall ensure that untrusted processes are not invoked in non-developmental components.

    2. Untrusted processes shall not be permitted to invoke privileged processes in custom-developed components.

  25. The application shall enforce access controls against path guessing or listing of files and directories. (OWASP)

    1. Users who are able to infer the file system directory structure indicated by the relative pathnames in user-viewable source code should be prevented, by the configuration of the file system access controls, from:
      1. Listing the contents of any file system directory (e.g., to discover unpublished resources).
      2. Directly accessing at the file system level any file or resource stored on the application host.

    2. A server application or web service shall validate the entity that sends it any data intended for display to users (e.g., web page content), and should not display that data if the sending entity cannot be verified as trustworthy.

    3. A certificate shall not be used without first checking its expiration.

    4. Unexpired host-specific certificate data shall be validated, while the certificate read was valid, to ensure it is for the site originally requested. If the host-specific data contained in a certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host.

    5. A Public Key Encryption (PKE) application that performs I&A shall not authenticate any entity that presents a certificate whose status cannot be validated by application’s certificate validation service using an approved standard certificate validation technology.

10.8.6.3.1.1  (09-30-2014)
Secure Directory Access Control Configuration

  1. The operating system/framework access controls on the directories in which the application components are stored shall be configured to protect the application executable(s) from unauthorized access, modification, and deletion. (IRS-defined)

    1. The directories shall be configured to protect all sensitive application data, such as access control lists, security event logs, and other sensitive data used by the application (including data decrypted by the application before use).

    2. The directory configuration(s) shall also prevent the insertion of any file of any type (binary or text) by an entity that is not explicitly authorized to insert a file into the directory.

  2. All application and environment software executable(s) (both developmental and non-developmental), source code files, and documentation shall be placed under secure configuration management with strict access and version control. (IRS-defined)

    1. This procedure prevents any inappropriate access given the role of the person attempting the access and the life-cycle phase in which the attempt is made. For example, source code checked in prior to a code review should not be write-accessible after that; instead, if changes must be made, a new version of the code should be generated for the update (this will prevent a rogue developer from secretly inserting malicious logic into a code version that has already been approved by the reviewers).

  3. All execution environment components (including host file system, databases, and other data stores) that store application executable, data, configuration, security, or include files shall be configured to prevent access to those files by any role other than the role assigned to the application itself and the role(s) assigned to the application’s administrator(s). All other roles, including user roles, shall be denied direct access to the resources. (IRS-defined)

  4. The application host’s file system shall be configured to isolate security processes within the application. (IRS-defined)

  5. Non-developmental software components in the application or its execution environment shall be the latest versions, with all security patches applied. (IRS-defined)

  6. All default accounts (e.g., "nobody" , "Administrator" ) in non-developmental server components shall be disabled or renamed unless the application absolutely cannot run without those specific account names. (OWASP)

    1. If the specific account names are needed, then these shall be documented in the system security documentation (e.g., system security policy).

  7. All sensitive data at rest shall be protected in accordance with IRM 10.8.1.

10.8.6.3.1.2  (09-30-2014)
Account Management

  1. An application shall be installed with unnecessary accounts disabled or deleted by default. (DISA: APP3370)

  2. An application shall prevent the creation of duplicate accounts. (DISA: APP3380)

  3. Users’ accounts shall be locked in accordance with IRM 10.8.1 for unsuccessful logon attempts. (DISA: APP3390)

  4. Locked users’ accounts shall only be unlocked in accordance with IRM 10.8.1. (DISA: APP3400)

  5. User Account Management General Policy: (IRS-defined)

    1. Application or enterprise user IDs shall be unique.

    2. System service accounts or application accounts shall not be disabled for lack of use.

    3. User / System IDs not required shall be removed from the system.

  6. An account management process shall be implemented, verifying only authorized users can gain access to and application and individual accounts designated as inactive, suspended, or terminated are promptly removed. (DISA: APP6210)

  7. If passwords generated for users, the passwords shall not be predictable and comply with the IRS’ password policy. (DISA: APP6220)

  8. Application users shall not use shared accounts. (DISA: APP6230)

  9. Inactive user accounts shall be disabled in accordance with IRM 10.8.1 guidance. (DISA: APP6240)

  10. Unnecessary built-in application accounts shall be disabled. (DISA: APP6250)

  11. Default passwords shall be changed. (DISA: APP6260)

  12. An application shall be configured to ensure account passwords conform to IRS password policy. (DISA: APP3320)

10.8.6.3.1.3  (09-30-2014)
Least Privilege

  1. An application shall be organized by functionality and roles to support the assignment of specific roles to specific application functions. (DISA: APP3470)

  2. Access to privileged accounts shall be limited to privileged users. (DSIA: APP3470)

  3. Non-privileged accounts shall be limited to non-privileged users. (DISA: APP3470)

  4. The application account shall be established and administered in accordance with a role-based access scheme to enforce least privilege and separation of duties. (DISA: APP3470)

  5. An application’s access procedures shall enforce the principles of separation of duties and "least privilege" . (DISA: APP3480)

  6. An application shall execute with no more privileges than necessary for proper operation. (DISA: APP3500)

  7. All security components in the execution environment (e.g., access control systems, cryptographic components) with which the application interacts, such as procedure calls, system calls, API, or networking protocols, shall be configured based on least privilege and least functionality principles in accordance with IRM 10.8.1. (OWASP)

  8. Entities (human users and processes) shall not be allowed to retain privileges "for future use" . Instead, a privilege should be assigned to the entity when it is needed, and revoked as soon as the function requiring the privilege has been completed. (IRS-defined)

    1. The development team lead shall ensure access privileges are reviewed, periodically, during the development process and remove unnecessary privileges.

10.8.6.3.1.4  (09-30-2014)
System-Use Notification

  1. An application shall be capable of displaying a system-use notification/warning banner in accordance with IRM 10.8.1. (DISA: APP3440)

10.8.6.3.1.5  (09-30-2014)
Previous Logon (Access) Notification

  1. An application shall have the capability to notify the user on login of date and time of the user's last unsuccessful logon, Internet Protocol (IP) address of the user’s last unsuccessful logon, date and time of the user's last successful logon, IP address of the user’s last successful logon, and number of unsuccessful logon attempts since the last successful logon. (DISA; APP3660)

  2. An application shall have the capability to display the user’s time and date of the last change in data content. (DISA: APP3670)

10.8.6.3.1.6  (09-30-2014)
Application Session Control

  1. An application shall support detection and/or prevention of communication session hijacking. (DISA: APP3405)

  2. An application shall provide a capability to limit the number of logon sessions per user in accordance with IRM 10.8.1. (DISA: APP3410)

  3. An application shall provide a capability to limit the total number of logon sessions for the application in accordance with IRM 10.8.1. (DISA: APP3410)

  4. An application shall provide a capability to automatically terminate a session and logout after a system defined session idle time limit is exceeded in accordance with IRM 10.8.1. (DISA: APP3415)

  5. An application shall provide a capability to terminate a session and logout in accordance with IRM 10.8.1. (DISA: APP3420)

  6. An application shall remove authentication credentials on client computers after a session terminates. (DISA: APP3430)

10.8.6.3.2  (09-30-2014)
AT - Security Awareness and Training

  1. In accordance with FISMA Specialized IT Training, the development team shall be trained in basic privacy law requirements (such as Privacy Act requirements and E-Government Act requirements), application development-related best practices (including threat modeling, misuse cases, test tools), and overall development security practices for implementing secure code.

  2. Personnel involved in program management shall receive security training regarding the necessity, impact, and benefits of integrating secure development practices into the development lifecycle. (DISA: APP2120.1)

  3. Designers shall receive, at a minimum, annual training on secure design principles for the entire Software Development Life Cycle (SDLC) and newly-discovered vulnerability types. (DISA: APP2120.2)

  4. Developers shall receive, at a minimum, annual training on secure design and coding practices. (DISA: APP2120.3)

  5. Testers shall receive, at a minimum, annual training on security testing practices. (DISA: APP2120.4)

  6. Refer to IRM 10.8.1 for additional guidance on Security Awareness and Training.

10.8.6.3.3  (09-30-2014)
AU - Audit and Accountability

  1. For additional guidance on Audit and Accountability, see IRM 10.8.1 and IRM 10.8.3Information Technology (IT) Security, Audit Logging Security Standards.

10.8.6.3.3.1  (09-30-2014)
Audit Events

  1. An application design shall have the capability to log all access to need-to-know information. (DISA: APP3680)

  2. An application shall log all failed access attempts to need-to-know information. (DISA: APP3680)

  3. The records vulnerable to unauthorized deletion, modification, or disclosure shall be audited by the application. (IRS-defined)

  4. The application shall log important security-relevant events. (IRS-defined)

    1. The application should log all security relevant events in a format that can be easily incorporated into the system audit logs. The type and amount of information to be collected by the log should be consistent with the requirements of the overall audit policy for the system. Security logs should never store authentication or authorization credentials.

    2. The application shall log all security-relevant events associated with reading, creating, overwriting, deleting, or copying/replication of objects in the schema of databases, directories, repositories, and XML documents used by the application. Auditing shall be able to be configured on and off by the administrator on a per-object basis.

  5. The audit service used by the application shall permit the administrator to select the events to be audited and the information to be captured about each event, with the caveat that logging of events and capturing of audit data required by policy should not be able to be turned off by the administrator. (IRS-defined)

10.8.6.3.3.2  (09-30-2014)
Audit Record Content

  1. Passwords shall not be written to the audit log/records. (IRS-defined)

  2. An application’s publicly releasable data audit records shall include: (DISA: APP3680)

    • Userid

    • Successful and unsuccessful attempts to access security files

    • Date and time of the event

    • Type of event

  3. An application’s sensitive data audit records shall include: (DISA: APP3680)

    • Userid

    • Successful and unsuccessful attempts to access security files

    • Date and time of the event

    • Type of event

    • Success or failure of event

    • Successful and unsuccessful logons

    • Denial of access resulting from excessive number of logon attempts

    • Blocking or blacklisting a userid, terminal or access port and the reason for the action

    • Activities that might modify, bypass, or negate safeguards controlled by the system

10.8.6.3.3.3  (09-30-2014)
Audit Storage Capacity

  1. An application shall have a capability to notify an administrator when audit logs are nearing capacity as specified in the system documentation. (DISA: APP3650)

10.8.6.3.3.4  (09-30-2014)
Audit Service Failure

  1. The application’s exception handling service shall enable core dumps to be turned off when the application is not undergoing testing. The exception handling service should be configured with core dump turned off when the application is deployed operationally. (IRS-defined)

  2. If the application’s audit service fails, the application shall notify the administrator and perform the administrator-configured recovery action. (IRS-defined)

    1. The application’s audit service shall include a tool that enables the administrator to view the application’s audit records and to run reports against them.

    2. The application’s exception handling service shall log all exceptions and failure events to an exception log. The exception handling service shall provide a tool through which the exception log is rendered human-readable by the privileged administrator role.

10.8.6.3.3.5  (09-30-2014)
Audit Record Retention

  1. Application audit records shall be retained in accordance with IRM 10.8.3 guidance.

10.8.6.3.3.6  (09-30-2014)
Audit Generation

  1. An application shall support the creation of transaction logs for access and changes to the data. (DISA: APP3640)

  2. Logs shall be generated and viewed using techniques preventing log injections and preventing attackers from misleading administrators or covering traces of attack. (OWASP)

  3. The application audit service shall log security events to read-only storage area and/transmitted securely over to a confidential, tamper-resistant network connection. (IRS-defined)

    1. Use of the application shall be monitored by an audit service by which all security-related application events can be either:
      1.Logged to an otherwise read-only storage location in the application host’s file system (with read-write access configurable only by the privileged security administrator role).
      2.Transmitted securely over a confidential, tamper-resistant network connection to a protected external audit collection facility.

    2. The audit service used by the application shall bind the username or process ID to the audit record of each event caused by the entity to which that username/process ID belongs.

  4. An audit trail shall be readable only by the application and auditors. (DISA: APP3690)

  5. An audit trail shall be protected against modification or deletion except by the application and auditors. (DISA: APP3690)

  6. Audit trails shall be periodically reviewed based on system documentation recommendations or immediately upon system security events. (DISA: APP6110)

  7. All suspected violations of IRS security policies shall be reported in accordance with IRS incident reporting procedures. (DISA: APP6120)

  8. Audit trails shall be readable only by application administrators and auditors. (DISA: APP3690)

  9. Audit trails shall be protected against modification or deletion except by application administrators and auditors. (DISA: APP3690)

10.8.6.3.4  (09-30-2014)
CA - Security Assessment and Authorization

  1. All appointments to required IA roles shall be established in writing (e.g., System Security Plan (SSP)) to include assigned duties and appointment criteria such as training, security clearance, and IT designation. (DISA: APP2010)

  2. See IRM 10.8.1 for additional guidance on security assessment and authorization.

10.8.6.3.4.1  (09-30-2014)
Security Assessments

  1. Security Assessments (initial, iterative, and re-assessments) shall be performed throughout the software’s lifecycle. (IRS-defined)

  2. Refer to the Application Development PMO Security’s Final Secure Coding Guidelines document for additional guidance on secure coding security assessments.

10.8.6.3.4.2  (09-30-2014)
Plan of Action and Milestones (POA&M)

  1. The results from security assessments shall be entered into the Plan of Action and Milestones (POA&M) for management approval or risk acceptance.(IRS-defined)

10.8.6.3.5  (09-30-2014)
CM - Configuration Management

  1. An application shall be deployed in a manner consistent with the Application Configuration Guide provided. (DISA: APP2020)

  2. The application shall be decommissioned when maintenance or support is no longer available. (DISA: APP6060)

  3. Provisions shall be in place to notify users when an application is decommissioned. (DISA: APP6070)

  4. See IRM 10.8.1 for additional guidance on IT Security Configuration Management (CM) requirements.

10.8.6.3.5.1  (09-30-2014)
Baseline Configuration

  1. Before each code review begins, design documentation and code to be reviewed shall be checked into the CM system and baselined. (IRS-defined)

  2. Every configuration item shall be checked into the CM system as a baseline before it is reviewed or tested. (IRS-defined)

10.8.6.3.5.2  (09-30-2014)
Configuration Change Controls

  1. A Configuration Control Board (CCB)shall be established to manage the CM process. (DISA: APP4040)

  2. The Information System Security Officer (ISSO) shall be a member of the CCB. (DISA: APP4040)

  3. The CCB shall meet at least every release cycle or more often. (DISA: APP4040)

10.8.6.3.5.3  (09-30-2014)
Access Restrictions for Change Management

  1. Roles and duties in the CM system shall be separated (development, test, and production with corresponding personnel should be assigned different noncontiguous roles with separate access rights to the system). (IRS-defined)

  2. The access privileges to the CM repository shall be reviewed every 3 months. (DISA: APP4010)

10.8.6.3.5.4  (09-30-2014)
Configuration Settings

  1. Development systems, build systems, and test systems shall have standardized environment settings established and be documented in the Application Configuration Guide. (DISA: APP2020)

    1. Standardization environment settings shall include, at a minimum, the software load, system configuration, and network configuration.

  2. Known security assumptions, implications, system-level protections, best practices, and required permissions shall be documented in the Application Configuration Guide. (DISA: APP2020)

  3. Deployment configuration settings shall be documented in the Application Configuration Guide. (DISA: APP2020)

  4. Application(s) shall have automated configuration tool(s) or script(s) that enables the administrator to set the parameters that govern the operation of the application’s security components and the characteristics of its security properties. (IRS-defined)

    1. The tool/script shall include a "feedback" capability that informs the administrator of possible security deficiencies in the configuration he/she has defined.

    2. For any application security component configuration that cannot be automated by a tool or script, manual configuration procedures shall be documented, and training should be provided to administrators on how to perform those procedures.

10.8.6.3.5.5  (09-30-2014)
Least Functionality

  1. The application shall be configured to comply with IRS-approved ports and protocol guidance. (DISA: APP2100)

10.8.6.3.5.6  (09-30-2014)
Software Configuration Management (SCM) Plan

  1. A Software Configuration Management (SCM) Plan shall be developed. (DISA: Application Security and Development STIG v3r5)

  2. The SCM Plan shall include the following: (DISA: APP4030)

    1. Describing the configuration control and change management process of objects developed and the roles and responsibilities of the organization.

    2. Identify all objects created during the development process subject to configuration control.

    3. Maintain procedures for identifying individual application components, as well as, entire application releases during all phases of the software development lifecycle.

    4. Identify and track all actions and changes resulting from a change request from initiation to release.

    5. Contain procedures to identify, document, review, and authorize any change requests to the application.

    6. Define the responsibilities, the actions to be performed, the tools, techniques and methodologies, and defines an initial set of baseline software components.

    7. Objects shall have security classifications labels.

    8. Identify tools and version numbers used in the software development lifecycle.

    9. Identify mechanisms for controlled access of simultaneous individuals updating the same application component.

    10. Define how only authorized changes by authorized persons are possible.

    11. Identify mechanisms to control access and audit changes between different versions of objects subject to configuration control.

    12. Identify mechanisms to track and audit all modifications of objects under configuration control. Audits shall include the originator and date and time of the modification.

10.8.6.3.6  (09-30-2014)
Contingency Planning

  1. Recovery procedures and technical system features shall exist so recovery is performed in a secure and verifiable manner. (DISA: APP6160)

  2. The circumstances inhibiting a trusted recovery shall be documented (e.g., SSP). (DISA: APP6160)

  3. Back-up copies of the application software shall be stored in a fire-rated container or otherwise not collocated with the operational software. (DISA: APP6170)

  4. See IRM 10.8.1 for additional guidance on Contingency Planning.

10.8.6.3.6.1  (09-30-2014)
Data Backup

  1. Procedures shall be in place to assure the appropriate physical and technical protection of the backup and restoration of an application. (DISA: APP6180)

  2. Data backup shall be performed based on the criticality of the data as documented in the system’s security documentation. (DISA: APP6190)

10.8.6.3.6.2  (09-30-2014)
Disaster Recovery Plan

  1. A disaster recovery plan shall exist based on the criticality of the data as documented in the system’s security documentation. (DISA: APP6200)

10.8.6.3.7  (09-30-2014)
IA - Identification and Authentication

  1. It shall not be possible to bypass authentication by alternative paths/URLs. (IRS-defined)

  2. Identification and authentication shall take place before access, modification, or transfer of SBU information. (IRS-defined)

    1. Before allowing an individual to access, modify, or transfer his/her personal information, the application shall authenticate that individual based on his/her username/password or another approved credential the robustness of which equals or exceeds the robustness of username/password.

    2. Refer to the IRS PII web page:
      http://irweb.irs.gov/AboutIRS/bu/pipds/pip/privacy/privacy_art/8352.aspx

  3. A server application or provider web service must present an authentication credential to any client or requestor service that asks for that credential in order to authenticate the server application/provider before sending data or request messages to it. (IRS-defined)

  4. The application shall not send unsolicited authentication data. (IRS-defined)

    1. Sending data that is used for authentication decisions to the client side shall be limited as much as possible or not done at all.

    2. User identity shall be sufficiently verified during authentication to prevent spoofing.

  5. IP addresses shall not be used as authentication since they can be easily spoofed. (IRS-defined)

  6. Authentication request shall be initiated by the entity that wishes to be authenticated. (IRS-defined)

    1. For every session (or transaction) initiated by a user, an authentication chain of trust should be established and maintained that begins at the user’s client, extends to the portal, thence onward from the portal to any back-end application servers, web servers, database servers, or web services with which the user is permitted to interact.

    2. A web application’s authentication service should not use basic or digest authentication. Instead, the authentication service should use form authentication, or cookie authentication with a temporary (one-time) encrypted cookie.

    3. An entity should never be authenticated based solely on its username or account name. The entity should always present an authentication credential.

  7. Server/Web service that authenticates based on role or group authentication shall perform individual authentication first. (IRS-defined)

    1. A server application/web service that authenticates an entity based on a role or group authentication credential submitted by that entity must first ensure that the entity:
      1.Actually belongs to the role/group associated with the credential.
      2.Has already been individually authenticated by an authentication service trusted by the server/web service.

    2. The application shall not authenticate entities that have anonymous account names or account names commonly associated with default accounts on COTS or Operation Support Systems (OSS).

    3. The application’s authentication service shall not be implemented by client-side code. All authentication service code should be implemented on a server.

    4. The application’s authentication service shall not be implemented in an application level or system level scripting language.

    5. The account management service of the application shall enable the administrator to designate any text string he/she chooses as the name assigned to any user, group, or role account and shall require the administrator to choose a predefined unique name for each account. If the application’s default configuration includes default account name(s), the account management service shall require the administrator to change those default account name(s). The application shall continue to operate correctly regardless of any such changes.

    6. All pages involved with authentication process shall use Hypertext Transfer Protocol Secure (HTTPS).

    7. Login failure shall not indicate whether username or password failed or that the account is locked.

10.8.6.3.7.1  (09-30-2014)
Authenticator Management

  1. The application shall utilize approved strong authentication credentials. (IRS-defined)

    1. Authentication of the following types of entities shall be implemented based on an approved strong authentication credential:
      1.Remote users of private server applications/services.
      2.Users (local and remote) of private intelligence server applications/services.
      3.Users, such as administrators, who belong to privileged roles/perform privileged functions.
      4.Privileged roles (e.g., administration).

  2. An application shall not contain embedded authentication data. (DISA: APP3350)

  3. An application shall be designed to not display account passwords as clear text. (DISA: APP3310)

  4. An application shall have the capability to require account password character lengths to be in accordance with IRM 10.8.1 . (DISA: APP3320)If passwords generated for users, the passwords shall not be predictable and shall comply with the IRS’ password policy. (DISA: APP6220)

  5. An application shall have the capability to require account passwords to contain a mix of uppercase letters, lowercase letters, numbers, and special characters in accordance with IRM 10.8.1. (DISA: APP3320)

  6. An application shall have the capability to require account passwords be changed in accordance with IRM 10.8.1. (DISA: APP3320)

  7. An application shall have the capability to limit reuse of account passwords within in accordance with IRM 10.8.1. (DISA: APP3320)

  8. An application shall have the capability to limit user changes to their account passwords in accordance with IRM 10.8.1. (DISA: APP3320)

  9. An application shall have the capability to require new account passwords differ from the previous password by at least changing the number of characters in accordance with IRM 10.8.1 when a password is changed. (DISA: APP3320)

  10. Passwords shall not contain personal information such as names, telephone numbers, account names, birthdates, or dictionary words. (DISA: APP3320.4)

  11. An application shall transmit account passwords in an approved encrypted format. (DISA: APP3330I)

  12. An application shall store account passwords in an approved encrypted format. (DISA: APP3340)

  13. Only approved session token technology shall be used. (IRS-defined)

    1. A web application that re-authenticates users based on session tokens shall accept only approved session token technology for this purpose.

    2. Session tokens shall not be stored in the URL as this is subject to replay attacks.

    3. The application’s security policy shall define the authentication and access control parameters for the application. Authentication parameters include authentication credential details, number of allowed failed authentication attempts, credential expiration periods, etc. Access control parameters include the attributes (i.e., roles) required for users who will be allowed to access the application, and the ways in which each type of user (as defined by these attribute(s)) will be allowed to access the application (e.g., execute-only, modify, delete).

  14. All default accounts shall have their default passwords changed upon installation, in accordance with IRM 10.8.1.

10.8.6.3.7.1.1  (09-30-2014)
Public Key Infrastructure (PKI) Authentication

  1. Applications shall use Department of Treasury Public Key Infrastructure (PKI) when required in accordance with IRM 10.8.1 and IRM 10.8.52, Information Technology (IT), PKI Security Policy.

  2. Applications requiring user authentication shall be Public Key (PK)-enabled. (DISA: APP3280)

  3. Applications requiring user authentication shall be designed and implemented to support hardware tokens. (DISA: APP3280)

  4. PK-enabled applications shall be configured to honor only IRS-approved PKI certificates. (DISA: APP3290)

10.8.6.3.8  (09-30-2014)
IR - Incident Response

  1. A security incident response process for the application shall be followed. (DISA: APP2140)

  2. See IRM 10.8.1 for additional guidance on Incident Response.

10.8.6.3.9  (09-30-2014)
PE - Physical and Environmental Protection

  1. Procedures shall be implemented to assure physical handling and storage of information is in accordance with the data’s sensitivity. (DISA: APP2150)

  2. See IRM 10.8.1 for additional guidance on Physical and Environmental Protection.


More Internal Revenue Manual