Hacker News new | past | comments | ask | show | jobs | submit login

From another article[1]:

> By entering through a router in Dulles, Va., and installing a back door for access, he intercepted DTRA e-mail, 19 user names and passwords of employees, including 10 on military computers.

If the security issue was found internally, you can just patch it, do a cursory check to see if there is evidence of intrusion, and go on your way. When you find the security issue as a result of being hacked, now you not only have to patch to flaw but also investigate what was compromised, but may have been modified, etc. That would entail taking down all of the potentially affected systems for evaluation, which means a big hit to productive work while the investigation is underway.

[1] http://abcnews.go.com/Technology/story?id=119423




Valid point. I did miss the installed backdoor. But I disagree about the "cursory check" - at the point of finding a vulnerability on a production system, one must assume compromise and be exhaustive. And that means it's costly, regardless of who found it first.


"Cursory" was perhaps the wrong word. In any case, taking down your company's network for forensic investigation is extremely costly - it's not something you'd do unless there was evidence of an intrusion. It would have been a whole lot cheaper to take care of this incident if the problem was found internally, rather than performing damage assessment and control after the fact.


> In any case, taking down your company's network for forensic investigation is extremely costly - it's not something you'd do unless there was evidence of an intrusion.

It's not something you would do even if there was. The sensible first response when you find a vulnerability is take a snapshot of the existing system -- you want to do this before patching the vulnerability in any event, in case the patch causes serious problems and has to be rolled back. Then you can conduct your investigation against the snapshot without having to disable the production systems.

Which is why I think you're making a very strong argument for why attributing "mitigation costs" is a farce. Because you could easily find a company who would take down their network and incur very high costs unnecessarily. The overreaction is not the fault of nor is it under the control of the attacker.


> The sensible first response when you find a vulnerability is take a snapshot of the existing system ... without having to disable the production systems.

Which would involve taking the system down to conduct the snapshot. What gets put back in place will depend on the severity of the breach, perceived threat, sensitivity of data, etc. They had no way of knowing exactly how sophisticated the attack was until the cops finished their investigation - is this some script kiddie or the Chinese military? I'm not going to worry about a foreign intelligence service if I'm serving up web pages for an eCommerce site, but I would if I were working for NASA. Just because you patch the vulnerability in question doesn't mean you've denied the attacker access to your network...

If they suspected additional backdoors have been added during the breach, the affected systems would need to rebuilt entirely, patched, then have data selectively restored from backup (you don't want to reintroduce to the system any malware that was saved to a backup). What other systems were accessible from the one that was hacked? Are there rootkits sending beacons home on any of them? Is there reason to preemptively take them down and rebuild them? What if one of the affected systems is a mail server/file server/etc.?

No, I don't blame NASA for overreacting. The kid pulled back technical details for a space station. The Russian government would have done the same (and may even have already been in there). NASA took steps that they thought were sensible, and they ate the costs. The kid ended up getting 6 months of house arrest and 2 years probation.


> Which would involve taking the system down to conduct the snapshot.

a) Not necessarily. Modern virtualization systems support live snapshots.

b) Taking the system down for a matter of minutes to make an offline snapshot is still dramatically less expensive than taking the system down for the duration of the investigation.

c) You still need the snapshot to be able to roll back to when patching the vulnerability in case it doesn't go well. The cost is the same whether you need it for an investigation or not because you need it regardless.

> I'm not going to worry about a foreign intelligence service if I'm serving up web pages for an eCommerce site, but I would if I were working for NASA.

You're arguing yourself into a corner. If the system is just "web pages for an eCommerce site" then taking the system offline is an overreaction. If it contains some vital national security information then you're here:

> The Russian government would have done the same (and may even have already been in there).

At which point it doesn't matter whether you know an intrusion has occurred, you have to treat it as though it had, because the likely adversary is sophisticated enough to evade cursory detection and the system is important enough to justify the expense of being thorough.


> At which point it doesn't matter whether you know an intrusion has occurred, you have to treat it as though it had...

Which gets you into benefits/trade-offs territory; I think it's probably an overreaction for NASA to take their internet facing servers and all computers on the connected networks down to investigate for possible intrusions every time a new security patch comes out. I don't think it's unreasonable for them to do so when they have credible evidence that they've been hacked. (of course, I don't work for NASA, so I have no idea what procedures they have in place)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: