LIVE THREAT MODELING FRAMEWORK

An example computer system for live threat modeling for an enterprise can include: one or more processors; and non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to: prepare abstracts for applications associated with the enterprise to form a threat model; monitor development phases of the applications; and apply the threat model to the applications during each of the development phases to identify risk.

BACKGROUND

Threat modeling enables informed decision-making about application security risks associated with software. Such modeling can include creation of a prioritized list of security improvements to the design and implementation of applications. However, the security risks for applications are always evolving, which makes it difficult to prioritize and maintain a current state for the threat modeling.

SUMMARY

Examples provided herein are directed to a live threat modeling framework.

According to aspects of the present disclosure, an example computer system for live threat modeling for an enterprise can include: one or more processors; and non-transitory computer-readable storage media encoding instructions which, when executed by the one or more processors, causes the computer system to: prepare abstracts for applications associated with the enterprise to form a threat model; monitor development phases of the applications; and apply the threat model to the applications during each of the development phases to identify risk.

DETAILED DESCRIPTION

This disclosure relates to a live threat modeling framework.

In the examples provided herein, the framework can be used by an enterprise to execute enterprise threat modeling processes, procedures and standards which are automatically updated. In these examples, the live threat modeling is automated as much as possible.

In the examples provided herein, the live threat modeling framework can focus on assessing applications within the enterprise to model the threats associated with those applications. This can include using the framework to analyze the possible impact of the threats, the potential severity of the threats, and/or mitigation strategies to reduce the threat surface via continuous refinement during design, build and deployment phases of the development of the applications. Further, the framework can be used to discover threats from external sources.

The example live threat modeling framework can be aligned with6S, which is a system that promotes safety throughout the enterprise. In this system, the framework can exhibit one or more of the following characteristics.

Scalability: early security architecture review that can be repeatable, consistent, efficient, and compliant.

Security: provides as part of product design and frequency-based and ad-hoc measures, addressing various types of threats.

Stability: tailored to a hybrid approach that addressed both on-premises and cloud-based infrastructure.

Speed: uses tools that are automated where possible, semi-automated and/or sometimes manual to identify, catalog, and mitigate live threats to the enterprise.

FIG.1schematically shows aspects of one example system100for an enterprise. The enterprise can be any type of business. In one non-limiting example, the enterprise is a financial institution that provides financial services to customers. However, the concepts described herein are equally applicable to other types of entities.

Generally, the system100includes a live threat modeling framework, which is described further below. The system100can include a plurality of client devices102,104,106and a server device112. The client devices102,104,106communicate with the server device112to accomplish business tasks.

Each of the client devices102,104,106and the server device112may be implemented as one or more computing devices with at least one processor and memory. Example computing devices include a mobile computer, a desktop computer, a server computer, or other computing device or devices such as a server farm or cloud computing used to generate or receive data.

In the examples shown, the client devices102,104,106can be used by customers or employees of the enterprise to conduct business. The client devices102,104,106can communicate with the server device112through a network110.

For instance, the example client device102can be programmed to design applications for products of the enterprise. The example client device104can be programmed to build those applications for the products of the enterprise. The example client device106can be programmed to deploy the applications for the products of the enterprise. Many other configurations for the client devices102,104,106are possible.

The server device112can be programmed to deliver functionality to the client devices102,104,106. For example, in one embodiment, the server device112is formed by one or more computers (typically a server farm or part of a cloud computing environment) that facilitates the various business processes of the enterprise, including the design, build, and deployment phases of the various applications for the products of the enterprise.

As depicted, the system100also includes a threat modeling device114that provides live threat modeling. More specifically, the threat modeling device114is generally programmed to develop and maintain a live threat model framework for the system100.

In this regard, the threat modeling device114is programmed to monitor threats associated with the applications that are designed, built, and deployed for the products of the enterprise. This can include development of abstracts of the applications to form the live threat model(s). An abstract can define such aspects as: (i) build information for the application, such as code type, versioning, etc.; (ii) functionality associated with the application; (iii) dependencies associated with the application; etc.

The example threat modeling device114can also be programmed to identify live threat information and apply that information to the abstracts of the applications in the threat model for the enterprise. For instance, the threat modeling device114can identify threats in near real-time and apply those threats to the applications of the enterprise. This allows the threat modeling device114to adapt as the threats evolve. This can also involve capturing incremental changes to the applications and threats and identifying risks associated therewith.

For example, the threat modeling device114can include or more databases that house threat models for the applications of the enterprise. As information regarding threats is obtained, that information can be stored in models within the database and automatically updated in near-real time, such as every minutes, every hour, etc. This allows the threat modeling device114to access the updated threat models and apply them to the applications during the lifecycle of the application, including design, build, and deployment phases.

For instance, the threat modeling device114can be programmed to consume threat information from different sources. Such sources can be structured in various manners such as, without limitation, according to the Open Worldwide Application Security Project and/or the Cybersecurity Framework from the National Institute of Standards and Technology.

In one example, the threat modeling device114is application programming interface (API) driven, so that the threat modeling device114can access live threat information through APIs. Such a configuration is provided in U.S. patent application Ser. No. 18/456,777, Attorney Docket No. 15896.0375US01, filed on Aug. 28, 2023, the entirety of which is hereby incorporated by reference.

In addition, the threat modeling device114can assist in remediation and reporting associated with the threats for the enterprise. For example, once a threat is identified, the threat modeling device114can be programmed to use standard and/or custom tools or catalogs for the system100to address the threat. For instance, the threat modeling device114can be programmed to access patches available from vendors to address the threats. Many other configurations are possible.

