SECURITY BREACHES NERC INSIDER THREATS PCI FAILED AUDITS FDCC REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS PCI FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI SECURITY BREACHES INSIDER THREATS CONTINUOUS MONITORING PCI REGULATORY VIOLA-TIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACH-ES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS PCI FAILED AUDITS FDCC REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS PCI FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI SECURITY BREACHES NERC INSIDER THREATS PCI FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA SECURITY BREACHES NERC INSIDER THREATS SOX FAILED AUDITS PCI REGULATORY VIOLATIONS BASEL II SYSTEM OUTAGES MiFID SECURITY BREACHES COBIT INSIDER THREATS FDCC FAILED AUDITS PCI REGULATORY VIOLATIONS ISO27001 SYSTEM OUTAGES GLBA

WHITE PAPERCONTINUOUS MONITORING

SEAN SHERMAN, CISSP, CISA, CCSK

DEFINING AND PLANNING CONTINUOUS MONITORING FOR NIST REQUIREMENTS

IT SECURITY AND COMPLIANCE AUTOMATION SOLUTIONS

CONTINUOUS MONITORING

Defining and Planning Continuous Monitoring for NIST Requirements2

EXECUTIVE SUMMARYContinuous monitoring is the practice of focused monitoring of systems to better manage risk and enhance security of the IT assets of an organization. And, continuous monitoring is part of a security and risk management program prescribed and promoted by the federal government as best practice. Recent changes to guidance for the Federal Information Security Management Act (FISMA) have generated some controversy and intensified discussions around this practice for federal agencies. This guidance, provided by the National Institute for Standards and Technology (NIST) in Special Publication (SP) 800-37 and SP 800-137, calls for changes in how government agencies must meet continuous monitoring requirements of FISMA.

What’s generating so much discussion is that the new NIST guidance requires organizations to achieve dramatically higher levels of awareness and manage-ment of their security controls. This can be a difficult task and will likely require automation to address risk management and systems accreditation.

Agencies are evaluating NIST guid-ance to determine the best way to incorporate these more stringent requirements into agency security and compliance programs. Because each agency’s security ecosystem differs, the solutions they devise will vary. However, agencies will have some tasks in common as they develop their solutions. At a minimum, they must re-examine the tools and techniques they currently use, and many may need to invest in new tools and processes.

Although the new guidance is controver-sial, it should significantly improve the security of agency information systems. For the most part, agencies (and other organizations) have focused on simply preventing incidents by defending the perimeter. Today’s increasing threat

environment includes internal and external threats, new technology, out-sourced IT services, and global threat actors. As a result, this prevention-based, perimeter-centric approach is no longer adequate.

Unfortunately, threats to security are never-ending, and breaches are likely inevitable. The key to a successful security strategy is the ability to quickly detect and respond to these events to minimize the damage. This is why agen-cies should embrace this new guidance around continuous monitoring.

In this white paper, we discuss what the U.S. Government is promoting related to this new guidance around continuous monitoring. In particular, we’ll highlight specific objectives and milestones of the changes. Ultimately, the guidance intends to provide practical advice to agencies. In that vein, we provide a starting point for agencies to build a continuous monitoring program that addresses the requirements in the way policy and compliance officers will likely interpret them.

Defining and Planning Continuous Monitoring for NIST Requirements 3

WHAT IS CONTINUOUS MONITORING?Continuous monitoring has been described as a security control, but also as an audit method. Because it can be both a detective control and a feedback mechanism towards correcting and adjusting security of sophisticated systems, it is also complex. The concept of continuous monitoring has been associated with a variety of proposed legislation1, NIST Guidance2 and different vendor solutions. Unfortunately, the term suffers from inconsistent definition in these contexts and others. Perhaps the best approach to answering the question is to explore the concept and develop a strategy to address its related compliance and security requirements.

THE HOME SMOKE ALARM ANALOGYContinuous monitoring has often been explained through the analogy of ceiling-mounted smoke alarms. Smoke alarms are a common requirement3 for most homeowners because they provide a continuous monitoring system for a security risk that could occur at any time: fire. But a good alarm also monitors itself for failure and typically “chirps” when its battery is failing. And modern alarms are typically inter-connected, so when smoke triggers an alarm in one room, the other alarms in the network are also triggered, protect-ing people throughout the entire house.

THREE KEY FUNCTIONS OF CONTINUOUS MONITORINGSimilarly, federal systems require continuous monitoring across multiple systems using controls to help protect the entire organization. This type of monitoring requires:

1. Analysis to understand security threats to a specific environment and select applicable controls that reduce risk (analogous to placing smoke alarms where they best protect the home from fire danger).

