Lessons Learned from A Biopharma Cybersecurity Attack
By Mitch Tanenbaum
Over the July 14, 2018 weekend, LabCorp, one of the largest medical testing labs in the world, announced that it had shut down large parts of its internal network because it had detected suspicious activity. Due to the size and nature of the business, in the event of a breach, the company is required to file reports with both the SEC and the Department of Health and Human Services Office of Civil Rights (DHS-OCR). Based on those reports, we have some more details. Likely, we will continue to learn more over time, but even with limited information, we have a pretty good picture of things.
In general, there are three major concerns related to cybersecurity incidents, each of which represents a certain negative financial impact to the company:
- loss or destruction of patient data
- damage to the company’s reputation
- theft of IP.
But there are other issues as well
- damage to products in development and in production
- product shortages in the supply chain
- probable lawsuits, possibly class actions.
For all of these reasons, it is in every company’s best interest to avoid cybersecurity incidents and, in the event of an incident, to minimize its impact if it cannot be avoided.
Here we use the events of the recent LabCorp incident to help other companies gauge their own ability to prevent or respond to an incident. In doing so, there are three phases to any cyberincident:
#1 – TIME TO DETECT
In this recent cybersecurity incident, LabCorp says it was able to detect the incident almost immediately. On average, it takes U.S. companies 206 days to detect a breach1. The Ponemon Institute recommends companies should set a goal of detecting a breach within 100 days. That is certainly better than 206 days, but is it acceptable to you to have intruders in your network for 100 days?
In the LabCorp case, which was a ransomware attack, the incident was incredibly damaging with very obvious effects, making quick detection likely. With ransomware, the attacker wants you to know they are there. Most of the time, however, the objective of an attacker is to keep a low profile, making detection much harder.
Remember that cybersecurity incidents do not always follow normal business hours. In the case of LabCorp, the incident started around midnight on a Friday night.
LabCorp has a Security Operations Center, or SOC. This SOC received alerts immediately, even though the event happened on a Friday night at midnight.
QUESTIONS:
Do you have a Security Operations Center? Does it operate 24/7/365? Do you have any systems that monitor your network that can generate real-time alerts for security incidents?
METRIC:
Track the amount of time between intrusion and detection, and create targets for decreasing this time window.
#2 – TIME TO CONTAIN THE CYBERSECURITY INCIDENT
After managing and reducing the time to detect a cybersecurity incident, the next most important metric is how long it takes to contain the incident. In the Lab- Corp case, the company says it took only 50 minutes to contain the damage. Again, this was a ransomware attack — and easier to “manage.”
In order to do this, a company needs to have an accurate map of its environment and have the mechanisms to allow the company to be able stop the malware in real time. A good way to do this is through network segmentation and even network micro-segmentation. This may require re-architecting your network.
QUESTION:
Do you have the ability to shut down parts of your network quickly in the case of a cybersecurity incident?
METRIC:
Track the amount of time it takes to contain any cybersecurity incidents, and create targets to reduce this time.
Note that some incidents will be quick to detect and contain, and others will not be, so you will need the ability to track these events over time.
#3 – TIME TO REPAIR
After the company has the malware contained, the next course of business is to recover. There are two metrics that are important here:
- The first is the recovery-time objective (RTO) – the amount of time it takes to get things working again. That time is not the same for all systems. A critical production system that impacts revenue or stops work in progress from being damaged or destroyed is more important than, say, an administrative system used by some internal department (although that department may disagree).
- The second metric is the recovery point objective (RPO) – how far back in time you have to go or how much work you are going to lose when you recover. For example, if you do nightly backups, you could lose 24 hours worth of work. If this is not acceptable, then you may need to back up data more frequently.
The RTO is influenced by how many systems are affected and the types of systems.
In the case of LabCorp, in that 50-minute window, 7,000 computers were infected, of which 1,700 were servers, and of those, 300 were production servers. LabCorp claimed it had 90 percent of those devices recovered about a week after the attack. If a week is not an acceptable recovery time, then alternatives need to be created.
QUESTIONS:
Do you have an inventory of all systems and their functions? Is there agreement as to what an acceptable RTO and RPO are? How often do you test your RTO and RPO time frames?
METRIC:
Create RTO metrics and RPO for all systems from end-user devices to servers in the cloud.
LESSONS LEARNED
In the case of LabCorp, it is believed that the breach was able to infect such a large number of systems so quickly because the company had remote desktop protocol (RDP) enabled and did not use multifactor authentication (MFA). Hopefully, that will change, but what is more important is that the company has a process to identify changes (lessons) that need to be made after an incident and then has a process to ensure that those lessons are implemented.
Does your company have a process to document lessons learned from every incident and another process to ensure that those lessons are implemented?
1https://www.itgovernanceusa.com/blog/how-long-does-it-take-to-detect-a-cyber-attack/
MITCH TANENBAUM is partner and technical director at CyberCecurity, LLC. He is a leading expert in the field of cybersecurity and has over 30 years of experience managing data centers, computer operations teams, developers, and security teams.