Last Updated: 2008-10-08 13:15:19 UTC
by Marcus Sachs (Version: 3)
October is Cyber Security Awareness Month and as we announced earlier we are going to use this month to solicit tips for proper incident handling.
The SANS Institute teaches a six-step process:
6. Lessons Learned
Preparation is the first step, and most of us know that if you are unprepared then it's nearly impossible to handle an incident property. For the rest of this week we will focus on the elements of preparation. To kick off the month, send us your ideas via the contact page on how you develop policies, how you engage management support, and how you raise user awareness. We'll add the best ideas to this diary throughout the day.
Thanks and Happy Cyber Security Awareness Month!!
Craig sent us these thoughts:
I would like to suggest this: Everyone knows an organization needs an Incident Response Plan that has management buy in, but how well written is your plan? Do YOU have to be there for it to work? I (being an engineer by education) do not consider myself a very good writer, so I was pleasantly surprised to hear that while I was on leave this past summer, an incident occurred and the organization was able to use the IRP totally and completely without my help.
I don't say that to brag, but it taught me something: If I'm going to have a good impact and create something that lasts, I have to build it so it operates independently of me. In a small org, that's one person deep at each position, it helps if policies and procedures aren't dependent on one person/position to succeed.
Handler Steve had these ideas:
I've recently had to define and create our incident response team. We took a multitude of source media SANS (of course), NIST, CERT, and molded this into our policies and procedures for the IRT. However, before all of that starts the first step has to be stakeholder management. Without the right names on a piece of paper telling you can do IRT on behalf of your organisation, your as good as sunk on day 1.
1. Define who you are working for, and who you perform Incident response on behalf of, and who you don't!
2. Work your way up the structure to find the best CxO's which cover what you define in 1, who want to sponsor your operation and educate them about incident response.
a) get them all to sign a document - your mission statement - which says you can perform Incident Response
b) check out RFC 2350
c) is important to ensure that these people are responsible for the RUN side of your IT, and not just the Information Security side. if they dont 100% align, either go higher, or get 2 to sign it.
3. Define your policy for IR.
The killers are:
- HR policies in relation to IR
- Incident handling policies
- Information handling, so what needs to be encrypted, hows it sent, who to, and how, how long do you keep it, and how do you dispose of it when your finished
4. Announce yourself to the world.
Marcus H. Sachs
Director, SANS Internet Storm Center
Last Updated: 2008-10-01 21:47:05 UTC
by Rick Wanner (Version: 1)
Just a few items that came in through the Handler's mailbox today:
A few readers sent in some more information on the TCP vulnerabilities that has been the talk around the water cooler for the last week or so. First a webcast of the Dutch researchers is available at http://debeveiligingsupdate.
Secondly, a Search Security article provides some more details here.
I haven't had time to dig into this in detail, but it seems that a relatively few number of packets are capable of DOSing most TCP/IP stacks. Some sources are making this sound like the Internet perfect storm, others are writing it off as FUD. I will leave it up to you to make your own decisions, but I expect it is closer to the latter.
Reader Frank forwarded an article about a hack at the University of Indianapolis that compromised 11,000 Social Security numbers. This in itself is nothing new. Universities by the nature of their culture have had a relatively open network, and it seems the bad guys have been increasingly turning there attentions in that direction. But a quote in the article upset Frank, ..."it was well beyond our control". Now I can't speak about the University of Indianapolis, they may very well have excellent security and this hack may have been carried out by world class hackers. But what this hack hilights for me is that the days when universities could have a wide open network are long gone. Enlightened universities have started realizing that they need to understand which data needs to be protected and separating the important data from the rest of the network with adequate security controls such as network segregation, firewalls, and encryption. If you are interested the article is here.
Christmas in October!
Frequent contributer Roseman pointed out the release of updates to the free SysInternal's tools. For those of you who regularly use the SysInternals tools to debug and understand Windows you understand when I say this is like an early Christmas. For those of you who are not yet enlightened about SysInternals...you should take a look.
The major change is a update to Process Monitor..."adds real-time TCP and UDP monitoring to its existing process, thread, DLL, file system and registry monitoring."
The blog post with some basic release notes is available here.
SysInternals tools can be downloaded from here.
-- Rick Wanner
rwanner at isc dot sans dot org
Last Updated: 2008-10-01 11:52:43 UTC
by Adrien de Beaupre (Version: 1)
The National Do Not Call List for Canada went live yesterday. Well, sort of. It would appear as though they did not adequately plan (prepare) for the volume of requests. Both the web services and phone services did not respond or a busy signal almost all day. Somewhat of an incident, particularly when a new service of any kind simply isn't available. The intention of the DNCL is for consumers to register their phone numbers for certain classes of telemarketers to never dial. Well, to the aproximately 1 Million fellow Canadians who failed to register for the Some-Should-Call-and-Some-Shouldn't list, perhaps tomorrow is another day for their provider to get the service up and running.
Adrien de Beaupré