Omar Herrera wrote: [ ... ] > Some issues: > Point 3 should be decided as fast as possible no matter the decision > taken (forensic policies and procedures should be in place already). This point is well worth repeating. With regard to the Subject of this thread, it's useful to note that a compromised system may be actively doing something harmful (like being used as a DoS slave amplifier), it may be doing something passively harmful (like sniffing the local networks for passwords/CC info/etc), or it just might be providing resources to unauthorized users (disk space, bandwidth, say if it's being used to host wares as an FTP server, or a IRC bouncer), or it might be doing nothing at all. And the compromised system could range from air-traffic control systems (providing critical services with human life potentially at risk if the system is taken down abruptly; case #1 below), to developer test machines, normal workstations, or spare hardware that could be taken down permanently, at any time, with no (serious) adverse consequences. Whether you should take a specific action, whether it be rebooting the machine cleanly, yanking the power cord immediately, or anything else, should take both the importance of continued uptime and the severity of the malicious activity-- or lack of activity-- currently taking place. If a user calls you over and says "hey, I double-clicked on this message that said ILoveYou, and all of a sudden, my hard drive starting freaking out", pulling the power cord before the worm finishes mangling all of the local images and starts hunting for network drives to damage would be a good move even in hindsight. And that's what it comes down to: you plan ahead so that you don't do things you end up regretting in hindsight. For example, whatever else you do, be *sure* to unplug the ethernet cable (or sandbox the machine behind a tight firewall, on put it on a test network, etc) before you power up the compromised system. If the machine is configured to do certain things upon system boot-- like email a sniffer logfile containing passwords see on the local subnet to the guy who r00t'ed the box-- and the machine is still connected to the outside world, you will be sad. > If taking decision C, could the company argue that by isolating the > system it is not failing to perform with due diligence? > Two cases for analysis: > * A critical system in an airport that controls air traffic > * The mail server of an ISP where no backup or replacement is > available at the time The second case means that the organization didn't already have a secondary MX in place, which seems unlikely for something which calls itself an "ISP", but losing a reader box and not having an adequate replacement lying around might happen. Losing an SMTP relay just means that other machines have to queue your mail until you do get a replacement up; not a big deal, usually. -- -Chuck ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sun Mar 30 2003 - 10:58:19 PST