2. Data verification by collecting infor-mation about the status of a control, including changes to status to confirm that the control is working (analogous to testing that a smoke alarm has power and is working correctly).

3. Data correlation to provide examina-tion of data and metadata, such as control information timing. This infor-mation helps determine root cause of an alert for a control (analogous to being able to determine which alarm triggered cascading alarms, and also determine if an alert was triggered by an unexpected or inappropriate cause—a false alarm.)

EXTENDING MONITORING ENTERPRISE-WIDEWhile many security programs include these three key functions, they often apply them to a single system or a limited number of systems. Continuous monitoring applies these functions to the entire organization, which includes mul-tiple systems and all relevant controls. It’s this expansive approach that makes continuous monitoring a core practice in strategic security management.

Given the wide coverage continuous monitoring entails, an enterprise IT

infrastructure will obviously gener-ate large amounts of information. The relative amount of data is daunting to imagine: just consider how much data a single control produces, multiply it by the hundreds of controls most systems rely on, and multiple that by the thousands of alert combinations possible with each control. In turn, that information needs to be managed to improve security. Clearly, automated and data-centric continuous monitoring is needed.

Continuous monitoring data correlation is an excellent example of an enter-prise level control, as it uses system level monitoring to detect, manage and mitigate threats across the enterprise.

.:. “Continuous monitoring is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. The objective is to conduct ongoing monitoring of the security of an organization’s networks, information, and systems, and respond by accepting, avoiding/rejecting, transferring/sharing, or mitigating risk as situations change.” .:.

NIST SP800-37, REV 1

Defining and Planning Continuous Monitoring for NIST Requirements4

It affords enterprise protection against adversaries by correlating the data from multiple systems to identify a coordi-nated external penetration attack or insider threat.

For many enterprise security teams, continuous monitoring appears to just make more work. But through data correlation and analysis, it improves system security and makes the job of protecting them easier by helping identify risks and the controls needed to mitigate them.

WHAT IS CONTINUOUS MONITORING FOR FEDERAL AGENCIES?NIST is working with the Office of Management and Budget (OMB) and Department of Homeland Security (DHS) to promote continuous monitoring along two different tracks. The first focuses on using FISMA compliance to enhance a risk management framework (RMF) and secure systems. The second, which is associated with the DHS Cyberscope ini-tiative, focuses on using automation to collect and analyze agency data across the entire government.

To understand continuous monitor-ing, you should be familiar with these tracks, including related key documents and activities. NIST SP 800-37 discusses and describes the role and require-ments of continuous monitoring in a risk management framework. SP 800-137 describes additional requirements for continuous monitoring that will require automation to extend reporting and monitoring government-wide.

GUIDANCE FROM NIST SP 800-37 FOR CONTINUOUS MONITORINGNIST Special Publication 800-37, Revision 1, Applying the Risk Management Framework to Federal Information Systems [Feb 2010] provides the main source for using FISMA compliance to enhance Risk Management Framework (RMF) and secure systems. The publication describes six steps of an RMF:

» Step 1: Categorize information systems

» Step 2: Select Security Controls » Step 3: Implement Security Controls » Step 4: Assess Security Controls » Step 5: Authorize Information System » Step 6: Monitor Security Controls

Each step describes security functions and specific tasks necessary to accom-plish those functions. These functions and tasks include well-known security concepts such as establishing informa-tion system boundaries, ensuring secure system deployment, and ensuring contin-uous monitoring of the security controls that protect the system.

Figure 1 lists the security functions and tasks for “Step 6: Monitor Security Controls”. The tasks describe how to continuously monitor the security controls that protect an information system.

Security teams may carry out these tasks, but many fail to use the resulting collected information to systemati-cally re-assess risk. For example, the

Security Function Task Prescription

Information System and Environmental Changes

6-1: Determine the security impact of proposed or actual changes to the information system and its environment of operation.

Ongoing Security Control Assessments 6-2: Assess a selected subset of the technical, management, and operational security controls employed within and inherited by the information system in accordance with the organization-defined monitoring strategy.

Ongoing Remediation Actions 6-3: Conduct remediation actions based on the results of ongoing monitoring activities, assessment of risk, and outstanding items in the plan of action and milestones.

Key Updates 6-4: Update the security plan, security assessment report, and plan of action and milestones based on the results of the continuous monitoring process.

Security Status Reporting 6-5: Report the security status of the information system (including the effectiveness of security controls employed within and inher-ited by the system) to the authorizing official and other appropriate organizational officials on an ongoing basis in accordance with the monitoring strategy.

