System Security Plan (SSP) Training

1. System Security Plan (SSP) Training • Conducted by • Centers for Medicare & Medicaid Services • November 4 - 7, 2002

2. Faculty • List instructors contact information

3. Risk Assessment (RA) Methodology • Describes steps to produce IS RA Report • The Information Security Risk Assessment process is presented as the following three phases: • System Documentation Phase • Risk Determination Phase • Safeguard Determination Phase

4. System Documentation Phase1.1 System Identification

5. System Documentation Phase1.1 System Identification (con’t)

6. System Documentation Phase1.1 System Identification (con’t)

7. System Documentation Phase1.1 System Identification (con’t) 1.2 Asset Identification 1.2.1 System Environment and Special Considerations 1.2.2 System Interconnection/Information Sharing 1.3 System Security Level

8. Risk Determination Phase • Identify potential dangers to information and systems (threats). • Identify the system weakness that could be exploited (vulnerabilities) associated to generate the threat/vulnerability pair. • Identify existing controls to reduce the risk of the threat to exploit the vulnerability. • Determine the likelihood of occurrence for a threat exploiting a related vulnerability given the existing controls. • Determine the severity of impact on the system by an exploited vulnerability. • Determine the risk level for a threat/vulnerability pair given the existing controls. This six step process for Risk Determination is conducted for each identified threat/vulnerability pair.

9. Risk Determination Phase (con’t)Risk Determination Table

10. Risk Determination Phase (con’t)Likelihood of Occurrence Levels

11. Risk Determination Phase (con’t)Impact Severity Levels

12. Risk Determination Phase (con’t)Risk Levels Table

13. Safeguard Determination Phase(4-steps) • Identify the controls/safeguards to reduce the risk level of an identified threat/vulnerability pair, if the risk level is moderate or high. • Determine the residual likelihood of occurrence of the threat if the recommended safeguard is implemented. • Determine the residual impact severity of the exploited vulnerability once the recommended safeguard is implemented. • Determine the residual risk level for the system.

14. Safeguard Determination PhaseSafeguard Determination Phase Table • Use Table 5 to summarize the analysis performed during the Safeguard Determination Phase. • Use the item numbers created for Table 1 as reference in Table 5 to correlate the analysis summarized in both tables to the same threat/vulnerability pair and associated risk level.

15. Risk Assessment Process Flow

16. RA Methodology Questions ?

17. Course Objectives • Understand • SSP methodology Version 3.0 (DRAFT) • Certification & Documentation Requirements for SSPs • SSPs within the Information Systems Security Program

18. Legal Requirements • Computer Security Act of 1987 • OMB A-130, Appendix III • Government Information Systems Reform Act (GISRA) of 2000 • Contractual

19. CMS Requirements • CMS SSP Methodology Version 3.0 (DRAFT) • CMS Risk Assessment (RA) Methodology Version 1.1

20. CMS SSP Architecture • 3-Tier Architecture CMS Systems • Master • General Support System (GSS) • Major Application (MA) SSP Methodology Section 1.2

21. General Support Systems • Defined elements of the infrastructure that provide support for a variety of users and/or applications under the same direct management control • Normally includes hardware, software, information, data, applications, communication, facilities, and people • Users may be from the same or different organizations • Physical platform and infrastructure with environmental software SSP Methodology Section 1.4.1

22. Major Applications • Systems, usually software applications, that support clearly defined business function for which there are readily identifiable security considerations and needs • Application code • Examples include: MCS, FISS, CWF SSP Methodology Section 1.4.2

23. BP SSP Documentation • Tab A: Certification Form • Tab B: Accreditation Form • Tab C: System Security Plan with Appendices & Attachments • Tab D: Summaries and References SSP Methodology Section 4.3

24. BP SSP Formal Submission • Original Certification Form with all signatures must be forwarded to: • [address] • SSP with a copy of the Certification Form must be filed in your Security Profile. SSP Methodology Section 4.3

25. Reviewing and Updating an SSP • Security may degrade over time as technology changes • Changes occur to authorizing legislation or requirements • People and procedures change SSP Methodology Section 4.5

26. Certification Acceptance of the security risk by the system owner • Requirement for all CMS systems • Based on technical evaluation of a system to see how well it meets security requirements • System Owners/Manager, ISSO/SSO, and System Maintainer/Manager must sign the certification form SSP Methodology Section 4.6

27. Re-Certification • Major system modification • Change in security profile • Serious security violation occurs • Changes to threat environment • Every year • Expiration of Certification SSP Methodology Section 4.6

28. Accepts the risk of the system as it impacts the rest of the agency as certified by the system owner Accreditation • CMS Internal Systems - formal accreditation by CIO or Sr. Systems Security Advisor (SSA) • Must authorize in writing the use of each system based on the SSP documentation, certification and the level of risk SSP Methodology Section 4.7

29. BP SSP Development Hints • The SSP is not: • a future planning document • an opportunity to educate the reader on security terminology, controls, best practices, etc. • a document to restate the CMS views on SSP methodology • The SSP is: • a document that describes the current operation • states what is and what is not in place, with any rational or compensating measures for what is not in place • Does not need to be developed from scratch

