Last updated at Wed, 27 Sep 2017 18:32:01 GMT
Compliance is not always an exciting topic to write about, in fact it's almost NEVER an exciting topic to write about, but that doesn't diminish its importance. For those of you in security who must adhere to a varietal (first of many references to adult beverages) of compliance policies you know that it is often a painful, yet necessary, part of your jobs. Unfortunately, the log management and SIEM technologies we all deployed over the years have served compliance officers by making it possible to obtain important information, but never considered the ease in which this ritual could be accomplished.
Fortunately for me, I get to sit down with security and compliance teams all the time, and when you talk with them about compliance, you hear the pain in their voices as they describe the months it takes to get the right reports built, not to mention the training needed to understand how to review the information. Volume and granularity have seemingly become the two tenants of security compliance reporting, instead of brevity and efficiency. This model needs to be fixed, and we'll talk about how, while enjoying a fine glass of wine and a pint of beer.
A pile of reports to dig through is no better than a pile of raw data.
Last week, while at dinner, we were greeted by the sommelier and under her arm was a fairly large wine book. This wine expert had most likely spent years building a knowledge of grapes, international regions, and food complements, and she was not there to simply tell us about her favorite wine. Instead, we conveyed to her what we were thinking about eating, what we liked in terms of wines, and she even asked pertinent questions about our tastes and personalities. These were all filters she applied on top of the enormous wine book to essentially spit out (sommelier puns everywhere!) a selection that would be ideal for that moment in time. Any time you have a long list of data points, it becomes more critical to build the right filters on top of the information to ask questions and transform it into something useful.
If you look at log management solutions of the past decade, you'll constantly read about “thousands of reports!” and “pre-built compliance dashboards!” but having these are just bragging about the thickness of your menu. Since compliance is all about having the process to monitor the right systems and the people to make that process work, auditors don't care about the number of available reports in the technology, they want to test your process by validating your solution so that they can retrieve the report that matters for each environment. This is why an easily customized menu with access to all of the relevant information is ideal for creating the dashboards your organization needs in a few hours. You should never have to dig through a series of embedded menus or pages and pages of reports every time you need to review a day's activity.
There is no acceptable reason for the compliance team to know every IP address and log format.
With the recent explosion of craft beer, the same five-star restaurants and their patrons (we're not diners at these places) have started to hire beer experts, occasionally labeled “cicerones.” These hop, malt, and yeast experts are intended to help you navigate the growing thickness of beer menus and appropriately pair with your meal choices. It would be pointless to ask a cicerone to answer all of a table's wine questions because you would typically end up with keeping up with both domains is a major challenge.
However, that's just what we've been asking compliance teams to do for years – understand the language of the networking team. Does the networking data contain valuable information for assuring a compliant network? Absolutely, but that doesn't mean we should require one to learn the other's craft. There is more than enough work for both parties in an organization. When a compliance officer needs to learn the format of IDS logs, Windows authentication logs, or firewall logs (which differ for every firewall vendor), it significantly reduces the focus on assuring the proper policies have been followed. Then, to have to track down which user accessed a protected asset when only an IP address is present in the logs is just, kind of, mean. That information should be baked into the events before they are reviewed.
Above all else, compliance reporting should be easy to adapt to [and use!] in your environment.
Since your compliance team needs to continuously monitor specific events across the systems and users uniquely important to your organization, both identifying the proper source data and viewing the resulting analyses need to be quick and easy. But making something as complex and cryptic as log data simple to view is more challenging than anyone ever anticipated:
- Normalization is the first key, and this is where the sommelier analogy unravel (since all sauvignon blanc is not equal). By parsing every authentication or firewall event and structuring the information in an easy-to-read format, Rapid7 InsightIDR makes every firewall event look the same, no matter how puzzling the original log, and going a step further, every event across all data types is given a very similar structure, so that reviewing the events doesn't require domain knowledge of networking devices or Microsoft logging conventions. This is done when the event source is connected, without any effort from the customer.
- The second key is to add important context, such as the user (think: human rather than account) responsible for the event and the host on which the event occurred, to enrich logs containing little detail. This is done during the pre-indexing phase of ingesting every event.
With the resulting easy-to-understand events, one only needs to learn the basics of our Querybuilder (LEQL for those who love acronyms) to define every dashboard a compliance team needs in a couple of hours. Having built them with your organization in mind, means no more digging through the thousands of noisy, irrelevant reports provided “out of the box” in other log management solutions. And don't worry, if you're an aspiring data archaeologist you can still dig into the raw events with the click of a button and the experts on other teams only need to get pulled in when something concerning needs to be explained or remediated.
Now, where did that cicerone go….?