What to Do When Your Security is Breached 177
ancientribe writes "When you've got a full-blown security breach on your hands, what do you do? If you've been smart, you'll already have a computer security incident response team — and a plan — in place. But many companies are too resource-strapped to have a full-blown, fully-tested incident response strategy. DarkReading has some tips on what to do — and what not to do."
Sometimes yes sometimes no (Score:2, Interesting)
In some cases, you may NOT want to pull the plug.
Sometimes proper forensic evaluation requires both plugs remain attached until the experts are done.
As the article said though, sometimes you have to balance continuing harm with the need to preserve the crime scene.
Re:The problem is (Score:5, Interesting)
I suppose that most Microsoft shops wouldn't even know if they were breached, because most breaches don't actually desctroy data, they just steal it.
It's so much worse than that.
Back in my younger days at a summer tech job for a US school district, I found that an NT4 SQL server had been compromised a group of people. They were based out of France, I think, from what I could tell from the IP addresses, and had actually set themselves up quite nicely, with organized file structure and their own IRC and FTP server running on it. They were using it as a repository to store files and a few French movies. After I told the sysadmin in place at the time about it, I was stunned when he said, "Well, are they hurting anything?"
After some persuasion on my part, he rebuilt the server. Three times. After it kept getting hacked by the same people.
I dunno, it's sorta... news to me (Score:5, Interesting)
For starters the advice to wait until the whole team is assembled, including the accountants, lawyers, etc, then holding meetings to determine your strategy, etc, before even unplugging the damn thing... dunno, it seems to me bordering on criminal. Yes, you don't want to let one lone cowboy handle it from end to end, but a trained admin could at the very least be able to unplug the computer from the network and isolate the damage before it goes any worse. Or know enough to decide if it has to be unplugged. But if he thinks it is, it should be step #1 not IIRC step #4 after you're done holding your meetings and informing the employees and having PR draft the vaguely worded announcement that tries to make it sound unimportant to your customers.
Waiting for the designated accountant, and the designated lawyer, and the HR guy, and God knows who else to arrive at the middle of the night and hold their meeting while a breach is in progress and someone is downloading your productive database, seems to me dumb to the extreme. To reuse your example, it's like saying you should keep your hand in the stove until you talked to your lawyer and your doctor and a designated family member, make sure you have a strategy, and only then pull the hand out. By that time, it could be burned to a crisp.
I mean, by the elder Gods, especially when you include such non-techies... surely you've seen these guys when they have to give you a spec for a program. If you wait for them to hold a meeting on such technical issues as "are we in aggreement that we need to unplug the server?", at least one goes into responsibility avoidance mode and refuses to be remembered as the one who took any decision, at least one goes into alpha-dog-pissing-on-everything-to-mark-his-territ ory mode, etc. It's a meeting that could well take hours without going anywhere.
Frankly. I'd rather just trust the "cowboy" admin to know his job well enough, and know whether he needs to unplug the servers because of a serious breach, or just let it be if it's just a DDOS, while the non-techies deal with their own domain of competence. There is _nothing_ a non-techie can add that's meaningful to that kind of an inherently techie decision. Just like you don't have the admins tell the company lawyers what to do, have the decency to not have the admin hang around and wait for the lawyers to tell him what to do. It's not only a better use of the admins' time, it's also a better use of the lawyers' time, who could be doing something that's a better use of _their_ skills in that time.
I'll aggree, though, that the advice at step 1 seems to be dangerously content free. It's something which, although it may sound otherwise, actually noone ever actually did as such. Even if one "cowboy" admin did offer to contain the incident, it's not like someone let him deal with the _whole_ affair, including the HR, legal and financial aspects. Which is the domains they mention that you need on that team. More likely the "cowboy" just dealt with the servers, while the lawyer did his own job, the HR guy did his own, etc. I don't think (m)any people let the admin draft the press release too, for example. So the whole "don't let one 'cowboy' deal with it all" advice is basically like saying "don't try to fly on a broomstick off a bridge": you weren't actually planning to do that anyway, and it's not really giving you any insight you didn't already have.
Finally, I don't know, maybe I'm just paranoid by trade, but the whole thing looks more like PR and a bit of an IT-for-PHBs magazine than anything actually serious about security or IT. It reads like little more than an advertisment for the three companies they mention, with a bit of a scare theme to make you contact them ASAP, than anything else. I'm also a tad cir
Re:Sometimes yes sometimes no (Score:2, Interesting)
You can preserve the evidence of how you got owned, like the means of entry, how privilege elevation was performed, what was done on the system. It's not uncommon for crackers to upload a binary, execute it so that it's running in memory and then delete the binary file, so if the bash_history was wiped you may never find any evidence it was even there unless you looked at the system while it was running. Figuring out how you were compromised may help you prevent it from happening again.
Re:not necessarily (Score:3, Interesting)
If you are big enough to have an Incident Response Team worth talking about (ie, more than the single IT guy), you should have seperate security analysis/reporting ability beyond what the box will report.
story (Score:5, Interesting)
Enter the FBI, who showed up in my roomate's lab asking about his computer (amoung other things). Picture yourself a grad student answering his lab door to find men in suits (an uncommon experience) who say they're part of the FBI (also uncommon), and mean it (still less common). After some questions, it was hesitantly established that my roomate was not the hacker serving root kits from his home computer.
From there, the FBI (with our permission) bugged our appartment. They put a "tap" in our appartment, which consistend of a special switch and a *very* loud windows machine that sat on our internet connection listening for hacker activity. The installation of the tap involved 7 FBI agents, none of which new nearly as much as my roomate about networking (that the broadcast ping couldn't get through their special switch with the word "tap" on it was a real mystery). Neadless to say, I didn't fool around with bittorrent or the like durring that time.
After a month or two, they caught the hacker (who was sweedish, apparently), and eventaully prosecuted him successfully.
Point is: sometimes it is useful to not reinstall immediately when hacked -- it can result in a good story :)
Re:The problem is (Score:4, Interesting)
I know some IRC groups were the members get their company servers to provide dumps and bots. And of course non one ever knows it is going on.
So I'm going to guess that if they went through the trouble of hacking it three more times, it was probably an inside job to some extent.
Story's author writes back (Score:2, Interesting)