System Security Plan

System Security Plan

Stephen D. Gantz , Daniel R. Philpott , in FISMA and the Risk Management Framework, 2013

Summary

The system security plan is the single most comprehensive source of security information related to an information system. It serves as the basis of system authorization decisions by authorizing officials and provides detailed information to support many processes and activities in the system development life cycle. This chapter described the process of developing a system security plan and the contents expected to be included in the plan, and the ways in which the system security plan supports key security management activities before and after system authorization. This chapter also explained the ways in which system security plans are affected by and used to support other activities in the system authorization process described in NIST's Risk Management Framework.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597496414000102

Preparing the System Security Plan

Laura P. Taylor , in FISMA Compliance Handbook, 2013

Abstract

The System Security Plan is the most important document in the Security Package. IT sums up the system description, system boundary, architecture, and security control in one document. All systems that are general support systems or major applications must have a System Security Plan. When describing system boundaries, keep in mind that your description should be inclusive of and should discuss the systems you described in your Hardware and Software Inventory. The system delineated by the boundary definition should be consistent with what comes under the purview of the system owner. In the System Security Plan, you describe how all security controls are implemented.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124058712000166

Preparing the System Security Plan

Laura Taylor , Matthew Shepherd Technical Editor , in FISMA Certification and Accreditation Handbook, 2007

Introduction

The System Security Plan is probably the most important document you will prepare for your C&A Package. If the evaluation team is pressed for time (which sometimes happens) and elects to scrutinize only one document in your entire C&A package, skimming through the others, it is likely that that the one document they will sift through with a fine-toothed comb will be the System Security Plan. Some federal agencies use a System Security Authorization Agreement (SSAA) in lieu of a System Security Plan. The SSAA historically has been used by agencies that make use of the DITSCAP C&A methodology.

The System Security Plan sums up the security requirements, architecture, and control mechanisms in one document. In the System Security Plan, you should also list pointers to the related C&A documents that are part of the same C&A package in your System Security Plan. For example, you can say, "Contingency Planning is described in the <System Name> Contingency Plan, Revision 3, April 7, 2006." Though you don't want to rewrite the other C&A documents in the System Security Plan, you will want to restate certain pieces of key information contained in other documents. For example, it is worth restating the C&A Level at which the C&A package is going to be submitted—the level that you calculated using the methodology described in Chapter 6.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749116750024X

Risk Management Framework Steps 3 & 4

Stephen D. Gantz , Daniel R. Philpott , in FISMA and the Risk Management Framework, 2013

Security Architecture Design

Following security control selection, the system security plan describes what controls and control enhancements will be implemented for the system. During security control implementation, system owners and functional and technical members of the project team determine how each control should be implemented and assign responsibility for all controls to personnel with appropriate skills and system knowledge to implement them. As noted above in the Roles and Responsibilities section, the nature of the work required to implement a control varies considerably across management, operational, and technical controls. Part of the process of designing the security architecture for the system is distinguishing among different types of controls and identifying the resources available within the organization to provide them. Architectural design considers the system and the functions and services it will perform in the context of the organization's enterprise architecture. This perspective helps identify existing business processes, services, technologies, and capabilities the system may be able to reuse and ensures that the system does not conflict with or duplicate functions or services already deployed in the organization [12]. Architecture design also typically produces detailed diagrams showing the different components making up the system and its operating environment, points of interconnection to other systems or environments, and the placement or integration of security controls. Any diagrams created during security control implementation may be added to the system description section of the system security plan. The security architecture indicates which security controls apply to different components of the system (recognizing that not all controls apply to all parts of each system) and clearly identifies common or hybrid controls allocated to the system [13]. With respect to the common controls identified in the system security plan, the security architecture design process analyzes the descriptions in common control documentation to either validate that the common controls satisfy relevant requirements for the information system or to determine if any of the controls are better suited to hybrid or system-specific implementation.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597496414000084

Information Governance and Risk Management

Timothy Virtue , Justin Rainey , in HCISPP Study Guide, 2015

