Delicately stated - most individuals working in both business and IT domains are quite well aware of the concept of risks, and OT operators are more aware of direct (potentially life taking) risks/impacts to operations. But at the end of the day, risk is a shared endeavor across both business/IT and operations/OT. Both have their challenges, and both have differing requirements to arrive at resolution or reduction through a balanced approach.
Regrettably, this balance though is even harder to achieve due to cyber security marketing factors, and as stated by the CISA director Chris Krebs: "vendors need to stop spreading Fear-Uncertainty-and-Doubt (FUD) to asset owners", or this concept of a slick hacker enveloped within a hoodie issuing mass destruction at the whims of a keyboard. And perhaps there is some truth that armies of dedicated and mischievous individuals with a desire to disrupt your OT organization exist, but if we take stock in how (generally) engineers have built these facilities - there is a certain amount of risk reduction and assurances for the truly dangerous processes.
And in the spirit of technological evolution and the advent of easy connectivity, the risk landscape in many traditional and “manual” or analog environments has been transformed by the adoption of commodity technology that makes our lives easier. Evolution or not, it's not an insurmountable challenge to secure these “optimized” environments or address new risks in retrospect, but the option of risk mitigation by way of replacement is not always a solution to balance risk equations. This is true particularly in OT environments, and even in IT environments (government or private), legacy systems exist and can't be necessarily "ripped and replaced" because:
- It is not cost effective to upgrade the solution
- No solution exists (e.g. home grown)
- Legacy commodity OS systems have been virtualized due to tomb-stoning
- It is what it is
So to reduce risk in those sorts of scenarios and return harmony (balance) to an organization’s security program, we need to protect against the common cyber security vectors and most likely to occur types of events/incidents at a minimum. Therefore, we should engineer a solution based on consequences (Think INL’s CCE) that improve our chances as defenders/administrators to:
- Improve access control to systems, networks, accounts and devices
- Improve on the odds we detect on a change in behavior
- Improve our accounting and process for maintaining a list of assets that is prioritized on criticality
- Recover quickly from a disruption
- Perform preventative activities (e.g. patching and hardening)
Now by acknowledging the high level of identifying and managing vulnerabilities that may be exploitable in those systems (either by a technologically enabled vector or abetted by a human), we need to look at managing exposure. Indeed, vulnerability and risks both need to be managed, but one cannot do so without looking at the actual exposure of those vulnerabilities. This is the fragile game of balance - risk, cost, reduction, and vulnerability/exposure.
So let's look at this term - exposure and define it.
Exposure is almost synonymous with mitigating or compensating controls to reduce the overall risk of a threat occurring, potentially the impacts, and also the shielding of a system with vulnerabilities. And this shielding is like blackout curtains blocking sunlight - a window is a hole in an external (perimeter) structure that allows sunlight to penetrate into the room separated from the outside, when we the owner (operator) wants.
Now we control the curtains, and if the window was to be used for air flow or entry. Obviously there would be some additional threats to consider: unauthorized access, prevention of internal error (child falling through), reduction of ideal environment conditions (temperature etc), gaps in monitoring (sensor/alarm is disabled if open) and so on...
Again, those are simple things to manage, and IT or OT systems can overlapping controls, which has been proven over and over by those who specializes in those environments, but - the question of looking at the overall surface, how do I reduce the risk of exposure? Clearly in our window example, those threats and the inherent vulnerabilities of a traditional window are amplified if you are a basement/ground level suite, vs. the second or third story in some respects.
Furthermore, if we look at RDP vulnerabilities such as Bluekeep, it looks absolutely terrifying on the surface. High CVSS scores, easy exploitation, and "wormable". Fortunately, if you add in other compensating controls such as protect direct access, host hardening (NLA), limiting any RDP sessions to those that originate from a hardened jumpbox, use VPNs, have monitoring, and multiple layers of firewalls - then this vulnerability isn't so extreme.
And if logic follows, then the presence of a vulnerability does not necessarily equate to it being exploitable nor actually an asset being vulnerable at all. This is especially true with Bluekeep (and some of the other RDP vulnerabilities) IF Network Layer Authentication (NLA) is on, or the RDP service is disabled altogether - then effectively, a system that has a vulnerability might not be vulnerable at all because of limited exposure or conditions that render it moot.
Then this circles us back to the original statement eloquently articulated by Mr. Krebs - how do we create actionable security that actually secures systems without selling needless equipment or solutions through fear? The honest answer is quite simple. By actually examining vulnerabilities, having a detailed asset catalog, and by leveraging heuristics that show indicators of best practices while looking at validated system information demonstrating actual locations of a system (with compensating controls), we can then arrive at something reasonable and not FUD driven, using actual exposure.
While it's a bit early to announce what I've been working on, exposure is definitely a conversation the ICS/critical infrastructure community needs to have. Asset owners are becoming aware (kudos to the community for that), but it means that accountability and responsibility for selling concrete solutions falls upon the vendor (as it should). Asset owners are also becoming frustrated by unsubstantiated product claims towards security and need solutions that help them solve problems today! And ultimately, this is why I think responsible cyber security is key in industry as a whole, and why I do what I do.
Over the next month or so, I'll be publishing a series of articles, and Verve will have a feature expose of this new concept that I believe will be of great help to our community. For more information, either reach out to me directly, comment, or ping us at email@example.com for solution related questions.