tenacity solutions incorporated l.
Skip this Video
Loading SlideShow in 5 Seconds..
Tenacity Solutions Incorporated PowerPoint Presentation
Download Presentation
Tenacity Solutions Incorporated

Loading in 2 Seconds...

play fullscreen
1 / 56

Tenacity Solutions Incorporated - PowerPoint PPT Presentation

Download Presentation
Tenacity Solutions Incorporated
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

  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 C&A process as well as Cross-Domain Solutions Engineering Support

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

  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 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 RMFStep 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 • dcomings@tenacitysolutions.net

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