Plan

Develop, review, and approve an overall information system security plan during the development/acquisition phase of the system development life cycle. The system owner and other appropriate stakeholders review the security plan to ensure it is complete and consistent, and satisfies the security requirements for the information system. If no changes are required, the plan is accepted and the system owner should be able to answer in the affirmative to the checkpoint questions in Figure 5.14.

Figure 5.14. NIST step 2 checkpoint.

Acceptance of the security plan represents an important milestone in both the risk management process and the system development life cycle. The stakeholder, by approving the security plan, agrees to the set of security controls proposed to meet the security requirements for the information system. This approval allows the risk management process to advance to the next step in the RMF (i.e., the implementation of the security controls). The approval of the security plan also establishes the level of effort required to successfully complete the remainder of the steps in the RMF and provides the basis of the security specification for the acquisition of the information system, subsystems, or components.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128020432000057

Continuous Monitoring

Stephen D. Gantz , Daniel R. Philpott , in FISMA and the Risk Management Framework, 2013

Selecting Security Controls for Continuous Monitoring

The process of selecting security controls and control enhancements for information systems, described in detail in Chapters 7 and 10 Chapter 7 Chapter 8 Chapter 9 Chapter 10 , coincides with initial development of the continuous monitoring strategy, including determining which controls will be monitored and the appropriate monitoring frequency [19]. Different organizations may apply different criteria when selecting security controls for monitoring, determining the type and level of monitoring activity to be performed, and prioritizing monitoring resources. Where the ISCM program provides monitoring capabilities shared across multiple systems, organizations can specify standard criteria to encourage consistent security control monitoring decisions and help ensure that resources allocated to monitoring activities reflect organizational priorities. NIST guidance emphasizes security control volatility—a measure of how frequently a control's implementation is likely to change—as well as control criticality to the organization's protection strategy and inclusion in the plan of action and milestones as key prioritization criteria for security control monitoring [20]. Identifying system and environment changes is a core task in security control monitoring, so controls more likely to change over time are also likely to demand closer monitoring attention. Security controls identified in the plan of action and milestones have known weaknesses or deficiencies that the system owner intends to remedy; in addition, some persistent weaknesses may remain if the system owner and authorizing official choose to accept the corresponding risk rather than commit resources to mitigate them. While unremediated weaknesses exist, systems expose vulnerabilities that increase the risk of exploitation, making monitoring for such controls a high priority. The priority associated with implemented security controls may also change as new threats and vulnerabilities emerge, whether discovered internally by the organization or brought to the organization's attention by vendor, industry, or governmental notifications such as the alerts issued by the United States Computer Emergency Readiness Team (US-CERT).

System owners document the monitoring strategy for selected controls in the system security plan and in the security assessment plan, where assessment methods often include tools, tests, or capabilities used in continuous monitoring. Depending on the scope of the information system continuous monitoring strategy, system owners may choose to document their monitoring strategies separately from the system security plan. NIST guidance specifies only that system owners should document their monitoring strategies, but given the dependencies between the ISCM strategy and key security management documents such as the system security plan, security assessment plan, and plan of action and milestones, system owners may find it more efficient to create and maintain a separate monitoring strategy document and incorporate its information by reference in other artifacts.

Tip

Although Special Publication 800-137 focuses more on organizational ISCM than information system-level tasks, NIST's Computer Security Division offers additional resources and guidance on continuous monitoring from organization, management, and information system perspectives, as well as tips and techniques and frequently asked questions [21].

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749641400014X

Advances in Software Engineering and Software Assurance

D. Shoemaker , ... N.R. Mead , in Advances in Computers, 2016

8.3 Summary

The controls selected or planned must be documented in the System Security Plan [67]. The combination of FIPS 200 and NIST Special Publication 800-53 requires a foundational level of security for all federal information and information systems [67]. The agency's risk assessment validates the security control set and determines if any additional controls are needed to protect agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, or the nation [68]. The resulting set of security controls establishes a level of "security due diligence" for the federal agency and its contractors.

