Continuous Monitoring

The Evolution of FISMA Compliance

Tina Kuligowski [email protected]

Overview
Evolution of FISMA Compliance
NIST Standards & Guidelines (SP 800-37r1, 800-53) OMB Memorandums (M-11-33, M-10-28) DHS Federal Information Security Memorandums (FISM 11-02) The Deltas

CM Tools & Technologies:

Guidelines: SP 800-137 Information Security Continuous Monitoring Automation Domains, Tools and Technologies (SCAP, NVD) CAESARS Framework & States iPost

CM Challenges
The Organization of the SP 800-53 The Limitations of CAESARS GAO Report: Limitations of iPost and Risk Scoring Program

Evolution of FISMA Compliance

800-37 r1 Deltas
C&A vs RMF Joint Task Force Organization-wide RM Strategy Risk Executive (function) [Tier 1] Information Security Architect [Tier 2] Information System Security Engineer [Tier 3] Risk Redefined

OMB 11-33 FISMA Reporting Instructions DHS Cyberscope

Traditional C&A Phase Task Subtask 1: Preparation. Information System Description Security Categorization Threat Identification Vulnerability Identification Security Control Identification Initiation

Risk Management Framework Step Task 1.2 Information System Description 1.1 Security Categorization 1.3 Information System Registration

2.1 Common Control Identification 2.2 Security Control Selection 3.1 Security Control Implementation 3.2 Security Control Documentation

2.3 Monitoring Strategy

Initial Risk Determination
2: Notification

Notification Planning And Resources

3: SSP Analysis, Security Categorization Review Update, And System Security Plan Analysis Acceptance.

System Security Plan Update System Security Plan Acceptance 2.4 Security Plan Approval

Certification

Phase Task 4: Security Control Assessment

5: Security Certification Documentation 6: Accreditation Decision 7: Security Accreditation Documentation 8: Configuration Management 9: Control Monitoring 10: Status Reporting And Documentation

Continuous Monitoring

Traditional C&A Subtask Documentation Supporting Materials Methods And Procedures Security Assessment Security Assessment Report Findings And Recommendations System Security Plan Update POAM Preparation Accreditation Package Assembly Final Risk Determination Risk Acceptability Security Accreditation Package Transmission System Security Plan Update Documentation Of Information System Changes Security Impact Analysis Security Control Selection Selected Security Control Assessment System Security Plan Update POAM Update

Risk Management Framework Step Task 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 Assessment Preparation Security Control Assessment Security Assessment Report Remediation Actions Plan of Action and Milestones Security Authorization Package Risk Determination Risk Acceptance

Accreditation

6.1 Information System and Environment Changes 2.3 6.2 6.4 6.3 Monitoring Strategy (sorta) Ongoing Security Control Assessments Key Updates Ongoing Remediation Actions

Status Reporting

6.5 Security Status Reporting

Ongoing Risk Determination and Acceptance Information System Removal and Decommissioning

RMF 6.6 RMF 6.7

Joint Task Force Transformation Initiative

ongoing effort to produce a unified information security framework for the federal government.

SP 800-37 Risk Management Framework Committee on Department DITSCAP/ NIACAP National Security SP 800-53r3 Security Controls of Defense DIACAP Systems SP 800-39 Managing Information Security Risk
DoD, ODNI , NSA(CNSS 1253), Office(27001) of the National ISO/IEC Collaboration DCID 6/3 C&A Guidelines Director of Institute of Johns Hopkins APL Among Public And National Standards and Private Sector MITRE Corporation (NVD) Intelligence Technology Entities Booz Allen Hamilton

Organization-wide RM Strategy/ New Roles

Risk Executive (function)

Information Security Architect

Information System Security Engineer

OMB 11-33 FISMA Reporting Instructions

FAQ #9. Must the Department of Defense (DoD) and the Office of the Director of National Intelligence (ODNI) follow OMB policy and NIST guidelines? Answer: Yes, for non-national security systems DOD and ODNI are to incorporate OMB policy and NIST guidelines into their internal policies. . Note: NSA Uses CNSS1253, which looks very similar to a compilation of FIPS 199/200, references 80053, and provides a very FDCC/USGCB-like baseline of configuration settings.

