Transcript Tenacity Solutions Incorporated

Tenacity Solutions Incorporated
David Comings, Ph.D.
Risk Management Framework
- Applied to Cross-Domain Solutions -
2
Introductions & Objectives (Agenda)
• Instructor –
• Who Am I?
• Background
• Objectives (Agenda)
• RMF Overview & Application to Cross-Domain Solutions
3
Presentation Scope
• High-level overview of the Risk Management Framework (RMF) in
a Cross-Domain Environment
• Introduces the 6-steps of the RMF
• Documents associated with each step
• Illustrative example of initial steps in the process
• NOT a comprehensive course in the RMF
•Tenacity Solutions Offerings
• 3-day course on RMF; updated as documents / policies are
released
• Consulting services to assist companies and organizations
navigating the new C&A process as well as Cross-Domain
Solutions Engineering Support
4
Risk Management Framework – 6 Steps
NIST 800-53A /
NIST 800-37 / NIST800-30
Continuously track changes
to information system that
may affect security controls
and reassess control
effectiveness
CNSSI 1253 (1199)
Categorization & Initial Tailoring Guidance,
as well as NSS Community agreed upon
“defined variables”
NIST SP 800-53 / CNSSI 1253
Select baseline security controls;
apply tailoring guidance and
supplement controls as needed
based on risk Assessment.
NIST 800-39 / NIST 800-37
/ NIST 800-30
Determine risk to
organizational operations,
assets, individuals, other
organizations, and the
Nation; if acceptable,
authorize operation.
NIST SP 800-53A / NIST 800-37
Determine security control effectiveness (i.e., controls
implemented correctly, operating as intended, meeting
security requirements for information system).
NIST 800-37
Implement security controls within enterprise
architecture using sound systems engineering
practices; apply security configuration settings.
5
RMF Step 1 - Categorize
• Used to identify an information system and its assets
• Critical step/phase in the Risk Management Framework
• Affects ALL other steps in the RMF from selection of security
controls to implementation, assessment, authorization, and monitoring
• Categorization process should be (for it to be effective);
• An organization-wide activity
• Ensures individual systems are categorized at appropriate impact levels
based on organizational objectives (missions)
• Incorporated into the organizations enterprise architecture
• Potentially an extensive exercise initially for organizations
6
RMF Step 1 – Categorize (cont.)
• Initial Stakeholder Meeting (key stakeholders for information
system)
• Chief Information Officer (CIO)
• Senior Agency Information Security Officer (SAISO)
• Authorizing Official/Designated Authorizing Official
• CDSO Representative
• Risk Executive
• Information System Owner
• ISSO/ISSE
• User Representatives
• Independent Evaluation Element
7
RMF Step 1 – Categorize (cont.)
• Unique Identifier
• Information Flows
• System Owner/Contact Information
• Governing Organization
• Organizational Mission(s)  Codified in
US Law
• Location of system/Physical
Environment
• System Users (Org affiliation, Access
rights)
• Purpose, Function, Capabilities
• System Operation (Gov’t or contractor
owned/operated)
• Types of information to be processed,
stored or transmitted
• Interconnection of systems
• Security Category of the system
• Security Authorization/Termination
dates
• Boundary of the system
• Security Authorization Process Roles
• Architectural description/Network
Topology
• Acquisition/SDLC status within
organization
• Hardware/Firmware
• Other relevant Information…
8
RMF Step 1 – Categorize (cont.)
• Stakeholder Meeting Input;
• Mission / Business Case
•Transfer Files Low-to-High, support all-source Intelligence Analysis,
primary information source
• System Description
• Location and physical requirements
• IC Agency HQS
• Intended users
• Senders/Recipients, cleared to access data transferred
• Information types being stored, transmitted, and/or processed by the
system
• Image/graphic files, text files, Microsoft Office, .pdf
9
RMF Step 1 – Categorize (cont.)
• Stakeholder Meeting Input;
•Requirements listing (as complete as possible);
• Hardware/Software
• Sun Hardware, One-Way Fiber, Solaris 10, Apache Web Server
Front-end (direct interface to users)
• Interconnection with other systems and/or enterprises
• Unclass-to-TS
• System operation and maintenance
• Will be performed by cleared personnel at IC Agency HQ
• Impact Levels;
• Confidentiality = Mod
• Integrity = Mod
• Availability = Mod
10
RMF Step 2 - Select
• Select Security Controls based on Impact Level selections in RMF
Step 1 (for C – I – A);
• Impact Levels; Conf-Mod, Int-Mod, Avail-Mod
• Baseline Security Controls selected from appropriate tables (CNSSI 1253)
• Tailor Baseline Security Control; insertion/deletion of controls
permitted (document all insertions/deletions)
11
RMF Step 2 – Select (cont.)
• Supplementation/Tailor Security Controls
• Initial baseline [prior to tailoring] = 355 controls/enhancements
• Deselect or add controls/enhancements based on system
characteristics and capabilities, risk data, mission needs, etc.
Reminder: Common and/or inherited controls relevant to this system should be
evaluated and compared against the baseline
• Coordinate supplement/tailoring results with Authorizing Official
and other stakeholders to maintain agreements
• Tailor controls based on environmental needs, local/federated
enterprise requirements, or common/inherited controls provided
12
RMF Step 2 – Select (cont.)
• Results from Selection and Tailoring
• Confirm that the control set is complete
• Update risk assessment documentation as needed
• Required Essential Information (REI) must be updated on an
iterative basis throughout the entire C&A process
Goal: Select the minimum number of controls necessary to adequately
protect the system and information
Tailored Baseline in this example = 299* controls/ enhancements
(Common Controls further reduce this overall number)
13
RMF Step 3 - Implement
• Implement the security controls as documented and specified in the
SSP
• NIST SP 800-37 calls for best practices to be used*
• Document security control implementation in the SSP
• Functional control of implementation to include;
• Inputs
• Expected behavior
• Outputs
• NOTE: Additional “implementation guidance” expected
14
RMF Step 3 – Implement (cont.)
• Security Controls Baseline is
provided to the system developer
• Security is built in and
documented, including all
necessary security settings
• Engineering documentation
reflects how and where in the
system each relevant security
control has been implemented
• Information System Security
Engineer (ISSE) participation is
key in this step
15
RMF Step 3 – Implement (cont.)
• Developer and Stakeholder Activities
• Developer
• Provides system architecture
and software design
• Identifies all necessary network connections
• Provides assurance of the integrity of all
Integrated Components
• Stakeholder
• Conduct initial certification analysis
• Forward design revisions and certification
analyses to developer throughout system
development
• Conduct System Test Readiness Review
• If Fail, continue to revise and reanalyze
• If Pass, proceed to RMF Step 4
16
RMF Step 4 - Assess
• Identify individuals that will be performing the assessment
• Qualifications & Independence (priorities!)
• Develop plan to assess the security controls for the system
• Reference assessment guidance contained in NIST SP 800-53A
•Assessment Requirements
• Security Assessment Plan
• Calls out objective for the security assessment
• Should be reviewed and approved by the AO/DAO (or designated rep)
• Ensures scope and controls to be assessed are correct
• Supporting materials for assessment
• Records, artifacts, test materials
• Reuse of previous security assessments (as applicable) are highly
recommended
17
RMF Step 4 – Assess (cont.)
• Factors in Assessing an Information System
• Which security controls/enhancements are required; optimal location(s) for
evaluation of controls/enhancements
• How to tailor assessment procedures as required
• Environmental factors or time constraints
• Developing additional assessment procedures as required
• To address emerging requirements or technology
• Optimizing assessment procedures
18
RMF Step 5 - Authorize
• Authorizing the system to operate
• Authorization package submitted to the AO/DAO by information system
owner, at a minimum, contains;
• System Security Plan
• Security Assessment Report*
• Plan of Actions & Milestones
• Authorization decision conveyed to information system owner
• NOTE: It is critical that ANY/ALL steps, actions, and activities taken to verify
compliance or non-compliance with controls and control enhancements be fully
documented (basis for building trust and fostering reciprocity amongst
organizations!)
19
RMF Step 6 – Monitor
• Effective security programs should include comprehensive
Continuous Monitoring
• Continuous Monitoring is an ongoing, dynamic activity that occurs
throughout the O&M stage (operational life) of the SDLC
• Used to maintain security authorization of a systems or systems
• Not just an annual event
• Provides near real-time status of a systems security state and risk posture (for
an organization)
• System specific plan should be created during the early steps of the RMF
20
?? Questions ??
21
• Contact Information
• David Comings, PhD
• [email protected]
22
Backup Slides
23
C&A Transformation Effort
Background & History
24
The Global Threat is Real
“Information Security is not just a paperwork drill. . . There are
dangerous adversaries in cyberspace capable of launching serious
attacks on our information systems that can result in severe or
catastrophic damage to the national security systems information
infrastructure and ultimately threaten our economic and national
security.”
- Dr. Ron Ross, Computer Scientist
National Institutes of Standards & Technology
25
U.S. IC Infrastructure
“National Security systems and assets, whether physical or virtual, are
extremely vital to the United States, such that the incapacity or
destruction of such systems and assets would have a debilitating
impact on security, national economic security, national public health
and safety, or any combination of those matters.”
− USA Patriot Act (P.L. 107-56)
26
C&A Transformation Effort
• Officially began in June 2006 with a “community wide” forum
• DNI CIO, DoD CIO, NIST
• Over 600 attendees/participants (physical)*
• Mini-Tiger Teams formed (Red, Gold, Green)
• Common Theme
• Lack of Common Standards (and Terminology)
• Lack of Reciprocity
• “Too Much” Documentation
• C&A Process “too long”
• Output  Seven (7) C&A Transformation Goals
27
Seven (7) Transformation Goals
1) Define a common set of impact levels and adopt and apply them
across the Intelligence Community (IC) and the Department of
Defense (DoD). Organizations will no longer use different levels
with different names based on different criteria.
2) Adopt reciprocity as the norm, enabling organizations to accept
the approvals by others without retesting or reviewing
3) Define, document, and adopt common security controls, using
NIST SP 800-53 as a baseline
28
Seven (7) Transformation Goals (cont.)
4) Adopt a common lexicon, using CNSSI Instruction 4009 as a
baseline, thereby providing DoD and IC a common language and
common understanding.
5) Institute a Senior Risk Executive function, which bases decisions
on an “enterprise” view of risk considering all factors, including
Mission, IT, Budget, and Security.
6) Incorporate Information Assurance (IA) into Enterprise
Architectures and deliver IA as common enterprise services across
the IC and DoD.
29
Seven (7) Transformation Goals (cont.)
7) Enable a common process that incorporates security within the
lifecycle processes and eliminates security-specific processes.
The common processes will be adaptable to various development
environments.
30
C&A Transformation & the 500-Day Plan
• Became part of the DNI’s 500-Day Plan to “Modernize Business
Processes”
• Issue: Multiple, disparate and inconsistently applied IT processes associated
with C&A related activities throughout the National Security Community
• Near Term Goal: Establish a streamlined, common and shared process for the
Intelligence Community
• Long Term Goal: Establish a standardized Risk Management approach to
Certification & Accreditation throughout the Federal Government
31
C&A Transformation Partnership
• Effort is a convergence of National Security and non-National
Security approaches integrated with current activities supported by;
• Directorate of National Intelligence / Intelligence Community
• Department of Defense
• Committee on National Security Systems (CNSS)
• Approval, Distribution, & Stewardship of NSS Policies & Procedures
• National Institute of Standards and Technology (NIST)
• Incorporating NSS required content into NIST SPs
• Enhancing existing Federal Standards originally designed for use by the
non-National Security Community (ex. NIST SPs 800-37, 800-53/A)
32
C&A Transformation Partnership (cont.)
• Effort is a convergence of National Security and non-National
Security approaches integrated with current activities supported by;
• OMB Information Systems Security Line of Business (ISS LOB)
• ISS LOB for C&A is charged with streamlining and reducing the cost of
C&A related activities for the Federal Govt
• Unified Cross Domain Management Office (UCDMO)
• The UCDMO is charged with streamlining and reducing the duplication
of cross-domain solutions in both the IC & the DoD
33
Unifying the C&A Process
• DNI, DoD, NIST, and the CNSS are working together on the effort
• Certification & Accreditation is now part of the Risk Management
Framework (RMF)
• Ensures that security is built into the System Development Life Cycle (SDLC)
• Captured in both Civil and National Security related documentation
• DNI and DoD CIO Reciprocity & Re-Use Memorandum
• Allows DoD and IC entities to accept each others C&A documentation
• Reduces needless duplication of effort (ex. formatting, doc conversion)
• Supports mission success by emphasizing content vice format in making
security related decisions
34
Breaking Down ICD 503
35
DNI Approach to Policy & Standards
• Established ICD 503 and will continue to develop Intelligence
Community Standards (ICS) as appropriate and required*
• Leverage existing NIST Special Publications
• Brings the IC more “in-line” with FISMA
• Assists the Inspector General (IG) audits, which are based on NIST standards
• Aligns with the rest of the Federal Government to support reciprocity
* Optimal goal is to ensure all key policies for the IC are either in an
official CNSS publication, or NIST SP
36
ICD 503
• Signed by the DNI and effective on September 15, 2008
• Rescinded DCID 6/3 Policy and Manual, and DCID 6/5 Manual*
• Requires IC elements to determine level of risk based on overall effect to
mission, not just security
• Addresses policy for;
• Risk Management
• Certification
• Accreditation
• Reciprocity and Interconnections
• Governance and Dispute Resolution
* Appendix E, Access by Foreign Nationals to Systems Processing Intelligence,
remains in effect (will likely be dealt with an ICS)
37
ICD 503 Authorities
• The National Security Act of 1947 (as amended)
• Federal Information Security Management Act of 2002
• Requires Federal agencies to develop, document, and implement an agency
wide information security program
• EO 12958 (as amended)
• Provides for the appropriate handling of classified
National Security Information
• EO 12333
• Strengthens the ability of the DNI to lead the Intelligence Community as a
unified enterprise
• Institutes the DNI as the responsible party for establishing common security
standards for managing and handling intelligence information and systems
38
Risk Management
• “The principal goal of an IC element’s information technology risk
management process shall be to protect the elements ability to
perform its mission, not just its information assets.”
• Determine level of acceptable risk
• Ensure mission capabilities are at acceptable risk levels
• Consider information sharing and collaboration requirements
• Consider the sensitivity of the information
• Apply common standards and processes per NIST, CNSS, and Intelligence
Community Standards (ICS)
39
Accreditation
• Management decision explicitly accepting a defined level of risk for
an IT system
• Accreditation decisions must factor in overall risk to the mission and
organization
• Enterprise level risks; mission, acquisition and finance (business), and
security
• Decision supports IC-wide collaboration and information sharing
• Element accepts minimum degree of risk of IT system to support
mission accomplishment
40
Authorizing Official
• Representative(s) designated by element head to make accreditation
decisions
• Normally the element CIO
• Must be a government employee
• Must possess a broad and strategic understanding of elements
mission(s) and role in the IC
• Accreditation decisions;
• Accredited
• Accredited with conditions
• Not Accredited
• May appoint one or more Delegated Authorizing Officials
41
Delegated Authorizing Official
• Appointed by AO to expedite approval of designated systems
• Interacts with key agency/organization officials on all things related to the
C&A process within that agency/organization
• Must be a government employee
• Must possess same capabilities as the AO
• May only accredit low or moderate impact systems*
* High Impact systems must be accredited by the AO
42
Certification
• A security certification is the required comprehensive assessment of
the management, operational, and technical security controls in an
information technology system, or for a particular item of information
technology, made in support of accreditation decisions
• The certification provides the essential information technology security
analysis needed to make a credible, risk-based decision
• The AO will appoint a Certification Agent(s) (CA) to act on his/her behalf
• A CA may not approve an accreditation on behalf of the AO or DAO
43
Reciprocity
• Elements of the IC shall make appropriate documentation available
to other IC elements, and to non-IC parts of the DoD, generally its
Military Departments, Combatant Commands, and Defense Agencies,
and also to non-IC agencies of the Federal Government.
• AO’s shall make available certification documentation to
other agencies as appropriate
• Agencies shall accept certification of a system by another
Agency without requiring additional validation and shall test
only the configuration differences by using the system in a new or different
environment
• All IC elements shall accept accreditations granted by
Commonwealth/5-Eyes Partners
44
Execution of Reciprocity in the IC
• DNI and DoD CIO’s Reciprocity & Reuse Memorandum
• Allows IC and DoD entities to accept each others C&A documentation
• Reduces needless duplication of paperwork and formatting
• Supports mission success by emphasizing content vice format in making risk
decisions
• ICD 704 – Personnel Security Standards for Access to SCI
• Specifies reciprocity of;
• Security Clearances between agencies
• Access to SCI
NOTE: Personnel Security is a control family in NIST SP 800-53
45
Interconnections & Resolution
• Interconnections of accredited IT systems are permitted with
accredited systems of other IC elements
• May require an Interconnection Security Agreement (ISA)
• IC CIO shall identify guidelines and standards for connecting IC systems to;
• Systems operated by Commonwealth Partners
• Systems operated by foreign nationals other than Commonwealth
Partners
• Governance and dispute resolution
• The IC CIO monitors compliance with the directive
• The IC CIO mediates all disputed matters
46
Status of ICD 503
• Policy guidance memorandum signed out by the Office of the DNI
CIO in November 2008
• NIST SP 800-37, CNSSI 1199 (draft), and CNSSI 1253 (draft) to be
converted to IC Standards*
• IC will produce interim guidance for authorizing new systems in the form of
IC Standards*
• Other CNSS documents (CNSSI 1230/1253A (drafts)) to be effective upon
review and approval of CNSS*
• DCID 6/3 to be used in the interim until all necessary supporting
documentation is published
* This language is contained in the official memorandum, but has subsequently
been superseded by decisions made at the 2009 CNSS Conference
47
Risk Management
48
Why use a Risk Managed Approach?
• Information Security decisions have been historically independent of
organizational risks
• Intelligence Community information systems currently operate in a
highly complex and interconnected environment
• Mission and business processes require a holistic view of risk,
taking organizational and enterprise factors into the decision process
• Information Security related risks, are but one component in an overall
Organizational Risk model
49
Concept of Risk Management
• Establishes a relationship between aggregate risk factors across an
organization and its enterprise
• Human Risk
 Malicious/Hostile Outsiders
 Malicious/Hostile Insiders
 Human Error
 Unauthorized Access
