Stuff
IR
Here's a really good...no, I take that back...a great blog post by Sean Mason on "IR muscle memory". Take the time to give it a read, it'll be worth it, for no other reason than because it's valuable advice. Incident response cannot be something that you talk about once and never actually do; it needs to be part of muscle memory. Can you detect an incident, and if so, how does your organization react? Or, if you receive an external notification of a security incident, how does your organization respond?
A couple of quotes from the blog post that I found interesting were:
...say, “Containment” without having any understanding of what is involved...
Yes, sometimes a consultant (or CISSP) will say this, and sometimes, there is that lack of understanding of how this will affect the business. This is why having IR built into the DNA of an organization is so important...understanding how the business will be affected by some response or containment procedure is critical.
There is also a modicum of patience and discipline required when it comes to containment, particularly when it comes to targeted threats. If the necessary instrumentation is not in place to monitor the environment, then prematurely pulling the trigger on some containment procedures rather than taking the time to prepare and conduct the containment procedures in a near-simultaneous manner will likely cause the threat actors to react, changing what they do. When dealing with these incidents, if someone on the response team decides, "...hey, I can make that change now, so I'll go ahead and take care of it..." can lead to a lot more work.
Another comment from the blog post:
...as a leader and a technologist, you always want everyone to know everything wing-to-wing, and while this can work great in a small organization the reality is that it doesn’t scale for a number of reasons in larger orgs.
I agree wholeheartedly with this. For larger teams in particular, it doesn't scale well for everyone to be an expert in everything, but it does work well to have designated pockets of deep expertise.
I know that I'll never be as good a malware reverse engineer as some of the folks I've had the honor of working with. I can put a great deal of effort into becoming good at it, but that effort would be effort that I wouldn't be spending become better at DFIR analysis. Also, I've found that an effective approach is to gather as much as I can about the malware...OS and version it's installed on, where it was found in the file system, persistence mechanism, any artifacts or indicators associated with the malware, etc. I provide these to the RE analyst, and continue my analysis while they dig deep into the malware itself. When the RE analyst finds something, they provide it back to me and I continue with my analysis.
A great example of this occurred a number of years ago. I have found some malware that was used to steal banking credentials (NOT Zeus) and shared it with the RE analyst, providing a second file and the information/intel needed to run the malware. The malware itself was obfuscated, and in return I got a mutex (I didn't have a memory dump, but I did have a hibernation file and the pagefile), the API used for off-system communications, and other valuable information. With that, I was able to nail down the specific user affected, the initial infection vector, when the infection occurred, etc.
On smaller teams, you won't be able to have those silos, but on larger teams, in larger organizations, it helps to pockets of deep expertise, and someone you can reach to for further assistance. This is particularly valuable in incidents, due to the ability to perform parallel analysis; rather than having one analyst who many not, say, analyze disk images on a regular basis try to wring as much information and intel out of an acquired image as they can while working an IR engagement, have that task run in parallel by someone with a deeper expertise. You're likely to get the info you need (and more) in a much more timely manner, while not loosing any time or focus on the engagement itself. On smaller teams, you're likely going to have a broader base of skill sets that aren't as deep as what you will find with individuals on larger teams. Larger teams can take advantage of pockets of skill sets, and even geographic dispersion, to keep the flow of the incident response going.
The rest of Sean's blog post is equally interesting. Sean goes on to provide his thoughts on people, process, and metrics, all with great insight.
To further Sean's thoughts, a great follow-on to his post is this article from WSJ; in particular, the following quote from that article:
“You are going to get hacked. The bad guy will get you. Whether you are viewed as a success by your board of directors is going to depend on your response.”
IR Fail?
Here's an interesting article from Kelly Jackson Higgins (DarkReading) that talks about Fortune 500 companies having IR teams, but many being pessimistic about their team's ability to handle a data breach. From my perspective, it's good to see that more firms are moving to having a computer security incident response plan, or CSIRP, and that these companies are actually thinking about things like, "...we need a plan...", and "...how good is our IR team?" Even if there is pessimism about the current team's effectiveness, at least there's thought going in that direction, and a realization and admission of the team's current state. From my perspective, this isn't really so much of a failure as it is a success that we've come this far.
From the article:
So why are aren't Target, TJ Maxx, and others sharing their war stories to help the next potential victim?
Yeah, you're not going to. Sharing is not a natural reaction within the DFIR community. This doesn't mean that it doesn't happen...years ago, while working an IR with a client, I heard that there was a forum in the local area where IT folks from different organizations in the same vertical came together and discussed issues and solutions. In fact, the DLP solution that my client had in place, which proved to be extremely valuable during the IR engagement, had been purchased as a result of engaging with others in their community. My point is, sharing can be powerful, and sharing information or intel that helps the next guy when they're attacked doesn't necessarily give away 'secret sauce' or competitive advantage.
Having an IR plan in place isn't enough, either.
No, it's not. You can't have a plan written by consultants sitting on a shelf...that's worse than not having a plan at all, because the organization will see that binder sitting on the shelf (literally or figuratively) and think that they've checked a box and have achieved some modicum of success. A CSIRP needs to be organic to an organization (remember Sean's blog post?); it needs to be owned and practiced by the organization. You can get assistance in writing it, reviewing it, and practicing the processes laid out in the CSIRP. Having an outside consulting firm come in and run an IR exercise...anything from a table top (in the military, we called this a "tactical exercise without troops", or TEWT) exercise to a full-on IR engagement...is a fantastic idea.
Over the years, I've seen a wide variety of organizations as a consultant. I've seen those that have been caught completely by surprise by a data breach, those that have IR plans but do not employ them, and I've seen those that have a practiced plan and want someone there to help guide them. Invariably, those organizations that have been thinking seriously about the need for incident detection and response end up faring much better than others, in a variety of metrics, including the overall cost of the incident.
RegRipper
In a few short weeks, I will be presenting at OSDFCon, talking about some changes to RegRipper that I've had in the works. I'll say right now that the changes I've been thinking about and working on are not ones that will significantly impact the use of the tool...so come on by and give it a listen.
OSDFCon and OMFW
I've attended and presented at OSDFCon before, and this is has always been a really great conference to attend.
Whether you're going to be at OSDFCon or not, I highly recommend that you consider attending the Open Memory Forensics Workshop, or OMFW 2014. This is the premier conference on memory analysis, put on by the top minds in memory analysis, from the Volatility Foundation.
If you're attending OSDFCon, be sure to come see Mari DeGrazia's presentation!
RegRipper Tutorial
Speaking of RegRipper, this tutorial was posted recently regarding how to set up and use RegRipper...I have say, I have somewhat mixed feelings about it. Part of me appreciates the interest in the tool, but
In the name of full disclosure, the author did contact me and ask me to review the article after it was complete. I responded, but to be honest, at the time that the request came in, I didn't have the cycles to focus on reviewing the article, and I definitely didn't have the cycles to address everything that I read in the article. So what you're seeing now is what I've worked on a few minutes at a time, here and there, since the article was published. I'm not going to address everything in the article, because I simply don't have the time to do so, so what I opted to do was pull out just a couple of comments and address them here.
For example...
I have often heard RegRipper mentioned on forums and websites and how it was supposed to make examining event logs, registry files and other similar files a breeze.
I'm not sure which forums or websites state this, but this is not the case at all. RegRipper is named as it is because it's intended for use against the Windows Registry...and only the Registry. It's not intended for use against any other files, in particular the Windows Event Logs. Right after I first released RegRipper, I did receive a request to have it parse PST files, but that simply wasn't/isn't practical.
As I wrote earlier there is a huge community out there writing plugins for RegRipper.
First off, there is no mention of "a huge community" in the tutorial, up to that point. Second, there is not a "huge community out there writing plugins". Yes, some plugins have been submitted over time, and some folks have suggested modifications to plugins...but there is not a "huge community" by any means. In fact, my understanding is that the vast majority of users simply download the tool and run the GUI...and that's it. Asking users specifically, via email or in person, what they'd like to see done to make the tool more useful does not often lead to responses such as requests for new plugins.
I could continue with a lot of the different things I found to be amiss (such as in the Downloads section), but it is not my intent to deride this effort. Again, I greatly appreciate the interest in the tool, and I wanted to address a couple of the comments because I felt that they were wide-spread misconceptions that should be addressed. I'm not going to do a walk-through and correct everything I find...instead, I'll refer folks to the various blog posts I've written, as well as to Windows Registry Forensics.
Here's a really good...no, I take that back...a great blog post by Sean Mason on "IR muscle memory". Take the time to give it a read, it'll be worth it, for no other reason than because it's valuable advice. Incident response cannot be something that you talk about once and never actually do; it needs to be part of muscle memory. Can you detect an incident, and if so, how does your organization react? Or, if you receive an external notification of a security incident, how does your organization respond?
A couple of quotes from the blog post that I found interesting were:
...say, “Containment” without having any understanding of what is involved...
Yes, sometimes a consultant (or CISSP) will say this, and sometimes, there is that lack of understanding of how this will affect the business. This is why having IR built into the DNA of an organization is so important...understanding how the business will be affected by some response or containment procedure is critical.
There is also a modicum of patience and discipline required when it comes to containment, particularly when it comes to targeted threats. If the necessary instrumentation is not in place to monitor the environment, then prematurely pulling the trigger on some containment procedures rather than taking the time to prepare and conduct the containment procedures in a near-simultaneous manner will likely cause the threat actors to react, changing what they do. When dealing with these incidents, if someone on the response team decides, "...hey, I can make that change now, so I'll go ahead and take care of it..." can lead to a lot more work.
Another comment from the blog post:
...as a leader and a technologist, you always want everyone to know everything wing-to-wing, and while this can work great in a small organization the reality is that it doesn’t scale for a number of reasons in larger orgs.
I agree wholeheartedly with this. For larger teams in particular, it doesn't scale well for everyone to be an expert in everything, but it does work well to have designated pockets of deep expertise.
I know that I'll never be as good a malware reverse engineer as some of the folks I've had the honor of working with. I can put a great deal of effort into becoming good at it, but that effort would be effort that I wouldn't be spending become better at DFIR analysis. Also, I've found that an effective approach is to gather as much as I can about the malware...OS and version it's installed on, where it was found in the file system, persistence mechanism, any artifacts or indicators associated with the malware, etc. I provide these to the RE analyst, and continue my analysis while they dig deep into the malware itself. When the RE analyst finds something, they provide it back to me and I continue with my analysis.
A great example of this occurred a number of years ago. I have found some malware that was used to steal banking credentials (NOT Zeus) and shared it with the RE analyst, providing a second file and the information/intel needed to run the malware. The malware itself was obfuscated, and in return I got a mutex (I didn't have a memory dump, but I did have a hibernation file and the pagefile), the API used for off-system communications, and other valuable information. With that, I was able to nail down the specific user affected, the initial infection vector, when the infection occurred, etc.
On smaller teams, you won't be able to have those silos, but on larger teams, in larger organizations, it helps to pockets of deep expertise, and someone you can reach to for further assistance. This is particularly valuable in incidents, due to the ability to perform parallel analysis; rather than having one analyst who many not, say, analyze disk images on a regular basis try to wring as much information and intel out of an acquired image as they can while working an IR engagement, have that task run in parallel by someone with a deeper expertise. You're likely to get the info you need (and more) in a much more timely manner, while not loosing any time or focus on the engagement itself. On smaller teams, you're likely going to have a broader base of skill sets that aren't as deep as what you will find with individuals on larger teams. Larger teams can take advantage of pockets of skill sets, and even geographic dispersion, to keep the flow of the incident response going.
The rest of Sean's blog post is equally interesting. Sean goes on to provide his thoughts on people, process, and metrics, all with great insight.
To further Sean's thoughts, a great follow-on to his post is this article from WSJ; in particular, the following quote from that article:
“You are going to get hacked. The bad guy will get you. Whether you are viewed as a success by your board of directors is going to depend on your response.”
IR Fail?
Here's an interesting article from Kelly Jackson Higgins (DarkReading) that talks about Fortune 500 companies having IR teams, but many being pessimistic about their team's ability to handle a data breach. From my perspective, it's good to see that more firms are moving to having a computer security incident response plan, or CSIRP, and that these companies are actually thinking about things like, "...we need a plan...", and "...how good is our IR team?" Even if there is pessimism about the current team's effectiveness, at least there's thought going in that direction, and a realization and admission of the team's current state. From my perspective, this isn't really so much of a failure as it is a success that we've come this far.
From the article:
So why are aren't Target, TJ Maxx, and others sharing their war stories to help the next potential victim?
Yeah, you're not going to. Sharing is not a natural reaction within the DFIR community. This doesn't mean that it doesn't happen...years ago, while working an IR with a client, I heard that there was a forum in the local area where IT folks from different organizations in the same vertical came together and discussed issues and solutions. In fact, the DLP solution that my client had in place, which proved to be extremely valuable during the IR engagement, had been purchased as a result of engaging with others in their community. My point is, sharing can be powerful, and sharing information or intel that helps the next guy when they're attacked doesn't necessarily give away 'secret sauce' or competitive advantage.
Having an IR plan in place isn't enough, either.
No, it's not. You can't have a plan written by consultants sitting on a shelf...that's worse than not having a plan at all, because the organization will see that binder sitting on the shelf (literally or figuratively) and think that they've checked a box and have achieved some modicum of success. A CSIRP needs to be organic to an organization (remember Sean's blog post?); it needs to be owned and practiced by the organization. You can get assistance in writing it, reviewing it, and practicing the processes laid out in the CSIRP. Having an outside consulting firm come in and run an IR exercise...anything from a table top (in the military, we called this a "tactical exercise without troops", or TEWT) exercise to a full-on IR engagement...is a fantastic idea.
Over the years, I've seen a wide variety of organizations as a consultant. I've seen those that have been caught completely by surprise by a data breach, those that have IR plans but do not employ them, and I've seen those that have a practiced plan and want someone there to help guide them. Invariably, those organizations that have been thinking seriously about the need for incident detection and response end up faring much better than others, in a variety of metrics, including the overall cost of the incident.
RegRipper
In a few short weeks, I will be presenting at OSDFCon, talking about some changes to RegRipper that I've had in the works. I'll say right now that the changes I've been thinking about and working on are not ones that will significantly impact the use of the tool...so come on by and give it a listen.
OSDFCon and OMFW
I've attended and presented at OSDFCon before, and this is has always been a really great conference to attend.
Whether you're going to be at OSDFCon or not, I highly recommend that you consider attending the Open Memory Forensics Workshop, or OMFW 2014. This is the premier conference on memory analysis, put on by the top minds in memory analysis, from the Volatility Foundation.
If you're attending OSDFCon, be sure to come see Mari DeGrazia's presentation!
RegRipper Tutorial
Speaking of RegRipper, this tutorial was posted recently regarding how to set up and use RegRipper...I have say, I have somewhat mixed feelings about it. Part of me appreciates the interest in the tool, but
In the name of full disclosure, the author did contact me and ask me to review the article after it was complete. I responded, but to be honest, at the time that the request came in, I didn't have the cycles to focus on reviewing the article, and I definitely didn't have the cycles to address everything that I read in the article. So what you're seeing now is what I've worked on a few minutes at a time, here and there, since the article was published. I'm not going to address everything in the article, because I simply don't have the time to do so, so what I opted to do was pull out just a couple of comments and address them here.
For example...
I have often heard RegRipper mentioned on forums and websites and how it was supposed to make examining event logs, registry files and other similar files a breeze.
I'm not sure which forums or websites state this, but this is not the case at all. RegRipper is named as it is because it's intended for use against the Windows Registry...and only the Registry. It's not intended for use against any other files, in particular the Windows Event Logs. Right after I first released RegRipper, I did receive a request to have it parse PST files, but that simply wasn't/isn't practical.
As I wrote earlier there is a huge community out there writing plugins for RegRipper.
First off, there is no mention of "a huge community" in the tutorial, up to that point. Second, there is not a "huge community out there writing plugins". Yes, some plugins have been submitted over time, and some folks have suggested modifications to plugins...but there is not a "huge community" by any means. In fact, my understanding is that the vast majority of users simply download the tool and run the GUI...and that's it. Asking users specifically, via email or in person, what they'd like to see done to make the tool more useful does not often lead to responses such as requests for new plugins.
I could continue with a lot of the different things I found to be amiss (such as in the Downloads section), but it is not my intent to deride this effort. Again, I greatly appreciate the interest in the tool, and I wanted to address a couple of the comments because I felt that they were wide-spread misconceptions that should be addressed. I'm not going to do a walk-through and correct everything I find...instead, I'll refer folks to the various blog posts I've written, as well as to Windows Registry Forensics.