Defense-based quantification of system security

Abstract

Computing equipment obtains a system model (110) that represents assets (A) of a system (100) and paths (P) therebetween. The computing equipment enriches the system model (110) with security control metadata (120) that indicates, for each of one or more of the paths (P), one or more security controls (SC) that are to be implemented for securing the 5 path (P). The computing equipment performs, or retrieves results of, static security analysis (130) on artifacts associated with the system (100) to identify issues (140) with security of the system (100). For each of one or more paths (P) represented in the system model (110), the computing equipment calculates a score (160) that quantifies how secure the path (P) is against a subset of the identified issues (140) that are applicable to the path (P), based on 0 which security controls (SC), if any, are to be implemented for securing the path (P) according to the enriched system model (110E). The computing equipment adapts, or assists with adapting, design of the system (100) based on the score (160) calculated for one or more of the paths (P).

Description

[0001] DEFENSE-BASED QUANTIFICATION OF SYSTEM SECURITY

[0002] TECHNICAL FIELD

[0003] The present disclosure generally relates to system security and more particularly to a defense-based approach to quantifying system security.

[0004] BACKGROUND

[0005] Cybersecurity concerns in modern software and hardware systems differ significantly depending on the nature of the system's deployment. Broadly, these systems fall into two categories: business-to-consumer (B2C) and business-to-business (B2B). Each category involves different security responsibilities, stakeholder expectations, and methods of security evaluation.

[0006] In B2C systems, the business retains control of the entire technology stack, from development through deployment, and manages security throughout the lifecycle. In these scenarios, vulnerabilities are addressed both in design and during operations, but the emphasis often falls on post-deployment monitoring and mitigation. Runtime security enforcement may leverage endpoint and network sensors for continuously monitoring deployed assets and responding to live threats. Security in this context focuses on monitoring whether a deployed system is configured securely and whether policies are correctly applied and enforced across the network in the post-deployment, operational phase of the system’s lifecycle.

[0007] By contrast, B2B systems involve a vendor organization (B1) delivering a product to another business (B2), and this introduces an entirely different set of security expectations. The receiving business (B2) typically lacks the ability to directly influence the development or architecture of the product it receives. As a result, the vendor (B1) is expected to not only address known vulnerabilities but also to provide detailed and proactive analysis of how those vulnerabilities affect the delivered system as a whole. This includes an assessment of the system’s architecture, its third-party dependencies, the controls already built into the design, and how all of these influence risk. Because the receiving business (B2) may have limited or no ability to apply security controls post-delivery, the burden falls on the vendor (B1) to integrate security at the design phase and / or assess the residual risks from the known vulnerabilities. The focus in B2B scenarios therefore shifts left, moving from postdeployment reaction to early-stage, design-phase security that is built into the system. This however presents substantial challenges when it comes to scalability and knowledge sharing, particularly because vendors often lack the desire or ability to share sensitive source code or architectural details with customers. Vulnerability prioritization across both B2C and B2B settings often relies on the Common Vulnerability Scoring System (CVSS), which provides a standardized way to assign severity scores to known vulnerabilities. The higher the CVSS score for a vulnerability, the greater the inherent severity of the vulnerability. However, CVSS is fundamentally attack-driven. Its base and temporal scores are derived from assumptions about how an attacker might exploit a vulnerability under typical conditions. This makes CVSS useful for estimating the exploitability of a vulnerability in abstract terms, but it does not capture the specific impact that the vulnerability might have within a particular system’s design or deployment context.

[0008] To compensate for this, CVSS includes an environmental score component that allows organizations to tailor the vulnerability rating to reflect the real-world risk to their specific environment. These environmental metrics adjust the base assumptions by factoring in how important confidentiality, integrity, and availability are to the affected system. They also allow organizations to override the base metrics, such as attack vector, attack complexity, and privileges required, if those metrics differ in their specific environment. For example, a vulnerability that is considered exploitable over a network under general conditions might pose much less risk in a system that is air-gapped from all external connections. In that case, the organization can adjust the attack vector from "network" to "physical," lowering the CVSS score to reflect the true difficulty an attacker would face in exploiting it. Even with the environmental score component, a CVSS score still serves primarily to quantify how inherently severe a vulnerability is to a system, based on how an attacker might exploit it.

[0009] While this environmental scoring framework improves the fidelity of CVSS ratings, it also introduces a dependence on deep system-specific knowledge. Adjusting these scores accurately requires an understanding of the internal configuration, deployment model, and sensitivity of affected systems, but this information is rarely available outside the organization that built the system. In B2B relationships, this creates a dilemma: customers need an accurate risk assessment based on the system as designed or delivered, but vendors may be unable or unwilling to disclose the level of proprietary detail required to support such an assessment.

[0010] Challenges therefore exist in enabling vendors to convey a system-aware view of security to business customers, especially in the design phase and in a way that preserves the confidentiality of sensitive design information.

[0011] SUMMARY

[0012] Some embodiments herein exploit a system model, enriched with metadata about the system’s security controls, in order to quantify how secure the system is against security issues identified from static security analysis (e.g., pre-code flow analysis or source code scanning). Quantifying system security in this way, based on which security controls are to be implemented in the system, shifts the focus from attack-driven scoring to defense-driven scoring, so as to ground security scoring more in what the system owner actually controls (defenses) rather than in what it does not (attacks). That is, some embodiments generally provide a model-based security assessment framework that is grounded first in systemspecific defenses, not generalized attack feasibility. And by representing the system as a model enriched with metadata, some embodiments better enable system security scoring during the system’s design phase, so as to better inform proactive adaptation of the system’s design before deployment. Furthermore, by representing the system (e.g., its structure, controls, and / or dependencies) using metadata rather than source code, and by linking the system’s model to vulnerability data in a structured way, some embodiments allow vendors to deliver contextual security assessments to customers without exposing proprietary design details. This makes it possible to quantify system security in a way that is scalable, consistent, and aligned with the realities of B2B product delivery, especially during the design and implementation phase, before deployment or monitoring ever begins.

[0013] More particularly, embodiments herein include a method. The method comprises obtaining a system model that represents assets of a system and paths therebetween. The method also comprises enriching the system model with security control metadata that indicates, for each of one or more of the paths, one or more security controls that are to be implemented for securing the path. The method also comprises performing, or retrieving results of, static security analysis on artifacts associated with the system to identify issues with security of the system. The method also comprises, for each of one or more paths represented in the system model, calculating a score that quantifies how secure the path is against a subset of the identified issues that are applicable to the path, based on which security controls, if any, are to be implemented for securing the path according to the enriched system model. The method also comprises adapting, or assisting with adapting, design of the system based on the score calculated for one or more of the paths.

[0014] Other embodiments herein include computing equipment comprising processing circuitry. The processing circuitry is configured to obtain a system model that represents assets of a system and paths therebetween. The processing circuitry is also configured to enrich the system model with security control metadata that indicates, for each of one or more of the paths, one or more security controls that are to be implemented for securing the path. The processing circuitry is also configured to perform, or retrieve results of, static security analysis on artifacts associated with the system to identify issues with security of the system. The processing circuitry is also configured to, for each of one or more paths represented in the system model, calculate a score that quantifies how secure the path is against a subset of the identified issues that are applicable to the path, based on which security controls, if any, are to be implemented for securing the path according to the enriched system model. The processing circuitry is also configured to adapt, or assist with adapting, design of the system based on the score calculated for one or more of the paths.

[0015] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a block diagram of a process for defense-based quantification of system security according to some embodiments.

[0017] Figure 2 is a block diagram of path score calculation according to some embodiments.

[0018] Figure 3 is a block diagram of additional details of score calculation for a path according to some embodiments.

[0019] Figure 4 is a block diagram of issue-specific score calculation according to some embodiments.

[0020] Figure 5 is a block diagram of asset-level score calculation according to some embodiments.

[0021] Figure 6 is a block diagram of an aggregated system risk analyzer according to some embodiments.

[0022] Figure 7 is a block diagram of metadata creation according to some embodiments.

[0023] Figure 8 is a block diagram of a risk analyzer and aggregator according to some embodiments.

[0024] Figure 9 is a block diagram of a system under evaluation in the form of a software web application according to an example.

[0025] Figure 10 is a block diagram of combining defense vectors and attack vectors for system aggregation according to some embodiments.

