Best Practices in Security Operations: Collection

Best Practices in Security Operations: Collection

.
Over the past few weeks, I’ve been giving a very similar presentation, to different audiences, when I’m asked to talk about the need for Collection across an enterprise. The attached diagram illustrates some of the flaws that come with relying on “point solutions” to provide enterprise visibility. Each technology has it’s inherent blind spots, but in conjunction with one another and a few other tools - namely Full Packet Capture, Log Management and SIEM you can provide your Detection team the ultimate information set for analysis and reduce your time to Incident Identification. This blog highlights some of the requirements for successfully establishing an effective Collection.

The overall model I’ve started to use more formally (Collection, Analysis, Escalation, Remediation, Reporting) is nearly the same as the Intelligence Model (Collection, Analysis, Dissemination) I used in my previous life, and is consistent with every other description I’ve found over the years. Richard Bejtlich has a fantastic CAER model he describes in a recent blog post. I recently used Richard’s recent blog entry to help justify this simplistic approach with several customers.

Collection: We have to ensure we have the right data available to the analysts, as efficiently as possible.

Context: This means we must understand what it is we are looking at and why we are looking at it. We must also understand the use of our networks/systems.

Vision/Clarity: We had to have clear access into the data, preferably the data is clean (void of as much garbage as possible). We must continually prune our systems in an operational mode (daily). Well-maintained systems are crucial to the success of the Detection Team.

Centralization: The moment you have to log in to more than one system to retrieve the log information, you’re fighting an uphill battle. Centralized Log Management is vital, brain dead simple, cost effective and hey… everyone else is doing it! There are tools out there that can help you centralize access to the logs, integrate with SIEM and collect data from your structured and unstructured data sets.

Automation: SIEM is your friend in this area. Much like an IDS you can generate “alerts” to notify you and speed up your incident identification timetable. With SIEM the “alerting” you get to enable is much more complex than with traditional IDS and you have built-in workflow to enable your Detection and Response Teams. In the end with SIEM you are making your life more efficient – as long as you plan for it and maintain it.

Data:: This seems simple… I’ll log x, y and z. In fact, introducing data sets should be the most complex part of your planning process. You must understand exactly why and how you will use the information made available to you before you tackle the task of bringing in the data and trying to analyze it. Easy example – trying to ask traditional network security analyst to look at custom financial application logs is going to hurt, a lot. Certainly you can look at that data, but you need Context to go along with the data. Security Point Solutions (IDS, FW, AV, Proxy etc) all have their place and should be monitored, but you will quickly find you’re fighting a losing battle if you rely solely on the information provided by these systems. The solution is a more holistic approach to seeing Network Traffic – Full Packet Capture. For one customer, we monitor multiple OC-12’s with Full Packet Data available for over 2 weeks and Meta Data available for 6+ Months. It is absolutely essential to reducing the time to incident identification, and helps us tune other sensors as well. Without the data – we were imaging drives to find confirmation of compromise/infection – these events are now trivial to verify with session reconstruction, we enable our Tier 1 to act much more quickly and with a much higher confidence level in their actions.

Full size image here: