New – Continuous Monitoring (Due 12 April) (5 Pages) (5 References – 3 included)

NIST Interage
(Second Draft

Jointly develo
Department o

ency Report 77
)

oped with the
of Homeland S

56

Security

7
t

CAAESASARSS Fraa workkmew
Exxtennsionn: Ann Enteerprrise
Coontinnuouus Moonitooringg
Teechnnical Refeerennce MModeel
(SSecoo ))nd DDraft

Petter Mell, David WWaltermiire, Larryy Feldmman,
e ng, Zac nd, andHarrold Boooth, Alfred Ouya hh Raglaa

Timmothy MccBride

Reports on Computer Systems Technology

NIST Interagency Report 7756
(Second Draft)

CAESARS Framework Extension: An
Enterprise Continuous Monitoring Technical
Reference Model (Second Draft)

Peter Mell, David Waltermire, Larry
Feldman, Harold Booth, Zach Ragland,
Alfred Ouyang, and Timothy McBride

C O M P U T E R S E C U R I T Y

Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20899-8930

January 2012

U.S. Department of Commerce

Secretary John E. Bryson

National Institute of Standards and Technology

Patrick D. Gallagher, Under Secretary for Standards
and Technology and Director

NISTIR 7756, Second Draft – January 2012

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of
concept implementations, and technical analysis to advance the development and productive use of
information technology. ITL’s responsibilities include the development of technical, physical,
administrative, and management standards and guidelines for the cost-effective security and privacy of
sensitive unclassified information in Federal computer systems. This Interagency Report discusses ITL’s
research, guidance, and outreach efforts in computer security and its collaborative activities with industry,
government, and academic organizations.

National Institute of Standards and Technology Interagency Report 7756
35 pages (Jan. 2012)

Certain commercial entities, equipment, or materials may be identified in this
document in order to describe an experimental procedure or concept adequately.

Such identification is not intended to imply recommendation or endorsement by the
National Institute of Standards and Technology, nor is it intended to imply that the
entities, materials, or equipment are necessarily the best available for the purpose.

2

NISTIR 7756, Second Draft – January 2012

Acknowledgments

The authors would like to thank the original research team that developed the Department of Homeland
Security (DHS) Federal Network Security’s seminal work on continuous monitoring architectures. The
Continuous Asset Evaluation, Situational Awareness, and Risk Scoring (CAESARS) architecture1,
created with MITRE support, formed the foundation of this work.

Also, we would like to recognize the following individuals for their participation on the continuous
monitoring research team, insightful ideas, and review of this work: Stephen York, Peter Sell, and David
Minge from the National Security Agency; Adam Halbardier, Adam Humenansky, Joe Debra, and Amit
Mannan from Booz Allen Hamilton; and Mark Crouter from MITRE.

Finally, we would like to thank the United States Chief Information Officer Council’s Information
Security and Identity Management Subcommittee (ISIMC) on Continuous Security Monitoring for its
leadership and direction as we created this publication. In particular we would like to thank the former
and current co-chairs2: Colonel Michael Jones from the US Army, John Streufert from Department of
State (DOS), Kevin Dulany from the Office of the Secretary of Defense (OSD), and Timothy McBride
from DHS (also one of the authors).

This publication was authored through the cooperative work of the following organizations:

– National Institute of Standards and Technology (Peter Mell, David Waltermire, Harold Booth)

– Department of Homeland Security (Timothy McBride)

– Booz Allen Hamilton (Larry Feldman, Zach Ragland)

– MITRE (Alfred Ouyang)

Abstract

This publication and its supporting documents present an enterprise continuous monitoring technical
reference model that extends the framework provided by the DHS Federal Network Security CAESARS
architecture. This extension enables added functionality, defines each subsystem in more detail, and
further leverages security automation standards. It also extends CAESARS to allow for large
implementations that need a multi-tier architecture and focuses on the necessary inter-tier
communications. The goal of this document is to facilitate enterprise continuous monitoring by presenting
a reference model that enables 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
awareness. The model design is focused on enabling organizations to realize this capability by leveraging
their existing security tools and thus avoiding complicated and resource-intensive custom tool integration
efforts.