Ongoing Risk Determination and Acceptance

6-6: Review the reported security status of the information system (including the effectiveness of security controls employed within and inherited by the system) on an ongoing basis in accordance with the monitoring strategy to determine whether the risk to organizational operations, organizational assets, individuals, other organizations, or the Nation remains acceptable.

Information System Removal and Decommissioning

6-7: Implement an information system decommissioning strategy, when needed, which executes required actions when a system is removed from service.

.:. FIG. 1 NIST 800-37 Rev 1, Step 6: How to Continuously Monitor IT Security Controls.

Defining and Planning Continuous Monitoring for NIST Requirements 5

security function “Ongoing Security Control Assessments” assumes that the security team establishes an initial inventory of all security controls for an information system and that a select subset of these controls will subse-quently be assessed for their associated threat, risk, interdependencies with other controls, and normal operating process. Figure 2 shows the information this assessment could generate for one system-level control.

This example illustrates the central role NIST SP 800-37 plays in the federal government’s push toward a more sophisticated risk-based model. This model relies on ongoing risk

assessments of controls through contin-uous monitoring and subsequent tuning to meet specific system threats.

Continuous monitoring requires system owners to employ various techniques and tools. Although NIST SP 800-37 does not prescribe any specific techniques or tools, the analysis it demands requires near continuous assessment of con-trols, the ability to address dynamic and external sub-systems, and a means of collecting and correlating all the security data generated by continuous monitor-ing. The illustration in Figure 3, taken from NIST guidance, emphasizes the iterative, cyclic nature of this approach to risk assessment.

Security Control Encrypt passwords and authentication credentials (a setting in the Operating System or Domain)

Threat the Control Protects Against

Man-in-the-Middle vulner-ability: making certain user passwords and credential information cannot be seen on the network and used to for false authentication

Risk to the Control Authentication spoof-ing, resulting in loss of confidentiality, integrity or availability of data. Risk of intentional or accidental setting changes is High

Associated Controls

Administrative rights (that could change this setting), logging any changes to the control (e.g. registry and logs)

CONTINUOUSLY MONITOR?

YES, validate that this setting is appropriate AND does not change. Watch for related changes to log settings (specific events), escalation of privilege (events), and administrative activity.

.:. FIG. 2 Example of assessment results.

RESPOND ANALYZE/REPORT

IMPL

EMEN

T

R

EVIEW

/UPD

ATE

DEFINE ESTABLISH

CONTINUOUSMONITORING» Maps to risk tolerance» Adapts to ongoing needs» Actively involves management

.:. FIG. 3 The cyclic and dynamic nature of risk assessment.

Defining and Planning Continuous Monitoring for NIST Requirements6

GUIDANCE FROM NIST SP 800-137 FOR CONTINUOUS MONITORINGNIST Special Publication 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations [IPD Dec 2010] clarifies expectations of federal agencies around continuous monitoring. It also includes additional requirements around continuous monitoring that will assist in extending risk management from the information system level to the enterprise level.

These additional requirements for enterprise-level risk management include:

» Define continuous monitoring strategy;

» Establish measures and metrics; » Establish monitoring and assessment frequencies;

» Implement continuous monitoring program;

» Analyze data and report findings; » Respond with mitigating strategies, or reject, transfer or accept risk; and

» Review and update continuous moni-toring strategy and program.

In addition, the document supports broader organizational goals around meeting existing requirements for FISMA reporting and system-level certification and authorization (C&A). These requirements and goals underscore the need for automated technologies and management.

Although there is controversy about these new requirements (mostly because many agencies already have significant investment in the FISMA reporting cycle and C&A process) one agency is forging ahead. NASA recently made the dramatic decision to tie con-tinuous monitoring directly to its C&A process.4 The decision was designed

to streamline the process and help the agency quickly experience the cost sav-ings and improved systems security. The effort will focus on strong enterprise risk management practices (defined by NIST) and suspend the traditional secu-rity certification process. Undoubtedly many lessons will be learned as NASA executes this plan.

KEY TAKEAWAYS FROM NIST SP 800-37NIST SP 800-137 offers two primary takeaways. First, risk management must be viewed from an organization-wide perspective. Risk management activities at the top organizational level impact the risk management strategy and associ-ated monitoring requirements at the common controls level (those controls common to multiple systems), on down to the level of individual information system controls. In turn, the metrics monitored at the common controls level and the system level flow data back up to the organizational level. This top-down

and bottum-up data flow impacts the decisions made and controls selected at the organizational level.

Second, the following elements are key for organization-wide continuous monitoring:

1. Configuration Management and Change Control

