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

May 3, 2012

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 November 25, 2011. 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) Due to enterprise operational impact, Cybersecurity has revised controls and control enhancements, levied in the previous version of this IRM. The following table lists the controls, which have been modified with this release of policy:

CLASS FAMILY CONTROL SECTION
Management Risk Assessment RA-5 Vulnerability Scanning 10.8.1.3.2.2
Management Planning PL-2 System Security Plan
PL-6 Security Related Activity Planning 		10.8.1.3.3.1
10.8.1.3.3.1.1
Management System and Services Acquisition SA-4 Acquisitions
SA-5 Information System Documentation
SA-6 Software Usage Restrictions
SA-8 Security Engineering Principles
SA-9 External Information System Services
SA-10 Developer Configuration Management
SA-11 Developer Security Testing
SA-12 Supply Chain Protection
SA-13 Trustworthiness 		10.8.1.3.4
10.8.1.3.4.4
10.8.1.3.4
10.8.1.3.4.3
10.8.1.3.4.1
10.8.1.3.4.6
10.8.1.3.4.6
10.8.1.3.4.5
10.8.1.3.4.5
Management Security Assessment and Authorization CA-3 Information Security Connections
CA-5 Plan of Action and Milestones
CA-7 Continuous Monitoring 		10.8.1.3.5.5
10.8.1.3.5.2
10.8.1.3.5.6
Operational Personnel Security PS-3 Personnel Screening 10.8.1.4.1.2
Operational Physical and Environmental Protection PE-2 Physical Access Authorizations
PE-3 Physical Access Control
PE-4 Access Control for Transmission Medium
PE-5 Access Control for Output Devices
PE-6 Monitoring Physical Access
PE-7 Visitor Control
PE-8 Access Records
PE-9 Power Equipment and Power Cabling
PE-10 Emergency Shutoff
PE-11 Emergency Power
PE-12 Emergency Lighting
PE-13 Fire Protection
PE-14 Temperature and Humidity Control
PE-15 Water Damage Protection
PE-17 Alternate Work Site
PE-18 Location of Information System Components 		10.8.1.4.2.1
10.8.1.4.2.1
10.8.1.4.2.1
10.8.1.4.2.1.1
10.8.1.4.2.1.2
10.8.1.4.2.1.3
10.8.1.4.2.1.3.2
10.8.1.4.2.3.1
10.8.1.4.2.3.2
10.8.1.4.2.3.3
10.8.1.4.2.3.4
10.8.1.4.2.3.5
10.8.1.4.2.3.6
10.8.1.4.2.3.7
10.8.1.4.2.4
10.8.1.4.2
Operational Contingency Planning CP-2 Contingency Plan
CP-3 Contingency Training
CP-4 Contingency Plan Testing and Exercises
CP-6 Alternate Storage Site
CP-7 Alternate Processing Site
CP-8 Telecommunications Services
CP-9 Information System Backup
CP-10 Information System Recovery and Reconstitution 		10.8.1.4.3
10.8.1.4.3.1
10.8.1.4.3.1.1
10.8.1.4.3.2
10.8.1.4.3.3
10.8.1.4.3.4
10.8.1.4.3.5
10.8.1.4.3.5.1
Operational Configuration Management CM-2 Baseline Configuration
CM-3 Configuration Change Control
CM-4 Security Impact Analysis
CM-5 Access Restrictions for Change
CM-6 Configuration Settings
CM-7 Least Functionality
CM-8 Information System Component Inventory
CM-9 Configuration Management Plan 		10.8.1.4.4.1
10.8.1.4.4.3
10.8.1.4.4.3
10.8.1.4.4.3
10.8.1.4.4.6
10.8.1.4.4.6
10.8.1.4.4.2
10.8.1.4.4
Operational Maintenance MA-2 Controlled Maintenance
MA-3 Maintenance Tools
MA-4 Non-Local Maintenance
MA-5 Maintenance Personnel
MA-6 Timely Maintenance 		10.8.1.4.5.1
10.8.1.4.5.2
10.8.1.4.5.3
10.8.1.4.5.4
10.8.1.4.5.5
Operational System and Information Integrity SI-2 Flaw Remediation
SI-4 Information System Monitoring
SI-6 Security Functionality Verification
SI-7 Software and Information Integrity
SI-8 Spam Protection
SI-9 Information Input Restrictions
SI-10 Information Input Validation
SI-11 Error Handling 		10.8.1.4.6.1
10.8.1.4.6.4
10.8.1.4.6.4.2
10.8.1.4.6.4.1
10.8.1.4.6.2.1
10.8.1.4.6.6
10.8.1.4.6.6
10.8.1.4.6.1
Operational Media Protection MP-2 Media Access
MP-3 Media Marking
MP-5 Media Transport
MP-6 Media Sanitization 		10.8.1.4.7.1
10.8.1.4.7.2
10.8.1.4.7.4
10.8.1.4.7.5
Operational Incident Response IR-2 Incident Response Training
IR-3 Incident Response Testing and Exercises
IR-4 Incident Handling
IR-5 Incident Monitoring
IR-6 Incident Reporting
IR-7 Incident Response Assistance 		10.8.1.4.8.3
10.8.1.4.8.3.1
10.8.1.4.8.1.2
10.8.1.4.8.2
10.8.1.4.8.1.1
10.8.1.4.8.4
Operational Awareness and Training AT-2 Security Awareness
AT-3 Security Training 		10.8.1.4.9.1
10.8.1.4.9.2
Technical Access Control AC-2 Account Management
AC-3 Access Enforcement
AC-4 Information Flow Enforcement
AC-5 Separation of Duties
AC-6 Least Privilege
AC-7 Unsuccessful Login Attempts
AC-10 Concurrent Session Control
AC-11 Session Lock
AC-14 Permitted Actions without Identification or Authentication
AC-17 Remote Access
AC-18 Wireless Access
AC-20 Use of External Information Systems 		10.8.1.5.2.2
10.8.1.5.2.2
10.8.1.5.2.5.2
10.8.1.5.2.6
10.8.1.5.2.7
10.8.1.5.2.10
10.8.1.5.2.10.3
10.8.1.5.2.10.2
10.8.1.5.2.14
10.8.1.5.2.11
10.8.1.5.2.12
10.8.1.5.2.15
Technical Audit and Accountability AU-2 Auditable Events
AU-3 Content of Audit Records
AU-5 Response to Audit Processing Failures
AU-6 Audit Review, Analysis, and Reporting
AU-7 Audit Reduction and Report Generation
AU-9 Protection of Audit Information
AU-10 Non-Repudiation
AU-12 Audit Generation 		10.8.1.5.3.1
10.8.1.5.3.3.1
10.8.1.5.3.2
10.8.1.5.3.4
10.8.1.5.3.4.1
10.8.1.5.3.3.4
10.8.1.5.3.5
10.8.1.5.3.3
Technical Identification and Authentication IA-2 Identification and Authentication (Organizational Users)
IA-3 Device Identification and Authentication
IA-4 Identifier Management
IA-5 Authenticator Management 		10.8.1.5.1
10.8.1.5.1.1
10.8.1.5.1.2
10.8.1.5.1.3
Technical System and Communications Protection SC-2 Application Partitioning
SC-3 Security Function Isolation
SC-4 Information in Shared Resources
SC-5 Denial of Service Protection
SC-7 Boundary Protection
SC-8 Transmission Integrity
SC-9 Transmission Confidentiality
SC-10 Network Disconnect
SC-12 Cryptographic Key Establishment and Management
SC-13 Use of Cryptography
SC-15 Collaborative Computing Devices
SC-18 Mobile Code
SC-19 Voice Over Internet Protocol
SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver)
SC-22 Architecture and Provisioning for Name/Address Resolution Services
SC-23 Session Authenticity
SC-28 Protection of Information at Rest
SC-32 Information System Partitioning 		10.8.1.5.4
10.8.1.5.4
10.8.1.5.4
10.8.1.5.4
10.8.1.5.4.3.1
10.8.1.5.4.4
10.8.1.5.4.4
10.8.1.5.4.3
10.8.1.5.4.6.1
10.8.1.5.4.6
10.8.1.5.4.11
10.8.1.5.4.7
10.8.1.5.4.4.1
10.8.1.5.4.3.2 , 10.8.1.5.4.11
10.8.1.5.4.3.2
10.8.1.5.4.12
10.8.1.5.4.6
10.8.1.5.4