There have been a number of attempts to enhance the response to the threat to the national well-being that is represented by cyberspace. Those attempts include the Cyber Security Act (2010), the International Cybercrime Reporting and Cooperation Act (2010), and the Protecting Cyberspace as a National Asset Act (2010). Nonetheless, FISMA requirements remain the primary Federal mandate for actual response to the issues and concerns that have been raised by the advance of Internet technology.

Although FISMA is still only applicable to systems in the federal sphere, its risk- and standard-best-practice-based approach has served as the basis for many other kinds of response to the growing number of threats raised by the growth of Internet technologies.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/S0065245816300298

Risk Management Framework Steps 5 & 6

Stephen D. Gantz , Daniel R. Philpott , in FISMA and the Risk Management Framework, 2013

Security Authorization Package

The security authorization package contains three core documents—the system security plan, security assessment report, and plan of action and milestones—and any additional supporting information required by the authorizing official. Each system owner or common control provider assembles these documents and other necessary information into the security authorization package and submits it to the appropriate authorizing official, a task depicted in Figure 9.2. The information in the security authorization package provides the basis for the system authorization decision, so the primary consideration for system owners or common control providers submitting authorization packages is ensuring the accuracy and completeness of the information provided to authorizing officials. For systems leveraging common controls or security controls implemented or provided by organizations external to the agency, the system owner must ensure that all common control providers or external providers furnish the security documentation needed by authorizing officials. The documents in the security authorization package represent the formal assertion by the system owner or common control provider that the security controls implemented for the system (including those planned for implementation within explicit timeframes as indicated in the plan of action and milestones) are effective and sufficient to provide adequate security. The authorizing official relies on the information in the security authorization package to validate the assertion of adequate security, determine the risk to the organization associated with operating the system, and decide if that risk is acceptable.

Figure 9.2. The Core Components of the Security Authorization Package Include the System Security Plan, Security Assessment Report, and Plan of Action and Milestones, All of Which are Carefully Evaluated by the Authorizing Official to Help Reach a Decision About the Level of Risk Associated with Operating the System [16]

Note

NIST guidance to agencies recommends the use of automated system authorization support tools to manage the information included in the security authorization package, provide an efficient mechanism for security information dissemination and oversight, and facilitate maintenance and updates of that information. There are many tools available to agencies that support system security management, authorization, and FISMA compliance and reporting activities, including government-furnished services, commercial off-the-shelf products, and open-source software. Examples include:

•

Cyber Security Assessment and Management (CSAM), a tool managed by the Department of Justice and available to other government agencies.

•

Trusted Integration Trusted Agent FISMA.

•

Telos Xacta IA Manager.

•

SecureInfo Risk Management Services.

•

Symantec Enterprise Security Manager for FISMA.

•

OpenFISMA, sponsored by Endeavor Systems and available in open-source and commercial versions.

When deployed for agency-wide use, tools such as these help ensure consistent execution of Risk Management Framework tasks and other security management activities and typically offer integrated monitoring and reporting capabilities to allow authorizing officials, risk managers, and security management personnel to track compliance with agency policies and federal requirements at individual information system and organizational levels.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597496414000096

FedRAMP primer

Matthew Metheny , in Federal Cloud Computing (Second Edition), 2017

Major Milestone Output

•

Security assessment package that includes the key documents used in making an authorization decision—the SSP, SAR, and POA&Ms.

•

Provisional ATO letter 55 that includes the risk determination and acceptance decision by the JAB for cloud service.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128097106000081

A Case Study for Cloud Service Providers

Matthew Metheny , in Federal Cloud Computing, 2013

Implement and Document Security Controls

Documenting security controls within the cloud service requires the CSP to describe how the security controls were implemented in the System Security Plan (SSP). In the previous section, security controls were allocated based on specific responsibilities (i.e., inherited by another organization, shared between organizations, or implemented by an organization). In the SSP, information system components will need to be described based on the authorization boundary. The SSP details how the implementations address each required security control and enhancement in the selected, tailored, and supplemented security control baseline, descriptions of roles and responsibilities, and expected behavior of individuals with system access [12].

