Patent Application
20200125342
The disclosure generally relates to the field of information security, and more particularly to modeling, design, simulation, or emulation.
Risk assessment generally requires specialised domain knowledge across the information technology arena, as well as highly advanced security specific knowledge in the same domain. Performing a complete and reliable risk assessment process can impose high costs in terms of budget and resources. It is not merely the financial cost of a resource but the availability of resources with risk management skills that often relegates risk management to a poorly understood and poorly implemented part of any software application development and deployment.
Moreover, applications have become important components for businesses in many sectors. The technical complexity of software applications can increase the probability that some critical non-functional requirements might be missed in the risk assessment process for these applications. This aggravates the need for expert resources that can perform the risk assessment.
Many times, project goals focus on delivering new functionality upon each release. This emphasis decreases the visibility of risk management in a project. Further, the emphasis on delivering new functionality can potentially increases the opportunity for missed requirements, the difficulty in evaluating the risks and in selecting or designing the most suitable risk mitigation approach. Furthermore, the required expertise together with the lack of understanding of the prominence of risk management of results in rushing, or even omitting risk management for an application. The risk management process may, in many cases, be performed in absence of critical expertise leading to ineffective and inaccurate analysis. This is due to the fact that risk analysis is usually not considered a task of software developer, making the risk management process even more challenging.
Aspects of the disclosure may be better understood by referencing the accompanying drawings.
The description that follows includes example systems, methods, techniques, and program flows that embody aspects of the disclosure. However, it is understood that this disclosure may be practiced without these specific details. For instance, this disclosure refers to risks and risk mitigations in illustrative examples. Aspects of this disclosure can be applied to other attributes of applications such as performance aspects, resource usage aspects, business impact aspects such as trustworthiness, reputation, legal compliance etc. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.
Overview
A system for application development includes a predictor that can report a probable set of risks (e.g., security risks, financial risks, legal risks etc.) and risk mitigations for software development or deployment risk management. The system records user activity with respect to assigning risks and risk mitigations to application components. The system utilizes user inputs and characteristics of the modelled application as well as the user inputs and characteristics associated with past development and deployment of similar applications in order to predict a probable set of risks and/or risk mitigation actions.
The risks and risk mitigations can be based on a predefined set of possible risks and risk mitigations. For example, in some aspects, the risks can comprise security threats and security controls. The set of security threats and security controls can be based on a set of security threats defined by the National Institute of Standards and Technology (NIST) Cybersecurity Framework. The NIST framework includes the following families of security controls:
AC—Access Control
AU—Audit and Accountability
AT—Awareness and Training
CM—Configuration Management
CP—Contingency Planning
IA—Identification and Authentication
IR—Incident Response
MA—Maintenance
MP—Media Protection
PS—Personnel Security
PE—Physical and Environmental Protection
PL—Planning
PM—Program Management
RA—Risk Assessment
CA—Security Assessment and Authorization
SC—System and Communications Protection
SI—System and Information Integrity
SA—System and Services Acquisition
Each family has a set of particular security controls. The NIST framework includes a definition of the security control and a measuring technique on how the security control should be fulfilled. The individual controls within the above-identified families can be applied to various risks associated with application components.
Other application risk management frameworks can be used in addition to, or instead of, the NIST Cybersecurity Framework. Examples of such other frameworks include the STRIDE Threat Model developed by Microsoft Corporation; Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology developed by the Software Engineering Institute of Carnegie Mellon University; and Open Web Application Security Project (OWASP). The embodiments are not limited to any particular risk definition and control framework.
Workflow manager 102 can include a user interface 122 that provides user interface elements that a user can utilize to interact with the system. For example, user interface 122 can provide user interface elements allowing a user to add and remove components of an application, configure the application and components of the application, associate risks and risk mitigation actions to applications and components etc. In some aspects, user interface 122 can represent a Kanban-style board utilized by members of a development team to visually assess the status and progress of an application and its components. As one example of a Kanban-style interface, user interface 122 can present a swimlane style dashboard that guides the user through the software development, deployment, and risk management process. Those of skill in the art having the benefit of the disclosure will appreciate that other styles of user interfaces can be utilized to maintain and present information about a software application during its development and deployment. Further, user interface 122 can present output generated by other modules of the system such as the analyzer 108, and predictor 110.
User behavior data collector 104 can collect information associated with actions performed by a user of the system. For example, when a user performs an action via user interface 122, the user behavior data collector 104 can receive an indication of the action, and collect information associated with the action. Examples of such information include inputs associated with the action (e.g., component type, name etc.), additions or changes to a set of risk characteristics for a component, indicators of additions and indicators of changes to risk mitigations associated with the risk characteristics for the component, and timestamps of the action. The indicators of user actions and information associated with the actions can be stored in a persistent storage 106 as user behavior data 120.
Persistent storage 106 can store information used by the components of system 100. In addition to the user behavior data 120, persistent storage 106 can store a component library 118 of components that are available for use by, or association with, applications or components currently under development. Persistent storage 106 can also store application models 116 created by analyzer 108. Further, persistent storage 106 can store a risk catalogue 130 and a risk mitigation catalogue 132. As an example, a set of risks such as the security threats and security controls defined by NIST (described above) can be stored in risk catalogue 130. Further, a set of risk mitigations such as security controls defined by NIST can be stored as risk mitigation catalogue 132. The risk mitigation catalogue 132 can be used by user interface 122 to present a set of risk management options to a user. Although shown as one unit in
Analyzer 108 can receive information from persistent storage unit 106 and use the information to generate one or more models. In some aspects, the models can include an application model 116, user choices model 112, and/or user behavior model 114. These models can be used to predict risks and risk mitigations for components. Analyzer 108 can include a machine learning engine 124 that can receive information about an application model 116 and user behavior data 120 to generate a user choices model 112. The user choices model 112 can include data that indicates the choices a user has made with respect to risks associated with the components from component library 118 that are included in an application, and risk mitigations associated with the risks. The data in user choices model 112 can define relationships between components, risks, and risk mitigations. Further, analyzer 108 can include a process mining engine 126 to generate a user behavior model 114. In some aspects, analyzer 108 can incorporate timestamp data or development phase data into models 112 and 114. The timestamp data or development phase data can be considered when providing predictions of risks and suggestions of risk mitigations.
Predictor 110 can receive data from analyzer 108 and use the data to generate a prediction for a component, including a component under development by a user. As an example, predictor 110 can receive a user choices model 112 that indicates the past choices that developers have made with respect to risks and risk mitigations for previously developed application components. The predictor 110 can then provide the generated prediction to a software developer via the user interface 122.
In some aspects, system 100 can include a deviation detector 128. Deviation detector 128 can analyze an application and its respective components and determine whether the risks and risk mitigations for the components of the application include any deviations from risks and risk mitigations associated with similar components of other previously developed applications. The deviation detector can provide a report of any detected deviations via the user interface 122.
The component data object 202 can include data elements describing an application component. As used herein, a component of an application can include software components as well as elements that are not software, but provide information about an application. For example, a component can describe features of an application. One example of such a component is a “user story” as commonly used in Agile software development environments. A user story can be a component that provides a description of a software feature from the perspective of an end-user. As an example, a user story may be text that states “As a user, I can indicate folders not to backup so my backup drive isn't filled with files I don't need saved.” A further example of a non-software component can be an element that lists or describes features of an application.
The component data object 202 can include a component identifier (ID) 204, a component description 206, and a component type 208. The component ID 204 can be a name of a component. The component description 206 can include text describing the functionality or other aspects of the component. For software components, the component description can include descriptions of any inputs and outputs of the component. The component type 208 provides a type associated with the component. For example, the component type may indicate that the component is a web service component, a database component, a user interface component, a queuing component, logging component, authentication component, group policy component, auditing component, a user story, a feature list etc. Those of skill in the art having the benefit of the disclosure will appreciate that the a component type can be associated with any component that carries out application logic or describes features and uses of an application.
A risk data object 210 can include data elements describing a risk that can be associated with an application component data object 202. In some aspects, the risk can be a security threat. In alternative aspects, the risk can be a financial risk, a legal compliance risk, a reputational risk, a performance risk, or a resource usage risk. The inventive subject matter is not limited to any particular type of risk. The risk data object 210 can include a risk ID 212, a risk description 214, a risk factor 216, a timestamp 218, and a development phase 219. The risk ID 212 is a label identifying the risk data object 210. The label can be a name of the risk or other identifying label associated with a risk. Risk description 214 can be text describing the risk. Risk factor 216 can be a calculated risk assessment associated with the risk. In some aspects, the risk factor 216 can be calculated based on a likelihood that the risk will occur and an impact that the risk has should it occur. For example, the risk factor 216 value can be calculated according to the formula:
Risk Factor=Likelihood*Impact
The values for likelihood and the impact can be based on values assigned by one or more users of the system. Development phase 219 identifies the development phase that a component was in when the risk was associated with the component. Development phase 219 can be a label for a development phase associated with the component. For example, a development phase for a component can be analysis, design, development, testing or deployment. Timestamp 218 can be a timestamp indicating the date and time that the risk was associated with the component. In some aspects, the development phase can be derived from timestamp 218.
Risk mitigation data object 220 can include data elements describing a risk mitigation that is applied to mitigate an associated risk. As an example, in aspects where the risk is a security threat, the risk mitigation can be a security control associated with the risk. The risk mitigation data object 220 can include a risk mitigation ID 222, a risk mitigation description 224, a timestamp 226 and a development phase 228. Risk mitigation ID 222 is a label assigned to the risk mitigation. The label can be a label defined by a framework such as the NIST Cybersecurity Framework. The risk mitigation description 224 can be text describing aspects of the risk mitigation. Development phase 228 identifies the development phase that a component was in when the risk mitigation was associated with the risk. Timestamp 226 can be a timestamp indicating the date and time that the risk mitigation was associated with the risk. In some aspects, development phase 228 can be derived from timestamp 226.
It should be noted that the component data object 202, the risk data object 210, and the risk mitigation data object 220 can include other data elements that have not been shown in
In some aspects, the indicators of user actions can include indications of inputs provided at development process steps (e.g. component type, description etc.), changes in the chosen set of risk characteristics and mitigation actions associated with an application component (e.g., risks and risk mitigations), and timestamps associated with the actions.
At block 304, the system can store the indicators of user actions in a persistent storage.
At block 306, an application risk management system can determine links between application components, risks, and risk mitigations based on the stored history of user actions in the persistent storage. In some aspects, the risks and risk mitigations can be those defined by a risk catalogue and risk mitigation catalogue.
At block 308, an analyzer of an application risk management system can generate a model based on the links between application components, risks, and risk mitigations. In some aspects, the model can be a user choices model that includes data linking the components of an application, linking risks with the components, and linking risk mitigations with the risks. Thus, the model represents the components used by applications, the risks associated with the components, and any risk mitigation actions associated with the risks. The analyzer can assign values to the links between the components, risks, and risk mitigations. For instance, the analyzer can determine the number of times a particular component is used with another component in applications. The greater the number of times a component is used with the other component, the higher the value of the link. Similarly, the analyzer can determine the number of times a particular risk has been associated with a component by application developers. The value of the link between the component and the risk can be determined based on the number of times the risk was associated with the application component. Likewise, the value of a link between a risk and a risk mitigation can be based on the number of times the risk mitigation was applied to the risk. An example user choices model is presented below in
In alternative aspects, the model can be a user behavior model that is created via process mining. The process mining can use the timestamps and/or development phases associated with risks and risk mitigations to represent how and when in the development process users have used the application risk management system to associate risks with components and how and when risk mitigations were associated with the risks.
At block 310, the application risk management system can compare the attributes of an application component being accessed by a developer with attributes of applications components in the model determined at block 308. The application component can be a component under development, under testing, or deployed. As an example, the application risk management system can compare the application component type of a component under development with types associated with application components in a user choices model. Further, the application risk management system can compare a description of the component under development with descriptions of components in the user choices model. Also, the application risk management system can compare the components associated with the component under development with components associated in the model.
At decision block 312, the application risk management system determines if the application component is a match to an application component in the model. For example, a match may be determined to occur if the components' types match. Further, the components may be determined to be a match if the components' descriptions match to a sufficient degree. If the components do not match, then the method ends.
If the components do match, then at block 314, the application risk management system generates a set of risks based on the risks associated with the matching component or components in the model.
At block 316, a predictor of the application risk management system can provide one or more of the generated set of risks to a developer as suggested risks for the component being accessed by the developer. The suggested risks can be based on the values of the links between the matching component in the model and its associated risks. Similarly, the predictor can provide suggested risk mitigations for the risks based on the values of the links between the risks of the matching application component in the model and the risk mitigations associated with the risks. Further, the predictor can provide suggested risks and risk mitigations based on the likelihood and severity (as determined via the risk factor). The predictor can provide the suggested risks and risk mitigations via a user interface 122 (
In some aspects, a development phase or timestamp can be used to determine when a risk or risk mitigation is suggested to a user. For example, the analyzer can determine when in the development process a particular risk or risk mitigation was previously associated with a component. The risk or risk mitigation can be suggested to a user when the component that the user is working on is at the same development phase or at a similar time in development as the matching component.
Thus, as can be seen from the user choices model, the system can determine:
Those of skill in the art having the benefit of the disclosure will appreciate that a typical user choices model can have many more application components, risks, and risk mitigations than those illustrated in
Variations
As described above, a predictor can be used along with application component models to provide a prediction to a software developer as to the risks and risk mitigations that the software developer may desire to apply to an application component. In further aspects, the above-described application risk assessment system can be used determine deviations in risks and risk mitigations from that predicted by a model. For example, a deviation detector 128 (
The flowcharts are provided to aid in understanding the illustrations and are not to be used to limit scope of the claims. The flowcharts depict example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable machine or apparatus.
As will be appreciated, aspects of the disclosure may be embodied as a system, method or program code/instructions stored in one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” The functionality presented as individual modules/units in the example illustrations can be organized differently in accordance with any one of platform (operating system and/or hardware), application ecosystem, interfaces, programmer preferences, programming language, administrator preferences, etc.
Any combination of one or more machine readable medium(s) may be utilized. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable storage medium may be, for example, but not limited to, a system, apparatus, or device, that employs any one of or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology to store program code. More specific examples (a non-exhaustive list) of the machine readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine readable storage medium is not a machine readable signal medium.
A machine readable signal medium may include a propagated data signal with machine readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine readable signal medium may be any machine readable medium that is not a machine readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a machine readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as the Java® programming language, C++ or the like; a dynamic programming language such as Python; a scripting language such as Perl programming language or PowerShell script language; and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a stand-alone machine, may execute in a distributed manner across multiple machines, and may execute on one machine while providing results and or accepting input on another machine.
The program code/instructions may also be stored in a machine readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
While the aspects of the disclosure are described with reference to various implementations and exploitations, it will be understood that these aspects are illustrative and that the scope of the claims is not limited to them. In general, techniques for application risk management as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.
Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure. In general, structures and functionality presented as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure.
Use of the phrase “at least one of” preceding a list with the conjunction “and” should not be treated as an exclusive list and should not be construed as a list of categories with one item from each category, unless specifically stated otherwise. A clause that recites “at least one of A, B, and C” can be infringed with only one of the listed items, multiple of the listed items, and one or more of the items in the list and another item not listed.
