Last updated at Mon, 04 Dec 2017 19:19:53 GMT

We recently interviewed Rebekah Brown for our Defender Spotlight series on the topic of her life as a cybersecurity defender. When we spoke with her, she also talked in-depth about how threat intelligence can inform and improve the incident response lifecycle.

Rebekah practices these concepts in her day-to-day life as a defender, and she’s even co-authored a book on this very topic called Intelligence-Driven Incident Response, which officially launched in early September.

Rebekah shared her wisdom with us on how she came to intelligence-driven incident response through her years of experience in the intelligence community, and as a defender.

—

What is intelligence-driven incident response?

Intelligence-driven incident response focuses on how to approach and respond to incidents based on the information available to you, then analyzing it in a way that’s very relevant to your organization.

So this means that you don’t just approach everything as stand alone, brand new information. You don’t approach events as a new threat. Instead, you ask, “What else do I know?” And you continue from there and ask, what else do I know about:

  • Things I’ve seen in my organization before?
  • Things I’ve seen in the world before?
  • Threat actors, how they operate, and what are their motivations?

From there, you’ll figure out how you can use all of their information and understanding to dictate your incident response approach. And of course, you’ll think about how to use that information to protect yourself from future attacks.

It sounds like this is about gaining context from past and present information about incidents?

Absolutely. We just chatted through the process on how to choose the tools and data you need to do threat intelligence. But people forget their own incidents are actually the best place to start. You look at the past, then ask things like:

  • What data were they after?
  • How are they able to get into our networks?
  • What did they do once they were in our networks?
  • What weaknesses did we have in our security that allowed the attacker in?

You use this information to build a better understanding of your own vulnerabilities, but also the attackers you can expect to see.

When we talk about threat intelligence, we’re also looking at the opportunity, capability, and intent of these malicious actors. So building a better picture of all these separate areas helps you understand how to best protect yourself and respond. Because much of the time, attackers are successful, but that doesn’t mean you need to give up and go home. You can learn from this experience, and continue to learn.

Intelligence-driven incident response is all about developing a process where you’re constantly building that context and threat picture. That way next time something happens, you have that body of knowledge behind you to dictate what to do.

What is Intelligence-driven Incident response

Intelligence-driven incident response is all about developing a process where you’re constantly building that context and threat picture.

So you mentioned tools in this process. What are good tools to help you manage intelligence-driven incident response?

The first things you need in place are actual security tools so you can get the data from your own networks. If you’re only pulling from the outside, you’ll have an understanding of the threat landscape, but you won’t have an understanding of how that applies to you.

You need to have the ability to get the data from your network and extract what’s important, whether it’s with logs or a SIEM. When you find something that is important you’ll also need to store it separately.

I’ve seen people try to query their SIEM with the thought of, “It has all the data!”, but when they go back and find information from a prior incident it is hard to find what they need. So, I like the concept of a separate place where you store the analyzed incident data.

There are a couple different platforms to do this: open source platforms like MISP or CRITS are good choices. A new one recently came out, and I haven’t played around with it too much, but it’s called Yeti — “Your Everyday Threat Intelligence” Platform (There’s no P at the end).

I also like using tools like Maltego to do the data and link analysis. It’s AWESOME. With Maltego, you can look for connections within a dataset. You can even perform custom transforms, or use pre-built ones that you can run against your own data sources, as well. That’s really valuable because you can start looking for patterns and analyzing what those patterns mean. That’s when you start turning threat data into actual analyzed intelligence.

There are other processes and models that we talk about in the IDIR book that don’t, to this date, have good tools around it, though good people are working on this. So doing things like doing an analysis of competing hypothesis, which is a process where you look at different potential hypotheses and determine the most likely outcome based on the evidence - this is a manual process. So you write it out, or Excel spreadsheet it (P.S. our favorite threat intelligence tool is Excel, you will almost always have that one available to you).

At the end of the day, intelligence is about, “What does this mean to me?” It’s not just a pile of data; it has to be analyzed. I do think we need more functional analytic tools to help with this process.

Threat intelligence
At the end of the day, intelligence is about, “What does this mean to me?” It’s not just a pile of data; it has to be analyzed.

Do you imagine there will be better tools for this in the future?

I hope so. We need better tools to help extract data, process it, and spot patterns. But I don’t want us to rely solely on tools. A person still needs to be involved. That’s what analysis is about; humans need to find the meaning behind the data. That meaning can change based on the scenario, and there are so many different variables involved. So tools to help enhance our work? Absolutely. Tools to do all of it for us? I hope not. You can’t replace a human.