In addition, some security controls may require developing support documentation. For example, Table 13.6 identifies some of the documents that would be implemented by the CSP for FedRAMP.

Table 13.6. SSP Supporting Documents [13]

Document Name Security Control Requirement
IT Contingency Plan a (including Business Impact Analysis b ) CP-2—Contingency Plan
The organization:
a.

Develops a contingency plan for the information system that:

–

Identifies essential missions and business functions and associated contingency requirements;

–

Provides recovery objectives, restoration priorities, and metrics003B

–

Addresses contingency roles, responsibilities, assigned individuals with contact information;

–

Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;

–

Addresses eventual, full information system restoration without deterioration of the security measures originally planned and implemented; and

–

Is reviewed and approved by designated officials within the organization;

b.

Distributes copies of the contingency plan to [Assignment: organization-defined list of key contingency personnel (identified by name and/or by role) and organizational elements];

c.

Coordinates contingency planning activities with incident handling activities;

d.

Reviews the contingency plan for the information system [Assignment: organization-defined frequency].
Configuration Management Plan c CM-9—Configuration Management Plan
The organization develops, documents, and implements a configuration management plan for the information system that:
a.

Addresses roles, responsibilities, and configuration management processes and procedures;

b.

Defines the configuration items for the information system and when in the system development life cycle the configuration items are placed under configuration management; and

c.

Establishes the means for identifying configuration items throughout the system development life cycle and a process for managing the configuration of the configuration items.
Incident Response Plan d IR-9—Incident Response Plan
The organization:
a.

Develops an incident response plan that:

–

Provides the organization with a roadmap for implementing its incident response capability;

–

Describes the structure and organization of the incident response capability;

–

Provides a high-level approach for how the incident response capability fits into the overall organization;

–

Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;

–

Defines reportable incidents;

–

Provides metrics for measuring the incident response capability within the organization;

–

Defines the resources and management support needed to effectively maintain and mature an incident response capability; and

–

Is reviewed and approved by designated officials within the organization;

b.

Distributes copies of the incident response plan to [Assignment: organization-defined list of incident response personnel (identified by name and/or by role) and organizational elements];

c.

Reviews the incident response plan [Assignment: organization-defined frequency];

d.

Revises the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing; and

e.

Communicates incident response plan changes to [Assignment: organization-defined list of incident response personnel (identified by name and/or by role) and organizational elements].
E-Authentication e IA-2—Identification and Authentication (Organizational Users)
The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).
IA-8—Identification and Authentication (Non-Organizational Users)
The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users).
Privacy Threshold Analysis and Privacy Impact Assessment f PL-5—Privacy Impact Assessment
The organization conducts a privacy impact assessment on the information system in accordance with OMB policy.
a
NIST Special Publication (SP) 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems contains sample Information System Contingency Plans for Low-Impact (A.1) and Moderate-Impact (A.2) systems. Available from: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
b
NIST Special Publication (SP) 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems contains sample Business Impact Analysis Template (Appendix B). Available from: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
c
NIST Special Publication (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems contains sample outline for a Security Configuration Management Plan (Appendix D). Available from: http://csrc.nist.gov/publications/nistpubs/800-128/sp800-128.pdf.
d
NIST Special Publication (SP) 800-61 Revision 2, Computer Security Incident Handling Guide contains a description of elements of the Incident Response Plan (Section 2.3.2—Plan Elements). Available from: http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf.
e
NIST Special Publication (SP) 800-63-1, Electronic Authentication Guide contains information on e-authentication. Available from: http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf. Additional information can be found at IDManagement.gov.
f
Office of Management and Budget (OMB) Memorandum 03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 provides guidance on conducting a privacy impact assessment (PIA). Available from: http://www.whitehouse.gov/omb/memoranda_m03-22.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497374000137