{"id":5677,"date":"2023-08-18T08:00:25","date_gmt":"2023-08-18T12:00:25","guid":{"rendered":"https:\/\/solutionsreview.com\/network-monitoring\/?p=5677"},"modified":"2023-08-21T10:00:45","modified_gmt":"2023-08-21T14:00:45","slug":"learning-from-moveit-what-to-do-when-a-zero-day-is-identified","status":"publish","type":"post","link":"https:\/\/solutionsreview.com\/network-monitoring\/learning-from-moveit-what-to-do-when-a-zero-day-is-identified\/","title":{"rendered":"Learning from MOVEit: What to Do When a Zero-Day is Identified"},"content":{"rendered":"

\"MOVEit\"<\/p>\n

Solutions Review\u2019s\u00a0Contributed Content Series<\/u><\/a> is a collection of contributed articles written by thought leaders in enterprise software categories. Pandian Gnanaprakasam of Ordr<\/a> examines what we can learn from MOVEit and what to do when a zero-day event is identified.<\/strong><\/em><\/p>\n

Disclosure of the MOVEit managed file transfer software vulnerability sent companies scrambling to identify, contain and patch the potentially disastrous security issue. It\u2019s 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.<\/p>\n

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.<\/p>\n

Despite vulnerability disclosures of this magnitude happening often (remember how Log4j ruined IT teams\u2019 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\u2019s easy to ask questions about a zero-day vulnerability like this, finding the answers — and ensuring you\u2019re better prepared for future unexpected disclosures like this — takes some work.<\/p>\n

\t\t\t

\"Download<\/a><\/p>\n<\/div>\n\t\t<\/div><\/div>\n

Learning from MOVEit: What to Do When a Zero-Day is Identified<\/strong><\/h2>\n
\n

Determining Exposure<\/strong><\/h3>\n

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.<\/p>\n

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 \u201cversions\u201d 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 \u201cDo we just see the presence of this software in the environment?\u201d<\/p>\n

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\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Patching the Issue<\/strong><\/h3>\n

Now that you\u2019ve reviewed your vulnerability and have a pretty good idea of whether you\u2019ve been exposed to a zero day, the next step – and the most critical – is to address that vulnerability and return to business as usual.<\/p>\n

Ideally, the IT team would be able to instantly download an appropriate patch and apply it to their systems. However, even though you\u2019ve 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.<\/p>\n

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.<\/p>\n

In some cases, the operating system has already reached end-of-life, but the device has not. There\u2019s 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?<\/p>\n

Alternate Approaches Using Segmentation<\/strong><\/h3>\n

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.<\/p>\n

The idea of segmentation grew out of the need to prevent attackers from breaching perimeter defenses and moving freely across an organization\u2019s 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.<\/p>\n

To implement Zero Trust segmentation, you need to have visibility of the device running in the network, understand what it\u2019s communicating with, and baseline its \u201cnormal behavior.\u201d 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.<\/p>\n

Be Prepared for the Future<\/strong><\/h3>\n

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\u2019t secure what you can\u2019t see. The more connected devices you have, the larger your attack surface– and the more complex this task becomes.<\/p>\n

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 \u201cnormal,\u201d and can alert the team to potential anomalous issues.<\/p>\n

Connected device security solutions manage these critically essential steps:<\/p>\n