Too Many Changes, Too Much Noise


Most industrial companies with whom I speak are aware of the amount of control system changes that occur on a daily basis, but lack the proper automation to monitor and manage those changes. This means that significant changes can go uninvestigated, which means unplanned outage, safety, and other risk increases. 

Major regulations and standards, including NERC-CIP, IEC 62443, NEI 08-09, and NIST 800-53, to name a few, mandate that organizations “develop, document, and maintain” security configuration baselines. For power companies, not complying with these standards can result in monetary fines. All industries risk reputational loss should an incident occur and become public.
 
Baselining is not just for compliance. Baselines help isolate focus onto the subset of objects/properties whose changes have security implications. This helps reduce the risk of cyber incidents originating from malicious internal or external actors, as well as from inadvertent engineering changes. 
 

Baselines, and Benchmarks, and Policies – Oh My!

I have noticed that the term baseline is used sometimes when the term benchmark is really more appropriate. It is important to gain alignment on what a baseline is and what it is not. Baselines are operational “snapshots” of asset configurations at a discrete point in time.  Baselines are taken on an ongoing basis, and deviations from one baseline to another are investigated. Baselining is an invaluable exercise to isolate and manage critical security changes (baseline deviations or variances). Archived baselines help operational and cybersecurity personnel to see what is “normal” for a given asset, which is important during change reviews and cybersecurity incident investigations.
 
Attempting to develop, document, and manage baselines manually is a non-starter. It is costly and error-prone, especially given dozens of disparate vendor systems comprising hundreds or thousands of industrial endpoints across a process control network (PCN). Just knowing what assets exist is enough of a challenge. And even if an asset inventory exists in a spreadsheet, knowing what the current configuration is and tracking changes to that configuration is extremely difficult, if not impossible, to maintain manually.
 
Baselines are not benchmarks. While baselining is used to narrow focus onto those security objects/properties that matter and to review detected deviation, baselining does not identify what state or setting any given configuration object/property should be. Benchmarks are used for that. Benchmarks define desired state or settings for specific configuration objects/properties. Leveraging benchmarks, policies are used to identify benchmark exceptions.  When policies identify these exceptions, there is usually some type of notification or alert for asset owners to investigate and re-align the configuration to the approved benchmark.
 

Industrial Control System (ICS) Configuration Baselines  

So, given that baselining helps mitigate compliance, safety, and reliability risk as well as improve efficiency, why aren’t they in more common use across PCNs? There are two reasons that I see. First, determining what configuration objects/properties to include requires deep subject matter expertise and takes a great deal of time. Second, accessing production-centric ICS endpoint configurations (i.e., Distributed Control Systems, Safety Instrumented Systems, Advanced Programmable Controllers, Programmable Logic Controllers, Turbine Controllers, Vibration Monitors, SCADA systems, etc.) is problematic at best and often not even possible.
 
This is where ICS configuration baselines come in. An ICS configuration baseline solution must go beyond identifying changes on IT-centric assets, such as operator consoles, HMIs, configuration stations, network devices, firewalls, etc. That is relatively easy, and there are no shortage of IT-centric baselining solutions on the market today to do that. Sure, every baselining solution needs to provide this – I call it basic IT-centric baselining. But it can’t stop here. Comprehensive ICS configuration baselining enables insight into the proprietary production-centric ICS endpoints across the entire PCN – the level 0 and level 1 industrial endpoints, not just the traditional IT-centric endpoints at levels 2 and 3. Without a holistic view of everything from level 0 up, the PCN is vulnerable to improperly configured or potentially compromised industrial endpoints. 
 
Are your baselines covering all your cyber assets or just the IT-centric ones?


Share this post


Comments

Comments
Blog post currently doesn't have any comments.