Skip to content ↓ | Skip to navigation ↓

In last article in the CSM series, we examined the Change Control use case scenario, which brings us now to the the Compliance Use Case. Previously, 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, and the fourth article looked at classifying your network assets, and the fifth article in the series examined specific attack use cases.

The Compliance Use Case

Compliance is typically the first use case implemented, mostly because PCI-DSS (and some other regulations) mandated the aggregation and parsing of event logs many years ago. Regardless of how you adopt CSM, make sure whatever monitoring infrastructure you put in place will be extensible and relevant to all your current and future use cases.

The goal of compliance is to document and substantiate the controls you have in place to pacify an auditor. It is not to solve actual security problems. Yes, that is a nuance, and if you adequately protect information assets you are likely to be able to prove compliance. But the converse is clearly not true. Just being compliant does not mean you are secure.

In terms of frequency of monitoring, you have a lot more leeway in this less stringent use case. In the attack and change control use cases, you need to continuously monitor critical assets to identify dangerous situations. But to be compliant you typically need to assess devices quarterly.

As long as you are collecting and parsing event logs on protected devices in a secure fashion (PCI Requirement 10), you’re good. Well, assuming that compliant equals good, but you are not necessarily secure. To be clear, logging is good, so do more of that. It helps when you have this information during incident response or investigation, so we are happy that PCI and other compliance hierarchies mandate it.

PCI also specifically requires assessment after ‘significant’ change (Requirement 11.2.3), but what does that mean? That kind of nebulous verbiage gives you the leeway to assess and monitor devices when you want to, and the PCI Council (and card brands) the leeway to string you up after a breach.

Compliance mandates like PCI may also specify a more ‘continuous’ monitoring approach such as an IDS (Requirement 11.4), which is also a good practice. But remember: this use case isn’t about being secure — it’s about just meeting the base requirements expressly mandated by regulation and/or guidance. So putting up an IDS to monitor your perimeter and fire one alert meets the requirement. Compliance is great, right?

We will climb down off the soapbox now. Smart security professionals realize that compliance is a means to an end. They can use a compliance mandate to free up budget for equipment and processes that also assist with the attack and change control use cases.

Data Sources

The data sources you use for compliance tend to be pretty consistent with the attack use case, though without the more sophisticated telemetry and forensic data you would need to really figure out what happened:

  • Assets: Your asset base is the fundamental data source for all use cases. You need an ongoing discovery capability to detect new devices on your network, and then a mechanism for profiling and classifying them.
  • Events & logs: Pretty much everything can and should be logged as part of the compliance use case — including security gear, network infrastructure, identity sources, data center servers, and applications. This is helpful for demonstrating that the controls in place work, which is the goal of this use case.
  • Patches: Keeping a device up to date is typically mandated by compliance regulations, so you need to generate reports showing which devices were updated when.
  • Configurations: Another aspect of compliance is implementing and maintaining secure configurations. You will need to document the posture of protected devices periodically. Differentials and history are less important because compliance is based on a point-in-time view of your infrastructure.
  • Vulnerabilities: Mandates also require periodic vulnerability scans of protected devices. So you need to document what was scanned, what was found, and eventually what was fixed, if the scan showed clear deficiencies.
  • Other documentation: Some mandates also require periodic penetration tests and other less automated functions. So you need the ability to store this unstructured data in the CSM repository if it will be used for compliance automation.

Preparing for the Audit

Unlike more action-oriented decision flows such as the attack and change control use cases, compliance is all about using data to prepare for assessment. You know when you need to be ready — auditors don’t show up unannounced like mystery shoppers. You also know the nature of the documentation you need to provide. Shame on you if you aren’t prepared for an audit, when you know exactly what’s expected and when to deliver it.

To help you prepare for an audit and make it as painless as possible, here is a streamlined process adapted from Mike Rothman’s Pragmatic CSO methodology:

1. Describe your security program: What about blasting the auditor with all sorts of reports to convince them you know what you’re doing? There is plenty of time for that, but only after you provide context for your security program — specifically how your CSM capabilities provide an accurate and timely view of information needed to understand your compliance posture.

2. Address past deficiencies: This is probably not your first audit, so you need to update the auditor on how you addressed previous findings. Here you can leverage your CSM platform to search for specifics and substantiate fixes for issues pointed out in the last assessment. One of the best ways to build your credibility with the assessor is to own your past mistakes and prove with data that you have fixed things.

3. Substantiate your controls: Now you can work through the data, showing the assessor that you have implemented the necessary controls effectively. This documentation should be straightforward to generate, given that CSM platforms have tons of pre-built reporting templates to relate collected data to the requirements of the leading mandates and regulations.

4. Streamline preparation: Compliance is an overhead function so you should focus on reducing the cost to prepare for the audit. Learn from each audit how to more effectively package and present your data. Get a feel for where you need additional information, or perhaps where your existing collection efforts provide more data than you need. Use these lessons to optimize your monitoring environment for this use case, which will make it easier to prepare for the next audit.

5. Get back to work: The problem with compliance is that it doesn’t directly help you protect your data or meet the other objectives of your security program. The less time you spend preparing for audits, and the quicker you can get them finished, the more time you can spend on other more productive aspects of your job. Compliance is table stakes so you cannot afford to neglect it, but the more time you spend on it, the less you have to take care of more strategic security activities.


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