SCPMaR CONOPS_v1 4 3.doc

Version 1.4.3 Concept of Operations for the Security Compliance Posture Monitoring and Reporting (SCPMaR) Solution

Concept of Operations for the Security Compliance Posture Monitoring and Reporting (SCPMaR) Solution Modernization and Information Technology Services (MITS) Cybersecurity

Version 1.4.3 : May 5, 2009 < This page has been intentionally left blank>

Table of Contents Introduction

81.1 Security Compliance Posture Monitoring and Reporting System (SCPMaRS) at a Glance

91.2 Strategic Drivers and Values

Solution Overview

122.1 Profile of User Roles

132.2 Information Classification

132.3 Modes of Operations

142.4 Security Category

142.5 Operating Environment Description

Concept of Operations (CONOPS)

153.1 Life Cycle Scenario: Security Certification and Accreditation (C&A) Support

153.1.1 Phase I: Initial Phase

163.1.2 Phase II: Security Certification Phase

173.1.3 Phase III: Security Accreditation Phase

173.1.4 Phase IV: Continuous Monitoring Phase

173.2 Operational Element: Security Configuration Compliance Assessment

173.2.1 Automated Security Assessment Process

183.2.2 On-demand Security Assessment Process

193.2.3 Execution of On-demand Security Assessment on a Stand-Alone Computing Asset

203.2.4 Execution of Asset Discovery

203.3 Operational Element: Security Configuration Compliance Posture Reporting

203.3.1 Security Posture Reporting Process

233.4 Operational Element: Risk Management

233.4.1 Risk Management Process

243.5 Elemental Operation: Security Configuration Management and Change Control

243.5.1 Execution of Security Configuration Management Process

253.5.2 Change control process

27Appendix A: Acronyms

28Appendix B: References

List of Figures

7Figure 1: CONOPS for the Security Compliance Posture Monitoring and Reporting System (SCPMaRS)

10Figure 2: Contextual architecture of the Security Compliance Posture Monitoring and Reporting System (SCPMaRS)

15Figure 3: CONOPS for SCPMaRS in system life cycle

18Figure 4: Automated security assessment process

19Figure 5: On-demand security assessment process

21Figure 6: Security assessment reporting process

22Figure 7: Example security posture reports

23Figure 8: Risk assessment process

24Figure 9: Security configuration management process

25Figure 10: Change control process

List of Tables

Error! Bookmark not defined.Table 1: Modes of Information Operations

21Table 2: Example granularity of security posture information in reports

27Table 3: Acronyms List.

Document Change Control Sheet

Document Title: Concept of Operations for the Security Compliance Posture Monitoring and Reporting (SCPMaR) Solution

< This page has been intentionally left blank> 1 Introduction The purpose of this document is to provide a preliminary concept of operations (CONOPS) to demonstrate the required capabilities for the IRS. The operational concept for the Security Compliance Posture Monitoring and Reporting (SCPMaR) solution is designed to follow the IRS Enterprise Life Cycle (ELC), security Certification & Accreditation (C&A) life cycle and operational security practices. (Figure 1) In general, the IRS security operations are characterized in two types of practices:

· IT Application Development Security Practice. This practice is characterized by the system development life cycle (SDLC) activities between ELC MS1 and MS4B. The security program management offices (PMOs) from the IRS business domains, business units, MITS AD, and the Development, Integration, & Test Environment (DITE, MITS-27) are primarily responsible for:

· Protecting the computing assets within the development operations, and

· Developing the security configurations baseline for the business applications under SDLC.

· IT Operations Security Practice. This practice is characterized by the post-SDLC and daily IT operations for the business application systems and the IT infrastructure. The IT services organizations such as MITS EOPS, EUES, EN, and the business units IT services organizations within CC, CI, and SOI are primarily responsible for:

· Protecting the computing assets within the Current Production Environment (CPE), Enterprise Computing Centers (ECCs), and IRS Service Centers, and

· Performing the continuous monitoring of operating computing assets within the IT infrastructure.

Figure 1: CONOPS for the SCPMaR solution Per NIST SP 800-37, the Initial Phase of security C&A life cycle begins by defining the security category of the information system based on its system characteristics and the information protection needs. In the Certification Phase, a security test and evaluation (ST&E) is performed to describe and capture the potential residual risks. In the Accreditation Phase, the designated approving authorities (DAAs) from the major application (MA) and the General Support System (GSS) are to review the potential residual risks and make the decision for an “Authority to Operate” (ATO) or “Interim Authority to Operate” (IATO). Finally, the accredited system is then migrated into the operational environment where the operations begin the Continuous Monitoring Phase.