Audience

This publication is intended for those planning to implement, develop products for, or support enterprise
continuous monitoring capabilities. The model is broadly applicable to diverse networks including

1 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf.

2 Co-chairs are listed on the Office of Management and Budget website

https://max.omb.gov/community/display/Egov/Continuous+Monitoring+Working+Group+Members.

3

https://max.omb.gov/community/display/Egov/Continuous+Monitoring+Working+Group+Members

http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

NISTIR 7756, Second Draft – January 2012

industry, civilian government, state government, tribal, and military networks. Expected users of this
document include Chief Information Security Officers, Chief Technology Officers, security tool vendors,
security tool testing laboratories, security program managers, enterprise architects, and security
procurement staff.

Although not a prerequisite, greater understanding of the CAESARS framework and our extensions will
be gained by also reading the DHS CAESARS architecture3.

3 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf.

4

http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

   
   
   

   
   
   

   
   

   
   
   
   
   

   
   
   
   
   
   
   
   
   
   

   
   
   

   
   
   
   
   
   

   

   

   

 

NISTIR 7756, Second Draft – January 2012

Table of Contents

1. Introduction and Document Overview …………………………………………………………………… 7

1.1 Introduction ………………………………………………………………………………………………….. 7

1.2 Document Overview………………………………………………………………………………………. 8

2. Defining and Scoping Continuous Security Monitoring …………………………………………. 9

2.1 Definitions ……………………………………………………………………………………………………. 9

2.2 Scoping and External System Interfaces ………………………………………………………… 10

3. Enterprise Architecture View for Continuous Monitoring……………………………………… 11

4. Foundational Work……………………………………………………………………………………………… 14

4.1 Overview of the CAESARS Reference Architecture …………………………………………. 14

4.1.1 Sensor Subsystem ……………………………………………………………………………. 15

4.1.2 Database Subsystem ………………………………………………………………………… 15

4.1.3 Analysis/Risk Scoring Subsystem ……………………………………………………….. 16

4.1.4 Presentation/Reporting Subsystem ……………………………………………………… 16

4.2 Limitations of the CAESARS Reference Architecture ……………………………………….. 16

4.2.1 Lack of Interface Specifications …………………………………………………………… 16

4.2.2 Reliance on an Enterprise Service Bus ………………………………………………… 16

4.2.3 Incomplete Communication Payload Specifications ……………………………….. 16

4.2.4 Lack of Specifications Describing Subsystem Capabilities ……………………… 17

4.2.5 Lack of a Multi-CM Instance Capability ………………………………………………… 17

4.2.6 Lack of Multi-Subsystem Instance Capability ………………………………………… 17

4.2.7 CM Database Integration with Security Baseline Content ……………………….. 17

4.2.8 Lack of Detail on the Required Asset Inventory …………………………………….. 17

4.2.9 Requirement for Risk Measurement …………………………………………………….. 18

5. CAESARS Framework Extension ………………………………………………………………………… 19

5.1 Variations on the CAESARS Architecture ……………………………………………………….. 19

5.2 Subsystem Overview …………………………………………………………………………………… 19

5.2.1 Presentation/Reporting Subsystem ……………………………………………………… 21

5.2.2 Task Manager Subsystem………………………………………………………………….. 21

5.2.3 Collection Subsystem ………………………………………………………………………… 23

5.2.4 Data Aggregation Subsystem ……………………………………………………………… 24

5.2.5 Analysis/Scoring Subsystem ………………………………………………………………. 26

5.2.6 Content Subsystem …………………………………………………………………………… 27

5.3 Multi-tier Capability ……………………………………………………………………………………… 29

6. Supporting Documentation Architecture ……………………………………………………………… 30

7. Conclusion…………………………………………………………………………………………………………. 32

Appendix A—Acronyms …………………………………………………………………………………………….. 33

5

 

 

 

 

 

 

 

 

 

 

 

 

NISTIR 7756, Second Draft – January 2012

List of Figures

Figure 1. Continuous Monitoring Data Domains ………………………………………………………………. 10

Figure 2. Enterprise Architecture View of Continuous Monitoring ………………………………………. 11