Tools vs. People Analyzing intelligence

A person still needs to be involved. That’s what analysis is about; humans need to find the meaning behind the data.

What does intelligence-driven incident response look like in a real-world setting? Can you walk me through what this looks like in action?

It is never as smooth as it should be. In an ideal world, you notice something is going on, you look at what you have and take in basic information like indicators, and the data targeted. Then you work to build the initial threat picture.

You look at things like:

  • The organization
  • The industry
  • Past incidents
  • IoCs
  • Type of attacker activity and behavior
  • Data they stole; ie. credit card, access data

With that information, you summarize what may be going on. You look at attacks similar to this, or attacks that this particular organization has seen. You compare how things are similar or different. From there, you work in tandem as you discover new data. You do detection to determine if the attacker is still in the environment, and if so, you try to figure out what they’re going to do.

You may want to try to isolate the attacker’s activity, or block and stop it, depending on how you think this attacker will operate. This approach goes back to my intelligence background. You dig into the data while something important is going on to try to figure out how to respond and remediate. But once you’ve figure out what to do, you’re not done.

After the incident, you want to capture all the information. We talk about CRITs and other ways to store the incident data for analysis — it doesn’t always happen in a timely fashion. It becomes more challenging when more than one attacker is in the environment at a time, because then you have to sort out the individual activity. They are different actors, and their data needs to be separate.

You then build detections for the future now that you know the types of attackers targeting your environment, and how they got in. You also look at your own weaknesses or vulnerabilities they were able to exploit. You’ll want to patch those. Then you’ll also update your understanding of the threat: how do the attackers operate? How is this different from when we saw them last month?

Using Intelligence to Improve Your Security Program

You then build detections for the future now that you know the types of attackers targeting your environment, and how they got in.

Do you ever wait to take action so you can watch the attacker?

Sometimes, yes. It’s difficult to make that call unless you really do understand the threat. Of course, we always want to observe and learn more — it’s the analyst at heart. We want more data on attackers and how they actually operate. However, waiting and observing can be a risky move.

If you choose to observe more, you need to have a handle on how the attacker is likely to respond; especially when we look at things like destructive malware and ransomware. In those cases, waiting and watching is a really bad decision.

Internal honeynets are becoming more popular and important for this reason. You can allow attackers to move around, and hopefully you can learn what they’re after. You may also learn things about their level of sophistication and stealth.

Of course, it’s in a quarantined environment, so if they decide to brick all the hard drives, it won’t be that serious. But you won’t want to observe on a production or mission critical network. The business ramifications to that could be really bad.

Incident response is a very reactive process. Do you think IDIR will make the process more proactive?

Yes, ideally. We’ve talked the importance of learning from an incident after the investigation is over. The application of this can mean investing in a new security appliance, updating your patching process, or even building new detections. The “learning” phase helps you understand what you’re missing, and the things you can put in place to prevent or mitigate future threats.

Applying Threat Intelligence to Incident Response

The “learning” phase helps you understand what you’re missing, and the things you can put in place to prevent or mitigate future threats.

You can also continue to build your threat profile with the information you have, which can help if you do see specific behavior or threat actors again. This applies to lucrative industries that I see targeted a lot. The “P” in APT is persistent for a reason. They’re not going to say, “Shucks! You caught us” and then go away. They’re going to come back, and they’re going to change.

This means you’re not just learning from your own information, but you’re also watching how these same attackers successfully target other companies. Doing this can help you keep up with the changing threat landscape rather than if you were to just treat all things as equal, and not prepare for particular types of attacks.

We’ll never be 100% proactive; we can’t perfectly anticipate what the attackers will do at all times. People are unpredictable, and attackers are people.

As a defender, we have crazy 2am ideas — “Oh my god, if I put this ruleset in, I’ll stop this type of attack!” But attackers also have crazy 2am ideas. That’s why it’s so important to learn from the attacker, because this can dictate how quick we can respond and ideally block their actions.

We’ll still be reactive, but hopefully less so.

Incident response as a proactive process

We’ll never be 100% proactive; we can’t perfectly anticipate what the attackers will do at all times. People are unpredictable, and attackers are people.

You and Scott Roberts wrote a book about this. Can you talk a little bit about what inspired you folks to write this?

