Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 1. Policy and Guidance

10.8.1  Policy and Guidance

Manual Transmittal

November 25, 2011

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 10.8.1, Information Technology (IT) Security, Policy and Guidance.

Background

IRM 10.8.1 was last revised July 31, 2010. Since that update, new Executive Orders (E.O.s), federal regulations, Office of Management and Budget (OMB), E-Government Act, and Department of Treasury guidance have been issued, which implement changes to security related policy for protection of all information and systems.

Material Changes

(1) This IRM establishes the comprehensive, uniform IT security policies to be followed by all IRS organizations.

(2) IRM 10.8.1 has been completely revised to conform to the Treasury IT Security Program, (TD P) 85-01, which provides explicit requirements and traceability back to Treasury. It also incorporates new Internal Revenue Service (IRS) requirements.

(3) IRM 10.8.1 has been aligned to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Recommended Security Controls.

(4) Chief, Mission Assurance and Security Services (MA&SS), now Associate Chief Information Officer (ACIO), Cybersecurity.

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

  1. All sections

(6) The following Interim Guidance Memorandums have been incorporated:

  1. Interim Guidance # MITS-10-0311-18, Information Technology (IT) Security, Policy and Guidance - Separation From Duty, Business Role Account Inactivity, and Password Management, dated May 30, 2011;

  2. Interim Guidance # MITS-10-0311-17, Information Technology (IT) Security, Policy and Guidance - PII on GPS Devices, dated April 8, 2011;

  3. Interim Guidance # MITS-10-0211-13, Information Technology (IT) Security, Policy and Guidance - Risk Based Decision (RBD), dated February 28, 2011;

  4. Interim Guidance # MITS-10-1210-06, Information Technology (IT) Security, Policy and Guidance - Information Technology (IT) with Video and Photographic Capabilities, dated January 31, 2011;

  5. Interim Guidance # MITS-10-1010-01, Information Technology (IT) Security, Policy and Guidance - Revised Security Controls for Remote Access, dated October 29, 2010;

  6. Interim Guidance # MITS-10-0910-27, Information Technology (IT) Security, Policy and Guidance - Malicious Code Protection, dated October 8, 2010;

  7. Interim Guidance # MITS-10-0810-26, Information Technology (IT) Security, Policy and Guidance - Personnel Security, dated August 31, 2010;

  8. Interim Guidance # MITS-10-0810-25, Information Technology (IT) Security, Policy and Guidance - Account Management, dated August 31, 2010;

  9. Interim Guidance # MITS-10-0810-24, Information Technology (IT) Security, Policy and Guidance - Remote Access (from non-US locations), dated August 6, 2010;

  10. Interim Guidance # MITS-10-0810-23, Information Technology (IT) Security, Policy and Guidance - Collaborative Software, dated August 6, 2010;

  11. Interim Guidance # MITS-10-0510-19, Information Technology (IT) Security, Policy and Guidance - Certification and Accreditation (C&A), dated August 6, 2010;

  12. Interim Guidance # MITS-10-0710-22, Information Technology (IT) Security, Policy and Guidance - Personally-Owned and Other Non-Government Furnished Equipment (Exception for Personally-Owned “Monitors”), dated July 23, 2010;

  13. Interim Guidance # MITS-10-0911-27, Information Technology (IT) Security, Policy and Guidance - Negative Taxpayer Identification Number (TIN) Checking”), dated September 30, 2011;

  14. Interim Guidance # MITS-10-0911-30, Information Technology (IT) Security, Policy and Guidance - IRM 10.8.1 Pre-Release, dated September 30, 2011;

  15. Interim Guidance # MITS-10-0911-29, Information Technology (IT) Security, Policy and Guidance - Risk-Based Decision Tracking, dated October 7, 2011;

(7) The entire IRM content is being released as guidance to facilitate implementation of the numerous updates to IRM 10.8.1 to conform to the Treasury IT Security Program, (TD P) 85-01, which provides explicit requirements and traceability back to Treasury. It also incorporates new Internal Revenue Service (IRS) requirements. The revised policy also aligns with NIST SP 800-53 Rev3. IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance is also being published via the normal IRM publication process.

Effect on Other Documents

This IRM supersedes all prior versions of IRM 10.8.1.

Audience

IRM 10.8.1 shall be distributed to all personnel responsible for ensuring that adequate security is provided for IRS information and information systems. This policy applies to all employees, contractors, and vendors of the IRS.

Effective Date

(11-25-2011)

/s/ Sharon C. James
Acting Director, Cybersecurity Architecture and Implementation

10.8.1.1  (11-25-2011)
Purpose

  1. This Internal Revenue Manual (IRM) provides policies and guidance to be used by Internal Revenue Service (IRS) organizations to carry out their respective responsibilities in information systems security. It provides guidance on all aspects of security for the protection of Information Technology (IT) resources.

10.8.1.1.1  (11-25-2011)
Overview

  1. It is the policy of the IRS to establish and manage an Information Security Program within all its offices. This manual provides uniform policies and guidance to be used by each office.

  2. It is the policy of the IRS to protect its information resources and allow the use, access, and disclosure of information in accordance with applicable laws, policies, federal regulations, Office of Management and Budget (OMB) Circulars, Treasury Directives (TDs), National Institute of Standards and Technology (NIST) Publications, other regulatory guidance, and best practice methodologies. All IT resources belonging to, or used by the IRS, shall be protected at a level commensurate with the risk and magnitude of harm that could result from loss, misuse, or unauthorized access to that IT resource. It is the policy of the IRS to use best practices methodologies (such as CMMI, ELC, ITIL, and LSS) to document and improve IRS IT process and service efficiency and effectiveness.

  3. This policy delineates the security management structure, assigns responsibilities, and lays the foundation necessary to measure progress and compliance. Requirements in this policy are subdivided under three major security control areas: management, operational, and technical.

  4. IRM 10.8.1 provides the overall security control guidance for the IRS. This guidance establishes the IT security framework for the development of security control specific implementations defined in subordinate IRMs and subordinate procedural guidance (Standard Operating Procedures, Desk Procedures, etc.).

    1. Subordinate IRMs offer additional business security controls for operating systems and platforms. http://mits.web.irs.gov/cybersecurity/Policy_Compliance/IRMS.htm

    2. Subordinate procedural guidance shall be used to provide detailed guidance for implementing and complying with the requirements within this IRM.

    3. For a high-level summary of an IRM, refer to the applicable Companion Guide.

    4. If there is a conflict with or variance from this IRM within the subordinate IRMs or procedural guidance, IRM 10.8.1 has precedence unless specifically noted otherwise within this IRM.

  5. For the purpose of this IRM, the following terms apply:

    1. IRS personnel or users, which includes:
      i. employees
      ii. consultants
      iii. detailees
      iv. temporary employees
      v. interns
      vi. IRS contractors

    2. Authorized or Unauthorized personnel infers to all IRS personnel being authorized or unauthorized to perform a particular action.

  6. This publication of IRM 10.8.1 supersedes and obsoletes all previously issued Interim Guidance (IG) and postings on information sharing environments associated with the IRM at the time of the posting.

  7. Cybersecurity has already documented and published security controls (IRM 10.8.x Suite) for IRS's Information Technology Environment/Resources. IRM 10.8.1, requires that Authorizing Officials (AO), establish and implement enterprise-wide procedures for management, operational, and technical controls for IT technology. Additionally, AOs are required to develop and maintain additional operational documentation (e.g., action and implementation plans, standard operations procedures (SOP)), etc. necessary for implementation of the security controls; delineated in IRM 10.8.x. Therefore, implementation of security policy is the responsibility of the owning AO; to include documentation and procedures for how their information systems are managed, administered and monitored.

  8. In an effort to reference the origin of a security requirement (NIST, Treasury, etc), a requirement may have the origin referenced in parenthesis at the end of the requirement, such as (NIST SP 800-53 CA-1) or (TD P 85-01 S-PM.1).

10.8.1.1.2  (12-16-2006)
Scope

  1. The provisions in this manual apply to all offices, business, operating, and functional units within the IRS, and are to be applied when IT is used to accomplish the IRS mission. This manual also applies to individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems containing IRS data.

  2. This policy governs 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.

10.8.1.1.3  (11-25-2011)
IRM Section Topics

  1. This manual contains information on the following subjects:

    • Purpose

    • General Policy

    • Management Controls

    • Operational Controls

    • Technical Controls

    • Risk Based Decisions

    • IRM 10.8.1 Management Control Crosswalk to NIST and TD P (See Exhibit 10.8.1-1)

    • IRM 10.8.1 Operational Control Crosswalk to NIST and TD P (See Exhibit 10.8.1-2)

    • IRM 10.8.1 Technical Control Crosswalk to NIST and TD P (See Exhibit 10.8.1-3)

    • NIST SP 800-53 to IRM 10.8.1 Crosswalk for Management Controls (See Exhibit 10.8.1-4)

    • NIST SP 800-53 to IRM 10.8.1 Crosswalk for Operational Controls (See Exhibit 10.8.1-5)

    • NIST SP 800-53 to IRM 10.8.1 Crosswalk for Technical Controls (See Exhibit 10.8.1-6)

    • TD P 85-01 Treasury Control Enhancer to IRM 10.8.1 Crosswalk (See Exhibit 10.8.1-7)

    • Glossary and Acronym List (See Exhibit 10.8.1-8.)

    • References (See Exhibit 10.8.1-9.)

10.8.1.1.4  (11-25-2011)
Authority

  1. IRM 10.8.1 is issued in support of Treasury Department Publication (TD P) 85-01, Treasury IT Security Program, under the authority of TD 85-01, Department of the Treasury Information Technology (IT) Security Program.

  2. TD P 85-01, Treasury Information Technology Security Program, provides a high-level view of IT security policy for senior executives, managers, and IT security practitioners, and is divided into two volumes.

    1. Volume I, Unclassified (Non-National Security) Systems, applicable to all information systems that do not process national security information (NSI).

    2. Volume II, Classified (National Security) Systems, applicable to all information systems that process or communicate NSI.

