The best way to understand how threat intelligence impacts your incident response/management process is to actually run through an incident scenario with commentary to illustrate the concepts. For simplicity’s sake we assume you are familiar with our recommended model for an incident response organization and the responsibilities of the tier 1, 2, and 3 response levels. You can get a refresher back in our Incident Response Fundamentals series.
This is part 2 of our Security Pro’s Guide to Cloud File Storage and Collaboration (file sync and share). The full paper isavailable on GitHub as we write it. See also Part 1.
One of the things I most enjoy when the kids are at camp is being able to follow my natural rhythms. During the school year things are pretty structured. Get up at 5, do my meditation, get the kids ready for school, do some yoga/exercise, clean up, and get to work. When I’m on the road things are built around the business day, when I’m running around from meeting to meeting.
In the latest Firestarter, Rich, Mike, and Adrian discuss the latest controversial research to hit the news from HOPE and Black Hat. We start with a presentation by Jonathan Zdziarski on data recoverable using forensics on iOS. While technically accurate, we think the intent he ascribes intent to Apple shows a deeply flawed analysis. We then discuss a talk removed from Black Hat on de-anonymizing Tor. In this case it seems the researchers didn’t really understand the legal environment around…
Now that we have the inputs (both internal and external) to our incident response/management process we are ready to go operational. So let’s map out the IR/M process in detail to show where threat intelligence and other security data allows you to respond faster and more effectively.
Our last post defined what is needed to Really Respond Faster, so now let’s peel back the next layer of the onion to delve into collecting data that will be useful for investigation, both internally and externally. This starts with gathering threat intelligence to cover the external side. It also involves a systematic effort to gather forensic information from networks and endpoints while leveraging existing security information sources including events, logs, and configurations.
In the July 2 Incite I highlighted Dave Elfering’s discussion of the need to sell as part of your security program. Going through my Instapaper links I came across Dave’s post again, and I wanted to dig a bit deeper. Here is what I wrote in my snippet:
I have been talking about data centric security all week, so you might figure that’s what I will talk about in this week’s summary. Wrong.
Every time I took a new job, on my first day I would tell the team that I hate surprises. What I really meant was a warning, not to screw something up and not tell me. That’s not really a surprise, per se. More a failure to communicate. But now that I’m a bit older I realize the importance of surprises. When you are surprised it really means you had no expectations.
This is a new series on what security pros need to know about cloud file storage and collaboration (also called file sync and share). If you have feedback please leave a comment, or eventrack and edit the evolving paper over on GitHub.