It originally started off as Kyle Maxwell and Scott’s baby. Kyle and Scott are both very strong incident responders who found themselves in the intelligence world. I was the opposite; I was in the intelligence world, then found myself in the incident response world.

So we partnered up to articulate these two worlds to people. We wanted to be successful and take incident response to its next natural evolution where it’s not so reactive.

Many incident responders have the same experiences. It goes something like this: you’re jumping from one incident to the next, and you start to realize you’re responding to the exact same incidents over and over again. You begin to wonder why it hasn’t been fixed, why measures haven’t been put in place to detect or mitigate these kind of attackers.

You ask yourself, “why do we have to go through the exact same steps to respond to the same incident?” instead of evaluating what was done previously to respond. So you want take that knowledge and learn from it. You want to capture the data and understand the best practices instead of having a knee-jerk reaction to an incident.

Getting that data in a place where you can actually analyze it is hard. So when we started talking about the book, we thought about how to articulate to people how to achieve this. We thought about the next generation of incident responders that are getting to that burn out point, and saying in frustration, “Why doesn’t anything get any better?!”

We wanted to give practical tips and advice on how to start taking this approach, whether you’re a one person team or a robust incident response practice already.

How long did it take to complete the book?

It’s been a work in progress for about 3 years. I came on board a little over a year ago to help bring focus to the intelligence and analysis portions.

What has the reception to the book been?

The reception has been great. Much of the feedback we get is from people that have thought about this concept, but haven’t really fleshed it out or documented it fully. At least not in book form. There are some great blog posts around concepts related to the overall IDIR process, but the whole entirety of the concept and the steps involved had not been documented prior to the book.

Overall, people seem really excited about intelligence-driven incident response. They’re excited to have a reference, an a-z approach to tackle and implement this in their organization.

There are also little nuggets in the book in the form of snarky comments I left for Scott that made it past reviews in the early release. People always think it’s fun when you can find them.

Fortunately my editors know my personality well enough to know when I’m being snarky, and when I’ve actually made a typo. So I accidentally left in a remark about “eleventy-billion indicators”, and someone in the comments responded with, “That’s not even a real number!” But it was snark for “ALL the indicators”.

Reception to Intelligence-driven Incident Response

There are also little nuggets in the book in the form of snarky comments I left for Scott that made it past reviews in the early release. People always think it’s fun when you can find them.

What do you think the future of IDIR is?

I’m excited about the future. There’s definitely an evolution to intelligence-driven incident response. Some of the things we talk about are the need for good databases, and ways to store your information.

Remember when I talked about taking a big pile of data, and getting it into a usable format? Hopefully, we’ll start to see good ways to store incident data as you are going through incidents, that also help capture the findings of the analysis process as well as technical details. It’s difficult because there are different types of data, different formats, even analyst notes. But I’m hoping we find a better way to capture and aggregate that data.

This will help expedite the analysis process. And it means I don’t have to sit down and analyze the entirety of a huge, month-long incident anymore. A good system will make it possible for me to quickly make connections to better understand what’s going on throughout the organization. This relies on better tools, and refinement of data structures and data formats, such as building on something like CybOX and STIX, or OpenIOC.

The standards we have now were primarily meant for sharing. They weren’t meant for analysis, even though we’re often trying to use them for for analysis, but it can be difficult because the flow isn’t great. So improvements and evolutions in the database standards will help us with future analysis.

Ideally, when we have a repeatable, predictable, and pragmatic approach, we’ll be able to free ourselves up to do more innovate things. The process will be easier, and we won’t need to worry about managing data while simultaneously trying to understand what’s going on. That’s a good next step and evolution of intelligence-driven incident response.

We’re hoping our book contributes to that natural evolution. We’re hoping people see it, adopt this concept, and then do cools things to make it even better.

Do you think another future of this will revolve around contribution? So people implement this in their organization, and then share what they’ve learned?

That’s what I’m hoping. People are all good at different things, and they have different approaches to problems. I can document what I think an ideal process looks like, but someone else could also have the same problem and solve it differently. I hope people will learn, then take the next step to start sharing what they’ve learned. There are so many people out there willing to help make this entire system better.

The infosec community is a great resource for general security things. But I’m hoping we can start building a deeper community around intelligence-driven incident response. I like the whole concept of “it takes a village” in our community.

—

If you enjoyed learning about Rebekah and the work she does, you can follow her on Twitter. If you enjoyed the topic and want to learn more, the Intelligence-Driven Incident Response book is now available for purchase