2. Reporting of Security Status3. Assessment of Implemented Controls4. Security Impact Analysis (which

informs which controls on which assets are achieving intended objectives)

Figure 4 shows the relationship between these elements and helps clarify the role that data, data analytics and auto-mation play in continuous monitoring.

With the large number of controls the U.S. government employs and the com-prehensive and onerous requirements of the RMF, automation will be essential

CONFIGURATION MANAGEMENTAND CHANGE CONTROL

SECURITYIMPACTANALYSIS

REPORT SECURITY STATUS

ASSESS AND EVALUATEIMPLEMENTEDSECURITY CONTROLS

Maintain visibilityinto assets

Ensure that implementedcontrols are achievingintended objectives

Ensure that controls are being implementedcorrectly and as planned

Maintain awareness ofvulnerabilities

CONTINUOUS MONITORING» Maps to risk tolerance

» Adapts to ongoing needs

» Actively involves management

.:. FIG. 4 Relationship of key elements in continuous enterprise-wide monitoring.

Defining and Planning Continuous Monitoring for NIST Requirements 7

for organization-wide risk management. In particular, automation will be needed to collect control alerts, verify control operations, perform configuration man-agement and report on security.

AUTOMATED CONTINUOUS MONITORING AND REPORTING FOR CYBERSCOPEThe second track related to continu-ous monitoring that NIST and the OMB are pursuing focuses on automation. Initially, NIST and OMB pushed for the use of automation in new reporting instructions for FISMA that the OMB outlined in OMB Memorandum 10-15.5 That memo explained that the OMB expected agencies to manage their (the agencies’) security information with the OMB’s security management tools.6

The OMB also wants agencies to send their security information electronically to a new program called CyberScope that the Department of Homeland Security (DHS) is currently developing in conjunction with the Department of Justice.7 Specifically, the CyberScope must be able to accept and analyze the data required by NIST 800-137 that each agency is supposed to submit. The government plans to use CyberScope to assess its security stance across all agencies and inform its strategy for national security and enterprise-wide risk/security. Agencies are mandated to submit their data via CyberScope by September 30, 2012.8 Given that the technology is still being developed, this may be a lofty goal.

Agencies not already involved with DHS’s implementation of CyberScope and the OMB’s efforts should exam-ine the NIST site http://scap.nist.gov/use-case/Cyberscope/. This site is associated with the NIST efforts for the Security Content Automation Protocol (SCAP), the initiative to prescribe and

monitor specific controls on worksta-tions throughout the federal enterprise. At a high level, CyberScope can be seen as an analytical tool for SCAP-monitored devices.9 But realistically, in the short term CyberScope will likely see SCAP reporting as only one of many streams of information it must process.

Because agencies differ in the security tools and tactics they employ, security tool vendors will likely have to figure out common standards for sending informa-tion to CyberScope and for agency-wide collection of continuous monitoring data.

Tripwire VIA Solutions for Continuous Monitoring.: . NIST guidance for FISMA calls for using automation to maintain

secure system configurations, provide robust alert and reporting features, and support standards and initiatives such as CyberScope, SCAP and the Extensible Configuration Checklist Description Format (XCCDF). Tripwire® VIA™ solutions meet the bulk of specific functionality called for by NIST. By using Tripwire as the core technology in their continuous monitoring program, the organization should be able to:

1. Expand the number of systems and components that meet continuous monitoring requirements with a product that supports the real world mix of non-homogenous operating systems, applications and networking devices.

2. Simplify setting up a continuous monitoring program with a tool that provides continuous configuration assessment out of the box. This functionality supports prescribed controls from NIST 800-53 (rev 3) for high, moderate and low baseline systems.

3. Improve operational performance with a solution that supports recommended workflow for continuous assessment and monitoring, and for the workflow and reporting requirements associated with change control, plan of action and milestones (POA&M) reporting, and remediation.

4. Improve the ability to gain rapid approval of the organization’s continuous monitoring program, thereby lowering cost of project security approval.

Defining and Planning Continuous Monitoring for NIST Requirements8

HOW TO ADDRESS CONTINUOUS MONITORINGWhile NIST 800-137 describes the process and aspects of setting up a program for organization-wide continuous monitoring, the following steps give a starting point for developing such a program.

STEP 1. IDENTIFY SYSTEMS ALREADY IN USE THAT CAN BE APPLIED TO CONTINUOUS MONITORINGContinuous monitoring requires you to assess the assets, tools and technology you already use. Many of the security and operational tools you use to manage your networks and systems will likely be part of your overall continuous monitoring solution. In an interview, Jerry Davis at NASA noted that they simply collect secu-rity information that existing solutions like patch and vulnerability management tools provide, crunch that information in a database, and produce a system risk score that they deliver to system owners.10