10.8.1.2  (11-25-2011)
General Policy

  1. In accordance with Title III of the E-Government Act, known as the Federal Information Security Management Act (FISMA), the IRS shall develop, document, and implement a service-wide information security program supporting the operations and assets of this agency.

    1. There shall be no grandfathering of requirements contained in this IRM.

    2. There shall be no exceptions to the requirements of this IRM based on past practices.

  2. Information systems approved for classified processing shall not be connected to any system not approved for classified operation. Systems approved for classified processing shall not share peripherals with unclassified processing equipment except through National Security Agency (NSA) -approved switching devices. Approval for the use of switching devices shall be included in the security authorization documentation.

  3. The IRS Information Security Program shall:

    1. Ensure the objectives of applicable laws, policies, federal regulations, OMB Circulars, TDs, NIST Publications, and other regulatory guidance are met by establishing and ensuring compliance with security requirements, procedures, and guidelines to properly implement management, operational, and technical controls;

      Note:

      In situations where regulatory guidance has been released outside of the annual update cycle for IRS requirement documents, the requirements within the regulatory guidance will be met through the issuance of interim guidance.

    2. Ensure that information systems used by the IRS operate effectively and provide appropriate confidentiality, integrity, and availability (CIA), through the use of cost-effective management, operational, and technical controls;

    3. Implement policies, standards, and procedures which are consistent with government-wide policies, standards, and procedures issued by the OMB, the Department of Commerce, the General Services Administration (GSA), and the Office of Personnel Management (OPM). Different or more stringent requirements for securing national security information shall be incorporated into agency programs as required by appropriate national security directives;

    4. Provide for the protection of Homeland Security Presidential Directive (HSPD) 7 Critical Infrastructure Identification, Prioritization and Protection, by identifying critical assets and individual, proprietary, financial, tax, mission critical, or otherwise sensitive information;

    5. Plan interdependency analyses of all designated Critical Infrastructure Protection (CIP) systems within one year of being designated an IRS critical asset, and complete the analyses within two years of critical asset Critical Infrastructure/Key Resource (CI/KR) designation (TD P 85-01 P-CIP.5);

    6. Review each interdependency analysis and provide updates at least every three years or whenever there has been a major change to the critical asset or its environment impacting the value chain;

    7. Ensure the ability to maintain processing during and following an emergency;

    8. Ensure the auditability of all information systems;

    9. Ensure management is responsible for designating the sensitivity of information, providing security controls, and certifying adequacy of these controls;

    10. Ensure management accountability for resources entrusted to them in accomplishing IRS objectives; and

    11. Ensure individual accountability for the data, information, and other IT resources to which individuals have access.

      Note:

      Implementation of the security controls defined within this IRM address the IRS Information Security Program requirements explicitly or implicitly.

  4. The IRS Information Security Program shall include:

    1. Risk assessments that consider internal and external threats to the CIA of systems and data supporting critical operations and assets;

    2. Policies and procedures that address the risk assessments associated with the operations and assets for programs and systems by cost effectively reducing information security risks to an acceptable level, and ensuring compliance with prescribed policies and procedures;

    3. Security Awareness Training and Education (SATE) to inform personnel of information security risks, procedures designed to reduce such risks, and their personal impact/responsibilities for both;

    4. Management testing and evaluation of the effectiveness of information security policies and procedures;

    5. A process for ensuring remedial action is defined for addressing deficiencies;

    6. Procedures for detecting, reporting, and responding to security incidents; mitigation of risks associated with such incidents before substantial damage occurs; notification/consultation with appropriate law enforcement officials and other offices/authorities; and

    7. Appropriate reporting to proper authorities of weaknesses and remedial actions.

  5. The IRS shall implement the provisions of FISMA to include the guidelines outlined in NIST publications, OMB circulars, and Federal Information Processing Standards (FIPS).

  6. All IRS information systems that generate, store, process, transfer, display, or communicate non-national security information shall be protected at a level commensurate with the potential impact of a loss of confidentiality, integrity, or availability on IRS’ operations, assets, or individuals.

  7. This policy and all Cybersecurity IRMs shall be evaluated a minimum of annually to ensure consistency with the IRS mission, functions, and associated laws, directives, regulations, and standards.

    Note:

    Implementation of the security controls defined within this IRM address the IRS Information Security Program requirements explicitly or implicitly.

10.8.1.2.1  (12-16-2006)
Roles and Responsibilities

  1. The IRS shall implement security roles in accordance with Federal laws and IT security guidelines (e.g., FISMA, NIST, OMB, etc.) that are appropriate for their specific operations and missions.

  2. Refer to IRM 10.8.2, , Information Technology (IT) Security, IT Security Roles and Responsibilities, for guidance on roles and responsibilities.

10.8.1.3  (12-16-2006)
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.

10.8.1.3.1  (11-25-2011)
Information Security Program Management

  1. The IRS shall develop, disseminate, review, and update annually an IRS-wide Information Security Program Management plan (IT Security Program Plan (ITSSP)) that: (NIST SP 800-53 PM-1)

    Note:

    The ITSSP can be found at http://mits.web.irs.gov/Cybersecurity/Divisions/Architecture_Implement/ITSI.htm

    1. Provides an overview of the requirements for the security program and a description of the security program management controls and common controls in place or planned for meeting those requirements;

    2. Provides sufficient information about the program management controls and common controls (including specification of parameters for any assignment and selection operations either explicitly or by reference) to enable an implementation that is unambiguously compliant with the intent of the plan and a determination of the risk to be incurred if the plan is implemented as intended; and

    3. Includes the following:

    • Purpose

    • Scope

    • Roles and Responsibilities

    • Management commitment

    • IRS coordination

    • Compliance

  2. The Information Security Program Management plan shall be revised to address organizational changes and problems identified during plan implementation or security control assessments. (NIST SP 800-53 PM-1)

  3. The IRS shall establish and implement an IRS IT security review and assistance program and conduct security reviews of information systems/operations. (TD P 85-01 P-SOC&A.1)

  4. Copies of approved draft and final IRS IT security policies and standards shall be provided to the Department of the Treasury. (TD P 85-01 P-SOC&A.2)

  5. The IRS shall assist and provide requested materials to the Treasury ACIO for Cyber Security (ACIOCS) as it conducts activities in support of its oversight and central reporting role. (TD P 85-01 P-SOC&A.3)

10.8.1.3.1.1  (11-25-2011)
Senior Agency Information Security Officer (SAISO)/Chief Information Security Officer (CISO)

  1. The IRS shall appoint a senior information security officer with the mission and resources to coordinate, develop, implement, and maintain an organization-wide information security program. (NIST SP 800-53 PM-2)

    1. Refer to IRM 10.8.2, for additional guidance.

10.8.1.3.1.2  (11-25-2011)
Information Security Resources

  1. The IRS shall: (NIST SP 800-53 PM-3)

    1. Ensure that each capital planning and investment request includes the resources needed to implement the information security program and documents all exceptions to this requirement;

    2. Employ a business case (e.g., Exhibit 300, Exhibit 53) to record the resources required; and

    3. Ensure that information security resources are available for expenditure as planned.

    Note:

    An Investment Review Board (or similar group) may be designated and empowered to manage and provide oversight for the information security-related aspects of the capital planning and investment control process. Business cases for IT investments are covered in Exhibit 300 and Exhibit 53 of OMB Circular A-11.

10.8.1.3.1.3  (11-25-2011)
Plan of Acton and Milestones (POA&M) Process

  1. The IRS shall develop, implement, and manage a process for ensuring that plans of action and milestones (POA&M) for the security program and the associated IRS information systems are maintained and document the remedial information security actions to mitigate risk to organizational operations and assets, individuals, other organizations, and the Nation. (NIST SP 800-53 PM-4; TD P 85-01 P-POA&M.1)

    Note:

    POA&Ms are a key document in the security authorization package and are subject to federal reporting requirements established by the Office of Management and Budget (OMB). POA&Ms updates are based on the findings from security control assessments, security impact analyses, and continuous monitoring activities. OMB FISMA reporting guidance contains instructions regarding organizational plans of action and milestones.

10.8.1.3.1.4  (11-25-2011)
Information System Inventory

  1. The IRS shall develop and maintain a comprehensive inventory of information systems and relevant security information for those systems. (NIST SP 800-53 PM-5 & TD P 85-01 P-INV.1)

    Note:

    This control addresses the inventory requirements in FISMA. OMB provides guidance on developing information systems inventories and associated reporting requirements.

  2. The inventory shall, at a minimum, contain information as shall be prescribed by the Department of the Treasury in supplemental guidance. (TD P 85-01 P-INV.2)

  3. The IRS shall provide the Department of the Treasury with periodic inventory updates to the Treasury-wide inventory on the Treasury-established schedule. (TD P 85-01 P-INV.3)

10.8.1.3.1.5  (11-25-2011)
Information Security Measures of Performance

  1. The IRS shall develop, define, monitor, and report on the results of information security measures of performance, which are the outcome-based metrics to measure/evaluate the effectiveness or efficiency of the information security program and the security controls employed in support of the program. (NIST SP 800-53 PM-6 & P-MS.1)

  2. The IRS shall report on FISMA and other related metrics (e.g., Critical Infrastructure Protection [CIP]) to the Department of the Treasury periodically as may be required in supplemental guidance. (TD P 85-01 P-MS.2)

  3. As the Department of the Treasury builds out its Security Information Management capability, the IRS shall provide security-related situational awareness data feeds to the Department of the Treasury as required in supplemental guidance to support a Treasury-wide Security Information Management capability. (TD P 85-01 P-MS.3)

10.8.1.3.1.6  (11-25-2011)
Enterprise Architecture

  1. The IRS shall develop an enterprise architecture with consideration for information security and the resulting risk to organizational operations, organizational assets, individuals, other organizations, and the Nation. (NIST SP 800-53 PM-7)

  2. The IRS shall document the security enterprise architecture following OMB Circular A-130, Transmittal Memorandum #4, Management of Federal Information Resources (November 28, 2000). (TD P 85-01 P-SEA.1)

  3. The IRS shall ensure security is fully integrated into their architecture framework and the security architecture is based on the latest Trust Model in the Treasury Enterprise Architecture Framework, as well as the taxonomy of the latest Federal Enterprise Architecture Framework. (TD P 85-01 P-SEA.2)

  4. The IRS shall review and update the security enterprise architecture data based on the enterprise architecture timeframes. (TD P 85-01 P-SEA.3)

  5. For additional guidance see: (TD P 85-01 P-SEA.3)

    1. The Office of Management and Budget’s Federal Enterprise Architecture web site; and

    2. NIST Special Publication (SP) 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories.

  6. The IRS’s HSPD-12 transition plan shall align with the government-wide architecture as described in the Federal CIO Council’s “Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance” (available at www.idmanagement.gov).

10.8.1.3.1.7  (11-25-2011)
Critical Infrastructure Plan

  1. The IRS shall address information security issues in the development, documentation, and updating of a critical infrastructure and key resources protection plan. (NIST SP 800-53 PM-8)

    1. The critical infrastructure and key resources protection plan shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  2. Cyber critical infrastructure protection (CIP) (IT assets) shall be included in the IT security program. (TD P 85-01 P-CIP.1)

  3. IT assets designated as "critical" under HSPD-7 shall be protected at a FIPS 199 impact level of HIGH. (TD P 85-01 P-CIP.2)

    1. When a system not already categorized as high is newly designated as a critical asset, a POA&M shall be created.

  4. For CIP assets, the IRS shall develop, disseminate, and periodically review and update a Business Impact Analysis that provides an analysis of how the loss or degradation of each asset would impact the organization’s business functions and determines how long it would take before nationally critical operations are affected. Bureaus shall analyze the consequences of this degradation and establish the necessary recovery time frames. (TD P 85-01 P-CIP.3)

    1. A maximum recovery time objective (RTO) shall be established for the critical asset that specifies when the full functions of the system will be back online before major impacts are felt.

    2. The RTO for the CIP system should be consistent with the time to impact on national security, homeland security, economic stability, and health and welfare of the American people.

    3. See the Cybersecurity, Security Risk Management, Enterprise FISMA Compliance Organization for additional information.

  5. For CIP assets, the IRS shall review, update, and maintain the list of Treasury-designated nationally critical assets on an annual basis. (TD P 85-01 P-CIP.4)

    1. Include identifying changes to system designations or functions that may impact the asset’s status as nationally critical and identifying new, fully deployed systems that should receive evaluation for consideration as nationally critical.

    2. If there are no CIP assets, the IRS shall provide to the ACIOCS, on an annual basis, an assessment of whether any of their physical or cyber assets are potential CIP candidates.

  6. For CIP assets, the IRS shall plan interdependency analyses of all designated CIP systems within one year of being officially designated a Treasury critical asset, and complete the analyses within two years of Critical Infrastructure/Key Resource (CI/KR) designation. (TD P 85-01 P-CIP.5)

    1. Interdependency analyses shall be updated at least every three (3) years or whenever there has been a major change to the CI/KR or its environment that impacts the value chain. (TD P 85-01 P-CIP.6)

    2. Results and reviews of interdependency analyses shall be transmitted to the ACIOCS for review.