(5) Due to enterprise operational impact, Cybersecurity has removed numerous controls across several control families, levied in the previous version of this IRM. The following table lists the controls, which have been removed with this release of policy:

CLASS FAMILY CONTROL
Operational Physical and Environmental Protection PE-19 Information Leakage
Operational System and Information Integrity SI-13 Predictable Failure Prevention
Operational Awareness and Training AT-5 Contacts with security Groups and Associations
Technical Access Control AC-9 Previous Logon (Access) Notification
AC-16 Security Attributes
AC-21 User Based Collaboration and information Sharing
Technical Audit and Accountability AU-13 Monitoring for Information Disclosure
AU-14 Session Audit
Technical System and Communication Protection SC-6 Resource Priority
SC-11 Trusted Path
SC-16 Transmission of Security Attributes
SC-25 Thin Nodes
SC-26 Honey Pots
SC-27 Operating System Independent Applications
SC-29 Heterogeneity
SC-30 Visualization Techniques
SC-31 Covert Channel Analysis
SC-33 Transmission Preparation Integrity
SC-34 Non-modifiable Executable Programs

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

  1. Interim Guidance # MITS-10-1011-01, Information Technology (IT) Security, Policy and Guidance - Securing Network Ports in IRS Facilities, dated November 30, 2011;

  2. Interim Guidance # MITS-10-0112-03, Information Technology (IT) Security, Policy and Guidance - Controls for Software and Applications during Development and Testing, dated January 6, 2012;