[0026] Figure 11 is a block diagram showing preparatory steps for gathering metadata according to an exemplary embodiment.

[0027] Figure 12 is a block diagram of risk assessment for computing the security posture of an application / system according to some embodiments

[0028] Figure 13 is a block diagram of a sample application example with different layers of trust boundaries and defense security controls according to some embodiments.

[0029] Figure 14 is a table representing score calculation according to some embodiments.

[0030] Figure 15 is a method for defense-based quantification of system security according to some embodiments.

[0031] Figure 16 is a block diagram showing an exemplary embodiment of a system implementing the present solution in the form of computing system environment.

[0032] DETAILED DESCRIPTION

[0033] Figure 1 shows a system 100 which broadly represents an organized collection of interacting components that together are to designed to perform one or more defined functions. As designed, the system 100 may include hardware elements such as physical devices, sensors, or computing nodes, include software elements such as services, microservices, application programming interfaces (APIs), or libraries, or include a combination of both hardware and software elements. In embodiments where the system 100 is designed to include software elements, the system 100 may be represented at the level of its source code 100C, as a collection of interrelated code artifacts — such as classes, functions, modules, and / or configuration files — that define the behavior and structure of its constituent components. No matter whether the system 100 is to include hardware, software, or both in combination, the system 100 in some embodiments is designed to be deployed in a centralized or distributed architecture, e.g., as a set of networked components in a cloud infrastructure, edge computing environments, or enterprise networks.

[0034] As part of the potentially iterative system design process, embodiments herein leverage static security analysis 130. Static security analysis 130 reveals issues 140 with the security of the system 100, e.g., early in the system development lifecycle. These issues 140 may encompass a flaw, defect, weakness, anomaly, vulnerability, exposure, or other problem that impacts the ability of the system 100 to protect against attacks that could compromise the system’s intended operation, integrity, confidentiality, availability, or the privacy of the data it processes. The issues 140 may for example include those that reduce the system’s ability to resist, detect, respond to, and / or recover from unauthorized access, misuse, disruption, modification, or data leakage. The issues 140 may alternatively or additionally span those arising from external attacks as well as internal misuse, enforcement of access and usage policies, and / or preservation of data privacy and user confidentiality.

[0035] In some particular embodiments, the identified issues 140 include vulnerabilities that constitute a flaw or weakness in code or configuration that can be directly exploited by a threat actor to cause harm, e.g., unauthorized access, privilege escalation, data exfiltration, or service disruption. In situations where the vulnerability identified is commonly encountered, the vulnerability may be mapped to an identifier standardized for identifying such a vulnerability, such as a CVE (Common Vulnerabilities and Exposures) identifier corresponding to the recognized vulnerability. For example, a hardcoded password might be associated with CVE-2022-22965 (Spring4Shell), an input validation flaw enabling remote code execution might map to CVE-2021-44228 (Log4Shell), and an improperly secured API endpoint might correspond to CVE-2019-19781 (Citrix ADC path traversal vulnerability). In these embodiments, then, security issues 140 may include specific system vulnerabilities that are cataloged as known exploitable flaws. Associating vulnerabilities with known CVEs facilitates traceability, remediation, and alignment with public vulnerability databases. The identified issues 140 may alternatively or additionally include exposures that constitute a condition that may not be immediately exploitable but still weakens the system's defensive posture, e.g., generalized system weaknesses that are enumerated as common design or coding weaknesses. These may include open endpoints, excessive information disclosure, or relaxed security settings, as a few examples. An identified exposure may similarly be mapped to an identifier standardized for identifying such an exposure, e.g., a CVE identifier for that exposure.

[0036] In any event, static security analysis 130 is static in the sense that it analyzes the system 100 in a static or non-executing state, i.e., without running the system 100 or any of its components in real production or a live environment. In embodiments where the system 100 includes a software application, static security analysis 130 may include Static Application Security Testing (SAST). In these and other embodiments, instead of evaluating the system 100 during execution, the analysis 130 is performed on artifacts associated with the system 100, which refer to files, representations, or other objects or relics that describe the system’s structure or behavior. Such artifacts may include for instance source code, compiled binaries, configuration files, firmware images, or hardware design files (e.g., Hardware Description Language, HDL, Register-Transfer Level, RTL, or telemetry or dump data from test systems). These artifacts are systematically analyzed as they exist at rest, without requiring system execution, as a way to examine the structure, data flow, and / or control flow of the system 100 as designed. By examining the system 100 in this static state, the analysis 130 can infer potential vulnerabilities, exposures, or other issues 140 based on how the system 100 is designed, as opposed to how it behaves during operation at run-time. For example, static security analysis 130 may detect insecure API usage, SQL injection risks, cross-site scripting (XSS) flaws, hardcoded credentials, improper cryptographic implementations, and / or other weaknesses that could be exploited by attackers if left unresolved.

[0037] Note that some embodiments herein perform static security analysis 130 internally and / or independently. Other embodiments, especially those in distributed or networked environments, may rely on external or outsourced analysis, in which case embodiments may retrieve the results of static security analysis 130 as externally performed and then leverage those results for further processing.

[0038] Viewed on their own, though, these individual issues 140 may only characterize the system’s security at the atomic level, rather than from a wider, end-to-end perspective. To facilitate a system-aware view of the system’s security, embodiments herein exploit a system model 110 that models the system 100. The system model 110 abstracts the system 100 as a bounded collection of assets A and paths P that interconnect those assets A. The system model 110 accordingly represents assets A of the system 100 and paths P therebetween. Assets A are defined as elements or nodes within the system 100 that possess business value and therefore warrant protection. Examples of assets A include, but are not limited to, nodes, servers, clusters, microservices, software components or modules, software classes, software methods, packaged software, and compiled code artifacts. The system model 110 captures both the individual nature of these assets A and their interdependencies by representing logical or physical connections between the assets A as paths P. These paths P denote potential interaction, communication, or dependency relationships between assets A of the system 100, e.g., in the form of communication channels, data flows, state transitions, dependencies, or access relationships. A path P may also be referred to or formed from one or more edges in the model 110. In these and other embodiments, then, the system model 100 is an abstract, structured representation of the system’s architecture, components / functions, and relationships or interactions therebetween, without necessarily referencing implementation details or physical deployment.

[0039] The system model 110 is a structured representation of the system 100 in the sense that it models the system 100 according to a defined schema or format, making it machine- readable and suitable for precise interpretation, automation, or transformation. The system model 110 may for example follow predictable syntax and semantics, allowing it to be queried, validated, or processed by software tools. This contrasts with an unstructured representation that may include informal or natural-language descriptions lacking consistency in format.

[0040] In some embodiments, for example, the system model 110 includes a diagrammatic model 110-1 that comprises a diagrammatic or schematic representation of the system 100. The diagrammatic model 110-1 may for example express the assets A and the paths P therebetween in a graphical format that is suitable for visualization or programmatic traversal. The system model 110 in this case may be expressed in a modeling language such as Unified Modeling Language (UML) or Systems Modeling Language (SysML). In one example, the system model 110 may be represented as a UML class diagram that defines associations and dependencies between classes, as an architecture diagram that depicts components, interfaces, and communication flows, as a data flow diagram that represents process interactions and data movements, or as a component model (e.g., a C4 model) illustrating dependencies and communication between services or modules.

[0041] In other embodiments, the system model 110 alternatively or additionally includes a metadata model 110-2 that comprises a structured metadata representation of the system 100. The metadata model 110-2 may for example represent the system 100 with metadata about each asset A of the system 100 and metadata about each path P in the system 100. The system model 110 in this case may take the form of a machine-readable model in JavaScript Object Notation (JSON) format or some other structured format such as extensible Markup Language (XML) or XML Metadata Interchange (XMI). Metadata may include identifiers, types, attributes, dependencies, relationships, or any other data describing the assets A and paths P.

[0042] As one concrete example, for each asset A, the metadata model 110-2 may include metadata with at least some of the following structure and / or attributes in JSON format (where an asset A is reflected by a “Node” in the metadata):