From the system functional perspective, the SCPMaR solution is designed to perform four of the following elemental operations: assessment, reporting, change control/baseline management, and risk management.

1.1 SCPMaR at a Glance

What is the SCPMaR? SCPMaR is a security awareness information system that provides IRS the capability to monitor, measure, and manage the security compliance of its implemented technical security controls.

How is the security compliance posture defined?

Security posture, as defined by Federal Information Processing Standard (FIPS) 200 and National Institute of Standards and Technology (NIST) SP 800-53, is the level of assurance that adequate technical security controls have been implemented to meet the information protection needs. The security posture metrics:

· Degree of assurance that the technical security controls and security configurations defined by IRS and NIST implemented.

· Level of assurance that security patches specified by IRS are implemented.

· Identification of IRS/ US-CERT-announced security vulnerabilities enumerated (e.g., SANS Top 20 and CVE) utilizing the Common Vulnerability Scoring System.

How are the security configuration baselines defined?

A security configuration baseline is a set of security configuration benchmarks with IRS accepted risks and approved patches.

A security configuration benchmark is a set of security configuration settings defined by the IRS. (The security configuration benchmarks are described using SCAP, originating from the NIST National Checklist Program.)

A Risk Based Decision (RBD) is the accepted difference between an approved security configuration benchmark and the actual, accepted security configuration of a system.

A non-conformance is a deviation from the accepted security configuration baseline and approved patches for the system.

How can IRS Stakeholders utilize the SCPMaR solution? The operational and functional requirements of SCPMaR are defined by an integrated project team (IPT) which consists of a spectrum of representatives from all the stakeholder organizations from the business units that own the information and information systems, the MITS organizations that provides IT services throughout the system life cycle. SCPMaR is designed to provide a set of four elemental operations: assessment, reporting, change control/baseline management, and risk management throughout the life cycle of a system.

Who will be the system owner for the SCPMaR solution? MITS Cybersecurity will be the system owner of SCPMaR. In addition, MITS Cybersecurity will continue as the organization that provides the security configuration policies (or benchmarks).

Who will be the service organization that maintains and operates the SCPMaR solution? The deployment architecture for SCPMaR is expected to be federated. While a majority of system components will be operated by MITS, organizations such as CI, CC, and SOI perform their own IT services; therefore part of the system components will be managed and operated by these business units.

1.2 Strategic Drivers and Values

The SCPMaR IPT has defined the following six key capabilities as the driver (or goal) for the SCPMaR project:

1. The solution shall provide the functional capability to monitor and measure the effectiveness of mandated security controls (i.e. security configuration benchmarks) on computing/internetworking assets, enterprise-wide, and in a timely manner.

2. The solution shall provide the functional capability to manage security configurations throughout the system life cycle (or security C&A life cycle) by assessing and reporting the level of compliance with the agency/US Government-specified technical security controls continuously.

3. The solution shall provide the functional capability to implement the standard protocols and technology (i.e. NIST SCAP) effectively, across the enterprise.

4. The solution shall provide the operational capability to automate the security compliance assessment and reporting processes to reduce the level of effort in coordination and execution, across the enterprise.

5. The solution shall provide the operational capability to facilitate the risk management process by verifying the information systems operate within the established security configuration baselines and identify risks at the appropriate level of abstraction.

6. The solution shall provide the operational capability to support the change and baseline control processes by assisting the authorized organizations to define and maintain security configuration baselines with risk commensurate deviations, throughout the system life cycle.

2 Solution Overview The SCPMaR “solution” is composed of “people, process, and technology”; i.e., the IRS information security stakeholders executing the security configuration management processes, supported by the SCPMaR systems.

Figure 2 illustrates the contextual relationships between people, process, and technology.

Figure 2: Contextual architecture of the SCPMaR solution People. Enterprise-wide, there are eighteen stakeholder organizations (six MITS service organizations and twelve mission-focused business units.) MITS is the primary IT services provider for IRS. MITS is functionally organized in the following sub-organizations: Cybersecurity, Enterprise Operations (EOps), End User Equipment & Services (EUES), Enterprise Networks (EN), Enterprise Services (ES), and Applications Development (AD). The business units include Agency-wide Shared Services (AWSS), Appeals, Chief Counsel (CC), Criminal Investigation (CI), Electronic Tax Administration (ETA), Human Capital Office (HCO), Large and Mid-size Business (LMSB), Research, Analysis, and Statistics (RAS), Small business/ Self-employed (SB/SE), Statistics of Income (SOI), Tax Exemption / Government Entities (TE/GE), and Wage and Investment (W&I).

Process. There are four elemental operations: assessment, reporting, change control/baseline management and risk management operations. These operations are divided into six principle processes: Security configuration deviation management process, Change control process, Automated security assessment process, On-demand security assessment process, Security assessment reporting process, and Risk management process.

