Embedding Cybersecurity into the Engineering Lifecycle 

Model-Based Design introduces a structured methodology where system models become the authoritative artifact for design, analysis, and validation. Instead of treating cybersecurity as an external activity, it becomes an inherent part of engineered systems. With tools such as MATLAB and Simulink, engineers can build architectural models that not only describe system functionality but also capture security-relevant elements such as assets, threats, and vulnerabilities. This creates a unified environment where design decisions and cybersecurity risks evolve together. The advantage is clear: cybersecurity is no longer an afterthought, but a continuously evolving dimension of the system. 

From Assets to Threats: Building the Foundation of Cybersecurity Analysis 

Every cybersecurity strategy begins with a simple but critical question: what needs to be protected? In a model-based framework, the answer is derived directly from the system architecture. Assets can include components, communication interfaces, or data flows that are essential for system operation. By marking these assets in the model, engineers ensure that security analysis remains tightly coupled with the system design. Once assets are identified, the next step is systematic threat modeling. Established methodologies such as STRIDE help categorize potential attack vectors, while publicly available threat libraries like MITRE ATT&CK or CAPEC provide real-world context for refining those threats. In aerospace and defense contexts, this also means accounting for sophisticated, state-level adversaries and the complex supply chains that characterize long-lifecycle programs. 

A practical nuance worth addressing here concerns how STRIDE relates to the CIA triad the three foundational security properties of Confidentiality, Integrity, and Availability that most standards use as their primary impact model. STRIDE covers a broader set of security properties, including Authenticity, Non-repudiation, and Authorization, which do not map directly onto CIA. Rather than forcing every STRIDE category into one of the three CIA properties, a more effective approach uses a hybrid structure: CIA as the primary impact classification framework, with the extended STRIDE-related properties retained as additional supporting attributes. This preserves the simplicity and auditability of CIA while capturing the full analytical depth that STRIDE provides. 

When using threat libraries such as MITRE ATT&CK to refine identified threats, the volume of potential techniques can be significant. ATT&CK Tactics which describe the attacker’s high-level objective, such as initial access, persistence, lateral movement, or impact can serve as a useful intermediate layer to guide selection. Rather than attempting exhaustive coverage, the goal is to identify the most risk-significant techniques for the specific system, avoiding redundancy where multiple techniques represent the same attacker objective. This structured approach transforms cybersecurity from a brainstorming exercise into a repeatable engineering process. The outcome is a comprehensive mapping between system assets and the threats that target them forming the basis for all subsequent analysis. 

Quantifying Risk: From Qualitative Concerns to Measurable Metrics 

Identifying threats is only the beginning. The real challenge lies in understanding which risks matter most. In Model-Based Design, risk analysis is performed by evaluating two fundamental dimensions: impact and feasibility. Impact reflects the potential consequences of a successful attack, while feasibility measures how easily that attack could be exploited a distinction that separates theoretical threats from operationally significant ones. In the TARA (Threat Analysis and Risk Assessment) context, vulnerability identification,  is not simply a “hacking-style” activity: it is a structured assessment of whether identified threat scenarios are technically feasible, validating assumptions made during analysis and surfacing weaknesses that require mitigation through security controls or design changes. Defining impact requires a clear categorization framework. While Safety, Financial, Operational, and Privacy are common starting points, a complete model for aerospace and defense systems should also include Reputation and Legal as distinct impact dimensions both of which carry significant weight in contractual and regulatory environments. 

What makes this approach particularly powerful is its ability to reuse existing engineering knowledge. Safety analyses such as Failure Mode and Effects Analysis (FMEA) or Functional Hazard Analysis (FHA) can be directly incorporated into cybersecurity assessments, creating a bridge between safety and security disciplines. A critical point in risk quantification is avoiding binary “major / not major” classifications based solely on CIA or STRIDE category scores. High or Very High scores in these categories should be treated as indicators that a threat warrants deeper investigation not as final verdicts. A threat can be classified as major when a risk-based prioritisation method such as DREAD, CVSS, or PASTA also rates it as High or Very High. Medium-rated threats should not be dismissed outright if they affect multiple categories, critical assets, or mission-critical functions. Importantly, when multiple threats receive equal risk scores, additional context determines priority: safety impact, mission criticality, irreversibility of consequences, ease of exploitation, attack surface exposure, and the availability of detection and response capabilities all serve as meaningful tie-breakers. The threshold for what constitutes a “major” threat should always be defined relative to the specific system’s architecture, operational context, and regulatory environment  not applied as a universal rule. Using MATLAB and Simulink, these evaluations can be partially automated, enabling engineers to calculate risk scores, define acceptance thresholds, and identify the most critical vulnerabilities within the system. The result is not just a list of concerns, but a prioritized set of risks with clearly defined mitigation strategies. 

