Q&A with Rick Kaun: Managing OT Regulatory Requirements

In our recent webinar, Managing Prescriptive and Auditable Regulations in OT Environment, VP Solutions Rick Kaun addressed how easy it is to become overwhelmed by the challenges of new cyber security requirements and shared how to successfully adapt to these changes to become more secure and achieve effective compliance.

The overall objective is typically to apply common IT security controls into OT environments, but it’s easier said than done. While most IT security professionals expect IT tools to easily transfer into OT, they quickly find they’re ill-suited for OT due to the sensitivity of these systems. Therefore, they find themselves facing significant gaps in coverage and scratching their heads on how to reduce risk.

In this Q&A, Rick answers nine questions from our webinar audience about their concerns around preparing for unseen audits, applying OT-safe remediation tactics, and how Verve managed regulatory requirements.

Q: What assets are considered OT, or in the case of NERC CIP, what constitutes a cyber system?

It has been about 13 years since I sat on a drafting committee for NERC CIP guideline creation so am not the expert.  However, I do know that CIP 002 has a host of clarifications and definitions as well as supporting documentation for exactly how to assess the assets at a site (i.e., those that could impact/take a system offline in 15 minutes or less) or those that would negate the ability for a site to act as a number of safety functions (like load shedding, black start, etc), but the guidelines also have thresholds for whether the site itself is even in scope for High, Medium or Low impact and therefore different levels of security need such as generation capacity.

Q: What is the best way to manage and prepare for unforeseen audits?

The most powerful way to manage and prepare for unforeseen audits is to have a real-time feedback loop from your OT assets into a central reporting dashboard.  Verve’s Think Global: Act Local architecture provides this type of view for regulated and corporate (audit) standards alike.

With less cyber security personnel on the OT side, managing the operations and maintenance on a day-to-day basis becomes another challenge. Leveraging a central team that can view the entire asset fleet (and associated threats and vulnerabilities) allows for the blending of IT and OT. With this contextual analysis, they can together build a remediation plan that remains consistent across the organization and adheres to the needs of both functions.

Q: How do new regulations such as TSA apply to OT environments?

Specific regulations apply based on several requirements.  For certain industries (like TSA regulation for US-based pipelines or NERC CIP for North American power) these are externally developed and prescribed to the operating companies. Both regulations have specific language to help the operating company determine what assets are applicable and what controls are required. Other guidelines are written specifically for OT but the application of them is up to the operating company (i.e., you may want to adopt inventory, vulnerability, and patch requirements but not practice incident response drills until you are more mature). Read more on managing OT regulations here.

Q: What is meant by “automating endpoint actions without causing OT risk”?

The challenge to managing and reducing risk in OT is the need to automate within certain asset classes to maximize efficiency balanced against real OT constraints like asset fragility, inability to reboot or go offline, and a wide range of different OS versions. To overcome those challenges, we need to approach OT security with an eye toward automating as many of the repetitive tasks as is safe for OT while stopping short of taking actions that might cause disruption.

In the use case we shared in the webinar, we talked about identifying 146 systems in scope for a software removal task. The action to remove the software was automated, but only allowed the action to take place once an OT staff member was in place physically at the console in scope. The OT staff managed the action within the expected operational confines of change management and communication for that specific site.  This way, much of the process was automated but stopped when it meant the asset itself needed a possibly challenging adjustment (reboot after uninstall).  It is this blend of automation but with an OT-safe mindset that propels clients towards significant security maturity and minimal cost.

Q: What are the best standards to implement for IoT to base an audit on?

Any audit can be built against any OT standard you wish (NIST CSF, CIS 18, IEC62443, NIS, etc.) but the challenge is in defining what is required of a specific control (i.e., vulnerability management – is the requirement to identify risk or to reduce it?).

The second challenge is how to allow for and track exceptions. If you have a logging requirement of networking equipment for intrusion detection but legacy OT equipment do not all support logs, how do you track that and build it into the future budget and refresh cycles?

Q: What is the best way to keep OT machines patched and in compliance without affecting productivity? What is Verve’s process for validating and testing patches before deploying them?

The Verve Security Center platform improves our customers’ existing patch process in a number of ways: Identify a wide range of in-scope patches (OS-based, application-based, etc.) and filter this view into specific operational context (like the subset that is approved by a specific OEM vendor). Identify target testing systems (like redundant Domain Controllers) for testing specific patches before deploying to a wider or more mission-critical set of assets.  All patch deployment actions can also be automated or staged to include on-the-ground OT involvement if desired. Read more about effective patch management here.

Q: What is your top recommendation for IT professionals to *conscientiously* integrate with OT environments, specifically in the realm of soft skills and receptivity to industry culture. And vice versa. (Local watering holes don’t count!)

The most compelling way for IT to ingratiate themselves with OT is to walk many miles in their shoes.  Go to OT conferences, (ICS JWG is a US government-free instance – runs twice a year, Public Safety Canada is the same but once per year), ask to tag along on an operational shift (if possible) – or be part of a multi-disciplinary team (if that is an option).  One refinery superintendent I know lobbied for the local IT staff to report to him not corporate. The five people (two IT at the site plus three OT support engineers – whose responsibilities included managing the data historian, OEM backups, etc.) all worked together and started task sharing and cross-training.  It is slow and cumbersome but effective.

Q: How are FDA regulations handled in food and beverage manufacturing?

FDA regulations are usually focused on testing the host or core function of a system to determine if it is negatively impacted by a new practice, technology, or tool.  When we work with an FDA-regulated client, we support the standard FDA process (different for different classes of assets) whereby we install our software, run various health and stability tests, run actions (like system hardening) and again certify the base image/function of the host.  We document our testing and then move on to deploy our technology more widely across the environment.

Q: Can Verve help map company-led requirements to regulatory requirements (especially if we operate in multiple jurisdictions/areas), so we can see the dependencies?

Yes – our platform gathers all raw data that is typically used to support regulatory status.  Changing the view or filters of the specific data for one standard versus another is quite simple and is wholly dependent on what data the standard wants to see – i.e., raw patch data of all assets for high-level compliance versus patches filtered by OEM approval or by security review process (NERC CIP) are just variations on the same data.