NASA’s approach illustrates a pragmatic and logical approach to automation that includes the following tasks:

1. Collect samples of the data and reporting existing tools provide.

2. Consider what tools could automate the identification of all IT assets and their status.

3. Assess and categorize systems by technology, system boundary and risk level/importance.

4. Consider which features of security and compliance tools best match your needs. For example, ° Take into account their age and sup-

port of other initiatives like SCAP. ° Examine whether their automation

“capabilities” provide controls, monitoring of controls, configu-ration management, scanning, alerting and reporting.

5. Develop a plan for assessing the need for the following types of tools11

° File Integrity Management ° Configuration Management/

Assessment ° Log Management/SIEM/SEM ° Patch Management ° Vulnerability Assessment ° Access and Authentication ° Encryption and Key Management ° Risk Management and Assessment ° Change Control/Help Desk/Incident

Management

STEP 2. ENSURE KEY PERSONNEL UNDERSTAND ROLES AND RESPONSIBILITIES Continuous monitoring requires con-tinued compliance with FISMA and other OMB mandates. To decrease any perceived conflict in requirements across mandates, clearly define roles and responsibilities and make certain that key personnel understand the risk management framework and risk man-agement goals.

NIST SP 800-137, section 2.4, describes key personnel that in many ways have the same responsibilities as authoriz-ing and certifying personnel described in FISMA. Avoid creating unnecessary new programs and expanding person-nel by reviewing potential overlap NIST SP 800-137 has with existing process, controls and risk management pro-cedures. The results of this effort can likely be used for compliance with con-tinuous monitoring and CyberScope.

STEP 3. DEVELOP (OR ENHANCE) A RISK MANAGEMENT PROCESSContinuous monitoring requires you to either create a new risk management process for the organization or enhance an existing one. Start by considering the highest risk systems, and then create templates for defining system-level risks and mitigation actions for these systems. For federal systems, this step will likely follow the FISMA process that NIST SP 800-37 describes and the controls that NIST SP 800-53 defines. This process should continue to support C&A com-pliance. Moving forward, the process should also now describe how controls that can be automated are associated with high-priority risk, and assessed with specific continuous monitoring tools.

Next, as you begin to develop the system reports for continuous monitor-ing and the associated risk assessment, ask upper level and business level management to review reports, existing policies, risk tolerance, and security management to identify gaps in gover-nance controls. These gaps will most likely be in policies and procedures, but they will guide and inform the develop-ment of the organization’s continuous monitoring program. The assessment of controls, frequency of assessment, and additional automation goals can also be clarified during this process. Decisions on what and how often to monitor will become the foundation for automation of the continuous monitoring program.

These steps should provide a high level strategy for most organizations and possibly encourage additional ideas about how to establish a continuous monitoring program.

Defining and Planning Continuous Monitoring for NIST Requirements 9

CONCLUSIONS ABOUT CONTINUOUS MONITORINGTo recap what this paper has addressed: continuous monitoring is a process and a high level control with the goal of gathering and analyzing security data to identify and mitigate risk and threats. It should be part of an overall system risk management strategy that extends to all management levels.

Continuous monitoring is also key to meeting requirements for OMB/FISMA reporting via CyberScope—an evolving national assessment program. Prepare to work with OMB and DHS to help them develop this program. Meeting these requirements will require you to define or redefine roles and responsibilities and create a continuous monitoring pro-gram for managing enterprise security.

Finally, continuous monitoring requires technology to monitor the broad range of controls prescribed in NIST guid-ance. This technology should help secure systems by collecting, cor-relating and analyzing security data. Automation of tasks and activities like continuous collection and correlation of status data from controls will be essential to manage and benefit from the volumes of valuable security data that these controls generate.

While this paper provides a high level strategy for developing a continuous monitoring program, your organiza-tion may wish to start looking at some of the more technically challenging aspects of continuous monitoring—for example, data collection, data manage-ment, and analytics.

The following sources provide a start-ing point for examining the technical requirements of a solution:

» Appendix D of NIST 800-137 outlines a series of protocols and initiatives around continuous monitoring led by NIST, MITRE and DHS.12 These pro-grams provide a wealth of information and volunteer opportunities for orga-nizations to help develop a solution.

» NIST Interagency Report 7756 describes the DHS reference archi-tecture, CAESARS, which is designed to “…enable enterprise continuous monitoring by presenting a technical reference architecture that allows organizations to aggregate collected data from across a diverse set of security tools, analyze that data, perform scoring, enable user queries, and provide overall situational aware-ness.” This reference architecture may be useful for developing the data management aspects of a continuous monitoring solution.