We recently interviewed Rebekah Brown for our Defender Spotlight series on the topic of her life as a cybersecurity defender. When we spoke with her, she also talked in-depth about how threat intelligence can inform and improve the incident response lifecycle.

Rebekah practices these concepts in her day-to-day life as a defender, and she’s even co-authored a book on this very topic called Intelligence-Driven Incident Response, which officially launched in early September.  

Rebekah shared her wisdom with us on how she came to intelligence-driven incident response through her years of experience in the intelligence community, and as a defender. 

—

What is intelligence-driven incident response?

Intelligence-driven incident response focuses on how to approach and respond to incidents based on the information available to you, then analyzing it in a way that’s very relevant to your organization.

So this means that you don’t just approach everything as stand alone, brand new information. You don’t approach events as a new threat. Instead, you ask, “What else do I know?” And you continue from there and ask, what else do I know about:

  • Things I’ve seen in my organization before?
  • Things I’ve seen in the world before?
  • Threat actors, how they operate, and what are their motivations?

 

From there, you’ll figure out how you can use all of their information and understanding to dictate your incident response approach. And of course, you’ll think about how to use that information to protect yourself from future attacks.

It sounds like this is about gaining context from past and present information about incidents?

Absolutely. We just chatted through the process on how to choose the tools and data you need to do threat intelligence. But people forget their own incidents are actually the best place to start. You look at the past, then ask things like:

  • What data were they after?
  • How are they able to get into our networks?
  • What did they do once they were in our networks?
  • What weaknesses did we have in our security that allowed the attacker in?

 

You use this information to build a better understanding of your own vulnerabilities, but also the attackers you can expect to see.

When we talk about threat intelligence, we’re also looking at the opportunity, capability, and intent of these malicious actors. So building a better picture of all these separate areas helps you understand how to best protect yourself and respond. Because much of the time, attackers are successful, but that doesn’t mean you need to give up and go home. You can learn from this experience, and continue to learn.

Intelligence-driven incident response is all about developing a process where you’re constantly building that context and threat picture. That way next time something happens, you have that body of knowledge behind you to dictate what to do.

What is intelligence-driven Incident response

Intelligence-driven incident response is all about developing a process where you’re constantly building that context and threat picture. 


So you mentioned tools in this process. What are good tools to help you manage intelligence-driven incident response?

The first things you need in place are actual security tools so you can get the data from your own networks. If you’re only pulling from the outside, you’ll have an understanding of the threat landscape, but you won’t have an understanding of how that applies to you.

You need to have the ability to get the data from your network and extract what’s important, whether it’s with logs or a SIEM. When you find something that is important you’ll also need to store it separately.

I’ve seen people try to query their SIEM with the thought of, “It has all the data!”, but when they go back and find information from a prior incident it is hard to find what they need. So, I like the concept of a separate place where you store the analyzed incident data.

There are a couple different platforms to do this: open source platforms like MISP or CRITS are good choices. A new one recently came out, and I haven’t played around with it too much, but it’s called Yeti — “Your Everyday Threat Intelligence” Platform (There’s no P at the end).

I also like using tools like Maltego to do the data and link analysis. It’s AWESOME. With Maltego, you can look for connections within a dataset. You can even perform custom transforms, or use pre-built ones that you can run against your own data sources, as well. That’s really valuable because you can start looking for patterns and analyzing what those patterns mean. That’s when you start turning threat data into actual analyzed intelligence.

There are other processes and models that we talk about in the IDIR book that don’t, to this date, have good tools around it, though good people are working on this. So doing things like doing an analysis of competing hypothesis, which is a process where you look at different potential hypotheses and determine the most likely outcome based on the evidence - this is a manual process. So you write it out, or Excel spreadsheet it (P.S. our favorite threat intelligence tool is Excel, you will almost always have that one available to you).

At the end of the day, intelligence is about, “What does this mean to me?” It’s not just a pile of data; it has to be analyzed. I do think we need more functional analytic tools to help with this process.

Threat intelligence
At the end of the day, intelligence is about, “What does this mean to me?” It’s not just a pile of data; it has to be analyzed.


Do you imagine there will be better tools for this in the future?

I hope so. We need better tools to help extract data, process it, and spot patterns. But I don’t want us to rely solely on tools. A person still needs to be involved. That’s what analysis is about; humans need to find the meaning behind the data. That meaning can change based on the scenario, and there are so many different variables involved. So tools to help enhance our work? Absolutely. Tools to do all of it for us? I hope not. You can’t replace a human.

