Tenacity solutions incorporated
1 / 56

Tenacity Solutions Incorporated - PowerPoint PPT Presentation

  • Updated On :

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. Presentation Scope.

Related searches for Tenacity Solutions Incorporated

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Tenacity Solutions Incorporated' - darby

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Tenacity solutions incorporated l.jpg

Tenacity Solutions Incorporated

David Comings, Ph.D.

Risk Management Framework

Applied to Cross-Domain Solutions -

Introductions objectives agenda l.jpg
Introductions & Objectives (Agenda)

  • Instructor –

    • Who Am I?

    • Background

  • Objectives (Agenda)

    • RMF Overview & Application to Cross-Domain Solutions

Presentation scope l.jpg
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

Risk management framework 6 steps l.jpg

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 800-37

Implement 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).

Risk Management Framework – 6 Steps

Rmf step 1 categorize l.jpg
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

Rmf step 1 categorize cont l.jpg
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


    • User Representatives

    • Independent Evaluation Element

Rmf step 1 categorize cont8 l.jpg
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

Rmf step 1 categorize cont9 l.jpg
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

Rmf step 2 select l.jpg
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)

Rmf step 2 select cont l.jpg
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

Rmf step 2 select cont12 l.jpg
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)

Rmf step 3 implement l.jpg
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

Rmf step 3 implement cont l.jpg
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

Rmf step 3 implement cont15 l.jpg
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 RMFStep 4

Rmf step 4 assess l.jpg
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

Rmf step 4 assess cont l.jpg
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

Rmf step 5 authorize l.jpg
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!)

Rmf step 6 monitor l.jpg
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

Slide20 l.jpg

?? Questions ??

Slide21 l.jpg

Slide23 l.jpg

C&A Transformation Effort

Background & History

The global threat is real l.jpg
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

U s ic infrastructure l.jpg
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)

C a transformation effort l.jpg
C&A Transformation Effort

  • Officially began in June 2006 with a “community wide” forum


    • 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

Seven 7 transformation goals l.jpg
Seven (7) Transformation Goals

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.

Adopt reciprocity as the norm, enabling organizations to accept the approvals by others without retesting or reviewing

Define, document, and adopt common security controls, using NIST SP 800-53 as a baseline

Seven 7 transformation goals cont l.jpg
Seven (7) Transformation Goals (cont.)

Adopt a common lexicon, using CNSSI Instruction 4009 as a baseline, thereby providing DoD and IC a common language and common understanding.

Institute a Senior Risk Executive function, which bases decisions on an “enterprise” view of risk considering all factors, including Mission, IT, Budget, and Security.

Incorporate Information Assurance (IA) into Enterprise Architectures and deliver IA as common enterprise services across the IC and DoD.

Seven 7 transformation goals cont29 l.jpg
Seven (7) Transformation Goals (cont.)

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.

C a transformation the 500 day plan l.jpg
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

C a transformation partnership l.jpg
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)

C a transformation partnership cont l.jpg
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

Unifying the c a process l.jpg
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

Dni approach to policy standards l.jpg
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

Icd 503 l.jpg
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)

Icd 503 authorities l.jpg
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

Risk management l.jpg
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)

Accreditation l.jpg

  • 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

Authorizing official l.jpg
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

Delegated authorizing official l.jpg
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

Certification l.jpg

  • 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

Reciprocity l.jpg

  • 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

Execution of reciprocity in the ic l.jpg
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

Interconnections resolution l.jpg
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

Status of icd 503 l.jpg
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

Why use a risk managed approach l.jpg
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

Concept of risk management l.jpg
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)

Organizational risk management l.jpg
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

Organizational risk management cont l.jpg
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

Risk from an enterprise perspective l.jpg
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

Evolution of nss security control input to nist sp 800 53 l.jpg
Evolution of NSS SecurityControl Input to NIST SP 800-53

DCID 6/3

Cross-Domain Controls and NSA System Requirements

Supply Chain/ Acquisition Controls




NISTSP 800-53



Security controls structure l.jpg
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)