10.8.1.3.1.8  (11-25-2011)
Risk Management

  1. The IRS shall: (NIST SP 800-53 PM-9)

    1. Develop a comprehensive strategy to manage risk to organizational operations and assets, individuals, other organizations, and the Nation associated with the operation and use of information systems; and

    2. Implement the risk management strategy consistently across the organization.

  2. The risk management strategy shall include, but not be limited to the following: (NIST SP 800-53 PM-9)

    1. An unambiguous expression of the risk tolerance for the organization;

    2. Acceptable risk assessment methodologies;

    3. Risk mitigation strategies;

    4. A process for consistently evaluating risk across the organization with respect to the organization’s risk tolerance; and

    5. Approaches for monitoring risk over time.

10.8.1.3.1.9  (11-25-2011)
Security Authorization Process

  1. The IRS shall: (NIST SP 800-53 PM-10)

    1. Manage (i.e., documents, tracks, and reports) the security state of organizational information systems through security authorization processes;

    2. Designate individuals to fulfill specific roles and responsibilities within the organizational risk management process; and

    3. Fully integrate the security authorization processes into an organization-wide risk management program.

    Note:

    The security authorization process for information systems requires the implementation of the Risk Management Framework and the employment of associated security standards and guidelines. Specific roles within the risk management process include an Authorizing Official (AO) for each organizational information system.

10.8.1.3.1.10  (11-25-2011)
Mission/Business Process Definition

  1. As part of program management, the IRS shall: (NIST SP 800-53 PM-11)

    1. Define mission/business processes with consideration for information security and the resulting risk to organizational operations, organizational assets, individuals, other organizations, and the Nation; and

    2. Determine information protection needs arising from the defined mission/business processes and revises the processes as necessary, until an achievable set of protection needs is obtained.

    Note:

    Information protection needs are technology-independent, required capabilities to counter threats to organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality, integrity, or availability). Information protection needs are derived from the mission/business needs defined by the organization, the mission/business processes selected to meet the stated needs, and the organizational risk management strategy. Information protection needs determine the required security controls for the organization and the associated information systems supporting the mission/business processes. Inherent in defining an organization’s information protection needs is an understanding of the level of adverse impact that could result if a compromise of information occurs. The security categorization process is used to make such potential impact determinations. Mission/business process definitions and associated information protection requirements are documented by the organization in accordance with organizational policy and procedure.

10.8.1.3.2  (11-25-2011)
Risk Assessment

  1. The IRS shall develop, disseminate, review, and update annually a formal, documented Risk Assessment Policy that addresses the following: (NIST SP 800-53 RA-1)

    • Purpose

    • Scope

    • Roles and Responsibilities

    • Management commitment

    • IRS coordination

    • Compliance

  2. The IRS shall develop, disseminate, review, and update annually procedures to facilitate the implementation of the Risk Assessment Policy and associated risk assessment controls. (NIST SP 800-53 RA-1)

    1. The Risk Assessment Policy and procedures shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  3. The IRS shall: (NIST SP 800-53 RA-3)

    1. Conduct an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of an information system and the information it processes, stores, or transmits;

    2. Document risk assessment results in system security plans and risk assessment plans;

    3. Review risk assessment results at least annually; and

    4. Update risk assessments at least every three (3) years or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system.

    Note:

    Examples of significant changes to an IRS information system that should have a risk assessment updated include, but are not limited to: (i) Installation of a new or upgraded operating system, middleware component, or application; (ii) Modifications to system ports, protocols, or services; (iii) Installation of a new or upgraded hardware platform or firmware component; or (iv) Modifications to cryptographic modules or services.

  4. Cybersecurity shall establish pass/fail criteria mapped to policy checker tool compliance levels, based on an assessment of risk to the IRS infrastructure. a. Pass/fail criteria shall be reviewed and updated at least annually.

  5. Refer to NIST SP 800-30, Risk Management Guide for Information Technology Systems, for additional guidance on risk assessments.

10.8.1.3.2.1  (11-25-2011)
Security Categorization

  1. The IRS shall: (NIST SP 800-53 RA-2)

    1. Categorize information and information systems in accordance with FIPS 199 and other applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;

    2. Document the security categorization results (including supporting rationale) in the security plan for the information system; and

    3. Ensure the security categorization decision is reviewed and approved by the AO or designated representative.

    Note:

    Security categorization describes the potential adverse impacts to IRS operations, assets, and individuals should the information and information system be compromised through a loss of confidentiality, integrity, or availability. The IRS conducts the security categorization process as an IRS-wide activity with the involvement of the chief information officer, senior information security officer, information system owner, mission owners, and information owners/stewards. The IRS also considers potential adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives, potential national-level adverse impacts in categorizing the information system. The security categorization process facilitates the creation of an inventory of information assets, and in conjunction with configuration management controls of this IRM, a mapping to the information system components where the information is processed, stored, and transmitted.

  2. Sensitivity in an IT environment shall consist of the system, data, applications, and type of user.

  3. All systems and applications shall require some level of protection for CIA, which is determined by an evaluation of the sensitivity and criticality of the information processed, the relationship of the system to the organization's mission, and the economic value of the system components.

  4. Information and information systems shall be considered sensitive if one or more of the following security objectives have been assigned a FIPS 199 impact value of moderate or higher.

    1. Confidentiality - The information and/or information system requires protection from unauthorized disclosure and access. A requirement that private or confidential information shall not be disclosed to unauthorized individuals is an example of confidentiality.

    2. Integrity - The information and/or information system shall be protected from unauthorized modification or destruction of information. The two facets of integrity are data integrity and system integrity. Data integrity ensures that information and programs are changed only in a specified and authorized manner. System integrity ensures that a system performs its intended function in an unimpaired manner, free from deliberate or inadvertent unauthorized manipulation of the system and its data.

    3. Availability - The information and/or information system shall be available on a timely basis to meet mission requirements or to avoid substantial losses. Availability requirements ensure that information systems work promptly and service is not denied to authorized users.

10.8.1.3.2.1.1  (11-25-2011)
Sensitive But Unclassified (SBU) Information

  1. Sensitive But Unclassified (SBU) information shall be defined as any information that requires protection due to the risk and magnitude of loss or harm to the IRS or the privacy to which individuals are entitled under 5 United States Code (U.S.C.) Section (§) 552a (the Privacy Act), which could result from inadvertent or deliberate disclosure, alteration, or destruction.

  2. The IRS processes SBU information which includes tax, financial, law enforcement, proprietary, life and mission critical, personal, and information relating to the privacy of U.S. citizens. SBU data shall be categorized in one or more of the following groups:

    1. Employee Information - All employee information covered by the Privacy Act. Examples include personnel, payroll, and evaluation data.

    2. Sensitive Law Enforcement Information - Grand jury, informant, and undercover operations information.

    3. Other Protected Information - All information covered by the Trade Secrets Act, the Procurement Integrity Act, and similar statues. Examples include information considered procurement sensitive, information marked Limited Official Use (LOU), and information marked Official Use Only (OUO).

    4. Taxpayer Information - All taxpayer-related information covered by § 6103 of the Internal Revenue Code (IRC), 26 U.S.C. § 6103.

    5. Personally Identifiable Information (PII) - All taxpayer information or any combination of information that can be used to uniquely identify, contact, or locate a person.

  3. SBU information shall include, but is not limited to, the following:

    1. Information which if improperly used or disclosed could adversely affect the ability of the agency to accomplish its mission;

    2. Proprietary data (business information that does not belong to the IRS);

    3. Records about individuals requiring protection under the Privacy Act;

    4. Information unreleaseable under the Freedom of Information Act (FOIA);

    5. Information which if modified, destroyed or disclosed in an unauthorized manner could cause: loss of life, loss of property or funds by unlawful means, violation of personal privacy or civil rights, gaining of an unfair procurement advantage by contractors bidding on government contracts, or disclosure of proprietary information entrusted to the Government;

    6. Personal information, including employment information such as job applications, disciplinary actions, performance appraisals, drug tests, and health exams;

    7. Tax return information;

    8. Security information containing details of serious weaknesses and vulnerabilities associated with specific systems and facilities;

    9. Law enforcement information;

    10. Procurement sensitive data, such as contract proposals;

    11. Documents and reports that have been marked as OUO or LOU;

    12. All forms of live data; and

    13. IP Addresses.

10.8.1.3.2.1.2  (11-25-2011)
Controlled Unclassified Information (CUI)

  1. A Presidential memorandum was released regarding the designation and sharing of Controlled Unclassified Information. Within the memorandum, it:

    • Adopts, defines, and institutes "Controlled Unclassified Information" (CUI) as the single categorical designation for all information referred to as "Sensitive But Unclassified" (SBU) in the Information Sharing Environment (ISE);

    • Establishes a corresponding new CUI Framework for designating, marking, safeguarding, and disseminating information designated as CUI; and

    • Designates the National Archives and Records Administration (NARA) as the Executive Agent, to oversee and implement the new CUI Framework.

  2. As NARA and Department of Treasury release implementation guidance, ACIO Cybersecurity shall be responsible for program planning and coordination in order to meet the White House Memorandum requirement for implementation of the CUI Framework.

10.8.1.3.2.1.3  (11-25-2011)
Personally Identifiable Information (PII)

  1. PII is a specific type of sensitive and SBU information. PII shall include the personal information of taxpayers, and the personal information of employees, contractors, applicants, and visitors to the IRS. Examples of PII include, but are not limited to:

    1. Name;

    2. Home address;

    3. Social Security number;

    4. Date of birth;

    5. Home telephone number;

    6. Biometric data (e.g., height, weight, eye color, fingerprints, etc.); and

    7. Other numbers or information that alone or in combination with other data can identify an individual.

  2. All IRS employees shall be responsible for protecting any PII that they may have in their possession, whether the PII is in paper form or in IRS computer equipment and computer systems.

  3. IRS sensitive information and PII shall only be released to those individuals having a "need to know" for access to the information, in the performance of their duties.

  4. Sensitive information and PII that is stored or transmitted by computer equipment (such as laptops and memory storage devices) shall be encrypted unless the CISO has made an Enterprise Risk Based Decision (RBD) to allow an exception.

  5. SBU and PII data such as user accounts and passwords shall not be posted to internal or external IRS websites.

  6. All requests for live data shall be processed in accordance with the SBU requirements stated in this IRM and IRM 10.8.8, Information Technology (IT) Security, Live Data (LD) Protection.

  7. Any information placed into an individual’s calendar (e.g., Outlook, etc.) containing SBU or PII data shall be encrypted.

    1. See the Electronic Mail (E-Mail) Security and System and Communications Protection sections of this IRM for additional guidance.

