If you believe cybersecurity in the operational technology (OT), industrial control systems (ICS) or critical infrastructure space is all doom and gloom, you’re not alone based on the posturing of various attitudes or media sensationalism.
Legacy assets and zones that have zero common vulnerabilities and exposures (CVEs) or known vulnerabilities should keep you awake as an asset owner. This is a realistic warning for assets that are easily accessed short of physical tampering and complete isolation. This is not a call for you to spend atrocious amounts of your budget on cybersecurity, but more-so about being aware of measuring risk vs. compensating controls.
CVEs are represented by a score which is based on a publicly announced finding (ideally after a period of responsible disclosure) by the vendor and/or researching entity. Like many things with a free economy, it sounds like it should work as intended.
3 Ways CVE Falls Short
- A flaw is subject to the classification used by the vendor to announce the nature of an issue. Many flaws, whether in software, configuration, and particularly hardware, can be “smuggled” under the rug as 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.
- The entity owning the product or system that has such a flaw is subject to the rules of business and the flexibility of ethics and 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.
- A CVE score does not translate directly to the actual risk or impact an organization faces, nor does it translate into a priority metric for remediation effectively. For critical infrastructure, and Operational Technology, it is a challenge to be discussed at a later date.
Looking at business motivations from a vendor’s perspective, it appears having little-to-no vulnerabilities means my competitors are less secure than my products. But as a cybersecurity professional and an asset owner, I’d argue there must be a certain amount of “skeletons” buried, particularly where legacy and insecure by nature design decisions exist.
Examining numerous product release notes, there is often a reoccurring theme illustrated in comments such as bug fixes (e.g., network stack), or logic errors (e.g., race-condition fixed on state machine). I’d bet those “fixes” are really referring to a pesky cybersecurity vulnerability and deliberately kept quiet by a vendor. Or a vendor’s internal CERT did not know about the vulnerability because it was not reported by the product teams. (This 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.
CVEs are one metric used to identify which elements to fix, but not one that wholly identifies the owned risk. For example, the risk of a devious or disgruntled employee and minimizing downtime are risks to the business.
Balancing two cybersecurity priorities:
- Focus on IT-specific infrastructure and data security
- Ensuring the safety and reliability of equipment that generates the businesses’ revenue
Focusing on IT-specific infrastructure and data security is already a popular topic, whether through data breaches such as Desjardins or Capital One.
Ensuring the safety and reliability of equipment that impacts the bottom line is a newer subject in the field. Many organizations are beginning their journey into securing operational environments that contribute economically, to the business, and play a critical role in our lives.
So far, 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. These events had significant impacts. If they were exploited to dangerous proportions directly or by accident, a CVE score would not have informed us of these threats.
Changes Should Be Made with CVEs
There is a need for more commentary on the announcement of common vulnerabilities and exposures. Consumable content for operators who know their process, their infrastructure and their business should be at the forefront.
Cybersecurity professionals need to view risks in one centralized location, monitor them, and comprehensively understand them with complete with realistic risk profiles that represent criticality to the business. It should also include those pesky insecure by nature vulnerabilities because they do exist and need to managed for safety in the OT environment.
Guidelines for Risk Management
- Note and acknowledge that vulnerabilities exist outside of the CVE realm
- Score vulnerabilities and understand what actions can be taken to mitigate or reduce the impact of their occurrence
- Implement compensating technologies, processes and monitoring of potential exploitation of those vulnerabilities
- Question vendors and integrators who are more silent than others – the more proactive an owner is, the higher quality results
- 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
- Enable operators to comprehensively and accurately examine the conditions of their environment to read or do something about each risk to ensure safe-reliable operations
Be aware and cautious during seemingly routine vulnerability releases. Always formulate a plan:
- ASSESS – your environment for risks
- IMPLEMENT – control measures and procedures
- MONITOR – for risks that are obvious and otherwise
- PRACTICE – response and situational handling