Tenacity Solutions Incorporated

David Comings, Ph.D.

Risk Management Framework- Applied to Cross-Domain

Solutions -

Introductions & Objectives (Agenda)• Instructor – • Who Am I?• Background

• Objectives (Agenda)• RMF Overview & Application to Cross-Domain Solutions

2

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

3

Risk Management Framework – 6 StepsCNSSI 1253 (1199)

Categorization & Initial Tailoring Guidance,as well as NSS Community agreed upon

“defined variables”

NIST SP 800-53 / CNSSI 1253Select baseline security controls;

apply tailoring guidance and supplement controls as needed

based on risk Assessment.

NIST 800-37Implement security controls within enterprise

architecture using sound systems engineering practices; apply security configuration settings.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-39 / NIST 800-37 / NIST 800-30Determine risk to

organizational operations, assets, individuals, other organizations, and the Nation; if acceptable, authorize operation.

NIST 800-53A / NIST 800-37 / NIST800-30Continuously track changes to information system that

may affect security controls and reassess control

effectiveness

4

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

5

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

6

RMF Step 1 – Categorize (cont.) 7

• Unique Identifier • Information Flows• System Owner/Contact Information • Organizational Mission(s) Codified in

US Law• Governing Organization• 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…

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

8

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

9

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 controlspermitted (document all insertions/deletions)

10

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

11

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)

12

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

13

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

14

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

15

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

16

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

17

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!)

18

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

19

?? Questions ??

20

• Contact Information• David Comings, PhD• dcomings@tenacitysolutions.net

21

Backup Slides

22

C&A Transformation EffortBackground & History

23

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 ScientistNational Institutes of Standards & Technology

24

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)

25

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

26

Seven (7) Transformation Goals1) 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

27

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.

28

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.

29

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

30

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)

31

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

32

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

33

Breaking Down ICD 503

34

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

35

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)

36

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

37

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)

38

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

39

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

40

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

41

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

42

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

43

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

44

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

45

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

46

Risk Management

47

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

48

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)

49

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

50

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

51

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

52

Security Control Catalog (NIST SP 800-53)

53

Evolution of NSS SecurityControl Input to NIST SP 800-53

SecurityControlsCatalog

DCID 6/3Cross-Domain Controls and NSA System

Requirements

NISTSP 800-53

Supply Chain/ Acquisition Controls

DoD8500.2

54

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)

55

Security Control Classes and Families

56