Beyond Mogura Taiji Security

This article has been adapted verbatim from a paper accepted and presented during INCOSE IS 2026 titled ‘Beyond Mogura Taiji Security’ authored by Mona Humes, Mark Winstead and myself.

Abstract

Organizations typically achieve cybersecurity compliance for nuclear and other critical infrastructure through established control-based guidance documents such as NIST SP 800-53, NIST SP 800-82, ISO 27001, and IEC 63096. This paper presents an engineering-driven methodology that leverages the INCOSE Guide to Security Needs and Requirements (GtSNR) and the trustworthy secure concepts and principles defined in NIST SP 800-160 Volume 1 Revision 1 to derive security needs and requirements for critical systems (CS) and critical digital assets (CDA). The resulting requirements are realized through security-informed architecture, design, and implementation, and the resulting engineered security capability might be later mapped to controls to represent and assess that capability for governance and compliance purposes, when needed. By applying systems security engineering (SSE) as defined in NIST SP 800-160 Vol 1 Rev 1 and INCOSE GtSNR selectively to systems and assets of highest consequence, the proposed approach supports incremental adoption, reduces implementation burden, and enhances alignment between systems engineering and security practices.

Although initially developed with the nuclear sector in mind, the methodology applies to other complex, safety-critical, and cyber-physical systems.

This paper serves as the foundational entry in a dedicated series on systems security specifically tailored to help executive leadership and senior decision-makers navigate the current landscape of information overload. It provides the strategic “kick-start” necessary to move beyond reactive compliance toward building inherently secure and resilient (inherently secure, for short) systems, setting the stage for subsequent works that will provide the practical roadmaps, templates, and measurable metrics for the enterprise.

Introduction

An overwhelming number of papers, standards, frameworks, guides, and research outputs addressing security or compliance from every conceivable angle to confront executives, senior leaders, and other decision makers. While this knowledge may be valuable and, if so, represents a tremendous collective achievement, the unintended consequence is information overload. Expecting executive leadership to remain deeply aware of, and fluent in, this vast and evolving corpus is unrealistic.

This paper argues that significant security gains can be achieved if leadership clearly understands and aligns on two foundational points. From the authors’ perspective, achieving consensus on these points represents a major step in the right direction, both strategically and operationally, for improving security posture across complex cyber-physical systems, which is particularly necessary as the industry transitions toward increasing complexity and IT/OT convergence such as the advent of new designs for Advanced and Small Modular Reactors (A/SMRs).

The following sections first present the two foundational points for executives and leaders to acknowledge, then examine the limitations of relying on NIST SP 800-53, NIST SP 800-82, or other control catalogs and control implementation guidance in complex OT and nuclear environments. The paper then introduces a practical, integrated approach that uses the Systems Security Engineering principles articulated in NIST SP 800-160 Volume 1 Revision 1 and INCOSE Guide GtSNR. We present this approach as a four-step process: identifying CS and CDAs, deriving security needs and requirements, mapping and customizing controls (optional), and verifying and sustaining security throughout the lifecycle. The paper concludes with recommendations and next steps for future work.

Foundational Points

First, while controls catalogs and implementation guidance remain potentially useful in certain contexts, executives must understand their limitations. Controls catalogs and implementation guidance are typically prescriptive and naturally focus on controls. They do not ensure that security is engineered holistically across a system’s lifecycle, nor do they address system-specific, emergent, or mission-driven security needs—particularly in complex cyber-physical systems. Relying on control compliance will leave critical gaps unaddressed while adding unnecessary controls that may increase cost and schedule and may diminish performance and reliability.

Second, likely not every asset will be protected to the greatest extent possible due to resources limitations. Instead, consider those elements whose compromise would have the greatest impact on safety or mission. This requires more than controls catalogs and implementation guidance can provide.

Recent research on advanced nuclear systems strengthens these points. Adam Williams in (Williams, 2025) conceptualizes security as functional perseverance, achieved through two engines: Vigilance (requirements, V&V, situational awareness) and Resilience (preparation, defense, and recovery). Embedding these principles early and continuously across lifecycle phases supports achieving inherently secure systems and reduces reliance on costly retrofits which are unlikely to completely close security and resilience deficits.

