Skip to content ↓ | Skip to navigation ↓

In the first installment of this series provided a general overview of continuous security monitoring, and the second article explained how CSM can help your organization react better to threats.

In the third article, we discussed the challenges regarding full visibility into your environment, the fourth article looked at classifying your network assets, and the fifth article in the series examined specific attack use cases.

The sixth and seventh installments looked at the Change Control use case the Compliance Use Case, which brings us now to strategies for selecting a CSM platform.

Now you need to decide on the technology platform to aggregate your data sources and perform the CSM analysis. You have a bunch of candidates, and probably a few already operational in your environment — though likely underutilized. Not to spoil the ending, but shockingly enough, the platform you choose will depend on your use case.

Many folks feel their eyes glaze over when someone uses the word ‘platform’. Security folks have a long and tattered history with all sorts of ‘platforms’, none of which have really done what they were supposed (promised) to do. Now we have the opportunity to reset expectations, which is why looking at the CSM platform in terms of use cases is critical.

Let’s start with general platform requirements and what you need:

  • Secure and scalable: Depending on your primary use case and the data sources you choose to aggregate, you may have significant scalability requirements. For lighter use cases such as compliance data storage demands are less intense. But we like planning for the future, which means picking a solution that can scale up even if you don’t need it yet. That comes back to architecture and deployment models, as described in our Security Management 2.0 paper. Keep in mind that the CSM environment includes sensitive data. So you will want to make sure your platform provides adequate security (strong authentication, data protection at rest, data integrity, etc.) to protect your protected information.
  • Analytics: Monitoring is all about being able to find patterns in disparate data sources, which requires the ability to analyze lots of data. Does that mean you need “big data” analytics? Again it depends on the use case, but make sure you can both look for patterns you already know about (standard attack scenarios) and also unknown situations that are clearly not normal. Also keep in mind that analytics (and the content to drive the analytics) changes over time, so selecting a platform driven by ongoing security research is critical to keeping the monitoring system current.
  • Agentry: For the attack and change control use cases you need to get information directly from monitored endpoints, which requires some kind of agent running on devices. Does it need to be a persistent agent? Not necessarily. You can get much of the data you need via credentialed scans or dissolving agents. But for continuous monitoring you will need something on devices looking for indicators of malicious activity.
  • Flexible alerting: Collecting data is good, but alerts make that data useful. You will want to ensure each alert provides enough information to actually do something about it. Whether that’s a poor man’s capability to manage an incident or integration with a broad investigative platform, you will need some way to operationally use the information from the platform. With the increasing availability of third-party threat intelligence you should also look for the ability to pull in external research feeds to search for specific indicators in the monitored environment.
  • Visualization: A good dashboard environment offers user-selectable elements, and defaults for both technical and non-technical users. The dashboard should focus on the highest-level information (which devices are at risk, aggregate reports, system health, etc.), and provide the ability to drill down as appropriate. Given the current state of technology, a web-based interface with significant customization is now table stakes.
  • Reporting: If compliance is your primary use case, your requirements are all about reporting. You need to produce artifacts to document how the security monitoring environment substantiates the effectiveness of controls on devices in scope. Even if another use case is your driver you will need some measure of ongoing reporting to satisfy compliance requirements.

Now that we know what the CSM platform is, let’s take a minute to mention what it doesn’t need to be — at least today:

  • Real time: One of the biggest confusions in security monitoring is over “real time”. You are aggregating data from an event that already happened, so it cannot actually be in real time. That said, the sooner you get the data, analyze it, and determine whether you have an issue, the better. Compliance doesn’t require any kind of real-time response. Change control requires more timeliness for critical devices, and the attack use case urgently requires fast reaction, so the shorter the window between event and alert, the better. But keep in mind that ‘real-time’ alerts aren’t useful if you cannot respond immediately. If you have a limited triage/ investigations staff (and who doesn’t?), that limits the value of ‘real-time’ response.
  • Big data centric: Big data is all the rage in all sorts of security discussions. But for compliance and change control it is generally overkill. And depending on the capabilities of your adversaries, advanced analytics may not add value to your efforts.

Eventually you may need a true security analytics platform with pseudo-real-time data collection to drive your CSM process. If you are facing truly advanced attackers you might need much more robust searching and forensics capabilities (perhaps including big data analytics). But if you are starting with compliance or change control, advanced analytics are likely to be more capability than you need.

Doesn’t the SIEM Do This?

You could certainly make a case that your current SIEM or Log Management product is already well-positioned to become your CSM platform. SIEM does a good job with most of the requirements above. And it already consumes most of the data sources for our use cases, with the exception of endpoint forensics and network packet capture… and a number of SIEMs are gaining the ability to capture network traffic. So clearly a SIEM is a reasonable choice for a CSM platform.

