System Security Plans 101
•Download as PPTX, PDF•
2 likes•2,493 views
System Security Plans are part of the required documentation for certification and accreditation package. Documenting your SSP can be a daunting task, so how can you make it easy? This overview session covers; who is responsible for the SSP, plan contents, overview of implementation detail for selected controls, flexibility of the SSP, plan maintenance issues, and what a SSP is not
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to System Security Plans 101
Similar to System Security Plans 101 (20)
More from Donald E. Hester
More from Donald E. Hester (20)
Recently uploaded
Recently uploaded (20)
System Security Plans 101
- 2. • GCN, February 2007, Reported a pair of security experts say FISMA is fundamentally flawed. • “FISMA wasn’t written badly, but the measuring system they are using is broken. What we measure now is, ‘Do you have a plan?’ Not whether the plan actually improves security. Too often, the plans do not improve security” Maze & Associates © 2007
- 3. • Avoid the danger of turning your security plan into a bureaucratic ‘check the box’ • Should be – Single reference for what needs to be secured – Documents controls – Support oversight, planning and budget – Document compliance Maze & Associates © 2007
- 4. Plan Initiation Plan Development Plan Implementation Plan Maintenance Recertification or Retirement Maze & Associates © 2007
- 5. • System Owner, is responsible for the plan • Can delegate preparation of the plan • Cannot delegate responsibility • Should be familiar with the system • Multiple people will contribute • Procedures should be in place outlining who reviews the plans, keeps the plan current, and follows up on planned security controls. Maze & Associates © 2007
- 6. • System Description • Description of Controls • System Security Roles & Responsibilities • External Requirements • Information Categories • Interconnectivity with the system • Certification Level • Plan Information Maze & Associates © 2007
- 7. • Flexibility in determination of the system • Generally under the same management control & usually locally group systems • May contain multiple subsystems • System Security Plan will have diagrams showing the system boundary System 1 Subsystem A Subsystem B Subsystem C Maze & Associates © 2007
- 8. Maze & Associates © 2007
- 9. • Selection of baseline security controls is based on system categorization • For this system you would select Moderate controls from NIST SP 800-53 Rev. 1 (High watermark) Information Criteria Security Impact Confidentiality Low / Moderate / High Integrity Low / Moderate / High Availability Low / Moderate / High Based on: NIST SP 800-60 and FIPS Pub 199 Maze & Associates © 2007
- 10. • Control selection based on Risk Assessment • Fully describe the how the control is implemented • Document differences with subsystems • Compensating Controls • Common Controls • Hybrid Controls • Tailored Controls Maze & Associates © 2007
- 11. Implementation Detail: Subsystem 1 Control satisfied via the following: A configuration management system retrieves a baseline configuration from all network devices and reports changes via a version control system. The checklist for installation includes a requirement to register new devices in the version control system. The system compares deltas in configurations and notifies technical staff about changes. Subsystem 2 Control satisfied via the CIS benchmark documentation which records what has changed in the baseline. Center Code XXX performs vulnerability Scans on a regular basis. XXX reports changes system admin evaluates materiality. Maze & Associates © 2007
- 12. “Compensating security controls are the management, operational, or technical controls used by an agency in lieu of prescribed controls in the low, moderate, or high security control baselines, which provide equivalent or comparable protection for an information system.” Source: NIST SP 800-100 § 8.4.4 Maze & Associates © 2007
- 13. 1 • Select controls from 800-53 2 • Complete and convincing rationale 3 • Assess and formally accept risk Maze & Associates © 2007
- 14. 1 • Agency has developed on documented common controls 2 • Agency has assigned responsibility of the common control 3 • Systems owners should be made aware 4 • Expert in the common control consulted 5 • Agency or Center Common Control Maze & Associates © 2007
- 15. • Implementation Detail: • Common Control: Item (i) Control satisfied via NPR 2810.1A, Security of Information Technology, Chapter 19 – Identification and Authentication, and Chapter 20 – Logical Access Controls. Item(ii) defined by ITS-SOP- 0037, NASA Common Access Controls Procedures for IT Systems (when finalized). Maze & Associates © 2007
- 16. • A portion of the control is outside the control or scope of the system owner • For example physical security may be handled at the gate and building level by guard service, while access to the computer room is handled by system staff. • Document what is done by whom • Coordination between responsible parties Maze & Associates © 2007
- 17. PS-3 PERSONNEL SCREENING Control: The organization screens individuals requiring access to organizational information and information systems before authorizing access. Implementation Detail: Center Hybrid Control; see System Owner action(s) needed Control is satisfied via the following: Center Code XXX Actions: All Center Level access is managed by center code XXX. Center Code YYY Actions: Civil Servants and contractors are screened by Human Resources (Code YYY). System Owner Action: Access is not granted to users until screening by XXX and YYY. No screening beyond what is provided by Code XXX and YYY. Maze & Associates © 2007
- 18. • System security plans should clearly identify which security controls used scoping guidance and include a description of the type of considerations that were made. • Reasons for tailored controls – Assessment of risk – Organization-specific security requirements – Specific treat information – Cost-benefit analyses – Availability of compensating controls – Special circumstances Source: NIST SP 800-100 § 8.4.1 Maze & Associates © 2007
- 19. • PE-11 EMERGENCY POWER • Control: The organization provides a short- term uninterruptible power supply to facilitate an orderly shutdown of the information system in the event of a primary power source loss. • System consists of desktop computers Maze & Associates © 2007 Criteria Rating Confidentiality Moderate Availability Low Integrity Low
- 20. • Implementation Detail: • Control not implemented, applied scoping guidance per NIST SP 800-53 rev.1 pages 18-20. • Desktop systems do not need uninterruptible power supply. Removing this control does not affect the security-relevant information within the system. System rated moderate for confidentiality and low for availability, control addresses availability not confidentiality. Systems with low availability do not require uninterruptible power supplies. Maze & Associates © 2007
- 21. Plan Initiation Plan Development Plan Implementation Plan Maintenance Recertification or Retirement Maze & Associates © 2007
- 22. • Keep the plan up-to-date • Don’t wait until recertification to update the plan • Review of the plan should occur prior to any major change • It has to be a living document • May trigger a recertification Maze & Associates © 2007
- 23. • The System Security Plan is not proof of the existence of controls • Cross reference procedures do not duplicate them (Hyperlink and name and location of documentation) • It is not a security procedures manual • Plan should not be lengthy and unusable Maze & Associates © 2007
- 24. Donald E. Hester CISSP, CISA, CAP, MCT, MCSE Security, MCSA Security, MCDST, Security+, CTT+, MV Maze & Associates / San Diego City College Email: DonaldH@MazeAssociates.com https://www.linkedin.com/in/donaldehester
Editor's Notes
- System Security Plans are part of the required documentation for certification and accreditation package. Documenting your SSP can be a daunting task, so how can you make it easy? This overview session covers; who is responsible for the SSP, plan contents, overview of implementation detail for selected controls, flexibility of the SSP, plan maintenance issues, and what a SSP is not.
- The danger is the plan could be treated as ‘check box’ and not given proper place. SAN FRANCISCO — A pair of security experts, one of them a former federal chief information security officer, gave a harsh critique Tuesday of the Federal Information Security Management Act as a well-intentioned but fundamentally flawed tool. “A lot of your money is being thrown away,” Alan Paller, director of research for the SANS Institute, told an audience at the RSA IT security conference. The 2002 act mandates security planning for agencies, requiring a risk analysis of IT systems, and certification and accreditation of those systems. “FISMA wasn’t written badly, but the measuring system they are using is broken,” Paller said. “What we measure now is, ‘Do you have a plan?’ ” Not whether the plan actually improves security. Too often, the plans do not improve security, said Bruce Brody, vice president of information assurance at CACI International Inc. and formerly with the Veterans Affairs and Energy departments “Federal systems and networks are like Swiss cheese,” Brody said. “FISMA over five years has not helped us to be appreciably more secure.” The speakers described the risk analysis and C&A processes as paperwork drills that let agencies comply with the letter of the law without doing anything to improve actual security. Even so, many agencies routinely receive failing grades in the annual FISMA report cards handed out by Congress, and government as a whole has not risen above D. Brody said he received four Fs and one C during his term in government. Paller offered two broad fixes for the security challenge facing government. The first is to stop blaming the user for problems, and require that vendors ship well designed products that are securely configured by default. He also called for using “attack-based” metrics in measuring security compliance. These metrics include: How quickly penetrations of the system are identified The length of time it takes to deploy needed security patches The number of accounts remaining active after employees or consultants have left an agency Whether programming teams are including errors in code How quickly malicious code can be found on a system. Brody defined five things a CIO must know about his systems to ensure security: The boundaries and topologies of the interconnected enterprise The devices that are connected to the enterprise and the channels they use to connect to it The configuration of these devices Who is accessing these devices and whether that access is authorized What these users are doing on the system. “You can measure good security, but it’s not being measured today,” Brody said. Brody and Paller were hopeful that changes in FISMA could be made in the new Congress.
- Direct management control does not necessarily imply that there is no intervening management. NIST SP 800-100 sec. 8.4.1
- The tables also identify the security impact levels for confidentiality, integrity, and availability for each of the information types expressed as low, moderate, or high. The security impact levels are based on the potential impact definitions for each of the security objectives (i.e., confidentiality, integrity, and availability) discussed in NIST SP 800-60 and FIPS Pub 199. High Water Mark
- An agency has the flexibility to tailor the security control baseline in accordance with the terms and conditions set forth in the standard. Tailoring activities include (1) the application of scoping guidance, (2) the specification of compensating controls, and (3) the specification of agency-defined parameters in the security controls, where allowed. The system security plan should document all tailoring activities. NIST SP 800-100 sec. 8.4.2 System security plans should clearly identify which security controls used scoping guidance and include a description of the type of considerations that were made. NIST SP 800-100 sec. 8.4.3 The application of scoping guidance must be reviewed and approved by the authorizing official for the information system. NIST SP 800-100 sec. 8.4.3
- Once the information system security plan is accredited, it is important to periodically assess the plan; review any change in system status, functionality, design, etc.; and ensure that the plan continues to reflect the correct information about the system. This documentation and its accuracy are imperative for system recertification and reaccreditation activity. All plans should be reviewed and updated, if appropriate, at least annually. Some items to include in the review are: Change in information system owner; Change in information security representative; Major change in system architecture; Change in system status; Additions/deletions of system interconnections; Change in system scope; and Change in authorizing official. NIST SP 800-100 Sec. 8.7
- Procedures should be in SOP or Rules of Behavior (external document) It should be a summary The plan should be brief and useable Consider hyperlinks to external documents