Figure 3. Contextual Description of the CAESARS System ………………………………………………. 15

Figure 4. CAESARS Framework Extension Subsystems and Components …………………………. 20

Figure 5. Presentation/Reporting Subsystem Communication …………………………………………… 21

Figure 6. Task Manager Subsystem Communication ……………………………………………………….. 22

Figure 7. Collection Subsystem Communication ……………………………………………………………… 24

Figure 8. Data Aggregation Subsystem Communication …………………………………………………… 25

Figure 9. Analysis/Scoring Subsystem Communication ……………………………………………………. 26

Figure 10. Content Subsystem Communication ………………………………………………………………. 27

Figure 11. Federated Hierarchical Continuous Security Monitoring Instance Model ……………… 29

Figure 12. Continuous Monitoring Document Architecture ………………………………………………… 30

6

NISTIR 7756, Second Draft – January 2012

1. Introduction and Document Overview

1.1 Introduction

The United States Office of Management and Budget (OMB) issued a memo in April 2010 requesting
that the Department of State, Department of Justice, and Department of the Treasury coordinate with the
Department of Homeland Security (DHS) to evaluate their continuous monitoring (CM4) best practices
and scale them across the Government5. As a result of this evaluation, DHS released the Continuous Asset
Evaluation, Situational Awareness and Risk Scoring (CAESARS) Reference Architecture Report version
1.86. The CAESARS report provides a reference architecture, based on security automation standards,
that guides organizations in deploying enterprise CM implementations.

In October 2010, the Federal Chief Information Officer Council’s Information Security and Identity
Management Committee’s (ISIMC) subcommittee on CM saw the need to create a technical initiative to
expand upon the CAESARS architecture to better scale it to large enterprises (e.g., the entire U.S.
government). A team of researchers from the National Security Agency’s (NSA) Information Assurance
Directorate (IAD), the DHS Federal Network Security CAESARS team, and the National Institute of
Standards and Technology’s (NIST) Information Technology Laboratory (ITL) worked together to
respond to this need. This publication is one of the outcomes of this joint research effort in support of the
ISIMC’s CM subcommittee.

The NSA’s involvement ensured the architecture’s applicability to U.S. military and national security
systems with consideration for integrating with existing Department of Defense programs such as
Computer Network Defense. DHS’ participation ensured applicability to its CyberScope program7 as well
as consistency with the CAESARS vision. NIST’s participation led to a model design that could support
industry as well as government and a design well integrated with existing and emerging security
automation standards.

This report describes the resulting CAESARS Framework Extension (FE), which builds upon the existing
CAESARS architecture to make it more broadly applicable to the entire U.S. Government, including the
Department of Defense, Intelligence Community, and civilian agencies. This work was also designed to
be applicable to industry, state governments, and tribal networks, using a flexible model able to handle
diverse customers and uses. In part, this was accomplished by extending CAESARS to allow for large
implementations that need a multi-tier CM architecture. In addition, much work was done to enable
additional functionality, provide more granularity within subsystem specifications, and further leverage
security automation standards (e.g., for communication payloads and application interfaces).

The end goal of CAESARS FE is to enable enterprise CM by presenting a technical reference model 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 awareness. The focus is on
primarily supporting cyber operations with compliance reporting as a by-product of actual security
monitoring and improvement. This design is focused on enabling organizations to realize this capability
by leveraging their existing security tools and minimizing custom tool integration efforts.

4 The acronym CM in this publication is not to be confused with other NIST 800 series publications that use the acronym CM to
denote “Configuration Management”.

5 The Department of Homeland Security’s Continuous Asset Evaluation, Situational Awareness and Risk Scoring Reference
Architecture Report, version 1.8, page xi (http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf).

6 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf.
7 http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-15.pdf .

7

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

http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf

NISTIR 7756, Second Draft – January 2012

This report provides a high-level design for meeting this goal. However, success will require additional
subsystem specifications, interface descriptions, and communication protocols. Achieving this goal will
also require the input and participation of security-tool vendors and their customers to help develop and
finalize these lower-level specifications.