In the examples provided below, the threat modeling device114can be integrated into the system100, such as in a cloud computing environment that allows the threat modeling device114to communicate with the computing devices associated with the enterprise. This can include automation of the threat modeling device114, so that the functionality described with reference toFIG.2can be automated.

Referring now toFIG.2, additional details on the threat modeling device114are provided. In this example, the threat modeling device114includes a design engine202, a build engine204, and a deployment engine206.

The example design engine202is programmed to receive input from various applications used to develop the applications that are implemented in the products of the system100for the enterprise. For instance, the design engine202is programmed to interface with the client device102, which can be used by a product owner, developer, and/or engineer who designs products for the system100. The design engine202can be programmed to receive information associated with the design of the products, including the creation and modification of source code stored in a GitHub associated with the enterprise during the design of one or more applications.

For instance, the design engine202can monitor the design of new and existing applications and continually update the abstract associated with the application in the threat model as the application is designed. As functionality associated with the application is designed and modified, the design engine202monitors the design in near real-time to identify and potentially mitigate threats.

The example build engine204is programmed to monitor the building of the applications for the products of the enterprise, including resources to compile and execute the source code. This can include services like building, inspecting, publishing, and scanning of the code in conjunction with the creation of the applications. As the applications are built, the build engine204monitors the builds in near real-time to identify and potentially mitigate threats.

The example deployment engine206is programmed to monitor the deployment of the applications for the products of the enterprise. This can include services like moving the applications for the various products into a production environment and the integration thereof, including Unix, iOS, and/or Android. As the applications are deployed, the deployment engine206monitors the deployments in near real-time to identify threats.

The threat modeling device114can be programmed to perform this functionality in various manners. For instance, the design engine202can monitor as code is being written and identify (e.g., highlight) sections of code that might be vulnerable to threats. Similarly, the build engine204can be programmed to identify sections of code that may be vulnerable when code is checked into and/or compiled by the server device112. Further, the deployment engine206can be programmed to flag an application that is vulnerable once the application is deployed and/or executed in the production environment.

In alternative embodiments, the threat modeling device114can embed the artificial intelligence capabilities to identity threats based on patterns identified on client devices102,104,106or server device112. Many other configurations are possible.

Referring now toFIG.3, an example dashboard300that can be generated by the threat modeling device114is shown. In this example, the dashboard300is programmed to report on the live threat modeling for the system100of the enterprise. Further, the dashboard300can be configurable to display information that is relevant to a user of the dashboard300, such as a product owner, manager, or cybersecurity analysist.

In this example, the dashboard300includes various selection menus302,304,306that modify the threat information that is displayed on a live threat module308. In this manner, the dashboard300can be tailored to provide information that is relevant to the user.

For instance, the menu302allows for receipt of selection between various lines of business for the enterprise. For instance, one or more of the lines of business are selectable, and the threat information in the live threat module308is modified to provide information on the threats associated with the applications/products for the selected lines of business. Similarly, specific products are selectable using the menu306, and the threat information in the live threat module308is modified to provide information on the threats associated with the selected applications/products.

Further, the menu304allows for selection of the desired phases associated with the design, building, and deployment phases of the applications. For instance, each phase is selectable to modify the information on the threats provided by the live threat module308to correspond to the selected phases.

The live threat module308provides a summary of the status of the threats associated with the system100based upon the selections provided by the menus302,304,306. In example embodiments, the live threat module308is programmed to provide a real-time assessment of the live threats for the system100. The live threat module308can be updated automatically based upon the selections in the menus302,304,306and the changing environment associated with the system100.

For instance, the live threat module308can display the products/applications that currently are vulnerable based upon the threats that exist within the live threat model. Products that have been recently patched and threats that are unmitigated can also be included in the live threat module308. Finally, a list of new threats that have been recently identified can be provided on the live threat module308. Many other configurations and information can be provided.

As illustrated in the embodiment ofFIG.4, the example threat modeling device114can include at least one central processing unit (“CPU”)402, a system memory408, and a system bus422that couples the system memory408to the CPU402. The system memory408includes a random access memory (“RAM”)410and a read-only memory (“ROM”)412. A basic input/output system containing the basic routines that help transfer information between elements within the threat modeling device114, such as during startup, is stored in the ROM412. The threat modeling device114further includes a mass storage device414. The mass storage device414can store software instructions and data. A central processing unit, system memory, and mass storage device similar to that inFIG.4are also included in other computing devices disclosed herein (e.g., the devices102,104,106,112).

The mass storage device414is connected to the CPU402through a mass storage controller (not shown) connected to the system bus422. The mass storage device414and its associated computer-readable data storage media provide non-volatile, non-transitory storage for the threat modeling device114. Although the description of computer-readable data storage media contained herein refers to a mass storage device, such as a hard disk or solid-state disk, it should be appreciated by those skilled in the art that computer-readable data storage media can be any available non-transitory, physical device, or article of manufacture from which the central display station can read data and/or instructions.

According to various embodiments of the invention, the threat modeling device114may operate in a networked environment using logical connections to remote network devices through network110, such as a wireless network, the Internet, or another type of network. The threat modeling device114may connect to network110through a network interface unit404connected to the system bus422. It should be appreciated that the network interface unit404may also be utilized to connect to other types of networks and remote computing systems. The threat modeling device114also includes an input/output controller406for receiving and processing input from a number of other devices, including a touch user interface display screen or another type of input device. Similarly, the input/output controller406may provide output to a touch user interface display screen or other output devices.

As mentioned briefly above, the mass storage device414and the RAM410of the threat modeling device114can store software instructions and data. The software instructions include an operating system418suitable for controlling the operation of the threat modeling device114. The mass storage device414and/or the RAM410also store software instructions and applications424, that when executed by the CPU402, cause the threat modeling device114to provide the functionality of the threat modeling device114discussed in this document.