We spent a bulk of this series defining the major use cases for Continuous Security Monitoring, taking a journey through Attacks, Change Control, and Compliance. We know that many of you tend to be people of action, who want to just get going. But without a proper plan and definition for what you are trying to achieve with your security monitoring initiative, you will just end up with a lot of shiny expensive shelfware.

Now you need to decide on the technology platform you will use 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. We will cover the general requirements you need to cover, and then consider whether an existing platform can satisfy them. Not to spoiler the ending, but shockingly enough it will depend on your use case. Then we will discuss deployment models and the process involved to broaden our use cases.

Selecting the CSM Platform

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 the 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. But 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 provide increased scale – 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 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.
• Agentry: For the attack and change control use cases you will need to get information directly from monitored endpoints, which requires some kind of agent running on the 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 truly continuous monitoring you will need something on the device 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 for you 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, then 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 cases 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 ‘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 are able to 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 can urgently require 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 in immediately. If you have a limited triage/investigations staff (and who doesn’t?), that minimizes the relevance 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 big data 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 overkill.

Doesn’t the SIEM Do This?

You could certainly make a case that the SIEM/Log Management product you probably already have in place is in a good position to become the platform for CSM. SIEM does a good job with most of the requirements above. And SIEM already consumes most of the data sources needed 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 as another data source for analysis. 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 considerable overkill for your use case. If you just want to generate compliance reports, there are likely several easier. 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 likey a good fit for pseudo-real-time detection of attacks, and likely to be overly expensive and complicated for other requirements.

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 have 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 sacrifice your ability to grow into the attack use case someday with a short-sighted technology choice. To be more specific, 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 platforms. That might include web application scanning, passive discovery, or log aggregation. That kind of expansive scope shows a platform mentality, and means you are less likely to be stuck with a niche technology provider and platform – offering some reassurance that you will be able 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.

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 the use case (again!). Under the right circumstances, a managed CSM offering makes very good sense.

Service offerings tend to do well with the following capabilities:

• 24/7 device monitoring: You have a ton of computing devices and you don’t have the 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 and ship it 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 then notify you of potential issues. But few of these service support a device-centric agent for the pseudo-real-time detection that is so valuable for 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, scalable, and provide 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-based 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.

Evolving to CSM

Depending on which platform you choose to build your CSM capability on, you may be simply adding capabilities to an existing in-house product, or you could be facing a rip and replace. In the latter case we suggest you check out the Migration section of Security Management 2.0. There we detail a granular process for migrating to a new platform.

But if you are looking at basically adding a new use case to an existing platform, you can take a streamlined approach. You still need to both plan and implement, but much less than for a platform migration. Your plan needs to be very clear and specific about when new capabilities are added if new software or modules are required and where any additional data will come from; then smoke-test the new functionality to ensure it doesn’t break anything, and that it produces correct information; finally determine who will perform the work.

Plan

• Identify new data sources: First you need to figure out what new data you need in your CSM platform to accomplish your new use case. For example, if you are expanding from compliance to change control you will need a history of vulnerabilities, patches, and configurations, so you can identify the differentials. Where will you get that data? How can you automate import?
• Define visualizations, alerts, and reports: Once the data is in the system, what do you do next? You need to figure out how it can help solve your problem. That means designing visualizations and/or dashboards to help make decisions. You also need to figure out which alerts and reports are relevant for your particular use case. In the planning phase you defining a place to start, but that may not be where you finish. Considerable tuning will be required to make each function useful.
• Allocate resources: Who does the work? When will they do it? How long will it take to add new capabilities? Depending on the sophistication of your use case and your internal resources, this may be a good time to engage professional services and enlist third-party assistance.
• Define the timeline: Estimate the time it will take to roll out your new use case, including time for testing and verification. There is likely to be some ‘guesstimation’ but you just need rough numbers. Plan the project commencement date and publish to the team. Solicit feedback and adjust before commencing, because you need to share accountability with the operations team(s) to make sure everyone is invested in the project’s success.
• Preparation: Do as much work as possible before you go into production. Depending on your platform, you may be able to set up a different instance or implementation to identify and fix issues with before they become problems in production. If this isn’t possible ensure you have planned out rollback scenarios to remove the additional data, dashboards, alerts, and reports.

Implement

• Import new data: This varies based on the deployment model you choose (on-site or cloud), but rolling out a new use will require you to add data to the system. You may do a bulk import if you are pulling from an existing system such as patching or configuration management, or you might just start collecting new data as needed. This could involve installing agents on critical devices. Verify the system is collecting all the new data correctly, and that there are no issues with data accuracy or integrity. Remember, you will be making operational decisions based on this data, so you need it to be correct.
• Install policies, dashboards, and reports: Next deploy the rules that comb through your data and fire alerts for your use case. Hopefully you created as many as possible during the planning stages. For pseudo-real-time analysis you need to tune the rules. Each additional rule added incurs a significant processing cost. It’s math – analyzing multiple data sources against many rules causes the system to do exponentially more work, effective performance and throughput.
• Test and verify: Are your dashboards and reports being generated properly? Are the correct alerts firing in a timely fashion? Generate copies of reports and send them to the team for review. Verify that you get what you need – now is the time to find any problems, while you can find and fix problems before they hit production.

At this point you have your new use case operational and you are benefitting from continuous security monitoring. But attaining CSM is only the first part of your journey. New technology deployments and capabilities such as cloud computing, as well as emerging attacks, will require you to continuously evolve your security monitoring environment to keep pace.

With that we wrap up this Continuous Security Monitoring series. We trust it has helped you understand what ‘continuous’ really means in the context of security monitoring, and more importantly that you have a clear idea of the use cases for the technology and how to get there. We will assemble this series into a paper over the next week or so, and we welcome any comments or questions on our research.