Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security United States

NIST Releases Guide to Cyber Attacks 126

Posted by CowboyNeal from the get-a-security-plan dept.
treerex writes "NIST (the US National Institute of Standards and Technology) has just released a 148 page report entitled Computer Security Incident Handling Guide (PDF). It covers the gamut, from setting up a response team to dealing with specific types of attacks: DoS, trojans, worms, malicious code, and unauthorized access. While written by a team from NIST and the contractor Booz-Allen Hamilton (BAH), they appear to have taken input from CERT and luminaries like Spafford. It is an interesting read."
This discussion has been archived. No new comments can be posted.

NIST Releases Guide to Cyber Attacks More

NIST Releases Guide to Cyber Attacks

Comments Filter:
  • So we establish "standard procedures" to deal with a standard gamut of attacks. That's great.

    Are we so naive to believe that following such advice will make us secure?

    • Re:Are these all the attacks? (Score:1, Interesting)

      by Anonymous Coward
      Are we so naive to believe that following such advice will make us secure?

      If anything, everyone following the same practices and procedures when under attack will make us all less secure.

      "OK, I just hit him with a SYN flood. Now he's going to do XXXX."

    • Re:Are these all the attacks? (Score:5, Insightful)

      by ElGnomo ( 612336 ) on Thursday January 22, 2004 @11:14PM (#8062626)
      I would think that if the majority of people did something so simple as to patch their machines, worms would posed half the threat they do now. So, yes, Education is a simple but effective measure to combat security exploits.
    • Are we so naive to believe that following such advice will make us secure?

      I don't think you could have read the article in the time it took to make your condemnation of its intentions.

      I see only good things coming out of this. Especially in comparison to the SOP up until now. There is no accepted standardized stance but what is (probably) being proposed in this document. Publishing this is a positive step in that direction. It appears (based on a cursory glance through the contents) to be focused on i

      • Re:Are these all the attacks? (Score:5, Interesting)

        by wwest4 ( 183559 ) on Thursday January 22, 2004 @11:38PM (#8062738)
        right on. currently, in the real world, if there is no procedure then things are only done if they are "business critical." most suits think that security events are unlikely, so that means security is low-prio. Most IT depts since the tech bubble popped are no longer autonomous. They are low on cash, low on available man-hours, and tied into caring more about the company's core business in terms of cash out, and risk management be damned. with an SOP, the cost and effort are easier to nail down, it's a slightly easier sell, and any sysadmin worth his salt will at least try to sneak some of it into the day-to-day.

        another thing - the idea that uniform SOP means that things will be easier to hack is pure bullshit - what would anyone recommend to the unwashed vulnerable? Maybe it would sound like this:

        - run only necessary services
        - audit and change your passwords
        - follow security news and patch accordingly
        - use virus protection
        - consider an IDS
        etc.

        sounds a hell of a lot like best practices / standard procedure to me. and NONE of that shit makes it "easier to hack." sheesh.

    • Re:Are these all the attacks? (Score:5, Funny)

      by Davak ( 526912 ) on Thursday January 22, 2004 @11:22PM (#8062671) Homepage
      They also have a 1-800 number.


      Thank you for calling the US National Institute of Standards and Technology Security Hotline.

      Please say "HOLA" now if you espanol...

      Otherwise please select one of the following selections dealing with your security problem.

      Press 1 if you have suffered a DOS attack
      Press 2 if your network has been infected with a worm
      Press 3 if your site is being slashdotted
      Press 4 if 13 year olds have defaced your web site
      Press 5 if you are running windows as your server

      Press 666 if you are a missle silo control room and have realized that someone has gained root or administrative access on your control system

      Have a nice day.
    • Oh, crud. I thought that these were the new official procedures to attack someone...

    • Re:Are these all the attacks? (Score:1, Insightful)

      by Anonymous Coward
      Yes, I think that is 'Great'. One of the problems with hackers is that while we all seem to speak the same language, the edges are filled with many regional dialects and different vocabularies.
      Many script kiddies and fresh rookie sysadmins only know about 'sploits and strangely named attacks and have no framework of 'security problem classes' to hang these ideas on. Encouraging a common vocabulary is a _good thing_ and generally goverment backed standards documents do the job.

    • Re:Are these all the attacks? (Score:4, Insightful)

      by Flower ( 31351 ) on Friday January 23, 2004 @01:08AM (#8063206) Homepage
      Wow! Who would ever think that there should be a methodology for dealing with security incidents? We should all just run around and do our own thing and, of course, the problem will be resolved. And when we catch the guy, our lack of methodology will ensure that any evidence we acquire will be usable in court.

      I'm just going to leave it at that. Anything else is just going to be a derogatory rant. IHBT HAND

  • Interesting! (Score:5, Interesting)

    by dot-magnon ( 730521 ) <co.auralvision@no> on Thursday January 22, 2004 @11:15PM (#8062629) Homepage
    This might be unnescessary for "professionals", people who know these things from before and work with it. But for the average sysadmin, this is just great! He/she could know how to:

    1. Find out what happened
    2. Close the breach
    3. Report the breach.

    If the sysadmin doesn't know how to do this, they also know where to seek help.

    I'll probably get messages back saying this is just dumb and generic, but it's better than not knowing anything at all. A lot better. All too few people know how to handle situations like this, and they will need somewhere to start.

    I'll give this thing a skim read (just read contents and some interesting paragraphs now) and get back to this ;)

    • Re:Interesting! (Score:2, Interesting)

      by dot-magnon ( 730521 )
      Oh, and I forgot - policy creation. Too many networks out there have zero security policy or a very bad existing one. This leads to a series of opportunities for intruders, and if these basic flaws are closed, they've taken a big step forward in securing their networks.

      • Re:Interesting! (Score:5, Informative)

        by randyest ( 589159 ) on Thursday January 22, 2004 @11:51PM (#8062820) Homepage
        As you will no doubt glean if you read the document completely, there are a lof of "Oh, and I forgot"'s in order -- that's why they made the doc and, presumably, why it's posted here. So, please hold the preemptive (and thus incomplete) summary. It's useful info for us all to read.

        Then again, looks like all the other threads below are mired in conversations about nukes, Amerika-bashing, and other offtopic stuff, so at least you're on topic.

    • Re:Interesting! (Score:3, Insightful)

      by zensufi ( 743379 )
      Exactly! It's like U.S. Army Manuals. They are very bland, general procedures for any platoon to follow to do things that a Green Beret team could do fluidly and efficiently without even thinking about it. They aren't written for the elite though, they are written for the common man.

      "What are the basic things I should do in this particular situation?"

      The idea is to write something that someone of an IQ of 100 can understand and implement without causing too many problems. Someone in another thread

      1. Find out what happened
      2. Close the breach
      3. Report the breach.

      4. Find out why is it happened like due to which poor laws;
      5. Blame your goverment for letting spammers to exploit the only desktop system product of the only desktop software company;

  • IJDE (Score:5, Informative)

    by Anonymous Coward on Thursday January 22, 2004 @11:15PM (#8062631)
    The International Journal of Digital Evidence [ijde.org] is also worth keeping up with, if this type of stuff interests you.

  • Gleam Something From This (Score:5, Insightful)

    by munch0wnsy0u ( 619737 ) on Thursday January 22, 2004 @11:20PM (#8062661)
    Beyond the typical vapid governmental reports, this is a step in the right direction. Anything to create a buzz around security, especially computer security, will serve the public well. This is what needs to happen: standardization. The government has done a commendable job in creating standards for dealing with national security - why not extend that to computer security. All these posts that do nothing to note the fact that this is a good thing don't see past the .gov TLD

  • BAH? (Score:4, Interesting)

    by J3zmund ( 301962 ) on Thursday January 22, 2004 @11:21PM (#8062664)
    Not too long ago, they were in hot water with the US Navy for letting some websites get hacked by leaving the default admin passwords in place. No joke, my friends work there!

    • Re:BAH? (Score:3, Insightful)

      by adrianbaugh ( 696007 )
      Don't base your view of them on one incident (or group of related incidents). It seems quite possible for a security consultancy to be really hot on security but initially screw up their personnel procedures so that they accidentally hire a monkey. If the person responsible was either clued up or fired, and hiring policies tightened so that kind of dumbness wasn't repeated (and more importantly if the problem itself was fixed in a professional, timely manner) then I'd be inclined to give them once more chan

      • Re:BAH? (Score:2, Informative)

        by J3zmund ( 301962 )
        Well, the original server-sitter left BAH before the break-ins occured. His position prior to building and maintaining webservers for a DoD contractor was dog-walker (no, seriously, he walked dogs for a living).

        The people who took over his position didn't change the passwords. They have since been re-educated about security and best-practices. Nothing confidential was on the servers in question, but it looked bad for their web-team here in San Diego.

      • Re:BAH? (Score:2)

        by kir ( 583 )
        BAH is not a security consultancy. They're your typcial government IT contractor. Others include CSC, Lockheed Martin, EDS, and SAIC (who I work for) (and buttloads more, but those are some of the major players). Lots of good folks work for them. Unfortunately, idiots are there too. They all do a variety of IT work for the gov - basic sysadmin, web design, system design, project management, security (which I do), etc.

        Just FYI.
  • It seems quite apropos to revisit this thread [slashdot.org], considering the article topic.

    -JT
  • Here's a mirror [coded.net]

    Mirror provided by Coded Networks [coded.net]
    Sponsored by Dedicated Gamer [dedicatedgamer.com]

  • Corporate Incident Response Checklist (Score:5, Funny)

    by Jonathan Quince ( 737041 ) on Thursday January 22, 2004 @11:29PM (#8062702) Homepage

    Guide for Sysadmins: Upon learning that your systems have been penetrated, proper incident response is as follows:

    1. Scream. Hold head between hands and moan.
    2. Check passport, one-way tickets to South American country of choice. Express relief that the emergency escape kit is still operational.
    3. Remember advising boss to recind deparmental policy of secure sticky-note-on-the-monitor storage for passwords. Recall boss' gales of laughter in response. Take hefty swig of Jack Daniel's.
    4. Remember advising boss to please not open random e-mail attachments. Recall boss' blank stare in response. Suck on barrel of .357 revolver for 5 minutes or until sufficiently calmed down.
    5. Remember pleading with boss to allow filtering executable attachments. Recall boss' response. Almost pull trigger.
    6. Resist urge to yank server out of rack and dump out nineth-story window.
    7. Advise boss of break-in. This starts the long chain of blame-passing that ends when the CEO sacks 5 random people in middle management and below.
    8. Sit back and watch the spin machine start the vital post-incident response protocol of figuring out who might know what happened and silencing them.
    9. ???
    10. Profit!

  • Does it say... (Score:5, Funny)

    by Black Parrot ( 19622 ) on Thursday January 22, 2004 @11:32PM (#8062715)


    ...what to do in case of a Slashdotting?

  • Text Version (Score:4, Informative)

    by Hal The Computer ( 674045 ) on Thursday January 22, 2004 @11:54PM (#8062837)
    You're going to need a text editor that supports lines longer than 80 charachters, but if you have one, I've made a decent zipped text file from the PDF for people with slow connections. As always NO WARRENTY WHATSOEVER.
    Computer Security Incident Handling Guide.zip (113K) [telus.net] (zipped text file)

  • A good idea (Score:5, Insightful)

    by unstable23 ( 242201 ) on Thursday January 22, 2004 @11:55PM (#8062844)
    I think it's actually a good use of taxpayer money, which is the first time that I've said that in public.

    If nothing else, it provides a good framework to start from, especially small companies/non-profits etc, where they don't have the resources to hire a full-time crack security team. This helps them set priorities and useful business things like that.

    I'm really quite surprised people are being negative about it.

    • Re:A good idea (Score:3, Insightful)

      by thedillybar ( 677116 )
      If you're employed by the IT industry, you should support taxpayer money being spent in the IT industry.

      After all, the government isn't just taking taxpayers money and spending it. They're taking our money and then giving it back to us (once we work for it).

      Either they spend it on cool reports like this, or they spend it on something else and it goes to somebody else. Not only is it financially supporting the industry, it's also providing us with some useful information.

  • Why is it? (Score:4, Insightful)

    by treerex ( 743007 ) on Friday January 23, 2004 @12:00AM (#8062869) Homepage

    I don't understand why people immediately dismiss a report coming from NIST as being worthless USG noise while many of the same "arguments" against this paper could be made against books like Incident Response: Investigating Computer Crime or Counter Attack or any of the other n+1 books on this topic that exist.

    Harumph.

  • Can't remember the exact quote, but it's something like 'if your system lets anyone use it, than it can be used by anyone'. Ie if people can use it, than people that shouldn't be able too, will find a way too.

    Standard response to standard attacks? Sounds like someone's played too much Mike Tyson's punchout. If he tries to do a stack overflow, I log it as a possible attack, then I give him a power punch and his pants fall down.

    Seriously, though the vast majority of attacks are of a common variety. The av

  • "... Consider limiting outbound connections that use encrypted protocols, such as SSH, HTTPS, IPsec. Permitting unncessary encrypted connections may allow users to perform actions that security controls cannot monitor. For example, a user could establish a SSH connection to an external server and download illegal materials; because the connection is encrypted, network security controls would not determine the nature of the activity. Possible methods for limiting the traffic include firewall rulesets and
    • People who know what they're talking about.

      Egress filtering. Application-level firewalls. This is EXACTLY what they exist for.

      • Egress filtering. Application-level firewalls. This is EXACTLY what they exist for.

        Sadly, they exist more to make a quick buck by giving ignorant admins a false sense of security.

        Transports which tunnel through the HTTP application layer [ssimicro.com] (not just SSH on port 80) using fully obscured forms of encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example, primarily because there are presently no proxies capable of

        • Not really, no security measure is absolute, i.e. no single step will guarantee absolute security.

          Tunnelling over HTTP is only useful if the remote system is capable of stripping HTTP headers then forwarding the data to the desired service, you couldn't connect direct to an ssh server like that. Setting this up is a bit beyond "the non-technical PC user", although its certainly not an impossible task. It would stop 99% of people right there.

          HTTP application layer firewalls are not just used for blocking o

          • Setting this up is a bit beyond "the non-technical PC user"

            They don't have to set up the HTTPort servers [htthost.com]. But if they wanted to, it's no more difficult than running an installer on their broadband-connected home PC.

            The real problem is that when you don't block things like SSH, you can log when and where such connections are going. When you do, determined users migrate to something like HTTPort, and now you loose the ability to track such connections.

            HTTP application layer firewalls are not just use

    • Original Post + Section 3.1.1 - Preparing to Handle Incidents
      "Contact information for team memebers and others within and outside the orgazination ... public encryption keys (in accordance with the encryption software described below), and instructions for verifying the contact's identity"... SSH = Shell + encryption, HTTPS = HTTP + encryption!

      The crap only gets crapier.

    • Limit outbound encrypted traffic? Damn straight! (Score:5, Interesting)

      by Nonesuch ( 90847 ) on Friday January 23, 2004 @01:17AM (#8063240) Homepage Journal
      "... Consider limiting outbound connections that use encrypted protocols, such as SSH, HTTPS, IPsec. Permitting unncessary encrypted connections may allow users to perform actions that security controls cannot monitor. For example, a user could establish a SSH connection to an external server and download illegal materials; because the connection is encrypted, network security controls would not determine the nature of the activity. Possible methods for limiting the traffic include firewall rulesets and URL filtering..."

      Who the hell wrote this crap?

      Apparently, somebody who knows how smart slacker geeks get their porn, and wants to put a stop to it.

      No really, blocking SSH/ESP and tracking HTTPS is a reasonable suggestion -- if anything, I'd say the above doesn't go far enough. The excerpted paragraph doesn't mention the more serious risks of SSH (port forwarding, tunneling, etc).

      I'm not particularly worried about a smart internal user establishing an SSH session to the Internet and downloading "illegal materials",

      I'm worried about the airhead secretary who brings in a floppy provided by her uberhacker boyfriend, and runs a rootkit, setting up an outbound SSH session providing him with a command prompt on her workstation...

      That's just one risk of permitting outbound crypto channels...

      • No really, blocking SSH/ESP and tracking HTTPS is a reasonable suggestion -- if anything, I'd say the above doesn't go far enough.

        Reasonable? Pointless.

        Applications which tunnel through the HTTP application layer [ssimicro.com] (not just SSH o port 80) using fully obscured forms encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example. Primarily because there are, at this time, no proxies capable of blocking them.

        And as

        • I guess, since all security measures are ultimately subject to some sort of circumvention, that we should just not bother?

          The point is to reduce exposure in cases where it cannot be completely removed. This limits the focus of where you need to manually apply the use logs, IDS's, leaps of inspiration, etc.

          Forcing everyone out the same few, comparatively unusual gates is far better than leaving them all open.

          • Forcing everyone out the same few, comparatively unusual gates is far better than leaving them all open.

            The more you make people go through things that don't appear to be gates, the less you can keep track of what is coming and going.

            If you have SSH ports open, at least you can log the traffic. If you force users to rely on an HTTP application layer tunnel like HTTPort, then you'll never know what they are doing or where they are doing it.

        • Reasonable? Pointless.

          Blocking SSH/ESP and tracking HTTPS is reasonable, in part because it catches the "low hanging fruit", users and automated attack tools not smart enough to try less alarm-triggering channels first.

          Applications which tunnel through the HTTP application layer (not just SSH o port 80) using fully obscured forms encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example.

          Like restrictive

      • Overall, I agree that limiting SSH and HTTPS connections makes sense. However, if you are in a NOC or any other environment where engineers or technicians access routers and other equipment using SSH instead of telnet, then you have to be careful about this. Even with RADIUS and TACACS, many organizations prefer to use SSH instead of telnet for remote access. This is an unusual case since it applies to ISPs and other companies managing networks.
    • Principle of Least Privilege. One of the 1st lessons of Security 101.

      Reread what you just posted and think about what it is saying instead of just reacting to the suggestion that you should limit encrypted connections.

    • Encyrpted communication. (Score:3, Insightful)

      by Fzz ( 153115 )
      Allowing encrpyted communication with untrusted hosts is rather like meeting a stranger in a dark alley; whatever happens there won't be any witnesses.
    • So, if they can't monitor you, then you're *obviously* doing something WRONG.

      I got laid off from a contract recently because of this. "You made an SSH connection to an outside machine" they said. Well, yeah, I checked my mail with Pine. I never signed anything saying that I couldn't do this, it merely because an arbitrary policy designed to get rid of anybody that might threaten the dominance of "management."

      It was really lame.

  • Issues on accuracy (Score:2, Informative)

    by Anonymous Coward
    I can tell that certain parts of the document were not written by people who have actually done the work. For example, a portion of it talks about write-protection software. Unfortunately it is in the wrong section where they talk about a live response. I'd love to see them apply a write protection device on an active Windows system!

    Typical Booz-Allen crud. We hated these guys when I worked in the gov. Our command once paid over 250k for a 2" high report that simply re-hashed the interviews they conducted

  • There's one HUGE thing missing here. (Score:3, Insightful)

    by Dolemite_the_Wiz ( 618862 ) on Friday January 23, 2004 @04:12AM (#8064080) Journal
    A section on telling organizations to test the policies and procedures that are put into place to work out any kinks in detection and reporting.

    If you put all these policies, processes, and procedures into place and don't have a Mock intrusion or emergency, you won't know how good or bad your incident response will be.

    Dolemite
    ____________________
  • Whats the standard response to republicans peeping at your internal files?

  • It's simple but that's what you need. (Score:3, Informative)

    by gelfling ( 6534 ) on Friday January 23, 2004 @11:35AM (#8065943) Homepage Journal
    While you all give mad props to each other about how much you know and how silly this is, there really are thousands of admins and others who need to be told to scratch their ass with THIS finger. Whether it's institutional paranoia, fear or lack of knowledge, skill or training - most of the problems we experience out there are easily preventable if someone enforced it, someone audited it, someone got educated in it or someone was simply TOLD to do it.
  • This work from the NIST is better than nothing. Even if it makes some organizations' responses predictable, it is better than the predictability of total disarray. And it gives consistency to policy. Plus, once I've ploughed through the entire 148 pages, I'm sure I'll find at least the seeds of a "DIY" policy that requires organizations to figure it out for themselves, based on information and training, rather than just giving up, passing the buck, and getting 0wn3d.
  • With the NIST releasing their new report; is there a "third party" agency that is doing any independant review of the suggestions in these reports/guides released by certain US govt agencies?

    The ones that really interests me are the "Security Recommendation Guides" supposedly by that "Three Letter Agency" [nsa.gov]

Slashdot Top Deals

Neutrinos have bad breadth.

Close