Lately, I’ve been noticing some vile examples of treating information security incidents in the same way as IT “issues.”
Think about it: “my PC is slow today” vs “my $800 million wind turbine schematics are stolen today” … these are TOTALLY the same and should be handled by the same people in the same way.
People, what kind of stuff are you smoking? This is totally and certifiably crazy!
One example comes from a recent conversation with somebody who said that the sole focus of his security IR program is to “restore IT service.” So, if the attackers steal all his payment data, employee data, deploy bots [well-written ones, that don’t disrupt his IT service], change corporate records, snoop on their executives’ private messages, etc, etc, etc , his “incident responders” won’t even get out of bed. Seriously? However, if a user reports that something (probably malware) opens too many windows, and that interferes with work, they will perform their “reimage and restore” magic.
In any case, I am shocked that I have to explain it, but let me still try:
- For those who like to preach the “security and business alignment” theme, think of security IR as responding to a “business incident,” not an IT issue.
- For those stuck in compliance-land, think of a data breach. Does it reduce your IT service? Probably not. Will it affect your organization? Oh, yes. Therefore, response becomes essential.
- For those ITIL lovers, keep loving it. Just don’t confuse the word “incident” in ITIL with a security incident. This is “lead pipe vs lead guitar” all over again…
- For those with LEO thinking, think of security incidents as … computer crimes. Some are and many aren’t, but *crime* is not thought of as an IT problem.
Now, I am not advocating more silos and walls between IT and infosec (well, sometimes you do need walls – think rogue sysadmin investigations). IT helpdesk often serves as a useful “intrusion detection system” that can reveal anomalies to a security team. Similarly, remediation activities will involve opening tickets, engaging with system administrators, making system changes, etc. Collaboration and cooperation though is NOT the same as equality.
The difference between IT issue resolution and security incident response is HUGE and UNAMBIGUOUS. Keep that in mind!
Posts related to the same research project:
- Top-shelf Incident Response vs Barely There Incident Response
- On SANS Forensics Survey
- Incident Plan vs Incident Planning?
- On Importance of Incident Response
- Is That An Incident In Your Pocket – Or Are You Just Happy to See Me?
- Time-tested Incident Response Wisdom?
- Incident Response: The Death of a Straight Line
- Alert-driven vs Exploration-driven Security Analysis
- My Next Research Area: Incident Response
- All posts tagged security incident response
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
7 Comments
I often encourage and teach IR perspective by always seeking the worst case scenarios. Then pull it back and use experience, public breach info and sister/acquired/parent companies or consultants to help determine which are most likely.
It qouldn’t
Oops.
…It wouldn’t surprise me if the same person you speak of also oversaw a purchase of some large forensic suite, because “that’s how you IR”, right?
Too many nod and make the right noises – even buy some of the right stuff, but don’t have a clue.
😉
The problem is when “my 80,000 PCs are slow today” compares with “my $800 million wind turbine schema *might* have been stolen today”. That’s a harder one to prioritize.
@adrian Thanks for the comment. A worst case scenario approach is sensible, but occasionally will lead to overspending, right?
BTW, the same person probably never bought a forensic suite since investigation is not essential to restoring service faster (in his mind). If anything, investigations delays service restoration 🙁
@christophe Thanks for the comment. My point was not the priority , but the ownership and handling methods. These would still be different, even if 80k PCs….
@anton: I certainly agree with the ITIL point. There are many conceptual difference between the way ITIL consider an incident it and the way “Security” looks at the same topic. We are currently editing the new ISO 27043 and 27035 and we are doing our best to finally draw the boundaries. Just think about it: ITIL’s definition of RFC is different from IETF. Which one is right? 🙂
@dario Thanks for the comment. Do you know anybody who promised me an advance copy of those ISO docs? 🙂
This guy is getting old 🙂 i will talk to him !