For many agency security teams, the requirements around continuous moni-toring appear to create a great deal of additional work. However, investing in such capabilities for enterprise-wide security will surely pay off in the long run, with fewer major security incidents and overall less effort expended to protect the entire ecosystem of federal information systems.

ABOUT SEAN SHERMAN.: . Sean Sherman is a Senior

Cyber-Security Consultant working for clients to provide strategic security and compliance solutions and solve complex problems to balance risk, compliance and security.

With over 24 years of IT experience, Mr. Sherman has seen the security and IT industry through many changes. He is active in the security and audit field, and has recently finished tenure as president of his local ISACA chapter and is an ISO 27001 Lead Auditor.

Mr. Sherman is considered a subject matter expert for a number of current compliance, security and privacy programs, including: NERC, NIST/FISMA, CNSS, ISO 27001, PCI, and other current IT Security regulations and frameworks. His background includes working over 15 years in the Federal IT/Security space. His current projects include work with FISMA, Smart Grid/Utility cyber security, Security and Compliance in cloud computing, classified systems development, and other compliance/risk/governance efforts. He holds a variety of certifications such as CISSP, CCSK, CISA, PMP, MCSE, CIPP, and CPISM. .:.

Defining and Planning Continuous Monitoring for NIST Requirements10

APPENDIX A: TRIPWIRE HELPS TO MEET NIST 800-37 AND 800-137 REQUIREMENTSThis matrix shows the functionality prescribed with the feature set of Tripwire Enterprise for continuous configuration assessment. These capabilities have enabled organizations to meet the compliance requirements for compliance programs such as FISMA and NIST, as well as SOX, PCI (cardholder data), ISO 27001, COBIT, NERC, FFIEC, GLBA, HIPAA, and other complex compliance programs. Additionally, Tripwire Enterprise automation provides foundational technology from which to effectively combine other automation such as log management. Tripwire Enterprise can be configured to monitor for patch, antivirus and other key files regardless of products used, and provide a single management and alert dashboard for continuous monitoring functionality.

SYSTEM LEVEL (SP 800-37) CONTINUOUS MONITORING STAGERequirement Description Tripwire Enterprise Feature/Function

Information System and Environmental Changes

Determine the security impact of proposed or actual changes to the information system and its environment of operation.

Tripwire Policy / Configuration Assessment feature monitors all configuration of a system to maintain compliance with regulation/ organizational security policy controls (e.g. NIST 800-53, Rev 2 or 3). When changes are made to a system, the changes to configuration that affect the security compliance posture of the system can be immediately determined though tripwire alerts or reporting on the status of all security configuration.

Ongoing Security Control Assessments

Assess a selected subset of the technical, management, and operational security controls employed within and inherited by the information system in accordance with the organiza-tion-defined monitoring strategy.

Tripwire Configuration Assessment feature monitors configuration settings on dozens of platforms, applications and devices (not just Windows). Changes to any configurations trigger an alert within Tripwire console to record the change, who initiated the change, and when the change occurred. Monitoring frequency can be changed to meet CM Program requirements.

Ongoing Remediation Actions

Conduct remediation actions based on the results of ongoing monitoring activities, assessment of risk, and outstanding items in the plan of action and milestones.

Tripwire File Change Detection feature is matched with Tripwire Policy remediation features which can return the configuration to a known good/desired status. This feature works in conjunction with alerts, review and approval workflow to allow for either instant or phased automated administration of systems.

Key Updates Update the security plan, security assessment report, and plan of action and milestones based on the results of the continuous monitoring process.

The Tripwire Configuration Assessment and remediation feature works to provide reports that meet the requirements of Plan of Action and Milestone (POA&M) reporting with approval information. Tripwire supports SCAP reporting and assess-ment requirements with NIST approved features.

Security Status Reporting

Report the security status of the information system (includ-ing the effectiveness of security controls employed within and inherited by the system) to the authorizing official and other appropriate organizational officials on an ongoing basis in accordance with the monitoring strategy.

Tripwire Policy reporting can be done on the device or system levels to provide security status information about the control, it's status and description, aging, remediation advice, remediation status, and assignment information. This informa-tion can also be rolled up with other systems in an enterprise to senior manage-ment security review.

Ongoing Risk Determination and Acceptance

Review the reported security status of the information system (including the effectiveness of security controls employed within and inherited by the system) on an ongoing basis in accordance with the monitoring strategy to deter-mine whether the risk to organizational operations, organiza-tional assets, individuals, other organizations, or the Nation remains acceptable.