But there are reasons to be cautious, starting with the fact that a SIEM may be more horsepower than you need for your specific use case. If you just want to generate compliance reports, there are likely several easier options. For change control most SIEMs don’t handle configuration assessment and reporting differentials without customization and clever policy building. None of these are show-stoppers but SIEM is likely a good fit for pseudo-real-time detection of attacks.

As with every technology, don’t just look at cost from the standpoint of purchase price. SIEM remains a complex technology that will require initial deployment assistance and ongoing tuning to keep the system current and effective. Those costs can get lost in the cost analysis, so keep that in mind.

What about the Vulnerability Management Platform?

You could make a similar case for a vulnerability management platform, as we described in Vulnerability Management Evolution, which provides the ability to see what’s vulnerable and what has changed, in order to determine areas of potential exposure. For the compliance and change control use cases a VM platform makes a lot of sense. Most VM products and services offer configuration assessment as a core feature, with capabilities such as integrated log/event aggregation and alerting.

But be wary of VM platforms without a scalable data model that can evolve to handle additional data sources over time. Again, depending on your use case, you may not need those capabilities immediately, but don’t let a short-sighted technology choice sacrifice your ability to grow into the attack use case someday. Investing in CSM is a strategic decision to execute on your security program, so make sure your vulnerability management vendor is constantly adding new capabilities and services to their platform. That might include web application scanning, passive discovery, file integrity monitoring or log aggregation. That kind of expansive scope shows a platform mentality, which is a good sign for your ability to handle future requirements.

But when you take a step back to consider, the lines between SIEMs and vulnerability management platforms continue to blur. Over time we expect a consolidation of these product categories into broader security monitoring platforms with advanced analytics. There is no good reason to maintain two separate products or services to detect attacks over time.

Yet, with many organizations already having deployed both SIEM and VM there will be a period of coexistence on the path to a common platform. The length of this period will be enterprise-specific and dependent on the degree of organizational separation (if there are two separate groups responsible for SIEM and VM), the ability for a CSM platform to support both the SIEM and VM features, and cost. Clearly consolidating onto a common platform is preferable, but not at the exclusion of functionality or causing organizational disruption.

In the cases where consolidation is not practical, you’ll want to define which system is the primary alerting and visualization tool and then ensure the other supporting platforms can send data to the primary for analysis in a timely and accurate fashion.

To Cloud or Not to Cloud

Many providers offer managed security monitoring platforms (typically from the vulnerability management side) to take the operational and 24/7 responsibility of managing a SOC (Security Operations Center) off the enterprise’s plate. The question of whether a cloud-based service is the best choice ultimately comes back to use cases (again!). Under the right circumstances a managed CSM offering makes very good sense.

Service offerings are often marketed on the following capabilities:

  • 24/7 device monitoring: You have a ton of computing devices but inadequate resources to properly monitor them. That’s a key situation where managed security monitoring can help. These services are generally architected to aggregate data on-site (via an appliance) and ship the collected data to the service provider for analysis and alerting. The provider should have a correlation system to identify issues and a bunch of analysts who can verify issues quickly and notify you of potential problems. But few of these services support device-centric agents or passive discovery/monitoring for the pseudo-real-time detection that is so valuable in the attack use case.
  • Vulnerability management & configuration assessment: Vulnerability management and configuration assessment were two of the first capabilities to migrate to the cloud. These services are mature and scalable, and offer comprehensive reporting. Areas of ongoing evolution include support for device agents and more sophisticated alerting, but rolling out new services tends to be faster and less disruptive with cloud infrastructure.
  • Compliance reporting: Another no-brainer for a services option is basic log aggregation and reporting — typically driven by compliance. This isn’t very complicated, and is a good fit for a service offering. It also gets you out of the business of managing storage and updating reports when a requirement or mandate changes — providers should handle all that. As much as it makes security purists wince, every buying decision comes down to economics. Depending on your funding model and your organization’s attitude toward capital expenses, leasing a service for security monitoring may be a better option than buying outright — even if that means compromising a bit on functionality. Of course there are other ways to turn a capital purchase into an operational expense, and we’re sure your CFO will have plenty of ideas on that front, but buying a service is a simple way to avoid capital expenditure.

Make sure any managed service meets your needs before you consider economics — especially if there is a risk that Accounting might drive you into a long-term commitment to an unsuitable product. No OpEx vs. CapEx tradeoff can make a service meet security requirements.


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].


Title image courtesy of ShutterStock