Security-tool vendor participation is critical because their security sensors and controllers will need to be
modestly instrumented to support the model and related security automation standards. Fortunately, much
of this has already been accomplished through compliance with the NIST Security Content Automation
Protocol (SCAP) Validation Program.8 In addition, new functionality in data aggregation, analysis, and
event management products will be needed. Fortunately again, many existing products already contain
much of the needed functionality and should require only modest instrumentation to support the model.

If successful, CAESARS FE and the security products that support it will enable organizations to bring
together diverse security products and, using those products, compose a hierarchical data aggregation
model that supports a large variety of CM consumers from both the security disciplines and general
information technology (IT) management domains. The challenge will be to minimally define the
required functionality so that security tool vendors can cost-effectively participate, while ensuring a
necessary level of interoperability between vendor products. This will require ongoing discussions,
collaboration, and development within government and industry.

1.2 Document Overview

This report begins in Section 2 with a discussion of the definition of CM. From this definition, essential
technical characteristics are derived that support the specific CM enterprise architecture (EA) view
presented in Section 3. This EA view reveals the need for a set of goals that help in the review of the
capabilities and limitations of the original CAESARS architecture presented in Section 4. Section 5
presents a high- level view of the FE to CAESARS that expands upon the original functionality and
addresses the limitations. Section 6 discusses the supporting lower-level technical publications. Section 7
provides a conclusion. Appendix A lists the acronyms used in this report.

8 NIST Security Content Automation Protocol Validation Program, http://scap.nist.gov/validation/index.html.

8

http://scap.nist.gov/validation/index.html

NISTIR 7756, Second Draft – January 2012

2. Defining and Scoping Continuous Security Monitoring

This section discusses several definitions of CM and extracts from these definitions essential technical
characteristics for CM implementations. It also discusses the scope of CM to help focus the reader on
what will be provided by this model and what will need to be provided by existing IT operations.

2.1 Definitions

CM can be broadly defined by the following:

Continuous monitoring is ongoing observance with intent to provide warning. A continuous
monitoring capability is the ongoing observance and analysis of the operational states of systems
to provide decision support regarding situational awareness and deviations from expectations.

This definition applies to both Cybersecurity and general IT domains (e.g., network management). In this
publication, we focus on the Cybersecurity domains, but the architecture presented is applicable to
general IT domains as well. Because of the effort and expense involved in creating an effective CM
solution, such solutions should be leveraged for as many uses as possible. We strive in this publication to
support use across both Cybersecurity and IT management domains.

To focus on Cybersecurity, we now redefine CM in the context of security risk management using the
NIST Special Publication (SP) 800-137 definition:

Information security continuous monitoring is defined as “maintaining ongoing awareness of
information security, vulnerabilities, and threats to support organizational risk management
decisions.”

Note: The terms “continuous” and “ongoing” in this context mean that security controls and
organizational risks are assessed and analyzed at a frequency sufficient to support risk-based security
decisions to adequately protect organization information.

For purposes of designing a technical reference architecture in this publication, we provide a more
granular and process-focused description. From this we extract essential characteristics for CM
implementations.

Continuous security monitoring is a risk management approach to Cybersecurity that maintains a
picture of an organization’s security posture, provides visibility into assets, leverages use of
automated data feeds, monitors effectiveness of security controls, and enables prioritization of
remedies.

The essential characteristics for CM that can be derived from this definition are the following:
• Maintains a picture of an organization’s security posture
• Measures security posture
• Identifies deviations from expected results
• Provides visibility into assets
• Leverages automated data feeds
• Monitors continued effectiveness of security controls
• Enables prioritization of remedies
• Informs automated or human-assisted implementation of remedies

These characteristics support the EA view of CM provided in Section 3.

9

NISTIR 7756, Second Draft – January 2012

2.2 Scoping and External System Interfaces

It is the intent of the architecture presented in this publication to clearly scope and bound our technical
CM solution. Thus, we make a delineation in our model between what capabilities a technical CM
implementation provides (e.g., providing analysis of events) and the external systems to which it
interfaces. Multiple external systems will interface with any CM capability. For example, CM
implementations must interface with asset management systems for a CM capability to determine what
assets exist.

These external systems and technologies can be categorized to include at least 11 domains (see Figure 1)
that could interface with a CM capability.9