10.8.1.3.2.2  (11-25-2011)
Vulnerability Analysis and Assessment

  1. The IRS shall employ vulnerability scanning tools and techniques that promote interoperability amongst tools and automate parts of the vulnerability management process by using standards for: (NIST SP 800-53 RA-5)

    1. Enumerating platforms, software flaws, and improper configurations;

    2. Formatting and making transparent, checklists and test procedures; and

    3. Measuring vulnerability impact.

  2. The IRS shall scan for vulnerabilities in an information system and hosted applications: (NIST SP 800-53 RA-5)

    1. At a minimum of monthly for all systems; and

    2. When new vulnerabilities potentially affecting the system/applications are identified and reported.

  3. The IRS shall: (NIST SP 800-53 RA-5)

    1. Analyze vulnerability scan reports and results from security control assessments;

    2. Remediate legitimate vulnerabilities in accordance with an assessment of risk; and

    3. Share information obtained from the vulnerability scanning process and security control assessments with designated personnel throughout the IRS to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).

      Note:

      In the context of this requirement, the term legitimate allows for possible false positives in a scan report, and vulnerabilities that have been determined to be an acceptable risk due to the potential negative affect that would be incurred if remediated.

  4. The IRS shall employ vulnerability scanning tools that include the capability to readily update the list of information system vulnerabilities scanned. (NIST SP 800-53 RA-5 CE1)

  5. For IRS information systems categorized as FIPS 199 HIGH, the IRS shall update the list of information system vulnerabilities scanned at least semi-annually or when new vulnerabilities are identified and reported. (NIST SP 800-53 RA-5 CE2)

  6. For IRS information systems categorized as FIPS 199 HIGH, the IRS shall employ vulnerability scanning procedures that can demonstrate the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked). (NIST SP 800-53 RA-5 CE3)

  7. For IRS information systems categorized as FIPS 199 HIGH, the IRS shall attempt to discern what information about an information system is discoverable by adversaries. (NIST SP 800-53 RA-5 CE4)

  8. For IRS information systems categorized as FIPS 199 HIGH, the IRS shall include privileged access authorization to information system components for selected vulnerability scanning activities to facilitate more thorough scanning. (NIST SP 800-53 RA-5 CE5)

    Note:

    The privilege access is granted to the user/service account conducting the scan.

  9. The IRS shall employ automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities. (NIST SP 800-53 RA-5 CE6)

  10. The IRS shall employ automated mechanisms to detect the presence of unauthorized software on IRS information systems and notify designated IRS officials. (NIST SP 800-53 RA-5 CE7)

    Note:

    See minimum scanning requirements in this section and the Configuration Management section of this IRM for frequency of employing automated mechanisms.

  11. The IRS shall review historic audit logs to determine if a vulnerability identified in an information system has been previously exploited. (NIST SP 800-53 RA-5 CE8)

  12. Penetration testing (frequency, level, etc.) shall be based on a business need and authorization.

  13. When penetration testing is conducted, the IRS shall employ an independent penetration agent or penetration team to: (NIST SP 800-53 RA-5 CE9)

    1. Conduct a vulnerability analysis on IRS information systems; and

    2. Perform penetration testing on an information system based on the vulnerability analysis to determine the exploitability of identified vulnerabilities.

    Note:

    A standard method for penetration testing includes: (i) pre-test analysis based on full knowledge of the target information system; (ii) pre-test identification of potential vulnerabilities based on pre-test analysis; and (iii) testing designed to determine exploitability of identified vulnerabilities. Detailed rules of engagement are agreed upon by all parties before the commencement of any penetration testing scenario.

  14. Refer to the System and Information Integrity section of this IRM for additional information related to vulnerability scanning.

10.8.1.3.3  (11-25-2011)
Planning

  1. The IRS shall develop, disseminate, review, and update annually a formal, documented security Planning Policy that addresses the following: (NIST SP 800-53 PL-1)

    • Purpose

    • Scope

    • Roles and Responsibilities

    • Management commitment

    • IRS coordination

    • Compliance

  2. The IRS shall develop, disseminate, review and update formal, documented procedures to facilitate the implementation of the security planning policy and associated security planning controls. (NIST SP 800-53 PL-1)

    1. The Planning Policy and procedures shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  3. Business and Functional unit owners are required to develop and maintain additional operational documentation (e.g., action and implementation plans, SOP, etc.) necessary for implementing the requirements of this IRM.

