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.