Designing and Validating Countermeasures Through Simulation 

Once risks are understood, the next step is mitigation. In traditional workflows, this often involves implementing security features and testing them late in development. Model-Based Design, however, enables a fundamentally different approach. By integrating countermeasures into the system model, engineers can simulate both attacks and defenses in a virtual environment. For example, an intrusion detection mechanism can be implemented within the model and tested against simulated attack scenarios to evaluate its effectiveness. This simulation-driven validation provides insights that are difficult to achieve through static analysis alone. Engineers can observe how attacks propagate through the system, assess how countermeasures respond, and quantify how much risk remains after mitigation. The concept of residual risk now gains particular importance here. Rather than assuming that a system can be made completely secure, engineers aim to reduce risks to acceptable levels while continuously validating their decisions. 

Continuous Cybersecurity in a Changing System Landscape 

One of the defining challenges of cybersecurity is that it is never static. Systems evolve, features are added, and new threats emerge. A one-time analysis is simply not sufficient. Model-Based Design addresses this by enabling continuous cybersecurity risk management. As changes are made to the system model, the associated risk analysis can be automatically updated. This ensures that security assessments remain consistent with the current state of the system. Equally important is the ability to generate comprehensive reports that document the entire process from asset identification to risk evaluation and countermeasure validation. These reports are essential not only for internal development but also for compliance with industry standards such as ISO/SAE 21434, IEC 62443, DO-356, and frameworks including NIST 800-53 and NIST 800-171. These standards establish different levels of rigour, definitions and other subtle variations in their analyses that can be taken into account in Model-Based Design, allowing engineers to customize their efforts while keeping the necessary traceability for auditing. In this way, cybersecurity becomes a living process rather than a static deliverable. 

Working on Aerospace & Defense or other safety-critical systems?

 Qyntar, SciEngineer’s cybersecurity practice, applies a technical adversarial perspective to complex system architectures uncovering attack paths across IT, OT, and embedded environments using model-based analytical methods. Qyntar supports compliance with NIST 800-53, NIST 800-171, NATO and EU cybersecurity frameworks, and DO-356, from the earliest design stages through audit readiness. Explore Qyntar’s defense & aerospace services → 

Why Model-Based Cybersecurity Matters for Modern Engineering 

The shift toward connected, software-driven systems has fundamentally changed the nature of engineering. Security breaches are no longer isolated incidents they can have wide-ranging impacts on safety, operations, and business continuity. This convergence of security and safety is particularly pronounced in cyber-physical systems, where a security issue affecting system behavior can directly produce safety consequences. A striking example is the effect of environmental threats such as radiation-induced bit-flipping in space or high-altitude systems which may originate outside any adversarial intent yet carry both security and safety implications. A risk does not always fall neatly into a single category: if a security-related failure can produce hazardous operational conditions, it must be treated with the same urgency as a safety risk. In TARA, this means the focus should not only be on the origin or nature of a threat, but on its impact across all relevant dimensions. By adopting Model-Based Design for cybersecurity risk analysis, organizations can detect vulnerabilities early in development, maintain full traceability between requirements, design, risks, and mitigation strategies, and simulate and validate security mechanisms before deployment. This approach not only improves system resilience but also accelerates development by reducing late-stage rework. 

From Reactive Security to Proactive Design 

The transition to Model-Based Design reflects a broader shift in engineering philosophy. Instead of reacting to threats after they emerge, organizations can anticipate and mitigate them during system design. Cybersecurity risk analysis is no longer a standalone activity it is an integral part of how modern systems are built. For engineering teams working on aerospace, defense, or other safety-critical systems, the question is no longer whether to integrate cybersecurity into the design process, but how quickly they can adopt a model-based approach to stay ahead of evolving threats. 

Final Thoughts 

As systems continue to grow in complexity, the need for scalable, integrated cybersecurity solutions will only increase. Model-Based Design provides a practical and proven framework for addressing this challenge — one that combines structured workflows, simulation capabilities, and continuous analysis to move organizations from reactive defenses to proactive, design-driven security. In a world where cyber threats evolve rapidly, the most effective protection starts not at deployment — but at design. And in domains like aerospace and defense, where the consequences of getting it wrong are measured in mission failure, regulatory liability, or worse, that principle is not optional. This is the kind of work Qyntar was built for. As SciEngineer’s cybersecurity practice, Qyntar operates at the intersection of engineering rigour and adversarial thinking supporting defense and aerospace teams with attack path analysis across IT, OT, and embedded architectures, supply chain risk management, and compliance with NIST 800-53, NIST 800-171, NATO and EU cybersecurity frameworks, and DO-356. Learn more →