[0043] “Node”: {

[0044] “type”:“object”,

[0045] “properties”: {

[0046] “name”:{“description”:“ ”,“type”: “string”},

[0047] “type”:{“description”:“ ”,“type”: “string”},

[0048] “protocol”:{“description”:“ ”,“type”: “string”},

[0049] “attributes”: {

[0050] “type”:“object”,

[0051] “properties”: {

[0052] “criticality”:{“description”:“ ”,“type”: “number”, “minimum”: 0, “maximum”: 10},

[0053] “configurability:”!

[0054] “properties”: {

[0055] “configurable”:{“description”:“Check if configurable”, “type”: “boolean”},

[0056] “value”:{“description”:“ ”,“type”: “number”, “minimum”: 0, “maximum”: 10}

[0057] }

[0058] }

[0059] “reachability”:{“description”:“ ”,“type”: “number”, “minimum”: 0, “maximum”: 10},

[0060] “risk”: {“description”:" ”,“type”: “number”, “minimum”: 0, “maximum”: 10},

[0061] “usage”: {“description”:" ”,“type”: “number”, “minimum”: 0, “maximum”: 10},

[0062] }

[0063] }

[0064] }

[0065] }

[0066] And, for each path P, the metadata model 110-2 may include metadata with at least some of the following structure and / or attributes in JSON format (where a path P may be a combination of one or more “Edges” in the metadata):

[0067] “Edge”: {

[0068] “type”:“object”,

[0069] “properties”: {

[0070] “source”:{“description”:“ ”,“type”: “string”}, “destination”:{“description”:“ ”,“type”: “string”}, “protocol”:{“description”:“ ”,“type”: “string”}, }

[0071] }

[0072] In embodiments where the system model 110 includes the metadata model 110-2, the metadata model 110-2 may be derived, converted, or otherwise obtained from the diagrammatic model 110-1. This process may involve parsing the diagrammatic model 110-1 to extract the constituent elements (assets A) and the relationships therebetween (paths P). Each element in the diagrammatic model 110-1 may be mapped to a corresponding asset A in the metadata model 110-2, and each connector or link between elements in the diagrammatic model 110-1 may be mapped to a corresponding path P in the metadata model 110-1. The extracted elements and relationships may then be encoded as metadata, capturing key attributes such as identifiers, types, interfaces, dependencies, and / or roles within the system 100. This process may be performed manually using modeling tools that support export functions, or automatically using software capable of programmatically traversing and interpreting the diagram’s underlying representation. The result is a structured metadata model 110-2 that preserves the structural and behavioral semantics of the original diagrammatic model 110-1 while enabling downstream processing.

[0073] In various embodiments, the system model 110 may be constructed and utilized during the design phase of system development, prior to the implementation or deployment of the system 100. During this phase, the system model 110 may serve as a forward-looking abstraction that captures intended components, interactions, and structural relationships based on architectural plans, specifications, or preliminary diagrams, with or without any actual code or infrastructure having been implemented. This design-time modeling allows for early validation against stakeholder constraints or performance objectives, and may guide implementation by providing a consistent blueprint for how assets A are to be structured and interconnected by paths P.

[0074] The system model 110 however may not itself reflect some of the security controls (SC) that the system 100 is designed to have in place for securing the system 100. Security controls refer to technical, procedural, or physical mechanisms implemented within the system 100 to prevent, detect, or mitigate security issues 140. These security controls SC may for example include authentication mechanisms (e.g., user identity verification), input validation and verification, output sanitization, encryption of data in transit or at rest, access control policies, secure database query enforcement, logging and audit trails, identification and monitoring of user or system behavior, and runtime protections such as web application firewalls (WAFs). Security controls SC can be applied at various layers of the system 100, ranging from the application layer to the infrastructure layer, and may operate proactively to block attacks or reactively to detect and contain them.

[0075] Accordingly, embodiments herein notably enhance the system model 110 with security control metadata 120. Security control metadata 120 herein comprises data which describes a security control SC that is to be implemented for securing a path P. Security control metadata 120 that describes a security control SC for a path P may for example describe the type of the security control SC, a relative weight to be given to the security control SC on the path P, or other attributes characteristic of the security control SC. Generally, then, security control metadata 120 indicates, for each of one or more of the paths P in the system 100, security control(s) SC that are to be implemented for securing the path P.

[0076] In embodiments where the system model 110 takes the form of the metadata model 110-2, enrichment may involve supplementing the metadata model 110-2 with additional metadata that describes the security controls SC for respective paths P. That is, enrichment may entail, for each of one or more paths P, enriching the metadata that the model 110-2 has about the path P with the security control metadata 120 for that path P, indicating which security controls, if any, are to be implemented for securing the path P. Continuing the above concrete example above, enrichment may entail adding a “security_control” attribute to each “Edge” object representing a path P, where the “security_control” attribute constitutes security control metadata 120 for that path P. In this example, the “security_control” attribute indicates that nine security controls are to be implemented for the path, including security controls that are labeled as “authentication”, “input_verification”, “validity_check”, “output_sanititation”, “encryption”, “web_application_firewall”, “identification”, “logging”, and “secure_database_access”.

[0077] “Edge”: {

[0078] “type”:“object”,

[0079] “properties”: {

[0080] “source”:{“description”:“ ”,“type”: “string”},

[0081] “destination”:{“description”:“ ”,“type”: “string”}, “protocol”:{“description”:“ ”,“type”: “string”}, “security_control”: {

[0082] “type”: “object”,

[0083] “properties”: {

[0084] “authentication”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “input_verification”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “validity_check”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “output_sanitation”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “encryption”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “web_app_firewall”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “identification”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “logging”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, “secure_db_access”:{“weightage”: “type”: “number”, “min”: 0, “max”: 10}, }

[0085] }

[0086] } }

[0087] The “type” attribute indicates a classification of the security control SC according to one or more classification criteria. For example, Preventive controls aim to block attacks before they cause harm and include mechanisms such as authentication, input validation, encryption, and access controls. Detective controls identify and alert on security-relevant events or anomalies and include logging, intrusion detection systems (IDS), and audit trails. Corrective controls help restore systems to a secure state after an incident, such as automated patching or configuration rollback mechanisms.

[0088] The “weightage” attribute indicates a relative weight to be given to the security control SC on the path P. A higher weight means that the particular security control SC is more important or critical for securing the path P than a lower weight, e.g., where a given type of security control may be more or less critical depending on which path P it is implemented on. Max and min attributes refer to a normalization scale which is numeric between 0-10.

[0089] In these and other embodiments, a security control SC may be defined at a level of generality that is not specific to any individual security issue 140, e.g., any individual vulnerability or exposure. A security control SC may thereby be issue-agnostic and / or potentially applicable for securing against multiple security issues 140. For example, an “authentication” security control is not specific to any individual security issue 140 (e.g., any individual CVE) but rather may contribute towards securing the system 100 against multiple security issues 140. Generally, then, at least one of the security controls SC may be issueagnostic and / or mitigate a security risk attributable to multiple types of security issues 140. Defining a security control SC in this way may advantageously enable more efficient population of and parsing of the security control metadata 120, without having to tailor the security control metadata 120 for a potentially very large number of individual security issues 140.

[0090] The security control metadata 120 for a path P may thereby generally describe what security control(s) are to secure the path P by defending the path against attacks or any other security issue 140. For this reason, the security control metadata 120 for a path P (e.g., the “security_control” attribute) may also be referred to as a so-called defense vector for that path P. The defense vector for a path P in this case includes security control attributes for different respective security controls, e.g., with each security control attribute indicating whether or not a respective security control is to be implemented for securing the path P and / or describing that security control.

[0091] In any event, enriching the system model 110 with security control metadata 120 yields an enriched system model 110E that not only captures the system’s architecture, components / functions, and relationships or interactions therebetween, but also reflects what security controls SC are to secure the system 100. Embodiments herein exploit this resulting enriched system model 110E to quantify the extent to which the system 100, its assets A, and / or its paths P are actually secured against the issues 140 revealed by static security analysis 130.

[0092] Figure 1 in this regard shows that a path score calculation 150 accepts the security issues 140 identified by statis security analysis 130 and the enriched system model 110E as input. From this input, the path score calculation 150 calculates one or more scores 160 for one or more respective paths P represented in the system model 110 / 110E, i.e., the score(s) 160 are path-specific. The score 160 for a path P quantifies how secure that path P is against a subset of the identified issues 140 that are applicable to the path P, based on which security controls SC (if any) are to be implemented for securing the path P according to the enriched system model 110E. Which of the identifies issues 140 are applicable to which paths P may be determined or otherwise governed by the type of path and / or the type of issue 140, e.g., some types of paths may not be in any way vulnerable to some types of issues.

[0093] In some embodiments, the score 160 for a path P monotonically increases the more secure the path P is against the subset of issues 140 that are applicable to the path P. The score 160 in some sense, then, is defense-driven so as to grade how well the system 100 defends the path P against attacks, with a higher score 160 reflecting the path P has better defenses. This contrasts with an attack-driven score that would grade how vulnerable the system 100 is to attack, with a higher score reflecting the path P is more susceptible to attack. Regardless, in these and other embodiments, path score calculation 150 may calculate the score 160 for a path P such that, for each issue 140 in the subset of issues 140 that are applicable to the path P, a security control SC that secures against the issue 140 and is to be implemented for securing the path P contributes positively to a value of the score 160. Note here that, even if a security control SC is to be implemented for securing the path P, that security control SC contributes positively to a value of the score 160 only to the extent that it actually secures against an issue in the subset of issues that are applicable to that path P.

[0094] In these and other embodiments, the score 160 for a path P may effectively reflect a level of security risk on the path that remains once the mitigating effect of the security control(s) SC are accounted for. The score 160 may thereby reflect the residual security risk on a path P.

[0095] Figure 1 shows that system design adaptation 170 may be performed based on or as a function of the resulting score(s) 160 calculated for path(s) P. System design adaptation 170 may be performed directly as a function of these path-specific score(s) 160 in some embodiments. Or, in other embodiments detailed later, other score(s) may be computed as a function of the path-specific score(s) 160, e.g., in the form of asset-level score(s) or a system-wide score, and then system adaptation 170 may be alternatively or additionally performed as a function of these other score(s). Either way, system design adaptation 170 in some embodiments adapts, or assists with adapting, the design of the system 100 based on the score(s) 160 calculated for path(s) P. For example, this may involve adapting, or assisting with adapting, which security controls SC are to be implemented for at least one path P represented in the system model 110 / 110E, e.g., as part of an iterative design process to improve the security of the system 100.

[0096] The score(s) 160 may for example advantageously quantify where architectural weaknesses, risky dependencies, or insufficient protections exist in the system 100, even before the system 100 is implemented. System design adaptation 170 can then adapt the system’s design as needed to mitigate identified risks, e.g., through structural changes or the introduction of additional or different security controls SC. For example, components found to process sensitive data might be redesigned to operate in isolated environments or incorporate encryption at rest and in transit. Paths P for communication between assets A may be rerouted through secure gateways or hardened with stricter authentication and authorization mechanisms. The selection of third-party libraries or cloud services can be reconsidered if they introduce known vulnerabilities or insufficient privacy guarantees. By iterating on the design in response to the quantified security assessment findings reflected in the score(s) 160, the likelihood of costly rework later in the development lifecycle can be avoided and security can instead be embedded as a foundational aspect of the system’s architecture by design.

[0097] In some embodiments, the system design may be automatically adapted in response to security assessment findings informed by the score(s) 160, without requiring direct human intervention. For example, system design adaptation 170 may update system configuration files, dependency declarations, or deployment topologies based on security policies defined as a function of the score(s) 160. Or, if a component is found to lack input validation, system design adaptation 170 may automatically insert a proxy layer into the design to enforce sanitization. As yet another example, if a data flow is identified as unencrypted, system design adaptation 170 may adapt the design to insert encryption modules or reroute traffic through secure communication channels. Other automated adaptation possibilities include modifying access control lists, regenerating container images with patched dependencies, or selecting alternative third-party components from trusted repositories.

[0098] In other cases, system design adaptation 170 may assist security personnel by producing structured outputs that guide manual adaptation. For example, system design adaptation 170 may generate annotated output highlighting assets A and paths P associated with specific vulnerabilities, exposures, or privacy concerns. It may also output remediation suggestions and / or prioritized score(s) 160. These outputs can be visualized in design tools or exported in machine-readable formats to integrate with security workflows, allowing architects or engineers to take informed, targeted actions to revise the design. Some embodiments may thereby enable scalable adaptation of the system’s security posture during the design phase.

[0099] Consider now additional details of path score calculation 150 according to some embodiments. As shown in Figure 2, path score calculation 150 consists of score calculation 150-1 ...150-N for respective paths P-1...P-N. Score calculation 150-1 for path P-1 accepts as input a subset 140-1 of security issues 140 that are applicable to that path P-1 as well as security controls SC-1 that are to be implemented on the path P-1 . From this, score calculation 150-1 for path P-1 calculates a path-specific score 160-1 that quantifies how secure the path P-1 is against the subset 140-1 of security issues 140 due to security controls SC-1 being implemented on the path P-1. Generally, with 1 < n < N, score calculation 150-n for path P-n calculates a path-specific score 160-n that quantifies how secure the path P-n is against the subset 140-n of security issues 140 due to security controls SC-n being implemented on the path P-n.

[0100] Figure 3 illustrates still additional detail of score calculation 150-n for path P-n. As shown, score calculation 150-n may be composed of issue-specification score calculation 152-1 ...152-X for respective security issues 142-1... 142-X in the subset 140-n of issues 140 that are applicable to the path P-n, followed by aggregation 154, where 1 < x < X. In this case, issue-specific score calculation 152-x for issue 142-x calculates an issue-specific score 144-x that quantifies how secure the path P-n is against that issue 142-x. This calculation is based on which security controls SC-n, if any, are to be implemented for securing the path P-n against that issue 142-x, according to the enriched system model 110E. This results in issue-specific scores 144-1...144-X for respective security issues 142- 1... 142-X in the subset 140-n. Aggregation 154 then aggregates the issue-specific scores 144-1 ...144-X calculated for the path P-n, to arrive at the path-specific score 16-n for that path P-n. Figure 4 now shows more detail of issue-specific calculation 152-x for security issue 142-x according to some embodiments. As shown, issue-specific score calculation 152-x comprises control-specific score calculation 156-1 ...156-Y for respective security controls C- 1...C-Y that are candidates to be implemented for securing a path P-n, where 1 < y < Y. Control-specific score calculation 156-y in this regard calculates a control-specific score 146- y that is specific to a particular security control candidate C-y. This control-specific score 146-y quantifies an extent to which the candidate security control C-y secures the path P-n against the security issue 142-x. This score 146-y is calculated as a function of whether the candidate security control C-y is to be implemented for securing the path P-n according to the enriched system model 110E. In some embodiments, the score 146-y is calculated also as a function of a normalized weight W-y specific to the candidate security control C-y. The normalized weight W-y in this case may reflect a relative importance or criticality of the candidate security control C-y in securing the path P-n against the issue 142-x.

[0101] No matter how the path-specific scores 160 are calculated, though, Figure 5 depicts resulting scores 160 for example paths to / from a particular asset A, superimposed for visualization on the enriched system model 11 E. For paths P-1 through P-5, path score calculation 150 calculates respective scores 160-1 ...160-5 that are normalized within a range of 0 - 10. Paths P-2 and P-4 have scores 160-2, 160-4 on the lower end, signifying that those paths P-2, P-4 are secured to a lesser extent, whereas path P-5 has a score 160- 5 on the higher end, signifying that the path P-5 is secured to a greater extent.

[0102] In some embodiments suggested above, Figure 5 shows that the path-specific scores 160 may be combined by asset-level score calculation 180 to produce an asset-level score 182 for each asset A. In this case, for each of one or more assets represented in the system model 110 / 110E, the scores 160 calculated for paths P to or from the asset may be combined, in order to obtain an asset-level score 182. This asset-level score 182 quantifies how secure the asset A is against a subset of issues 140 applicable to the asset A. Design adaptation may then be performed alternatively or additionally based on the asset-level sco re (s) 182.

[0103] Similarly, although not shown, one or more of these resulting asset-level score(s) 182 may themselves be combined. If asset-level score(s) 182 for a portion of the assets A in the system 100 are combined, the result may be one or more sub-system -level scores that each quantify how secure a subsystem within the system 100 is. Or, if asset-level score(s) 182 for all of the assets A in the system 100 are combined, the result may be a system-wide score that quantifies how secure the system 100 as a whole is. Such a system-wide score may thereby advantageously quantify the overall security posture of the system 100. In this case, then, system design adaptation 170 may be performed based on the sub-system -level score(s) and / or the system-wide score. The score(s) in these and other embodiments herein thereby enable improved understanding of the overall system’s security posture, as compared to individual vulnerability analysis (atomically). The score(s) may enable prioritization for project planning (based on scores at path levels or system level), e.g., which security controls are needed to be implemented first and which later. Moreover, with score(s) at the path level and / or system aggregated level, some embodiments may reduce the time spent on analyzing individual issues / vulnerabilities.

[0104] Moreover, as embodiments herein exploit a system model 110 rather than relying on an already deployed system 100 in operation, some embodiments herein may support experimental or hypothetical design scenarios, e.g., as part of exploratory designs for the system 100. For example, the score(s) may help security experts, architects, designers, or product owners to experiment with the system design to see if security controls are more effective compared to others and / or to identify which security issues could pose bigger security or privacy risks compared to others.

[0105] That said, some embodiments may also be implemented post-deployment, to support re-design efforts at a later stage. In these and other embodiments, then, static security analysis 130 may be supplemented by dynamic security analysis, e.g., penetration testing, Dynamic Application Security Testing (DAST), fuzz testing, runtime security monitoring, etc. This dynamic assessment may reveal security issues 140 from a different perspective, offering additional insight into score(s) 160 and potential system re-design.

[0106] Some embodiments address one or more shortcomings of traditional vulnerability scanning tools. Vulnerability scanning tools give a general alert or warning on any vulnerability found in a scan of a deployed system. Such a scan produces results in terms of one or more Common Vulnerability and Exposure (CVE) records. A CVE identifies or provides a number given to a vulnerability at a global level.

[0107] The security scan on any software application generates a huge volume of vulnerabilities, which need to be analyzed manually to determine the associated security risks. The manual analysis requires expert knowledge which is difficult to find. Additionally, it is less efficient, error-prone and time-consuming.

[0108] Traditional vulnerability scanning lacks the ability to provide insight into the system’s security posture. Security posture refers to an organization's overall state of cybersecurity readiness. An enterprise's security posture considers: Visibility into the security status of software and hardware assets, networks, services, and information. The security posture of an organization generally represents the overall security status of its networks, systems, and procedures. Vulnerability scanning tools don’t have intelligence about “Application\System knowledge” and thereby effective security impact analysis is not possible.

[0109] Some embodiments address the inability of other approaches to provide an aggerated perspective of the security risk from the system point of view. Indeed, traditional vulnerability scanning tools perform analysis only for individual vulnerabilities at the atomic level, missing the bigger end to end view. What it means is that the security scan by the tools is usually at the individual component (atomic) level without any knowledge of the overall system level security guardrails and procedures in place. Contrasted with these approaches, embodiments herein account for sufficient guardrails and / or procedures at the system level which might prevent hackers to reach the vulnerabilities at the atomic or individual component level. Some embodiments thereby overcome these shortcomings by providing an automated way to visualize or present the security posture of a system (e.g., an application) and assess the residual risk of the system. Some embodiments may provide indications on which (existing) security controls at the system level can reduce an application’s security risk at the system level.

[0110] Some embodiments herein also contrast with existing methods that address security only from the attack scenario perspective. This is the case for National Vulnerability Databases (NVD’s) Common Vulnerability Scoring System (CVSS), MITRE’S or other commonly known attack models (MITRE, etc.), OWASP’s Common Weakness Enumeration (CWE) and Common Attack Pattern Enumeration and Classification (CAPEC). An NVD, National vulnerability Database, is a central database of vulnerabilities of known 3PP / Open- source software. CVSS is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores are calculated based on a formula that depends on several metrics that approximate ease and impact of an exploit. Scores range from 0 to 10, with 10 being the most severe. Embodiments herein address security in the inverse way, i.e., from the defense scenario perspective.

[0111] Moreover, some embodiments herein address shortcomings of vulnerability scanning tools in that they don’t have knowledge about the application\system and its interacting components, unused components, or the security controls in place from the application\system architecture view. These tools are only doing shallow analysis (best effort basis). Even if these tools learn, they cannot know details about an application / system on how a vulnerable component is utilized.

[0112] Some embodiments herein also address shortcomings of existing tools that focus simply on mitigating a vulnerability. These tools do not focus on answering the question of, if some vulnerabilities (i.e., risk) are left out or not fixed, what would be the residual risk considering the product’s overall design and security controls. Embodiments herein in this regard account for the possibility that some vulnerabilities may result in critical risk at the system level whereas others are less severe at the system level due to already existing security controls and system architecture.

[0113] Since the aggregated scores are computed at the system level, this security posture potentially enables measuring the effectiveness / quality of zero trust implementation for the system. Some embodiments herein alternatively or additionally enable measuring zero trust at a system level.

[0114] More particularly, some embodiments provide a defense-driven approach for the risk assessment, on top of existing ways of computing risk through an attack-driven approach. Some embodiments reflect an inverse way of thinking of the risk, i.e., from the defense perspective rather only the existing perspective which is attack vector driven. These embodiments recognize that the defense is always under the control of the application / system owner, while attack scenarios are additional external / internal inputs that are dynamic in nature. Through this defense driven approach, some embodiments provide better tracking and implementation of security controls and hence better defenses against the attack scenarios.

[0115] Based on this premise, the score(s) described with respect to Figures 1-4 above may be realized in some embodiments in the form of a Defense Vector Scoring System (DVSS). Whereas the traditional CVSS attempts to assign severity scores to vulnerabilities, the DVSS in some embodiments herein reflects how good the system’s defenses are. This DVSS may be an arrived at by combining security control metadata / attributes, e.g., which may be defined by a Security Expert of that application as per the security requirements of the application. The security control metadata in this regard may include defense vector attributes. This Defense vector (DVSS) is metadata of the security control, indicates how it is mapped to the system’s assets, and indicates in which part of the application / system it is present.

[0116] Figure 6 is a block diagram showing an Aggregated System Risk Analyzer 7 that, according to some embodiments, performs one or more aspects shown in Figure 1 , e.g., system model enrichment, static security analysis, path score calculation 150, and / or system design adaptation 170. As shown, the NVD database 1 lists software-related vulnerabilities The System under Evaluation (SUE) 2 exemplifies the system 100 in Figure 1 . Vulnerability scanning is performed on the SUE, e.g., via static security analysis or dynamic security analysis such as penetration testing. The vulnerability scanning produces a list of various vulnerability findings, e.g., in the form of CVEs published in NVD, as well as their locations in the SUE (e.g., code repositories). Some embodiments thereby take input from a vulnerability scanner that in turn gets input from a National Vulnerability Database (NVD) to scan the System Under Evaluation (SUE) to produce a Vulnerability Scan results (one or more CVEs), etc. Security scanning tools (Static Application Security Test, SAST, or Dynamic Application Security Test, DAST) may be run against the application system at different phases of software development. They produce a list of vulnerabilities that ‘as per scanning tool’ are affecting the application / system.

[0117] Figure 6 further shows that the Aggregated System Risk Analyzer 7 exploits architecture inputs that define the architecture of the SUE 2. These can be programmatically drawn diagrams like PlantUML, ZenUML, Mermaid etc. Based on the architecture inputs, system level metadata is created, e.g., exemplifying the system model 110 in Figure 1. Figure 6 shows an illustration of the application / system metadata as Block 9. The application / system metadata may be used for evaluating the security posture. Component interaction diagrams, data flow diagrams, or service interactions may be used to produce the metadata at the system or compound aggregated level.

[0118] The Aggregated System Risk Analyzer 7 further exploits security control metadata 5, also referred to as defense vector(s). This may be based on input given by a Security Expert on the security controls, sub controls and their attributes. Figure 6 illustrates an example of security control metadata as Block 10.

[0119] A defense vector constitutes ‘inverse logic’ for computing security risk by seeing which defenses implemented in a system / application (or to be implemented) reduce the risk of exploiting any known vulnerabilities. This will help extract human knowledge into machine readable format which can later be used for further and futuristic processing. Even though the security scanning tools find many vulnerabilities that bring attack vectors to the application system, each asset may have one or more security controls implemented. These security controls defend against real attack exploit scenarios. A defense vector may be a parameter defined to encapsulate the security control type, as applied to an associated asset, and accounting for the criticality of the asset.

[0120] The Aggregated System Risk Analyzer 7 effectively merges the system / application metadata 4 and the security control metadata 5, e.g., exemplifying the system model enrichment process described in Figure 1. In some embodiments, when combined together, the system / application metadata 4 and the security control metadata 5 may be referred to as application / system context.

[0121] The Aggregated System Risk Analyzer 7 then finds which CVEs affect the SUE 2 (from vulnerability findings 3) and find the maximum impact flows. Based on this, the Aggregated Residual risk at system level is found via aggregated Risk Analysis. Risk Analysis entails combining the input from the above data / metadata i.e., system / application metadata, defense vector, and performing security risk analysis aggregated to the system level. This is different from individual / atomic CVE analysis as it covers the end-to-end aggregated system view for all the CVEs and all the implemented security controls. Thus, in addition to analyzing each vulnerability individually and in an atomic way, some embodiments provide an aggregated system level analysis considering broader end to end system view, where multiple vulnerabilities (CVEs) can be evaluated in a combined way (e.g., chain of attacks or lateral movement utilizing multiple CVEs). This may reduce time in analysis of the system to get an overall picture of the system’s risk.

[0122] Figure 8 shows that the final outcome of this is the system level security posture.

[0123] Some embodiments thereby include methods and procedures that combine the knowledge of the vulnerabilities (from scanning tools and / or penetration testing of the application / system, etc.) and the knowledge of the application\system (together with its security controls) in machine-readable format to assess the residual risks better.

[0124] In some embodiments, a machine-readable format (like for example JSON etc.) may have attributes that can contribute to risk-assessment of the residual risk (considering likelihood and impact of that application\system).

[0125] The Aggregated Residual risk in some embodiments may provide a result value (e.g., score in percent, or additional level e.g., class A, class B, etc.) representing the security posture. So, the result may be in format X (out of Y, or in percentage), or class B level security. This may give an overall indication or visualization of the security posture of the application system. This can help an organization understand the current situation overall.

[0126] Additionally, this can be used to theoretically model which application security control, if implemented, can improve the situation better in terms of residual risks. A security expert can for instance experiment with different permutations or combinations of security controls to find the best fit controls for the given application, considering the threat landscape. For example, given the system / application model, and security controls, and the known vulnerabilities, the security posture may be scored 45 (out of 100) as a hypothetical example. But if a new security control is added (say SC1 - additional access control checks) to the same system, the security posture meter may increase to 55 (instead of 45). Considering the above example, it is also quite possible that after the control SC1 was implemented to the system / application, new critical CVEs are later found that will reduce the score from 55 to 50 (automatically).

[0127] In some embodiments, for example, a security expert can look at problematic paths to identify which security controls on those paths would increase security of the application / system as whole. The security expert can experiment theoretically by checking which one would be more valuable for the least time / effort invested. Some embodiments thereby provide methods and procedure to perform theoretical assessment or whiteboard hacking. That is, some embodiments may help to evaluate / assess the current security posture of a system and theoretically evaluate the security posture assuming ‘what if a new control is implemented’ before even implementing those controls, to see if it improves the security posture or not and to what level the system risk gets reduced.

[0128] These and other embodiments may enable security personnel to focus more on the top security by design items and important vulnerabilities in a given application / system context and the latest attack trends in the industries (threat landscape).

[0129] The above could be periodically used as a quality check for improving the security posture.

[0130] This may be extended to the application level, rather than just the endpoint or host level.

[0131] Figures 7 and 8 show an overview of the steps involved in some embodiments. Figures 7 and 8 show System / application metadata in graphical representation. Critical paths of the system / application can be identified at this step. The graphs represent nodes of the products metadata, where NVC (Not Vulnerable Component) represents node of the system / application where there is no known vulnerability found yet. VC (Vulnerable Component) represents nodes of the system / application where there is already known vulnerability found. Figures 7 and 8 also show vulnerability metadata i.e., CVSS, as well as security control metadata which is the defense vector (can be represented in graphical structure). All of the above are combined together to come to an aggregated value, i.e., score, which is representing the system security posture (after residual risk-assessment). The graph overlaps or superimpose may provide the resultant effect of the defenses in place.

[0132] Figure 9 shows a concrete example of a system under evaluation in the form of a software web application with frontend, backend server and database, representing a three- tier application. In this example, a plantUML diagram is used to create the system diagram and extract the System / application metadata in Json format.

[0133] The JSON schema for the diagram is based on that described earlier, with the “Node” elements, “Edge” elements, and “security_controls” metadata in JSON format. The defense vector here may be a list of Security Control Attributes (where each edge can have zero or more security controls acting as defense against the attack vector).

[0134] Figure 10 summarizes the inverse logic of the attack vector to visualize the defense vector and combining them for system aggregation, DVSS vs. CVSS.

[0135] Figure 11 is a block diagram showing preparatory steps for gathering metadata (application and security controls) according to an exemplary embodiment. This entails preparing metadata of the product by defining assets and flows (Step 1), and preparing the defense vector of the product (security control metadata) (Step 2). The Security expert of the application may for example create a JSON Format based Key attributes, which defines the asset and key flows, and then defines the Defense Vector attributes, like control type, authentication type etc. This further entails mapping the defense vector to the product metadata (Step 3) and storing the mapping into the system context database (Step 4).

[0136] The above two databases are combined (Step 6) along with any known risks / weaknesses of the product (Step 6). The CVEs findings in this regard may be mapped with the DVSS attributes and application data, trying to identify the impacts of it. In some embodiments, the CVEs are mapped into CWEs to see which identified issue when fixed will result in maximum impact.

[0137] All the risks that are not addressed are aggregate and then create an overall residual system risk for the application. The result is the enriched product context (Step 7), as an example of the enriched system model 110E in Figure 1.

[0138] Figure 12 shows Risk assessment to compute the security posture of the application / system according to some embodiments.

[0139] Block 1 : The architecture inputs include programmatically drawn diagrams like PlantUML, ZenUML, Mermaid etc.. Based on these inputs, system level metadata is created and stored in an Application / system Context Database.

[0140] Block 2. Security scans run on the applications to get a list of vulnerabilities.

[0141] Block 3. Each CVE is processed and mapped to the component in the Architecture Diagram, so as to identify which part of the system each vulnerability belongs to.

[0142] Block 4. The resulting output is an Application / system context enriched Vulnerability Matrix

[0143] Block 5. The Matrix is used to map to the Application\System Context and Security Context Meta Data and calculate an Aggregated Risk Score

[0144] Figure 13 shows a sample application example with different layers of trust boundaries and defense security controls implemented at each layer viz. Front-end, middle layer (backend, database layer, etc.).

[0145] CVE-2023-34840 is in the Front-End Layer, which is part of CWE-79. CWE-79 primarily deals with Untrusted data that enters a web application, from a web request. As it is a web application, the primary attack vector is Network, and it requires user interactions by the attacker. As part of DVSS, the security control of Restricting Front-End API access to low privileges is defined.

[0146] The backend layer with business logic has many vulnerabilities (or CVEs) and thus many CWEs. In the above example, CWE-400 is related to uncontrolled resource consumption, which shows that if an attacker creates a repetitive task, it can end up using all system resources thereby crashing it. CWE-20 is related to inputs not validated correctly by the application. CWE-502 is improper deserialization of untrusted data.

[0147] Considering the above CWEs, the following security controls are needed in the backend layer: (i) Implement throttling and limit the amount of resources that an unauthorized user can cause to be expended; (ii) signing / sealing features of the programming language to assure that deserialized data has not been tainted; and (iii) use input validation frameworks.

[0148] Database layer comparatively has less CVE’s. CWE-1392 is usage of default credentials for the database. This would be the security control for the database.

[0149] Weaknesses that could be exploited are denoted here as CVEs (vulnerabilities) and they have common patterns called CWE (weakness enumerations) and some of these patterns independently or in a combined way can be tried out to exploit a system / application. Each such combined attack pattern is defined as CAPECs.

[0150] The CVEs can be found either through security scanning tools or penetration test exploits.

[0151] So, a list of a huge number CVEs can be converged into a smaller list of CWEs and similarly CWEs into multiple CAPECs.

[0152] The table in Figure 14 shows Security Controls not implemented for a CWE-79. If it is implemented, it will affect all the CVEs which have CWE-79 associated. This will help in improving the Net Security Control Value. In the current scenario it is 3.6

[0153] The table shows a list of CVEs identified by the security scans. Each CVE has a corresponding CWE, which is a broad area which this CVE belongs to. As part of the Security Control Meta Data, Security Controls and their Weightage are defined. This Weightage is defined based on CWE and the Criticality of the component.

[0154] If for example Control_1 is implemented for CVE-2020- 10776, it is marked yes; if it is not, then no. All the control implementations are aggregated for each CVE. For CVE-2020- 10776 is 0, while for CVE-2021-25963 it is 0.8.

[0155] Finally consolidated aggregation for all the CVEs is done. For CWE-79, it is 3.6 without controls being implemented

[0156] This is just an example. This entire process would be automated; that is what is being described in the table showing the security posture before CWE-79 is implemented.

[0157] If the controls for CWE-79 are implemented, the security posture improves to 6.8 from 3.6 as shown in the table of the security posture after CWE-79 is implemented.

[0158] Before implementing CWE-79 related security controls the residual risk calculated was 3.6 while after implementing the security controls related to CWE-79 it reached to 6.8.

[0159] This also gives an indication that CWE-79 is spread across many vulnerabilities and needs attention to improve the security posture and reduced the probability of attack scenarios.

[0160] This way, security architects can experiment theoretically and understand which controls need to be implemented first and which next.

[0161] The above example can be used for any system to aggregate the system level risk, understand the system’s security posture and also help understand what level of zero trust is implemented in the system / application and thereby measure how good is the defense in depth.

[0162] Security analysts can thus know controls are more important to be prioritized, in which part of the system and which are of the system has a bigger impacting problem.

[0163] In the example of Figure 14, the result of 3.6 in some embodiments may represent a path-specific score 160-n for a path n. In this case, the control net values in the far right column exemplify issue-specific scores 144-1. ,.144-X (e.g., as described in Figure 3). And each issue-specific score 144-x in a row is the aggregation of control-specific scores represented in that row (control-specific scores are a function of the weight (%) and whether the control is fixed (yes / no).

[0164] Some embodiments can be extended to not only apply to software but also to hardware vulnerabilities.

[0165] Some embodiments can be realized either by extending a vulnerability scanning tools or by creating a separate tool that takes the input of vulnerabilities from the scanning tool.

[0166] In view of the modifications and variations herein, Figure 15 depicts a method in accordance with particular embodiments. The method includes obtaining a system model 110 that represents assets A of a system 100 and paths P therebetween (Block 1500). The method also includes enriching the system model 110 with security control metadata 120 that indicates, for each of one or more of the paths P, one or more security controls SC that are to be implemented for securing the path P (Block 1510). The method also includes performing, or retrieving results of, static security analysis 130 on artifacts associated with the system 100 to identify issues 140 with security of the system 100 (Block 1520). The method also includes, for each of one or more paths P represented in the system model 110, calculating a score 160 that quantifies how secure the path P is against a subset of the identified issues 140 that are applicable to the path P, based on which security controls SC, if any, are to be implemented for securing the path P according to the enriched system model 110E (Block 1530). The method also includes adapting, or assisting with adapting, design of the system 100 based on the score 160 calculated for one or more of the paths P (Block 1540).

[0167] In some embodiments, the security control metadata 120 comprises, for each of the one or more paths P, a defense vector that includes security control attributes for different respective security controls SC, with each security control attribute indicating whether or not a respective security control is to be implemented for securing the path.

[0168] In some embodiments, the score 160 for a path monotonically increases the more secure the path is against the subset of issues 140 that are applicable to the path.

[0169] In some embodiments, the score 160 for a path is calculated such that, for each issue 140 in the subset of issues 140 that are applicable to the path, a security control that secures against the issue 140 and is to be implemented for securing the path contributes positively to a value of the score 160.

[0170] In some embodiments, calculating a score 160 for a path comprises, for each issue 140 in the subset of issues 140 that are applicable to the path, calculating an issue-specific score that quantifies how secure the path is against that issue 140, based on which security controls SC, if any, are to be implemented for securing the path against that issue 140 according to the enriched system model 110E, and aggregating the issue-specific scores calculated for the path. In some embodiments, calculating an issue-specific score for an issue 140 for a path comprises, for each of one or more candidate security controls SC that are candidates to be implemented for securing the path, calculating a control-specific score that quantifies an extent to which the candidate security control secures the path against the issue 140, as a function of whether the candidate security control is to be implemented for securing the path according to the enriched system model 110E. In some embodiments, calculating an issue-specific score for an issue 140 for a path comprises aggregating the control-specific scores calculated for the issue 140 for the path. In some embodiments, the control-specific score for a candidate security control is calculated also as a function a normalized weight specific to that candidate security control. In some embodiments, the normalized weight reflects a relative importance or criticality of the candidate security control in securing the path against the issue 140.

[0171] In some embodiments, the obtained system model 110 is a structured metadata representation of the system 100. In some embodiments, obtaining the system model 110 comprises converting a diagrammatic or schematic representation of the system 100 into the structured metadata representation of the system 100 comprising metadata about each asset of the system 100 and metadata about each path in the system 100, and said enriching comprises, for each of the one or more paths P, enriching the metadata about the path with the security control metadata 120 for that path indicating which security controls SC, if any, are to be implemented for securing the path P.

[0172] In some embodiments, the artifacts associated with the system 100 include source code for the system 100, configuration files for the system 100, and / or the system model 110.

[0173] In some embodiments, the issues 140 with security of the system 100 include specific system vulnerabilities that are cataloged as known exploitable flaws. In other embodiments, the issues 140 with security of the system 100 alternatively or additionally include generalized system weaknesses that are enumerated as common design or coding weaknesses.

[0174] In some embodiments, at least one of the one or more security controls SC is issueagnostic and / or mitigates a security risk attributable to multiple types of security issues. In some embodiments, the method further comprises, for each of one or more assets A represented in the system model 110, aggregating the scores 160 calculated for paths P to or from the asset in order to obtain an asset-level score that quantifies how secure the asset is against a subset of issues 140 applicable to the asset, and said adapting or assisting with adapting is performed based on the one or more asset-level scores (Block 1550). In some embodiments, the method further comprises, for each of multiple assets A represents in the system model 110, aggregating respective asset-level scores calculated for the assets A in order to obtain a sub-system -level score that quantifies how secure a subsystem within the system 100 is and / or a system-wide score that quantifies how secure the system 100 as a whole is, and said adapting or assisting with adapting is performed based on the sub-system -level score and / or the system-wide score (Block 1560).

[0175] In some embodiments, the method further comprises performing, or retrieving results of, dynamic security analysis on the system 100 to identify issues 140 with the security of the system 100.

[0176] In some embodiments, said adapting, or assisting with adapting, comprises adapting, or assisting with adapting, which security controls SC are to be implemented for at least one path represented in the system model 110.

[0177] Figure 16 is a block diagram showing an exemplary embodiment of a system implementing the present solution in the form of computing system environment 800. The computing system environment 800 may implement one or more aspects of the processes described in Figure 1 and / or Figure 15. The computing system environment may be any computing machine, e.g., virtual or physical server hosted with this function. It can also be implemented as a real time service (with or without agent).

[0178] Although as made clear above, the computing system environment 800 is only one example of a suitable computing environment for the present solution and is not intended to suggest any limitation as to the scope of use or functionality of the claimed subject matter. Further, the computing environment 800 is not intended to suggest any dependency or requirement relating to the claimed subject matter and any one or combination of components illustrated in the example operating environment 800.

[0179] An example of a device for implementing the previously described innovation includes a general purpose computing device in the form of a computer 810. Components of computer 810 can include, but are not limited to, a processing unit 820, a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.

[0180] Computer 810 can include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810. By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile as well as removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 810. Communication media can embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any suitable information delivery media.

[0181] The system memory 830 can include computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) and / or random access memory (RAM). A basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within computer 810, such as during start-up, can be stored in memory 830. Memory 830 can also contain data and / or program modules that are immediately accessible to and / or presently being operated on by processing unit 820. By way of non-limiting example, memory 830 can also include an operating system, application programs, other program modules, and program data.

[0182] The computer 810 can also include other removable / non-removable and volatile / nonvolatile computer storage media. For example, computer 810 can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and / or an optical disk drive that reads from or writes to a removable, nonvolatile optical disk, such as a CD-ROM or other optical media. Other removable / non-removable, volatile / nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM and the like. A hard disk drive can be connected to the system bus 821 through a non-removable memory interface such as an interface, and a magnetic disk drive or optical disk drive can be connected to the system bus 821 by a removable memory interface, such as an interface.

[0183] A user can enter commands and information into the computer 810 through input devices such as a keyboard or a pointing device such as a mouse, trackball, touch pad, and / or other pointing device. Other input devices can include a microphone, joystick, game pad, satellite dish, scanner, or similar devices. These and / or other input devices can be connected to the processing unit 820 through user input 840 and associated interface(s) that are coupled to the system bus 821 , but can be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).

