Patent Application
20180032929
The disclosure generally relates to the field of system development processes, and more particularly to tracking risks on a per-component basis during different phases of a risk analysis process that is integrated with a software development lifecycle.
A software development process is typically implemented in and across different developmental phases or stages. The developmental phases are sometimes collectively referred to as a software development lifecycle. The development phases are utilized by programmers and other development team members to design, model, test, construct, and modify software components and multi-component systems. A given development process is typically designed, in part, to meet specified development and performance goals within specified time and resource budgets. The development process for one or more software items may be integrated within the context of a higher-level system development life cycle for a system comprising hardware and/or software components potentially supplied by different development teams.
There are several distinct categories of development processes (sometimes referred to as development models) that may be applied for handling different types of software and system complexities. For example, a waterfall type model implements a sequential, unidirectional development process in which development progress flows “downward” through design, build, test, produce, and maintain phases. So-called spiral development utilizes processes from various different development models based on risk patterns that may be unique to a particular program or multi-program system under development. A spiral model adopts elements of other types of development models (e.g., waterfall, incremental, evolutionary, etc.) based on risk patterns determined by the spiral model.
As software development processes and models become more dynamic, based on continuously changing user-centric requirements, greater flexibility and speed are required for software development. Addressing the need for greater flexibility and speed, agile software development establishes a software development framework in which requirements are addressed and solutions evolve via collaboration across multiple distinct units of the development team. Agile development promotes adaptive planning as well as flexible and rapid response to changes in customer requirements, market conditions, etc. While agile software development techniques provide greater cross-team continuous collaboration for dynamic development, risk management is typically implemented in such processes in a non-integrated manner.
Embodiments 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. In some instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.
Overview
Software development lifecycles are generally designed to maximize program efficacy while avoiding or ameliorating risks such as excessive overhead expenditures, violation of scheduled time-frames, etc. The present disclosure describes systems, devices, components, and methods for integrating risk management techniques and processes within a software development system or subsystem. In one aspect, a software development system includes an application or system architecture generator. As utilized herein, an “application” may refer to a distinct (i.e., independently compiled) application program and or may refer to a collection of multiple application programs and other code constructs such as APIs and libraries. In this manner, the terms application may be utilized synonymously with “system” to designate multiple programs, packages, and scripts that are included within a given system or application architecture design.
In some aspects, a system architecture design may be implemented via a system model comprising multiple system components such as programs, packages, libraries, scripts, etc. Such a system model may represent high, medium, and/or low levels of functionality of a complex system such as a Cloud or multiple Cloud services application comprising multiple components. As utilized herein, a “component” may refer to a “component element” which is a data representation of a system component and is generated as part of a system modeling processing. “Component” may also refer to a corresponding “component object” which is a data representation of a system component corresponding to but distinct from a “component element.” Specifically, a component object is a data representation of a system component that is adapted for use with a displayed risk management interface as described herein.
The disclosed embodiments provide techniques for assessing risks for individual components, sub-sets of components, and for an entire system model on a per-component basis. In some embodiments, system architecture components are processed by a description parser that may utilize components definitions or other information to identify components within a system model that require risk analysis. The description parser may also utilize pre-specified definitions and other information to identify inter-component relationships that may be subject to risk management as described herein.
In some aspects, a management cycle generator receives a set of the components identified as requiring or as otherwise subject to risk analysis during system development. The risk management cycle generator is configured, using any combination of coded software, firmware, and/or hardware, to receive and process data elements representing identified system components. The risk management cycle generator may determine a risk management cycle to be applied to the system model based, at least in part, on one or more risk factors associated with the identified system components. The identified components may be converted or otherwise translated into corresponding data constructs, referred to herein as component objects. Each of the component objects may be input into a corresponding one of multiple displayed risk management phases that form the risk management cycle. The component objects may be inserted and moved between displayed risk management phases such as by graphical user inputs. The risk management cycle generator processes the components, positioning of components, and movements of components to provide a risk-adaptive software development subsystem that detects, identifies, and mitigates risks in an agile development environment.
Example Illustrations
Model generator 102 processes input from client device 104 to retrieve component elements and corresponding descriptions from component library 106 to generate a system model file 112 that includes a list component elements C1.1, C1.2, C3.0, etc. The component elements may comprise data constructs that represent system components (e.g., a document server, API, etc.) and may also include constructs representing communication protocols or other connectivity features between system components. Model render unit 108 receives system model file 112 as input and displays the components and components' connectivity within the displayed system model 111 accordingly.
In some embodiments, the system model file 112 is also be sent to and received by a description parser 114 that is configured, using any combination of coded software, firmware, and/or hardware, to identify individual components and connections. Description parser 114 may first identify each of the components and connections described by the corresponding component elements. Each of the component elements C1.1, C1.2, and C3.0, may include a specified alphanumeric component ID associated with component description data. For example, component element C1.2 include component ID “DOCUMENT SERVER.” Description parser 114 may utilize the component IDs as indices to access a risk factors table 115 stored within storage device 117. Risk factors table 115 includes row-wise entries that each associates one or more of the component element identifiers with a quantitative and/or qualitative risk factor value or descriptor. For instance, the first entry of risk factor table 115 associates a component ID, CID_1, with a risk factor ID, RF_5, the second entry associates one component ID, CID_2, with two risk factor IDs, RF_3 and RF_8, and the third entry indicates that no risk factors are associated with CID 3.
In some embodiments, description parser 114 selects a subset of the identified components to be input to and processed by a risk management cycle generator 120. The selection of component elements may be based, at least in part, on risk factor data associated with the component elements within risk factor table 115. For each component ID in a system model corresponding to an entry within table 115, description parser 114 determines whether to select the corresponding component element to be included in a component risk file 116 in accordance with the associated risk factor(s). In this manner, component risk file 116 includes entries for a subset of 0 to n of the n component elements included in system model file 112. For example, component risk file 116 is depicted as including component elements C2.0, C11, C25, etc.
Component risk file 116 is transmitted to and received as input by risk management cycle generator 120, which includes several components including a cycle editor 122 and a component conversion unit 132. Cycle editor 122 is configured, using any combination of coded software, firmware, and/or hardware, to identify, construct, synthesize, or otherwise determine a risk management cycle having multiple risk management phases. The determined risk management cycle is utilized to generate a risk management interface object 128 that may be displayed by an interface render module 136 on a display device 138. Cycle editor 122 may determine the risk management cycle as a sequence of phases that themselves are selected or otherwise determined and are further mutually sequenced based, at least in part, on input from a cycle templates file 124 and a component risk factor database 126.
Cycle templates file 124 includes entries that specify distinct templates each comprising multiple phases having a specified sequence. For instance, the first depicted entry in cycle templates file 124 specifies a sequence of risk management phases beginning with risk management phase 1 (RMP_1) and concluding with RMP_N. Cycle editor 122 may initially select and/or modify one of the cycle template based, at least in part, on a collective assessment of component-specific risks factors that may be specified within risk factor database 126.
Having determined a risk management cycle, cycle editor 122 generates an interface object 128, which includes multiple risk management phase objects (not depicted) that correspond to the phases and sequencing of the determined management cycle. Interface object 128 may comprise data and program code and be displayable such as via rendering by interface render module 136 within display device 138. As shown in
Insertion control unit 130 also receives as input component objects (not depicted) that are generated by component conversion unit 132. In the depicted embodiment, conversion unit 132 receives as input and processes the component element entries within component risk file 116. More particularly, conversion module 132 may generate displayable data objects that include some template-based features that are common for all of the generate component objects and further include component-specific features. For instance, conversion module 132 may insert a component ID such as the ID “SQL DATABASE” included within the component object, CO_3, displayed within the displayed PHASE_1 object.
The development subsystem components, such as risk management cycle generator 120, may further be configured, using any combination of coded software, firmware, and/or hardware, to dynamically manage the display of system components.
Based on the component element input and other information, cycle editor 206 generates management interface object data that is input to a component insertion control unit 210. For instance, cycle editor 206 may access cycle template data and/or component risk factor data from respective files as shown in
In addition to the management interface object data from cycle editor 206, insertion control unit 210 receives component object data from component conversion unit 208. For instance, component conversion unit 208 may generate an object data construct for each of the input selected component elements and output a set of corresponding component objects to insertion control unit 210. In the depicted example, component conversion unit 208 generates six component objects that are each displayed within a respective one of the five phase objects within management interface object 214. The displayed component objects include an APP BRIDGE object displayed in the VULNERABILITY DETECT phase object, an SQL DATABASE object displayed in the THREAT DEFINITION phase object, a NoSQL SYSTEM object displayed in the RISK DEFINITION phase object, WEB SERVER and DATA FILTER objects both stored in the REMEDIATION STATUS phase object, and a DOC SERVER object displayed in the RISKS MANAGED phase object. In some embodiments, movement of the component objects between phases may be performed based on and in response to user input such as a command line instruction or as a graphical user input such as a drag and drop operation. In other embodiments, the component objects may be moved between displayed phases based on and in response to background risk analysis processing.
In the depicted embodiment, insertion control unit 210 includes, among other components, a risk analysis element (RAE) collection unit 216 and a movement manager 228. RAE collection unit 216 is configured, using any combination of coded software, firmware, and/or hardware, to identify component objects that are displayed in or otherwise associated with each of the risk management phases. Upon initial generation of a risk management interface, RAE collection unit 216 may identify each of the multiple constituent phase objects and determine that some or all of the system component objects are associated with (e.g., displayed within) the first of the sequenced phases. In the depicted embodiment, for example, RAE collection unit 216 may determine that all of the system component objects are initially displayed within the VULNERABILITY DETECT phase object.
As the component objects traverse the displayed phase objects, RAE collection unit 216 is further configured to monitor each of the phases to identify which object components are displayed therein. For example,
RAE collection unit 216 copies the risk analysis elements for each of the component objects in each of the phase objects and transmits the risk analysis elements to a storage interface 218. Storage interface 218 stores the risk analysis elements to one of a set of collection objects 220, 222, 224, and 225. Each of collection objects 220, 222, 224, and 225 corresponds to a respective one of the displayed risk management phases. In the depicted embodiment, collection object 220 corresponds to the VULNERABILITY DETECT object, collection object 222 corresponds to the THREAT DEFINITION object, collection object 224 corresponds to the RISK DEFINITION object, and collection object 225 corresponds to the REMEDIATION STATUS object. RAE collection unit 216 may include a table or other data structure that associates identifiers (e.g., filenames) for each of collection objects 220, 222, 224, and 225 with the corresponding displayed risk management phase.
As shown in
As depicted, each of the risk analysis elements corresponds to a respective one of the component objects and is stored in a collection object that uniquely corresponds to one of the displayed risk management phases. In this manner, the risk analysis elements stored within the collection objects are both component and phase specific. To facilitate collection of the risk analysis elements as components are positioned in and moved between phases, insertion control unit 210 may be further configured to receive graphical user input signals to detect movement of the component objects between the displayed phases. For example, when insertion control unit 210 detects that the NoSQL SYSTEM object has moved from the THREAT DEFINITION phase to the RISK DEFINITION phase, RAE collection unit 216 may allocate a NoSQL SYSTEM collection file within collection object 224. The collection file may be accessed to store risk analysis elements collected from the NoSQL SYSTEM component (e.g., messages entered by users) during the period in which the NoSQL SYSTEM remains in the RISK DEFINITION phase.
The risk analysis element data stored within collection objects 220, 222, 224, and 225 includes content (e.g., message specifying a particular component vulnerability) that is both component and phase specific. Such data may be utilized for various risk management analysis purposes including controlling or otherwise managing movements of component objects between the displayed phase objects. In response to insertion control unit 210 detecting an attempted movement of a component object between phase objects, a call may be sent to movement manager 228 indicating the detected movement or positioning. In response to the call indicating an attempted movement of the component object, movement manager 228 generates a risk condition query that may be based, at least in part, on a selected one of risk analysis rules 229. For example, movement manager 228 may receive a call to generate a risk condition query in response to detection of the WEB SERVER component object being moved from the REMEDIATION STATUS phase object to the RISKS MANAGED phase object. To generate the risk condition query, movement manager 228 selects one of risk analysis rules 229 to be applied in determining whether to reject or otherwise restrict the movement or attempted movement. In some embodiments, the selected risk analysis rule defines a risk condition that is dependent on a specified relation between a risk analysis element in the origin phase (e.g., REMEDIATION STATUS) and a risk analysis element in a phase preceding the origin phase (e.g., RISK DEFINITION). Continuing with the example, the risk analysis elements for the WEB SERVER component stored within collection object 224 may comprise messages that each specify a defined risk. Furthermore, the risk analysis elements for the WEB SERVER component stored within collection object 225 may comprise messages that each specify a remediation status for one or more risks. In this case, movement manager 228 may select a risk analysis rule that determines whether collection objection 225 includes a WEB SERVER risk analysis element (remediation status) that, based on the rule, adequately addresses each and all of the defined risks specified by collection object 224 for the WEB SERVER component.
In other examples, movement manager 228 may select a risk analysis rule that determines whether to reject or otherwise restrict a component movement from the RISK DEFINITION phase to the REMEDIATION STATUS phase. For instance, in response to determining that RISK DEFINITION is the origin phase, movement manager 228 may select a rule that defines the movement acceptance condition as depending on whether a risk definition RAE has been specified for each of the specified threat definition RAEs.
Having selected a risk analysis rule in association with the origin phase object or otherwise, movement manager 228 generates and sends a risk condition query to storage interface 218. The query may specify the collections objects from which data is to be retrieved and also may specify individual data objects (e.g., files) that are associated with component object IDs. During query execution, movement manager 228 retrieves a set of one or more risk analysis elements from the one of the collection objects that corresponds to the origin phase object. Movement manager 228 further retrieves a set of one or more risk analysis elements from one or more of the collection objects that correspond to phase object(s) that precede the origin phase object. Movement manager 228 processes the retrieved risk analysis elements in accordance with the selected risk analysis rule to determine whether the risk condition defined by the rule has been detected based on the risk analysis element data. If the risk condition is detected (e.g., one of the threat definition RAEs lacks a corresponding risk definition RAE) movement manager 228 issues a call to a display manager to implement a movement rejection action. In some embodiments, the movement rejection action may entail the display manager displaying a warning message in association with risk management interface 214. In some embodiments, the movement rejection action may entail the display manager preventing the movement of the displayed component object.
During or following construction or modification of the displayed system model, each of the component elements are received as input by a description parser (block 304). For each component element, the description parser parses descriptive content and compares the content with risk factor data (step 306) to determine whether or not to select the component for risk analysis. For example, the description parser may identify the component element representing an SQL database based on parsed object data (e.g., object ID). The description parser may then compare this data with risk factor data by utilizing “SQL,” “DATABASE,” and/or “SQL DATABASE” as an index key in a risk factor file that associates component identifiers with corresponding risk factors. The comparison may result in the description parser determining a correlation between the component description and one or more specified risk factors. For instance, a correlation may be detected in response to determining that the component ID “SQL DATABASE” is associated within a risk factor file with one or more specified risk factors.
In response to detecting no correlation at block 308, process control returns to block 304 for processing of a next component element in the model. In response to detecting a correlation at block 308, the description parser selects the component element for analysis such as by entering the component element description in a component risk file (block 310). Processing of each of the component elements in the foregoing manner continues until all components have been processed as determined at block 312 and control passes to block 314 with a risk management cycle generator generating a displayable risk management interface object. The risk management interface object includes multiple displayed risk management phase objects that are designated by a phase identifier. For example, the phase objects depicted in
At block 316, a cycle editor within the cycle generator generates the risk management interface object comprising the selected and sequenced phase objects and outputs the risk management interface object to an insertion control unit. The component risk file generated at blocks 304 through 312 is input to and processed by the cycle generator. The cycle generator includes a component conversion unit that generate component objects that each correspond to a respective one of the component elements included in the component risk file (block 318). At block 320, each of the component objects are displayed within a respective one of the displayed risk management phases within the risk management interface.
The depicted embodiment further includes operations and functions for collecting and storing the messages and other risk-related information associated with a component object as it traverses the cycle phases. It should be noted that while the foregoing and the following blocks are depicted in relative sequence, the operations and functions for entering data within components and collecting and storing the data may be performed concurrently and in a continuous manner. At blocks 410 and 412 an RAE collection unit identifies component objects that are displayed within the phase objects. For each component object, the RAE collection unit collects risk analysis elements incorporated in or otherwise associated with the component object (block 414). At block 416, the RAE collection unit stores the collected risk analysis elements with a collection object that uniquely corresponds to the phase object in which the component object is currently displayed. The RAE collection unit may perform the collection and storage operations for each of the displayed component objects in an individual instance or batched manner. For example, the RAE collection unit may respond individually to each new text entry (blocks 406 and 408) by collecting and storing the text entry as a risk analysis element. In addition or alternatively, the RAE collection unit may respond to an instruction to collect and store risk analysis elements for all components or a subset of the components. In such an embodiment, the process continues for each component (block 418) within each displayed phase (block 420).
In response to detecting an attempted movement of the component object between phase objects, a movement manager within the insertion control unit selects a risk analysis rule (block 507). In some embodiments, the risk analysis rule defines a risk condition that depends on a specified relation between risk analysis element for the same component but across different phases. The risk analysis rule may be selected from among multiple risk analysis rules that, as a set, are implemented in the cycle generator configuration based on the identities of one or more of the phase objects.
In further response to detecting an attempted movement of the component object and following selection of a risk analysis rule, the movement manager generate and executes a risk condition query at superblock 508. The risk condition query may include one or more data read requests issued to a storage system in which multiple collection objects corresponding to displayed phase objects are maintained. The read request(s) constituting the risk condition query may be determined, at least in part, based on the selected risk analysis rule. For example, the risk analysis rule may define a risk condition as a condition in which there is a quantitative or qualitative discrepancy between risk analysis elements for a common component but between different phases. Furthermore, the rule may specify the condition as being determined between the origin phase object (i.e., the phase object from which the component has been moved or been attempted to be moved to a target phase object) and a phase object preceding the origin phase object. As shown beginning at block 509, execution of the risk condition query includes identifying and retrieving risk analysis elements for the component object that are stored in a collection object corresponding to the origin phase object. At block 510, the movement manager completes execution of the risk condition query by identifying and retrieving risk analysis elements for the same component object but that are stored in a collection object corresponding to the to a phase object that preceded the origin phase object.
Having read or otherwise retrieved the risk analysis elements, the movement manager applies the risk analysis rule to the risk analysis elements (block 512). In response to detecting a risk condition defined by the rule as a result of applying the rule to the risk analysis elements (block 514), the movement manager issues a program call to implement a movement rejection action (block 518). For example, the movement manager may instruct a display manager to display a warning message indicating the risk condition defined by the risk analysis rule. In some embodiments, the movement rejection action may entail preventing movement of the displayed component object or returning the displayed component object to be displayed in the origin phase object. If application of the risk analysis rule to the retrieved risk analysis elements fails to meet the defined risk condition, the component movement is accepted (block 516).
Variations
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 provided 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 implementing risk-adaptive system development 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 shown as separate components in the example configurations may be implemented as a combined structure or component. Similarly, structures and functionality shown 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.
