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."
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.
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
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.
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 chance. Of course, if it was just one in a great long series of screw-ups then my opinion would be rather different...
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
"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 made a comment about how this might cause increased security risk because people will know the defenses against any possible attack. This is obviously not true. Any cracker will know anyway what the basic defenses are, and a good system admin will be flexible enough that this will not be a problem.
I have two eyes, I have two feet.
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.
People who know what they're talking about.
Egress filtering. Application-level firewalls. This is EXACTLY what they exist for.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I'm just going to leave it at that. Anything else is just going to be a derogatory rant. IHBT HAND
I don't want knowledge. I want certainty. - Law, David Bowie
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!
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.
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.