[BreachExchange] Implementing Effective Remote Incident Response in a Pandemic

[Destry Winant]

https://www.infosecurity-magazine.com/blogs/implementing-response-pandemic/

Cybersecurity threats have risen by over 37% in the last month, with
threat actors and cyber-criminals using the fear brought on by the
COVID-19 pandemic as a target of opportunity to further their phishing
and ransomware attacks.

Scammers are taking advantage of this unique moment and seeking those
who are most vulnerable with hospitals, in particular, being actively
targeted. This is bad enough in a normal situation, but given the
current lifesaving work that is being conducted it’s reprehensible! In
response to this, my company (NTT Ltd) is offering to provide
hospitals around that world that are treating COVID-19 patients with
cybersecurity incident response support at no cost, if an incident
occurs.

With a lockdown being enforced across most countries across the world,
things are made more complicated as it becomes harder to dispatch
traditional Digital Forensics and Incident Response (DFIR) teams to
client sites. However, with the massive shift in digital
transformation and remote working seen following the virus outbreak,
remote incident response is a real alternative. So what are some of
the challenges experienced with this approach and how can
organizations take advantage?

For remote incident response teams, the biggest problem faced is not
being able to get their hands on all of the affected systems or to be
able to access organizations’ SIEM and other logging technologies (for
those organizations who have their SOC staff working remotely this is
a must!). Also something as simple as sitting down and talking to
people becomes harder. While the likes of Webex, Zoom, and Microsoft
Teams are easing the problem through remote teleconferences, they
aren’t quite the same as face to face interaction.

In a remote deployment of an incident response team the first and most
obvious strategy is to extend access to internal tools. The easiest
way to do this is to screen share via a conferencing tool, however
that is reliant upon whoever is running the session to drive the
investigation with the incident responder’s guidance.

A much easier option is to provide remote access to the security
tools, but this is not always possible depending upon how systems are
configured and regulatory/security concerns.

What a lot of incident response teams have moved to over the last few
years has been cloud-based Endpoint Detection and Response (EDR) tools
(which are sometimes referred to as Next Gen AV). These toolsets (and
there are a lot out there now) offer the ability to run an
investigation from anywhere on the planet and be able to have a full
visibility of an organization’s endpoints and servers.

Once the cloud instance is stood up, an MSI agent is able to be
deployed out across the endpoint and server estate(s) by the client
organization (via group policy or other available tools) in small
batches (10-20 sensors initially to ensure there are no compatibility
issues. In an ideal world EDR tools would be deployed across an estate
BEFORE the incident as the full history and timeline artefacts are
available.

As the endpoints start to roll in, it is then time to ensure all of
your Intelligence feeds and other Threat Hunting Indicators of
Compromise (IOC) information is populated within the EDR console.
However, ensure you have a contingency for your deployment plan if the
Multiprotocol Label Switching (MPSL) or Virtual Private Network (VPN)
is down. Ensure you have a Plan B for additional remote access!

Other options involve the building of a Forensic Lab within the
affected network (segregated obviously) which allows for remote
processing of information without the need to upload large images
externally to IR service providers. Granting access to the Lab enables
organizations to retain their data (and audit trail) whilst also
having the flexibility of hands-on analysis remotely.

Triage of the incident can start the minute that systems start to roll
in (and can be targeted if there are already suspect machines within
the investigation). At this point you will revert to your standard
incident response process/runbook to investigate, but for most cases
you will be seeking to identify malicious content (and downloading a
copy for offline analysis) and building out bespoke watchlists to
search for additional hosts associated with the
malware/breach/incident.

As more and more suspect files are identified, they can be quarantined
(in line with your strategy) either on an individual file (allowing
the host to still remain online) or to completely remove the network
access from the host pending a rebuild (as and when the IT team are
able to get someone remove it physically).

That brings us to the biggest problem here for EDR’s or any other
tools without some level of on-site support: the investigation can
only quarantine the threat. A true clean-up of the threat is still
going to involve a physical reimaging of the affected system unless
the organization is able to use System Center Configuration Manager
(SCCM) or another tool to re-image remotely. Therefore, planning how
this is going to happen (if it is going to happen!) remotely is now
really important and should be baked into the newly updated Business
Continuity Plans!

Teleconferences were touched upon earlier and as with all incident
response activities communications is key. Holding frequent meetings
with clear and concise status updates ensures that all tasks stay on
track. Having a good two way communications between all the parties
involved in the remote investigation will reduce any confusion and
speed up the containment and remediation process.

In these days of working from home, communication is more important
than ever for incident response.