[0184] A graphics subsystem can also be connected to the system bus 821 . In addition, a monitor or other type of display device can be connected to the system bus 821 through an interface, such as output interface 850, which can in turn communicate with video memory. In addition to a monitor, computers can also include other peripheral output devices, such as speakers and / or printing devices, which can also be connected through output interface 850.

[0185] The computer 810 can operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote server 870, which can in turn have media capabilities different from device 810. The remote server 870 can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and / or any other remote media consumption or transmission device, and can include any or all of the elements described above relative to the computer 810. The logical connections depicted in FIG. 8 include a network 871 , such as a local area network (LAN) or a wide area network (WAN), but can also include other networks / buses.

[0186] When used in a LAN networking environment, the computer 810 is connected to the LAN871 through a network interface or adapter. When used in a WAN networking environment, the computer 810 can include a communications component, such as a modem, or other means for establishing communications over a WAN, such as the Internet. A communications component, such as a modem, which can be internal or external, can be connected to the system bus 821 through the user input interface at input 840 and / or other appropriate mechanism.

[0187] In a networked environment, program modules depicted relative to the computer 810, or portions thereof, can be stored in a remote memory storage device. It should be noted that the network connections shown and described are exemplary and other means of establishing a communications link between the computers can be used.

[0188] The apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and / or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

