790 likes | 1.12k Views
System Security Plan (SSP) Training. Conducted by Centers for Medicare & Medicaid Services November 4 - 7, 2002. Faculty. List instructors contact information. Risk Assessment (RA) Methodology. Describes steps to produce IS RA Report
E N D
System Security Plan (SSP) Training • Conducted by • Centers for Medicare & Medicaid Services • November 4 - 7, 2002
Faculty • List instructors contact information
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
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
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.
Risk Determination Phase (con’t)Likelihood of Occurrence Levels
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.
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.
RA Methodology Questions ?
Course Objectives • Understand • SSP methodology Version 3.0 (DRAFT) • Certification & Documentation Requirements for SSPs • SSPs within the Information Systems Security Program
Legal Requirements • Computer Security Act of 1987 • OMB A-130, Appendix III • Government Information Systems Reform Act (GISRA) of 2000 • Contractual
CMS Requirements • CMS SSP Methodology Version 3.0 (DRAFT) • CMS Risk Assessment (RA) Methodology Version 1.1
CMS SSP Architecture • 3-Tier Architecture CMS Systems • Master • General Support System (GSS) • Major Application (MA) SSP Methodology Section 1.2
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
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
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
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
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
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
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
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
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
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
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
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
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
1.2 Responsible Organization • Name of Organization, address, city, state, zip, contract number, contractor name (if applicable)
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
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
1.5 System Operational Status • New • Operational • Undergoing a major modification
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
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
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)
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
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
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 …
Section 1 Questions ?
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
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
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
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