Technology. The SCPMaR system shall provide the following six functional and operational capabilities:

Functional capabilities:

1. Monitor and measure the effectiveness of mandated security controls (i.e. security configuration benchmarks) on computing/internetworking assets, enterprise-wide, and in a timely manner.

2. Manage security configurations throughout the system life cycle (and security C&A life cycle) by assessing and reporting the level of compliance with the agency/US Government-specified technical security controls continuously.

3. Implement standard protocols and technology (i.e. NIST SCAP) effectively, across the enterprise.

Operational capabilities:

4. Automate the security compliance assessment and reporting processes to reduce the level of effort in coordination and execution, across the enterprise.

5. Facilitate the risk management process by verifying that information systems operate within the established security configuration baselines and identify risks at the appropriate level of abstraction.

6. Support the change and baseline control processes by assisting the authorized organization to define security configuration baselines with risk commensurate deviations.

In addition, the solution shall provide FISMA compliance reports in accordance with OMB M-07-19 and Federal Desktop Core Configuration (FDCC) compliance reports as defined in OMB-M-07-11 using the NIST-defined Security Content Automation Protocol (SCAP) format.

For interoperability with existing IRS IT investments, the solution shall be able to import or integrate data from existing IRS systems and tools including but not limited to:

· The solution shall provide the ability to import a list of identified vulnerabilities generated from ISS Internet Scanner (Version 7.x or most current release) and Nessus (Version 3.x or most current release).

· The solution shall provide the ability to import a list of required security patches specified by the IRS.

· The solution shall provide the ability to import a list of approved software specified in the IRS Enterprise Architecture (EA) Enterprise Standards Profile.

· The solution shall provide the ability to import a list of baseline IT hardware assets from the IRS Information Technology Asset Management System (ITAMS) (i.e., HP Peregrine Asset Management) and EOPS Master Server Database (MSDB) (i.e., Oracle RDBMS).

· The solution shall integrate with Microsoft Active Directory Service for user authentication.

· The solution shall integrate with Microsoft Active Directory to facilitate the management of Group Policy Objects (GPO).

· The solution shall integrate with the IRS Employee User Portal (EUP) (i.e., SiteMinder) for user authentication to web interfaces.

Profile of User Roles The following roles & responsibilities are summarized based on IRM 10.8.2 from the Enterprise Risk and Security Configuration Posture Monitor Project perspective...

Chief Information Security Officer (CISO) and Assistant Chief Information Officer (ACIO):

· Aware of information security risks of information systems within his/her area of responsibility.

· Coordinate with Designated Accrediting Authorities (DAAs) on security C&A reports and risk assessments.

· Conduct periodic security audits.

· Track Plan of Actions and Milestones (POA&M) weaknesses.

· Manage risk RBDs and ATO expiration dates.

Designated Accrediting Authority (DAA):

· Determine the security category of an information system based on the information sensitivity and the impact level (i.e. FIPS 199 and 200).

· Issue IATO, ATO, or deny ATO based on the Security Test and Evaluation (ST&E) results.

· Adjudicates non-conformance from the IRS approved baselines and makes determination on whether to accept RBD.

· Manage RBDs and ATO expiration dates.

Information System Owner (/ Business and Functional Unit Owner):

· Aware of information security risks of information systems within his/her area of responsibility.

· Track POA&M weakness.

Security PMO/ Information System Security Officers (ISSO):

· Identify and track POA&M weaknesses.

· Maintain awareness of information security risks of information systems within his/her area of responsibility.

· Coordinate with DAAs on C&A and risk assessments.

· Conduct periodic security audits.

· Track POA&M weaknesses.

· Determine the security category of an information system based on the information sensitivity and the impact level (i.e. FIPS 199 and 200).

Security Policy Working Group (SPWG) Member/ Cybersecurity Policy & Procedure Management:

· Determine security configurations’ (a.k.a. security configuration benchmarks) alignment to IRS security policies (e.g. IRM 10.8.10, IRM 10.8.20, IRM 10.8.32, and etc.)

· Review proposed RBDs and make recommendation to system owners.

Configuration Management (CM)/ Change Control Board (CCB) Member:

· Review change requests and assign change control actions.

Security Certification Agent/ C&A Analyst:

· Conduct ST&E.

· Capture and document non-conformance.

· Maintain awareness of information security risks of information systems within his/her area of responsibility.

Developer:

· Utilize the IRS approved security configuration benchmark as an initial baseline for development platform.

· Perform on-demand assessment on the development systems to document and record non-conformance parameters, or

