Hey folks,

So a lot of you have been asking me about incident response(IR). What is it? How does it work? How does it relate to Cyber Security? So I’m making this post to talk about IR in a very rudimentary way without going into a very big technical deep dive.

What is Incident Response? Incident Response is basically an organized approach to addressing and managing the aftermath of a security incident. IR focuses on determining how an attack has occurred, trying to patch security holes so the attack doesn’t happen again, and also building on security principals so when further development occurs security is in mind.

The Incident Response Lifecycle:

(Most of the info in this post will be from NIST)

So NIST (The National Institute of Standards and Technology) has broken up addressing an incident into 4 phases to form the basis of any incident response plan. There’s a lot of variations for the IR lifecycle but for the sake of this post let’s just stick to the NIST variation. In NIST there’s 4 main phases: Preparation, Detection & Analysis, Containment Eradication & Recovery, and Post Incident Activity.

1. Preparation:
   • When it comes to an incident, the first thing we want to do is take an inventory of all the devices. This will allow the incident handler to better asses the environment, understand what assets are on the playing field, and what can/cannot be used as an attack vector. *What the goal during this phase is preparing the organization to be read to respond to incidents, but also preventing incidents by ensuring systems, networks, and apps are secure. It is common for consultants to point out certain flaws they find in their report along with a way for the client to patch them.

• It’s not surprising to see a network diagram, a port list, OSs, Application versions, etc. in a report during this phase.

• Keeping the number of incidents low is obviously very important to protect a business and its credibility.

• During this phase risk assessments are often taking place 1. Risk assessments are exactly what they sound like, they review and assume where an organization’s greatest weaknesses are. 2. You may be thinking what’s the difference between a risk assessment and a pen test. Well pen testing takes things a level up and look into ways of digitally AND physically breaking into networks and organizations while proving that it’s possible.
  1. Detection & Analysis:
  • Incidents occur in an unfathomable amount of ways ranging from social engineering to ransomware. That being said it’s impossible to create a step by step playbook as to handling each and every type of incident to occur (job security am I right 😉 )

• Organizations want to focus on being prepared to handle incidents that use common attack vectors(think OWASP for Web, Phishing, Removable Media, MITM[Man in the Middle] Attacks, etc.)

• Incidents can be detected through various different means. It’ll be easy somedays and it’ll be hard on others. Automation being the future, there’s technology like network-based and host-based Intrusion Detection and Prevention Systems (IDS/IPS/IDPS), antivirus software, and log analyzers that can help automate detecting threats. There are also manual means such as network downtime, credentials being changed 😛 , registry changes, etc.

  • NIST separates Incident Indicators into 2 Categories:
    1. Precursors = a sign that an incident may occur in the future
    2. Indicators = a sign that an incident may have occurred or may be occurring now.

  • Most attacks don’t have any identifiable or detectable precursors from the victim perspective. IF precursors are detected, then that would be the prime time for the organization to really act fast to prevent an incident from occurring. At minimum an organization would want a SoC(Security Operations Center) monitoring their network using a SIEM(Security Information and Event Management) like the Elastic Stack, QRadar, or Splunk. Unfortunately this can be costly so not all companies can afford to have such measures in place, lucky for the hackers.

  • One quick and easy way to boost security is verifying the hashes of a file you’re sending between users. This prevents MITM attacks.

  • Incident Analysis is where the real work for an Incident Handler comes into play. Say an incident could have occurred(you’re not 100% sure yet), you’re on the client site, you’re thrust into that crisis management mode for them, and the IDS is giving you false positives. Many incidents aren’t associated with clear symptoms. The incident handler is responsible for analyzing ambiguous, contradictory, and incomplete symptoms to determine what has happened. You really are trying to put a puzzle together but sometimes the puzzle pieces will be missing, or the edge of a piece will be bitten off because your little sister ate it. It’s a hard job!

  • Once a potential vector for an incident has been found it has to be validated.

  • When it’s time for analysis think profiling networks, understanding what’s normal behavior, event correlation, etc.

1. Containment, Eradication, and Recovery:
   • Containment is important because if an incident gets bad enough it will overwhelm resources, cost downtime, and increase damage overall.

• Organization ought to define acceptable risks when determining strategies for containing an incident.

• You maybe thinking containment!?!?! WHAT? HOW??

• It’s not uncommon for handler to pivot an attacker into a sandbox so they can monitor the attacker’s activity.

• The thing about that is you’d want to consult the legal department to see if that’s feasible to gain more digital evidence.

• You want to get as much evidence as you can to bring to the client in your report. That’s also very important in the instance legal proceedings are needed.

• Containment is another tough game but it’s that classic cat and mouse where the handler needs to identify the attacking host but the attacker keeps moving or is hiding their tracks (think anti-forensics).

• How To Identify an Attacker? It’s precisely what you’d think validating their IP-Address would be the best if possible, but also researching the attacker though search engines, incident databases, IRC channels, to see of past activities. Who knows it could be an APT(Advanced Persistent Threat!) Many APTs are documented enough so identifying them is a tad easier. Thanks Mandiant that FireEye company 😉 😛

• Once successfully contained you’ll prolly want to delete the malware, and disabling breached user accounts, etc. You want to identify and mitigate all the vulnerabilities that were exploited.

• During Eradication you want to identify all the affected hosts for remediation.

• Remediation is the key word here in second half of this phase

1. Post Incident Activity

• So we’ve gotten to the point of the IR where we want the client to learn and improve upon their security. Each IR team ought to stay up to date on the latest trends in the industry and the latest threats.

• What you want to do is hold a “lessons learned” meeting with all the involved peeps from the organization.

• That meeting should provide a chance to achieve closure with respect to the incident being reviewed.

• Think questions like these:
  • What precursors or indicators should be watched for in the future to detect similar incidents?
  • What corrective actions can prevent similar incidents in the future?
  • What would the staff and management do differently the next time a similar incident occurs?
  • What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

• Due to the changing nature of technology, and personal in an org. The IR team should review all related documentation and procedures for when they go to perform their post-mortum engagements. After all they need to stay updated as well on the new threats so they themselves don’t become victim to an attack.

• That was a basic run down of Incident Response and its lifecycle. But by no means is that all of IR. I definitely didn’t cover everything but that should give you enough to go dig deeper or hold your own in a conversation. For some more information I highly recommend checking out NIST and their Incident Handling Guide it’s a 79 page document but there’s a lot that goes into an IR plan: NIST SP800-61r2.

Let me know what y’all think! I’d love to hear your opinions, and interests. Don’t forget to share the post and follow me on Twitter! 🙂