Tenacity Solutions Incorporated

1
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 CA process as
  well as Cross-Domain Solutions Engineering Support

4
Risk Management Framework 6 Steps
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.)
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 CA 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 OM 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
• dcomings_at_tenacitysolutions.net

22
Backup Slides
23
CA 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
CA 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
• CA Process too long
• Output ? Seven (7) CA Transformation Goals

27
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

28
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.

29
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.

30
CA Transformation the 500-Day Plan

• Became part of the DNIs 500-Day Plan to
  Modernize Business Processes
• Issue Multiple, disparate and inconsistently
  applied IT processes associated with CA 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
CA 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
CA 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 CA is charged with streamlining and
  reducing the cost of CA 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 CA 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
  CA 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 elements
  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 CA 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.
• AOs 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 CIOs Reciprocity Reuse Memorandum
• Allows IC and DoD entities to accept each others
  CA 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 SecurityControl Input to NIST
SP 800-53
DCID 6/3
Cross-Domain Controls and NSA System Requirements
Supply Chain/ Acquisition Controls
Security Controls Catalog
NISTSP 800-53
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