· Perform remediation to ensure development platform’s alignment to the IRS approved security configuration baseline.

System Administrator:

· Configure the system configuration parameters in accordance with IRM security configuration policies.

· Monitor the security posture of information systems within their area of responsibility.

· Perform on-demand security configuration assesments.

2.1 Information Classification

In accordance to IRS security policy, the information processed, stored and transported by the SCPMaR solution is expected to be classified as “Official Use Only” (OUO).

2.2 Modes of Operations

The SCPMaR solution, as a component of the MITS IT security management infrastructure, it is expected to operate in System-High mode.

2.3 Security Category

In accordance to Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, the Security Categorization for SCPMaR is expected to be catagorized as SC = {(Confidentiality, Moderate), (Integrity, Moderate), (Availability, Low)}.

2.4 Operating Environment Description

The IRS IT computing infrastructure operates in a geographically diverse environment in multiple domains and includes:

· 120,000+ Windows XP desktop workstations and laptops

· 1,000+ Windows-based servers running Windows 2000 Server

· 3,000+ Windows-based servers running Windows 2003 (x-32 and x-64 bit platforms)

· 1,000+ Unix-based servers running Solaris 8, 9, and 10

· 300+ UNIX-based servers running Red Hat Enterprise Linux 4 and 5

· 100+ UNIX-based servers running HP-UX 11 and IBM AIX 5.2 IRS plans to begin migrating Windows servers to Windows Server 2008 by the end of 2009. Most of the servers are located in 3 geographically diverse enterprise computing centers (ECC) and 10 major campuses. The desktop workstations and laptops are mostly located in 700 Posts-of-Duty (POD) throughout U.S. and overseas.

3 Concept of Operations (CONOPS) The CONOPS for the SCPMaR solution is designed to follow the IRS Enterprise Life Cycle (ELC) and the C&A life cycle. (Figure 3)

3.1 Life Cycle Scenario: Security C&A Support

The SCPMaR solution shall provide the following key functions throughout the security C&A life cycle: 1) define the required technical security controls based on the security categories (i.e. FIPS 199); 2) support the ST&E by performing audits of baseline technical security controls; 3) facilitate the risk management processes by documenting weaknesses and recording RBDs and 4) perform continuous monitoring to determine the security posture for the computing assets and IT infrastructure.

Figure 3: CONOPS for SCPMaR in the system life cycle

3.1.1 Phase I: Initial Phase

Step 1:

Select and Implement an IRS-defined Security Configuration Benchmark

Security engineer (MITS Cybersecurity SE) describes information system (i.e., system characterization) and determines information protection needs (i.e., initial risk determination)

· Perform FIPS 199 security categorization.

· Identify potential information security flaws or weaknesses in an information system (i.e., potential vulnerability.)

· Identify the potential threat and likelihood of threat source to act on a vulnerability.

Security PMO (Business Unit or MITS AD) or ISSO (MITS Cybersecurity) working with the System administrator (MITS EOPS or EUES) performs:

· Security PMO (Business Unit or MITS AD) or ISSO (MITS Cybersecurity) selects the benchmark stored within the SCPMaR solution based on the security category and computing platform.

· System administrator (MITS EOPS or EUES) applies benchmark using SCPMaR solution development platform Refer: Operational Element: Security Configuration Baseline Management and Change Control (Section 3.5).

Step 2:

Create Baseline by Modifying Benchmarks to meet Development Security Needs Security PMO (Business Unit or MITS AD), or ISSO (MITS Cybersecurity) working with System administrator (MITS EOPS or EUES) creates or updates the security configuration settings and propose a security configuration baseline.

Refer: Operational. Element: Security Configuration Baseline Management and Change Control (Section 3.5).

System administrator (MITS EOPS or EUES) assesses the effectiveness of the implemented security configuration baseline.

Refer: Operational Element: Security Configuration Compliance Assessment (Section 3.2).

Security PMO (Business Unit or MITS AD), ISSO (MITS Cybersecurity) or System administrator (MITS EOPS or EUES) produces a security compliance posture report that validates the level of compliance with the approved baseline.

Refer: Operational Element: Security Compliance Posture Reporting (Section 3.3).

3.1.2 Phase II: Security Certification Phase

Step 3:

Security Test and Evaluation (ST&E)

Security PMO (Business Unit or MITS AD), ISSO (MITS Cybersecurity), or System administrator (MITS EOPS or EUES) assesses the level of compliance with the approved baseline.

Refer: Operational Element: Security Configuration Compliance Assessment (Section 3.2).

Security PMO (Business Unit or MITS AD), ISSO (MITS Cybersecurity) or C&A Analyst:

· Reports the level of compliance with the approved baseline.

