Slashdot Mirror
NIST Releases Guide to Cyber Attacks
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."
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?
I have been pwned because my
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
The International Journal of Digital Evidence is also worth keeping up with, if this type of stuff interests you.
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
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!
It's all Hood
It seems quite apropos to revisit this thread, considering the article topic.
-JT
When's the last time the Feds did *not* figure out what happened and find the perp? That's what Incident Response is about.
Here's a mirror
Mirror provided by Coded Networks
Sponsored by Dedicated Gamer
The fact that the guvmint machines are the easy targets is apparently the point.
This if for federal agency use, and anyone elses.
This also effectively says "You WILL do it like this" to the federal agencies.
There will be a quiz.
Guide for Sysadmins: Upon learning that your systems have been penetrated, proper incident response is as follows:
Microsoft Windows is, fittingly, the official Desktop OS of Olig
I haven't been able to read the report yet, but the government often employs really smart people to produce some excellent information on information security, which they then ignore.
...what to do in case of a Slashdotting?
Sheesh, evil *and* a jerk. -- Jade
It's good that they did this. It amazes me how many Fortune 500 IT departments still don't know how to buckle down and protect a system.
:D
Like when Microsoft's Brazil site was hacked
Seriously, though, It's really not unlike setting up an office in a really bad part of town. Sure it might be cheaper so company might want to do it -- however many decide it's not worth the risk.
Why don't companies really concerned about security simply disconnect, and pay someone else to host a static page saying "slashBank cares so much about your security we don't let our workers browse pr0n on the computers that run your account, and we don't offer online banking".
Major hack attack on the U.S. Senate
In the free world the media isn't government run; the government is media run.
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) (zipped text file)
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.
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.
How come Homer and Krusty look like clones?
I think Homer and Krusty look a like because originally, the Simpson's premise was about a boy who hated his father but was in awe with a clown who looked exactly like his father. Thus they look a like.
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 average hacker is a stupid high-school student that thinks it is cool, and has found a hacking website that tells him how to do it.
The problem with security is that it makes you think your secure. If people have passwords they can tell someone else their's and all the ssh updates in the world won't help you. How many of you can honestly say they have never given anyone else there password for anything? Simple things like forgetting your work some where and giving someone your password to email it to you is a bigger security risk, than a dozen highschool hackerz.com readers.
"... 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?
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.
Description courtesy of Bruce Schneier's Crypto-gram:
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...
I do not deploy Linux. Ever.
Would you like to play a game?
Run around in circles, screaming and shouting.
Blame Microsoft.
Thank you.
Ummm... They do. If you've ever worked anywhere involving classified information, you'd know that EXTREME measures and controls are normally in place in order to completely eliminate possible bleeding between classified and unclassified networks...
Sig.i>
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
____________________
Save the World! Use a Quote!
Reasonable? Pointless.
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. Primarily because there are, at this time, no proxies capable of blocking them.
And as soon as such proxies appear, the HTTP application layer tunnels will go polymorphic in their protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well-known to the steganography community that any open channel, even email, are insecure. Unless such channels are closely monitored by a professional cryptographer, there is no chance that they can reliably be monitored to prevent unfriendly traffic.
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 (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 blocking them.
As soon as such proxies appear, the HTTP application layer tunnels will implement polymorphic protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well known in the steganography community that any open channel, even email, is transparently insecure. Unless such channels are closely monitored by a professional cryptoanalyst, there is no chance that they can reliably prevented from carrying unwanted traffic.
Just a DOS attack by Democrats on behalf of special interest groups trying to control the Federal courts. It is described here (pdf).
Not to be confused with the planned social engineering of the Senate Intelligence Committee. That was a plan to probe for weaknesses, and announce an investigation whether weaknesses are found or not. There effectively was a DOS when the attack was discovered and the interfaces were turned off to block the attack.
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.
In the land of the blind, the one-eyed man is usually crucified.
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 true. It's not just unplugging the network cables, this can in fact go to the extremes like having no windows in the rooms and having some level of protection against electromagnetic spying, such as entire rooms being faraday cages...
Whats the standard response to republicans peeping at your internal files?
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
I recently did a lot of work with various Booz-Allen contractors in the government, and I noticed that without fail every single team they had included at least one hot 25 year old girl. It was amazing, and when I talked to a guy who used to work there he confirmed that was pretty much the case. I know where I'll be looking when I hit the private sector.
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.
This is not a standard, it is a GUIDE. The purpose of which is to help establish a framework to protect your network. Use it as the basis for your security procedure and extend it as necessary. Nowhere in the document does it say following the recommended procedures will make you network secure. But it damn well will help.
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.
its interesting that microsofts security bug solution of, "Just Don't Write Them", and "Don't Tell Anyone About It" was loudly ignored.
because I see there no added benefit to creating an account and logging on to such.
The added benefit with an account is that you automatially post at 1 while posting as an AC you automatically post at 0. My point is that the vast majority of people will not even see your post if you are posting as an AC.
YARRA
Yet another right-wing Republican apologist
bullshit
debian have a dedicated security team who deal with backporting security fixes
slso the hole used to comprimise the debian main servers was not a remote hole they had managed to log in seing s sniffed password from a normal user
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.
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.
--
make install -not war
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"
--
Time is on my side
Like restrictive nations, one benefit of banning encryted protocols and logging all traffic is that you do not need to know what the user is doing with the connection, just proving that they are using unapproved connectivity is sufficient to fire the offender.
As a related example, I've heard from Saudi visitors that the government run dialup ISPs will drop your session (not sure if they drop carrier, or just shun your IP address) the moment you try to bring up an encrypted session to a foreign destination.
No, this doesn't stop the spies, but it does discourage the average visitor from using encrypted sessions, and the log of attempts gives the defenders an idea of who might deserve closer scrutiny.
True, though latency on email (assuming inbound/outbound email is passed through a chain of SMTP relays, not just "permit TCP 25" packet filters) is high enough that it's not an effective way to tunnel IP traffic.I don't know about others, but I do traffic analysis on the raw volume of sessions and bytes in/out by source (by IP, by subnet, etc), and by the internet source/destination of the traffic. The average porn hound is going to be caught not by the nature of the HTTP sites he visits, but by the sudden spike in bandwidth, and the sudden increase in traffic to and from an internet destination not commonly seen.
There are exceptions, e.g. Google Image Search. OTOH, most of the porn hounds we fire are caught first by their poor job performance, any logs or evidence on their PC are just insurance against the former employee filing a "wrongful dismissal" lawsuit...
I do not deploy Linux. Ever.