4.4 Given an incident, apply mitigation techniques or controls to secure an environment

  • Reconfigure Endpoint Security Solutions
    • Application Approved List
    • Application Blocklist / Deny List
    • Quarantine
  • Configuration Changes
    • Firewall Rules
    • MDM
    • DLP
    • Content Filter / URL Filter
    • Update or Revoke Certificates
  • Isolation
  • Containment
  • Segmentation
  • SOAR
    • Runbooks
    • Playbooks

When faced with an attack, we can take some measures to ensure that it doesn’t happen again.

Reconfigure Endpoint Security Solutions

  • Application Approved List.  The approved list is a list of applications that are permitted.  If our incident was created by an incident on the list, we might remove it from the list.

    If we don’t have an approved list, then we might want to create one.  Any application that is not on the list is automatically prohibited.

  • Application Blocklist / Deny List.  The blocked list is a list of applications that are not permitted.  If we find that the incident was caused by a malicious application, we can add it to the block list.

  • Quarantine.  We can quarantine any device that appears to be part of the incident until we can further investigate.  When a device is quarantined, it cannot

Configuration Changes

  • Firewall Rules.  If the incident was created by an insecure firewall, we can add some rules

    • Deny traffic from specific sources

    • Deny traffic to a specific destination

    • Deny traffic between specific ports

    • Deny traffic from specific applications

    • Use an advanced firewall such as a Next Generation Firewall that uses AI

  • MDM.  If the incident was caused by a weak mobile device, we can apply Mobile Device Management.  If we already have Mobile Device Management, we can improve the security

    • Force mobile devices to accept operating system updates

    • Delete unnecessary applications

    • Enforce security settings such as longer passwords and encryption

    • Compartmentalize user data and corporate data

  • DLP.  If the incident was created by a data leak, we should implement a Data Leak Prevention system.  If we already have a DLP, then it probably wasn’t working well, and we need to train it.

    We also need to educate users about data protection.

  • Content Filter / URL Filter.  If the incident was caused by a virus, we should implement a content filter to block malicious websites and data.

  • Update or Revoke Certificates.  If the incident was caused by a source that used to be trusted, we should revoke its certificate.  That might be a user account or device that has access to our network.


Isolation is where we move a device to an area where it cannot connect back to the rest of the network.  The isolation may be physical, or it may be logical.  Once a device is isolated, we can repair it or send it the necessary updates.  Once the device is compliant with our policies, it can be moved back to the main network.


Containment is a concept where each application runs inside its own virtual machine.  If an application is not aware of the presence of other applications, devices, or files, the risk that it can infect something is minimal.


As discussed earlier, we can create divide our network into different segments using VLANs, or even physically.  We can take segmentation a step further and logically isolate each device into its own subnet so that a hacker or malicious application cannot move laterally from one device to another.  Many viruses and ransomware have been able to spread over a network by taking advantage of a vulnerability in a Windows network tool.  If the devices can’t see each other, then the malware can’t spread.


SOAR or Security Orchestration, Automation, and Response is an idea where we can combine multiple types of threat response.  It includes an SIEM, a security incident response system, and security automation.

When the SIEM detects a threat, it automatically notifies an administrator and creates an incident.  It can also launch an automatic response; the type of response depends on the type of incident and its severity.  We can program the SOAR to respond the way that we want.

Some examples

  • The SIEM detects that a user has accessed too many shared files in a short time.  SOAR notifies an administrator or the user’s manager to investigate further.  SOAR takes no further action.

The SIEM detects that ransomware has infected a user’s computer through an e-mail.  SOAR automatically shuts down the user’s computer and isolates it from the network.  SOAR notifies an administrator of the issue and begins an in-depth scan of other devices on the network.  SOAR also takes a fingerprint of the ransomware and adds it to its threat database so that it can be blocked if it attempts to enter through another mechanism

  • Runbooks – the runbook is a set of conditional instructions that form a response to a specific task.  We can automate a runbook.  A runbook is good if our incident response must comply with a specific regulation.  It ensures that tasks are followed.

  • Playbooks – we can combine the runbooks to create a playbook. 

But now that you know all these security measures (and you have been reading about them for the last 600 pages), implement them now instead of waiting for an incident to happen.  Your management might want to spend the money until something bad happens.

One company had no security because their management didn’t care until they were hit with a ransomware attack that bricked 20,000 machines.  Once it happened, they went crazy and rushed to implement intense security policies with no planning.  Now their network is secure, but nobody can get anything done because they can’t remember their complicated passwords that they have to change every day.  The lost productivity from the security is probably worse than the ransomware attack.