We spent the first few posts in this series on understanding what our data collection infrastructure should look like and how we need to organize our incident response capability in terms of incident command, roles and organizational structure and Response Infrastructure. Now we’ll turn to getting ready to detect an attack. It turns out many of your operational activities are critical to incident response, and this post is about providing the context to show why.
A decade seems like a lifetime. And in the case of XX1 it is. You see I’m a little nostalgic this week because on Monday XX1 turned 10. I guess I could confuse her and say “XX1 turns X,” mixing metaphors and throwing some pre-algebraic confusion in for good measure – but that wouldn’t be any fun. For her – it would be plenty fun for me. 10 years. Wow. You see, I don’t notice my age. I passed 40 a few years back and noticed that my liver’s ability to deal with massive amounts of drink and my…
First, for our non-technical readers who want to know more about this Firesheep/sidejacking thing, check out my relatively non-geeky article over at TidBITS.
In our last post we covered organizational structure options for incident response. Aside from the right org structure and incident response process, it’s important to have a few infrastructure pieces (tools) in place, and take some preparatory steps ahead of time. As with all our recommendations in this series, remember that one size doesn’t fit all, and those of you in smaller companies will probably skip some of the tools or not need some of the prep steps.
Yep, another white paper is in the can. As you all know, we turn a lot of the research we post on the blog into comprehensive white papers after we gather feedback from the community on our research. You may remember the Monitoring up the Stack series Adrian and Gunnar drove last month, which has now been packaged, edited, and (with the help of our editor Chris Pepper) turned into English.
Ah, the investment bankers are circling again. Late Friday rumors started circulating about IBM discussions of acquiring Fortinet. With a weekend to stew and the gap open for Fortinet stock, it makes sense to think about what a potential deal means, right?
I have very little social life, so I spent my weekend researching trends in database security. Part of my Saturday was spent looking at Microsoft’s security model for the Azure SQL database platform. Specifically I wanted to know how they plan to address database and content security issues with their cloud-based offering. I certainly don’t follow all things cloud to the degree our friend Chris Hoff over at RationalSurvivability does, but I do attempt to stay current on database security trends…
What a wild few weeks. Talk about been there, done that, got the t-shirt.
It all started October 9th, when I finally achieved a goal I’ve been chasing for well over a decade, and completed my first Olympic-distance triathlon. (1.5K swim, 40K bike, 10K run – those are distances, not dollar values).
In our last post we introduced some of the key principles of incident response. Today we will focus on the major roles and organizational structure.
Imagine you’re a young, skilled techie just starting your career. Maybe you’re fresh out of school, or still in an internship program. Or maybe you’ve been out of school for a few years, working your way up through various companies in the industry. You came from a normal background – possibly you thought about the military at some point, but the allure of working in technology drew you into the private sector. Your skills are solid, you produce at work, and you don’t get into any trouble…