10.8.1.3.3.1  (11-25-2011)
System Security Planning

  1. The IRS shall develop a security plan for an information system that, at a minimum: (NIST SP 800-53 PL-2)

    1. Is consistent with the IRS’s enterprise architecture;

    2. Explicitly defines the authorization boundary for the system;

    3. Describes the operational context of the information system in terms of missions and business processes;

    4. Provides the security categorization of the information system including supporting rationale;

    5. Describes the operational environment for the information system;

    6. Describes relationships with or connections to other information systems;

    7. Provides an overview of the security requirements for the system;

    8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation (e.g., Risk Based Decision (RBD) decisions; and

    9. Is reviewed and approved by the AO or designated representative prior to plan implementation.

  2. The IRS shall: (NIST SP 800-53 PL-2)

    1. Review a security plan for an information system at a minimum annually; and

    2. Update a plan a minimum of every three years or whenever there is a significant change to the system.

    Note:

    Examples of significant changes to an IRS information system include, but are not limited to: (i) Installation of a new or upgraded operating system, middleware component, or application; (ii) Modifications to system ports, protocols, or services; (iii) Installation of a new or upgraded hardware platform or firmware component; or (iv) Modifications to cryptographic modules or services.

  3. The IRS shall: (NIST SP 800-53 PL-2 CE1)

    1. Develop a security Concept of Operations (CONOPS) for IRS information systems containing, at a minimum:
      i. The purpose of the system;
      ii. A description of the system architecture;
      iii. The security authorization schedule; and
      iv. The security categorization and associated factors considered in determining the categorization.

    2. Review and update the CONOPS at a minimum, annually.

    Note:

    The security CONOPS may be included in the security plan for the information system.

  4. The IRS shall develop a functional architecture for information systems that identifies and maintains: (NIST SP 800-53 PL-2 CE2)

    Note:

    An architecture may be a document, plan, or other artifact.

    1. All external interfaces, the information being exchanged across the interfaces, and the protection mechanisms associated with each interface;

    2. User roles and the access privileges assigned to each role;

    3. Unique security requirements;

    4. Types of information processed, stored, or transmitted by the information system and any specific protection needs in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance; and

    5. Restoration priority of information or information system services.

    Note:

    Unique security requirements for an information system include, for example, encryption of key data elements at rest. Specific protection needs for an information system include, for example, the Privacy Act and Health Insurance Portability and Accountability Act (HIPAA), E-Government Act of 2002, and PII.

  5. Refer to NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems, for guidance on security planning.

    Note:

    Stakeholders with access to IRS intranet can sign up for automatic electronic notification of changes to all 10.8.x series IRMs on the IRM Numerical Index located on the media and electronic publishing website.

10.8.1.3.3.1.1  (11-25-2011)
Security Activity Planning

  1. The IRS shall plan and coordinate security-related activities affecting the information system before conducting such activities in order to reduce the impact on organizational operations (i.e., mission, functions, image, and reputation), organizational assets, and individuals. (NIST SP 800-53 PL-6)

    Note:

    Security-related activities include, for example, security assessments, audits, system hardware and software maintenance, and contingency plan testing/exercises. Organizational advance planning and coordination includes both emergency and non-emergency (i.e., planned or non-urgent, unplanned) situations.

10.8.1.3.3.2  (11-25-2011)
Rules of Behavior

  1. The IRS shall establish and make available to all information system users, the rules that describe their responsibilities and expected behavior with regard to information and information system usage. (NIST SP 800-53 PL-4)

  2. The rules of behavior shall address security, acceptable level of risk, and usage of IRS computing resources.

  3. The IRS shall include in the rules of behavior, explicit restrictions on the use of social networking sites, posting information on commercial web sites, and sharing information system account information. (NIST SP 800-53 PL-4, CE1)

  4. The IRS shall identify the penalties for behavior(s) that are not in compliance with the rules of behavior (e.g., job termination and/or criminal prosecution).

    Note:

    Refer to IRM 6.751.1 , Discipline and Disciplinary Actions: Policies, Responsibilities, Authorities, and Guidance, for further information.

  5. All users shall sign a statement indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to information and the information system. (NIST SP 800-53 PL-4)

  6. Any failure to comply with the Rules of Behavior shall be considered a security incident.

    1. If the incident is deemed willful, it shall be escalated to a security violation and is subject to disciplinary actions.

  7. Refer to NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems, for additional guidance on rules of behavior.

10.8.1.3.3.3  (11-25-2011)
Privacy

  1. The IRS shall protect taxpayer and employee privacy rights.

  2. The IRS shall consider the effects of its actions on the privacy of individuals and ensure that appropriate legal and technical safeguards are implemented.

  3. Privacy protection shall be an essential part of an information system’s life cycle and include the following controls:

    1. Procedures addressing the storage, retrieveability, accessibility, retention, and disposal of PII shall be established, maintained and enforced;

    2. A privacy impact assessment (PIA) shall be conducted for all IRS information systems in accordance with OMB policies (i.e., M-03-22, M-06-16); (NIST SP 800-53 PL-5)

    3. Procedures for the disclosure of an individual’s record upon that individual’s request shall be developed, maintained, enforced; and

    4. Security safeguards to protect against the unauthorized accumulation, use, and dissemination of SBU data shall be implemented.

  4. The disclosure of an individual’s data upon that individual’s request shall be referred to the Office of Governmental Liaison and Disclosure for adjudication and resolution.

  5. All PIAs shall be conducted and reviewed by the Privacy, Information Protection & Data Security (PIPDS) Office.

  6. PIPDS shall establish and manage privacy policies and the PIA processes and procedures. For all privacy-related guidance, see IRM 10.5.1, PIPDS Policy, Roles and Responsibilities:
    http://irm.web.irs.gov/link.asp?link=10.5.1

10.8.1.3.4  (11-25-2011)
System and Services Acquisition

  1. The IRS shall develop, review, and update annually a System and Services Acquisition Policy that incorporates information security considerations and addresses the following: (NIST SP 800-53 SA-1)

    1. Purpose

    2. Scope

    3. Roles and Responsibilities

    4. Management commitment

    5. IRS coordination

    6. Compliance

  2. The IRS shall develop procedures to facilitate the implementation of the System and Services Acquisition Policy and associated system and services acquisition controls. (NIST SP 800-53 SA-1)

    1. System and Services Acquisition policy and procedures shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  3. All acquisition of applications or services shall adhere to Federal laws, executive orders, directives, policies, regulations, standards, and guidance for foreign and domestic trade.

  4. IRS information system acquisition contracts shall include the following requirements and/or specifications, explicitly or by reference, based on an assessment of risk and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: (NIST SP 800-53 SA-4)

    1. Security functional requirements/specifications;

    2. Security-related documentation requirements; and

    3. Development and evaluation-related assurance requirements.

  5. Acquisition documents shall require vendors or contractors to provide information describing the functional properties of the security controls to be employed within the information system. (NIST SP 800-53 SA-4 CE1)

  6. Acquisition documents shall require vendors or contractors to provide information describing the design and implementation details of the security controls to be employed within the information system, information system components, or information system services (including functional interfaces among control components) in sufficient detail to permit analysis and testing of the controls. (NIST SP 800-53 SA-4 CE2)

  7. The IRS shall ensure that each information system component acquired is explicitly assigned to an information system and that the owner of the system acknowledges this assignment. (NIST SP 800-53 SA-4 CE4)

  8. The IRS shall develop, document, and enforce rules governing the installation of software by users. (NIST SP 800-53 SA-7)

  9. The IRS shall employ control and tracking measures to ensure: (NIST SP 800-53 SA-6)

    1. Software usage, installation restrictions, and documentation are in compliance with contract agreements and copyright laws;

    2. Software and documentation protected by quantity licenses are not copied and distributed beyond the authorized quantity;

    3. Copyrighted material is not distributed, displayed, or reproduced via peer-to-peer file share technology; and

    4. IRS information systems or networks are not used to download illegal and/or offensive content, or for activities otherwise prohibited in the Rules of Behavior.

    Note:

    IRS computer systems or networks, as well as those operated by contractors on the IRS’ behalf, must not be used for the downloading of illegal, unauthorized, and/or copyrighted content. Specifically this includes the creation, download, viewing, storage, copying, or transmission of materials related to gambling, illegal weapons/weapons of mass destruction, terrorist activities, and any other activities otherwise prohibited in the Rules of Behavior.

  10. The IRS shall: (NIST SP 800-53 SA-6 CE1)

    1. Prohibit the use of binary or machine executable code in an information system from the public domain sources or from sources with limited or no warranty, and without accompanying source code;

    2. Provide exceptions to the source code requirement for compelling mission/operational requirements, when no alternative solutions are available and with the express written consent of the authorizing official; and

    3. Ensure only legal and licensed (including open source, shareware, and freeware licenses, etc.) software (including operating systems, databases, applications, etc.) approved by MITS is used or installed on the IRS systems and networks.

  11. All new systems under development or being acquired shall be enabled to use Personal Identity Verification (PIV) credentials, in accordance with NIST guidelines, prior to being made operational. (OMB M-11-11).

  12. Procurements for services and products involving facility or system access control must be in accordance with HSPD-12 policy and the Federal Acquisition Regulation. (OMB M-11-11)

10.8.1.3.4.1  (11-25-2011)
Contractors and Outsourced Operations

  1. The IRS and respective AO shall ensure all acquisitions: (NIST SP 800-53 SA-9)

    1. Provide safeguards for information security, personnel security, and physical security.

    2. Employ security controls in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and established service-level agreements;

    3. Define and document government oversight, user roles, and responsibilities with regard to external information system services;

    4. Monitor external service provider compliance with security controls in accordance with IRS and Department of Treasury security policies.

  2. The IRS shall: (NIST SP 800-53 SA-9 CE1)

    1. Conduct an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and

    2. Ensure that the acquisition or outsourcing of dedicated information security services is approved by the AO or authorized senior official.

  3. The IRS shall ensure contract vehicles and statements of work (SOW) identify and document the following security requirements for contractors, outsourced services, and operational requirements: (NIST SP 800-53 SA-9)

    1. Explicit procedures, where needed or as necessary;

    2. Contractor and/or outsourced operations capabilities required to meet security compliance requirements;

    3. The information and resources specifically required for an external contractor to perform the services. Access to all other information and resources shall be prohibited;

    4. How IRS sensitive information is handled and protected at the contractor’s facility or site, to include any information stored, processed, or transmitted using the contractor’s computer systems;

    5. Requirements for background investigation and/or clearance and SATE for contractor activities or facilities;

    6. Facility physical security requirements;

    7. Upon the expiration of a contract, contractors certify IRS information has been sanitized from any contractor-owned systems used to process IRS information and return any IRS information technology (IT) resources provided to the contractor; and

    8. Annual security reviews of work performed at the contractor’s facilities to ensure security requirements have been incorporated, and are in compliance.

  4. The IRS shall require that information system developers implement a configuration management process that: (NIST SP 800-53 SA-10)

    1. Manages and controls changes to the system;

    2. Implements only IRS-approved changes;

    3. Documents all approved changes; and

    4. Tracks security flaws.

  5. The IRS shall require information system developers to provide an integrity check of its software to facilitate IRS’s verification of software integrity after delivery. (NIST SP 800-53 SA-10 CE1)

  6. The IRS shall provide an alternative configuration management process with IRS personnel, in the absence of a dedicated developer configuration management team. (NIST SP 800-53 SA-10 CE2)

    Note:

    The configuration management process includes key organizational personnel responsible for reviewing and approving proposed changes to the information system, and personnel that conduct impact analyses prior to the implementation of any changes to the system.

  7. The IRS shall require that information system developers, in consultation with associated security personnel (including security engineers): (NIST SP 800-53 SA-11)

    1. Create and implement a security test and evaluation plan;

    2. Implement a verifiable flaw remediation process to correct weaknesses and deficiencies identified during the security testing and evaluation process; and

    3. Document the results of the security testing/evaluation and flaw remediation processes.

  8. The IRS shall require that information system developers:

    1. Employ code analysis tools to examine software for common flaws and document the results. (NIST SP 800-53 SA-11 CE1)

    2. Perform a vulnerability analysis to document vulnerabilities, exploitation potential, and risk mitigations. (NIST SP 800-53 SA-11 CE2)

    3. Create a security test and evaluation plan and implement the plan under the witness of an independent verification and validation agent. (NIST SP 800-53 SA-11 CE3)

  9. The IRS shall include security requirements/specifications in system development acquisitions, to include (at a minimum) security requirements contained within this IRM and TD P 85-01, Treasury Information Technology Security Program. (TD P 85-01 P-AC&O.1)

  10. When an IRS-owned information system is operated by a contractor at the contractor’s facility, the IRS shall: (TD P 85-01 P-AC&O.2)

    1. Include specific language in the contract to ensure IRS’ IT security policies for all personnel requiring access to the system are applied;

    2. Require self-assessments to be conducted to show compliance with IRS IT security policies; and

    3. Ensure the contract provides for unannounced, on-site inspections of the contractor facilities by the IRS to ensure an adequate level of security is being maintained by the contractor.

  11. When forming agreements with extra-IRS entities for operation and maintenance of IRS-owned information systems, the IRS shall include in the agreement, language addressing responsibility for security authorization activities and access to security authorization documentation. (TD P 85–01 S-EC.23)

  12. Refer to IRM 11.3.24 , Disclosures to Contractors, for further information.

10.8.1.3.4.2  (11-25-2011)
Capital Planning and Investment

  1. Business or functional owners shall include the information system security requirements for an information system as part of the business case planning, programming and budgeting documentation. (NIST SP 800-53 SA-2)

  2. The IRS shall determine, document, and allocate the appropriate resources required to protect an information system as part of its capital planning and investment control process. (NIST SP 800-53 SA-2)

  3. The IRS shall establish a line item for Information Security in programming and budgeting documentation. (NIST SP 800-53 SA-2)

  4. Program Officials shall ensure:

    1. Per FISMA requirements, IT security requirements are included in capital planning and investment business cases by the owner of the business case; (TD P 85-01 P-CPIC.1)

    2. IT security requirements are adequately defined and funded in accordance with OMB Circular A-11, before Treasury and IRS Investment Review Boards approve any capital investments; (TD P 85-01 P-CPIC.2)

    3. Description/funding figures are updated as they change and enter these in the IRS’s Capital Planning Investment Control (CPIC) database; and (TD P 85-01 P-CPIC.3)

    4. Selected secure configuration baselines are incorporated into the IRS CPIC processes. (TD P 85-01 P-CPIC.4)

10.8.1.3.4.3  (11-25-2011)
System Development Life Cycle (SDLC)

  1. The IRS shall manage information systems using a SDLC methodology that includes information security considerations. (NIST SP 800-53 SA-3)

    1. Security shall be integrated into the IRS-approved SDLC.
      i. SDLC is a term which denotes any IRS-approved system development life cycle such as the Enterprise Life Cycle (ELC).

    2. ELC milestone requirements shall contain the security requirements and policies identified within this IRM and subsequent IRM 10.8.x series.
      i. Security requirements shall be incorporated into the system requirements
      ii. Security requirements shall be tracked, updated, and validated throughout a system’s life cycle.

    3. For additional ELC guidance, see:
      http://elc.nc.no.irs.gov/.

  2. The IRS shall define and document information security roles and responsibilities throughout the system development life cycle. (NIST SP 800-53 SA-3)

    1. Individuals, with information security roles and responsibilities, shall be identified.

  3. Information system security engineering principles shall be applied in the specification, design, development, implementation and modification of an information system. (NIST SP 800-53 SA-8)

  4. All phases of the procurement cycle (e.g., planning, solicitation, source selection, contract administration, and closeout) for an information system shall take into account and incorporate information security. (NIST SP 800-53 SA-3)

10.8.1.3.4.4  (11-25-2011)
Documentation

  1. Administrator documentation for IRS information systems shall be obtained, protected, and made available (based on sensitivity) to authorized personnel that describes: (NIST SP 800-53 SA-5)

    1. Secure configuration, installation, and operation of the information system;

    2. Effective use and maintenance of security features/functions; and

    3. Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions.

  2. User documentation for IRS information systems shall be obtained, protected, and made available (based on sensitivity) to authorized personnel that describes: (NIST SP 800-53 AC-5)

    1. User-accessible security features/functions and how to effectively use those security features/functions;

    2. Methods for user interaction with the information system, which enables individuals to use the system in a more secure manner; and

    3. User responsibilities in maintaining the security of the information and information system.

  3. Attempts to obtain information system documentation shall be documented when it is either unavailable or non-existent. (NIST SP 800-53 SA-5)

    Note:

    In the absence of documentation for an information system, the AO and system owner can make a RBD based on industry best practices for implementing technologies.

  4. Security requirements and specifications based on level of risk shall be included in information system contracts of acquisition and solicitation documents, which shall include requirements such as:

    1. Required security capabilities

    2. Development processes

    3. Test and evaluation procedures

    4. Required documentation

  5. The IRS shall obtain, protect, and make available (based on sensitivity) to authorized personnel, vendor or contractor provided documentation with sufficient detail to permit analysis and testing, and that describes the following:

    1. The functional properties of the security controls employed within the information system; (NIST SP 800-53 SA-5 CE1)

    2. The security-relevant external interfaces to the information system; (NIST SP 800-53 SA-5 CE2)

    3. The high-level design of the information system in terms of subsystems and implementation details of the security controls employed within the system; and (NIST SP 800-53 SA-5 CE3)

    4. The low-level design of the information system in terms of modules and implementation details of the security controls employed within the system. (NIST SP 800-53 SA-5 CE4)

  6. The source code shall be obtained, protected, and made available (based on sensitivity) to authorized personnel, so as to permit analysis and testing. (NIST SP 800-53 SA-5 CE5)

  7. The IRS shall ensure documentation is developed and maintained detailing the IT hardware and software configuration, to include all security configurations and countermeasures protecting it.

  8. The IRS shall require in acquisition documents, that information system components are delivered in a secure, documented configuration, and that the secure configuration is the default configuration for any software reinstalls or upgrades. (NIST SP 800-53 SA-4 CE5)

10.8.1.3.4.5  (11-25-2011)
Product Assurance

  1. Information Assurance (IA) shall be considered a requirement for all systems used to enter, process, store, display, or transmit sensitive information. IA provides for the availability of systems; ensures the integrity and confidentiality of information; and the authentication/non-repudiation of parties in electronic transactions.

  2. The IRS shall: (NIST SP 800-53 SA-4 CE7)

    1. Limit the acquisition and implementation of Commercial off-the-Shelf (COTS) and/or Government off-the-Shelf (GOTS) IA and IA-enabled products with security capabilities to products that have been evaluated against a validated U.S. Government Protection Profile for a specific technology type, if such a type exists, by an accredited commercial or NIST laboratory, such as:
      i. International Common Criteria for Information Security Technology Evaluation Mutual Recognition Agreement;
      ii. National Information Assurance Partnership (NIAP) Evaluation and Validation Scheme; or
      iii. NIST Cryptographic Module validation program.

    2. Require FIPS-validated cryptographic modules be used, if no U.S. Government Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy.

      Note:

      The IRS requires FIPS 140-2 validation.

  3. The IRS shall: (NIST SP 800-53 SA-4 CE6)

    1. Employ only GOTS or COTS IA and IA-enabled information technology products that compose an National Security Agency (NSA) approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and

    2. Ensure these products have been evaluated and/or validated by the NSA or in accordance with NSA-approved procedures.

  4. The IRS shall require software vendors/manufacturers to demonstrate their software development processes employ state-of-the-practice software and security engineering methods, quality control processes, and validation techniques to minimize flawed or malformed software. (NIST SP 800-53 SA-4 CE3)

    1. Methods for demonstrating include, but are not limited to:
      i. Capability Maturity Model Integration (CMMI) compliance levels
      ii. Software Assurance Maturity Model (SAMM)
      iii. Software Engineering Institutes (SEI) Software Process Improvement (SPI) Models
      iv. Six Sigma

  5. Planning, acquisition, and implementation of new products shall be made in accordance with mandatory Security Content Automation Protocol (SCAP) and Federal Desktop Core Configuration (FDCC) standards as compliant products become available.

    1. SCAP compatible tools will be used when monitoring security configurations of Windows Operating Systems (OS) (e.g., Vista, Windows XP, Windows 7). (TD P 85-01 S-CVM.6)

    2. Refer to NIST SP 800-126, The Technical Specifications for the Security Content Automation Protocol (SCAP) and NIST SP 800-117, Guide to Adopting and Using the Security Content Automation Protocol (SCAP) for further guidance.

  6. The IRS shall employ measures to protect against supply chain threats through a comprehensive, defense-in-breadth information security strategy, by: (NIST SP 800-53 SA-12)

    1. Purchasing all anticipated information system components and spares in the initial acquisition. (NIST SP 800-53 SA-12 CE1)

    2. Ensuring that during the information system lifecycle, trusted cutouts for purchasing contract services, acquisitions, or logistical activities are used. (NIST SP 800-53 SA-12 CE2)

    3. Conducting a due diligence review of suppliers prior to entering into contractual agreements to acquire information system hardware, software, firmware, or services. (NIST SP 800-53 SA-12 CE3)

    4. Using trusted shipping and warehousing for information systems, information system components, and information technology products. (NIST SP 800-53 SA-12 CE4)

    5. Using a diverse set of suppliers for information systems, information system components, information technology products, and information system services. (NIST SP 800-53 SA-12 CE5)

    6. Using standard configurations for information systems, information system components, and information technology products. (NIST SP 800-53 SA-12 CE6)

    7. Minimizing the time between purchase decisions and delivery of information systems, information system components, and information technology products. (NIST SP 800-53 SA-12 CE7)

    8. Performing independent analysis and penetration testing against delivered information systems, information system components, and information technology products. (NIST SP 800-53 SA-12 CE8)

  7. The IRS shall ensure information systems meet a level of trustworthiness by meeting or providing the core IA principles of confidentiality, integrity, and availability. (NIST SP 800-53 SA-13)

10.8.1.3.5  (11-25-2011)
Security Assessment and Authorization

  1. The IRS shall develop, disseminate, review, and update annually a formal, documented, Security Assessment and Authorization Policy that addresses the following: (NIST SP 800-53 CA-1)

    • Purpose;

    • Scope;

    • Roles and responsibilities;

    • Management commitment;

    • Coordination among organizational entities; and

    • Compliance

  2. The IRS shall document procedures to facilitate the implementation of the Security Assessment and Authorization Policy and associated Security Assessment and Authorization controls. (NIST SP 800-53 CA-1)

    1. The Security Assessment and Authorization Policy and procedures shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

  3. The IRS shall use one of the following Security Assessment & Authorization processes: (NIST SP 800-53 CA-1)

    1. National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 1000, National Information Assurance Certification and Accreditation (C&A) Process (NIACAP) for IRS information systems handling national-security information; or

    2. NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, for all other IRS information systems.

  4. The IRS Security Assessment and Authorization process shall follow a Risk Management Framework methodology, as outlined in NIST SP 800-37, which provides a disciplined and structured process that integrates information security and risk management activities into the system development life cycle.

10.8.1.3.5.1  (11-25-2011)
Security Assessments

  1. The IRS shall develop and employ a security assessment plan that describes the scope of the assessment, including: (NIST SP 800-53 CA-2)

    1. Security controls and control enhancements under assessment;

    2. Assessment procedures to be used to determine security control effectiveness; and

    3. Assessment environment, assessment team, and assessment roles and responsibilities.

  2. The IRS shall assess the security controls in an IRS information system at a minimum on an annual basis to determine the extent to which the management, operational, and technical controls are: (NIST SP 800-53 CA-2)

    1. Implemented correctly;

    2. Operating as intended;

    3. Meeting the security requirements of the system; and

    4. Producing the desired outcome.

  3. Weaknesses found during security assessments shall be documented in a POA&M to include planned, implemented, and evaluated remedial actions to correct any deficiencies. (NIST SP 800-53 CA-5)

    Note:

    Risk-based Decisions (RBD) for weaknesses and system vulnerabilities do not need to be tracked in a POA&M as long as the RBD is documented in the Security Assessment and Authorization (SA&A) documentation (e.g., System Security Plan) for the information system.

  4. The results of all security assessments shall be documented in a security assessment report. (CA-2)

  5. The IRS shall conduct its annual security assessments in accordance with NIST guidelines (e.g., NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, NIST SP 800-53, Recommended Security Controls for Federal Information Systems, NIST 800-53A, Guide for Assessing the Security Controls in Federal Information Systems, or comparable). (NIST SP 800-53 CA-2)

  6. The security controls of an IRS information system shall be assessed as part of: (NIST SP 800-53 CA-2)

    1. Security authorization or reauthorization (accreditation or reaccreditation);

    2. Meeting the Federal Information Security Management Act (FISMA) requirement for annual assessments;

    3. Continuous monitoring; and

    4. Testing/evaluation of an IRS information system during the system development life cycle process.

  7. On FIPS 199 HIGH and MODERATE systems, the assessment of security controls for the purposes of Security Authorization (i.e., Certification) shall be conducted by an independent Security Control Assessor (i.e., Certification Agent) or Security Control Assessor team. (NIST SP 800-53 CA-2 CE1)

  8. The IRS, for FIPS 199 HIGH systems, shall include announced assessments as part of its security control assessments on an annual basis. These assessments may consist of, but are not limited to the following assessment types: (NIST SP 800-53 CA-2 CE2)

    1. In-depth monitoring;

    2. Malicious user testing;

    3. Penetration testing; and

    4. Red team exercises.

      Note:

      Red team exercises are conducted as a simulated adversarial attempt to compromise an organization's missions and/or business processes to provide a comprehensive assessment of the security capability of the information system and organization. While penetration testing may be laboratory-based testing, red team exercises are intended to be more comprehensive in nature and reflect real-world conditions.

  9. The IRS shall provide the results of security assessments and audits, in writing, to the AO or the Authorizing Official designated representative for review and possibly further action. (NIST SP 800-53 CA-2)

    1. Security assessment and audit results shall be made available to appropriate authorized personnel.

10.8.1.3.5.2  (11-25-2011)
Plans of Action and Milestones (POA&M)

  1. The IRS shall: (NIST SP 800-53 CA-5)

    1. Develop a Plan of Action and Milestones (POA&M) for IRS information systems to document the planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; and

    2. Update existing POA&Ms on an quarterly basis, at a minimum, based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities.

    Note:

    POA&Ms are a key document in the security authorization package and are subject to federal reporting requirements established by the OMB.

  2. The IRS shall employ automated mechanisms to help ensure that the plan of action and milestones for an IRS information system is accurate, up to date, and readily available. (NIST SP 800-53 CA-5 CE1)

  3. The IRS shall ensure that all new weaknesses are entered into appropriate POA&Ms within: (TD P 85-01 P-POA&M.11)

    1. 30 calendar days of identification for program-level weaknesses and those for information systems categorized as Federal Information Processing Standard (FIPS) 199 HIGH systems; and

    2. 60 calendar days for weaknesses for all other systems with a POA&M

  4. All POA&Ms shall be entered into the Treasury FISMA reporting tool (e.g., Trusted Agent FISMA [TAF]) within:

    1. 30 calendar days of identification for program-level weaknesses and for information systems categorized as FIPS 199 HIGH systems; and

    2. 60 calendar days for weaknesses for all other systems with a POA&M.

  5. The IRS shall use POA&Ms to track the status of resolutions of weaknesses and verify that each weakness is corrected before closing that item on a POA&M.

  6. The IRS shall document in POA&Ms, at a minimum, all IT security weaknesses warranting corrective actions that have been identified by: (TD P 85-01 P-POA&M.2)

    1. The Secretary of the Treasury and resulting in a material weakness in the Department’s Annual Performance and Accountability Report;

    2. An external audit or evaluation (e.g., the Government Accountability Office [GAO], the Office of the Inspector General, or the Treasury Inspector General for Tax Administration [TIGTA]);

    3. Treasury ACIO Cybersecurity compliance and assistance reviews;

    4. Internal IRS evaluations (e.g., policy, training programs, self-assessments, periodic security test and evaluation, or contingency plan testing); or

    5. Corrective actions necessary to achieve full compliance with Treasury Department policies and standards.

  7. The IRS shall ensure that the individual and/or office responsible for correcting each weakness is identified in the appropriate POA&M (TD P 85-01 P-POA&M.4)

  8. The IRS shall track all POA&Ms to completion. (TD P 85-01 P-POA&M.5)

  9. The IRS shall prioritize weaknesses in their POA&Ms in accordance with supplemental Treasury Department guidance (i.e., TD P 85-01 Volume I, Section 3.7, Policy for Maintaining Plans of Action and Milestones). (TD P 85-01 P-POA&M.6)

  10. The IRS shall submit quarterly POA&Ms to the office of the ACIO Cybersecurity per the requirements of OMB reporting guidelines. (TD P 85-01 P-POA&M.7)

  11. Refer to the IRS POA&M SOP for additional Guidance on the enterprise POA&M process.

10.8.1.3.5.3  (11-25-2011)
Authorization

  1. IRS information systems shall be re-authorized (i.e., re-accredited) whenever there is a significant change to the system, or every three (3) years, whichever occurs first. (CA-6)

    Note:

    Examples of significant changes to an IRS information system that should be reviewed for possible reaccreditation include, but are not limited to: (i) Installation of a new or upgraded operating system, middleware component, or application; (ii) Modifications to system ports, protocols, or services; (iii) Installation of a new or upgraded hardware platform or firmware component; or (iv) Modifications to cryptographic modules or services.

  2. The AO shall grant one of three types of security authorization decisions (i.e., accreditation), based on assessment of risk as outlined in the following paragraphs: (NIST SP 800-53 CA-6)

    1. ATO - Authorization to Operate shall be granted when the following apply:
      i. The authorization package is complete;
      ii. The inherent risk the system introduced to IRS operations (including mission, function, image, and reputation), assets, individuals, other organizations, and the Nation, is acceptable to the AO; and
      iii. No corrective actions are required or may require minor corrective actions. (Note: There may be findings during the authorization process that are tracked with a POA&M, but do not prevent an ATO).

    2. IATO - Interim Authorization to Operate shall be granted when the following apply:
      i. The authorization package is complete;
      ii. The inherent risk the system introduced to IRS operations (including mission, function, image, and reputation), assets, individuals, other organizations, and the Nation, is unacceptable to the AO to grant a full ATO, but there is an important mission-related need to place the system into operation; and
      iii. A POA&M schedule for correcting the deficiencies to achieve ATO is developed. This plan shall be mutually acceptable to the system owner and the AO.

      Note:

      (from NIST SP 800-37 Rev1) “Some organizations may choose to use the term interim authorization to operate to focus attention on the increased risk being accepted by the authorizing official in situations where there are significant weaknesses or deficiencies in the information system, but an overarching mission necessity requires placing the system into operation or continuing its operation.”

    3. Denial of Authorization to Operate - If the system cannot meet IATO requirements or the residual risks are considered by the AO to be too high to accept; the authorization shall be denied. The system may not be placed into operation until at least an IATO can be granted.

  3. An IRS information system's Security Authorization (i.e., accreditation) shall be maintained through continuous monitoring, POA&M actions, and updates to other Security Authorization (i.e., accreditation) documentation.

    1. At a minimum, an information system’s Security Authorization (i.e., accreditation) documentation shall be reviewed and updated annually.

  4. An IRS information system shall be submitted for re-authorization (i.e., re-accreditation) to the AO 30 days prior to its ATO expiring, which allows sufficient time for the documentation to be reviewed.

    1. Additional time shall be needed if an information system’s authorization documentation has not been maintained and updated through continuous monitoring efforts.

    2. If the appropriate ongoing authorization steps have been followed, then the reauthorization action can be as simple as updating the security status information in the authorization package (i.e., the security plan, security assessment report, and plan of action and milestones).

  5. If an IRS information system has not been re-authorized (i.e., re-accredited) after 3 years and it has not been granted an IATO to continue operations, it shall:

    1. Have its ATO rescinded; and

    2. Be removed from operations until at least a Security Authorization (i.e., accreditation) has been granted.

  6. All IRS information systems, major applications, and GSS shall go through the Security Assessment and Authorization process and be authorized (ATO or IATO) by the AO before being placed into production. (NIST SP 800-53 CA-6)

  7. The AO shall be responsible for accepting and accountable for the security risks associated with the information system operations on their information systems.

  8. The Chief Information Officer (CIO) shall appoint, in writing, a senior-level executive or manager to the role of AO for an IRS information system.

  9. The IRS shall maintain an inventory of all major applications and GSS.

    1. The inventory shall be updated at least annually.

  10. In addition to the inventory requirements identified in the System Component Inventory section of this IRM, the inventory of major applications and GSS shall contain, at a minimum:

    1. The system name;

    2. Platform and type (major application or GSS);

    3. Classification level if appropriate;

    4. FIPS-199 category;

    5. Business Unit (and POC);

    6. AO;

    7. Interfaces and interconnections;

    8. Whether it is an IT critical asset;

    9. Last vulnerability test date;

    10. Last risk assessment date; and

    11. Authorization dates.

  11. At a minimum, the final Security Assessment and Authorization package(s) shall consist of the following deliverables:

    1. System Security Plan (SSP);

    2. Security Risk Assessment (SRA);

    3. Any Interconnection Agreements;

    4. Any Memorandum of Understanding (MOU);

    5. IT Contingency Plan (ITCP);

    6. Privacy Impact Assessment (PIA);

    7. Any active POA&Ms

    8. Any Risk-Based Decisions;

    9. System Test and Evaluation (ST&E) Report;

    10. Security Assessment Report (SAR);

    11. Executive Summary of Risk;

    12. Authorization Recommendation;

    13. Auditing plan; and

    14. Security Authorization Decision Document (i.e., signed ATO/IATO memo).

  12. IRS information system owners shall confirm the required deliverables of the Security Assessment and Authorization package with ACIO Cybersecurity.

  13. See the Cybersecurity Security Assessment & Authorization (SA&A) web site for SA&A information. http://mits.web.irs.gov/Cybersecurity/Certification/default.htm

10.8.1.3.5.4  (11-25-2011)
Security Reviews (Audits)

  1. IRS security reviews lend themselves to following the Government Auditing Standards performance audits and where appropriate, shall follow the guidance provided in the standard.

  2. Per the Government Auditing Standards, performance audits, entailing a broad or narrow scope of work, should apply a variety of methodologies; involve various levels of analysis, research, or evaluation; generally provide findings, conclusions, and recommendations; and result in the issuance of a report. Performance audit objectives shall include, but are not limited to:

    1. Whether the audited entity is following sound procurement practices; and

    2. The reliability, validity, or relevance of financial information related to the performance of a program.

  3. Per the Government Auditing Standards, internal control audit objectives relate to management's plans, methods and procedures used to meet its mission, goals and objectives. Objectives related to internal control shall include, but are not limited to, the extent that internal control of a program provides reasonable assurance that:

    1. Resources are safeguarded against unauthorized acquisition, use, or disposition;

    2. Security over computerized information systems shall prevent or timely detect unauthorized access;

    3. Contingency planning for information systems provides essential backup to prevent unwarranted disruption of activities and functions the systems support; and

    4. The information and information systems are assured the appropriate level of Confidentiality, Integrity, & Availability (CIA).

  4. The IRS shall perform performance reviews, specifically internal control reviews of mission/information assurance conditions.

    1. IRS security reviews shall be conducted by internal (e.g., Cybersecurity) or external (e.g., GAO, TIGTA) organizations.

  5. Security reviews shall have documented:

    1. Well defined objectives - The objectives are what the review is intended to accomplish. The objectives shall define the review subjects and performance aspects to be included, as well as the potential finding and reporting elements that the reviews expect to develop. Review objectives can be thought of as questions about the program (function/system/application) that reviewers seek to answer;

    2. A defined scope - Scope is the boundary of the review and shall be directly tied to the review objectives. For example, the scope defines parameters of the review such as the period of time reviewed, the availability of necessary documentation or records and the locations at which field work shall be performed; and

    3. A methodology to achieve the objectives - The methodology comprises the work involved in gathering and analyzing data to achieve the objectives. Review procedures are the specific steps and tests reviewers shall carry out to address the review objectives. Reviewers shall design the methodology to provide sufficient, competent and relevant evidence to achieve the objectives of the review. Methodology includes both the types and extent of review procedures used to achieve the review objectives.

10.8.1.3.5.5  (11-25-2011)
Information System Connections

  1. The IRS shall: (NIST SP 800-53 CA-3)

    1. Authorize all connections from an IRS information system to other information systems outside of the authorization boundary through the use of system connection agreements;

    2. Document IRS information system connections through an Interconnection Agreement and associated security requirements for each connection, the interface characteristics, security requirement, and the nature of the information communicated; and

    3. Monitor information system connections, verifying enforcement of security requirements.

    Note:

    This control applies to dedicated connections between the information systems and does not apply to transitory, user-controlled connections such as e-mail and website browsing or to connections with external providers who are only providing telecommunications and transmission services.

  2. The IRS shall prohibit the direct connection of an unclassified, national security system to an external network. (NIST SP 800-53 CA-3 CE1)

  3. The IRS shall prohibit the direct connection of a classified, national security system to an external network. (NIST SP 800-53 CA-3 CE2)

    Note:

    No direct connection means that an information system cannot connect to an external network without the use of an approved boundary protection device (e.g., firewall) that mediates the communication between the system and the network.

  4. The IRS shall configure all equipment connected to an IRS system or network, to at least meet the minimum security requirements in this document and applicable Federal IT security guidelines and requirements (e.g., FISMA, NIST, OMB, FIPS, etc.).

  5. A risk assessment shall be performed before any equipment capable of storing or transmitting that data is connected to an IRS system or network. (NIST SP 800-53 CA-3)

  6. Adequate countermeasures shall be applied before connecting any equipment to an IRS system or network. (NIST SP 800-53 CA-3)

  7. The AO shall decide through Risk Management Framework (RMF) processes to allow or disallow equipment to be connected to an IRS system or network.

  8. Devices that are not IRS-owned shall not be used to transmit SBU data.

  9. The IRS shall include language addressing the responsibility for Security Assessment and Authorization activities and access to Security Assessment and Authorization documentation when forming agreements with extra-IRS entities for operations and maintenance of IRS-owned information systems.

  10. Interconnection Agreements shall be established with all agencies in accordance with NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems. For systems in which the AO is not the CIO/CTO, the coordination shall include a CIO/CTO sign-off.

10.8.1.3.5.5.1  (11-25-2011)
Interconnection Agreements

  1. Interconnections between IRS and non-IRS systems shall be established through controlled interfaces and shall be documented with an Interconnection Agreement. (NIST SP 800-53 CA-3)

  2. Interconnection Agreements shall include technical, management, and operational controls and who is responsible for each control at his/her respective side of the connection.

    1. Responsibility and accountability shall be documented for both sides of the interconnection.

  3. Interconnecting systems with the same AO do not require an Interconnection Agreement. The interface characteristics between the interconnecting information systems shall be described in the security plans for the respective systems.

  4. When Interconnecting systems have different AO, but both AOs are in the IRS, the IRS may determine whether an Interconnection Agreement is required, or alternatively, ensure the interface characteristics between systems are described in the security plans of the respective systems. (NIST SP 800-53 CA-3)

  5. The IRS shall document interconnections between external networks with an Interconnection Agreement signed by both AOs. (NIST SP 800-53 CA-3)

  6. The Interconnection Agreement shall document the security protections on both systems to ensure only acceptable transactions are permitted. (NIST SP 800-53 CA-3)

  7. A single Interconnection Agreement can cover multiple system connections to multiple systems within the same external organization from a single IRS system or from multiple IRS systems. In the latter case, any unique or technical security requirements relevant to a discrete subset of the systems should be identified as such.

    1. The Interconnection Agreement shall identify any unique technical or security requirements relevant to a discrete subset of the systems in agreements where multiple system connections exist in the same Interconnection Agreement.

    2. The Cybersecurity - IT Security - Architecture & Implementation - Architecture Engineering Advisory Organization is responsible for providing security engineering oversight of interconnections with external partners and the supporting Interconnection Agreements. Refer to Cybersecurity Architecture & Engineering Advisory A&I Security Engineering Services for additional information and support on Interconnection Agreements or MOUs.

  8. When conducting a joint authorization (an information system involving more than one AO), one individual shall be designated the lead AO by mutual agreement. A single AO shall be designated for each information system.

  9. Where an information system involves more than one bureau, one shall be designated the AO by mutual agreement. The Treasury Department shall resolve any conflicting security controls or concerns.

  10. The IRS shall create Interconnection Agreements in accordance with NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems.

10.8.1.3.5.6  (11-25-2011)
Continuous Monitoring

  1. The IRS shall establish a continuous monitoring strategy and implement a continuous monitoring program that includes: (NIST SP 800-53 CA-7)

    Note:

    Continuous monitoring and security assessments are interrelated. Information obtained during continuous monitoring and security assessments is used when making authorization decisions.

    1. A configuration management process for the information system and its constituent components;

    2. A determination of the security impact of changes to the information system and environment of operation;

    3. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy; and

    4. Reporting the security state of the information system to appropriate IRS officials annually, at a minimum.

    Note:

    For this requirement, security state is relevant to a system’s compliance status.

  2. The IRS shall employ an independent assessor or assessment team to monitor the security controls in IRS information systems on an ongoing basis as part of the continuous monitoring program. (NIST SP 800-53 CA-7 CE1)

  3. As part of the continuous monitoring program, the IRS shall plan, schedule, and conduct security assessments on an annual basis, at a minimum, to ensure compliance with all vulnerability mitigation procedures. (NIST SP 800-53 CA-7 CE2)

    1. Assessments shall be announced and unannounced; and

    2. Assessments may consist of, but are not limited to the following assessment types:
      i. In-depth monitoring;
      ii. Malicious user testing;
      iii. Penetration testing; and
      iv. Red team exercises.

10.8.1.3.5.6.1  (11-25-2011)
Compliance Monitoring

  1. Cybersecurity Operations shall ensure the development of Standard Operating Procedures (SOPs) to ensure compliance with IRM 10.8.x series providing enterprise level guidance and review throughout the Enterprise Life Cycle.

  2. SOPs shall be used by Security Specialists as a means to ensure compliance reporting and monitoring objectives in order to meet IRS FISMA compliance reporting requirements.

  3. Cybersecurity Operations shall partner with the appropriate MITS and impacted business units for the development, approval, and communication of SOPs.

  4. Cybersecurity shall ensure SOPs are developed and maintained for all IRS critical business processes.

    1. At a minimum, SOPs shall address the following areas:
      • Internet Security Scanner Network Scanning;
      • Network Policy Compliance Checks;
      • Operating System Policy Compliance Checks;
      • Windows-based Account Status Compliance Checks;
      • Windows-based Account Activity Checks;
      • Common IT Security Controls Review;
      • Online 5081 (OL5081) Reviews;
      • Cybersecurity Quality Assurance Reviews;
      • Disaster Recovery.

  5. Cybersecurity Operations shall maintain their security SOPs in an on-line repository available to all stakeholders (http://mits.web.irs.gov/Cybersecurity/Tools_Resources/office_procedures.htm)

    1. SOPs shall be updated as processes or technologies change.

10.8.1.4  (12-16-2006)
Operational Controls

  1. The IRS shall implement operational security controls, which are primarily implemented and executed by personnel for each information system.

10.8.1.4.1  (11-25-2011)
Personnel Security

  1. The IRS shall develop, disseminate, review, and update annually a formal, documented Personnel Security Policy that addresses the following: (NIST SP 800-53 PS-1)

    • Purpose

    • Scope

    • Roles and Responsibilities

    • Management commitment

    • IRS coordination

    • Compliance

  2. The IRS shall develop, disseminate, review, and update annually, procedures to facilitate the implementation of the Personnel Security Policy and associated Personnel Security controls. (NIST SP 800-53 PS-1)

    1. The Personnel Security Policy and procedures shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

10.8.1.4.1.1  (11-25-2011)
Position Categorization

  1. The IRS shall ensure that individuals occupying positions of responsibility within IRS organizations are trustworthy and meet established security criteria for those positions.

    1. Refer to IRM 10.8.2 , for further guidance on roles with IT security responsibilities.

  2. The IRS shall: (NIST SP 800-53 PS-2)

    1. Assign a sensitivity/risk level designation for all positions (employee and contractor);

    2. Establish screening criteria for individuals filling these positions; and

    3. Review and revise position sensitivity/risk level designations at a minimum annually or when position descriptions are rewritten.

    Note:

    Position risk designations are consistent with Office of Personnel Management policy and guidance. The screening criteria include explicit information security role appointment requirements (e.g., training, security clearance).

10.8.1.4.1.2  (11-25-2011)
Personnel Screening

  1. The IRS shall implement and maintain an appropriate personnel screening (i.e., investigations) process.

    1. Screenings and background investigations for employees and contractors shall be conducted in accordance with procedures outlined in IRM 10.23.1, Personnel Security; IRM 10.23.2, Contractor Investigations; and IRM 10.23.3, Personnel Security/Suitability Program.

  2. Program officials and appropriate IRS heads of office shall ensure adequate funding is available to cover the cost of screening for employees and contractors accessing their information systems.

  3. All employees and contractors accessing information systems shall be screened prior to authorizing access. (NIST SP 800-53 PS-3)

  4. Employees and contractors shall not access an IRS information system that processes, stores, or transmits sensitive/classified information until they are cleared and in-briefed in accordance with IRM 10.23.1 , Personnel Security, IRM 10.23.2, Contractor Investigations, and IRM 10.23.3, Personnel Security/Suitability Program to the highest classification-level for the information on the information system. (NIST SP 800-53 PS-3 CE1)

10.8.1.4.1.3  (12-16-2006)
Unauthorized Access (UNAX)

  1. The willful unauthorized access or inspection of taxpayer records is referred to as UNAX.

  2. On August 5, 1997, President Clinton signed the Taxpayer Browsing Protection Act into law. Under the law:

    1. Willful unauthorized access or inspection of non-computerized taxpayer records, including hard copies of returns - as well as computerized information - is a crime, punishable upon conviction, by fines, prison terms and termination of employment;

    2. Taxpayers have the right to take legal action when they are victims of unlawful access or inspection - even if a taxpayer’s information is never revealed to a third party; and

    3. When managers or employees are criminally charged, the Service is required to notify taxpayers that their records have been accessed without authorization.

  3. IRS employees shall only be allowed access to taxpayer records when the information is needed to carry out their tax administration duties.

  4. The provisions and applicable criminal penalties under the Taxpayer Browsing Protection Act shall also apply to all contractors and contractor employees.

  5. The IRS shall establish a program to ensure that all employees understand what UNAX is and what the consequences are if they access or inspect taxpayer records for other than authorized tax administration reasons.

  6. Cybersecurity shall manage a centralized evaluation capability, including the consistency of actions taken, to oversee compliance with the UNAX policy and program.

  7. Cybersecurity shall be responsible for reporting on the progress of the IRS' efforts being taken and making recommendations for improving the effectiveness of the UNAX program to IRS’ Management.

  8. The IRS shall conduct annual awareness briefings that focus attention on the prevention of willful unauthorized access and inspection of taxpayer returns/tax return information.

  9. Upon completing the required UNAX training, each employee shall either electronically certify that they have completed their briefing through ELMS or along with his/her manager, sign a Form 11370, Certification of Annual UNAX Awareness Briefing. http://irweb.irs.gov/AboutIRS/Nwsctr/Headlines26162.aspx.

10.8.1.4.1.4  (11-25-2011)
Access Agreements

  1. Individuals requiring access to IRS information and information systems shall sign appropriate access agreements prior to being granted access. (NIST SP 800-53 PS-6)

    1. Access agreements shall be reviewed and updated at a minimum annually.

    Note:

    Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with the information system to which access is authorized. Electronic signatures are acceptable for use in acknowledging access agreements unless specifically prohibited by organizational policy.

  2. Access to information and information systems with sensitive information (e.g., SBU, CUI, PII, proprietary) shall only be granted to individuals who: (NIST SP 800-53 PS-6 CE1)

    1. Have a valid need for the access in order to conduct their assigned official duties; and

    2. Satisfy associated personnel security criteria (Have the clearance for the information being accessed).

10.8.1.4.1.5  (11-25-2011)
Personnel Departures (Separation from Duty)

  1. The IRS shall implement and maintain procedures to ensure appropriate system accesses are revoked for employees/contractors who leave the IRS, are reassigned to other duties, on extended leave, or are under disciplinary actions. (NIST SP 800-53 PS-5)

    1. Accounts for IRS employees placed on Leave Without Pay (LWOP) while performing military duty shall adhere to the inactivity provisions in the Business Role Account Inactivity section of this IRM.

      Note:

      45 days is timeframe under Business Accounts Inactivity. An IG Memo is in queue for signature extending this to 120 days.

    2. IRS employees placed on furlough may be provided access to e-mail, intranet and internet only for usage during the furlough time-period.

  2. All appropriate personnel shall be notified promptly of all reassignments/transfers, promotions, terminations, or retirements of departing employees or contractors to ensure that accesses are removed.

  3. Access shall be suspended for any employee or contractor on extended leave or detail over 90 days.

    1. The employee's supervisor or Contracting Officer's Technical Representative (COTR) shall request reinstatement of access upon the return to active duty of the employee or contractor.

  4. The IRS shall implement procedures that require departing employees to return all forms of media used to gain system access to IRS media, personal electronic devices, keys, identification (ID) cards, proxy cards, and any other IRS property on their last workday. (NIST SP 800-53 PS-4)

  5. Each employee’s manager shall have the primary responsibility for notifying the responsible organization via OL5081, Automated Information System (AIS) User Registration/Change Request, of system user status changes (e.g., terminations, transfers, reclassifications).

    1. The responsible organization shall immediately suspend, cancel, and/or adjust all access privileges associated with changes in status of the user.

  6. The IRS shall implement and maintain periodic follow-up reviews and corrective action procedures to ensure timely adjustment of access privileges associated with transfers, terminations, and changes in contractual agreements with non-IRS entities. The procedures shall include, at a minimum:

    1. Review of inactive user IDs/accounts;

    2. Coordinated review of access control lists with information owners;

    3. Coordinated review of network, system, and resource access authority for non- IRS entities with responsible IRS business areas; and

    4. Setting of automated account expiration for non-IRS entities, where technically feasible, and when the access termination date can be predetermined.

  7. Employees shall be instructed whether or not to remove data from their computer before leaving. If cryptography is used to protect data, the availability of cryptographic keys to management personnel must be ensured.

10.8.1.4.1.5.1  (11-25-2011)
Personnel Termination

  1. Upon an individual’s (employee, contractor, etc…) termination, at a minimum, the IRS shall include the following procedures in their termination procedures (NIST SP 800-53 PS-4):

    1. Terminate information system access;

    2. Retrieve security-related IRS information system-related property (e.g., hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes);

    3. Brief on the continuing responsibilities for confidentiality and privacy;

    4. Retain access to IRS information and information systems formerly controlled by the terminated individual; and

    5. Conduct certificate revocation in accordance with IRM 10.8.52, Information Technology (IT) Security, PKI Security Policy.

  2. After an individual's termination, but before their departure, an exit interview shall take place to ensure all out processing/exit actions are completed and all IRS property and equipment is returned. (NIST SP 800-53 PS-4)

10.8.1.4.1.5.2  (11-25-2011)
Personnel Transfer

  1. Logical and physical access authorizations to information systems and facilities shall be reviewed when personnel are reassigned or transferred to other positions within the IRS. (NIST SP 800-53 PS-5)

  2. Transfer or reassignment actions shall be initiated in accordance with the OL5081 processes within five (5) business days of the formal transfer action. (NIST SP 800-53 PS-5)

    Note:

    Reviews and OL5081 process actions apply when the reassignment or transfer of an employee is permanent or of such an extended duration as to make the actions warranted.

10.8.1.4.1.6  (11-25-2011)
Disciplinary Action

  1. The IRS shall employ a formal sanctions process for personnel failing to comply with established information security policies and procedures. (NIST SP 800-53 PS-8)

    1. The sanctions process shall be consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

      Note:

      The process is described in access agreements and can be included as part of the general personnel policies and procedures for the IRS.

  2. IRS employees shall be subject to disciplinary action for failure to comply with IRS security policy, whether or not the failure results in criminal prosecution.

  3. All users (e.g., employees, non-IRS federal employees, and IRS contractors) who fail to comply with IRS security policy shall be subject to having their access to IRS information systems and facilities terminated, whether or not the failure results in criminal prosecution.

  4. Any person who improperly discloses sensitive information shall be subject to criminal and civil penalties and sanctions under the appropriate law (e.g., Privacy Act, Trade Secrets Act, and Bank Secrecy Act).

    1. Refer to the Sensitive But Unclassified (SBU) Information, Controlled Unclassified Information (CUI), and Personally Identifiable Information (PII) sections of this IRM for further guidance.

  5. The IRS shall establish procedures for disciplinary actions for security violations for employees, in accordance with applicable personnel and conduct regulations.

    1. Disciplinary actions shall take into account the sensitivity of the information involved, the impact of the offense, and the number of prior offenses.

  6. SATE and the Rules of Behavior for each system shall specify the disciplinary actions for security violations.

  7. The IRS shall adopt standard contract terms for addressing disciplinary action, consistent with the Federal Acquisition Regulations, which shall be incorporated into all contracts that permit contractor employees access to IRS information and information systems.

    1. Contract terms shall permit the government to exclude contractor employees from accessing IRS information and information systems.

  8. Suspected security violations shall be reported to the appropriate IRS personnel, depending on the type of incident (IT, personnel, etc.) for investigation and recommended disciplinary action.


Next

More Internal Revenue Manual