Linkz for Detection and Response

Monday, January 19, 2015 Posted by Corey Harrell
The fastest way to reach a destination is to learn from those who have traveled parts of the journey you are on. Others may point you in a direction to avoid the obstacles they faced or show you the path through the woods towards your destination. In Information Security, we tend to gain knowledge from others by what they publish: websites, blogs, books, and even their 140 character tweets. The journey I have been on is exploring enterprise security detection and response; actually implementing enterprise detection and response. Implementing them not as standalone processes standing on their own but two complimentary processes that feed into each other. This Linkz post is sharing the works by others I came across whose focus is on detection and response.

Linkz for Incident Response and SIEM

I shared these linkz before but they point to some great resources about detection and response. For linkz related to incident response - including the thought process behind IR - refer to the post Linkz for Incident Response. For linkz related to detection with a focus on SIEM refer to Linkz for SIEM.

Network Security Operations Management Workflow

When it comes to network security there is a wealth of information. How to create a SOC, how to design and deploy IDS sensors, and how to use security monitoring tools are a few of the topics covered. Despite the wealth of information, there is very little about the management workflow for network security monitoring. Securosis released the Network Security Operations Quant Report about five years ago and it outlines one of the best management workflows I have come across. The Manage Process (on page 13) addresses policy review, update policies & rules, evaluate signatures, deploy, and audit/validate. It's a decent process since it touches on topics I haven't seen addressed elsewhere. At this point I could care less about the metrics portion of the document but the process portion is worth a look.

Network Security Monitoring Books

One thing I tend to look for in detection and response resources is do they outline a process or a thought process. Tools are great and all but it's pretty easy to learn a tool on your own compared to the process one  should use when doing detection and response. The processes are what you can learn from others to reach your destination and you can fill in the gaps by teaching yourself the tools. The next two resources are not free but are well worth the investment. Richard Bejtlich's The Practice of Network Security Monitoring: Understanding Incident Detection and Response and Chris Sanders  & Jason Smith's Applied Network Security Monitoring: Collection, Detection, and Analysis. Both books cover open source NSM tools and analyzing network data but the aspects I really enjoyed where their perspectives. Their perspectives about how to approach NSM and how to manage certain aspects of NSM including the response to security incidents along with detection security events.

Free Book with Strategies for Cybersecurity Operations Center

Carson Zimmerman of The MITRE Corporation released a free book titled Ten Strategies of a World-Class Cybersecurity Operations Center. I have been to a few different conferences where vendors give out free books. Needless to say, based on my past experiences I view free books with skepticism. However, Ten Strategies of a World-Class Cybersecurity Operations Center has restored my faith in free books. I'm surprised it was released for free; the content was great and the quality was top notch. The strategies covered topics from consolidating functions of detection and response under one organization to CSOC size to staff quality to sensor placement to responding to incidents. It's a great read for anyone who is looking to improve an organization's detection and response capability. It may even be worth the while for people who have been managing CSOCs to pick up a few different ideas.

Leveraging the Kill Chain for Detection

Sean Mason wrote the article Leveraging The Kill Chain For Awesome discussing the various ways the kill chain can be used. The section I wanted to focus on was the following: "when it comes to enterprise detection, the Kill Chain is useful for understanding what your capabilities are, as well as your gaps in coverage by tools and threat actors." This is one area where I think the kill chain excels. By organizing your detection rules beneath the kill chain it is easy to see what detection areas are strong and weak. Furthermore, it helps to see where external tools or intelligence can fill in the gaps. The one additional point I suggest is to do this organization for each use case that is implemented.

Questions to Answer During Response

A couple months ago Jack Crook put together a nice post over on his HandlerDiaries blog called Answering those needed questions. He walked through the typical questions he needs to answer when he is responding to an incident. In addition, he addressed "some of the actions needed during response activities." There were two things I really enjoyed about the post. First was how he broke down all of the possible questions one could ask into six categories; this simplifies the thought process making it easier to work through. The second point I liked was how he tied together response and detection. Throughout the post he touched on things to consider to improve detection as you respond.

Triage Questions

Continuing along with what questions should be answered when responding to security incidents is David Bianco's article Triage Any Alert With These Five Weird Questions!. David defines alert triage as "the process of going through all of your alerts, investigating them, and either closing them or escalating them to an incident." By far, this is one of the most common activities for those performing detection and response. The article walks through five questions one should ask while performing alert triage. The article is well worth the read since it highlights things to consider when performing this work.

If Antivirus Fires Triage that System

Speaking about triaging and alerts. Adam over at the Hexacorn blog put together an awesome post (The art of disrespecting AV (and other old-school controls), Part 2) highlighting a critical point. His conclusion was "when you see an AV alert you need to triage the system, because it has been compromised + there may be still some undetected malware present on it." I couldn't agree more with the items he brought to light in his post and his conclusion. Too many times you see organizations complacent in that their antivirus solutions detected and removed a malware without any additional work or trying to answer questions. Too many times I've seen where antivirus hits on one file but missed numerous others. The line of thinking things are all good "since antivirus got it" is broken and in the end risks leaving compromise systems on the network. Furthermore, triaging every single antivirus alert provides visibility into the network and the methods being used trying to compromise an organization.

Seeing the Complete Picture

Rounding out this linkz post is the article What It Looks Like: Malware Infection via a Weaponized Document by Harlan Carvey. Harlan obtained a weaponized document, executed it in a test system, and then walked through his examination to identify artifacts on the host. The document he obtained was already written about from the dynamic analysis perspective but it didn't address artifacts left on the system. The thing I really liked about Harlan's post is it addresses an area that very little is written about. There are a ton of articles about dynamic analysis and offensive techniques such as exploiting a vulnerability but there is not as much about attack vector artifacts left on the system. The attack vector artifacts showing how it looks when a hacker (or cracker) uses a path or means to gain access to a computer or network server in order to deliver a payload or malicious outcome. Over the past month there have been various articles mentioning the increase in malicious documents being used to compromise systems. The malicious documents mentioned vary as well as their payloads vary. However, the activity left on the system due to a malicious document will remain the same. This activity is what Harlan addressed in his post and the information helps to bring a more complete picture into view. Harlan also provided his thoughts on a few take-aways for detection and response.
Labels: , ,
  1. Corey,

    Most of the threat intelligence I see is written by malware RE folks, and detection mechanisms are focused on the network. However, as an incident responder, I'm in a position where I'm responding well after the initial compromise, so I'm interested in those artifacts that are most likely to remain weeks (or months) after the fact. We still need to be able to address things like window of compromise, initial infection vector, and scope if we're going to truly remediate and protect an environment.

Post a Comment