{"id":213,"date":"2024-10-19T01:57:33","date_gmt":"2024-10-19T01:57:33","guid":{"rendered":"https:\/\/cybersecuritysanity.com\/?p=213"},"modified":"2024-10-19T03:20:40","modified_gmt":"2024-10-19T03:20:40","slug":"an-underwriters-guide-to-cyber-risk-managing-3rd-party-risk-part-2","status":"publish","type":"post","link":"https:\/\/cybersecuritysanity.com\/?p=213","title":{"rendered":"An Underwriters’ Guide to Cyber Risk: Managing 3rd Party Risk – Part 2"},"content":{"rendered":"\n

Understanding and Preventing Zero Day And Other Software Supply Chain Attacks<\/strong><\/p>\n\n\n\n

This is the second post in the series, intended to help better understand how third party risks can be managed, and addressing the problem of misinformation from high raking sources. Because of the pervasiveness of the myth that third party risks are unmanageable, primarily due to the insistence by insurance executives that “Well I don’t understand it, and therefore it can’t be done.” But because of this toxic insistence, it is necessary to break things down and provide detailed supporting information.<\/p>\n\n\n\n

In this post, we will look at zero days and unpatched vulnerabilities as a type of exposure to third party risk. Zero days are similar to supply chain attacks, and many of the same methods for controlling zero days apply to supply chain attacks as well. MOVEit is an example of a zero day attack, which caused massive damage to the US and global economy. It illustrates exactly how these attacks work.<\/p>\n\n\n\n

In some ways, it was the kind of systemic attack that insurers are constantly complaining about. However, it also illustrates all the ways the damage could have been prevented. MOVEit was bad, but it was also tragic, because so much of the loss could have been prevented, if we had our act together on this.<\/p>\n\n\n\n\n\n\n\n

Manage Third Party Risk Through Critical Patch and Zero Day Management:<\/strong>
One of the biggest unnecessary losses that we continue to su\ufb00er is that of unpatched so\ufb05ware, which as been exploited and is actively being used to attack businesses. The principle is not hard to understand: so\ufb05ware sometimes has \ufb02aws discovered in it, and those \ufb02aws may make the so\ufb05ware subject to compromise. If this is the case, and the so\ufb05ware is high risk then moments matter. Mitigating steps must be taken right away, and these can include patching the so\ufb05ware or, if necessary, suspending its use until it can be safety returned to service.<\/p>\n\n\n\n

A \u201dZero day\u201d is a situation where there are zero days of notice on a critical \ufb02aw, because the bad guys discover it \ufb01rst and the \ufb01rst sign of trouble is that you are breached by a novel \ufb02aw that was previously unknown and therefore could not be avoided. While this can happen, it should be noted that it would be astronomically bad luck to be hit on the literal \ufb01rst day an exploit is discovered and few organizations truly are.<\/p>\n\n\n\n

Last summer, the world su\ufb00ered the single most costly and damaging supply chain attack in history. The a\ufb05ermath is still not fully clear. Hundreds of companies were hacked and some of the most sensitive, highly damaging and private information is now in the hands of some of the most viscous ransomware gangs out there. The attack pumped over a quarter billion dollars of ransom into the Kl0p group, with some of it ending up with a\ufb03liates in Iran and North Korea. The attack has le\ufb05 the US and allies with a gaping wound torn open. The ransomware gangs now have the single largest injection of cash in their history, and much of it is already being used to buy weapons for the pro-Russia Ukrainian groups in the Donbas region.<\/p>\n\n\n\n


MOVEit: A Textbook Example of What We Are Doing Wrong<\/strong>
The problem started with a product called MOVEit. MOVEIt is a secure server made by Progress so\ufb05ware. It is used in the highest security environments as a way of transferring high risk \ufb01les between locations. For example, if a medical or \ufb01nancial institution needed to provide o\ufb00-site access to secret \ufb01les, MOVEit would be a natural choice to use, and thousands of customers use if for just that. As such, some of the most secure and sensitive environments rely on MOVEit. One would expect that such a product would be the subject to the highest levels of security testing and certi\ufb01cation, but that is o\ufb05en not the case, due to poor enforcement and lax standards.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

On May 27, 2023, it was discovered that the MOVEit server could easily be breached by an outsider through a simple method known as code injection. Code injection simply means that a command could be entered into the \ufb01elds for things like login or password. If, instead of entering a login, a user entered a command to the system, the command would be run, allowing the user to unlock the server completely and do as they pleased.<\/p>\n\n\n\n

Code injection is a well known type of attack. The image to the le\ufb05 shows how a user might enter computer code into a password \ufb01eld with the intention of bypassing the passwords. Code injection has been around for decades. It’s normally the result of poor coding practice. It’s so well known and common that it is standard for it to be tested for when secure systems are evaluated. Unfortunately, because that is not enforced and there is no third party to hold anyone’s feet to the \ufb01re on it, code testing is rarely done and even when it is, external audits and assurance is very rare.<\/p>\n\n\n\n

Almost as soon as the \ufb02aw was discovered, it was exploited. Exploiting it was easy. MOVEit servers frequently face the internet and are as easy as using Google to \ufb01nd. Using other search methods, the Kl0p gang, a terrorist group aligned with the Russian far right and with a\ufb03liates in Afghanistan, Iran, Syria and North Korea began to exploit the MOVEit \ufb02aw. The \ufb01rst victims included the BBC, British Airlines and numerous other organizations in the US, UK and Canada. The attack started in the UK but within days, servers were being breached on both sides of the Atlantic.<\/p>\n\n\n\n

At this point no further breach should have happened, because by end the of May, word had gotten out and a patch to \ufb01x the problem. Every breach that happened a\ufb05er the patch was issued and news dispatched as an act of extreme negligence.<\/p>\n\n\n\n

Before the end of June, beaches at United Healthcare, Johns Hopkins University, Virgin, Aon, Prudential, Shell and others had leaked the private information of hundreds of millions of people, cost the world billions of dollars and enriched Russian terrorists beyond their wildest dreams. The hacks kept coming over the summer. The Kl0p gang even laughed, because as commentators talked about the situation on the news, nobody seemed to realize that the solution was pretty simple: track down the users of the so\ufb05ware and make them patch it.<\/p>\n\n\n\n

In General, Attentive Companies Can Protect Themselves<\/strong>
It is important to note that few zero day hacks actually happen on the first day of the hack being discovered. That’s only true for some very unlucky organizations. From an underwriters perspective, there is a need to be certain that a broad variety of clients are covered, but for individual organizations, the problem can be greatly mitigated by simply engaging in the best practices of patch management.<\/p>\n\n\n\n

Patch management is the process of updating software, and it usually is not as critical as it is when a zero day is making the rounds, but it is always important. It can be largely automated, of course. Done properly, patch management could stop more than 90% of these problems. Future articles will describe the patch management process in greater detail.<\/p>\n\n\n\n

Because patch management is a form of preventative maintenance, many organizations have a great deal of trouble making it a priority without an external stakeholder to lean on them about it.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

The Problem is a Lack of Infrastructure<\/strong>
Had MOVEit been a drug, there would have been a system of pharmacies, distributors and the FDA to coordinate a recall. Had MOVEit been a food product, the FDA, USDA and states would have sprung into action. Had MOVEit been a car, the state DMV\u2019s along with auto dealerships and the DOT would have helped coordinate a recall. But MOVEit is so\ufb05ware, and unlike other products, there exists no system nor agency to coordinate a recall. Additionally, insurers have done nothing to establish any private sector e\ufb00ort to \ufb01nd and address so\ufb05ware or other third party products that may be producing a systemic loss.<\/p>\n\n\n\n

In order to properly respond to these kind of events in the future, insurance companies need to start ahead of time by planning on how they will address a zero day emergency, such as what happened with MOVEit. Because only a small number of victims are attacked on the very \ufb01rst day, the overwhelming amount of damage that a so\ufb05ware based third party attack can cause can, in fact, be avoided. Doing so, however, requires a fast moving plan of action, because under these circumstances, every moment counts.<\/p>\n\n\n\n

In fact, what needs to be done is very straight forward. Insurers must start by getting an inventory of their insured\u2019s IT assets. An IT asset inventory is the \ufb01rst step in any kind of planning for a zero day emergency. This will help determine which clients have the so\ufb05ware in question. However, it is still necessary to provide notice to all, because there are circumstances where a product may not have been updated to the inventory. There are also times when technology can be used to scan systems looking for the vulnerable so\ufb05ware.<\/p>\n\n\n\n

In many cases, this can itself be automated. Automated patch management systems do exist and many companies already use them. It is, however, important to verify that such systems are in place and test them regularly. In all cases, it is a best practice for human veri\ufb01cation of the corrective action to be used in the highest risk circumstances<\/p>\n\n\n\n

Once it is determined who uses the so\ufb05ware in question, it is simply a matter of assuring they are noti\ufb01ed and that action is taken, either to patch the so\ufb05ware or to uninstall or disable it until a safer version is available. If companies already have a procedure in place to do so, this is a piece of cake, but as with anything else, it is not possible to do a good job when it is necessary to ad hoc a solution together at the last minute.<\/p>\n\n\n\n

One reason it is important that the process move quickly is that with more exposure comes more risk that a system may have become compromised, even if it has not been detected. Therefore, as time goes on, the necessity of examining systems that were exposed for a signi\ufb01cant period of time arises, making the entire process that much more costly and di\ufb03cult.<\/p>\n\n\n\n

Beyond the urgent zero day emergencies, having outreach to policyholders and assuring they are keeping their so\ufb05ware up to date is a good move to reduce risk in general. As a general rule, keeping so\ufb05ware up to date is a good way of reducing a broad number of risks, so doing so automatically and checking in with policyholders on this important issue has excellent ROI.<\/p>\n\n\n\n

Further Mitigation:<\/strong>
As mentioned, organizations that were proactive in their patch management were likely to avoid all losses in the MOVEit attack, and others similar to it. Any organization that took it upon themselves to engage in the best practices for patch management was likely to have had no problems with MOVEit, but it was still possible to be hit within the first day or two. Thankfully, there is a great deal more that can be done to mitigate the risks of a zero day, such as MOVEit occurring at a given organization.<\/p>\n\n\n\n

The problem is few organizations go all out to protect themselves. However, those that do can and should be qualified as the lowest risk. Listed are some additional controls, which, if in place, will further mitigate the risk of a zero day allowing unauthorized access.<\/p>\n\n\n\n

<\/p>\n\n\n\n