Incident Handling Process

 

Before we start talking about handling incidents, we need to understand the attack lifecycle (a.k.a. the cyber kill chain). This lifecycle describes how attacks manifest themselves. Understanding this lifecycle will provide us with valuable insights on how far in the network an attacker is and what they may have access to during the investigation phase of an incident.The cyber kill chain consists of seven (7) different stages.

The recon stage is the initial stage, and it involves the part where an attacker chooses their target. Additionally, the attacker then performs information gathering to become more familiar with the target and gathers as much useful data as possible.

In the weaponize stage, the malware to be used for initial access is developed and embedded into some type of exploit or deliverable payload.

In the delivery stage, the exploit or payload is delivered to the victim(s). Traditional approaches are phishing emails that either contain a malicious attachment or a link to a web page.

The exploitation stage is the moment when an exploit or a delivered payload is triggered. During the exploitation stage of the cyber kill chain, the attacker typically attempts to execute code on the target system in order to gain access or control. 

In the installation stage, the initial stager is executed and is running on the compromised machine. As already discussed,

In the command and control stage, the attacker establishes a remote access capability to the compromised machine. As discussed,

The final stage of the chain is the action or objective of the attack. The objective of each attack can vary.

Incident handlers spend most of their time in the first two stages, preparation and detection & analysis. This is where we spend a lot of time improving ourselves and looking for the next malicious event.

Preparation Stage (Part 1)

In the preparation stage, we have two separate objectives. The first one is the establishment of incident handling capability within the organization. The second is the ability to protect against and prevent IT security incidents by implementing appropriate protective measures. Such measures include endpoint and server hardening, active directory tiering, multi-factor authentication, privileged access management, and so on and so forth.

During the preparation, we need to ensure that we have:

• Skilled incident handling team members (incident handling team members can be outsourced, but a basic capability and understanding of incident handling are necessary in-house regardless)
• Trained workforce (as much as possible, through security awareness activities or other means of training)
• Clear policies and documentation
• Tools (software and hardware)

Some of the written policies and documentation should contain an up-to-date version of the following information:

• Contact information and roles of the incident handling team members
• Contact information for the legal and compliance department, management team, IT support, communications and media relations department, law enforcement, internet service providers, facility management, and external incident response team
• Incident response policy, plan, and procedures
• Incident information sharing policy and procedures
• Baselines of systems and networks, out of a golden image and a clean state environment
• Network diagrams
• Organization-wide asset management database
• User accounts with excessive privileges that can be used on-demand by the team when necessary (also to business-critical systems, which are handled with the skills needed to administer that specific system). These user accounts are normally enabled when an incident is confirmed during the initial investigation and then disabled once it is over. A mandatory password reset is also performed when disabling the users.
• Ability to acquire hardware, software, or an external resource without a complete procurement process (urgent purchase of up to a certain amount). The last thing you need during an incident is to wait for weeks for the approval of a $500 tool.
• Forensic/Investigative cheat sheets

Moving forward, we also need to ensure that we have the right tools to perform the job. These include, but are not limited to:

• Additional laptop or a forensic workstation for each incident handling team member to preserve disk images and log files, perform data analysis, and investigate without any restrictions (we know malware will be tested here, so tools such as antivirus should be disabled). These devices should be handled appropriately and not in a way that introduces risks to the organization.
• Digital forensic image acquisition and analysis tools
• Memory capture and analysis tools
• Live response capture and analysis
• Log analysis tools
• Network capture and analysis tools
• Network cables and switches
• Write blockers
• Hard drives for forensic imaging
• Power cables
• Screwdrivers, tweezers, and other relevant tools to repair or disassemble hardware devices if needed
• Indicator of Compromise (IOC) creator and the ability to search for IOCs across the organization
• Chain of custody forms
• Encryption software
• Ticket tracking system
• Secure facility for storage and investigation
• Incident handling system independent of your organization's infrastructure

Many of the tools mentioned above will be part of what is known as a jump bag - always ready with the necessary tools to be picked up and leave immediately. 

Preparation Stage 

Another part of the preparation stage is to protect against incidents. Let us now look at some of the highly recommended protective measures, which have a high mitigation impact against the majority of threats.DMARC is an email protection against phishing built on top of the already existing SPF and DKIM. The idea behind DMARC is to reject emails that 'pretend' to originate from your organization. Therefore, if an adversary is spoofing an email pretending to be an employee asking for an invoice to be paid, the system will reject the email before it reaches the intended recipient. DMARC is easy and inexpensive to implement, however, I cannot stress enough that thorough testing is mandatory; otherwise (and this is oftentimes the case), you risk blocking legitimate emails with no ability to recover them. Remember to also block script types such as .hta, .vbs, .cmd, .bat, .js, and similar. Please pay attention to LOLBin files while implementing whitelisting. Do not overlook them; they are really used in the wild as initial access to bypass whitelisting.Utilize host-based firewalls. As a bare minimum, block workstation-to-workstation communication and block outbound traffic to LOLBin.Deploy an EDR product. At this point in time, AMSI provides great visibility into obfuscated scripts for antimalware products to inspect the content before it gets executed. It is highly recommended that you only choose products that integrate with AMSI.

