Collecting ports and services information in a control network is a tedious and manual task. Rarely do vendors provide guidelines for asset configuration rules leaving the asset owners to find the right configuration to ensure a balance of performance, reliability, and security. Due to the level of work it takes to configure assets, comprehensively managing ports and services often gets overlooked. Not because it isn’t important, but because it’s not absolutely critical to system performance. Understanding open ports and services is obviously a critical component of securing and maintaining automation systems environments in order to minimize system vulnerabilities. Ports and services auditing has also become a very prominent piece of critical infrastructure regulatory standards, such as NERC CIP and CFATS.
Free White Paper: Ports & Services Management for Control Systems
Most of the time what we see people do is just run a port scan using one of the widely available open source tools. These tools have been developed for the IT world, most only capable of being run locally, are risky, and generally difficult to configure in a control systems environment.
Industrial Defender has taken a different approach with Automation Systems Manager. We automatically retrieve ports and services information with our automated data collection models. So if your IT department advises of a Conficker outbreak on the corporate network you can quickly run a query against all the Windows systems with port 445/TCP listening to identify those at risk. With this information you can issue a ticket to have Windows patches (KB95864, 957097, and KB958687 in case you’re wondering) applied to the vulnerable systems.
To help control system professional understand the semantics of the standards and how to manage ports and services we have compiled a technical white paper which describes the requirements, processes and complexity in detail that can be downloaded here.
The plant security working group of the WIB International Instrument User’s Association (www.wib.nl) has published report “M 2784 X10″ entitled “Process Control Domain – Security Requirements for Vendors”. Shell was a driving force behind this standard available for download here (note: WIB permission is needed to redistribute). Shell is starting to require their vendors to certify against M-2784 and Wurldtech is putting the first batch of vendors through the certification program now.
I just got back from the Digital Bond SCADA Security Scientific Symposium (S4) where I presented on whitelisting.
Whitelisting is the “hot new” host intrusion prevention system (HIPS) technology that some tout as the end of the anti-virus (AV) era. Anti-virus of course works by producing a “black list” of virus signatures. If data or a file matches a signature, the AV technology takes some sort of action to protect your system – anything from a popup alert to blocking execution and quarantining or removing the offending file. Whitelisting application control takes the opposite approach – application control technology has a “white list” of signatures of allowed executables. Any time you try to run a program or OCX or DLL, that executable’s signature is recalculated and compared to what the approved signature for that program is. Unapproved software or software that’s been tampered with is triggers an action – anything from a popup alert to blocking execution.