Clarifying DHS Cybersecurity Responsibilities (M-10-28)

Critical Infrastructure Protection US-CERT Trusted Internet Connection Initiative Primary Responsibility for the Operational Aspects of Cybersecurity [FISMA Reporting]
Instructions New FISMA Reporting Metrics Cyberscope

DHS FISM 11-02 (aka OMB 11-33) FISMA Reporting Instructions

FAQ #28. Is a security reauthorization still required every 3 years or when an information system has undergone significant change as stated in OMB Circular A-130? Answer: No. Rather than enforcing a static, three-year reauthorization process, agencies are expected to conduct ongoing authorizations of information systems through the implementation of continuous monitoring programs.

FY2011 Reporting Metrics 13. Continuous Monitoring

13.1. What percentage of data from the following potential data feeds are being monitored at appropriate frequencies and levels in the Agency:
13.1a.IDS/IPS 13.1b.AV/Anti---Malware/Anti---Spyware 13.1c.System Logs 13.1d.Application Logs 13.1e.Patch Status 13.1f.Vulnerability Scans 13.1g.DNS logging 13.1h.Configuration/Change Management system alerts 13.1i.Failed Logins for privileged accounts 13.1j. Physical security logs for access to restricted areas (e.g. data centers)

DHS Cyberscope
Monthly Data Feeds to DHS
1. 2. 3. 4. 5. 6. 7. Inventory Systems and Services Hardware Software External Connections Security Training Identity Management and Access

Government-wide benchmarking on security posture Agency-specific interviews

Risk Management OODA LoopRedefined

Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations Information security continuous monitoring (ISCM) is defined as:
Maintaining Ongoing Awareness of Information Security, Vulnerabilities, and Threats Support Organizational Risk Management Decisions Begins With Leadership Defining A Comprehensive ISCM Strategy Encompassing technology processes procedures operating environments people

SP800-137

SP 800-137

ISCM Criteria
Risk Management Strategy: 1. How the organization plans to assess, respond to, and monitor risk 2. Oversight required to ensure effectiveness of RM strategy Program Management 1. Defined by how business processes are prioritized 2. Types of information needed to successfully execute those business processes

Monitoring System Level Controls and Security Status Reporting 1. Security Alerts 2. Security Incidents 3. Identified Threat Activities

Guidance: 800-137
Risk Tolerance Enterprise Architecture Security Architecture Security Configurations Plans for Changes to Enterprise Architecture Available Threat Information

The CM Process
Define an ISCM Strategy Establish an ISCM Program Implement an ISCM Program Determining Appropriate Response Mitigating Risk Review and Update the Monitoring Program

SP 800-137

Role of Automation in ISCM

Consideration is given to ISCM tools that:
Pull information from a variety of sources (Specifications, Mechanisms, Activities, Individuals) Use open specifications such as SCAP Offer interoperability with other products (help desk, inventory management, configuration management, and incident response solutions) Support compliance with applicable federal laws, regulations, standards, and guidelines Provide reporting with the ability to tailor output Allow for data consolidation into Security Information and Event Management (SIEM) tools and dashboard products.

SP 800-137

Security Automation Domains

Vulnerability & Patch Management Event & Incident Management Malware Detection Asset Management Configuration Management Network Management License Management Information Management Software Assurance
SP 800-137

Automation Domain 1 - Vulnerability Management 2 - Patch Management 3 - Event Management 4 - Incident Management 5 - Malware Detection

Tools and Technologies NIST Guidelines Vulnerability scanners NIST SP 800-40 Creating a Patch and Vulnerability Management Program Patch management tools NIST SP 800-92, Computer Intrusion detection/ prevention systems and Security Log Management logging mechanisms NIST SP 800-94, Guide IDPS

NIST SP 800-83, Malware Antivirus/ Incident Prevention and Malware detection Handling mechanisms 6 - Configuration SCAP, SEIM, Dashboards NIST SP 800-126r2 The Technical Specification for Management SCAP Version 1.2 SP 800-137

