How to Use Static Analysis to Improve NERC Critical Infrastructure Protection Compliance

INTRODUCTION:

Securing connected industrial control systems (ICS) or Supervisory Control and Data Acquisition (SCADA) for use in the energy sector is a unique undertaking. The cyber security standards required for the North American power grid are defined by the North American Electric Reliability Corporation (NERC). These standards are overarching, system-wide and complex. Although these standards do not address software development processes in detail, they do define high level requirements with respect to custom software and malware prevention that vendors must comply with. Companies wishing to supply ICS or SCADA systems into this market also need to understand these requirements. This post discusses how static analysis applied within a secure software development lifecycle can reduce the cost and risk in developing devices for this market.

Related:

• Cyber Security – Configuration Change Management and Vulnerability Assessments (NERC CIP 010-2)
• Using Static Analysis To Improve IIoT Device Security
• A Four-Step Guide To Security Assurance For IoT Devices
• How Static Analysis Protects Critical Infrastructure from Cyber Threats

Device Security Challenges in the Electrical Energy Sector

North American Electric Reliability Corporation (NERC) is a “not-for-profit international regulatory authority whose mission is to assure the reliability and security of the bulk power system in North America.” Cyber security requirements are defined by a set of Critical Infrastructure Protection (CIP) standards (CIP-002 through CIP-014.) This list is very comprehensive and deals with large infrastructure systems and thus cover many aspects of security beyond the scope of this post. The standard that applies the most to developing software is CIP-010-2 “Configuration Change Management and Vulnerability Assessments.”

What does the standard say?

The NERC CIP-010-2 specifies the handling and configuration of software in medium and high impact BES (Bulk Electric System). These requirements aren’t specific to ICS or SCADA systems; however, they are clear that any operating system, open source and custom software be adequately protected from security vulnerabilities and malware. These requirements would trickle down into individual control systems requiring due diligence from OEMs and software vendors so that the ultimate customer, the manufacturer of the BES, satisfies a CIP vulnerability audit.

For example, a responsible entity (vendor or operator of the electrical system) is required to:

• Maintain a baseline configuration for operating systems, open source, commercial and custom software and associated patches [CIP-010-2 Table R1], which implies strict configuration management control over all parts of the system, including ICS and SCADA systems.
• Any changes to the baseline are fully documented, tested, and don’t violate security requirements already in place. This implies a test of the updated software in a realistic environment plus any additional testing to prevent the introduction of new vulnerabilities or malware.
• Monitor and detect any changes in the baseline every 35 days [CIP-010-2 Table R2].
• Perform a vulnerability assessment at least once every 15 months [CIP-010-2 Table R3]. This implies active security testing in a realistic setting, either in production or in a reasonable facsimile test environment.

What does this mean for software development of ICS and SCADA systems? First and foremost, configuration management needs to satisfy these high-level requirements. Since open source and commercial software (e.g. real time operating system) are common components of control systems, tight control over changes is needed. Secondly, a reasonable but concerted effort to remove and prevent malware and security vulnerabilities from the supplied software, including developing “custom” software plus any open source or commercial software used. Thirdly, an ongoing process of patching, testing and documenting software updates. Clearly, this implies good software development processes and procedures. So, what are some of the unique security challenges in ICS and SCADA systems?

Secure Device Challenges for ICS and SCADA Systems

ICS and SCADA devices are increasingly targeted by attackers, having traditionally poor built-in security, large deployments of legacy devices, increasing machine-to-machine connectivity over the Internet, and are being brought into the Internet of Things “fold.”

There are some unique challenges:

• ICS systems are hardware-limited in terms of processing capabilities for many modern security features, such as encryption, networks stacks, and built-in firewalls.
• They control critical infrastructure, which makes the possible outcomes of cyber-attacks much more serious. Consequently, NERC CIP compliance is critical for success in the energy marketplace.
• They have different communication protocols and standards than enterprise systems. Communication to enterprise systems is also required, complicating security, especially given device limitations.
• Various other factors, including extremely long product lifecycles and difficulty in updating firmware and hardware compared to other devices.

These additional challenges exacerbate the security challenge for development teams building connected ICS and SCADA systems.

Four Steps to Improve ICS and SCADA Security

Our previous posts on a four-step improvement process applies equally to ICS/SCADA with extra consideration for the challenges mentioned above. Incorporating the following four major steps into an embedded software-development process can improve security (and quality) for highly-connected devices. To avoid repetition, the four-step process, is illustrated in Figure 1 and summarized as follows:

1. Design with a security first philosophy,
2. Use and repeat system-wide threat assessments and analysis,
3. Leverage tools as much as possible,
4. Use advanced source and binary code analysis to ensure the quality and security of custom, open source and commercial third-party code. 

Figure 1: A four step process for improving ICS and SCADA security

The Role of Static Analysis Tools in Improving ICS and SCADA Security

Static analysis tools like GrammaTech’s CodeSonar provide critical support in the coding and integration phases of development. Ensuring continuous code quality, both in the development and maintenance phases, greatly reduces the costs and risks of security and quality issues in software. In particular, static analysis provides some of the following benefits:

• Continuous source-code quality and security assurance: As each new code block is written – file or function – it can be scanned by static analysis tools, detecting errors and vulnerabilities (and maintaining secure coding standards, discussed below) in the source before it enters the build system.
• Tainted data detection and analysis: Analysis of the data flows from sources (i.e. interfaces) to “sinks,” where data gets used in a program, is critical in detecting potential vulnerabilities from tainted data (containing potential exploit payloads). 
• Assessing the quality and security of open source and commercial third-party code: Most projects are not greenfield development and require the use of existing code within a company or from a third party. Performing testing and dynamic analysis on a large existing codebase is hugely time consuming and may exceed the limits on the budget and schedule. Static analysis is particularly suited to analyzing large codebases and providing meaningful errors and warnings that indicate both security and quality issues. CodeSonar’s binary analysis can analyze binary-only libraries and provide similar reports to source analysis when source is not available. In addition, binary analysis can work in a mixed source and binary mode to detect errors in the usage of external binary libraries from the source code. 
• Secure coding standard enforcement: Static analysis tools analyze source syntax and can be used to enforce coding standards. Various code security guidelines are available such as SEI CERT C and Microsoft’s Secure Coding Guidelines. 
• Documentation and configuration management support: Report generation is a valued by-product of the source and binary analysis. Advanced static analysis tools integrate with configuration, build and documentation systems. Updates and patches can be audited for security vulnerabilities with reports included in configuration documentation.

As part of a complete tools suite, static analysis provides key capabilities that other tools cannot. The payback for adopting static analysis is the early detection of errors and vulnerabilities that traditional testing tools may miss. This helps ensure a high level of quality and security on an on-going basis during development and the ever more important maintenance phase of security, safety and quality patches and upgrades.

CONCLUSION:

Building ICS and SCADA systems destined for the energy sector require increased due diligence and disciplined, secure, software development. Vendors need to make sure their products meet the requirements of their customers building the next generation electrical grid.

Following a security-first development approach that includes the use of state of the art tools is recommended. Advanced static analysis of both source and binaries plays a key role in a security-first development toolset. Developers receive further benefits leveraging these tools to assist vulnerability assessments, malware prevention and configuration management required in order to satisfy NERC cyber security requirements.

 Interested in learning more? Read our guide on 

How Static Analysis Protects Critical Infrastructure from Cyber Threats

{{cta(‘3f15d992-4ede-4359-a609-14f613cb416c’)}}