Layer 8

The ugly reality of security incidents.

It sounds kinda romantic, doesn’t it? Your 133T skillz against those of the wily hacker. Showdown at the 0K corral. (Heh. Would that be “zero k”?) But most of the time, it doesn’t happen that way—at least, not to me. Here are some of the harsh realities of security incidents:

They usually start with someone frowning at the screen and saying, “That’s odd ...“
It can take a really long time whether you even know for sure that you’ve got a breach.
Sometimes you can work on something for hours and then figure out that it was just some weird-ass behavior on the part of some application.
When it comes to an insider, not everyone will agree that it was really a breach of security, much less one requiring disciplinary action.
In fact, sometimes you have to work instead on protecting the network against someone who is behaving badly, yet whose management refuses to fire him.
Does two people arguing over control of a root password constitute a security breach? If one of them changes it out from under the other one? You tell me.
There is very rarely, if ever, a “takedown.“ Most of the time you just manage to block the bad guy out and hope that he’ll move on to another target.
It can take law enforcement a really, really, really long time even to get around to looking at the evidence, much less decide whether they have a case.
You’ll never know whether you found everything. You just have to live with that.

Posted by shrdlu on Sunday, November 12, 2006
(3) Comments • Permalink •

Next entry: Metrics reloaded.

Previous entry: Not only does it go all the way to 11, but it does so EXPONENTIALLY!

Comments

dan

on 11/13 at 06:25 AM:

Its funny what you mentioned, we spent 60 days hunting down a person who was doing bad things, but we needed enough data, and a good enough attribution ip to person (even with the ISP not wanting to help) to build an air tight case enough to deliver a C&D. (Cease and Desist). Had to make sure though, but no, it wasn’t anything like the matrix tracking someone through a wire, which was a bummer. Cheers/r/Dan

shrdlu

on 11/13 at 07:10 AM:

Heh. Thanks, Dan. Nothing like having an incident unfold in sssllooowww mmmoottiiooonn ...

LonerVamp

on 11/13 at 09:39 AM:

Yeah, reality in security is still something that not many people are directly dealing with. It’s been something on my mind lately, but hasn’t quite made it around my head enough to spill out anywhere. You’d think from reading NetworkWorld, CIO/CSO, ComputerWorld, and most of the media that we all know what to do and we’re running about doing it diligently, all these best-practices. But reality is far, far, far from that.

I did post recently on an incident response blog that talked about the proper way to preserve evidence of a scene. But the reality is how many admins have time and backing to take proper steps? And just how quickly does it really get designated a security issue? It helps that those admins have proper training and regularly practice those skills so they can do them without thinking…

I think you could add another bullet point: Too often security incidents are the result of someone just noticing something odd while performing some other task. Wow, our CPU is pegged on the development server…whoa, is that a worm process? Whoa, who the fuck reconfigured the firewall to put these servers’ balls out on the Internet for two months?!? (true story)

I’ve found that most incidents don’t make it outside of the immediate IT team dealing with them, or their manager. Tracking and metrics on issues is poor, at best.

Perhaps this is still best. Perhaps management should only give proper budget to IT/security and just ask them the simple question, “How do you feel about our security?“ Instead of trying to teach management about IT/security, or trying to get those liaisons who can “speak” business and IT at the same time, or getting IT people to learn business…perhaps they just need to trust each other and ask the important questions.