This is the third in a series of pieces on the recently released FERC summary of the results of their 2018 CIP audits. The earlier pieces are here:
- The introductory piece about why that document was worthy of your attention
- Automated inventory and why it’s the cornerstone of a strong security assurance program
6. Consider the remote configuration of applicable Cyber Assets via a TCP/IP-toRS232 Bridge during vulnerability assessments.
Very few topics in the history of CIP standard development have generated more fire and fury than the boundaries around what, if any, portion of the standards should apply to assets which are serially connected to assets which, themselves, are fully IP-connected and addressable from at least some portion of an operational network. Note that these serially-connected assets are a subset of the whole group of assets which aren’t externally routably connected; assets which aren’t connected at all to anything present a different risk profile and are a subject for another day.
At the core of this conflict are two basic truths:
- Many of the controls described in the CIP corpus make no sense in the context of serially-connected assets, even those which are addressable through tactics such as port mapping on the devices to which they’re connected.
- These assets wouldn’t have the serial connections if you didn’t want to communicate with them or at least hear from them in some way, and in the extremely general sense, communication paths always represent weak spots in your overall security and should be managed accordingly.
These truths are currently addressed by the compromises present in scoping for non-ERC assets in version 5 and later of the standards, and there doesn’t appear to be any strong will on either side to adjust the current boundaries. However, those boundaries create an oddball situation where many utilities avoid doing some configuration control on their serially-connected assets because they’re afraid that the communication paths needed to update configurations will introduce ERC and exacerbate their compliance risk. This lack of configuration management is what FERC appears to be attempting to remedy with the new lessons learned guidance.
For assets without direct remote addressability, the most common way to be able to remotely access them is to open a session of some kind to the terminal server or other device which serves as the IP boundary in the path to the serial device and then utilize local functionality on that gateway device to manually create a session to the end serial device and perform configuration tasks. While this typically is a valid means of performing a single asset configuration, knowing which assets require the updates, how many of them you have, where they are located and tracking the execution is a significant challenge in most OT environments.
However, one truism of most communication devices is that almost anything which can be done fully manually can be captured and then re-created by session simulation software, given sufficient expertise. If prior to executing such an exercise we had granular details about our asset fleet (including operational criticality to direct priority and, possibly, special handling, if required) we could indeed be extremely efficient and targeted in our efforts. Indeed, one of the major tasks that’s generally performed during installation and setup of the Verve software platform is identifying both end point specific data (firmware, serial number, OS, etc.) and operational or contextual data (asset owner, asset criticality, location, redundancy, etc.). This, in turn, allows for both an empirical measurement of scope and effort and for strategic planning (by criticality, location, unit, etc.) so as to best suit the organization and its risk tolerance. Finally, the real time update of the system parameters means tracking progress is near instantaneous and is verified by the assets themselves.
It’s also worth noting that, while FERC staff don’t address this extended topic in the report, this programmed communication ability also opens the possibility of remote configuration monitoring for serially-connected assets, something which can provide a big win in reducing risk exposure at the point where the hardware is most closely tied to actual operational components. One of the reasons given for opposing extension of the standards further for these serially-connected assets is that there are many classes of attacks on those assets which “could never happen”. This argument always seems to be based on assumptions about the capabilities of the devices, but it also seems to be based on assumptions about the capabilities of the attackers in many cases, and that’s extremely dangerous. Assuming that you are smarter than your adversaries is reassuring, but it can leave you exposed. In the end, though, especially outside the scope of compliance reach, it just makes sense to monitor for conditions that you believe are impossible, because if one of them ever occurs, you really want to know about it in a hurry.
Once you’ve established these bidirectional capabilities to be able to push and pull configurations without extending your ERC boundaries, it’s simply a matter of integration to be able to incorporate these efforts into your enterprise (for whatever operational scope you’ve defined for the enterprise) systems for event monitoring, patch maintenance and installation and incident response. In the end, whatever the compliance scope, reaching the point where your OT assets are managed in well-understood ways is a good way to boost confidence, even if you know there are some differences under the hood in how it gets done.