e-Evidence
Christina's updated the e-Evidence What's New site...check it out! There's always some good reading here...
Tools
Speaking of tools, Don's been busy...no, Don's not a tool, but he's posted a tool update over on the SecRipcord blog. In addition to the tool update, Don has a little tip he got from some guys from Mandiant on detecting if malware embedded in or infecting CHM (Windows compiled Help) files might have been run on the system.
Don also links over to IronGeek's forensically interesting spots post. It's a very interesting post, and I noticed that a lot of the Registry locations that IronGeek mentions are covered by RegRipper plugins. Also, something else to think about...IronGeek has done a great job of presenting some interesting places to look for forensic data, but I noticed that under both IE and Firefox, there's no mention of Favorites or Bookmarks, respectively.
I digress for a moment, but I really think that examining some of the areas described in my earlier post can add a great deal of context to the information retrieved via more well-known analysis. For example, one of the first items on many checklists with respect to browser analysis is to check the contents of the TypedURLs key. That's fine, but what if the user's default browser isn't IE? That's right...no entries in this key would be explained by that fact. Now, what if there are some entries in the key, and the default browser is IE? Checking the Favorites list would provide some context to what was being seen in the browser history.
Where this can also be helpful is if some sort of anti-forensic tools or techniques have been employed on the system. I actually received a question along these lines just the other day...someone interested in getting into the field asked me how analysts "deal with" anti-forensic tools, and specifically mentioned timestomp. Well, there are a number of locations on a system that contain timestamps that are not affected by timestomp or other anti-forensic tools/techniques.
It seems that I'm not the only one thinking along these lines...Kristinn has updates to log2timeline that include adding this sort of information to a timeline. Thanks to gl33da for sending me the link to Kristinn's page.
Analysis
Speaking of tools, Daniel Wesemann has a SANS ISC post on the static analysis of malicious PDFs, which is pretty easy to follow along with...and starts out using Didier's PDF tools. Very cool!
Circling back around to browser analysis yet again, I picked this one up from the sausage factory...consider the browser's session restore capabilities, something that's been around for a bit. I use Firefox (I've been using Mozilla since 0.9, from as far back as...'94?) and version 3.5 would crash often. When it did, I'd have to decide to restore sessions are just start new ones. Harry Parsonage posted a PDF on the topic...take a look.
Certs
Daniel Castro had a very interesting article in FCW regarding his thoughts on a national certification program. I think that Daniel made some very important points in his article, one being that an increase in certified individuals hasn't resulted in a corresponding decrease in vulnerabilities, incidents/breaches, and losses. I also agree with Daniel in that a national/federal certification program will result in a check-in-the-box mentality...there are plenty of examples out there to illustrate this occurring.
There are a number of excellent certification and training programs out there, and I really don't think that the issue is the programs themselves; no, it's the individual who gets the certification and what they do with it. Let's say you go away to a training program, work hard, and get the certification, and when you return back to your job, you don't use any of the newly-developed skills for 6 or more months...then what? Do you go for a skills review after an incident occurs? If your company is going to send you off to this training, shouldn't there be a purpose for it...like, this person is going to be an integral part of our security plan or CIRT? Wouldn't it then be a good idea to have a plan that starts with getting someone trained, and once they return, get them involved in the program and using those newly-learned skills?
I've seen certified responders walk up to a compromised system, open the Event Viewer, start opening event records, and use Paint to save bitmaps of the entire desktop to the system hard drive as a means of documenting their findings. Seriously. Is that the fault of the certifying organization, or whomever wrote the materials? No, of course not. The material was provided to an individual and they were certified, but what happens after that is in part up to the individual, and in part the responsibility of their management.
Rootkits
Microsoft's Malware Protection Center recently posted some observations on rootkits for 2009...pretty interesting read. However, I think that like a lot of AV service write-ups, something like this falls short of what it could be. Many times, AV service write-ups are geared toward "use our product" type of information, and sometimes not enough to be useful in an environment that may already use that product.
Working as an incident responder over the past several years, a couple of the things I've seen are that (a) a malware infection can devastate an infrastructure, (b) AV products don't protect against everything, and (c) AV services are geared toward using the product.
As an example, just about a year ago, Conficker (and later in the spring, Virut) variants would bring an infrastructure to its knees...literally. Our team would show up, and often find someone from the AV vendor already on-site or engaged. Our observations of the malware characteristics would lead us to a diagnosis, so that we could assist in identifying infected systems, which would be pulled offline and scanned with the updated virus files provided by the vendor. Often things didn't really get rolling until we stepped in because the AV vendor required a sample to analyze, and the customer was drowning.
After the incident settled down, we would have discussions with the customer to help them understand that this was a variant of previously detected malware family, and that the variant itself was sufficiently different enough to escape detection by their current and up-to-date AV product.
Anyway...enough of the soapbox, I guess...it's just too early in 2010 for that!
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Showing posts with label certifications. Show all posts
Showing posts with label certifications. Show all posts
Friday, January 08, 2010
Sunday, January 14, 2007
P0wned by certs
Have we been p0wned by certs?
You're probably asking yourself, "What the...?" right about now. Bear with me on this one. How many of us go away to training, receive a certification, and then never use that training again? Or worse, without an instructor there, we are sloppy about how we use the training, and then it's as if we had never gone in the first place. Come on, raise your hands. Okay, now, think about it...how many of us go away to training, come back, and thankfully never get evaluated on what we learned?
We've all seen it...we meet someone with a certification in, say for example, incident handling. And then we watch how they go about handling an incident, either in a training scenario or during a real incident, and we wonder...why are they doing that, or "what the...?"
I'm sure we could all trade stories on this, but I think that we've already gotten to the point. So the question becomes, what's the purpose of the certification if the person who gets it cannot then perform to the minimum level specified by that certification?
Back in the '90s, I decided that I wanted to learn SCUBA. So I went to the nearby military base, took classes, paid my tuition, took the "final" and then received my certification. From that point on, if I failed to perform at the level specified by my certification, I could have seriously injured (or killed) myself, or worse, others. Had I been unsafe and irresponsible, some one would have likely reported me, or at the very least, refused to dive with me and left me to hurt only myself.
The military itself is very similar. If you get sent off for training, it's very likely that when you return to your unit, you will have to actually use that training for something. During military training, I was taught how to disassemble and reassemble several weapons, to include the M9, M16 (w/ M203 40mm grenade launcher), M249, M60, and M2 .50 calibre machine gun. Not only did I have to pass a practical, but I then had to use that knowledge at my first unit to teach the same things to others.
So someone goes off to learn to be an incident handler and then returns to their organization, and an incident occurs. How is the certified individual evaluated, or are they evaluated at all? What is the outcome of the incident? Does the certified individual declare that the incident was the result of "rootkit" with no data to support that claim?
See, I guess what I'm getting at is...are certifications effective, or have we been p0wned by certs? I guess you really have to look at the purpose of a certification, and what it's intended for. However, I do have some recommendations as to an alternative approach...
Thoughts?
You're probably asking yourself, "What the...?" right about now. Bear with me on this one. How many of us go away to training, receive a certification, and then never use that training again? Or worse, without an instructor there, we are sloppy about how we use the training, and then it's as if we had never gone in the first place. Come on, raise your hands. Okay, now, think about it...how many of us go away to training, come back, and thankfully never get evaluated on what we learned?
We've all seen it...we meet someone with a certification in, say for example, incident handling. And then we watch how they go about handling an incident, either in a training scenario or during a real incident, and we wonder...why are they doing that, or "what the...?"
I'm sure we could all trade stories on this, but I think that we've already gotten to the point. So the question becomes, what's the purpose of the certification if the person who gets it cannot then perform to the minimum level specified by that certification?
Back in the '90s, I decided that I wanted to learn SCUBA. So I went to the nearby military base, took classes, paid my tuition, took the "final" and then received my certification. From that point on, if I failed to perform at the level specified by my certification, I could have seriously injured (or killed) myself, or worse, others. Had I been unsafe and irresponsible, some one would have likely reported me, or at the very least, refused to dive with me and left me to hurt only myself.
The military itself is very similar. If you get sent off for training, it's very likely that when you return to your unit, you will have to actually use that training for something. During military training, I was taught how to disassemble and reassemble several weapons, to include the M9, M16 (w/ M203 40mm grenade launcher), M249, M60, and M2 .50 calibre machine gun. Not only did I have to pass a practical, but I then had to use that knowledge at my first unit to teach the same things to others.
So someone goes off to learn to be an incident handler and then returns to their organization, and an incident occurs. How is the certified individual evaluated, or are they evaluated at all? What is the outcome of the incident? Does the certified individual declare that the incident was the result of "rootkit" with no data to support that claim?
See, I guess what I'm getting at is...are certifications effective, or have we been p0wned by certs? I guess you really have to look at the purpose of a certification, and what it's intended for. However, I do have some recommendations as to an alternative approach...
- Rather than sending someone off to take generic training, have functional training within your organization. That way, the training can be specific to your environment, and immediately useful in that environment. Be sure to coordinate with the instructor and provide input on the types of incidents you're seeing.
- This type of training isn't just for the technical folks...managers need it, too. Not to the same technical detail, of course, but managers need to know what skills they are deploying against an incident, so that efforts can be coordinated and properly...uh...managed.
- Managers also need to know how to evaluate the performance of the team, as well as each member. After all, don't we tend to remember things better if we know that we're going to be tested on it, and that something (bonus, promotion, etc.) may be riding on how well we use that knowledge? Also, being able to evaulate the team will allow the manager to identify shortcomings, obtain additional training, etc. One great way to do this is to see who's really strong in one area, and have them work with others to bring them up to speed.
Thoughts?
Subscribe to:
Posts (Atom)