Patent Grant
12086264
Users and procurers of software applications, particularly those in regulated industries, generally seek assurance that the software products they want to procure will not result in vulnerabilities to customer data and security breaches of that data. These procurers gain assurance by assessing the security and compliance posture of the software before procurement. They typically try to obtain information such as how data will be handled by the software application, and what protections are provided for critical vulnerabilities for the software application and data it manages, which other services may depend upon. Currently, users and entities seeking to obtain software applications from producers do not have a centralized repository that provides up-to-date, evidence-backed information required for software risk assessments.
Instead, these users and entities request this information from the vendors or producers for each assessment, such as via a questionnaire, (e.g., a 150 point checklist) covering the product's key security and compliance attributes. Users then require evidence to validate the vendor response, which typically sets off a series of back-and-forth discussions between the user's and vendor's security and product teams and can delay assessment by a meaningful amount of time (e.g., typically up to 10 additional weeks). Due to tight timelines and resource constraints, often users can perform validation for only a few mission-critical products, and they have to trust the vendor's self-attested information for the rest. Because this is a ‘point-in-time’ assessment, users therefore need to build manual processes (including periodic re-assessments) to track changes to the software's security and compliance posture post procurement. For vendors, responding to user requests is repetitive, time-consuming, and requires coordinated efforts a number of different teams and users.
Various techniques will be described with reference to the drawings, in which:
Systems and methods are described herein for performing a risk or other assessment on software applications utilizing various evidence sources. Entities, including private organizations, government agencies, and the like, utilize various applications and pieces of software to operate, perform public functions, etc., where those applications may interface with various data, including sensitive data, such as health information, financial information, etc. These entities typically seek some assurances that the applications they are employing meet various standards for data security and risk mitigation. The described techniques address a number of challenges with the typical manual process of asking an application producer or vender a large number of questions concerning the risk and vulnerabilities of the application, waiting for responses, and having to manually update the assessment over time. The described techniques do so by automatically gathering evidence from a number of sources, and in some cases providing monitoring of the evidence sources to provide updates on the risk assessment of the application. Importantly, the described techniques can gather operational data from the application executing in a runtime environment, such as provided by a computing resource service provider, to provide the most current and accurate risk assessment data across a number of different variables or control sets (e.g., an assessment criteria). In some cases, the described techniques may also utilize other evidence sources to assess the risk of the application, including obtaining compliance certifications from various external organizations, and/or self-attestations and other data generated by the application vendor or producer. In some cases, one or more of these evidence sources may be monitored, such as continuously, to update the risk assessment and/or provide notifications to the operator utilizing the application of changes in security and/or increased vulnerabilities of the application. Utilizing one or more of the above-described features, the described techniques may provide a platform to enable more robust risk assessment of various applications.
In some aspects, the described systems and techniques gather evidence-backed security and compliance information financial risk or posture information, and/or to legal considerations or compliance information for software from vendors, present that information in a dashboard or other interface, and provide notifications to monitor changes to various controls or attributes of that information. The described techniques provide a structured and automated way to access the security posture, compliance status, and supporting evidence for applications through a user interface or dashboard that enables interacting with various levels of information relating to risk assessments and data security. In some cases, the described techniques automate evidence gathering using an audit management system to present current, validated information. The described systems may also extract relevant evidence from certified audit reports such as ISO-27001 or SOC-2. The ability to gather this evidence reduces the need for back-and-forth discussions enabling entities to complete assessments within a few hours instead of months. The described systems enhance data security by obtaining external evidence, not just an application developer's own self-assessment. In addition, the described techniques may reduce or eliminate the need for periodic re-assessments, as entities will have access to the dashboard and reports post-procurement and can also receive notifications to monitor changes in the application's security posture.
In some aspects, upon obtaining the compliance and security data or evidence from one or more sources, the evidence may be compared and mapped to a number of different variables or indicators (e.g., an assessment criteria) relating to data security, risk management, financial risk or posture, or to legal considerations or compliance. In some cases, the variables may be controls that are placed on the data, such as whether the data is encrypted at rest and in transit, where the evidence may indicate whether the controls are active or in place. Different variables or controls may be organized into control sets based on the type of category they fall into, such as one or more of audit and compliance, data security and privacy, risk management and incident response, access management, security policy, application security, business resilience, end user device/mobile security, infra security, and human resources. The evidence may be mapped to individual variables or controls within these broader categories, where the indicator may specify from which evidence source it originates, such that one or more of data obtained from the application executing in a runtime environment, a compliance report, or a self-attestation may indicate whether a certain control is active for the application. The evidence may be compared/mapped to the criteria to generate a risk assessment comparison. A representation of the risk assessment of the application (e.g., via a user interface) may be generated across at least some of the criteria (e.g., for variables where evidence is available). In this way, various evidence from various sources may be coherently and comprehensively gathered, organized and presented to give an accurate picture as to an application's potential vulnerabilities.
In some cases, one or all of the available evidence sources may be monitored, such as periodically, aperiodically, or continuously, to detect if any changes have occurred in the evidence. In some cases, the risk assessment representation may be updated based on detected changes in the evidence. The risk assessment representation may be updated in real-time or near real time compared to when the changes in evidence are detected, or may be updated periodically, such as at a regular interval. In yet some cases, the changes in evidence may be analyzed to determine if any immediate notifications or alerts need to be generated to prevent any compromising events to the application or data managed by the application. In yet some cases, one or more mitigation actions may be automatically triggered in response to configurable detected events as indicated by changes in the evidence.
In some aspects, data generated for a risk assessment of a first application, such as in response to a first request, may be used to form a second risk assessment for the same application (e.g., a different instance or implementation of the application) for a second request. In some cases, the described systems may support publishing questions concerning the application and the vendors responses, or responses from various other sources. In some cases, this information may be provided to related risk assessments, such as in the example described above. In yet some cases, natural language processing may be utilized to identify similar questions that have been asked concerning the application from different requests. The corresponding responses may then be provided with related risk assessments, and in some cases, in response to specific questions or requests about a risk assessment of the application.
To protect sensitive information, in response to receiving a request to view a risk assessment of an application, the described system may redact portions of the risk assessment to provide responsive to the request. In some cases, a non-disclosure agreement or similar agreement may be provided in response to the request, such that the risk assessment is only provided if the terms to the non-disclosure agreement are agreed to.
In the preceding and following description, various techniques are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of possible ways of implementing the techniques. However, it will also be apparent that the techniques described below may be practiced in different configurations without the specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the techniques being described.
As one skilled in the art will appreciate in light of this disclosure, certain embodiments may be capable of achieving certain advantages, including some or all of the following: (1) improved and more robust security assessments of applications to identify potentially vulnerabilities in applications to ultimately reduce data breaches; (2) improved efficiency in generated a risk assessment of applications to reduce network bandwidth usage; (3) a more efficient user interface for accessing risk assessment data, and (4) other advantages as will be made apparent in the rest of this disclosure.
Client 104 may refer to a client computer system or computing device connected to a server (e.g., computing resource service provider) over a network 106. In some cases, client 104 refers to a user or operator of a client computer system and may be an employee of an organization that utilizes a computing resource service provider 102 to interact with various forms of data, such as application data/data source 124 through one or more vendor applications 120, in combination with risk assessment service 112, audit management system 110, storage service 122, and/or other services 126.
Client 104 may submit a request 130 for access to various computing resources (e.g., services or computing resources thereof) of computing resource service provider 102. The request 130, in some examples, is a web service application programming interface request (also referred to simply as a web service request), may be received by a service of the computing resource service provider 102. As illustrated, the client 104 may submit a request 130 to configure, access, and otherwise interact with a vendor application 120 and risk assessments of that application, as provided by risk assessment service 112. In some cases, the request 130 may be directed to one or more services provided by the computing resource service provider 102, and may include a request to submit an application and related information to generate and/or configure a risk assessment of the application, such that may be made available to other users or entities desiring to utilize the application. In yet other cases, the request 130 may include a request to access a risk assessment of an application, such as may be provided through a user interface 118 of the risk assessment service 112. In yet some cases, the request 130 may include other requests to access, store, or evaluate applications 120 that may interact with application data 124.
In some examples, request 130 may include one or more of: a destination of the software code of the application, various information or evidence relating to vulnerabilities, risk assessment, and/or controls implemented by the application, one or more compliance reports generated by various organizations, locations of the compliance report or reports, a self-attestation of the application from the producer of the application, and various other information relating to execution and evaluating the application for vulnerabilities, data security, etc. In some cases, the request may include an indication of what variables or controls are pertinent to the application, evidence pertaining to those variables or controls, and various other information as may be useful in providing the application to others for execution and enabling the risk assessment service 112 to generate a thorough and accurate risk assessment of the application.
In some cases, the front end 108 may receive the request and direct it to the appropriate service. The front end 108 may be a system including a set of web servers (e.g., a single web server or a set of web servers which may be managed by a load balancer) provided by the computing resource service provider 102. Web servers of the front end 108 may be configured to receive various requests and to process them according to one or more policies associated with the service. In at least one embodiment, client 104 uses client software that is configured to establish a client-server relationship with a service of a computing resource service provider 102. A client 104 may connect to a service via front end 108, which receives requests from clients and routes them to backend services. Front end 108 may interface with one or more of a risk assessment service 112, an audit management system 110, a vendor application 120, a data storage service 122, and/or other services 126 offered by a computing resource service provider 102 to its customers. In at least one embodiment, client 104 interacts with a GUI to interact with various media provided by or through the computing resource service provider 102, and client-side software translates the GUI setup to a web service API request which is transmitted from the client computer system 104 to front end 108 via a network 106.
In some cases, the network 106 includes any appropriate network, including an intranet, the Internet, a cellular network, a local area network, a satellite network or any other such network and/or combination thereof, and components used for such a system depend at least in part upon the type of network and/or system selected. Many protocols and components for communicating via such a network are well known and will not be discussed herein in detail. In an embodiment, communication over the network 106 is enabled by wired and/or wireless connections and combinations thereof. In some cases, a network may include or refer specifically to a telephone network such as a public switched telephone network or plain old telephone service (POTS).
The computing resource service provider 102 may provide various services such as data processing, data storage, software applications, security, encryption, and/or other such services. A computing resource service provider described herein may be implemented using techniques described below in reference to
In some examples, the computing resource service provider 102 may provide one or more of a risk assessment service 112, an audit management system 110, a vendor application 120, a data storage service 122. Each of these services may provide ways for a customer to interact with various forms of data, including using the one or more services to assess risk and vulnerabilities of various applications.
The risk assessment service 112 may be a collection of computing resources or processes configured to generate and process risk assessment for applications, such as vendor application 120 that may be executed in a runtime environment provided by the computing resource service provider 102 and may access application data 124, which as illustrated, may be managed and stored via a data storage service 122 also provided by the computing resource service provider 102. In other cases, application 120 may access data external to the computing resource service provider 102. In yet some examples, the application for which the risk assessment is produced may also be executed external to the computing resource service provider 102. The risk assessment service 112 may generate an assessment of risk or other attributes of an application based on various evidence sources. As used herein, this assessment may be generally referred to as a risk assessment. It should understood, however, that the assessment may not be limited to different assessing risks of an application, but may rather provide a summary of various attributes of an application based on data security, vulnerabilities, or based on other attributes, such as relating to financial data or information or legal compliance, etc.
The risk assessment service 112 may obtain an application 120 for performing a risk assessment, such as associated with a request 130. The risk assessment service 112 may coordinate and direct obtaining evidence or data relating to various attributes of the application from various sources, via an evidence gathering process 116. In some aspects, the risk assessment service 112 may coordinate and/or instruct the audit management system 110 to evaluate the application 120, as it is executed in a runtime environment provided by the computing resource service provider 102. In some cases, the risk assessment service 112 may initiate executing of the application itself, such as through audit management system 110, and/or other services 126. In other cases, the risk assessment service 112 may simply receive a notification that the application is running, and coordinate with the audit management system 110 to obtain operational data from the application. In some cases, the evidence gathering process 116 may obtain data from one or a number of different sources, including self-attestation data from a vendor or producer of the application itself, one or more compliance or other reports from an external service or data source 128, and/or operational data of the application executing in a runtime environment, such as may be collected by an audit management system 110. It should be appreciated that external service or data source 128 may including any of a variety of certifying or examination entities, relating to data security, best practices or requirements in certain industries, such as legal, financial (e.g., financial reports), health care, other application evaluations (e.g., ScoreCard), and so on. As used herein, external service or data source 128 may contemplate any external organization or data source that may provide evaluations of applications.
The risk assessment service 112 may also include a assessment criteria 114, which may be a collection of computing resources or processes for configuring what types of controls and variables (e.g., assessment criteria) are analyzed and collected for a given application, and what evidence maps to those controls and variables. More detailed examples of different variables and controls which may be determined for an application will be described in greater detail below in reference to
The audit management system 110 may be a collection of computing resources configured to observe an application, such as vendor application 120, and collect operational and other data that may be used to generate a risk assessment of the application. The audit management system 110 may access a data source, such as data sources 124, from a data storage service 122 provided by the computing resource service provider 102, and/or via other data sources maintained, stored, or accessed external to the computing resource service provider 102. The audit management system 110 may perform one or more of the following functions: collecting and storing logs, determining what types of controls are active in managing data by the application, generating metrics relating to operation of the application, aggregating metrics, etc., on the data. The audit management system 110 may collect or generate data and metrics pertaining to the application 120, which may be used by the risk assessment service to generate a risk assessment of the application.
The risk assessment service 112 may additionally include or provide a user interface 118, which may structure and provide access to the various indications of different attributes of a risk assessment of application 120. A more detailed example of an organizational structure used to represent a risk assessment, which may be provided by user interface 118, will be described in great detail below in reference to
In some examples, the computing resource service provider 102 may provide data storage through a data storage service 122 to store and manage large volumes of data, including various types of data as may be used by various applications 120, which may collectively be referred to herein as a data source or application data 124. In some cases, the data storage service 122 may interact with application 120, audit management system 110, risk assessment service 112, and/or other service 126 to enable risk assessments to be generated, updated, and accessed relevant to data stored by the data storage service 122. Data storage service 122 may be an on-demand data storage service, such as an object-based data storage service, and may be configured to store various forms of media. The data storage service 122 may be implemented on a computer system, or abstraction thereof (such as one or more virtual machines, software containers, or other computing resource abstractions), implemented using hardware and software, and may comprise one or more processors and memory that stores executable instructions whose execution by the one or more processors causes the computer system to perform operations described herein. In some examples, data stored in the data storage service 122, which may collectively form a data source 124, may be organized into data objects, The data storage service 122 may store numerous data objects of varying sizes. The data storage service 122 may operate as a key value store that associates data objects with identifiers of the data objects which may be used by the client 104 to retrieve or perform other operations in connection with the data objects stored by the data storage service 122. Access to the object-based data storage service 122 may be through application programming interface (API) calls to the service or via an interface, such as a graphical user interface (GUI).
In some aspects, data source 124 may include data obtained from a specific application or service, such as virtual computing resources including virtual machines, containers, etc., data storage services, and other services or entities running within or outside of the computing resource service provider. In some cases, the data source 124 may include any of a number of different data sources and different types of data sources, such as from a Software as a Service (SaaS) application, a relational database or service, risk assessment service, audit management system, or other data source. In some cases, the customer, such as in a request 130, may specify the data source 124, such as via any type of an identifier, including IP address, resource name, such as may be assigned by a computing resource service provider 102 that provides the service or data source, or via other types of identifiers. In yet some cases, the data storage service 122 may store part or all of risk assessments generated by the risk assessment service 112. In some cases, the data storage service 122 may operate as a key value store that associates data objects with identifiers of the data objects which may be used by the client 104 to retrieve or perform other operations in connection with the data objects stored by the data storage service 122. Access to the data storage service 122 may be through application programming interface (API) calls to the service, for example from either directly from client 104, or via the computing resource service provider 102. It should be appreciated that the data storage service 122 may additionally or alternatively provide non-object-based data storage, such as block data storage, table-oriented data storage, relational databases, file-based storage, and the like.
The risk assessment service 204 may obtain the application code for the application 214, and coordinate with one or more other systems to load the application in a runtime environment to assess the application 214 while it is executing or thereafter. In some cases, the runtime environment may be provided by a computing resource service provider that also provides or instantiates the risk assessment service 204. In these cases, access to data from the application may be established under a push or pull scheme, such that data is obtained from the executing application either by actively requesting data from the application 214, or establishing in the runtime environment triggers or cues for the application itself, or a service executing the application, to send data from the application to the risk assessment service 204, in the form of live evidence 212. In cases where the runtime environment for the application is external to the computing resource service provider, a pull scheme may typically be utilized, as configuring an external runtime environment may present undesired difficulties or further customization. However, it should be appreciated that a push scheme may also be unutilized in these scenarios.
The live evidence 212 may include any of a variety of information that may be obtained or observed while the application is executing in a runtime environment, or thereafter. The live evidence may pertain to compliance with various standards set by various organizations and/or laws, such as HIPAA, FEDRAMP, PCI, and/or any of the following general categories: audit and compliance, data security and privacy, risk management and incident response, access management, security policy, application security, business resilience, end user device/mobile security, infra security, and human resources. In some cases, the live evidence 212 may pertain to information used to ensure or evaluate compliance with any standards set by various organizing, including HIPAA, FEDRAMP, PCI, audit reports such as ISO or SOC-2, other audit reports, other standards set for various industries, including health organizations, financial institutes, and various other data. Live evidence 212 may include operational data pertaining to how the application accesses, stores, and transfers data, what the data includes, and so on. It should be appreciated that live evidence 212 can include any data that is useful in evaluation an application for compliance, security, etc.
One benefit of gathering live evidence 212 from the application in a runtime environment is to observe exactly how data will be managed by the application, including what communications channels are used to obtain and transmit data, what storage devices or services are used to temporarily store the data, such as when it is being processed by the application, and other variables that are dependent upon the actual environment in which the application is executed.
The evidence gathering process 206 of the risk assessment service 204 may similarly obtain evidence from one or more audit reports, 216, such as SOC-2, ISO, and various other audit reports that may typically be used to evaluate applications and software code. Similarly, one or more self-attestations 218 provided by the producer of the application may similarly be obtained. The self-attestations 218 may take a variety of forms and may include a variety of information, including statements indicating what controls are placed or implemented within the application to ensure security and compliance with various standards, as made by the producer or vendor of the application. In addition, the evidence gathering process 206 may obtain one or more compliance reports or artifacts 220, from various sources, that indicate compliance of the application with one or more standards, sch as HIPAA, FEDRAMP, PCI, and others, such as relating to financial reports, credit scores, legal compliance, etc.
The evidence gathering process 206 may extract various pieces of information from one or all of these evidence sources and map the evidence to various variables and controls, as structured via the security controls component 208, at operation 222. In some aspects, individual variables in the risk assessment may have an indication for each evidence source, where the data from the different evidence sources is separate and represented separately, to enable more precise evaluation of an application by a potential user of the application. A more detailed example of a data structure for representing risk assessment data for an application will be described in greater detail below in reference to
In some cases, operation 222 may include utilizing a number of rules that identify which evidence sources and what information maps to specific variables or controls in the security controls/assessment criteria. In some cases, the set of rules may be manually entered or based on prior assessments performed by the risk assessment service 204. In yet some cases, such as when evidence is mapped from a compliance report or audit report, templates may be used to map individual pieces of data at certain locations within those reports to various controls/criterion in the assessment. In yet some examples, machine learning techniques may be utilized to develop, train, and improve models for mapping certain key words and phrases, such as in certain locations in a document, and/or taking into account proximity of words to other words, to develop a mapping. In some cases, mapping the obtained security and compliance evidence to the risk assessment criteria to generate the risk assessment may be performed using at least one trained model, wherein the at least one trained model includes indicators of the obtained security and compliance evidence that correspond to individual attributes of the plurality of attributes of the application. Various machine learning techniques may be utilized for this process, as are known in the art.
In some cases, operation 222 may include mapping a plurality of pieces of evidence, either from one data source or across multiple data sources 212, 216, 218, and/or 220, to one control or variable, as used in the assessment criteria/security controls 208. In some cases, this may include combining similar values into one combined value, noting any disagreement between the sources, providing a confidence score in a given value, and various other schemes, as may be used to efficiently convey values for different variables or controls.
Upon mapping the evidence to various variable and security controls, the security controls component 208 of the risk assessment service 204 may then generate a representation, such as an interactive and/or graphical representation of the various security controls and variables evaluated for the application, at operation 224, and provide the representation to a user interface 210. In some cases, the security controls component 208 may not be limited to security or other risk assessments, but rather may include a more general assessment criteria, implemented in a similar way, as described above in reference to
In some cases, the user interface may include a dashboard interface that structures the evaluation or risk assessment information into one of multiple layers. In some cases, the different layers may increase in specificity as they are selected. In one example, the dashboard may include various categories of a risk assessment performed for an application. Upon selecting a given category, one or more control sets or logical groupings of controls and/or variables or indicators that pertain to the category may be provided, including a number of individual controls or variables. Upon selecting an individual control or variable, a summary of the evidence collected for that specific control or variable my be presented. A more detailed example of a data structure for representing risk assessment data for an application will be described in greater detail below in reference to
A similar process may be used to update an already generated risk assessment, based on any of the evidence sources. The process for updating the risk assessment may be performed on the application as being executed by the user of the application. In this scenario, the risk assessment service 204 may either request updated information from one or more of the evidence sources 212, 216, 218, and/or 220, or receive updates from any of these evidence sources via a push mechanism. In some aspects, the risk assessment service 204 may also include a mitigation process or component 230. The mitigation process 230 may obtain updated evidence information and compare that updated evidence information to a set of configurable thresholds for determining if one or more mitigation actions need to be taken to reduce, prevent, or mitigate potential security breaches or other unwanted risk events from occurring while the application is executing. In some aspects, the mitigation process 230 may trigger action to be taken by a security system, such as may be provided by a computing resource service provider 102. In some cases, upon detection an action warranting mitigation action, the mitigation process 230 may generate a ticket or other notification that can initiate a security action to be to be performed to address the detected event.
In some aspects, a vendor may interface with a vendor profile service 316 of the vendor interface 314 to establish and/or modify a profile of the vendor as maintained by the risk assessment service. The vendor may interact with the vendor profile service 316 by submitting information about the vendor (e.g., contact information, history information including what applications them have produced, various credentials indicating their ability to create trustworthy applications, etc.) via one or more API calls so that a profile may be created and/or modified pertaining to the vendor. The profile may be accessible to users to aid them in assessing various applications for use. Similarly, the vendor may also interact with the product profile service 318, also part of the vendor interface 314, for providing information describing the one or more applications offered by the vendor. The vendor may interface with the product profile service 318 via one or more API calls that include information about the application, self-attestations, answers to questions concerning the application, compliance certificates, audit reports, pointers to the application in a production or runtime environment, and various other information.
The risk assessment service 300 may also include an evidence collection service or process 326, which may incorporate one or more aspects of evidence gathering process 116, 206. The evidence gathering service 326 may include a live data gathering process 328, which may obtain operational data from an application in a production or runtime environment, and a certification parser 330, which may obtain various certificates or compliance reports pertaining to the application as generated by one or more external organizations. The evidence gathering service 326 may collect data for a given application upon receiving an instruction, at operation 332, from the product profile service 318, which may generate the application assessment. The certificate parser 330 may extract relevant data from the obtained reports. The product profile service 318 may get the evidence data, collected by the evidence gathering service 326, at operation 334, to generate a risk assessment of the application. The product profile service 318 may then communicate the risk assessment to the search management service 312 of the application catalogue 310, at operation 336, to enable other users to identify and access the risk assessment of the given application, such as via one or more public APIs.
A user or potential acquirer of an application may access the user interface 304 to obtain various information about various applications and risk assessments of those applications generated by the risk assessment service via one or more API calls. The user interface 304 may include an assessment management service 306, which is responsible for obtaining evidence and risk assessments of various applications, such as through an aggregate data management service or process 324, via operation 338. In some cases, the aggregate data management service 324 may obtain evidence directly from the evidence gathering service 326, via a push or pull mechanism, at operation 340.
The user interface 304 may also include a security subscription service 308, which is responsible for monitoring an application, in a product or runtime environment, and providing notifications to a user of changes in the security profile of the application. The security subscription service 308 may obtain updates to evidence data and other risk assessment information through a security posture streaming service 332, which may obtain changes in the underlying evidence from the aggregate data management service 324, at operation 342. In some cases, the security subscription service 308 may continuously monitor the application. In other cases, the security subscription service 308 may monitor the application periodically (e.g., every hour, every 12 hours, every 24 hours, every week, etc.), or at a user defined interval. In some cases, the aggregate data management service 324 may obtain changes in evidence from the evidence gathering service 326 and push important updates to the security subscription service 308. In yet some cases, the security posture streaming service 322 may also send various changes in the evidence to a notification service 320, which may notify a user directly, and/or a security service to trigger and/or perform one or more mitigation actions to address the change in security evidence for the application.
In the example illustrated, a data structure 400 includes variables, controls, and. or control sets 408-420 relating to the category 422 of data security and privacy 402. Various indicators or variables (also referred to as a control set when plural) 404 may be provided with corresponding values 406, such as including ingested customer data 408, corresponding to a value of see examples, a data storage location 410 corresponding to 6 locations, data storage countries 412 corresponding to 2 countries, data shared with external vendors 416 with a corresponding value of no, data encryption 418 with a value of 4 out of 4 controls turned on or active, and access control 410 with a value of 4 of 4 controls active. In the illustrated example, the data encryption indicator may include 4 different individual controls, where data encryption 418 may be referred to as a control set 424.
The data encryption control set 418 may include a number of different controls 424, each with corresponding evidence values or indicators 440. For example, a first control 426 of data encryption control set 418 may include an attribute or control imposed on data used by the application: whether the data is encrypted at rest and in transit. Upon obtaining evidence from one or a number of evidence sources, the indicators for this control 426 may be populated. In the example illustrated, a vendor self-assessment 428 may indicate that this control is turned on, and similarly with audit report evidence 430 and live evidence 432. Each additional control 434, 436, 438 in the control set 424 may similarly have different evidence sources indicating the same or different values for a given control/variable.
In a similar way, various other categories, control sets, controls, and evidence may be organized in a similar data structure, which may facilitate efficient access to the risk assessment information. For example, audit and compliance information and evidence may include and/or be structured as follows:
In some examples, data security and privacy information and evidence may include and/or be structured as follows:
Risk management information and evidence may include and/or be structured as follows:
Access management information and evidence may include and/or be structured as follows:
Security and configuration policy information and evidence may include and/or be structured as follows:
Application security information and evidence may include and/or be structured as follows:
Business resiliency information and evidence may include and/or be structured as follows:
End user device/mobile security information and evidence may include and/or be structured as follows:
Infrastructure security information and evidence may include and/or be structured as follows:
Human resources information and evidence may include and/or be structured as follows:
It should be appreciated that the various categories of data, controls, and corresponding and evidence described above are given by way of examples. Various other controls, and various combinations or sub-combinations of the above-described controls can be used to evaluate an application and generate a risk assessment thereof.
Process 500 may begin at operation 502, in which a request to perform a risk assessment for an application may be received, for example, by a risk assessment service. The request may identify an application that already has a profile within the risk assessment service, such as may be managed by a product or application profile service 318 and/or an application catalogue 310. In some cases, the application may have already been provided by a developer of the application, through a vendor interface 304. In some aspects, process 500 may proceed to optional operation 504, in which execution of the application in a runtime or production environment may be initiated. The runtime environment may be provided by a computing resource service provider that also provides the risk assessment service. In other examples, process 500 may be performed without a discreet request to generate a risk assessment, such as from a user. In these cases, such as upon uploading an application for assessment by a vendor, some or all of operations of process 500 may be performed. In some cases, upon uploading or otherwise submitting the application for assessment, the system may generate an assessment of the application, and add the assessment of a catalogue of available applications, such as catalogue 310.
Next, at operation 506, security and compliance evidence for the application may be obtained. Operation 506 may include obtaining evidence and operational data from any of a number of different sources, such as live evidence from the application executing in the runtime environment 508, an application developer self-attestation and/or other information provided by the developer, such as responses to questions concerning the application, compliance certificates 512, and/or audit reports 514. In some cases, all available evidence may be obtained. In yet other cases, evidence from only a subset of the evidence sources 508-514 may be obtained. In yet some cases live evidence 508 may be obtained, such as when operation 504 is performed, and at least one evidence 510, 512, and 514 may be used to supplement that data.
Process 500 may proceed to operation 516, in which a risk assessment may be generated by comparing or mapping the obtained evidence to a risk assessment criteria. Operation 516 may include comparing and/or mapping the various evidence data to one or more different categories, control sets, controls/variables, and/or evidence source indications as described in greater detail above in reference to
In some instances, the user interface provided in operation 518 may include a comparison function, whereby risk assessments of multiple applications may be presented side by side, to enable a user to compare different applications across a number of security controls or variables. In some cases, different attributes or variables of the applications selected for comparison may be customized/configured, so that a user may quickly and efficiently be able to compare a large amount of data across a number of different applications. In this example, operations 502-516 may be performed for each application, whereby the user interface can then collect the different risk assessments and generate a visualization of the different assessments, across a number of default or configured variables or controls. In some cases, this comparison function may provide the different attributes or criterion of different applications all at one time, such as to make the information more readily comprehendible.
In some cases, the user interface provided in operation 518 may be either an overview of the risk assessment, such as that may not contain any sensitive or confidential information (e.g., excluding some evidence sources, values of the evidence, and/or some variables or controls) or, a full risk assessment, which may include sensitive or confidential information (e.g., including all available evidence sources and variables). In the case that the full risk assessment is provided, agreement to non-disclosure terms, such as described above, may be required. In the example of an overview of a risk assessment, this version of the risk assessment may be generated, such as by a risk assessment service, so as not to include sensitive or confidential information. In some cases, the overview risk assessment may, however, contain import features pertaining to the application or assessment thereof, such as to enable robust search functionality by potential users of the application. For example, an overview risk assessment may include what compliance certificates the application has or is associated with, one or more subsets of various security features that the application conforms to or has enabled (e.g., is data encrypted at certain stages in the application processing), audit report or other report scores or ratings (e.g., a ScoreCard or other external or independent rating organization), and other features or attributes that users of the application may find useful to know in selecting that application. In some cases, the overview risk assessment may be catalogued for ease of searching, such as in catalogue 310 described above in reference to
Process 600 may begin at operation 602, in which a request to monitor risk and compliance evidence for an application may be received. In some cases, the request may be received through a user interface 304 of a risk assessment service. In other cases, instead of operation 602, process 600 may be automatically triggered upon a user selecting an application for use through the risk assessment service. In either case, responsive to the request, one or more evidence sources may be monitored for changes in the risk and compliance information relating to the application, at operation 604. Operation 604 may include monitoring the application in a runtime environment, such as to obtain live evidence of the application. In yet some cases, operation 604 may additionally or alternatively include monitoring other evidence sources, such as application developer attestations, or other related evidence provided by the developer, compliance reports, and/or audit reports.
In some aspects, the risk assessment service may provide for a message board, messaging application, or other similar interface to enable others to access information and responses from the developer to questions submitted by users relating to the risk and compliance information of an application. In some cases, various techniques, such as natural language processing, may be used to identify key words and phrases to provide answers to user questions from similar questions already asked by other users relating to the same application. In one specific example, a user may ask the application developer or vendor about a particular security risk. A second user, also seeking to evaluate the application for use, may ask a similar question about a related security risk. The prior answer may be supplied to the second user's question based on the fact that both questions relate to a similar or related security issue. In this way, more data may be made available in a more efficient way for a user to evaluate an application for use.
Retuning to process 600, in some cases operation 604 may be performed continuously, periodically, or aperiodically, or based son a triggering event, such as an updated compliance or audit report. In some cases, the frequency of the monitoring individual evidence sources may be determined by user selection or configurator, or based on the type of evidence source. For example, live evidence may be monitored whenever it is made accessible to the risk assessment service. Compliance and audit report information may be monitored at given intervals, or when a new report or certification is published. Similarly, additional information provided by the application vendor may be monitored and detected when it is made available, or at regular intervals, as a few examples.
Process 600 may proceed to operation 608, in which it may be determined if a change is detected in one or more evidence sources. If no change is detected, process 600 may loop back through operations 604 and 606, until a change is detected. When a change is detected, at operation 608, it may then be determined if the change satisfies a mitigation criteria, which may dictate when actions should be taken immediately or in a short time from detection, to mitigate security risks, breaches of data, etc. If the change does satisfy a mitigation criteria, then a mitigation action may be initiated, at operation 610. In some cases, operation 610 may include triggering an action to be taken by a security service, such as may be provided by a computing resource service provider 102.
Process 600 may then proceed to operation 616, in which a notification of the change may be generated and/or made available to the user, and/or the risk assessment for the application updated. If the change that is detected does not satisfy a mitigation criteria, at operation 608, process 600 may proceed directly to operation 616. Upon completion of operation 616, process 600 may loop back to operation 604 and continue to monitor the application. In some cases, operation 616 may include updating the risk assessment and/or sending a notification to a user upon detection of the change, periodically, or at various other times.
In an embodiment, the illustrative system includes at least one application server 708 and a data store 710, and it should be understood that there can be several application servers, layers or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. Servers, in an embodiment, are implemented as hardware devices, virtual computer systems, programming modules being executed on a computer system, and/or other devices configured with hardware and/or software to receive and respond to communications (e.g., web service application programming interface (API) requests) over a network. As used herein, unless otherwise stated or clear from context, the term “data store” refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed, virtual or clustered system. Data stores, in an embodiment, communicate with block-level and/or object-level interfaces. The application server can include any appropriate hardware, software and firmware for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling some or all of the data access and business logic for an application.
In an embodiment, the application server provides access control services in cooperation with the data store and generates content including but not limited to text, graphics, audio, video and/or other content that is provided to a user associated with the client device by the web server in the form of HyperText Markup Language (“HTML”), Extensible Markup Language (“XML”), JavaScript, Cascading Style Sheets (“CSS”), JavaScript Object Notation (JSON), and/or another appropriate client-side or other structured language. Content transferred to a client device, in an embodiment, is processed by the client device to provide the content in one or more forms including but not limited to forms that are perceptible to the user audibly, visually and/or through other senses. The handling of all requests and responses, as well as the delivery of content between the client device 702 and the application server 708, in an embodiment, is handled by the web server using PHP: Hypertext Preprocessor (“PHP”), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example. In an embodiment, operations described herein as being performed by a single device are performed collectively by multiple devices that form a distributed and/or virtual system.
The data store 710, in an embodiment, includes several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. In an embodiment, the data store illustrated includes mechanisms for storing production data 712 and user information 716, which are used to serve content for the production side. The data store also is shown to include a mechanism for storing log data 714, which is used, in an embodiment, for reporting, computing resource management, analysis or other such purposes. In an embodiment, other aspects such as page image information and access rights information (e.g., access control policies or other encodings of permissions) are stored in the data store in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store 710.
The data store 710, in an embodiment, is operable, through logic associated therewith, to receive instructions from the application server 708 and obtain, update or otherwise process data in response thereto, and the application server 708 provides static, dynamic, or a combination of static and dynamic data in response to the received instructions. In an embodiment, dynamic data, such as data used in web logs (blogs), shopping applications, news services, and other such applications, are generated by server-side structured languages as described herein or are provided by a content management system (“CMS”) operating on or under the control of the application server. In an embodiment, a user, through a device operated by the user, submits a search request for a certain type of item. In this example, the data store accesses the user information to verify the identity of the user, accesses the catalog detail information to obtain information about items of that type, and returns the information to the user, such as in a results listing on a web page that the user views via a browser on the user device 702. Continuing with this example, information for a particular item of interest is viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the context of web pages, but are more generally applicable to processing requests in general, where the requests are not necessarily requests for content. Example requests include requests to manage and/or interact with computing resources hosted by the system 700 and/or another system, such as for launching, terminating, deleting, modifying, reading, and/or otherwise accessing such computing resources.
In an embodiment, each server typically includes an operating system that provides executable program instructions for the general administration and operation of that server and includes a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, if executed by a processor of the server, cause or otherwise allow the server to perform its intended functions (e.g., the functions are performed as a result of one or more processors of the server executing instructions stored on a computer-readable storage medium).
The system 700, in an embodiment, is a distributed and/or virtual computing system utilizing several computer systems and components that are interconnected via communication links (e.g., transmission control protocol (TCP) connections and/or transport layer security (TLS) or other cryptographically protected communication sessions), using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate in a system having fewer or a greater number of components than are illustrated in
The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices that can be used to operate any of a number of applications. In an embodiment, user or client devices include any of a number of computers, such as desktop, laptop or tablet computers running a standard operating system, as well as cellular (mobile), wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols, and such a system also includes a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. In an embodiment, these devices also include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network, and virtual devices such as virtual machines, hypervisors, software containers utilizing operating-system level virtualization and other virtual devices or non-virtual devices supporting virtualization capable of communicating via a network.
In an embodiment, a system utilizes at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially available protocols, such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), User Datagram Protocol (“UDP”), protocols operating in various layers of the Open System Interconnection (“OSI”) model, File Transfer Protocol (“FTP”), Universal Plug and Play (“UpnP”), Network File System (“NFS”), Common Internet File System (“CIFS”) and other protocols. The network, in an embodiment, is a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, a satellite network, and any combination thereof. In an embodiment, a connection-oriented protocol is used to communicate between network endpoints such that the connection-oriented protocol (sometimes called a connection-based protocol) is capable of transmitting data in an ordered stream. In an embodiment, a connection-oriented protocol can be reliable or unreliable. For example, the TCP protocol is a reliable connection-oriented protocol. Asynchronous Transfer Mode (“ATM”) and Frame Relay are unreliable connection-oriented protocols. Connection-oriented protocols are in contrast to packet-oriented protocols such as UDP that transmit packets without a guaranteed ordering.
In an embodiment, the system utilizes a web server that runs one or more of a variety of server or mid-tier applications, including Hypertext Transfer Protocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGI”) servers, data servers, Java servers, Apache servers, and business application servers. In an embodiment, the one or more servers are also capable of executing programs or scripts in response to requests from user devices, such as by executing one or more web applications that are implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++, or any scripting language, such as Ruby, PHP, Perl, Python or TCL, as well as combinations thereof. In an embodiment, the one or more servers also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase®, and IBM® as well as open-source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. In an embodiment, a database server includes table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers, or combinations of these and/or other database servers.
In an embodiment, the system includes a variety of data stores and other memory and storage media as discussed above that can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In an embodiment, the information resides in a storage-area network (“SAN”) familiar to those skilled in the art and, similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices are stored locally and/or remotely, as appropriate. In an embodiment where a system includes computerized devices, each such device can include hardware elements that are electrically coupled via a bus, the elements including, for example, at least one central processing unit (“CPU” or “processor”), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), at least one output device (e.g., a display device, printer, or speaker), at least one storage device such as disk drives, optical storage devices, and solid-state storage devices such as random access memory (“RAM”) or read-only memory (“ROM”), as well as removable media devices, memory cards, flash cards, etc., and various combinations thereof.
In an embodiment, such a device also includes a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above where the computer-readable storage media reader is connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. In an embodiment, the system and various devices also typically include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or web browser. In an embodiment, customized hardware is used and/or particular elements are implemented in hardware, software (including portable software, such as applets), or both. In an embodiment, connections to other computing devices such as network input/output devices are employed.
In an embodiment, storage media and computer readable media for containing code, or portions of code, include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules or other data, including RAM, ROM, Electrically Erasable Programmable Read-Only Memory (“EEPROM”), flash memory or other memory technology, Compact Disc Read-Only Memory (“CD-ROM”), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other medium which can be used to store the desired information and which can be accessed by the system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed but, on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention, as defined in the appended claims.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Similarly, use of the term “or” is to be construed to mean “and/or” unless contradicted explicitly or by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected,” when unmodified and referring to physical connections, is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. The use of the term “set” (e.g., “a set of items”) or “subset” unless otherwise noted or contradicted by context, is to be construed as a nonempty collection comprising one or more members. Further, unless otherwise noted or contradicted by context, the term “subset” of a corresponding set does not necessarily denote a proper subset of the corresponding set, but the subset and the corresponding set may be equal. The use of the phrase “based on,” unless otherwise explicitly stated or clear from context, means “based at least in part on” and is not limited to “based solely on.”
Conjunctive language, such as phrases of the form “at least one of A, B, and C,” or “at least one of A, B and C,” (i.e., the same phrase with or without the Oxford comma) unless specifically stated otherwise or otherwise clearly contradicted by context, is otherwise understood within the context as used in general to present that an item, term, etc., may be either A or B or C, any nonempty subset of the set of A and B and C, or any set not contradicted by context or otherwise excluded that contains at least one A, at least one B, or at least one C. For instance, in the illustrative example of a set having three members, the conjunctive phrases “at least one of A, B, and C” and “at least one of A, B and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}, and, if not contradicted explicitly or by context, any set having {A}, {B}, and/or {C} as a subset (e.g., sets with multiple “A”). Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of A, at least one of B and at least one of C each to be present. Similarly, phrases such as “at least one of A, B, or C” and “at least one of A, B or C” refer to the same as “at least one of A, B, and C” and “at least one of A, B and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}, unless differing meaning is explicitly stated or clear from context. In addition, unless otherwise noted or contradicted by context, the term “plurality” indicates a state of being plural (e.g., “a plurality of items” indicates multiple items). The number of items in a plurality is at least two but can be more when so indicated either explicitly or by context.
Operations of processes described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. In an embodiment, a process such as those processes described herein (or variations and/or combinations thereof) is performed under the control of one or more computer systems configured with executable instructions and is implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. In an embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. In an embodiment, a computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transitory signals (e.g., a propagating transient electric or electromagnetic transmission) but includes non-transitory data storage circuitry (e.g., buffers, cache, and queues) within transceivers of transitory signals. In an embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media having stored thereon executable instructions that, when executed (i.e., as a result of being executed) by one or more processors of a computer system, cause the computer system to perform operations described herein. The set of non-transitory computer-readable storage media, in an embodiment, comprises multiple non-transitory computer-readable storage media, and one or more of individual non-transitory storage media of the multiple non-transitory computer-readable storage media lack all of the code while the multiple non-transitory computer-readable storage media collectively store all of the code. In an embodiment, the executable instructions are executed such that different instructions are executed by different processors—for example, in an embodiment, a non-transitory computer-readable storage medium stores instructions and a main CPU executes some of the instructions while a graphics processor unit executes other instructions. In another embodiment, different components of a computer system have separate processors and different processors execute different subsets of the instructions.
Accordingly, in an embodiment, computer systems are configured to implement one or more services that singly or collectively perform operations of processes described herein, and such computer systems are configured with applicable hardware and/or software that enable the performance of the operations. Further, a computer system, in an embodiment of the present disclosure, is a single device and, in another embodiment, is a distributed computer system comprising multiple devices that operate differently such that the distributed computer system performs the operations described herein and such that a single device does not perform all operations.
The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
Embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for embodiments of the present disclosure to be practiced otherwise than as specifically described herein. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.
All references including publications, patent applications, and patents cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20150356477 | Milkman | Dec 2015 | A1 |
| 20200287910 | Zerrad | Sep 2020 | A1 |