Figure 1. Continuous Monitoring Data Domains

Although the tools supporting these domains are not a core part of the technical CM capability, they need
to be instrumented to interface with CM solutions. For this reason, they are included in our model but are
clearly shown as external entities so that we can describe the needed interface requirements.

9 NIST Special Publication 800-137, Information Security Continuous Monitoring for Federal Information Systems and
Organizations, Appendix D.1. http://csrc.nist.gov/publications.

10

http://csrc.nist.gov/publications

NISTIR 7756, Second Draft – January 2012

3. Enterprise Architecture View for Continuous Monitoring

This section presents an EA view10 for CM with the purpose of illuminating high-level goals for the
CAESARS FE technical reference model and associated implementations. Figure 2 displays the EA view
of the enterprise continuous monitoring capability (ECMC).

Figure 2. Enterprise Architecture View of Continuous Monitoring

10 This was created by the National Security Agency Information Assurance Directorate and was modified slightly by the authors
to depict the ad hoc queries and focused aggregation.

11

 

NISTIR 7756, Second Draft – January 2012

This is not a technical architecture but is illustrative of higher-level goals that need to be implemented by
the CAESARS FE technical model. The following subsections describe each level of the EA view and
make general observations regarding the required technical model. They start with an explanation of how
data sources feed data collection activities and then show how that data is stored, analyzed, and presented
to consumers who make decisions based on a variety of drivers.

a. Data Sources
The data sources for CM include the categories of people, process, technology, and environment. While
many CM implementations may focus initially on technology, a CM technical architecture should be
general enough to allow inclusion of the other categories. The people, process, and environment data
types do not always lend themselves to fully automated data collection efforts and in most cases will
require some human data collection effort.

b. Data Collection
A variety of methods, both automated and manual, can be used to collect data. Focus should be on using
standards-based methods within tools for performing data collection to reduce integration costs, enable
plug-and-play compatibility of subsystems, and enable CM implementations to incorporate diverse sets of
security implementations. However, not all data feeds are currently standardized so the technical model
needs to allow for acceptance and processing of proprietary data payloads. Human-generated data (e.g.,
from user surveys or from security compliance documentation) should be collected using mechanisms
that harness automation and that leverage standardized methods. In addition, the appropriate frequency
for data collection needs to be determined for each data feed. Some data feeds will be truly continual
(always on) while others will be continuous (collected periodically at some set interval), and, in some
cases, it may be more appropriate for the data feed to be event driven.

c. Data Storage and Analysis
The collected data will initially reside at a local repository near the point of collection and then may be
aggregated at higher tiers in the organization. Having CM data available at each tier enables users at that
tier to have an appropriately abstracted view into the organization’s security posture. Normally, users at
each tier need only an abstracted view of the lower-level CM data, and thus it is not necessary to duplicate
all data up through each tier. Replicating all low-level security data at multiple levels within an
organization could pose an increased security risk, along with authorization and scalability challenges.
For this reason, the CM EA view shows a “focused aggregation” occurring when transferring CM data
from a lower-level repository to a higher-level repository. Only the data needed by the next higher tier is
transferred up and duplicated. Determining these necessary “predefined views” is an important step in any
CM implementation. Ideally, the majority of the CM data, especially the most sensitive data, will stay at
the local repository level. At this level, the information is closest to the authoritative sources (i.e., data
collectors), allows for fine-grained access control, is the timeliest copy of the data, and poses the least
aggregation risk.

This model for performing data aggregation using predefined views is a common approach for CM
implementations. However, it is likely that users at higher tiers will have an operational need to
occasionally query data that is outside of the available predefined view. In such cases, organizations may
be tempted to aggregate more and more of the data at all tiers. At an extreme, they may attempt to
aggregate and duplicate all CM data at all tiers. This may result in network bandwidth and data storage
challenges while presenting additional security risks. To alleviate this need, the EA CM view enables
users at one tier to issue operational, or “ad hoc,” queries that are propagated down to lower tiers for data
retrieval. If the requested data is not available in local repositories, the operational query from a higher-
level tier may trigger additional data collection at the lower tiers. The technical CM …