Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security IT

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."
This discussion has been archived. No new comments can be posted.

What to Do When Your Security is Breached

Comments Filter:
  • Got done.... (Score:5, Informative)

    by Creepy Crawler ( 680178 ) on Monday March 26, 2007 @06:24PM (#18494225)
    I got done reading this, and it's pretty dumb.

    "If you're a big company, you already have a security team. If not, hire one." DOH!

    That smacks me of the same kind of response from slashdot about legal advice... "Im being sued by the RIAA, should I ignore it?"

    Still, why not gander around and see what the the real security experts and such say about such matters:

    The Coroners Toolkit [fish2.com] Tools for Unix

    Nagios detection suite [nagios.org]

    Honeypots for 'sticking hackers' [honeynet.org]

    And there's the wonderful tools in the Linux kernel for bridges and such that can be made to monitor data as if there was no computer there at all. Also, PF in FreeBSD can route and filter based on much more criteria than Linux netfilter can (like via OS).

    You should have a secure layout of your network along with a respectable sensor network. The Sensornet should be separate from the general network.

    If you already work in IT, these things should be obvious, as it is the similar measures required for data recovery on non-hack problems.
  • My version: (Score:5, Informative)

    by Alex Belits ( 437 ) * on Monday March 26, 2007 @09:27PM (#18496095) Homepage
    1. Keep the suits and incompetent people the hell out!

    Once a compromise happened, there is no time to listen to lawyers or marketing executives. If they have anything to say, they would write a document where they list all recommendations they can care about -- for example, how "This site is pwn3d" web page is supposed to look like, whether it is a good thing to send all users a letter "please cancel your credit card", or what information can be released to authorities. If they didn't do that already, let them write those things while sysadmins are working.

    This, of course, means that if there is only one sysadmin competent enough to investigate and fix the problem, then he would have to work on it alone.

    2. Shut it down and investigate changes made by the attackers.

    Before doing any investigation or recovery, shut the compromised and potentially compromised devices down. No malicious code should remain running. Whatever services should remain, must run in the minimal mode on separate hardware. For example, keep email running on a newly installed box. All investigation should be done in a clean environment -- drives moved to dedicated "clean" machines, or original servers booted from clean images (CD, PXE, replacement drives) on a private subnet, not accessible to anyone but people involved in incident response. Make full images of compromised hosts' storage whenever possible.

    Backups are your friend. IDS logs are, too, but make sure that your IDS isn't compromised, and actually recorded something meaningful.

    3. Don't worry about the person who originated the the attack.

    Find its results and, if possible, method. Likely there will be at least one person within the company (malicious or more likely negligent) and at least one outside. Screw them both, they don't have access to your network anymore because it's off.

    4. Immediately restore known-clean backups, perform audit on potentially compromised data and update the systems.

    Backup is "known-clean" if investigation shown that it is from a state before the attack and does not contain vulnerable versions of software or compromised authentication information that allowed attack to happen. Usually some data has to be restored from a compromised system because it's more recent than backup (or because you are an idiot and forgot to back it up). Audits are supposed to be painful. Once data is in place, update software and configuration. Erase all compromised authentication keys and tokens.

    5. Document the process.

    I mean, technical details.

    6. Tell everyone that they are screwed.

    Explain to every office drone that they are going to get new passwords. They won't like it, so keep your LART ready.

    Oh, btw:
    http://abelits.livejournal.com/30214.html [livejournal.com]
    http://abelits.livejournal.com/30681.html [livejournal.com]
    http://abelits.livejournal.com/30872.html [livejournal.com]
  • Mostly old news (Score:2, Informative)

    by neilbaby ( 53319 ) on Tuesday March 27, 2007 @08:40AM (#18499917) Homepage Journal
    At the risk of tooting my own horn, I blogged [bea.com] about similar material about a week before the Dark Reading publication. My blog focused more on the PR foul-ups that companies tend to make and ways to prevent those foul-ups rather than the technical response. It was based off of a recent Google vulnerability that got publicly posted as ?revenge? by the vulnerability discover who was unhappy about having not gotten enough credit for previously reported Google vulnerabilities. Neil Smithline BEA WebLogic Security Architect

For God's sake, stop researching for a while and begin to think!

Working...