Limitations of Control-Based Guidance

Control based guidance such as NIST SP 800-53 and NIST SP 800-82 provide security controls for federal information systems and industrial control systems, respectively, addressing areas such as risk management, access control, monitoring, and incident response. However, the increasing digitalization of nuclear instrumentation and control systems introduces complex vulnerabilities that require added domain-specific analysis beyond general cybersecurity frameworks. Studies have highlighted the unique security challenges associated with digital nuclear control systems and the need for tailored risk assessment approaches to address safety-critical threats (Arinze et al., 2020; Ayodeji et al., 2023; Song et al., 2013; U.S. Nuclear Regulatory Commission, 2023).

Despite adherence to guidance such as that from NIST, nuclear facilities are still exposed to persistent and increasingly sophisticated cyberspace-based threats targeting industrial control systems. Adversaries employ advanced techniques including social engineering, artificial intelligence, firmware manipulation, and exploitation of supply chain vulnerabilities to compromise cyber-physical systems. The rapid evolution of these threats can challenge static frameworks and create protection gaps. Real-world incidents such as the TRITON (HatMan) malware attack demonstrate the ability of attackers to manipulate firmware within safety instrumented systems, highlighting the risks posed by advanced cyber-physical attacks against critical infrastructure (Ayodeji et al., 2023; Cybersecurity and Infrastructure Security Agency, 2019; Di Pinto et al., 2018).

Moreover, insider threats and the need for specialized security training tailored to nuclear personnel are not comprehensively addressed. Similarly, supply chain security remains an underrepresented concern within current frameworks, despite guidance from IAEA NSS 42-G and DOE Supply Chain Principles emphasizing lifecycle security (Ayodeji et al., 2023; IAEA, 2021a; IAEA, 2021b).

Recent research further suggests that the principal limitation is not the absence of security controls but holistic systems engineering. Williams (Williams, 2025) argues that integrating security during system design can improve system resilience and reduce the need for costly retrofits required when security is considered later in the system lifecycle, especially after system design or realization.

From the authors’ perspective, the existing reliance on prescriptive frameworks has fostered a ‘containment-centric’ mindset. This accepted norm has seen security become an additive discipline: a series of protective architectural perimeters and controls appended after initial design, rather than an emergent quality property of the system itself. Under this model, the underlying cyber-physical system design is implicitly assumed to be trustworthy, relegating security to the establishment of external boundaries. When this foundational assumption proves false, organizations are trapped in a reactive, vulnerability-patching cycle—the very “Mogura Taiji” (the Japanese name for the “Whac-a-Mole” game) scenario modern engineering systems security engineering seeks to avoid.

The Proposed Approach

To move beyond the reactive cycle, we propose an integrated approach that:

• Applies NIST SP 800-160 Vol 1 (Ross et al., 2022) to embed security across the entire system lifecycle, by incorporating security principles and concepts into needs elicitation, requirements definition, architecture, implementation, operation, and sustainment activities.
• Uses INCOSE GtSNR to supplement NIST SP 800-160 Vol 1 in defining security needs and requirements early in the lifecycle, offering detailed guidance for eliciting, analyzing, and writing structured, testable requirements.
• When needed, represent the engineered security capability for governance and regulatory purposes by using control catalogs as references, mapping realized system security requirements, mechanisms, and assurance evidence to applicable controls while keeping a clear separation between systems security engineering and compliance reporting.

For nuclear environments, the approach can be contextualized using IAEA NSS 17-T Rev. 1 (International Atomic Energy Agency, 2021b) and NSS 33-T (International Atomic Energy Agency, 2021c), tailoring security architecture and technical measures to address the unique constraints of the nuclear environment, including the safety–security interface.