· Identifies non-conformance Refer: Operational Element: Security Compliance Posture Reporting (Section 3.3).

Step 4:

Security Certification Agent (CA) or ISSO (MITS Cybersecurity) reviews the ST&E report and determines the acceptable residual risks.

· Review identified non-conformance.

· Submit recommendation to address RBD to the DAA.

Refer: Operational Element: Security Configuration Baseline Management and Change Control (Section 3.5).

3.1.3 Phase III: Security Accreditation Phase

Step 5:

Security Accreditation

Security Certification Agent (CA) or ISSO (MITS Cybersecurity) submits the proposed baseline to obtain approval (IATO/ ATO) from DAA.

Refer: Operational Element: Risk Management Process (Section 3.4)

DAA (MITS EOPS or EUES) reviews the residual risks and formally approves the baseline via ATO or IATO.

· If DAA requires changes to reduce risks, then go back to Step 2.

· If DAA approves the proposed baseline, then the baseline is established as the approved baseline within the SCPMaR solution.

Refer: Operational Element: Security Configuration Baseline Management and Change Control Process (Section 3.5).

3.1.4 Phase IV: Continuous Monitoring Phase

Step 6:

Continuous Monitoring

ISSO (MITS Cybersecurity) works with Operations manager (MITS EOPS or EUES) to plan the security compliance assessment schedule. The SCPMaR solution shall perform automated security compliance posture assessments periodically, enterprise-wide.

Refer: Operational Element: Security Compliance Assessment (Section 3.2) All security stakeholders (from MITS Cybersecurity, EOPS, EUES, ES, and Security PMOs) shall access the SCPMaR solution’s security compliance posture dashboard according to his/her area of responsibilities (AOR).

Refer: Operational Element: Security Compliance Posture Reporting (Section 3.3).

3.2 Operational Element: Security Configuration Compliance Assessment

The assessment of the IRS security posture shall be initiated in two ways: automated and on-demand. The automated security posture assessments are the periodic, scheduled activities. The on-demand security posture assessments are initiated by authorized personnel with necessary privilege to a pre-defined set of computing systems that are specific to his/her area of responsibilities (AOR).

The assessment of the IRS security posture consists of three types: security configuration, patch-level, and enumeration of vulnerabilities. The assessment of the security configuration shall be conducted based on an IRS approved baseline for a specific system. Each recorded weakness shall become a part of the assessment result record. The assessment of the patch-level shall be based on an IRS approved baseline. Each non-conformance found shall become a part of the assessment result record. The enumeration of vulnerabilities ingested from ISS Internet Scanner and Nessus shall be correlated to a specific computing system.

3.2.1 Automated Security Assessment Process

Figure 4 illustrates the automated periodic security assessment process. In a large enterprise, it is necessary for the SCPMaR solution to orchestrate the automated activities so that the potential vulnerabilities can be addressed through a comprehensive risk management and change control processes.

Figure 4: Automated security assessment process Step 1: Scheduling Automated Assessments

ISSO (MITS Cybersecurity) works with Operations manager (MITS EOPS or EUES) to schedule the automated security assessments based on the organization’s security awareness needs. The SCPMaR solution shall perform periodic security compliance posture assessments in accordance with this pre-determined schedule.

Step 2: Automated Assessments

The SCPMaR solution shall perform automated security assessments to all the computing platforms according to the asset portfolio information stored in the SCPMaR solution. Each security assessment shall be based on the assigned security configuration baseline.

Step 3: Collection and Storage of Assessment Results

The security assessment results are stored in the SCPMaR solution to support the reporting, change control and risk management processes.

3.2.2 On-demand Security Assessment Process

Figure 5 illustrates the on-demand security assessment process. During system development or C&A process, it is necessary to utilize this capability to assist in ST&E of a system.

Figure 5: On-demand security assessment process Step 1: Requesting an On-demand Assessment

Security Certification Agent (CA) or ISSO (MITS Cybersecurity) requests System administrator (MITS EOPS or EUES) to perform an on-demand security assessment on a specific computing asset. The SCPMaR solution shall provide role-based access control (RBAC) where only a specific set of users are allowed to perform on-demand security assessment on a production system. For example: authorized system administrator, security PMO, or security manager.

Step 2: On-demand Assessment After a specific computing asset has been identified, the System administrator (MITS EOPS or EUES) then performs the security compliance posture assessment using the SCPMaR solution based on the security configuration baseline associated to that computing asset.

Step 3: Collection and Storage of Assessment Results The security assessment results shall be stored within the SCPMaR solution to support the reporting, change control, and risk management processes.

3.2.3 Execution of On-demand Security Assessment on a Stand-Alone Computing Asset

