Evolving Continuous Monitoring to a Dynamic Risk Management Strategy

March 2, 2012 - 2 Comments

Organizations implementing Continuous Monitoring strategies are remiss if they are not taking into account the value of network telemetry in their approach. NIST Special Publication 800-137, Information Security Continuous Monitoring for Federal Information Systems and Organizations provides guidance on the implementation of a Continuous Monitoring strategy, but fails to address the importance of network telemetry into that strategy. In fact the 38 page document only mentions the word “network” 36 times. The SP 800-137 instead focuses on two primary areas: configuration management and patch management.  Both are fundamental aspects of managing an organizations overall risk, but to rely on those two aspects alone for managing risk falls short of achieving an effective Continuous Monitoring strategy for the following reasons

First, the concepts around configuration and patch management are very component specific. Individual components of a system are configured and patched. While these are important the focus is on vulnerabilities of improper configuration or known weaknesses in software. Second, this approach presumes that with proper configuration control and timely patch management that the overall risk of exploitation to the organization’s information system is dramatically reduced.

While an environment that has proper configuration and patch management is less likely to be exposed to known threats, they are no more prepared to prevent or detect sophisticated threats based on unknown or day-zero exploits. Unfortunately, the customization and increase in sophistication of malware is only growing. A recent threat report indicated that nearly 2/3 of Verizon’s data breach caseload were due to customized malware. It is also important to keep in mind that there is some amount of time that passes between a configuration error is determined and fixed or the time it takes to patch vulnerable software. This amount of time can potentially afford an attacker a successful vector.  For these reasons organizations looking to implement a Continuous Monitoring strategy should depend on the network to provide a near real-time view of the transactions that are occurring. Understanding the behavior of the network is important to create a more dynamic risk management focused Continuous Monitoring strategy.

Network telemetry can consist of different types of information describing network transactions in various locations on the network. Two valuable telemetry sources are NetFlow and Network Secure Event Logging (NSEL). NetFlow is a mechanism that organizations can use to offer a more holistic view of the enterprise risk picture. NetFlow is available in the majority of network platforms and builds transaction records of machine-to-machine communications both within the enterprise boundary as well as connections leaving the enterprise boundary. These communication records provide invaluable information and identify both policy violations and configuration errors. Additionally, NetFlow also provides insight into malicious software communications and large quantities of information leaving an enterprise. Network Secure Event Logging uses the NetFlow protocol to transmit important information regarding activities occurring on enterprise firewalls. This is valuable data that can be aggregated with other NetFlow sources to bring additional context to the network behavior occurring.

Coupling the configuration and patch management guidance in SP 800-137 with an active NetFlow monitoring capability will provide organizations with a Continuous Monitoring strategy that is more system focused and more apt to fostering a dynamic risk management environment. Cisco will be discussing NetFlow, NSEL and other security topics at the March 21st,  Government Solutions Forum in Washington, D.C. If you’re interested in learning more, click on the following URL:


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Interessting statement from somebody working for a company who put their own event correlation and log monitoring product supporting Netflow (do you remember MARS) to end of life without any replacement. I think there is a saying like: “walk your talk”.
    BTW: Off course almost all of the products support Netflow, as long as we are talking about routers. But not those products who are in use in the masses within an enterprise network. The switches. If Cisco would bring Netflow to access switches it could bring in a highly valued benefit and I fully agree to your statements. But as long as Netflow is only available on big core devices, like Cat6500 or Nexus 7000 plattforms and higher, it’s not realy an option, as you’re not able to monitor traffic flowing within the same access area. And therefore you are left only with a partial view of your network traffic, as only traffic leaving your access area and flowing through your distribution switches can be monitored. Even not all Cat4500 variants do support Netflow. Only specific sups can be upgraded with a daugther card.

  2. Chris,
    Interesting comments and thoughts about Continuous Monitoring, but I think you have missed the core concept behind 800-137 and Information Security Continuous Monitoring. ISCM is not intended to be operations and incident response focused, as your ideas about NetFlow and NSEL suggest. While I think 137 has quite a few shortcomings, its focus on configuration compliance and patch management is spot on.

    When you talk about “evolving” Continuous Monitoring, I am a bit confused considering NIST has yet to even develop a reference model to prove that even the basics of patch management and configuration compliance can be automated and reported in the way 800-137 describes. So how can we “evolve” when we don’t even have the basics complete that we would evolve from?

    Continuous Monitoring is widely misunderstood; it is not collecting/watching logs, monitoring IDS/IPS, or dynamic network traffic analysis. While those metrics could provides cues on the effectiveness of a Continuous Monitoring program, the ISCM program itself will focus on collecting data from endpoints and generating system level, as well as enterprise level reporting.

    NetFlow and NSEL have a place in network security, but lumping them in with Continuous Monitoring will only exacerbate the confusion that already surrounds how to implement Continuous Monitoring.