[0189] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0190] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally. Additionally, it should be noted that as used in this application, terms such as “component,” “display,” “interface,” and other similar terms are intended to refer to a computing device, either hardware, a combination of hardware and software, software, or software in execution as applied to a computing device. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computing device. As an example, both an application running on a computing device and the computing device can be components. One or more components can reside within a process and / or thread of execution and a component can be localized on one computing device and / or distributed between two or more computing devices, and / or communicatively connected modules. Further, it should be noted that as used in this application, terms such as “system user,” “user,” and similar terms are intended to refer to the person operating the computing device referenced above.

[0191] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0192] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0193] It should also be noted that in some alternate implementations, the functions / acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Moreover, the functionality of a given block of the flowcharts and / or block diagrams may be separated into multiple blocks and / or the functionality of two or more blocks of the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks that are illustrated.

[0194] Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0195] Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, the present specification, including the drawings, shall be construed to constitute a complete written description of various exemplary combinations and subcombinations of embodiments and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

Claims

CLAIMS1. A method comprising: obtaining (1500) a system model (110) that represents assets (A) of a system (100) and paths (P) therebetween; enriching (1510) the system model (110) with security control metadata (120) that indicates, for each of one or more of the paths (P), one or more security controls (SC) that are to be implemented for securing the path (P); performing (1520), or retrieving (1520) results of, static security analysis (130) on artifacts associated with the system (100) to identify issues (140) with security of the system (100); for each of one or more paths (P) represented in the system model (110), calculating (1530) a score (160) that quantifies how secure the path (P) is against a subset of the identified issues (140) that are applicable to the path (P), based on which security controls (SC), if any, are to be implemented for securing the path (P) according to the enriched system model (110E); and adapting (1540), or assisting (1540) with adapting, design of the system (100) based on the score (160) calculated for one or more of the paths (P).