For tracking the security compliance posture of computing assets that are not on the IRS network, the SCPMaR solution shall provide the authorized System administrator (MITS EOPS or EUES) a portable assessment capability to perform an on-demand security compliance posture assessment using an IRS defined security configuration baseline managed within the SCPMaR system. The security assessment result shall be imported into the SCPMaR system.

3.2.4 Execution of Asset Discovery

System administrator (MITS EOPS or EUES) shall use the SCPMaR solution to perform asset discovery and validate the baseline inventory stored within the SCPMaR solution.

For tracking the computing assets that are not on the IRS network, the SCPMaR solution shall provide System administrator (MITS EOPS or EUES) the ability to perform manual data entry of inventory information.

3.3 Operational Element: Security Configuration Compliance Posture Reporting

The reporting of the IRS security posture shall be based on a set of pre-defined roles, the roles are organized hierarchically based the end user’s AOR.

In general, there are three types of reports: Security Awareness Dashboards, IRM defined Compliance Reports, and FISMA Reports.

The Security Awareness Dashboards are the executive-level daily summary of the IRS security posture. The content of the dashboards shall be specific to the end user’s AOR and it shall contain a summary of the following attributes:

· Level of assurance that the IRS defined security controls and configurations have been properly implemented.

· Level of assurance that the IRS specified security patches have been implemented.

· Identification of IRS announced security vulnerabilities enumerated utilizing the NIST specified Common Vulnerability Scoring System (CVSS).

The Security Awareness Dashboards shall provide the authorized user the ability to perform drill-down to a specific computing system, vulnerability, and non-conformance.

The IRM defined Compliance Reports are the enterprise-level security assessment reports that indicate degree of compliance with baseline security controls.

The FISMA Reports are the inter-agency level security assessment reports that indicate degree of compliance with baseline security controls.

3.3.1 Security Posture Reporting Process

Figure 6 illustrates the automated security posture reporting process. Through role-based access control, the SCPMaR solution is to provide the necessary security compliance posture information according to end-users’ AOR for example:

· Awareness of security operations condition.

· Measure security effectiveness.

· % of compliance (enterprise-level with drill-down to GSS)

· # of missing patch (enterprise-level with drill-down to GSS)

· # of systems in compliance over a period of time (enterprise-level with drill-down to GSS)

· Awareness of security operations condition.

· Measure security effectiveness.

· % of compliance (enterprise-level with drill-down to GSS)

· # of missing patch (enterprise-level with drill-down to GSS)

· # of systems in compliance over a period of time (enterprise-level with drill-down to GSS)

· Awareness of security operations condition.

· Measure security effectiveness.

· % of compliance (GSS-level with drill-down to computer + network platforms)

· # of missing patch (GSS-level with drill-down to computer + network platforms)

· # of systems in compliance over a period of time (GSS-level with drill-down to computer + network platforms)

· Awareness of security operations condition.

· Demonstration of security effectiveness.

· Awareness of security events (computing + network platforms)

· Awareness of non-compliance (computing + network platforms)

· Awareness of patch required (computing + network platforms)

· Awareness of vulnerability (security deficencies) (computing + network platforms)

· % of compliance (GSS-level with drill-down to computer + network platforms)

· # of missing patch (GSS-level with drill-down to computer + network platforms)

· # of systems in compliance over a period of time (GSS-level with drill-down to computer + network platforms)

· Enumerate a detailed list of non-conformance and missing patches

· Awareness of security events (computing + network platforms)

· Awareness of non-compliance (computing + network platforms)

· Awareness of patch required (computing + network platforms)

· Awareness of vulnerability (security deficiencies) (computing + network platforms)

· % of compliance (System-level with drill-down to computer + network platforms)

· # of missing patch (System-level with drill-down to computer + network platforms)

· # of systems in compliance over a period of time (System-level with drill-down to computer + network platforms)

· Enumerate a detailed list of non-conformance and missing patches

Table 1: Example granularity of security posture information in reports

Figure 6: Security assessment reporting process Step 1: User authentication and authorization RBAC shall be executed throughout the SCPMaR solution. The SCPMaR solution shall utilize the IRS-defined user authentication mechanism (i.e., Microsoft Active Directory and/or CA SiteMinder for Web). The SCPMaR solution shall assign each authorized user to a specific role, and the permission assignment to each operation.

Step 2: Generate Security Compliance Posture Reports

The automated and/or on-demand reports shall be generated based on the assessment results that are stored in the SCPMaR solution.

Step 3: Review Security Compliance Posture Reports

