Traditionally, hardware-based systems were isolated from security violations. But as network access proliferates throughout nuclear organization, the underlying benefits versus risks may not be obvious. Unprecedented access to the core systems, a vast majority of which are implemented in software, must be managed through new set of security controls and policies.
Regulations such as those defined by North American Electric Reliability Corporation (NERC) are relevant to the nuclear industry. NERC’s Critical Infrastructure Protection regulations are aimed at power suppliers and power generation and transmission operators, who are required to show compliance with all the provisions of NERC pertaining to cyber security.
Vulnerabilities introduced during software delivery processes can arise from a lack of oversight in cyber security evaluation and requirements, leading to poor software integration and overall system vulnerability. Regulatory compliance, reliability protections, and data loss prevention provide a strong business case for enforcing strict cyber security policies. The U.S. Nuclear Regulatory Commission (NRC) provides a framework to help identify those digital assets that must be protected from cyber attacks. The identified digital assets are referred to as critical digital assets (CDAs). Within Title 10 of the Code of Federal Regulations, 10CFR73.54, titled, "Protection of Digital Computer and Communications Systems and Networks" it requires, in part, that U.S. commercial nuclear plants provide high assurance that digital computer and communications systems and networks are adequately protected against cyber attacks. (See Resources.)
Architecting for security
Nuclear operators acquire software from multiple sources; collectively these may be vulnerable to cyber attacks. Also, in trying to satisfy the aforementioned NRC security requirements, project teams, who are inundated with multiple operational and control requirements, often omit or misinterpret security specifications.
Furthermore, commercial off-the-shelf, or open source applications are customarily used in complex systems affiliated with large IT and network systems. Nuclear organizations frequently use software service providers and independent software vendors for developing and integrating the final system. Among the many benefits of outsourcing, lower total cost, larger pool of available experts, and shorter time to market are the obvious ones. However, despite a diverse number of teams involved in software assembly, there are no safety regulations imposed on independent software vendors, commercial off-the-shelf, or open source components used in the delivered system.
It is vital to include cyber security assessment as part of a systems analysis and architecture prior to building, integrating, and delivering the system. Applications slated for use in a nuclear plant should make use of a secure software development life cycle, which will help ensure faster customer acceptance and optimum return on investment.
According to the NRC’s Regulatory Guide 5.71, products are to be free from known, testable vulnerabilities and malicious code through eliminating, among many things, "use of undocumented code or malicious functions that might allow either unauthorized access or use of the system, or the system to behave beyond the system requirements."
Managing the requirement for security
After system specifications are captured, it is vital to interlace these with security requirements from sources such as the NRC Regulatory Guide 5.71. Consequently, the resulting requirements document will not only contain user specification, but also regulatory content pertaining to security. Thus, layering different sets of requirements prior to breaking them down into modules for downstream implementation creates an overall set of system-wide requirements, which are inclusive of security specifications.
Figure 1. Requirements in modular form, side-by-side with model-generated source code.
As illustrated in Figure 1, the left column contains numerous requirements modules, such as infusion parameters, pump channel, and software architecture, where each module may contain security requirements from the aforementioned NRC or NERC sources. In many cases, specific requirements are divided as objects so that they can be easily be addressed based on their object identifier. Figure 1 shows the requirements modules and the underlying objects, side-by-side, with implementation modules realized in either model form, source code, or commercial off-the-shelf modules. Each requirement object may be traced to a Unified Modeling Language (UML) model element, but must definitely be traced to the final source code. This arrangement creates navigability, which becomes vital for security compliance. Navigability between architectural elements, safety specifications, design elements, or security requirements, in addition to their underlying implementation, is achieved.
Requirements traceability and compliance
If traceability exists bi-directionally, that is each requirements module and its underlying requirements objects are mapped to a design or implementation artifact, these links can be easily traversed in both directions.
As shown in Figure 2, overall user requirements are traced to design, implementation, or to both. For example, if a UML design element is mapped to a certain requirement, this linkage can be traversed in both directions, creating a bi-directional traceability. From a security perspective, requirements on the left in Figure 2 can be traced in the forward direction to the corresponding design or source code implementation. Additionally, design or source code is linked backwards to the requirement objects.
Figure 2. Requirements traceability and impact analysis are achieved reliably using tool automation.
Of course, bi-directional traceability is best accomplished through the use of a requirements management (RM) tool, which is also frequently integrated with design and source code development environment, thus creating an automated collaboration solution. Exploiting the integration of IBM Rational® DOORS with UML modeling tools, Rational Rhapsody, and Rational Software Architect, created a fully automated RM-driven application and system delivery environment. These tools are a part of the larger Rational Jazz platform, which is aimed at distributed product delivery teams working in a collaborative environment.
Another major benefit of using collaborative environment becomes obvious during debugging and testing, where design and source code implementations are frequently changed. Such changes may inadvertently violate previously fulfilled security requirement. Worse, many violations may stay undetected in the finally delivered system. In order to prevent this threat, an impact analysis (IA) feature proves valuable; IA can identify the requirements that are affected by design and source code changes and identify the affected requirements. This feature becomes a useful aspect of a change management system. For example, changes can be validated or rejected, depending on their impact on the underlying requirements, security specific, or otherwise. In Figure 2 the dashed lines illustrate IA, as a complement of requirements traceability. This arrangement is fairly immune to changes made during final delivery when the system is being integrated and tested.
Cyber security standards and traceability
In accordance with NRC Regulatory Guide 5.71, systems are classified based on their criticality. CDAs that are critical to safety and security functions and if compromised would adversely impact the safety of the overall system, are allocated to Cyber Security Defensive Level 4, as shown in Figure 3.
Figure 3. Overview of cyber security defensive architecture, from NRC Regulatory Guide 5.71, overlaid with corresponding traceability.
Level 4 CDAs are protected from all lower levels, as shown in bold, white arrows in Figure 3. Per Regulatory Guide 5.71, only one-way data flow is allowed from Level 4 to Level 3 and from Level 3 to Level 2. Data only flows from one level to other levels through "devices" that enforce security policy between each level. The overall defensive architecture has the responsibility of "detecting, preventing, delaying, mitigating, and recovering from cyber attacks." Another guideline recommends elimination of all applications, services, and protocols that are not necessary to support the design-basis function of the contained CDAs.
To enforce the scheme described in Figure 3, tactical use of traceability is used to automate the compliance process. By compartmentalizing the requirements corresponding to each CDA level, into modules 0-4, data flow between levels is studied through traceability links. In other words, CDAs in level 4 requirement modules that are coupled with level 3 CDAs through traceability should only show data flow in one direction, illustrated by a "flow direction" attribute.
CDAs, specifically, their underlying requirements, which remain untraced to other requirements, exhibit the first symptom of an "orphan" object and may be candidates for elimination. Commonly, many unnecessary system components are not only captured as requirements, but are further elaborated into system's architecture, design, and eventually, source code. An audit, identifying these dangling, or orphan requirements, not only identifies the requirements, but also the traced design and source code components that may pose a security risk in the deployed system. This type of validation is in line with the 5.71 recommendation, to remove unnecessary system components that do not contribute to design-basis function.
Validating cyber security requirements
From a validation perspective, the final review process greatly benefits from tabulated traceability reports created by the RM tool. While both RM and modeling tools automate the process of linking requirements to the underlying implementation, missed or incomplete requirements are not easily identified through traceability alone.
Figure 4. A tabular or matrix view can quickly identify gaps and create new traceability links
In Figure 4, use cases arranged in columns, depict design and implementation phases of the final system. When arranged against a set of cyber security requirements, which are represented horizontally, a few key conclusions are easily drawn:
- Multiply linked security requirements: in this case, requirement SR-56, is mapped to multiple use cases, "Capture Usage Data," and "Configure Route". As such, this requirement will be applied and tested against both these use cases and any changes in the implementation of either use case will impact this requirement.
- Many security requirements, for example, SR-37, SR-44, SR-46, and few others, are not implemented in any of the three use cases; this may be a result of requirements slippage, which implies that the final implemented system may have missed these slipped security requirements. If true, this may render the system non-compliant. The report may prompt an action plan to remedy this situation.
After use cases in Figure 4 are corrected and implement the slipped security requirements, the latter can be linked to the corresponding use cases by simply clicking the mouse on the appropriate table cell, easily creating a traceability link; another benefit of automation provided by RM tools.
Security has multiple dimensions
The most logical place to start implementing security is in the evolving software slated for delivery. Developing a business process to include NERC and NRC requirements at many key stages of a nuclear plant's operations is essential for creating a security-conscious culture. It is also beneficial to engage security professionals to help design and develop a customized vulnerability action plan applicable to the security standards that are observed internationally. From a security perspective, it is vital for a power company to incorporate safety measures into the following elements:
- The various model, source code, and executable software components comprising the final system
- The collaborative development and integration process practiced in-house and by the extended teams
- The enterprise structure through review and re-engineering the enterprise architecture and the business process
Implementing security involves all stages of the product delivery process. Beginning with requirements gathering, security requirements should be managed alongside other requirements, to be eventually delivered as software-based product. In order to preserve fidelity between the delivered system and the overall requirements, traceability becomes a key feature to help eliminate requirements slip and inadequate requirements coverage. Slippage caused by source code or design change during system integration and testing can become a major source of non-compliance. Requirements management (RM) tools provide automated impact analysis capability, to avoid slipped requirements and aid in creating a secure system. In addition to enforcing cyber security through RM, an effective security program hinges on a solid collaboration process during product development and delivery efforts. Finally, business processes and workflows, along with the underlying organizational structure play a major role in realizing effective cyber security.
- U.S. NRC 73.54 Protection of digital computer and communication systems and networks: Read the full regulation.
- Office of Nuclear Regulatory Research, Regulatory Guide 5.71, Cyber security programs for nuclear facilities: PDF version of the entire guide.
- NERC website: Learn more about the North American Electric Reliability Corporation.
- A nuclear energy renaissance: How software is changing the nuclear industry: Check out Irv's blog post in the developerWorks community.
- Best practices in delivering a smart grid solution: This paper positions model-driven development as vital to application integration and development in energy and utilities.
- Collaborative Application Lifecycle Management with IBM Rational Products: This IBM Redbooks publication, gives a blueprint for Collaborative Application Lifecycle Management (CALM) and shows how Rational products support this market.
- Rational Business Driven Development for Compliance: This IBM Redbooks publication is intended to help you design your processes and solutions using Rational products to manage compliance.
- IBM energy and utilities software: Learn more about IBM solutions for this industry.
- developerWorks Rational: Explore IBM Rational resources for developers.
- developerWorks on Twitter: Join today to follow developerWorks tweets.
- developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
Get products and technologies
- Evaluation software: Download a trial version, work with product in an online, sandbox environment, or access it in the cloud. Rational Software Architect and Rational Rhapsody Developer are two examples of what's available.
- developerWorks profile: Create your profile today and set up a watchlist.
- developerWorks community: Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.