• Acquisition and Supply chain risk
• Operational/Environmental Risks
• Fosters an organizational climate that factors in risk from the outset of the System
Development Life Cycle (SDLC)
50
Organizational Risk Management
• Benefits to an organization;
• Standardized approach that allows senior leadership to better manage risks
associated with operational systems within their organization
• Helps security professionals within an organization better understand risks
associated with their systems in relation to the organizations mission
51
Organizational Risk Management (cont.)
• Security Professionals role;
• Understand issues that constitute overall risk
• Understand how risk can be mitigated and managed within an organization
• Support organizational management by;
• Becoming familiar with guidance and legislation associated with Risk
Management (DNI, DoD, CNSS, NIST)
• Identifying potential risk related issues in fielding IT systems within an
organization
52
Risk from an Enterprise Perspective
• Key steps in managing enterprise-level risk*;
• Categorize the information and systems impact/criticality/sensitivity
• Select and tailor appropriate, system-specific security controls
• Implement the security controls in the information system
• Assess the security controls for effectiveness
• Decide the enterprise/agency-level risk and risk acceptability and then
• Authorize information system operation
• Monitor security controls on a continuous basis
*Overall risk to the organization resulting from the operation of an information
system
53
Security Control Catalog (NIST SP 800-53)
54
Evolution of NSS Security
Control Input to NIST SP 800-53
Cross-Domain
Controls and
NSA System
Requirements
NIST
SP 800-53
DCID 6/3
Supply Chain/
Acquisition Controls
Security
Controls
Catalog
DoD
8500.2
55
Security Controls Structure
• Three Security Control classes
• Management Controls; Actions taken to manage the development,
maintenance, and use of the system
• Policies, procedures, and rules of behavior
• Operational Controls; Day-to-day mechanisms and procedures used to protect
operational systems and environment
• Awareness Training, Configuration Management, and Incident Response
• Technical Controls; Hardware/Software controls used to provide protection of
the IT system and the information it stores, process, and/or transmits
• Access Controls, Authentication Mechanisms, and Encryption
• 17 Security Control Families (see next slide)*
*Program Management Family “added” to NIST SP 800-53 (FPD), so the “true” total of control families
is 18 (FIPS 200 describes 17 control families)
56
Security Control Classes and Families