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.)
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."
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.
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.
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.
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.
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
website: Learn more about the North American Electric Reliability
- A nuclear energy renaissance: How software is changing the nuclear
industry: Check out Irv's blog post in the developerWorks
- 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.
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.
energy and utilities software: Learn more about IBM solutions for
Rational: Explore IBM Rational resources for
Industries: Find more industry-specific technical resources for
- developerWorks on
Twitter: Join today to follow developerWorks tweets.
- developerWorks podcasts: Listen to interesting interviews and
discussions for software developers.
demos: Watch demos ranging from product installation and setup for
beginners to advanced functionality for experienced developers.
Get products and technologies
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
developerWorks profile: Create your profile today and set up a watchlist.
community: Connect with other developerWorks users while exploring
the developer-driven blogs, forums, groups, and wikis.
A systems engineer and software architect in multiple industries, Irv is the IBM Rational Go-To-Market Manager for Energy and Telecom industries. He is the co-author and co-chair of Telco Modeling Language (TelcoML) standard and chairs the Object Management Group's upcoming Smart Energy standard. He has written over fifty papers on systems and software architecture. Irv can be reached at firstname.lastname@example.org.