Learning from MOVEit: What to Do When a Zero-Day is Identified
-
By
Pandian Gnanaprakasam
, Co-Founder and CPO at Ordr - Network Monitoring Best Practices,
Solutions Review’s Contributed Content Series is a collection of contributed articles written by thought leaders in enterprise software categories. Pandian Gnanaprakasam of Ordr examines what we can learn from MOVEit and what to do when a zero-day event is identified.
Disclosure of the MOVEit managed file transfer software vulnerability sent companies scrambling to identify, contain and patch the potentially disastrous security issue. It’s a big problem– MOVEit is used by thousands of companies, including an estimated 1,700 software companies and 3.5 million developers. MOVEit is also significantly used in the healthcare industry, with HHS taking the extraordinary step of issuing an alert about the vulnerability.
Are we exposed? Do we use it? Have these vulnerabilities already been exploited in my network? How deeply have the hackers penetrated my network– and how much data has already been exfiltrated? These are the questions asked immediately after a vulnerability of this sort is identified.
Despite vulnerability disclosures of this magnitude happening often (remember how Log4j ruined IT teams’ December holidays a couple of years ago?), many companies need help to see if they are exposed and how deep the exposure might be. While it’s easy to ask questions about a zero-day vulnerability like this, finding the answers — and ensuring you’re better prepared for future unexpected disclosures like this — takes some work.
Learning from MOVEit: What to Do When a Zero-Day is Identified
Determining Exposure
The first question to answer when a zero-day like MOVEit is disclosed is whether you are exposed or not. This sounds simple, but is easier said than done.
First, most organizations lack visibility into devices, their complete context, and the software applications running on each one of those devices. Second, to determine whether your devices are vulnerable to, for example, MOVEit, you need to identify the actual software level of MOVEit in each device, as not all “versions” of MOVEit are impacted. This, of course, varies based on the software attacked and the specificity of the vulnerability. But the point is you need to know more than just “Do we just see the presence of this software in the environment?”
Software Bill of Materials (SBOM) are intended to help with visibility into applications; an SBOM is an inventory of all the software components and their dependent libraries. While this list of applications running on a device is analogous to a packaged food product ingredient list, it’s just not as easy as checking the label on the side. An SBOM is a point-of-time snapshot, may not reflect what is actually being used in real-time, and depends on the willingness of the manufacturer to update the details when software is upgraded or patched.
It is very hard for product vendors to come up with a detailed list of all software components, as each one of these components in turn pulls in various software packages for the final assembly. The flaw could be in any of those software components, or perhaps in the hundreds of packages that are being used in conjunction with the software. Additionally, even when the manufacturers publish them, SBOM formats are often challenging to parse and search through, if published in an electronic format without proper standardization.
Alternate options to SBOMs should be explored to attain the visibility you need. For example, at Ordr, we created a lightweight app that organizations can deploy on their endpoint, that does not impact device operations, but provides visibility into the granular applications running on their devices.
Patching the Issue
Now that you’ve reviewed your vulnerability and have a pretty good idea of whether you’ve been exposed to a zero day, the next step – and the most critical – is to address that vulnerability and return to business as usual.
Ideally, the IT team would be able to instantly download an appropriate patch and apply it to their systems. However, even though you’ve confirmed your organization is running a vulnerable application, patches may only be available some of the time. The vulnerability may be very difficult to correct, so the vendor may still be working on a fix. Perhaps the vulnerability was discovered by a hacker who publicized it instead of contacting the vendor, or the vulnerability could have come to light because of a successful attack.
It could also be an issue of the patch being unable to be applied to the software in question because it is a device that cannot be accessed easily for updates. It could be in regular, repeated use – and that use could be of a critical nature. Think of a surgical tool or emergency room diagnostic equipment. The device could also be in a mission-critical function that cannot be upgraded and/or patched without going through a whole slew of certifications to be able to begin using it again.
In some cases, the operating system has already reached end-of-life, but the device has not. There’s simply no way to update or upgrade it. So, it still will be used for another five to ten years, but now every time it is used it opens the organization to an attack. What can an organization do at this point to stop attackers from compromising their organization through a zero-day?
Alternate Approaches Using Segmentation
If, as described above, there are potential problems patching the zero-day in specific areas of use, Zero Trust segmentation is a potential compensating control.
The idea of segmentation grew out of the need to prevent attackers from breaching perimeter defenses and moving freely across an organization’s network, quickly and easily gaining access to areas of critical information that they could profit from. With Zero Trust segmentation, you are baselining what is normal behavior for the device and allowing only those communications – and nothing else.
To implement Zero Trust segmentation, you need to have visibility of the device running in the network, understand what it’s communicating with, and baseline its “normal behavior.” With this information, teams can design and apply segmentation policies that mitigate the risk of a zero-day, without forcing critical devices or equipment offline. For example, an HVAC system can communicate with smart-building controls using approved protocols while still being blocked from connecting to the outside internet.
Be Prepared for the Future
The examples above are how to address a zero-day vulnerability when it strikes. But there are still other strategies you can put in place to be prepared for the future. The most important best practice is visibility into every asset on your network, as you can’t secure what you can’t see. The more connected devices you have, the larger your attack surface– and the more complex this task becomes.
Connected device security solutions can assist in this process – identifying for a team exactly what is connected, what it connects to, and what it is running, so a risk score can be established for each device or piece of equipment. Just as critical is the ability to baseline what normal activity looks like on your network, so that in the future a security system has a clear definition of “normal,” and can alert the team to potential anomalous issues.
Connected device security solutions manage these critically essential steps:
- Discovery and classification of every device
- Identification of vulnerabilities and risks
- Real-time detection of exploits using intrusion detection systems
- Tracking of communications to compromised IP/URLs
- Baselining of device behavior to surface anomalies and create Zero Trust segmentation policies
With the continued increase of new zero-day discoveries and disclosures, it becomes even more important for the organization to embrace compensating control techniques like zero trust segmentation.
Move Quickly
The bottom line is that time is of the essence in addressing these types of zero-day vulnerabilities. The ability to automate detection and vulnerability mapping of impacted devices, identify potential exploits, and quickly mitigate risks via segmentation is key to both reducing the impact– and putting the organization on the correct path for faster mitigation of future exploits. Start preparing for the next zero-day now by gaining a complete asset inventory of what’s in your network!
- Learning from MOVEit: What to Do When a Zero-Day is Identified - August 18, 2023
Pandian Gnanaprakasam
Pandian Gnanaprakasam has more than 20 years of product and engineering leadership experience and is also a serial entrepreneur. Before founding Ordr, he was the Chief Development Officer at Aruba, responsible for all engineering and product management functions. Aruba, an enterprise mobile wireless company, was acquired by HPE for $3 Billion in March 2015. Before Aruba, Pandian served as the head of engineering for Cisco’s multi-billion-dollar Wi-Fi business unit and before that as VP of engineering for low-end switching product lines. He graduated with a master’s degree in Electrical Engineering from IIT, Chennai, India, and holds several patents to his credit in various networking technologies.