2. The method of claim 1 , wherein the security control metadata (120) comprises, for each of the one or more paths (P), a defense vector that includes security control attributes for different respective security controls (SC), with each security control attribute indicating whether or not a respective security control is to be implemented for securing the path.

3. The method of any of claims 1-2, wherein the score (160) for a path monotonically increases the more secure the path is against the subset of issues (140) that are applicable to the path.

4. The method of any of claims 1-3, wherein the score (160) for a path is calculated such that, for each issue (140) in the subset of issues (140) that are applicable to the path, a security control that secures against the issue (140) and is to be implemented for securing the path contributes positively to a value of the score (160).

5. The method of any of claims 1-4, wherein calculating a score (160) for a path comprises, for each issue (140) in the subset of issues (140) that are applicable to the path, calculating an issue-specific score that quantifies how secure the path is against that issue (140), based on which security controls (SC), if any, are to be implemented for securing thepath against that issue (140) according to the enriched system model (110E), and aggregating the issue-specific scores calculated for the path.

6. The method of claim 5, wherein calculating an issue-specific score for an issue (140) for a path comprises: for each of one or more candidate security controls (SC) that are candidates to be implemented for securing the path, calculating a control-specific score that quantifies an extent to which the candidate security control secures the path against the issue (140), as a function of whether the candidate security control is to be implemented for securing the path according to the enriched system model (110E); and aggregating the control-specific scores calculated for the issue (140) for the path.

