Wednesday, September 28, 2016

Answering those needed questions

When I look at incident response I like to see at as a series of questions that typically needs to be answered. Once all of the stones have been turned, analysis performed and questions have been answered we can usually wind down and learn from what has transpired. As I was reading twitter today I saw a link to a vendor blog that made reference to IR questions in an attempt to help sell their product. It wasn’t a very good attempt and really minimized the work needed to effectively perform incident response. I won’t post the link here or mention the company name as I don’t want it to seem like I’m bashing them in any way. What I would rather do is to share my views on some of the questions that should be answered as well as some of the actions needed during response activities.
I think if you break it down into 6 categories you can begin to answer some of the questions. As you begin to answer these questions you should be building detection to help identify additional compromised assets, internal movement or the adversary attempting to regain access.
1. How did they get in?
2. How are they able to persist in your network?
3. How are they getting out?
4. How long were they able to persist in your network?
5. What did they do once they gained access?
6. What needs to be contained, investigated and remediated?
How did they get in?
What in your environment was exploited in order for the adversary to gain access to your network? Was it a vulnerable application on a host machine that was exploited by a phish or watering hole? Was it an external facing system that was exploited or maybe even a weak acl? Whatever the mechanism was it should be identified so that detection can be created as well as remediating the vulnerability.
How are they able to persist in your network?
This can also be stated as how are they maintaining access. Was some type of backdoor placed on compromised asset? Are they able to take advantage of legitimate access (contractor, M&A’s, 3rd party)? Are they able to take advantage of legitimate access via an externally facing asset? Also keep in mind that they may have multiple ways into your environment as well as multiple methods. Once access is identified detection should be immediately created and deployed. This can help identify additional entry points as well as it may alert you when they attempt to get back in.
How are they getting out?
Just because they have a way into your environment does not mean that they will move data out of your environment over the same path. All outbound connections should be analyzed and any suspicious connections should be investigated. When I mention outbound connections I’m speaking outbound from a compromised host to anywhere as you may see hop points within your environment where data is moved through. Create detection where possible and don’t only think about ip’s and domains. Is there a certain protocol or port that is being used? Are there certain credentials being used or maybe even certain file sizes?
How long were they able to persist in your network?
Identifying dwell time is important so that you have a time range to base your investigation on. Management will also want an answer to this question. Remember that this time will likely change as additional hosts are identified.
What did they do once they gained access
This is a big one and can encompass answering many questions. Some of these may be:
*What tools were brought in with them?
*Where were the tools placed?
*How were the tools used?
*How did they move laterally?
*Where did they move laterally from?
*Where did they move laterally to?
*What hosts are compromised?
*How was each host compromised?
*What hosts are suspected of being compromised, but not yet confirmed?
*Were any internal credentials used?
*Were any internal credentials taken?
*Was any data taken?
As with all of the other questions, ensure you create detection where it makes sense. Also ensure that any credentials that have either been used or attempted are contained and remediated.
What needs to be contained, investigated and remediated?
If there are any indications that a host, credential, data has been compromised it needs to, at a minimum, be investigated. The outcome of the analysis or response policy will usually drive the containment and remediation. As containment is often driven internally and every company has differing philosophies I won’t go into containment here. What I will say about it though is, ensure that you know what your options are and that you know what affect it will have on the data that needs to be collected.
Every intrusion is different, but knowing what questions typically need to be answered beforehand will usually help with response and ensuring you are covering the items that need to be covered. When documenting your analysis you may even want to have specific fields for your questions as it can help focus the work to what’s most important.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.