Stuff
NoVA Forensics Meetup Reminder
Don't forget about the meetup tonight...and thanks to David for pointing out my typo on the Meetup Page.
I haven't received any responses regarding a pre-meetup warm-up at a local pub, so I'll look forward to seeing everyone who's attending tonight at 7pm at our location.
I posted the slides for tonight's presentation to the NoVA Forensics Meetup Yahoo group.
SSDs
I was recently asked to write an article for an online forum regarding SSDs. Up until now, I haven't had any experience with these, but I thought I'd start looking around and see what's already out there so I can begin learning about solid state drives, as they're likely to replace more traditional hard drives in the near future.
In Windows 7, if the drive is an SSD, ReadyBoot and SuperFetch are disabled.
Resources
SSDTrim.com
Andre Ross' post on on the DigFor blog.
OpenIOC
With this M-unition blog post, Mandiant announced the OpenIOC framework web site. I strongly suggest that before going to the OpenIOC.org site that you read through the blog post thoroughly, so that you understand what's being presented and offered up, and to set your expectations when you go to the site.
What I mean by this is that the framework itself has been around and discussed for some time, particularly through the Mandiant site. Here is a presentation from some Mandiant folks that includes some discussion/slides regarding the OpenIOC. There's also been an IOC editor available, which allows you to create IOCs, and now, with the OpenIOC.org site being released, the command line IOC finder tool has been released. This tool (per the description in the blog post) allows a responder to check one host at a time for the established IOCs.
Fortunately, several example IOCs are also provided, such as this shelldc.dll example. I tend to believe that this is where the real power of this (or any other) framework will come from; regardless of the type of framework or schema (or standard) used to describe indicators of compromise, the real power is going to come from the ability of #DFIR folks to understand and share these IoCs. Having a standard for this sort of thing raises the bar for DFIR...not for admission, but it tells everyone where they have to be with respect to their understanding of DFIR activities, because not only will they have to understand what's out there, but they'll have to really understand it in order to be part of the community and share their own findings.
So, in a lot of ways, this is a step in the right direction. I hope it takes off...as has been seen with GSI's EnScripting and the production of RegRipper plugins, sometimes no matter how useful something is to a small subset of analysts, it's not really picked up by the larger community.
Breach Reporting
There's been some interesting discussion in various forums (G+, Twitter, etc.) lately regarding breach reporting. Okay, not so much discussion as folks posting links...I do think that there needs to be more discussion of this topic.
For example, much of the breach reporting is centered around actually reporting that a breach occurred. Now, if you read any of the published annual reports (Verizon, TrustWave, Mandiant), you'll see historically that a large percentage of breach victims are notified by external third parties. These numbers appear to be across the board, as each of the organizations publishing these reports target slightly different customer bases and respond predominantly to different types of breaches (PCI/PII, APT, etc.).
Maybe a legislative requirement for reporting a breach, regardless of how it was discovered, is just the first step. I mean, I've seen during PCI breaches where a non-attorney executive has stated emphatically that their company would not report a breach, but I tend to think that was done out of panic and a lack of understanding/information regarding the breach itself. However, if breaches start getting reported, there will be greater visibility into the overall issue, and from there, intelligent metrics can be developed, followed by better detection mechanisms and processes.
With respect to PII, it appears that there are 46 states with some sort of breach notification requirements, and there's even a bill put forth by Sen. Leahy (D-VT) and others regarding a national standard requiring reporting of discovered breaches.
Resources
Leahy Personal Data Privacy and Security Act
Don't forget about the meetup tonight...and thanks to David for pointing out my typo on the Meetup Page.
I haven't received any responses regarding a pre-meetup warm-up at a local pub, so I'll look forward to seeing everyone who's attending tonight at 7pm at our location.
I posted the slides for tonight's presentation to the NoVA Forensics Meetup Yahoo group.
SSDs
I was recently asked to write an article for an online forum regarding SSDs. Up until now, I haven't had any experience with these, but I thought I'd start looking around and see what's already out there so I can begin learning about solid state drives, as they're likely to replace more traditional hard drives in the near future.
In Windows 7, if the drive is an SSD, ReadyBoot and SuperFetch are disabled.
Resources
SSDTrim.com
Andre Ross' post on on the DigFor blog.
OpenIOC
With this M-unition blog post, Mandiant announced the OpenIOC framework web site. I strongly suggest that before going to the OpenIOC.org site that you read through the blog post thoroughly, so that you understand what's being presented and offered up, and to set your expectations when you go to the site.
What I mean by this is that the framework itself has been around and discussed for some time, particularly through the Mandiant site. Here is a presentation from some Mandiant folks that includes some discussion/slides regarding the OpenIOC. There's also been an IOC editor available, which allows you to create IOCs, and now, with the OpenIOC.org site being released, the command line IOC finder tool has been released. This tool (per the description in the blog post) allows a responder to check one host at a time for the established IOCs.
Fortunately, several example IOCs are also provided, such as this shelldc.dll example. I tend to believe that this is where the real power of this (or any other) framework will come from; regardless of the type of framework or schema (or standard) used to describe indicators of compromise, the real power is going to come from the ability of #DFIR folks to understand and share these IoCs. Having a standard for this sort of thing raises the bar for DFIR...not for admission, but it tells everyone where they have to be with respect to their understanding of DFIR activities, because not only will they have to understand what's out there, but they'll have to really understand it in order to be part of the community and share their own findings.
So, in a lot of ways, this is a step in the right direction. I hope it takes off...as has been seen with GSI's EnScripting and the production of RegRipper plugins, sometimes no matter how useful something is to a small subset of analysts, it's not really picked up by the larger community.
Breach Reporting
There's been some interesting discussion in various forums (G+, Twitter, etc.) lately regarding breach reporting. Okay, not so much discussion as folks posting links...I do think that there needs to be more discussion of this topic.
For example, much of the breach reporting is centered around actually reporting that a breach occurred. Now, if you read any of the published annual reports (Verizon, TrustWave, Mandiant), you'll see historically that a large percentage of breach victims are notified by external third parties. These numbers appear to be across the board, as each of the organizations publishing these reports target slightly different customer bases and respond predominantly to different types of breaches (PCI/PII, APT, etc.).
Maybe a legislative requirement for reporting a breach, regardless of how it was discovered, is just the first step. I mean, I've seen during PCI breaches where a non-attorney executive has stated emphatically that their company would not report a breach, but I tend to think that was done out of panic and a lack of understanding/information regarding the breach itself. However, if breaches start getting reported, there will be greater visibility into the overall issue, and from there, intelligent metrics can be developed, followed by better detection mechanisms and processes.
With respect to PII, it appears that there are 46 states with some sort of breach notification requirements, and there's even a bill put forth by Sen. Leahy (D-VT) and others regarding a national standard requiring reporting of discovered breaches.
Resources
Leahy Personal Data Privacy and Security Act