7. The method of claim 6, wherein the control-specific score for a candidate security control is calculated also as a function a normalized weight specific to that candidate security control, wherein the normalized weight reflects a relative importance or criticality of the candidate security control in securing the path against the issue (140).

8. The method of any of claims 1 -7, wherein the obtained system model (110) is a structured metadata representation of the system (100), wherein obtaining the system model (110) comprises converting a diagrammatic or schematic representation of the system (100) into the structured metadata representation of the system (100) comprising metadata about each asset of the system (100) and metadata about each path in the system (100), and wherein said enriching comprises, for each of the one or more paths (P), enriching the metadata about the path with the security control metadata (120) for that path indicating which security controls (SC), if any, are to be implemented for securing the path.

9. The method of any of claims 1-8, wherein the artifacts associated with the system (100) include source code for the system (100), configuration files for the system (100), and / or the system model (110).

10. The method of any of claims 1 -9, wherein the issues (140) with security of the system (100) include: specific system vulnerabilities that are cataloged as known exploitable flaws; and / or generalized system weaknesses that are enumerated as common design or coding weaknesses.

11. The method of any of claims 1-10, wherein at least one of the one or more security controls (SC) is issue-agnostic and / or mitigates a security risk attributable to multiple types of security issues.

12. The method of any of claims 1-11 , further comprising, for each of one or more assets (A) represented in the system model (110), aggregating the scores (160) calculated for paths (P) to or from the asset in order to obtain an asset-level score that quantifies how secure the asset is against a subset of issues (140) applicable to the asset, and wherein said adapting or assisting with adapting is performed based on the one or more asset-level scores.