Tripwire records configuration change information for the purpose of seeing the effectiveness of security controls. The Tripwire compliance reports can be viewed in a variety of manners to find specific control information across systems and devices, or to alert and assess specific controls of high importance by customiza-tion of the score-weight of a control or group of controls. This information may be submitted for higher-level review with other agency reports through report export features.

Information System Removal and Decommissioning

Implement an information system decommissioning strat-egy, when needed, which executes required actions when a system is removed from service.

Tripwire's highly customizable configuration verification "rules" can check for the status (for instance) of decommission scripts, and the successful removal of data or settings as part of the decommission strategy.

Defining and Planning Continuous Monitoring for NIST Requirements 11

ENTERPRISE LEVEL (SP 800-137) CONTINUOUS MONITORING PROGRAMRequirement Description Tripwire Enterprise Feature/Function

Define continuous monitoring strategy;

A task which involves selection of tools and techniques for assessing security of systems and which provides the basis for continuous risk assessment by the organization.

Tripwire Configuration Assessment should be at the core of this strategy as a means by which all devices across all systems in the enterprise are monitored for compliance to policy. Tripwire provides a way to assess change with rapid alert and detailed assessment of any change that affects security or compliance.

Establish measures and metrics;

Set baseline of those controls most important or correlating to the highest risk to the organization

Tripwire Configuration Assessment is based on the file integrity feature which can be used to "hash" or "fingerprint" key system files. This can make setting a "known good" state for systems, and provide for the baseline of systems. Additionally, the Tripwire configuration assessment feature allows for monitored controls, settings or files to be given relative "weight" to associate with the risk level or importance. This allows for alerts of failure of a control to be similarly prioritized (e.g. a failure of a setting with weight of 1 is less important than setting with weight 9).

Establish monitor-ing and assessment frequencies;

The exact frequency of monitoring controls across the enter-prise will be based on the importance of various systems, complexity of the controls and the resources to apply.

Tripwire automation of configuration assessment becomes an important way to assess controls on a much more frequent manner than if by hand. Tripwire systems can be set to monitor on almost any schedule depending on compute resource. Typical monitoring frequency of Tripwire systems is much more "continuous" than called for by OMB/NIST guidelines.

Implement continuous monitoring program;

Move beyond the assessment phase to implement tools and controls to provide steady reporting on the security and risk status of systems with detail information on controls which are most important.

Tripwire configuration assessment is at the core of a continuous monitoring program by providing technology which - out of the box- provides FISMA compli-ant control assessment of systems, application and system components. Reporting can be organized to roll up systems by department, region or domain. Additionally, the Tripwire reporting and remediation features provide a proven method to manage change workflow (POA&M and Change Control) in a method as defined by NIST in 800-37.

Analyze data and report findings;

To analyze data from continuous monitoring as part of ongoing security management and risk management of the enterprise.

Tripwire Configuration assessment provides an organization with the base technol-ogy and data to manage risk in the enterprise. By using base or customized Tripwire Policy allows for any setting, file or configuration on a system to be monitored. By using remediation metadata, system administration can be enhanced, and by using weight and scoring can help make the identification of high value controls.

Respond with mitigat-ing strategies, or reject, transfer or accept risk; and

Perform risk mitigation strategy which allows for quick identification of change that increases risk, and application of appropriate mitigation.

Tripwire Configuration Assessment policies come with remediation instructions for manual repair of controls, and with automated remediation features which can return a setting to compliant state. This feature, used in conjunction with POA&M reporting and weighting provides a compliant risk and continuous monitoring program.

Review and update continuous monitoring strategy and program.

The Risk Management framework implies an ongoing assess-ment of the program to enhance capabilities and reporting based on risk information.

Use of the Tripwire Configuration Assessment feature as the foundation of the Continuous Monitoring Program in the organization provides a technology which can be used to develop ever more sophisticated rules for continuous monitoring. System administrators can build complex rules for testing a wide range of controls and system specific attributes.

Defining and Planning Continuous Monitoring for NIST Requirements12

REFERENCES AND FOOTNOTESARTICLES“Agencies figuring out how to take network vitals”, (March 1, 2011) Jason Miller, Federal News Radio http://www.thecre.com/cm/?p=131

“Continuous Monitoring Discussed by Gen. Alexander” (Feb 23 2011) Molly Bernhart Walker, Fierce Government IT http://www.thecre.com/cm/?p=127

“NASA’s new FISMA approach and what it means for you” (May 24, 2010) Ben Bain, Federal Computer News Week http://fcw.com/Articles/2010/05/24/Web-NASA-FISMA-memo.aspx?Page=1