Automation Domain 7 - Asset Management 8 - Network Management

Tools and Technologies System configuration, network management, and license management tools
Host discovery, inventory, change control, performance monitoring, and other network device management capabilities License management tools

9 - License Management 10 - Information Management

Data Loss Prevention (DLP) Tools: network analysis software, application firewalls, and intrusion detection and prevention systems SP 800-137

Software Assurance Technologies

Security Automation Domain #11

Software Assurance Automation Protocol (SwAAP measure and enumerate software weaknesses): CWE Common Weakness Enumeration Dictionary of weaknesses that can lead to exploitable vulnerabilities CWSS Common Weakness Scoring System Assigning risk scores to weaknesses CAPEC Common Attack Pattern Enumeration & Classification Catalog of attack patterns MAEC Malware Attribute Enumeration & Characterization Standardized language about malware, based on attributes such as behaviors and attack patterns SP 800-137

DHS Reporting Metrics 12. Software Assurance

12.1Provide the number of information systems, developed in-house or with commercial services, deployed in the past 12 months.
12.1a.Provide the number of information systems above (12.1) that were tested using automated source code testing tools. 12.1b.Provide the number of the information systems above(12.1a) where the tools generated output compliant with: 12.1b (1).Common Vulnerabilities and Exposures (CVE) 12.1b (2).Common Weakness Enumeration (CWE) 12.1b (3).Common Vulnerability Scoring System (CVSS) 12.1b (4).Open Vulnerability and Assessment Language (OVAL) Source code testing tools are defined as tools that review source code line by line to detect security vulnerabilities and provide guidance on how to correct problems identified.

Automation and Reference Data Sources

Security Content Automation Protocol (SCAP)
What Can Be Automated With SCAP How to Implement SCAP Partially Automated Controls

Reference Data Sources

National Vulnerability Database (NVD) Security Configuration Checklists

SP 800-137

NVD Primary Resources

1. 2. 3. 4. Vulnerability Search Engine National Checklist Program SCAP Compatible Tools SCAP Data Feeds (CVE, CCE, CPE, CVSS, XCCDF, OVAL) 5. Product Dictionary (CPE) 6. Impact Metrics (CVSS) 7. Common Weakness Enumeration (CWE)

SCAP Program
Scan

NVD
Data Feed

SP 800-137

SCAP: What Can Be Automated?

Vulnerability and Patch Scanners
Authenticated Unauthenticated

Baseline Configuration Scanners

Federal Desktop Core Configuration (FDCC) United States Government Configuration Baseline (USGCB)

SP 800-137

How to Implement SCAP with SCAP-validated Tools

SP 800-137

 and SCAP-expressed Checklists

SP 800-137

Partially Automated Controls

Open Checklist Interactive Language (OCIL)
Define Questions (Boolean, Choice, Numeric, Or String) Define Possible Answers to a Question from Which User Can Choose Define Actions to be Taken Resulting from a User's Answer Enumerate Result Set

Used in Conjunction with eXtensible Configuration Checklist Description Format (XCCDF)

SP 800-137

Technologies for Aggregation and Analysis

Management Dashboards
Meaningful And Easily Understandable Format Provide Information Appropriate to Roles And Responsibilities

Security Information and Event Management (SIEM), analysis of:

Vulnerability Scanning Information, Performance Data, Network Monitoring, System Audit Record (Log) Information Audit Record Correlation And Analysis

SP 800-137

IR 7756

CAESARS Framework

IR 7756

IR 7756

CM Documents

IR 7756

Department of States iPost

Custom Application Continuously Monitors Uses Data from Various Monitoring Tools Holistic View Of Risk Leveraging Competitiveness Encourage Risk Reduction

iPost Development Stages

Deploy Enterprise Monitoring Tools Aggregate Monitoring Data: iPost Establish Risk Scoring Program

Monitoring Tool Data Sources