tools vs. people Analyzing intelligence

A person still needs to be involved. That’s what analysis is about; humans need to find the meaning behind the data.


What does intelligence-driven incident response look like in a real-world setting? Can you walk me through what this looks like in action?

It is never as smooth as it should be. In an ideal world, you notice something is going on, you look at what you have and take in basic information like indicators, and the data targeted. Then you work to build the initial threat picture.

You look at things like:

  • The organization
  • The industry
  • Past incidents
  • IoCs
  • Type of attacker activity and behavior
  • Data they stole; ie. credit card, access data
     

With that information, you summarize what may be going on. You look at attacks similar to this, or attacks that this particular organization has seen. You compare how things are similar or different. From there, you work in tandem as you discover new data. You do detection to determine if the attacker is still in the environment, and if so, you try to figure out what they’re going to do.

You may want to try to isolate the attacker’s activity, or block and stop it, depending on how you think this attacker will operate. This approach goes back to my intelligence background. You dig into the data while something important is going on to try to figure out how to respond and remediate. But once you’ve figure out what to do, you’re not done.

After the incident, you want to capture all the information. We talk about CRITs and other ways to store the incident data for analysis — it doesn’t always happen in a timely fashion. It becomes more challenging when more than one attacker is in the environment at a time, because then you have to sort out the individual activity. They are different actors, and their data needs to be separate.

You then build detections for the future now that you know the types of attackers targeting your environment, and how they got in. You also look at your own weaknesses or vulnerabilities they were able to exploit. You’ll want to patch those. Then you’ll also update your understanding of the threat: how do the attackers operate? How is this different from when we saw them last month?

using intelligence to improve your security program

You then build detections for the future now that you know the types of attackers targeting your environment, and how they got in. 


Do you ever wait to take action so you can watch the attacker?

Sometimes, yes. It’s difficult to make that call unless you really do understand the threat. Of course, we always want to observe and learn more — it’s the analyst at heart. We want more data on attackers and how they actually operate. However, waiting and observing can be a risky move.

If you choose to observe more, you need to have a handle on how the attacker is likely to respond; especially when we look at things like destructive malware and ransomware. In those cases, waiting and watching is a really bad decision.

Internal honeynets are becoming more popular and important for this reason. You can allow attackers to move around, and hopefully you can learn what they’re after. You may also learn things about their level of sophistication and stealth.

Of course, it’s in a quarantined environment, so if they decide to brick all the hard drives, it won’t be that serious. But you won’t want to observe on a production or mission critical network. The business ramifications to that could be really bad.

Incident response is a very reactive process. Do you think IDIR will make the process more proactive?

Yes, ideally. We’ve talked the importance of learning from an incident after the investigation is over. The application of this can mean investing in a new security appliance, updating your patching process, or even building new detections. The “learning” phase helps you understand what you’re missing, and the things you can put in place to prevent or mitigate future threats. 

Applying threat intelligence to incident response

The “learning” phase helps you understand what you’re missing, and the things you can put in place to prevent or mitigate future threats.


You can also continue to build your threat profile with the information you have, which can help if you do see specific behavior or threat actors again. This applies to lucrative industries that I see targeted a lot. The “P” in APT is persistent for a reason. They’re not going to say, “Shucks! You caught us” and then go away. They’re going to come back, and they’re going to change. 

This means you’re not just learning from your own information, but you’re also watching how these same attackers successfully target other companies. Doing this can help you keep up with the changing threat landscape rather than if you were to just treat all things as equal, and not prepare for particular types of attacks. 

We’ll never be 100% proactive; we can’t perfectly anticipate what the attackers will do at all times. People are unpredictable, and attackers are people.

As a defender, we have crazy 2am ideas — “Oh my god, if I put this ruleset in, I’ll stop this type of attack!” But attackers also have crazy 2am ideas. That’s why it’s so important to learn from the attacker, because this can dictate how quick we can respond and ideally block their actions. 

We’ll still be reactive, but hopefully less so.

incident response as a proactive process

We’ll never be 100% proactive; we can’t perfectly anticipate what the attackers will do at all times. People are unpredictable, and attackers are people.


You and Scott Roberts wrote a book about this. Can you talk a little bit about what inspired you folks to write this?

