The digitalization and growing interconnection of industrial environments (OT) requires a rethinking of the supervision of connected equipment and communication networks.
IT – OT convergence has driven the use of powerful and modern technologies in industrial systems. It has also brought a culture of cyber protection, one of the components of which is vulnerability management. Thus, it is today accepted, even imposed by standards, to have to know your OT equipment fleet in detail, with firmware versions, to relate them to known vulnerabilities via semi-permanent interrogation with the CERTs databases, and to organize update campaigns or deployment of security patches accordingly. This approach has many drawbacks.
The pitfalls of security in OT environments
- The first, well-identified, disadvantage is that unlike an IT park that is permanently administered, the OT system can only be subject to changes at certain times, under the risk of impact of unavailability and loss of production; and that these systems having been tested under very specific conditions and configurations, the risk of functional regression requires that the fixes be tested beforehand on a representative third-party platform.
- The second disadvantage is also known: obsolete equipment cannot be corrected. They must be isolated in a protected area, and respond to persistent vulnerabilities (a few hundred for Windows XP) with zoning and perimeter protection.
This is also the answer for another fairly common configuration: that of machines which come with their own, opaque IS, little – or not – managed from a cyber point of view. Rights management is, for example, specific to the machine and cannot be delegated to an AD of the IS OT.
Only the machine manufacturer can work on the software, otherwise the contractual maintenance conditions no longer apply.
OT CISOs have no choice but to segment the workshops concerned, and to put pressure on the manufacturers; pressure always lower than operating and production requirements. - The third disadvantage is that this process, assuming that an industrial entity agrees to put it in place with adequate resources, is too slow. It was already there before the era of AI: we considered that two update campaigns per year were sufficient, which means that we agreed to live with our vulnerabilities. However, the time between the publication of a vulnerability and its exploit is now in days, even hours: which threatens IT infrastructures, but reinforces for OT that the posture is not to patch at all costs, but to live with one’s vulnerabilities.
Very real specificities
First, we must admit that inventory accuracy, which is a cyber-only demand, may not be so crucial. Yes there is shadow OT, yes it can be used to attack the system. But not necessarily less than other equipment. When the ingress firewall is subject to 5 to 10 severe vulnerabilities per month, it is not said that it is a less risky attack vector than a forgotten XP server which manages the coffee machine. The mantra “you only protect what you know” loses its relevance if protection is essentially linked to architecture, as presented above for obsolete equipment and machines. After all, Vauban’s fortifications do not depend on construction within protected areas.
Then, we have to live with three types of vulnerabilities: those that are known and old, those that are new, and those that we do not yet know. Vulnerability management only concerns the first two. The cyber emergency criterion clashes with functional necessity; on the other hand, assuming that old and new vulnerabilities are managed very well, everything is called into question with those that will arrive tomorrow.
Finally, since we have to live with our vulnerabilities, is knowledge of them necessary? Yes, but…. What an industrialist looks at are not theoretical risks, as indicated by EBIOS type scenarios: they are real risks. Going from published vulnerabilities to real risks, apart from the fact that they do not concern future vulnerabilities, including 0-days, requires weighting the score with the exposure, the configuration of the vulnerable service (for example a web service on a non-deployed automaton), the business impact. This is a considerable amount of work, unless you have previously integrated cyber into a business risk analysis, … and not cyber.
What about the solutions to consider?
As with the physical protection of sites, there is a two-step reaction: the automation of initial security upon detection of an attack, then a thoughtful and human action to remove doubt and take action on a proven attack. There are now products available to detect intrusion and suspicious behavior. We should not expect these alerts to be exact, but likely. This is what site perimeter protection systems do.
Detection is a suspicion which must trigger a security action, therefore improving the posture, typically by removing or reconfiguring access routes to the industrial system. All industrial systems have functional survivability when they are autonomous, which IT infrastructures generally are not. This is also why manufacturers want on-premises systems rather than cloud.
See and know what’s happening
Industrial systems are vulnerable, and will remain so, and no product can present an exhaustive picture over time. Attack surface minimization is obviously necessary, but by definition it concerns what is exposed, and inbound and outbound communications.
Security comes from a real observability platform, capable of detecting and qualifying suspected attacks, by behavior, by pattern, in connection with Threat Intelligence analyses, which provide real-time analysis of threats; and that this platform, by itself or coupled with other systems, provides automatic, immediate security; then raises the alert with sufficient indicators to allow precise analysis, removal of doubt, and appropriate actions. Reflection is no longer a reflex, since the latter is activated with the observability platform which is on site. The functional survival of the industrial system allows us to take the time for analysis.
Even with this new type of product, it is useful to know your fleet, and to know its vulnerabilities. The very architecture of the OT system, defense in depth, and the capture points of the observability platform take this data into account. But, with the exception of certain campaigns targeting exposed equipment, it is not necessary to see its vulnerabilities as the main axis for organizing the defense. A zero-day is only revealed during its exploit, and only an excellent observability platform can enable an effective defense.
