US-12619710-B2 - Securing software architectures with threat models

Abstract

Methods and systems for securing software architectures are disclosed. The software architectures may be secured through the implementation of threat models. The threat models may include design threat models that indicate vulnerabilities that software based on an architecture may exhibit, and build threat models that indicate vulnerabilities of implementation of the software based on the architecture may exhibit. The threat models may be used to select where and how to deploy software to limit exploitable vulnerabilities to be within acceptable levels.

Inventors

• Igor Dubrovsky
• Boris Shpilyuck
• Maxim Balin
• Nisan Haimov

Assignees

• DELL PRODUCTS L.P.

Dates

Publication Date

20260505

Application Date

20230828

Claims (20)

1. 1 . A method for securing software architectures, the method comprising: obtaining an architecture for a software; analyzing the architecture to obtain a first quantification regarding first vulnerabilities presented by the architecture using at least one security standard; obtaining a design threat model for the architecture using the first vulnerabilities; obtaining an implementation of the software; analyzing the implementation of the software to obtain a second quantification regarding second vulnerabilities presented by the implementation of the software; obtaining a build threat model for the implementation of the software using the second vulnerabilities; identify the software for deployment to a data processing system; based on the identifying of the software: identifying a final threat model for the software, the final threat model being based on the design threat model for the architecture for the software and on the build threat model for the implementation of the software; defining an environment to which the software will be deployed using the final threat model to obtain an environment definition; and deploying the software to an instance of the environment hosted by the data processing system using the environment definition.
2. 2 . The method of claim 1 , further comprising: prior to identifying the software for the deployment to the data processing system, and after obtaining the design threat model: analyzing the design threat model and the build threat model to obtain a third quantification regarding a difference between the first vulnerabilities and the second vulnerabilities using the first quantification and the second quantification; in a first instance of the analyzing of the design threat model and the build threat model where the third quantification is in a third acceptable range: obtaining the final threat model using the design threat model and the build thread threat model; and in a second instance of the analyzing of the design threat model and the build threat model where the third quantification is outside of the third acceptable range: initiating revision of the architecture and/or the implementation.
3. 3 . The method of claim 2 , wherein obtaining the design threat model for the architecture comprises: identifying a first deviation of the architecture from the at least one security standard; identifying at least one vulnerability associated with the first deviation; and adding the at least one vulnerability associated with the first deviation to the design threat model.
4. 4 . The method of claim 3 , wherein obtaining the build threat model for the implementation of the software comprises: identifying a second deviation of the implementation from the at least one security standard; identifying at least one vulnerability associated with the second deviation; and adding the at least one vulnerability associated with the second deviation to the build threat model.
5. 5 . The method of claim 4 , wherein analyzing the design threat model and the build threat model to obtain the third quantification regarding the difference between the first vulnerabilities and the second vulnerabilities comprises: enumerating the first vulnerabilities specified by the design threat model to obtain a first enumeration of vulnerabilities; enumerating the second vulnerabilities specified by the build threat model to obtain a second enumeration of vulnerabilities; obtaining a list of vulnerabilities introduced by the implementation using the first enumeration and the second enumeration; and obtaining the third quantification using the list of vulnerabilities and a vulnerability scoring system.
6. 6 . The method of claim 5 , wherein obtaining the list of vulnerabilities comprises: removing, from the second enumeration, each of the vulnerabilities listed in the first enumeration, to obtain the list of vulnerabilities.
7. 7 . The method of claim 1 , wherein the final threat model is further based on at least one scoring system, the scoring system defining how quantifications for the first vulnerabilities due to the architecture are calculated.
8. 8 . The method of claim 7 , wherein the final threat model is further based on the first vulnerabilities due to the architecture and the second vulnerabilities due to the implementation.
9. 9 . The method of claim 8 , wherein the first vulnerabilities and the second vulnerabilities define when the software is acceptable for deployment to the data processing system.
10. 10 . A non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for securing software architectures, the operations comprising: obtaining an architecture for a software; analyzing the architecture to obtain a first quantification regarding first vulnerabilities presented by the architecture using at least one security standard; obtaining a design threat model for the architecture using the first vulnerabilities; obtaining an implementation of the software; analyzing the implementation of the software to obtain a second quantification regarding second vulnerabilities presented by the implementation of the software; obtaining a build threat model for the implementation of the software using the second vulnerabilities; identify the software for deployment to a data processing system; based on the identifying of the software: identifying a final threat model for the software, the final threat model being based on the design threat model for the architecture for the software and on the build threat model for the implementation of the software; defining an environment to which the software will be deployed using the final threat model to obtain an environment definition; and deploying the software to an instance of the environment hosted by the data processing system using the environment definition.
11. 11 . The non-transitory machine-readable medium of claim 10 , further comprising: prior to identifying the software for the deployment to the data processing system, and after obtaining the design threat model: analyzing the design threat model and the build threat model to obtain a third quantification regarding a difference between the first vulnerabilities and the second vulnerabilities using the first quantification and the second quantification; in a first instance of the analyzing of the design threat model and the build threat model where the third quantification is in a third acceptable range: obtaining the final threat model using the design threat model and the build threat model; and in a second instance of the analyzing of the design threat model and the build threat model where the third quantification is outside of the third acceptable range: initiating revision of the architecture and/or the implementation.
12. 12 . The non-transitory machine-readable medium of claim 11 , wherein obtaining the design threat model for the architecture comprises: identifying a first deviation of the architecture from the at least one security standard; identifying at least one vulnerability associated with the first deviation; and adding the at least one vulnerability associated with the first deviation to the design threat model.
13. 13 . The non-transitory machine-readable medium of claim 12 , wherein obtaining the build threat model for the implementation of the software comprises: identifying a second deviation of the implementation from the at least one security standard; identifying at least one vulnerability associated with the second deviation; and adding the at least one vulnerability associated with the second deviation to the build threat model.
14. 14 . The non-transitory machine-readable medium of claim 10 , wherein the final threat model is further based on at least one scoring system, the scoring system defining how quantifications for first vulnerabilities due to the architecture are calculated.
15. 15 . The non-transitory machine-readable medium of claim 14 , wherein the final threat model is further based on the first vulnerabilities due to the architecture and the second vulnerabilities due to the implementation.
16. 16 . A data processing system, comprising: a processor; and a memory coupled to the processor to store instructions, which when executed by the processor, cause the processor to perform operations securing software architectures, the operations comprising: obtaining an architecture for a software; analyzing the architecture to obtain a first quantification regarding first vulnerabilities presented by the architecture using at least one security standard; obtaining a design threat model for the architecture using the first vulnerabilities; obtaining an implementation of the software; analyzing the implementation of the software to obtain a second quantification regarding second vulnerabilities presented by the implementation of the software; obtaining a build threat model for the implementation of the software using the second vulnerabilities; identify the software for deployment to the data processing system; based on the identifying of the software: identifying a final threat model for the software, the final threat model being based on the design threat model for the architecture for the software and on the build threat model for the implementation of the software; defining an environment to which the software will be deployed using the final threat model to obtain an environment definition; and deploying the software to an instance of the environment hosted by the data processing system using the environment definition.
17. 17 . The data processing system of claim 16 , further comprising: prior to identifying the software for the deployment to the data processing system, and after obtaining the design threat model: analyzing the design threat model and the build threat model to obtain a third quantification regarding a difference between the first vulnerabilities and the second vulnerabilities using the first quantification and the second quantification; in a first instance of the analyzing of the design threat model and the build threat model where the third quantification is in a third acceptable range: obtaining the final threat model using the design threat model and the build threat model; and in a second instance of the analyzing of the design threat model and the build threat model where the third quantification is outside of the third acceptable range: initiating revision of the architecture and/or the implementation.
18. 18 . The data processing system of claim 17 , wherein obtaining the design threat model for the architecture comprises: identifying a first deviation of the architecture from the at least one security standard; identifying at least one vulnerability associated with the first deviation; and adding the at least one vulnerability associated with the first deviation to the design threat model.
19. 19 . The data processing system of claim 18 , wherein obtaining the build threat model for the implementation of the software comprises: identifying a second deviation of the implementation from the at least one security standard; identifying at least one vulnerability associated with the second deviation; and adding the at least one vulnerability associated with the second deviation to the build threat model.
20. 20 . The data processing system of claim 16 , wherein the final threat model is further based on at least one scoring system, the scoring system defining how quantifications for first vulnerabilities due to the architecture are calculated.