Substantiating such an approach is the SunRISE pilot (Ross & Tan, 2025). Through the pilot, the National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL) and NIST demonstrated that protecting mission-critical systems requires moving from a compliance-driven mindset toward a systems engineering approach grounded in the concepts and design principles of NIST SP 800-160. Ross and Tan emphasize treating security as an emergent property of the mission system and integrating security into the system life cycle rather than addressing it post-design through compliance activities. This approach highlights the advantages of incorporating security considerations early in system architecture and design. The pilot showed that applying the design principles during early development phases increases architectural visibility, enables more effective placement of needed security features, and contributes to improved system resilience.

While presented in a logical sequence, the following steps are executed iteratively, recursively, and concurrently. As the system evolves, information, analysis results, and assurance evidence flow across the steps, continuously refining system definition and strengthening confidence in its security.

First Step: Asset Identification

The approach can apply to all systems, subsystems and components within the project or organization; however, such an approach may be overwhelming and resource intensive. In such cases, this paper argues for a targeted and prioritized application to cyber-physical systems as a starting point. Apply the approach primarily to CS and CDA, those elements whose compromise would have the greatest impact on safety or mission. By limiting initial scope to what matters most, organizations can realize the approach’s benefits without excessive disruption, while making more effective use of limited engineering and security resources.

For nuclear projects, (U.S. Nuclear Regulatory Commission, 2023) offers detailed guidance on identifying critical systems and critical digital assets, which ensures comprehensive coverage of safety and security priorities. It serves as a powerful example for other sectors by establishing a clear regulatory expectation: the loss or impairment of a Safety, Security, or Emergency Preparedness (SSEP) function is an unacceptable loss. This allows organizations within the nuclear sector to effectively anchor their systems engineering activities around the preservation of these functions as an intrinsic part of delivering mission capability.

The identification journey begins with a comprehensive site-specific analysis aimed at mapping the facility’s CSs. These systems are defined by their association with four essential pillars: safety-related functions, security functions, emergency preparedness (including offsite communications), and any support equipment whose failure could degrade these primary functions. To ensure no vulnerability is overlooked, a consequence analysis is needed that evaluates the “worst-case” impact of a compromise while intentionally ignoring any existing mitigating measures.

Once the boundary of CSs is established, the focus narrows to the CDAs existing within them. A CDA is characterized as any digital subcomponent that performs a Safety, Security, and Emergency Preparedness (SSEP) function or provides a pathway that could be exploited to attack such functions. The identification process must emphasize that connectivity does not define criticality; the guide explicitly includes autonomous or “air-gapped” systems within its scope, recognizing that even standalone assets are susceptible to internal threats and malicious media introduced via “sneaker nets” (U.S. Nuclear Regulatory Commission, 2023).

To further refine resource allocation, the Graded Approach outlined in (International Atomic Energy Agency, 2021b) may be applied. While (U.S. Nuclear Regulatory Commission, 2023) identifies what is critical, the Graded Approach allows engineers to assign specific security levels and zones based on assessing the function’s worst-case consequences of compromise. This ensures that the most rigorous engineering activities are targeted towards preserving functions with the highest safety and security consequences, directly addressing the resource constraints.

Second Step: Needs and Formal Requirements

After the CSs and the CDAs are identified, NIST SP 800-160 Vol 1 and the INCOSE GtSNR are applied to define security-informed system behavior, objectives, and requirements prior to design realization.

NIST SP 800-160 Vol 1 establishes SSE as a disciplined, repeatable process integrated into the system lifecycle—from concept development through disposal. It calls for explicit activities such as defining security objectives, allocating security requirements to architecture elements, producing security views, planning verification and validation, and sustaining security through configuration management and monitoring.

The INCOSE GtSNR aids this by providing structured methods to elicit, analyze, and transform mission-driven protection needs into testable requirements early in the lifecycle. It emphasizes capturing stakeholder concerns, developing loss scenarios and misuse cases, capturing protection needs in objective language, and converting them into “shall” statements that are verifiable and traceable.

Key Actions in this step include, but not limited to:

• Identify stakeholder concerns for asset loss.
• Capture protection needs without design bias; maintain clarity and objectivity.
• Develop loss scenarios and misuse cases to identify failure modes and adversarial behaviors.
• Transform needs into security-informed, testable requirements and allocate them to architecture components.
• Apply security considerations, principles, and concepts to shape system architecture, ensuring security emerges as a property of the design rather than being addressed solely through controls and barriers.
• Plan verification and validation using analysis, inspection, demonstration, and test methods aligned with lifecycle phases.
• Establish bidirectional traceability from stakeholder needs → requirements → architecture/design → realized system elements and any derived control implementations (where applicable → V&V evidence.
• Assurance Evidence Generation and Organization: Produce and organize objective assurance evidence derived from protection needs and requirements definition activities. This evidence shows that security objectives are reflected rigorously in the captured needs and requirements and provides a defensible basis for stakeholder decision-making and any subsequent compliance representation.

By embedding SSE practices from the concept phase onward, organizations ensure that security requirements are systematically identified, modeled, and validated as primary drivers of system definition and design. This approach reduces costly redesigns, supports proactive risk management, and produces systems that are trustworthy, resilient, and verifiable throughout their lifecycle.

Third Step: Informed System Realization and Trustworthiness Demonstration

This step realizes the defined requirements, including those defined in the second step, and proves system trustworthiness through objective, lifecycle-derived evidence. Security is no longer treated as an abstract intent or planned capability; it is implemented, integrated, analyzed, and evaluated to confirm that the system behaves only as authorized and intended and adequately protects critical assets against loss.

Consistent with a systems security engineering approach, trustworthiness is demonstrated through evidence produced by standard engineering activities conducted across the system life cycle, including implementation, integration, analysis, verification, validation, and—in applicable cases—early operational use. Assurance is therefore an outcome of disciplined engineering execution, not a standalone activity. Activities in this step include, but not limited to:

• Security Informed System Realization and Integration: Implement and integrate system elements per the defined architecture and requirements. Security is realized as part of normal system construction and integration, allowing system behavior to be shown as components are composed.
• Verification of Security Requirements and Validation of Protection Needs: Perform verification activities to confirm that security requirements have been correctly implemented and validation activities to confirm that the system effectively protects critical assets and functions under realistic operational conditions, including those reflected in defined loss scenarios and misuse cases.
• Engineering Trade Space Evaluation and Decision Documentation: Capture and document engineering decisions and tradeoffs involving security, performance, cost, operability, and usability. This includes recording the rationale for accepted design choices, characterizing residual loss exposure, and supporting the determination of security adequacy.
• Assurance Evidence Generation and Organization: Produce and organize objective assurance evidence derived from realization, integration, verification, validation, and analysis activities. This evidence shows that security objectives have been met and provides a defensible basis for stakeholder decision-making and any subsequent compliance representation.

At the conclusion of this step, the system has been realized and evaluated, and a structured body of assurance evidence exists to support claims that the system is trustworthy and adequately secure with respect to defined assets, loss scenarios, and operational expectations. This evidence enables informed determinations of system acceptability and provides the engineering foundation for compliance representation in the next step.

Fourth Step: Compliance Representation

When necessary for governance, controls catalogs such as NIST SP 800-53 and SP 800-82 can be used as references for alignment—not as sources of requirements or design drivers. This step ensures that control-based representations accurately reflect the security capability engineered into the system, showing both satisfaction of applicable controls and coverage of other system-specific security requirements beyond those controls. Key Activities include:

• Coverage and Gap Analysis. Identify:
  • controls inherently satisfied by the system design,
  • controls requiring tailoring to reflect implementation, and
  • other system-specific requirements and safeguards that extend beyond control catalog coverage, ensuring projects fully address mission-driven protection needs.
• Operational and Management Expectations Captured: Any procedures and assumptions of use captured into engineering artifacts are mapped to any applicable operational or management controls.
• Compliance Artifact Development: Produce structured artifacts that faithfully represent the engineered system and its assurance evidence in a form suitable for regulatory and organizational use.

The resulting system not only satisfies applicable customized NIST control sets but also addresses other mission- and system-specific security requirements beyond those controls, providing a more complete and defensible security posture.

Sustaining Security Beyond Project Delivery

Once security capability has been engineered, realized, verified, validated, and represented through compliance artifacts, long-term effectiveness depends on how organizations govern and sustain security beyond individual system or project delivery.

To further strengthen long-term sustainability, the computer security program governance model within IAEA NSS 42-G (International Atomic Energy Agency, 2021a) may be adopted to manage computer security within an integrated management system rather than through individual project delivery. This governance model provides the organizational structure necessary to maintain security objectives, manage configuration and change, oversee ongoing assurance activities, and ensure continued alignment with regulatory and operational expectations throughout the system’s operational life.

Considerations while Applying the Proposed Approach

When To Engage Systems Security (Including Cybersecurity) And Systems Engineering Stakeholders

As INCOSE Needs and Requirements Manual (Wheatcraft et al., 2024) explained, engaging the right stakeholders at the right time is critical to defining, validating, and sustaining effective systems across their lifecycle. Stakeholders are the primary source of needs, constraints, and requirements for the System of Interest (SOI). Failure to engage relevant can result in incomplete requirements, misaligned design decisions, and systems that fail validation, regulatory approval, or operational acceptance.

To apply the approach effectively, systems security engineering must be embedded into systems engineering, present in all systems engineering activity starting from the concept phase. This ensures that the critical systems security requirements are identified, mapped, and integrated into their components and architecture from the outset, aligning with NIST SP 800-160 Vol 1 guidance as supplemented by INCOSE GtSNR and addressing added context-specific needs.

Sustaining Stakeholder Engagement

Stakeholder identification and engagement are not one-time activities. As the SOI matures, new stakeholders may emerge, roles may evolve, and other needs and constraints may be identified. Continuous communication and engagement are necessary to support ongoing validation of requirements, architectures, and lifecycle artifacts.

Sustained collaboration between systems engineering and systems security stakeholders—across both IT and OT domains—enables early identification of conflicts, informed executive decision-making, and systems that achieve security objectives without compromising operational safety or mission performance.

IT Versus OT

Executives must recognize that securing Information Technology (IT) is fundamentally different from Operational Technology (OT). IT systems prioritize data confidentiality, availability, and rapid recovery, while OT systems are primarily concerned with availability, safety, reliability, determinism, and continuity of a cyber-physical function. Treating OT systems as extensions of enterprise IT, or assuming that IT-centric security solutions, designed for protecting data, naturally translate to OT, introduces operational risk and can undermine system safety. Because IT and OT systems have different missions, risk tolerances, and consequences of failure, one community alone cannot decide. Early engagement of all stakeholders enables leadership to make informed trade-off decisions that balance security protection with operational safety, reliability, regulatory compliance, and mission assurance. Leadership awareness of this distinction is essential for informed decision-making and proper governance.

Recommendations and Next Steps

Cybersecurity for nuclear and other critical infrastructure systems cannot rely on prescriptive control catalogs such as NIST SP 800-53, SP 800-82, and ISO 27001. While these control catalogs may be currently treated as essential for compliance, they do not inherently ensure secure design or address system-specific, mission-driven needs. The proposed approach integrates SSE concepts and principles from NIST SP 800-160 Vol 1 with the supplemental structured requirements process of GtSNR. By applying the approach early in the lifecycle and focusing on CS and CDA, organizations can embed security as an emergent property of the architecture rather than as an afterthought. This engineering-driven approach supports proactive risk management, reduces costly redesigns, and strengthens assurance that systems are trustworthy and resilient throughout their lifecycle.

Next Steps for Future Work

• Create a practical roadmap that includes templates for loss scenarios, protection needs, and traceability matrices.
• Explore how Systems Modeling Languages (SysML) security views and mission thread modeling can operationalize SSE and GtSNR guidance.
• Establish metrics and assurance cases. Define measurable indicators of security posture and develop structured confidence arguments for regulatory acceptance.
• Pilot and validate in real projects. Apply the methodology in a nuclear or critical infrastructure project to gather lessons learned and refine best practices.

References

• Arinze, U. C., Longe, O. B., & Eneh, A. H. (2020). Regulatory perspective on nuclear cybersecurity: The fundamental issues. International Journal of Nuclear Security, 6(1). https://doi.org/10.7290/ijns060103
• Ayodeji, A., Mohamed, M., Li, L., Di Buono, A., Pierce, I., & Ahmed, H. (2023). Cyber security in the nuclear industry: A closer look at digital control systems, networks and human factors. Progress in Nuclear Energy, 161. https://doi.org/10.1016/j.pnucene.2023.104738
• Cybersecurity and Infrastructure Security Agency. (2019). HatMan – Safety system targeted malware (Update B) (Malware Analysis Report MAR-17-352-01). U.S. Department of Homeland Security. https://www.cisa.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%20-%20Safety%20System%20Targeted%20Malware%20%28Update%20B%29.pdf
• Di Pinto, A., Dragoni, Y., & Carcano, A. (2018). TRITON: The first ICS cyberattack on safety instrumented systems—Understanding the malware, its communications and its OT payload. Black Hat USA.
• International Atomic Energy Agency. (2021a). Computer security for nuclear security (Nuclear Security Series No. 42‑G). IAEA.
• International Atomic Energy Agency. (2021b). Computer security techniques for nuclear facilities (Nuclear Security Series No. 17‑T, Rev. 1). IAEA.
• International Atomic Energy Agency. (2021c). Computer security of nuclear safety instrumentation and control systems (Nuclear Security Series No. 33‑T). IAEA.
• International Council on Systems Engineering. (2024). Guide to security needs and requirements. INCOSE-TP-2024-146.
• International Electrotechnical Commission. (2020). Nuclear power plants – Instrumentation, control and electrical power systems – Security controls (IEC 63096:2020).
• International Organization for Standardization. (2013). Information security, cybersecurity and privacy protection – Security techniques - Information security management systems - Requirements (ISO Standard No. 27001:2013). https://www.iso.org/standard/54534.html
• Joint Task Force. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5 Ross, R., & Tan, K. (2025). Protecting mission‑critical systems: The need for a shift in culture, strategy, and process. INSIGHT, 28(3), 15–22.
• Ross, R., M. Winstead, M., and McEvilley, M. (2022). Engineering trustworthy secure systems (NIST SP 800-160 Vol. 1 Rev. 1), National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-160v1r1.
• Seo, J., Abdel‑Khalik, H., Mertyurek, U., Arbanas, G., Marshall, W., & Wieselquist, W. (2023). Comparative analysis of standard and advanced USL methodologies for nuclear criticality safety. Nuclear Science and Engineering, 198(3), 673–701. https://doi.org/10.1080/00295639.2023.2211202
• Song, J., Lee, J., Park, G., Kwon, K., Lee, D., & Lee, C. (2013). An analysis of technical security control requirements for digital I&C systems in nuclear power plants. Nuclear Engineering and Technology, 45(5), 637–652. https://doi.org/10.5516/net.04.2012.091
• Stouffer, K., Pillitteri, V., Lightman, S., Abrams, M., & Hahn, A. (2015). Guide to industrial control systems (ICS) security (NIST SP 800-82 Rev. 2). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-82r2
• U.S. Nuclear Regulatory Commission. (2023, February 13). Cyber security programs for nuclear power reactors. Federal Register, 88(29), 9117–9127. https://www.govinfo.gov/content/pkg/FR-2023-02-13/pdf/2023-02941.pdf
• Williams, A. D. (2025). Helping Future Nuclear Power Facilities Navigate Predatory & Hostile Environments: Insights from Systems Security Engineering. INCOSE International Symposium, 35(1), 1306–1319. doi:10.1002/iis2.70111).
• Wheatcraft, L. S., Ryan, M. J., & Katz, T. E. (Eds.). (2024). INCOSE needs and requirements manual: Needs, requirements, verification, validation across the lifecycle. Wiley.