(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. Additionally, this IRM was updated to incorporate Interim Guidance # MITS-10-1011-01 and # MITS-10-0112-03. See Exhibit 10.8.1-9, References, IRS & Cybersecurity Memorandums, for superseded Interim Guidance Memorandums to date.

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

(05-03-2012)

Terence V. Milholland
Chief Technology Officer

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  (05-03-2012)
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. For further information, see Cybersecurity’s website at: 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. Cybersecurity has already documented and published security controls (IRM 10.8 series) 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)), necessary for implementation of the security controls; delineated in the IRM 10.8 series. 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.

  7. In an effort to reference the origin of a security requirement (NIST, Treasury, etc.), a requirement may have it's 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).

  8. In addition to referencing the origin at the end of a requirement (e.g., NIST SP 800-53 CA-1), a Federal Information Processing Standards (FIPS) 199 Security Impact-level Designator may be assigned at the end of it. This designator indicates that the requirement applies to information systems categorized at that FIPS 199 impact-level. A requirement without a Security Impact-level Designator, means the requirement applies to all information systems.

    Note:

    For example, a requirement with an indicator of (H) indicates the requirement only applies to information systems categorized as FIPS 199 Impact-level HIGH.

  9. FIPS 199 Security Impact-level Designator:

    • (L) – Applies to systems categorized as FIPS 199 Impact-level LOW

    • (M) – Applies to systems categorized as FIPS 199 Impact-level MODERATE

    • (H) – Applies to systems categorized as FIPS 199 Impact-level HIGH

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  (05-03-2012)
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  (05-03-2012)
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 significant 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.

  8. Information systems in a Development and Testing Environment shall adhere to the security requirements within this IRM based on an assessment of risk and the system’s assigned FIPS 199 categorization level.

    Note:

    i. The FIPS 199 categorization level of information systems is contingent on the information and data processed, stored, and transmitted on the system. The existence of sensitive data on a system may establish a security categorization level of Moderate or High, depending on the impact level determined during the system’s assessment of risk.
    ii. An AO makes risk based decisions, based on an assessment of risk, determining which applicable security controls (e.g., contingency planning, alternate storage and processing sites, system backup and recovery) are to be implemented on an information system in a development and testing environment. The risk based decision is to be documented in accordance with the Risk Assessment section of this IRM.

    1. See the Risk Assessment and Security Categorization section of this IRM for guidance on conducting an assessment of risk and defining security categorization levels.

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  (05-03-2012)
Information Security Program Management

  1. The IRS shall develop, disseminate, review, and update every three (3) years (or if there is a significant change) 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;

    3. Is approved by a senior official with responsibility and accountability for the risk being incurred to organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation; and

    4. 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  (05-03-2012)
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; TD P 85-01 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 Treasury builds out its Security Information Management capability, the IRS shall provide security-related situational awareness data feeds to the Department of 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  (05-03-2012)
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.” For further information, see www.idmanagement.gov.

10.8.1.3.1.7  (05-03-2012)
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 (2) 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 significant 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  (05-03-2012)
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 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  (05-03-2012)
Risk Assessment

  1. The IRS shall develop, disseminate, review, and update every three (3) years (or if there is a significant change) 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 compliance applications tools compliance levels, based on an assessment of risk to the IRS infrastructure.

    1. 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  (05-03-2012)
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 HIGH.

    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  (05-03-2012)