Component Vulnerability Patch Security Compliance Anti-Virus Unapproved OS Cyber Security Awareness Training SOE Compliance AD Computers ID VUL PAT SCM AVR UOS CSA What is Scored Source Vulnerabilities detected on a host Foundstone (McAfee) Patches required by a host SMS (System Center) Failures of a host to use required security settings McAfee Policy Auditor Out of date anti-virus signature file Unapproved operating systems Every user who has not passed the mandatory awareness training within the last 365 days Incomplete/invalid installations of any product in the Standard Operating Environment (SOE) suite Computer account password ages exceeding threshold User account password ages exceeding threshold (scores each user account, not each host) Incorrect functioning of the SMS client agent Missed vulnerability scans Missed security compliance scans SMS (System Center) AD DoS Training Database

SOE ADC

SMS (System Center) AD

AD Users
SMS Reporting Vulnerability Reporting Security Compliance Reporting

ADU
SMS VUR SCR

AD
SMS (System Center) Foundstone (McAfee) McAfee Policy Auditor

Risk Scoring

Remediation

CM Challenges
The Organization of the SP 800-53 Emerging CM Technologies
SCAP OCIL

The Limitations of CAESARS Department of States iPost and Risk Scoring Program

18 Families 198 Controls

Organization of Security Controls

892 Control Items

(Parts/Enhancements)

Evident in USGCB

Mapping STIG to 800-53

Using Fishbone to Find Root Controls

Plan, Engineer, & Prepare for Operations
Plan

Operate, Monitor, & Improve

Operate & Check Improve

Prepare

Effectiveness Measure

Requirements Definition

PP

Track Desired State Design/ Test/ AQ/ Infrastructure

PP

Find Systemic Problems

PP

11

7
PP
Assign Scores to Delta Track Actual

1
PP

A
Value Proposition/ Operational Metric

8
PP

Policy & Planning

5
PP

10

ID Score Deviations

PP

Fix Issues by Priority

PP

4
Prep Staff

PP

Manage & Operate

PP

The Limitations of CAESARS

Lack of Interface Specifications Reliance on an Enterprise Service Bus Incomplete Communication Payload Specifications Lack of Specifications Describing Subsystem Capabilities Lack of a Multi-CM Instance Capability Lack of Multi-Subsystem Instance Capability CM Database Integration with Security Baseline Content Lack of Detail on the Required Asset Inventory Requirement for Risk Measurement

GAO Report on Scope of iPost Risk Scoring Program

(1) Addresses windows hosts but not other IT assets on its major unclassified network (2) Covers a set of 10 scoring components that includes some, but not all, information system controls that are intended to reduce risk (3) State could not demonstrate the extent to which scores are based on risk factors such as threat, impact, or likelihood of occurrence that are specific to its computing environment

Minimum Security Controls (FIP 200) Access Control Awareness and Training Audit and Accountability Security Assessment and Authorization Configuration Management Contingency Planning Identification and Authentication Incident Response Maintenance Media Protection Physical and Environmental Protection Planning Personnel Security Risk Assessment System and Services Acquisition System and Communications Protection System and Information Integrity

Controls Monitored by iPost Security Compliance (AD Group check) Awareness Training Reporting

Patching, SOE, Reporting(Inventory)

AD Computers & Users

Vulnerabilities

Patching, Antivirus

Challenges with Implementation of iPost

(1) Overcoming limitations and technical issues with data collection tools (2) Identifying and notifying individuals with responsibility for site-level security (3) Implementing configuration management for iPost (4) Adopting a strategy for continuous monitoring of controls (5) Managing stakeholder expectations for continuous monitoring activities

FITSI Objectives Review

FISMA Compliance
OMB Memorandums DHS FISMs NIST Standards & Guidelines Evolution via Deltas

CM Tools & Technologies:

Guidelines: SP 800-137 Automation Domains, (SCAP, NVD) CAESARS Framework & States iPost

1. Consistent Body if Knowledge 2. Training Baseline

CM Challenges
The Organization of SP 800-53 The Limitations of CAESARS Your Organizations ISCM

Overcome CM Challenges with Collective Contributions

Q&A

Tina Kuligowski [email protected] [email protected] 571-229-0543