By now, you probably heard about the cascade of data breaches that occurred because of a zero-day vulnerability in the MOVEit file transfer application that was exploited by the Cl0p ransomware group. If not, here’s a few basics as of the time of this writing.
- In late May 2023, a vulnerability (CVE-2023-34362) in MOVEit was publicly disclosed by Progress Software, the owner of the application, and at the time was already known to be exploited in several environments.
- It is believed that Cl0p began actively exploiting this vulnerability around Memorial Day 2023.
- Over the next few weeks, second and third vulnerabilities were also found and disclosed. The third vulnerability was found after Progress partnered with a company to assess the application independently.
- Three more vulnerabilities were later discovered and disclosed. Two were scored as high severity, while the other was scored as critical.
- Progress has released several patches to address these vulnerabilities, however, this comes at the heels of data breaches across several businesses including Shell Oil and many financial services companies, government agencies such as the US Department of Energy, institutions like Johns Hopkins University and Johns Hopkins Healthcare Systems and many more. While many are US based, many international companies have also experienced breaches.
I think it would be naïve to think that the story is over when it comes to MOVEit. As you can tell from these points, more news continues to trickle out about these vulnerabilities and the damage created from them.
But the point of this blog isn’t to point fingers or just tell a story. Security incidents can happen anywhere, and what’s occurring here is not unique. It doesn’t even mean anyone necessarily did anything “wrong”. We will see more of these incidents in the future. It’s more important to look at this as an opportunity to make our own security and risk management posture better, so let’s talk about some takeaways and lessons.
Vulnerabilities Exist In Everything, Even If You Think It’s Secure
The initial vulnerability exploited by Cl0p in MOVEit was being tested as far back as July 2021, so it took nearly 2 years for this critical vulnerability to be taken advantage of. It was discovered in 2021, but once the application was built, it was there. Some might think that’s irresponsible, but everything has vulnerabilities, it’s just a matter of what degree and what can be done with it. In fact, if you are using an application, whether it’s a desktop app, or a SaaS product, or an app for your phone and it’s not getting security updates, that should be suspicious to you. Products need updates and fixes (not just software).
These products are built by people who make mistakes using tools that are imperfect. We learn over time better ways to make products. Sometimes new attack techniques are developed that make existing technology suddenly less secure. There is no perfect software just like there is no perfect anything. The important question is how we limit our security risks by exercising diligence.
By the way, I rewrote the ending to the Three Little Pigs. Turns out that even though the Pigs thought they had a really nice and secure brick house to protect themselves after the whole straw and sticks debacle, the Big Bad Wolf was a more sophisticated threat actor than once thought. He “borrowed” a bulldozer from a nearby construction site and knocked that brick house out in about 20 minutes. It was brutal. Maybe the Pigs should have built a moat. Or maybe they should have done more security testing. Speaking of which…
The Only Way To Understand Security Risk Is (Real) Testing
Tell me if you have seen this before. You go to Amazon to buy a product, and the product page brags about how secure it is. The most secure, in fact. Way more secure than the other products. Maybe they put a big number on the box about encryption or some other impressive language or graphics. Now that I think about it, I bet most technology products you would get on Amazon would make these kinds of claims. How are all these hacks happening when we have all of these “secure” hardware and software products available to us?
I already mentioned the fact that everything has its flaws, but it may not surprise you that claims about security can only be backed up by testing and documentation, and that documentation needs to go beyond generic advertising claims. One good example of proper documentation and transparency when it comes to security practices and testing is Microsoft Azure and the volumes they publish on their website regarding actions they take, certifications they receive, and other reasonable documentation (which is not flashy) describing everything they do to protect the systems they control. They also outline things their customers can do while using their products to protect them from security risks they can’t necessarily control. This doesn’t mean Azure is perfect, but Microsoft is demonstrating their diligence to securing their product.
If you manage an application, you must not only perform regular security testing but also have documentation outlining what your threat model is, including the types of assets you control and the actors who may seek to exploit them, the methodology your security testers took to evaluate vulnerabilities, as well as what was found and how it was addressed to deal with the risk. This process should be a consistent discipline in your organization and address the inevitable changes in technology and security over time. How can you be confident about how secure a product is if you don’t consistently test?
Getting back to the methodology, the approach you take for testing anything for security risks is entirely dependent on what it does and how complicated it is as well as what will produce actionable results. Anybody can create a “testing process”, but the approach for testing matters. If your efforts are too automated and limited, you may be checking off a box instead of finding real vulnerabilities like the kind that were exploited in these MOVEit breaches. You want your security team to discover the critical vulnerabilities before groups like Cl0p do.
To be clear, I don’t know what testing MOVEit had before the incident, but the fact that so many critical vulnerabilities were discovered in this application in such a short period of time suggests that it’s possible a different approach could have yielded different results.
Your 3rd Party Risks Are Your Risks
Every business puts the assets they care about in the trust of someone else. This is particularly true for the vendors and partners that have access to our data, provide us with software or technology services, or have close contact with the sensitive parts of our business.
You probably use many applications and tools to get your core work done. What are your vendors doing to make sure they are providing you with services that protect your assets rather than leaving you liable for significant risk? Can you measure your 3rd party risks of all your vendors effectively? If not, you really can’t say what your risk profile is. Every application you are putting sensitive data into offers a potential attacker a place to exploit a vulnerability and take your asset (not the asset of your vendor). You are the stakeholder who is at risk, so you owe it to yourself to have a good 3rd party risk management process with the right tool to make this process feasible for your team.
All of these huge organizations I mentioned earlier relied on MOVEit and Progress Software to help them achieve a goal, and now they are faced with significant consequences because of a vulnerability they didn’t create. I can’t say whose fault all of this is, and hindsight is 20/20. As I said before, maybe nobody did anything wrong. But if you want to minimize your risks from something like this happening, you have to do the right things to protect yourself, including scrutinizing your third party risks.
Good Security Is Layered and Multi-Faceted
There is reason to be optimistic and positive about security risk management overall, even with what happened with MOVEit. Yes, hundreds of organizations have been impacted, but not all the organizations using MOVEit were exploited. And some that were exploited didn’t have the internal impact from the incident as much as others. Why is this?
It’s because security is not about having perfect products but having good disciplines, including security solutions that are layered and support one another. Do a little Googling about MOVEit and you can see discussion forums from late May where, despite not being patches for some of the vulnerabilities at the time, security engineers and IT support people were discussing ways to mitigate the issue with some successes. They had a good incident response, which helped mitigate the potential consequences. This was an important layer of security.
This isn’t limited just to incident response but having other security tools in place that adhere to principles like zero-trust. We shouldn’t assume that everything is secure, even if we have done the right things. Systems break. Things don’t always work out as planned. That’s why we have backups and systems that support one another for the things we care about.
To recap, I think these are the key principles to take to account as a result of the MOVEit breaches
- Nothing is invulnerable. Don’t assume that anything is, even if you are doing everything right.
- The only way to figure out risk is to have real security testing of your systems.
- Your assets are your responsibility, which includes measuring third party risk, like the applications you purchase to get work done.
- Real security mitigates risk by layering solutions that support one another.
Want to learn more about proper security testing or how you can manage your third party risks? Check out this blog about how to approach securing your vendors when there is no “one size fits all” solution! Thanks for reading this blog and feel free to reach out using our Ask An Expert form if you want to have a chat!