Vulnerability Analysis and Assessment

  1. Vulnerability scanning tools and techniques shall be employed 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. Information systems and hosted applications shall be scanned for vulnerabilities: (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. Vulnerability scanning tools shall be employed that include the capability to readily update the list of information system vulnerabilities scanned. (NIST SP 800-53 RA-5 CE1) (M, H)

  5. The list of information system vulnerabilities scanned shall be updated at least semi-annually or when new vulnerabilities are identified and reported. (NIST SP 800-53 RA-5 CE2) (M, H)

  6. Vulnerability scanning procedures shall be employed 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) (M, H)

  7. The IRS shall attempt to discern what information about an information system is discoverable by adversaries. (NIST SP 800-53 RA-5 CE4) (M, H)

  8. 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) (M, H)

    Note:

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

  9. Automated mechanisms shall be employed to detect the presence of unauthorized software on IRS information systems and notify designated IRS officials. (NIST SP 800-53 RA-5 CE7) (M, H)

    Note:

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

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

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

10.8.1.3.3  (05-03-2012)
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 shall 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  (05-03-2012)
System Security Planning

  1. A security plan shall be developed 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., RBD) decisions; and

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

  2. The information system’s security plan shall be: (NIST SP 800-53 PL-2)

    1. Reviewed at a minimum every three (3) years (or as a result of a significant change); and

    2. Updated to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments.

    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. 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 series IRMs on the IRM Numerical Index located on the media and electronic publishing website.

10.8.1.3.3.1.1  (05-03-2012)
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) (M, H)

    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  (05-03-2012)
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 rules of behavior shall include, 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  (05-03-2012)
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, Governmental Liaison and Disclosure (PGLD) Office.

  6. PGLD shall establish and manage privacy policies and the PIA processes and procedures. For all privacy-related guidance, see IRM 10.5.1, Privacy, Information Protection & Data Security Policy and Guidance. For further information, see
    http://irm.web.irs.gov/link.asp?link=10.5.1

10.8.1.3.4  (05-03-2012)
System and Services Acquisition

  1. The IRS shall develop, review, and update every three (3) years (or if there is a significant change) a System and Services Acquisition Policy that incorporates information security considerations and addresses the following: (NIST SP 800-53 SA-1)

    • Purpose

    • Scope

    • Roles and Responsibilities

    • Management commitment

    • IRS coordination

    • 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, E.O.s, directives, policies, regulations, standards, and guidance.

  3. All acquisition of applications or services shall adhere to federal laws, E.O.s, 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, E.O.s, 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) (M, H)

  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) (H)

  7. Each information system component acquired shall be explicitly assigned to an information system and the owner of the system shall acknowledges this assignment. (NIST SP 800-53 SA-4 CE4) (M, H)

  8. Rules governing the installation of software by users shall be developed, documented, and enforced. (NIST SP 800-53 SA-7)

  9. Control and tracking measures shall be employed 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. Only legal and licensed (including open source, shareware, and freeware licenses, etc.) software (including operating systems, databases, applications, etc.) approved by MITS shall be 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  (01-06-2012)
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 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 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.

  3. 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. (TD P 85-01 P-AC&O.1)

  4. 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.

  5. 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)

  6. 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  (05-03-2012)
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 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) (M, H)

  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  (05-03-2012)
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. Vendor or contractor provided documentation shall be obtained, protected, and made available based upon sensitivity to authorized personnel with sufficient detail to permit analysis and testing that describes the following:

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

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

    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) (M, H)

  6. Documentation shall be developed and maintained detailing the IT hardware and software configuration, to include all security configurations and countermeasures protecting it.

10.8.1.3.4.5  (05-03-2012)
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. 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.

  3. 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) (H)

  4. 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) (H)

10.8.1.3.4.6  (01-06-2012)
Information System Developers

  1. Information system developers shall 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.

  2. Information system developers in consultation with associated security personnel (including security engineers), shall: (NIST SP 800-53 SA-11) (M, H)

    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.

  3. The information system development requirements in this section apply to both internal and external development.

  4. For additional system development guidance see IRM 2.5.x, Systems Development.

10.8.1.3.5  (05-03-2012)
Security Assessment and Authorization

  1. The IRS shall develop, disseminate, review, and update every three (3) years (or if there is a significant change) 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:

    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  (05-03-2012)
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.

    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 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.

  6. 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) (M, H)

  7. The IRS 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) (H)

    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.

  8. 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  (05-03-2012)
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 a 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 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

  3. 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.

  4. 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.

  5. 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.

  6. 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)

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

  8. 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)

  9. 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)

  10. 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 Technology Officer (CTO) 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. For further information on Security Assessment & Authorization (SA&A), see the Cybersecurity web site at: 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  (05-03-2012)
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) (M, H)

  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) (H)

    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.

  6. Adequate countermeasures shall be applied before connecting any equipment to an IRS system or network.

  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  (05-03-2012)