Description

FIELD Embodiments disclosed herein relate generally to threat modeling. More particularly, embodiments disclosed herein relate to securing software architectures and implementations through threat models. BACKGROUND Computing devices may provide computer-implemented services. The computer-implemented services may be used by users of the computing devices and/or devices operably connected to the computing devices. The computer-implemented services may be performed with hardware components such as processors, memory modules, storage devices, and communication devices. The operation of these components and the components of other devices may impact the performance of the computer-implemented services. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments disclosed herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. FIG. 1 shows a diagram illustrating a system in accordance with an embodiment. FIG. 2A shows a first data flow diagram illustrating operation of a portion of a system in accordance with an embodiment. FIG. 2B shows a second data flow diagram illustrating operation of a portion of a system in accordance with an embodiment. FIG. 2C shows a second data flow diagram illustrating operation of a portion of a system in accordance with an embodiment. FIG. 3A shows a flow diagram illustrating a method of deploying a software with a final threat model to an environment in accordance with an embodiment. FIG. 3B shows a flow diagram illustrating a method of obtaining a design threat model for a software architecture in accordance with an environment. FIG. 3C shows a flow diagram illustrating a method of developing a final threat model from a design threat model and a build threat model in accordance with an embodiment. FIG. 4 shows a block diagram illustrating a data processing system in accordance with an embodiment. DETAILED DESCRIPTION Various embodiments will be described with reference to details discussed below, and the accompanying drawings will illustrate the various embodiments. The following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of various embodiments. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of embodiments disclosed herein. Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in conjunction with the embodiment can be included in at least one embodiment. The appearances of the phrases “in one embodiment” and “an embodiment” in various places in the specification do not necessarily all refer to the same embodiment. References to an “operable connection” or “operably connected” means that a particular device is able to communicate with one or more other devices. The devices themselves may be directly connected to one another or may be indirectly connected to one another through any number of intermediary devices, such as in a network topology. In general, embodiments disclosed herein relate to methods and systems for securing software to limit exploitation of vulnerabilities. To limit the exploitation of the vulnerabilities, a threat model based on an architecture and implementation of a software may be obtained. The threat models may be based on deviations of the architecture and implementation from security standards for the software. The threat models may be used to qualify the software for various uses. For example, different entities may be willing to accept lesser or greater numbers of exploitable vulnerabilities in deployed software. Additionally, the threat models may be used to limit the extent to which vulnerabilities may be exploited in deployed instances of software. For example, the threat models may be used to select where and how to deploy the software to limit the ability of vulnerabilities to be exploited. By doing so, software that may not otherwise meet security standards for an organization may be placed into acceptable condition by reduce the ability of the vulnerabilities from being exploited. In an embodiment, a method securing software architectures is provided. The method may include (i) identifying software for deployment to a data processing system, (ii) based on the identifying of the software: (a) identifying a final threat model for the software, the final threat model being based on an architecture for the software and an implementation of the software; (b) defining an environment to which the software will be deployed using the final threat model to obtain an environment definition; and (c) deploying the software to an instance of the environment hosted by the data processing system using the environment definition. The method may further include, prior to identifying the software for the