NIST has posted Interagency or Internal Reports (NISTIR) on Continuous Monitoring in NIST-IR-7756, NIST-IR-7799 and NIST-IR-7800 and would like comments by February 17th, 2012.

• NISTIR 7756, CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture
  

  presents an enterprise continuous monitoring technical reference architecture that extends the framework provided by the Department of Homeland Security’s CAESARS architecture. The goal is to facilitate enterprise continuous monitoring by presenting a reference architecture 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.

• NISTIR 7799, Continuous Monitoring Reference Model Workflow, Subsystem, and Interface Specifications
  

  provides the technical specifications for the continuous monitoring (CM) reference model presented in NIST IR 7756. These specifications enable multi-instance CM implementations, hierarchical tiers, multi-instance dynamic querying, sensor tasking, propagation of policy, policy monitoring, and policy compliance reporting. A major focus of the specifications is on workflows that describe the coordinated operation of all subsystems and components within the model. Another focus is on subsystem specifications that enable each subsystem to play its role within the workflows. The final focus is on interface specifications that supply communication paths between subsystems. These three sets of specifications (workflows, subsystems, and interfaces) are written to be data domain agnostic, which means that they can be used for CM regardless of the data domain that is being monitored.

• NISTIR 7800, Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains
  

  binds together the Continuous Monitoring workflows and capabilities described in NIST IR 7799 to specific data domains. It focuses on the Asset Management, Configuration and Vulnerability data domains. It leverages the Security Content Automation Protocol (SCAP) version 1.2 for configuration and vulnerability scan content, and it dictates reporting results in an SCAP-compliant format. This specification describes an overview of the approach to each of the three domains, how they bind to specific communication protocols, and how those protocols interact. It then defines the specific requirements levied upon the various capabilities of the subsystems defined in NIST IR 7799 that enable each data domain.

Updated to add related docs on Continuous Monitoring:
NIST SP 800-137 – Final – Information Security Continuous Monitoring for Federal Information Systems and Organizations
NIST SP 800-126 Rev 2 – Final – The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
NIST IR 7694 – Final – Specification for the Asset Reporting Format 1.1
NIST IR 7693 – Final – Specification for Asset Identification 1.1

Summaries:
SP 800-137 – High-level guidance document for CM
SP 800-126 Rev 2 – Technical specification that defines how to represent checks and checklists for configuration and vulnerability
IR 7694 – A high level reporting format to carry data about assets
IR 7693 – A standard data model for identifying assets

General
NIST IRs: http://csrc.nist.gov/publications/PubsNISTIRs.html
NIST SPs: http://csrc.nist.gov/publications/PubsSPs.html

The BBC has a headline story on the second professional athlete to be seriously injured or die on a superpipe in Utah.

The four-time Winter X Games champion crashed on the same superpipe where snowboarder Kevin Pearce suffered a traumatic brain injury during a training accident in late 2009.

[…]

“There are inherent risks in everything,” [Peter Judge, chief executive of Canada’s freestyle team] said prior to her death.

“Freestyle is a very safe sport in large part because we had to build a safe sport in order to get into the Olympics.”

Judge really should explain exactly why he believes the sport is safe instead of using a tautology — saying the same thing twice.

If I were to use similar reasoning as the above I could say this is a brilliant blog post because in order for it to be a blog post it has to be brilliant. What I want to hear is how vulnerabilities and threats are addressed at a reasonable level of detail. The more detailed the scrutiny the more likely improvements can be found; two major accidents by top talent on the same spot in two years (high severity and high frequency) suggests some safety gaps may be at hand.

A strange statement popped out at me in an article called Top 10 PCI Compliance Mistakes.

“PCI DSS 2.0 mandates that even if one VM deals with cardholder data, your entire virtual infrastructure must comply with the standard. The challenge is — the wording in PCI DSS on virtualization is vague and it all depends on the interpretation of the auditors,”

First, your entire virtual infrastructure does not have to comply with the standard if just one VM deals with cardholder data. That must be a misquote. I think what was meant was that a VM with cardholder data brings into scope the infrastructure that supports it (e.g. connected to or hosted on, per the Virtualization Guidelines quoted below). An entire virtual infrastructure can obviously include areas that are unrelated and unconnected to the VM in question. Segmentation is possible.

Second, the PCI assessors (not the same as auditor, but the two terms seem to be interchanged now) always interpret regulations. I say PCI DSS is one of the most prescriptive and therefore least vague. Moreover, it does not all depend on interpretation of the assessors. That is like saying food safety all depends on the health inspector. The Security Standards Council (SSC) for example can clarify or otherwise overrule an assessor’s interpretation.

With that in mind, here are a couple relevant sections.

PCI DSS 2.0:

2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

PCI DSS 2.0 Information Supplement: PCI DSS Virtualization Guidelines

If any virtual component connected to (or hosted on) the hypervisor is in scope for PCI DSS, the hypervisor itself will always be in scope.

I wrote last year a white paper on PCI compliance mistakes specific to virtual environments that you may find useful: 5 Mistakes Auditing Virtual Environments (You Don’t Want to Make)

I also wrote an earlier post on PCI scope errors.