30. SSP Development Hints • Refer to/use existing system documentation • Must contain high-level summary of technical information about the system, its security requirements, and the controls implemented to provide protection against its vulnerabilities • Where possible provide references to policy/procedures, responsible component, and how it can be reviewed • Must be dated to allow ease of tracking modifications and approvals • Use a 3-ring binder for certified SSP • Maintain a history of all documentation and sign-offs

31. Questions ?

32. System Security Plan Sections An Executive Summary is OPTIONAL. If included provide a summary of each of the first four sections of the SSP Section 1: System Identification Section 2: Management Controls Section 3: Operational Controls Section 4: Technical Controls

33. Section 1: System Identification 1.1 System Name/Title 1.2 Responsible Organization 1.3 Information Contact(s) 1.4 Assignment of Security Responsibility 1.5 System Operational Status 1.6 General Description / Purpose

34. 1.1 System Name/Title • Official name and title of the system, including acronym • (example:) Fiscal Intermediary Standard System (FISS) • SOR # • Financial Management Investment Board(FMIB) N/A • Web Support Team (WST) # N/A

35. 1.2 Responsible Organization • Name of Organization, address, city, state, zip, contract number, contractor name (if applicable)

36. 1.3 Information Contact(s) • Title, organization, address, city, state, zip, e-mail address, and phone number for: • SSP Author • System Owner/Manager • System Maintainer/Manager • Business Owner/Manager

37. 1.4 Assignment of Security Responsibility • Title, organization, address, city, state, zip, email address, and phone number for: • Individual(s) responsible for security from BP • Component Information System Security Officer/System Security Officer (ISSO/SSO) • Emergency contact information (name and phone number of different person for backup) • NOTE - This section must contain 4 different individuals

38. 1.5 System Operational Status • New • Operational • Undergoing a major modification

39. 1.6 General Description / Purpose • New “check one only” block for CMS On-site systems, CMS off-site system or External Business Partners (Medicare Contractors) • Brief description (1-3 paragraphs) on the purpose of the system and the organizational processes supported (include major inputs/outputs, users and major business functions performed) • If GSS, include all applications supported, including functions and information processed

40. 1.6.1 System Environment and Special Considerations • Brief (1-3 paragraphs) general description of the technical system describing the flow of data and processes through the infrastructure covered by the SSP. • Describe environmental factors that raise special security concerns • Document the physical location of the system • Provide a network diagram or schematic to help identify, define, and clarify the system boundaries

41. 1.6.2 System Interconnection / Information Sharing • Describe any system interconnections and/or information sharing(inputs and outputs) outside the scope of this plan • Include information on the authorization for connection to other systems or the sharing of information • Written management authorization must be obtained prior to connection • Document any written management authorizations (MOA/MOU or Data Exchange Agreement)

42. 1.6.2 System Interconnection / Information Sharing (cont’d) • For GSSs describe various components and sub-networks connections and /or interconnections to LAN or WAN • For MAs provide description of the major application and sub-applications along with other software interdependencies

43. 1.6.3 Applicable Laws or Regulations • List the laws and regulations not already listed in the CMS Master Plan • Any laws or regulations that establish system specific requirements for confidentiality, integrity, availability, audit ability, and accountability of information in the system

44. 1.6.4 General Description of Information Security Level • Appendix B, SSP Methodology • Information Security Levels Table • Information Security Levels by Information Categories • Information Owner (CMS) must define the Information Security Level • Claims processing systems have a Information Security Level of …

45. Section 1 Questions ?

46. 2.0 Management Controls Management controls focus on the management of the computer security system and the management of risk for a system 2.1 Risk Assessment and Risk Management 2.2 Review of Security Controls 2.3 Rules of Behavior 2.4 Planning for Security in the Life Cycle

47. 2.1 Risk Assessment and Risk Management • Attach the risk assessment to the SSP and provide a summary in this section including: • Value of the system or application (ie. assets) ?? • Threats • Vulnerabilities • Effectiveness of current or proposed safeguards • Describe the methods used to assess the nature and level of risk to the GSS or MA • Identify the risk assessment methodology used • Complete chart in Section 2.1 of SSP

48. Sample RA Charts for 2.1

49. 2.2 Review of Security Controls • Summarize any/all security evaluation conducted within the last 12 months on the system (e.g.SAS-70, GAO, IG, Internal Revenue Service, Self Assessments, CAST,audits) for each review • Who performed the review • When the review was performed • The findings and actions taken as a result of the review • Where the final report is located and who to contact for review of the final report

50. 2.3 Rules of Behavior • Provide summary of ROB, reference policy and how it can be reviewed • Describe and document the system specific rules of behavior or “code of conduct” of users of the GSS or MA • Must include the consequences of non-compliance • Must clearly state the exact behavior expected of each person • Include appropriate limits on interconnections to other systems • Cover such matters as work at home, dial-in access, connection to the Internet, the assignment and limitation of system privileges