Detection & Analysis Stage 

The detection & analysis phase involves all aspects of detecting an incident, such as utilizing sensors, logs, and trained personnel. It also includes information and knowledge sharing, as well as utilizing context-based threat intelligence. Segmentation of the architecture and having a clear understanding of and visibility within the network are also important factors.It is highly recommended to create levels of detection by logically categorizing our network as follows.

• Detection at the network perimeter (using firewalls, internet-facing network intrusion detection/prevention systems, demilitarized zone, etc.)
• Detection at the internal network level (using local firewalls, host intrusion detection/prevention systems, etc.)
• Detection at the endpoint level (using antivirus systems, endpoint detection & response systems, etc.)
• Detection at the application level (using application logs, service logs, etc.)we should aim to collect as much information as possible at this stage about the following:
  • Date/Time when the incident was reported. Additionally, who detected the incident and/or who reported it?
  • How was the incident detected?
  • What was the incident? Phishing? System unavailability? etc.
  • Assemble a list of impacted systems (if relevant)
  • Document who has accessed the impacted systems and what actions have been taken. Make a note of whether this is an ongoing incident or the suspicious activity has been stopped
  • Physical location, operating systems, IP addresses and hostnames, system owner, system's purpose, current state of the system
  • (If malware is involved) List of IP addresses, time and date of detection, type of malware, systems impacted, export of malicious files with forensic information on them (such as hashes, copies of the files, etc.)

The investigation starts based on the initially gathered (and limited) information that contain what we know about the incident so far. With this initial data, we will begin a 3-step cyclic process that will iterate over and over again as the investigation evolves. This process includes:

• Creation and usage of indicators of compromise (IOC)
• Identification of new leads and impacted systems
• Data collection and analysis from the new leads and impacted systems

Containment, Eradication, & Recovery Stage

we take action to prevent the spread of the incident. We divide the actions into short-term containment and long-term containment. It is important that containment actions are coordinated and executed across all systems simultaneously. Otherwise, we risk notifying attackers that we are after them, in which case they might change their techniques and tools in order to persist in the environment.Once the incident is contained, eradication is necessary to eliminate both the root cause of the incident and what is left of it to ensure that the adversary is out of the systems and network. Some of the activities in this stage include removing the detected malware from systems, rebuilding some systems, and restoring others from backup.In the recovery stage, we bring systems back to normal operation. Of course, the business needs to verify that a system is in fact working as expected and that it contains all the necessary data. When everything is verified, these systems are brought into the production environment. All restored systems will be subject to heavy logging and monitoring after an incident, as compromised systems tend to be targets again if the adversary regains access to the environment in a short period of time. Typical suspicious events to monitor for are:

• Unusual logons (e.g. user or service accounts that have never logged in there before)
• Unusual processes
• Changes to the registry in locations that are usually modified by malware

  Post-Incident Activity Stage

  In this stage, our objective is to document the incident and improve our capabilities based on lessons learned from it. This stage gives us an opportunity to reflect on the threat by understanding what occurred, what we did, and how our actions and activities worked out. This information is best gathered and analyzed in a meeting with all stakeholders that were involved during the incident. It generally takes place within a few days after the incident, when the incident report has been finalized.

  Reporting

  The final report is a crucial part of the entire process. A complete report will contain answers to questions such as:

  • What happened and when?
  • Performance of the team dealing with the incident in regard to plans, playbooks, policies, and procedures
  • Did the business provide the necessary information and respond promptly to aid in handling the incident in an efficient manner? What can be improved?
  • What actions have been implemented to contain and eradicate the incident?
  • What preventive measures should be put in place to prevent similar incidents in the future?
  • What tools and resources are needed to detect and analyze similar incidents in the future?

  Such reports can eventually provide us with measurable results. For example, they can provide us with knowledge around how many incidents have been handled, how much time the team spends per incident, and the different actions that were performed during the handling process. Additionally, incident reports also provide a reference for handling future events of similar nature. In situations where legal action is to be taken, an incident report will also be used in court and as a source for identifying the costs and impact of incidents.