Skip to content ↓ | Skip to navigation ↓

In this fifth article in the CSM series, we will examine specific attack use cases, as the first installment of this series provided a general overview of continuous security monitoring, and in the second article explained how CSM can help your organization react better to threats. In the third article, we examined the challenges regarding full visibility into your environment, and the fourth article discussed classifying your network assets.

The Attack Use Case

The first use case we’ll address tends to be the highest profile, given it’s focused on stopping attacks. We mentioned NIST’s “official” definition of Continuous Monitoring above (“assessed, analyzed and reported at a frequency sufficient to support risk-based security decisions”).

As such, Your monitoring strategy should as ‘continuous’ as it needs to be. Just like advanced attackers are only as advanced as they need to be. We appreciate this clarification, which reflects the fact that some assets need to be monitored at all times, others not so much.

That’s why we delved into the importance of classifying your assets and applying a risk-based filter to your monitoring efforts. As we dig into this specific use case, it makes sense to be a bit more specific about what you are trying to identify in this use case:

  • Determining your attack surface by understanding your vulnerabilities and exploitable devices
  • Prioritize remediating those devices based on which have the most risk of compromise
  • Identify malware in your environment
  • Detect intrusion attempts at all levels of your environment
  • Gain awareness and track adversaries in your midst
  • Detect exfiltration of sensitive data
  • Identify the extent of any active compromise and provide useful information for clean-up
  • Verify clean-up and elimination of the threat

Data Sources

To address this laundry list of goals you need the following data sources:

  • Assets: As we discussed under classification, you cannot monitor what you don’t know about; likewise you need to know how critical an asset is to choose the most appropriate way to monitor it. As we described in our Vulnerability Management Evolution research, this requires an ongoing (dare we say, ‘continuous’) discovery capability to detect new devices appearing on your network, and then a consistent mechanism for profiling and classifying them.
  • Network topology & telemetry: Next you need to understand the network layout, specifically where critical assets reside. Assets accessible to attackers are higher priority than inaccessible assets, so it is quite possible to have a device which is technically vulnerable and contains critical data, but is prioritized lower than a less-valuable asset in harm’s way.
  • Events & logs: Any technological device generates log and event data. This includes security gear, network infrastructure, identity sources, data center servers, and applications, among others. Patterns in the logs may indicate attacks if you know how to look; logs also offer substantiation and forensic evidence after an attack.
  • Configurations: Configuration details and unauthorized configuration changes may also indicate attacks. Malware generally needs to change device configuration to cause its desired behavior.
  • Vulnerabilities: Known vulnerabilities provide another perspective on device vulnerability, and can be attacked by exploits in the wild.
  • Device forensics: An advanced data source providing a very detailed image (including memory, disk, etc.) of the device at any point in time. Typically associated with an incident investigation, this capability is evolving into a broader endpoint activity monitoring function, granularly tracking the activity on the device over a long period of time. This enables much more detailed analysis of the activity leading to a compromise. Investigators can then establish a timeline of the attack to isolate indicators of compromise and then understand how the device was used by the attackers.
  • Network forensics: Capturing full packet streams enables replay of traffic into and out of devices. This is very useful for identifying attack patterns, and also for forensics after an attack.

That is a broad list of data, but — depending on the sophistication of your CSM process — you may not need all these sources. More data is better than less, but everyone needs to strike a balance between capturing everything and only aggregating what’s immediately useful.

You do not get a second chance to capture data but resource constraints have a strong influence on the scope of collection efforts.

We say ‘pseudo-real-time’ because due to the nature of monitoring and the laws of physics, there is always lag between when something happens on the device and when it can be analyzed by the CSM system.

We say ‘pseudo-real-time’ because due to the nature of monitoring and the laws of physics, there is always lag between when something happens on the device and when it can be analyzed by the CSM system.

Getting the Data

So how can you collect all this data on an ongoing basis, and with what frequency? It’s time to get back to those asset classifications you decided on earlier. For critical assets gather as much data as possible. That likely means some kind of agentry on the devices to gather data at all times and send it back to the CSM aggregation point for pseudo-real-time analysis.

We say ‘pseudo-real-time’ because due to the nature of monitoring and the laws of physics, there is always lag between when something happens on the device and when it can be analyzed by the CSM system.

As mentioned above, Internet-accessible devices bring additional risk given they are subject to any and every recon attempt from anyone with an Internet connection. Thus, these devices should be monitored and/or assessed more frequently and likely via an external scan (from outside your perimeter).

You want to be able to assess these devices from the perspective of an attacker, and that attacker is very likely coming from outside your perimeter. So when gathering CSM data, both the inside-out and outside-in perspectives are important.

For devices which do not quite require always-on monitoring or forensics, you need to determine the frequency of vulnerability scanning, file integrity monitoring, and/or configuration change monitoring. Depending on criticality you might want to scan daily or weekly.