13. The method of claim 12, further comprising, for each of multiple assets (A) represents in the system model (110), aggregating respective asset-level scores calculated for the assets (A) in order to obtain a sub-system -level score that quantifies how secure a subsystem within the system (100) is and / or a system-wide score that quantifies how secure the system (100) as a whole is, and wherein said adapting or assisting with adapting is performed based on the sub-system -level score and / or the system-wide score.

14. The method of any of claims 1-13, further comprising performing, or retrieving results of, dynamic security analysis on the system (100) to identify issues (140) with the security of the system (100).

15. The method of any of claims 1-14, wherein said adapting, or assisting with adapting, comprises adapting, or assisting with adapting, which security controls (SC) are to be implemented for at least one path represented in the system model (110).

16. Computing equipment comprising processing circuitry (820) configured to: obtain a system model (110) that represents assets (A) of a system (100) and paths (P) therebetween; enrich the system model (110) with security control metadata (120) that indicates, for each of one or more of the paths (P), one or more security controls (SC) that are to be implemented for securing the path; perform, or retrieve results of, static security analysis (130) on artifacts associated with the system (100) to identify issues (140) with security of the system (100); for each of one or more paths (P) represented in the system model (110), calculate a score (160) that quantifies how secure the path is against a subset of the identified issues (140) that are applicable to the path, based on which securitycontrols (SC), if any, are to be implemented for securing the path according to the enriched system model (110E); and adapt, or assist with adapting, design of the system (100) based on the score (160) calculated for one or more of the paths (P).

17. The computing equipment of claim 16, wherein the processing circuitry (820) is configured to perform the method of any of claims 2-15.

18. A computer program comprising instructions which, when executed by at least one processor of computing equipment, causes the computing equipment to perform the method of any of claims 15.

19. A carrier containing the computer program of claim 18, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Images