Not Another Software Supply Chain Attack - Unfortunately Yes
Another day, another breach, this time via a vulnerability in an application called MOVEit, and sadly, as you will undoubtably be aware, three huge UK brand names in the frontline of Cyber Security news again.?For anyone worried check out the patch link and advice on the NCSC web site here:
According to US Gov advisory sources the exploit became active on or around May 27th.?Progress, the authors of the MOVEit Transfer application released advisory warnings to their community on May 31st and ?NVD, on the 7th June, published CVE – 2023-34362 with a ?9.0 Critical rating, all within a week.
The exploit resulted in the payroll and personal details of employees being stolen and some of these details are being published on the dark web to leverage the related extortion demands.
So what does this mean for me:
Well, it did get me thinking that the speed at which all of this happened means SOC teams, Threat Analysts, Responders, Developers and anyone responsible for Software Security would have been left gasping and struggling to deal with the situation, especially since they already have their hands full with other, also critical issues and their day jobs.
OK in this instance, it is fairly easy to work out if you have the MOVEit application, but what if you have integrated other third-party code in your own applications, or open source libraries. ?If there is a problem, how do you find it and remediate the situation, even more so how, do you even know you have the problem and how do you prioritise your efforts.?My mind is drawn back to Solarwinds and if we want to go further back in the supply chain, Log4J, CodeCov and GitBleed (all pretty nasty issues in their own special way).
I then got thinking, actually it doesn’t just apply to the code written for homegrown applications, it also concerns any code produced that is open to external third party usage (this one is on you) and furthermore how do you know you can trust code that is licensed from third parties including SaaS providers and Open Source.?It is now getting very complex.
Imagine a large manufacturing organisation with hundreds, if not thousands, of supply chain partners, a significant number of these will be supplying code or applications for integration, so how do you manage the security assurance in these situations.?How do you make sure the software you are embedding or integrating is as safe and rigorously tested as you yourself expect.
Proactivity and Collaboration:
A proactive approach is required to assuring software security and this applies to in house facing processes and also the collaborative testing of inbound software components.?Yes, this will require a closer bi-directional security relationship with your suppliers, but surely that would be to everybody’s advantage.
Visualise for understanding:
领英推荐
The first step must be to have a wholistic view of all of the steps in your Software Supply Chain, from code to cloud and the risks therein.?Currently organisations use a vast number of tools to gain this visibility, but the resulting views are siloed, difficult to manage and lack context that a singular view can give.?One integrated picture is paramount to being able to understand your risks.
Speed of action with the benefit of Context
Secondly organisations need a super rapid way to analyse the risks present and then prioritise remediation effort based on the business context not just the technical severity of the vulnerability.? Again, in the case of MOVEit this is pretty clear, if you are using it, patch it now.?However, if you have other risks which look critical but aren’t exposed, or reachable, or dormant and not deployed then the CVE score is irrelevant to you as an organisation.?Sure, you should deal with it and remove the vulnerability, but you may want to deal with other more dangerous and pressing issues first.
Continuous Assurance
Thirdly and perhaps most importantly this approach of visualising, contextualising, prioritising and remediating should be a recurring and continuous process that assures your software supply chain security continually and not a reactive one, when one of your favourite high street brands gets hit.
If you would like to explore this approach in more detail, please DM me for a meeting and demo of the Ox Security Platform, designed to ensure safety in your software supply chain.
?
WWW.ox.security
VP BizDev @ YouCC Technologies LTD.
1 年Great Article Adrian. The fact that one type of attack has happened, as significant as it may be, should help us understand that today it might happened in one process and tomorrow it could happen in another process or business app. It's not one hole in the bucket and you have to prepare for a variety of holes that can affect any business and put its reputation in jeopardy.
Rapidly transforming green screen systems into modern agile technology assets for Insurers, Banks, Retailers and Manufacturers
1 年Great article Adrian, it certainly has provoked me to consider fire drilling our response process, we have steps and they are well documented, but making time an element of the fire drill is an important dimension, when we think back to school days, fire drills were always timed exercises, so it really fits. We'll certainly move to a more pit lane tire change approach. Some good points about evaluating the security of your code base chain, we were already a 9001 and 27001 company but we also adopted ISO5055 last year, which has a security vulnerability focus, we also added automated red team into our tool chain and delivery cycle, but your points about being a beacon in your ecosystem of co-creators is well made.