You also need to determine whether you need a credentialed scan for a far more granular assessment, or if an uncredentialed scan will suffice. Of course today’s malware spreads almost instantaneously, so if you don’t catch a configuration change or another indicator of attack for a week, who knows how much damage will happen before you notice?

This is why classification is so important — an attacker may start (and gain presence) by compromising an infrequently scanned device, but at some point they will need to go after a critical device you should be monitoring continuously — and therefore you should be in a position to detect the attack.

Another important aspect of data collection is automation. The only way to scale any kind of monitoring initiative is to have the data sent to the aggregation platform without human intervention, for both efficiency and accuracy. One aspect of the ‘continuous’ monitoring approach espoused by the US government is moving away from accreditation every couple years, instead monitoring devices more frequently.

It seems obvious, and it is. Today security success requires shortening the window between compromise and detection. To be clear, there is a place for third-party and/or manual assessment to confirm controls, but operational automation of data collection is essential.

We should also point out the blurry line between monitoring and defense, particularly for critical devices which are monitored continuously. Monitoring is a passive alerting function compared to prevention — actively blocking attacks.

The nuances of what to block and what to only monitor, as well as how to avoid false positives and negatives, are both beyond the scope of this paper. But all things being equal, if you can identify a clear attack on a critical device, you should position yourself to prevent it.

Quantifying CSM Risk

A key aspect of prioritizing which devices require remediation is understanding the risk a compromised device poses to your organization, based on how you classified the asset (as described above). We have never been fans of risk scoring because it can be far too subjective, and the algorithms tend to capture risk of compromise rather than true organizational or economic risk.

Once again, NIST offers useful perspective:

True risk scoring can be difficult to achieve using the NIST SP 800-37 revision 1 definition, and many “risk scoring” methodologies do not demonstrate a correlation to true risk measurement. Instead, they usually measure the state of a collection of security capabilities or controls. NIST IR 7756, p 26 (PDF)

Of course many folks (including some of our friends) have spent a significant portion of their careers trying to quantify risk, and we applaud those efforts. We are sure they will love our risk quantification shortcuts. But for our definition of CSM it is not clear we need to truly quantify risk — mostly we merely need to assess relative risk to support decision-making.

Issues with critical assets need higher priority. You can prioritize further based on whether the device can be accessed via external or only internal attackers. Inaccessible device are lower priority. Then you need to define a coarse hierarchy of potential exposures.

It might look like this:

1. Devices exhibiting anomalous behavior and/or indicators of compromise
2. Vulnerable devices with exploit code in the wild
3. Configuration issues which could result in full compromise
4. Devices vulnerable to non-weaponized attack
5. Everything else

Obviously compromised devices need to be addressed ASAP. Next on the list would be a device vulnerable to an exploit which has been seen in the wild. You may not have seen an active attack yet, but you will. Attackers are reliable that way, once weaponized code is available. Next you address configuration errors which could result in a compromised device.

Finally you deal with standard vulnerabilities as part of the normal patch/maintenance cycle. This list is not intended to be comprehensive — simply to illustrate you don’t need a very complicated algorithm to determine security risk in your environment and drive remediation decisions.

We aren’t trying to minimize the work required to aggregate all this data and define the rules to determine what is an attack, versus an exploitable vulnerability, versus a problematic configuration issue. It is decidedly non-trivial, but clearly it’s difficult to make decisions based on disparate information sources using inconsistent metrics and reporting environments.

The compelling value of CSM is in integrating all these disparate data sources into a common platform for more effective decision support. keep your eye on the prize. Today these data sources are aggregated and analyzed within separate management systems.

Clearly it’s difficult to make decisions based on disparate information sources using inconsistent metrics and reporting environments. The compelling value of CSM is in integrating all these disparate data sources into a common platform for more effective decision support.


In the next article in the CSM series, we will examine the change control use case… Stay Tuned!


Editor’s Note: This post is a series of excerpts from the Continuous Security Monitoring whitepaper developed by Mike Rothman of Securosis, and was developed independently and objectively using the Securosis Totally Transparent Research process. The entire paper is available here.


About the Author: Securosis Analyst/President Mike Rothman’s bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security — such as protecting networks and endpoints, security management, and compliance. Mike is one of the most sought-after speakers and commentators in the security business, and brings a deep background in information security. After 20 years in and around security, he’s one of the guys who “knows where the bodies are buried” in the space. Mike published The Pragmatic CSO in 2007 to introduce technically oriented security professionals to the nuances of what is required to be a senior security professional. He can be reached at mrothman (at) securosis (dot) com.


Related Articles:



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


picDefinitive Guide to Attack Surface Analytics

Also: Pre-register today for a complimentary hardcopy or e-copy of the forthcoming Definitive Guide™ to Attack Surface Analytics. You will also gain access to exclusive, unpublished content as it becomes available.


Title image courtesy of ShutterStock