It originally started off as Kyle Maxwell and Scott’s baby. Kyle and Scott are both very strong incident responders who found themselves in the intelligence world. I was the opposite; I was in the intelligence world, then found myself in the incident response world.

So we partnered up to articulate these two worlds to people. We wanted to be successful and take incident response to its next natural evolution where it’s not so reactive. 

Many incident responders have the same experiences. It goes something like this: you’re jumping from one incident to the next, and you start to realize you’re responding to the exact same incidents over and over again. You begin to wonder why it hasn’t been fixed, why measures haven’t been put in place to detect or mitigate these kind of attackers.

You ask yourself, “why do we have to go through the exact same steps to respond to the same incident?” instead of evaluating what was done previously to respond. So you want take that knowledge and learn from it. You want to capture the data and understand the best practices instead of having a knee-jerk reaction to an incident. 

Getting that data in a place where you can actually analyze it is hard. So when we started talking about the book, we thought about how to articulate to people how to achieve this. We thought about the next generation of incident responders that are getting to that burn out point, and saying in frustration, “Why doesn’t anything get any better?!”

We wanted to give practical tips and advice on how to start taking this approach, whether you’re a one person team or a robust incident response practice already.

How long did it take to complete the book?

It’s been a work in progress for about 3 years. I came on board a little over a year ago to help bring focus to the intelligence and analysis portions.
 

What has the reception to the book been?

The reception has been great. Much of the feedback we get is from people that have thought about this concept, but haven’t really fleshed it out or documented it fully. At least not in book form. There are some great blog posts around concepts related to the overall IDIR process, but the whole entirety of the concept and the steps involved had not been documented prior to the book.

Overall, people seem really excited about intelligence-driven incident response. They’re excited to have a reference, an a-z approach to tackle and implement this in their organization.

There are also little nuggets in the book in the form of snarky comments I left for Scott that made it past reviews in the early release. People always think it’s fun when you can find them.

Fortunately my editors know my personality well enough to know when I’m being snarky, and when I’ve actually made a typo. So I accidentally left in a remark about “eleventy-billion indicators”, and someone in the comments responded with, “That’s not even a real number!” But it was snark for “ALL the indicators”.  

Reception to intelligence-driven incident response

There are also little nuggets in the book in the form of snarky comments I left for Scott that made it past reviews in the early release. People always think it’s fun when you can find them.


What do you think the future of IDIR is?

I’m excited about the future. There’s definitely an evolution to intelligence-driven incident response. Some of the things we talk about are the need for good databases, and ways to store your information.

Remember when I talked about taking a big pile of data, and getting it into a usable format? Hopefully, we’ll start to see good ways to store incident data as you are going through incidents, that also help capture the findings of the analysis process as well as technical details. It’s difficult because there are different types of data, different formats, even analyst notes. But I’m hoping we find a better way to capture and aggregate that data.

This will help expedite the analysis process. And it means I don’t have to sit down and analyze the entirety of a huge, month-long incident anymore. A good system will make it possible for me to quickly make connections to better understand what’s going on throughout the organization. This relies on better tools, and refinement of data structures and data formats, such as building on something like CybOX and STIX, or OpenIOC.

The standards we have now were primarily meant for sharing. They weren’t meant for analysis, even though we’re often trying to use them for for analysis, but it can be difficult because the flow isn’t great. So improvements and evolutions in the database standards will help us with future analysis.

Ideally, when we have a repeatable, predictable, and pragmatic approach, we’ll be able to free ourselves up to do more innovate things. The process will be easier, and we won’t need to worry about managing data while simultaneously trying to understand what’s going on. That’s a good next step and evolution of intelligence-driven incident response.

We’re hoping our book contributes to that natural evolution. We’re hoping people see it, adopt this concept, and then do cools things to make it even better.

Do you think another future of this will revolve around contribution? So people implement this in their organization, and then share what they’ve learned?

That’s what I’m hoping. People are all good at different things, and they have different approaches to problems. I can document what I think an ideal process looks like, but someone else could also have the same problem and solve it differently. I hope people will learn, then take the next step to start sharing what they’ve learned. There are so many people out there willing to help make this entire system better.

The infosec community is a great resource for general security things. But I’m hoping we can start building a deeper community around intelligence-driven incident response. I like the whole concept of “it takes a village” in our community.

 

— 

If you enjoyed learning about Rebekah and the work she does, you can follow her on Twitter. If you enjoyed the topic and want to learn more, the Intelligence-Driven Incident Response book is now available for purchase.