This is the first installment in our lockdown series, wherein we discuss methods you can use to effectively contain security events, and how Vectra can help. Stay tuned for the follow-up piece highlighting the Vectra automated lockdown capabilities and our coverage for Microsoft Azure and AWS!
Time is of the essence
Anybody working in incident response (IR) will tell you that the faster you contain an event, the less likely it'll become a full-blown incident. Validation of a detection should be swiftly followed by isolation. This buys time for evidence gathering, scoping, and ultimately remediation. Depending on the type of detection, we may only have a part of the picture.
Take, for example, a Port Sweep detection targeting a number of hosts from a single source. In this scenario, we need to know how the system is being accessed, how the attacker gained a foothold, how long they've had access, or if there has been any successful lateral movement. All of these questions take time to answer.
We also need to consider the dwell time of the attacker. The more time they have access to the environment, the closer they'll get to actualizing their goal (e.g. encrypting file servers and holding the business for ransom, or exfiltrating that new research your organization has worked on for several years). Obstructing the attacker's advance and giving the incident responders valuable time to investigate will lead to better informed decisions during remediation. Once an attacker has privileged access, they can move faster and further to complete their mission.
Consider the example of MAZE Ransomware: attackers created their own accounts and leveraged privileged accounts to spread across the network. Containment is the answer to disrupting this advance and stopping attackers such as the MAZE operators from using privileged accounts on the network to deploy their ransomware.
How to enforce?
There are a number of ways to contain an attacker. We could isolate the attack in one of two ways: first, through an endpoint agent on the host; second, on the network stack by disabling the account used for lateral movement or modifying the exploited service. In most cases, the endpoint isolation can quickly and effectively stop any interaction by breaking the target systems communication to or from anywhere except a predefined list of systems. This allows for the remote collection of further evidence without the need to take the system offline and ship it back to your incident response team, who can perform the investigation remotely before releasing the system back to either the local IT team or the end user.
If we identify an account being abused for lateral movement then we can disable the account in Active Directory. If it's a local account, it's less likely the attacker will be able to get very far as local accounts do not have group privileges applied and will prohibit an attacker to move laterally.
We can also achieve a similar result by leveraging using the network stack to perform isolation, leveraging ACLs (Access Control Lists) or putting the system in a separate VLAN stops interaction with other systems on the network. Creating a VLAN for remediation is a common practice, and this VLAN allows the endpoint to talk back to management systems like Windows Patch Server update server, Microsoft System Center Configuration Manager ( SCCM), or antivirus endpoint detection and response (EDR), but nowhere else on the network.
Another way to achieve isolation is by leveraging Microsoft's GPO (Group Policy Objects) to manage Windows endpoint firewall rules. You create a policy to block all services by default and then whitelist critical services. An important note here is that you'll need to ensure local policies are ignored since a user (or malware) can modify local systems’ firewall rules by default.
For critical services where we can't simply isolate the system without impacting the business, consider limiting service access based on source IP or account. On a Linux system, we could leverage ip tables or update /etc/host.deny. We should also consider access from the system: if it's a mail relay, maybe we can exclusively limit the traffic to and from TCP port 25 and to one internet destination (Exchange) while we investigate further. It won't be possible to write a playbook for every scenario; that said, it's important to be aware that unusual scenarios may arise and will require Incident Response expertise.
Part two – taking it to the cloud:
Speed is a key ingredient to successful containment, logging into another platform, finding the host or policy you want and applying it all takes time. Vectra enables security teams to contain directly in the platform, users can easily see and manage containment settings from a single pane of glass.
In the next part of this blog series, we’ll look at what actions can be taken for infrastructure in the cloud and how to automate lockdown actions from Vectra.