Interconnection Agreements

  1. Interconnections between IRS and non-IRS systems shall be established through controlled interfaces and shall be documented with an Interconnection Agreement.

  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.

  5. The IRS shall document interconnections between external networks with an Interconnection Agreement signed by both AOs.

  6. The Interconnection Agreement shall document the security protections on both systems to ensure only acceptable transactions are permitted.

  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  (05-03-2012)
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.

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 the IRM 10.8 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. For further information, see http://mits.web.irs.gov/Cybersecurity/Tools_Resources/office_procedures.htm

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

10.8.1.3.5.6.2  (05-03-2012)
Security Testing

  1. Annual security assessments shall be conducted 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)

  2. NIST SP 800-53A shall be used as the basis for testing those controls included in that document. (TD P 85-01 S-AST.1)

    1. For security controls not included in 800-53/800-53A, the method of how a control is tested shall be documented in the system’s annual review documentation. (TD P 85-01 S-AST.2)

    2. Priority for selection of controls to be tested shall be: 1) Those POA&M items completed within the applicable timeframe and 2) High-volatility security controls. (TD P 85-01 S-AST.3)

      Note:

      There is no set number of controls to be tested annually; however, the number of controls should take into account the FIPS 199 security categorization level of the system. Controls selected for testing should not be limited to technical controls, but also include operational and management controls.

      Note:

      With regard to volatility, by their nature, operational controls require that correct actions be taken by individuals. Due to potential for personnel turnover, degradation in infrequently used skills, and other factors, many operational controls are volatile, which should be taken into account when selecting controls for testing. Additionally, this volatility with regard to individuals also affects access controls, particularly keeping access control lists and permissions (both for general support systems and applications) up to date. Bureaus should also consider the importance of specific controls to the security of a system. Controls that are crucial to the protection of a system should be considered for selection as part of the testing requirement. These are not necessarily the same as highly volatile controls and may or may not be POA&M items.

  3. For new SA&A and re-authorizations, the testing accomplished in the SA&A shall meet the annual FISMA testing requirement. (TD P 85-01 S-AST.4)

  4. Testing of a system's security-relevant changes that occur out of the SA&A cycle but do not necessarily constitute a ‘significant change’ necessitating a new SA&A shall support meeting the annual testing requirement. (TD P 85-01 S-AST.5)

    Note:

    Since multiple systems might rely on common controls and these systems might each be on a different three (3) year SA&A cycle, continuous monitoring of common controls is essential for assuring system owners that adequate protection is supported by common controls. Examples of this can include (but are not limited to) the activities to continue to screen employees and check references, such as security officials conducting background investigations or moving interim clearances into full clearances. Environmental, HVAC, and fire suppression systems that are maintained by physical plant managers with ongoing inspections and repairs are other examples. As applicable, these should be cross-referenced to the appropriate NIST SP 800-53 control number.

  5. Activities for the annual testing shall be documented and shall include the following (as applicable): (TD P 85-01 S-AST.6)

    1. Planning
      • Security controls selected for testing
      • How these controls were selected (i.e., to include that risk-based decisions were made in control selection)
      • Frequency of planned testing
      • Methods to be used to test/monitor the controls (800-53A or otherwise, as appropriate)
      • Signed approval by the Authorizing Official and the bureau Chief Information Security Officer of the set of security controls that are to be tested as well as the monitoring frequency.

    2. Testing
      • Who conducted the testing
      • Who was interviewed
      • What documentation was reviewed
      • Date(s) of testing
      • Test locations
      • Networks/servers tested
      • Results of testing

    3. Follow-up
      • Weaknesses found and remediated
      • Weaknesses found to be entered into POA&M
      • Update security plan to reflect changes

  6. When testing of a security control reveals that the control is not functioning as expected and corrective action has been taken to mitigate the weakness, the finding and corrective action shall be documented within the testing documentation. In this case, it would not be entered into the POA&M (TD P 85-01 S-AST.7)

  7. When a weakness is not immediately corrected, the weakness shall be documented in the testing documentation and the planned corrective actions should be entered into the POA&M. (TD P 85-01 S-AST.8)

    1. See TD P 85-01, Section 3.8 - Annual Security Reviews (Continuous Monitoring) for additional guidance.

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  (05-03-2012)
Personnel Security

  1. The IRS shall develop, disseminate, review, and update every three (3) years (or if there is a significant change) 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  (05-03-2012)
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)

10.8.1.4.1.3  (05-03-2012)
Unauthorized Access (UNAX)

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

  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. For further information, see: http://irweb.irs.gov/AboutIRS/Nwsctr/Headlines/26162.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).


Next

More Internal Revenue Manual