“NASA hits FISMA reset button” (June 4, 2010), staff, http://fcw.com/articles/2010/06/07/buzz-nasa-fisma-jerry-davis.aspx

NASANASA Memorandum (Jerry Davis) on C&A process change in lieu of M-10-15, http://fcw.com/articles/2010/05/24/~/media/GIG/FCW/Documents/C%20A_Changes_ATO_Extension_051810.ashx

OMB MEMORANDUMM-10-15, “FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management” http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-15.pdf

NISTSpecial Publication 800-137, “Information Security Continuous Monitoring for Federal Information Systems and Organizations (Draft)” http://csrc.nist.gov/publications/drafts/800-137/draft-SP-800-137-IPD.pdf

Special Publication 800-37, “Guide for Applying the Risk Management Framework to Federal Information Systems”, Rev 1, http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

Cyberscope – Draft work. http://scap.nist.gov/use-case/Cyberscope/

Special Publication 800-12, “An Introduction to Computer Security” (Oct 1995). http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf

NIST InterAgency Report 7756, “CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture (Draft)” – (Feb 2011) http://csrc.nist.gov/publications/drafts/nistir-7756/Draft-nistir-7756_feb2011.pdf

NIST “FAQ on Continuous Monitoring”, June 1, 2010 - http://csrc.nist.gov/groups/SMA/fisma/documents/faq-continuous-monitoring.pdf

DHS“Continuous Asset Evaluation, Situational Awareness and Risk Scoring (CAESARS) Reference Architecture Report” version 1.8, (Sept 2010) http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

FOOTNOTES1 Examples: Executive Cyberspace Coordination

Act, sponsored by Rep. James Langevin, D-R.I., Cybersecurity and Internet Freedom Act of 2011, introduced in February 2010 by Reps. Roscoe Bartlett, R.-Md, C.A. Ruppersberger, D-Md., and Loretta Sanchez, D-Calif., and Measure, S. 3480 by Sen. Thomas Carper, D-Del., on the Senate Homeland Security and Governmental Affairs Committee.

2 As far back as 1995 – NIST 800-12, and through 2010, NIST 800-137

3 In the United States, most state and local laws regarding the required number and place-ment of smoke detectors are based upon standards established in NFPA 72, National Fire Alarm and Signaling Code. http://en.wikipedia.org/wiki/Smoke_detector.

4 Jerry Davis, NASA’s Deputy Chief Information Officer for IT Security, issued a memo “Suspension of Certification and Accreditation Activity” which outlined a new process for the agency to follow in lieu of the three-year C&A process and paper-based recertification.

5 http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-15.pdf

6 Interesting assumption of a correlation of security tool data – long overdue.

7 For much more on the NIST/DHS development of Cyberscope, check out the NIST IR 7755 (Feb 2011) CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture (Draft)

8 Federal News Radio (http://www.thecre.com/cm/?p=131) “OMB directed in the fiscal 2012 IT budget passback that agencies must imple-ment continuous monitoring capabilities by the end of 2012. Before moving to continuous monitoring, OMB also wants agencies to sub-mit data to the CyberScope tool by Sept. 30.”

9 Actually much more than this, refer to the NIST IR 7756 – CAESARS FE

10 Federal Computer Week http://fcw.com/Articles/2010/05/24/Web-NASA-FISMA-memo.aspx?Page=2

11 These areas align loosely to the NIST automation domains as referenced in Appendix D, NIST 800-137

12 OCIL, NVD, SCAP, etc.

13 Tripwire supports most operating sys-tems (e.g. Windows, SunOS, Linux vari-ants, as well as most enterprise data-bases (e.g. Oracle, DB2, SQL) and Network devices (e.g. Cisco switch/routers)

.:. Tripwire is a leading global provider of IT security and compliance automation solutions that help businesses, government agencies, and service providers take control of their physical, virtual, and cloud infrastructure. Thousands of customers rely on Tripwire’s integrated solutions to help protect sensitive data, prove compliance and prevent outages. Tripwire VIA, the integrated compliance and security software platform, delivers best-of-breed file integrity, policy compliance and log and event management solutions, paving the way for organizations to proactively achieve continuous compliance, mitigate risk, and ensure operational control through Visibility, Intelligence and Automation. .:.

LEARN MORE AT WWW.TRIPWIRE.COM AND @TRIPWIREINC ON TWITTER.

©2011 Tripwire, Inc. Tripwire, VIA and ChangeIQ are trademarks of Tripwire, Inc. All other product and company names are property of their respective owners. All rights reserved.WPCMN1n 201107