Each set of security assessment reports can only be accessed based on the end-user’s role or job function. For example, ACIO’s have full access to all executive-level security assessment reports. DAAs shall have full access to GSS-level security assessment reports. ISSO (MITS Cybersecurity) or Security PMO (Business Unit or MITS AD) will only have access to the security assessment reports to assets that are in their AOR. Chief Council (CC) Security PMO will only see reports on the computing assets that are owned or operated by CC.

Figure 7 illustrates some examples that provide end-users with the security posture of their computing assets.

Figure 7: Example security posture reports

3.4 Operational Element: Risk Management

Risk management is where the DAA works with the system owners and TIGTA to determine and adjudicate the residual risks found in the security compliance posture assessment. The SCPMaR solution shall facilitate this risk management process and record RBDs as part of the security configuration baseline for a computing system.

3.4.1 Risk Management Process

Figure 8 illustrates the risk management process. The SCPMaR solution shall use the NIST specified CVSS to provide risk calculations to the stakeholders (i.e. DAA, system owner, and TIGTA) in determining the level of acceptable information security risks.

Figure 8: Risk assessment process Step 1: Adjudication of Risk

DAA from the operational organization authenticates into the SCPMaR solution. Based on the security compliance posture assessment results from the ST&E or the automated periodic assessments, the DAA works with ISSO, system owners (or TIGTA, if needed) to adjudicate the residual risks.

Step 2: Change Control and Configuration Management of Baseline After the appropriate level of risks have been accepted, the approved security configuration baseline is then checked-in to the SCPMaR solution.

3.5 Operational Element: Security Configuration Baseline Management and Change Control

After a security category has been determined, a security configuration benchmark is then selected and implemented using the SCPMaR solution to a set of development and test platforms. During the C&A process, weaknesses shall be captured and stored within the SCPMaR solution. This proposed security configuration baseline is then checked-in to the SCPMaR solution. Any security configuration changes to the baseline shall be managed through the change management process. The project management office (PMO) shall integrate these non-conformance as residual risks to be integrated in the project’s plan of action and milestones (POA&M).

3.5.1 Execution of Security Configuration Baseline Management Process

Figure 9 illustrates the security configuration baseline management process. In accordance with FISMA, it is necessary to provide adequate security controls commensurate with the risk and magnitude of harm. The SCPMaR solution shall facilitate the risk management process by providing the ability to record and associate weaknesses with a specific computing system.

Figure 9: Security configuration management process

Step 1: Select and Implement Benchmark

Security PMO (Business Unit or MITS AD) or ISSO (MITS Cybersecurity) working with System administrator (MITS EOPS or EUES) to implement the selected benchmarks using the SCPMaR solution. The authorized System administrator (MITS EOPS or EUES) authenticates into the SCPMaR solution. The authorized system administrator then implements the selected security configuration benchmark (e.g. Web server, e-mail server, database server, or IRS COE, etc.) using the SCPMaR solution. The security configuration benchmark will be provided in XCCDF and OVAL and originate from NIST or IRS as a part of the NIST National Checklist Program.

Step 2: Baseline Creation After the software development has been completed, the authorized Security PMO (Business Unit or MITS AD), ISSO (MITS Cybersecurity), or System administrator (MITS EOPS or EUES) shall utilize the SCPMaR solution to perform the security compliance posture assessment. (Section 3.2) The result shall be documented as a proposed security configuration baseline, with RBDs. As a part of the IRS C&A process, this new security configuration baseline is then submitted to the Security Policy Working Group (SPWG) (MITS Cybersecurity) or Security Certification Agent (CA) or ISSO (MITS Cybersecurity) for review and approval.

3.5.2 Change Control Process

Figure 10 illustrates the change control process in the life cycle of a security configuration baseline, where the application development organization initiates the change control process by submitting a request for change to the IRS Security Policy Working Group (SPWG) (MITS Cybersecurity) or an organizational Change Control Board (CCB). The requested change is then evaluated and adjudicated through the risk management process before the proposed security configuration baseline can be implemented.

Figure 10: Change control process

Step 1: Request Change The authorized Security PMO (Business Unit, MITS AD), ISSO (MITS Cybersecurity), or System administrator (MITS EOPS or EUES) submits a change request to IRS SPWG (MITS Cybersecurity) or an organizational CCB.

Step 2: Test and Assess Risk The authorized IRS SPWG (MITS Cybersecurity) or an organizational CCB evaluates the change request, assigns it to a test organization (i.e. MITS EOPS, EUES, or Cybersecurity) to verify the proposed new security configuration baseline, and a risk assessment organization (i.e. MITS Cybersecurity SE) to evaluate the risks. (Section 3.2)

Step 3: Go to Risk Management After the residual risks have been evaluated by the Security PMO (Business Unit, MITS AD), ISSO (MITS Cybersecurity), Operations manager (MITS EOPS or EUES), or System administrator (MITS EOPS or EUES), the new baseline is subjected to the Risk Management Process. (Section 3.4) Appendix A: Acronyms

