Obviously from the title you may think that cyber-security, and particularly in OT/ICS/critical infrastructure may be a bit of fear-mongering…. And you may be right based on the posturing of various attitudes or media sensationalism, but what if I told you… those legacy assets and zones that have zero CVEs or known vulnerabilities – should keep you awake as an asset owner. This is a sombre and realistic warning for assets that can be easily accessed short of physical tampering, and complete isolation. And again, this is not a call for you to spend atrocious amounts of your budget, it is about being on the watch and measuring risk vs. compensating controls.
Now please stay with me and let me explain CVEs as a simplified process: CVEs are a score based on a finding that has been publicly announced (ideally after a period of responsible disclosure) by the vendor and/or researching entity. Hypothetically/in practice, like many things with a free economy, it sounds like it should work as intended. Fine and dandy if it works, unfortunately...
CVE as a concept breaks in the following ways for a variety of reasons, and here lay some of the problem(s):
- Firstly, a flaw is subject to the classification used by the vendor to announce the nature of an issue. This means that many flaws whether in software, configuration, and particularly hardware, can be “smuggled” under the rug as merely a “bug” that can be fixed during a release and not openly called out as what they may actually be – a risk to an organization
- Secondly, the entity that owns the product or system that has such a flaw is subject to the rules of business and the flexibility of ethics/morality. Without turning this into a philosophical debate, let’s look at it objectively – rarely will an organization be transparent and immediate in discussing a vulnerability or incident as it unfolds (if they do at all)
- Thirdly, a CVE score does not translate well/directly to the actual risk or IMPACT an organization may face at all nor does it translate into a priority metric for remediation effectively. For critical infrastructure, and Operational Technology (OT)it is a challenge not to be discussed by this post; sorry (but stay tuned)!
Now if I’m to look at business motivations from an vendor’s perspective – it would appear that having little to no vulnerabilities would mean that my competitors are less secure than my products (apparently), but as a professional, and an asset owner – I’d argue that there must be a certain amount of “skeletons” buried there regardless; particularly where legacy and insecure by nature design decisions exist. Don’t worry – there are...
And surely, when I examined numerous product release notes – there is often a repeated theme illustrating comments such as bug fixes around X (e.g., network stack), or logic errors (e.g., race-condition fixed on Y state machine). Enthusiastically, I’d bet my bottom dollar those “fixes” are actually referring to one of those pesky cyber-security vulnerabilities I keep hearing about, and were deliberately kept quiet by X vendor or X vendor’s internal CERT did not even know because the product teams did not report it as such (the latter is an area we can all improve so no fingers directly pointed).
Yet, frequent releases vs. CVEs make the security (Eastern) front appear calm and serene.
So to circle back to the concept of CVEs, they are but one (1) metric to be used as a way to identify elements to be fixed, but not one that wholly identifies the risk I may be owning. For example, just as you or I may acknowledge the risk of a devious or disgruntled employee, I’d also be focusing on minimising downtime, risks to the business and balancing my budget IF I were a C-something, I’d look to two things:
- An obvious focus on IT-specific infrastructure and data security
- And where we haven’t spent money ensuring the SAFE-RELIABLE-OPERATION of equipment that actually generates the businesses’ revenue
The first point has probably been beaten to a pulp at this point (whether through breaches such as Desjardins or Capital One), but point two, we are just getting started… many organization’s are just beginning their journey into securing their operational environments that literally contribute economically, to the business, and play a critical role in our lives. So far (it seems), it has been a quiet war front – ranging from nation state events such as Stuxnet, Trisis, or the ransomware that has targeted (Maersk, Mondelez, and Norsk), but still – these had impacts, and should they have been exploited to dangerous proportions directly or by accident, we never would have known based on a merely CVE score; regardless if a CVE score was even published to begin with.
There needs to be more commentary during this war on who announces CVEs (if at all). There needs to not be X number of CNAs, Y number of CVEs, and there needs to be content that is humanly consumable for operators who know their process, their infrastructure and their business… they need to be able to see it in one centralized location, to monitor it, and comprehensively understand it with complete with REALISTIC risk profiles that REPRESENT criticality to the business, and also includes those pesky insecure by nature vulnerabilities (whatever they may be)… because… <some deity> help us… they exist and when all is foggy on the front, surprises happen and we need to manage those risks; especially when it comes to safety, and the environment.
Do I have an answer written in stone, and to be cast down as gospel? No, but – I present to you a solution that equates to:
- Noting and acknowledging that vulnerabilities exist outside of the CVE realm
- Score those vulnerabilities, and understanding what can be done to mitigate or reduce the risk/impact of their occurrence
- Implement compensating technologies, processes and monitoring of potential exploitation of those vulnerabilities
- Question vendors and integrators whom may be more silent than others (I’d actually bet that the more proactive an owner is, higher quality may result)
- Provide product features that aggregate CVEs, inherent by design vulnerabilities, and in-direct risks due to legacy conditions (e.g., End-of-Life) in one centralized location
- And result in enablement of Operators a way to comprehensively and accurately examine the conditions of their environment in a way they at than read/do something about X risk to ensure safe-reliable operations
To end this article, I’d like to equate OT to the war against my car’s tires like this:
Imagine that your perfectly functioning automobile is bombing down a well travelled road. Your car WILL eventually get one (or more) flat tire(s) on a SEEMINGLY NORMAL ROAD during its lifetime despite having pressure sensors and adequate maintenance. Just rather swell right? Not really!
If you don’t have the basics such as a jack and a spare, you will be in trouble, however, if you have a portable pump, or some new fangled spray/tire – you would have admitted to those risks and hoped a flat never occurred when you were driving. Don’t be that driver. Be aware, be cautious, and be afraid where appropriate because when all else is quiet or normal, use that time to:
- ASSESS – your environment for risks
- IMPLEMENT – control measures and procedures
- MONITOR – for risks that are obvious and otherwise
- PRACTICE – response and situational handling
Notice that I haven’t even talked about complementary threat intel or hunting yet? Until another time, Verve radio reporting in from somewhere in the world where brand-new tires go flat with little reason or the rubber gremlins get hungry – and solutions (to be outlined in my followup article) are required that enable action.
Comment below or reach out to email@example.com