Table 2: Acronyms List.

Appendix B: References

1. Clinger-Cohen Act of 1996 (a.k.a. Information Technology Management Reform Act –ITMRA) (40 United States Code 1452))

2. Federal Information Security Management Act of 2002 (FISMA) (Title III, 2002 E-Gov Act)

3. FIPS 140-2, Security Requirements for Cryptographic Modules, May 2001.

4. FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

5. FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006.

6. FY 2007 IT Security and Privacy Action Plan and Milestones, January 2007.

7. IRM 10.8.1, IRS Information Technology (IT) Security, Policy and Guidance, Version 2.9, December 16, 2006.

8. IRM 10.8.10, Basic UNIX Security Policy and Guidance, Version 21-5, October 26, 2006.

9. IRM 10.8.12, Security Patch Management, Version 1.1, October 25, 2005.

10. IRM 10.8.2, IRS Information Technology Security Roles and Responsibilities, Version 4.2, December 15, 2005.

11. IRM 10.8.20, Windows Security Standard, Draft, TBD.

12. IRM 10.8.22, Windows 2000/XP Security Standard, Version 5-4, July 11, 2006.

13. IRM 10.8.24, Windows Server 2003 Security Standard, Version 5-5, July 11, 2006.

14. IRS Cyber-Security Vision and Strategy for 2014, Version 0.9, July 2007.

15. IRS EOps Security Improvement Plan—Security Configuration Management: “Security Compliance Reporting Process” (SCM.2B), Version 1.0, June 29, 2007.

16. IRS Security Summit Presentation, October 2007.

17. NIST SP 800-18, Rev. 1 Guide for Developing Security Plans for Information Technology Systems, February 2006

18. NIST SP 800-30, Risk Management Guide for Information Technology Systems, January 2002.

19. NIST SP 800-53, Rev.2, Recommended Security Controls for Federal Information Systems, December 2007.

20. NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems, July 2008.

21. NIST SP 800-65 Integrating IT Security into the Capital Planning and Investment Control Process, January 2005.

22. OMB Circular A-130 Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources.

23. OMB Circular No. A-11 Preparation, Submission and Execution of the Budget, Part 2 Section 53—Information Technology and e-Government, and Part 7—Planning, Budgeting, Acquisition, and Management of Capital Assets.

24. OMB Memorandum for Chief Information Officers, Establishment of Windows XP and VISTA Virtual Machine and Procedures for Adopting the Federal Desktop Core Configurations, July 31, 2007.

25. OMB M-07-19, FY 2007 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, July 25, 2007.

26. OMB M-07-18, Ensuring New Acquisitions Include Common Security Configuration, June 1, 2007.

27. OMB Memorandum for Chief Information Officers, Top 10 Risks Impeding the Adequate Protection of Government Information, July 17, 2007.

28. OMB M-07-11, Implementation of Commonly Accepted Security Configuration for Windows Operating Systems, March 22, 2007.

29. OMB M-06-20 FY 2006 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, July 17, 2006.

30. TD 71-10 Department of the Treasury Security Manual, August 23, 1999.

31. TD 81-01 Treasury Information Technology (IT) Programs, April 13, 2000.

32. TD 85-01 Department of the Treasury Information Technology (IT) Security Program, February 13, 2003.

33. TD P 71-10 Department of the Treasury Security Manual, August 23, 1999.

34. TD P 85-01 Treasury Information Technology Security Program, November 3, 2006.

35. Treasury Enterprise Architecture Framework, Version 1, July 2000.

Monitor report and manage implemented security controls to maintain security posture

ISSOs

Security PMO tracks approved deviations and monitor risks

Project Initiation

Domain Architecture

Preliminary Design

Detailed Design

System Development

System Deployment

Functional Baseline

Allocated Baseline

Product Baseline

Operational Baseline

Operations

Maintenance

MS

A

B

Preliminary risk assessment and define information protection needs

FIPS

Security category

IRM security configuration benchmarks

Implement security configuration benchmarks

Verify designed security controls

Perform ST

E to validate implemented security controls and record residual risks

DAAs review negotiate and approve deviations

ELC Phases

ELC Baseline

Security

Activities

Security C

Life Cycle

Logical Design

Physical Design

IT Application Development Security Practice e g

MITS AD

DITE

Business Domains etc

IT Operations Security Practice e g

EOPS

EUES

etc

Security

Practices

Security C

Initial Phase

Certification Phase

Accreditation

Phase

Continuous Monitor

Phase

May 5, 2009

Page vi