A system and method for predicting platform security requirements

Abstract

The system may be configured to evaluate the state or condition of a stack of services. Some embodiments may include monitoring the source code, base image, and runtime environment of each of a plurality of microservices in the stack via a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively. Each of the tools may be selectable and may include at least one scanner or sensor configured to output historical data. The microservices may then operate with respect to the same business objectives or set of rules. The method may further include iteratively predicting a security assessment of the stack of microservices via the model based on the first, second, and third scores, and determining, based on the predicted assessment, the amount of resources required by a security team to enhance the security assessment via resource implementation.

Description

[Technical Field]

[0001] (Cross-reference to related applications) This application claims priority to U.S. Patent Application No. 17 / 980,336, filed 3 November 2022, entitled “SYSTEMS AND METHODS FOR PREDICTING A PLATFORM SECURITY CONDITION,” which is incorporated herein by reference in its entirety.

[0002] (Technical field) This disclosure generally relates to systems and methods for monitoring a stack of cloud services.

[0003] (background) Security attacks can occur dynamically against one or more vulnerabilities at a computationally feasible time. For example, one risk may be resolved, only for another threat to emerge shortly thereafter. For application security (AppSec) teams, it is becoming increasingly difficult to fully assess the state of the entire cloud platform and resolve issues before users and / or the business are negatively impacted.

[0004] AppSec can be measured as a performance metric, typically evaluating its success in terms of progress toward an organization's long-term goals. Application vulnerabilities contribute to information technology (IT) risks. They are a factor in overall business risks, and businesses often intend to reduce IT risks to zero.

[0005] Known monitoring tools and / or security utilities are not capable of providing a complete overview of the entire ecosystem related to the needs of the application platform. Such tools are, for example, limited to evaluating only the current state. However, security degradation (or enhancement) can only be detected and addressed after it has occurred within the system. This creates a need for proactive methods that can predict changes in security values. [Overview of the project]

[0006] A system and method are disclosed for determining at least one of the overall state of a global cloud security platform, the history of previous components, and the state of the current components. Accordingly, one or more aspects of this disclosure relate to a method for monitoring the (i) source code, (ii) base image (BI), and (iii) runtime environment of each of several microservices in a stack via a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively. Each security tool may be optional and may comprise at least one scanner or sensor configured to output historical data. The microservices (e.g., of a cloud platform) may operate in a unified manner. For example, the microservices may share a set of operating parameters, including the same set of business objectives and / or rules. The method may further include iteratively predicting a security rating of a stack of microservices via a model based on the first, second, and third scores, and determining, based on the predicted rating, the amount of resources required for a security team to enhance the security rating through resource implementation.

[0007] The method is implemented by a system comprising one or more hardware processors configured by machine-readable instructions and / or other components. The system includes one or more processors and other components or media, such as machine-readable instructions, on which the machine-readable instructions can be executed. Implementations of any of the described techniques and architectures may include instructions stored in a method or process, apparatus, device, machine, system, or computer-readable storage device.

[0008] Details of particular implementations are set forth in the accompanying drawings and the description below. Throughout this specification, like reference numerals may refer to like elements. Other features will be apparent from the following description, including the drawings and claims. However, the drawings are for illustrative and explanatory purposes only and are not intended as a definition of the scope of the present disclosure.

Brief Description of the Drawings

[0009] [Figure 1] An example of a system for dynamically predicting the security state of a microservices stack according to one or more embodiments is illustrated. [Figure 2] Aspects of a software release to be evaluated (e.g., containerized) according to one or more embodiments are illustrated. [Figure 3] An example of data that can be used by a base image scan tool according to one or more embodiments is illustrated. [Figure 4] [[ID=2I]]Vulnerability mapping from quantitative scores to qualitative ratings according to one or more embodiments is illustrated. [Figure 5] An example of data that can be used by an environment scan tool according to one or more embodiments is illustrated. [Figure 6] A mismatch between vulnerability scores and the number of vulnerabilities according to one or more embodiments is illustrated. [Figure 7-8] An example of data that can be used by a source code scan tool according to one or more embodiments is illustrated. [Figure 9]An example of a weighted value and a predicted value that can be predicted according to the above embodiments is illustrated. [Figure 10] An example of a case where it may be necessary to apply a patch to maintain or reduce a vulnerability score due to an increase in vulnerability according to one or more embodiments is illustrated. [Figure 11] A process for predicting and reporting a security state according to one or more embodiments is illustrated.

Best Mode for Carrying Out the Invention

[0010] As used throughout this application, the term "may" is used in an permissive sense (i.e., having the possibility of doing) rather than in a mandatory sense (i.e., must do). Terms such as "include", "including", "includes" mean including but not limited to these. As used herein, the singular forms "a", "an" and "the" include the plural unless the context clearly dictates otherwise. As adopted herein, the term "number" shall mean an integer of 1 or greater than 1 (i.e., plural).

[0011] As used herein, the description that two or more parts or components are "coupled" means that the parts are joined or cooperate directly or indirectly, i.e., through one or more intermediate parts or components, as long as a link occurs. As used herein, "directly coupled" means that two elements are in direct contact with each other.

[0012] Unless otherwise specified, throughout this specification, discussions using terms such as "processing", "computing", "calculating", "determining", etc. are understood to refer to actions or processes of a specific apparatus such as a dedicated computer or similar dedicated electronic processing / computing device.

[0013] This disclosure describes a method for creating a security score for a project using any number of security sensors. The sensors may be configured to output data in a specific manner. For example, a release checklist may be created for each microservice on a cloud platform. Third parties are risk factors, and the reports envisioned herein may be more detailed regarding third parties, and may involve base image security and / or core reviews, etc. The reports may be customizable by the user (for example, via the UI device 18 in Figure 1). Using the security score, the processor 20 of system 10 in Figure 1 may be configured to determine quantitative and / or qualitative work that needs to be performed by the security team to maintain or improve at least the current security level or the security state of the project. For example, using an expectation module, the processor 20 may be configured to estimate the possible security state for subsequent releases. In this example or another, system 10 may enable the security team to proactively take appropriate measures.

[0014] The approach disclosed herein further improves upon known manual testing methods that AppSec teams can use to consider the behavior of each microservice and the relationships between them, for example, identifying potential business impacts. However, this testing method relies on errors in business logic and cannot be easily automated.

[0015] The microservices envisioned herein may have an architecture, structure, and / or style that exhibits several aspects of a service-oriented architecture (SOA). These microservices may form a collection of loosely coupled services, for example, these services may be granular, have lightweight and non-enforcing protocols (e.g., via containers), and / or have reduced network communication requirements (e.g., to maintain loose coupling). Each microservice may include its own project by a team of developers, for example, with its own development lifecycle, habits, and routines. A microservice may comprise three layers: microservice source code, source code dependencies (which may also be known as third parties), and a runtime environment.

[0016] In some embodiments, microservices implemented across multiple cloud computers may be implemented using different programming languages, databases, hardware and software environments, and / or serverless computing, based on business and / or application needs. Microservices scale up only those microservices that support resource-constrained functions, thereby providing the benefits of resource and cost optimization. Microservices can be deployed independently and have endpoints that can be logically coupled with other microservices to build a variety of applications.

[0017] The approach disclosed herein enables AppSec teams to eliminate the effort that might otherwise be required for manual testing, which is used in scenarios where existing automated tools are insufficient. Thus, system 10 defines an implementation where additional work and / or resources may be applied to fix one or more security issues identified by system 10.

[0018] The approaches disclosed herein further enable the measurement of one or more information technology (IT) risks and at least a simplified estimate of how much work may be required to maintain at least the security status of the same component. The approaches disclosed herein may further enable the aggregation of the security status of each component and / or platform into, for example, a single metric. In some embodiments, the security status of each microservice component and / or platform may be aggregated into a single metric (for example, to simplify by summing or otherwise combining the scores of individual microservices).

[0019] The system 10 shown in Figure 1 includes a processor 20 (having components described later), sensors 50 (described later), cloud computers 90 (e.g., 90-1, 90-2, ... 90-n, where n is a natural number), a network 70, and peripheral structures for the processor 20 (likewise described later). The approach disclosed herein may be further extensible by design, for example, considering whether all security tools provide historical data and the current state of the application. In a non-limiting example, if a seasonal use detects a composite forecast (season-based and trend-based) that could result in CPU utilization exceeding 90% within the next hour, the user may request a trigger from the microservices manager. In one embodiment, when these conditions are met, the output of time-series data may be triggered for consumption by the microservice in question.

[0020] As shown in Figure 1, the processor 20 is configured to execute one or more computer program components via machine-readable instructions. The computer program components may include one or more of the following: an information component 30, a sensor scoring component 32, a monitoring component 34, a security rating component 36, a resource estimation component 38, a microservices releasing component 40, a management / UI component 42, and / or other components. The processor 20 may be configured to execute components 30, 32, 34, 36, 38, 40, and / or 42 by software, hardware, firmware, a combination of software and hardware and / or firmware, and / or other mechanisms for configuring processing performance on the processor 20.

[0021] In Figure 1, components 30, 32, 34, 36, 38, 40, and / or 42 are illustrated as coexisting within a single processing unit. However, in embodiments where the processor 20 comprises multiple processing units, it should be understood that one or more of components 30, 32, 34, 36, 38, 40, and / or 42 may be located separately from other components. For example, in some embodiments, each of processor components 30, 32, 34, 36, 38, 40, and 42 may comprise a separate and distinct set of processors. The descriptions of the functionality provided by the different components 30, 32, 34, 36, 38, 40, and / or 42 described below are illustrative and not intended to be limiting, as any one of components 30, 32, 34, 36, 38, 40, and / or 42 may provide more or fewer functions than those described. For example, one or more of components 30, 32, 34, 36, 38, 40, and / or 42 may be excluded, and some or all of their functionality may be provided by other components 30, 32, 34, 36, 38, 40, and / or 42. As another example, the processor 20 may be configured to perform one or more additional components that perform some or all of the functionality attributable to one or less of components 30, 32, 34, 36, 38, 40, and / or 42.

[0022] On a daily basis, there are at least some vulnerabilities that affect a platform (e.g., a cloud platform), and achieving a vulnerability-free profile is virtually impossible. For example, the time required to apply patches is often longer than the time required to discover new vulnerabilities in the software or technology that make up the component itself. However, vulnerability mitigation is not the same as risk mitigation. For example, vulnerabilities found in third-party dependencies or in the source code dependencies of one or more microservices may each have different levels of severity and component impact compared to, for example, manually discovered vulnerabilities.

[0023] Vulnerabilities found manually may not be associated with platform components and may rather be speculations about the legitimate functionality of the platform. Therefore, in some embodiments, the need for automated scan review may be reduced or eliminated. Fixing 1,000 critical vulnerabilities associated with third-party source code (e.g., via a predetermined amount of resources and / or within a specific timeframe) in response to reports from one or more scanners 50 may (e.g., automatically) adjust the risk level to that of fixing one critical vulnerability found manually. Each microservice or utility may have its own vulnerability profile and / or associated database, for example, including separate sets of Type 1 (false positive) and Type 2 (false negative) errors. In some embodiments, a monitoring component 34 may monitor each profile and / or database individually, and a security assessment component 36 may generate a unified metric for an overview of the application's state without considering the source of information, for example. For example, only historical data and a snapshot of the current state may be required.

[0024] The approaches disclosed herein can reduce IT risk levels to acceptable levels over time and / or highlight trends to developers or auditors by predicting, for example, when to make reservations and when resource-based effort will be required. For example, these options may include updating the core image, updating core image components, updating third parties, removing third parties, replacing third parties, disabling code endpoints, adding new layers of protection to endpoints (e.g., input data sanitizers), and / or other preferred options.

[0025] Different types of microservices may be integrated or form part of a stack (for example, integrated through the same business objectives and / or set of rules). In some embodiments, the monitoring component 34 may analyze the code, base image, and environment of each microservice in the stack. For example, the monitoring component 34 may acquire and store historical data through several predetermined tools, such as Anchore® / Trivy® (for example, for vulnerability checking of the base image (BI)), DTRACK (for example, for vulnerability checking of the environment), Sonar® (for example, for vulnerability checking of the source code), and / or other images, environments, and / or code scanners (but not limited to these).

[0026] In some embodiments, the historical data may be displayed to the user of system 10 (for example, via a UI device 18).

[0027] In this or another example, the outputs of these tools or devices may be combined. Each tool included in the prediction database 60 may be used as a data source by the monitoring component 34 and may be required to provide at least one of the following: a list of security vulnerabilities, or a vulnerability score (or a string that can be converted to a score) for each vulnerability included in the list. Optionally, a vulnerability score converter (e.g., EPSS) may be required instead or in addition.

[0028] The assumed analysis of at least one sensor 50 (e.g., by the sensor whose score is calculated) may involve the runtime environment and / or runtime system, the latter typically serving as a gateway through which a running program interacts with the runtime environment. The environment may include subsystems present on both the computer where the program was created and the computer on which the program is intended to run or execute. A microservices stack may be an exemplary environment. The runtime system or environment may include managed structures (e.g., application memory, operating system interfaces, etc.).

[0029] The runtime environment may include state values ​​and / or active entities that a program can interact with during execution. For example, environment variables, which are a feature of the OS, may be part of the runtime environment, and a running program may access them through the runtime system. The execution model may be implemented, at least partially, in the runtime system, and this may belong to the program itself. A programming language may include a runtime system (including, for example, features to assist with support such as type checking, debugging, code generation, and optimization).

[0030] In some embodiments, the security assessment component 36 can predict short-term security assessments when the requirements for the next platform release are known, and the requirements for the next release may be different, and such a predictive model may not be required. However, such a predictive model may be implemented in the long term if required, for example, based on historical factors and current dynamics.

[0031] In some embodiments, the security assessment component 36 may predict or forecast the security conditions or risk levels of the microservice stack continuously (e.g., indefinitely), frequently, holistically, and / or iteratively. The frequency of predictions may be adjusted to be daily, or at other regular and / or configurable intervals. For example, it may be possible to recalculate several coefficients each time (e.g., in the backend, at a shorter time than required for the current period or security assessment) to express them as new state predictions for the current interval, timeframe, elapsed time, or cycle. In non-limiting examples, stack releases may be at an adjustable frequency (e.g., daily, monthly, etc.) and / or when the stack's security conditions are required to be checked.

[0032] In some embodiments, the user may be provided with the option to choose the level of understanding of the algorithm itself (e.g., at the mathematical level, or a basic explanation). For example, access to the algorithm may not be provided, but the ability to modify the coefficients of the Holt-Winters model may be enabled.

[0033] In some embodiments, in response to the sensor scoring component 32 acquiring historical data, the monitoring component 34 may track changes in the project's status according to its release lifecycle. In these and other embodiments, each layer may apply additional checks individually and automatically to exclude, for example, type 1 (false positive) errors, while type 2 errors may be false negatives. For example, scores from an Exploit Prediction Scoring System (EPSS) may be used in the monitoring component 34 and / or the security rating component 36. Each score may indicate the probability that a software vulnerability will be exploited during deployment and can be used to prioritize vulnerability remediation work. For example, a higher score indicates a higher probability that the vulnerability will be exploited.

[0034] In some embodiments, the results from the sensor's scoring component 32 may be incomplete or unreliable as is. For example, the resulting score (or calculation thereof) may need to be weighted, and some of the detected vulnerabilities may be substantially minor and distracting. Thus, the disclosed embodiments may reduce the time spent with the scanner 50 and increase the time spent on fieldwork by, for example, the security team.

[0035] In some embodiments, the monitoring component 34 and / or the security assessment component 36 may retrieve a model from the database 60 for predicting per-microservice values ​​(e.g., release points) over at least one entire cycle. In a non-limiting example, as described in detail below, the monitoring component 34 and / or the security assessment component 36 may retrieve a Holt-Winters model from the database 60 for predicting per-microservice values ​​(e.g., release points) over at least one entire cycle. For example, there may be a significant increase in vulnerabilities over a cycle, but the predicted values ​​may then immediately drop sharply and then show an increasing trend (for example, this may indicate the start of a new cycle). In this example or another, the component may not be included (e.g., it has been used before), and the information is considered to have been calculated by default in system 10.

[0036] In some embodiments, the security assessment component 36 and / or resource estimation component 38 may operate without excluding Type 1 errors (i.e., false positives). For example, the possibility of missing or skipping vulnerabilities may be eliminated by enriching the data and leveraging its greater potential. Rather than unnecessarily acquiring irrelevant information, the disclosed embodiments may acquire more information than otherwise required, for example, increasing the number of false positives and decreasing the number of false negatives.

[0037] In some embodiments, the monitoring component 34 and / or the security assessment component 36 may use a time series to detect the presence of anomalies and subsequently alert the developer.

[0038] In some embodiments, the monitoring component 34 and / or the security assessment component 36 may obtain information for each season, timestamp, or other period according to the release cycle for all cloud microservices of the cloud computer 90. For example, the monitoring component 34 and / or the security assessment component 36 may synchronize or otherwise enhance the information for each microservice based on already enhanced information. In this example or another, the components of the processor 20 may measure all microservices in the stack using the available information (for example, in the information component 30), including cases where suitable information is currently lost for one or more of the microservices.

[0039] For example, a component may be currently released or recently released, and a security assessment component 36 may be aware of a vulnerability in that component. However, this awareness may be distributed across all projects, for example, as a pair of integrated / individual values. If this number increases, for example, above a base level, a resource estimation component 38 or a microservice releasing component 40 may generate and / or send a report (for example, notifying the need for a situation review). The manual score may then decrease, either because the estimate may be unreasonable or for other preferred reasons. In some embodiments, additional scans by the sensor 50 may be performed to further enrich the collected information and modify the variables. In this way, the resource estimate (e.g., effort) may be reduced by obtaining updated information that would otherwise not have been collected.

[0040] In some embodiments, the security rating component 36 may determine the security rating by summing up security scores or values ​​for each project or thread (for example, related to the output of one or more sensors 50 for each microservice at a given point in time).

[0041] In some embodiments, if the security score meets a criterion (e.g., is too high), the developer may be triggered to provide a new release. The resulting new security score may then differ from the previous security score (e.g., be lower). Therefore, applying a security patch may be recommended. In some embodiments, the sensor scoring component 32, monitoring component 34, and / or security rating component 36 may measure possible security values, including by adhering to certain boundaries. For example, if the project's security score exceeds 50, the management / UI component 42 may communicate with the developer to determine what work to do and how that work will resolve the issue.

[0042] In some embodiments, the score or representative value calculated by the security rating component 36 may be intended to be reduced. For example, the resource estimation component 38 and / or the microservice releasing component 40 may reduce the amount of human effort required to remediate one or more vulnerabilities in the microservice stack (e.g., implemented on the cloud computer 90) (e.g., by configured objectives). In this or another example, the processor 20 components may be configured to adjust the time required for resources to perform remediation and / or address other security responsibilities associated with one or more microservices in the stack. Also in either of these or another example, the resource estimation component 38 and / or the microservice releasing component 40 may be involved in determining which tasks or projects should be given higher priority in order to better address security objectives. In this determination, these components may further determine whether it is safe to delay the implementation of certain resources for lower-priority security tasks without significantly increasing the risk of, for example, system crashes or malicious activity.

[0043] In some embodiments, the resource estimation component 38 and / or the microservices releasing component 40 may be configured to determine that certain resources (e.g., security experts and / or software tools) are needed at a particular time, enabling the scheduling of a security team such that sufficient personnel are allocated and / or otherwise prepared to resolve the issues predicted by the security assessment component 36.

[0044] In some embodiments, the resource estimation component 38 may be more proactive by enabling the estimation of the amount of work that needs to be put into the application (for example, to at least prevent a degradation in security ratings and / or to improve such ratings).

[0045] In some embodiments, the resource estimation component 38 and / or the microservice's releasing component 40 may, for example, obtain a security score (e.g., generated by component 36 and / or the sensor's scoring component 32) when communicating with one or more developer teams. For example, scores, predictions, and / or ratings exceeding thresholds may trigger a project metric report.

[0046] In some embodiments, the microservice releasing component 40 may be involved in multiple incremental releases, for example, to ensure that security conditions are improved in accordance with adjustments to one or more microservices. In these or other embodiments, the risk levels associated with the monitoring component 34 and / or the security assessment component 36 may be configurable (for example, by the user).

[0047] In some embodiments, the AppSec team and / or developers may determine the security level based on a set of documentation (e.g., standards) that defines how it operates. For example, the stricter the requirements of the aforementioned set of documentation, the lower the security score may be.

[0048] In some embodiments, the resource estimation component 38 may make predictions that result in a lower security rating determined by component 36. For example, an AppSec team may be triggered to take action based on a security level breach before the risk materializes, and / or a developer may be triggered to take action on one or more vulnerabilities based on another security level breach. In this and other examples, the AppSec team may be triggered to take action earlier, resulting in a more secure outcome than obtaining a score when it might be too late for the security team to provide patches or other countermeasures.

[0049] In some embodiments, the management / UI component 42 or another component of the system 10 may be configured to provide a selectable set of components and / or microservices requested by the user (for example, those in a table via the UI device 18). Once one or more of these sets are selected, the monitoring component 34 then begins evaluating one or more of them, and the microservice staff Ku It can be configured to determine the overall score for the next release.

[0050] In some embodiments, the monitoring component 34 may determine that not all microservices have been updated or changed, but it may then need to recalculate the overall score (i.e., for all microservices related to and / or selected by the user). For example, one component or analysis tool may not be updated for several months, while other components or analysis tools may be updated on a weekly basis. Fixing vulnerabilities only in recently updated components may be insufficient, but this is because staff Ku This is because the number of vulnerabilities can continue to increase if components that haven't been recently updated are changed or not updated.

[0051] Known security tools can create snapshots of the current state, but only at compile time or during product preparation (e.g., at distribution). Thus, in contrast to an approach where sensors are not simply triggered for information gathering, the sensor scoring component 32 can communicate with sensors 50 accompanying these tools to trigger, for example, the collection of data about relevant operations, and then generate a report. The monitoring component 34 can eliminate blind spots in visibility into the context surrounding this component. For example, the monitoring component 34 and / or the security rating component 36 may identify one or more trends (e.g., the behavior of another component) as the number of risk factors increases. An increase in vulnerabilities provides harmful feedback to feedback-driven links on the component's backend. In some embodiments, the security rating component 36 may estimate a component value or security score (e.g., for a release the next day) that describes the situation.

[0052] In some embodiments, the sensor or scanner 50 may include a tool or application that collects data and makes reactive inferences. For example, an information component 32 and / or a sensor scoring component 32 may take network data from the security sensor 50 and create vulnerability notifications regarding attacks (e.g., those that can be measured with a high probability by a monitoring component 34).

[0053] In some embodiments, the management / UI component 42 may perform actions to deploy the platform via one or more configuration control files, including predicting the state of the microservice stack. For example, this component may make available all components that each provide collectible output data and synchronize them in the backend. As a result, the user experience is unaffected by eliminating contingencies of security vulnerabilities, due to the security rating calculated by component 36 being based on all relevant microservices. In this example or another, the resource estimation component 38 may determine the amount of technical work, the type of resource, and / or the time it will take to perform the work.

[0054] Each microservice release may be implemented according to a release quality checklist. For example, the AppSec team may check and determine the level or amount of security success, such as the absence of anticipated vulnerabilities. This approach may eliminate manual testing. In this or another example, vulnerabilities may not have a security-degrading impact on the microservice with respect to layers such as the microservice source code, source code dependencies, and runtime environment.

[0055] Figure 2 illustrates the configuration of an evaluated (e.g., containerized) software release according to one or more embodiments. As shown in the example in Figure 2, each microservice tool (e.g., one that may operate using a sensor scoring component 32) may focus on the security of one such layer 99 (e.g., code 99-1, environment 99-2, ... and / or dependency relationships 99-n, where n is any natural number) and may provide at least the current application state for subsequent analysis. In some embodiments, another layer may be added to contribute to an automated Java bytecode security review when developing a suitable coding and configuration model (e.g., a father for the application). In some embodiments, the application may be based on the Spring Boot application framework.

[0056] In some embodiments, the tools implemented by the sensor 50 may vary depending on the use case, due to the preferences and / or requirements of the relevant AppSec team and due to continuous integration (CI), which may constitute part of the continuous development / delivery (CD) process. Thus, the components of the processor 20 may be configured to interoperate with a set of security sensors 50 that output any amount of data (e.g., of considerable depth). Furthermore, third-party functionalities may be encapsulated with one another, for example, by covering their respective functionalities or source code. As a result, the output from the security assessment and resource estimation component 38 calculated by component 36 may be more accurate and / or precise.

[0057] The resulting security assessment can be more accurate and / or precise, for example, through a monitoring component 34 that relies on scores from three different sensors and a component 36 that proactively makes predictions based on those scores. Thus, the techniques envisioned for system 10 can not be improved solely by using the Exploit Prediction Scoring System (EPSS) and the Common Vulnerability Scoring System (CVSS), but can also be improved by a method in which values ​​from sensor 50 are recalculated.

[0058] As mentioned above, fuzzing techniques can be used on APIs, for example, to measure security levels. Fuzzing results can be treated as data that can be mapped to (for example, given) requirements. Since fuzzing results can be used in construction, they may also be used as additional layers. That is, this tool is not intended as an implementation for checking base images, environments, or source code vulnerabilities, but rather as an additional aspect or layer.

[0059] Figure 3 illustrates an example of the data available through a base image scan tool. In one example, SysDig can be used as a BI review tool. In another example, Anchore can be used as a BI review tool, which may provide all the necessary data as shown in Figure 3.

[0060] Figure 4 illustrates the vulnerability mapping from quantitative scores to qualitative assessments. An example of a sensor-based vulnerability reporting tool is Anchore. For example, if P is an Anchore project with m vulnerabilities, Anchore may not be able to provide the number of vulnerabilities. As shown in Figure 4, for each vulnerability D, CVSS D It can be mapped using metrics. The total score of an Anchore project is: It can be characterized as TIFF0007866689000001.tif30159.

[0061] Figure 5 illustrates an example of data available from an environmental scanning tool. DTrack can be an example of an environmental review tool that provides all the necessary data, as shown in Figure 5. DTrack can also provide a vulnerability number converter—EPSS scores. As illustrated in an example in Figure 6, the number of EPSS scores available for vulnerability checking may not match the number of vulnerabilities. Figure 6 illustrates the discrepancy between vulnerability scores and the number of vulnerabilities.

[0062] In some embodiments, the sensor scoring component 32 may implement a converter for converting the sensor score to an EPSS or similar value, for example. For example, deeply nested vulnerabilities may actually be determined to have a lower level of risk than initially or previously estimated (e.g., via DTrack). And this may be targeted across releases. DTrack or another tool may not display two or more nested vulnerabilities, but may detect them. For example, critical vulnerabilities (e.g., those with an increased chance of a fatal blow) may be detected. This may be yet another layer of dependency.

[0063] The approaches disclosed herein can resolve errors, for example, by providing additional nesting information and / or by providing an EPSS value if the Common Vulnerability Identifier (CVE) does not have one.

[0064] In some embodiments, a component or microservice may be configured to read its JSON file. However, in some cases, conversion of JSON to HTML may not be implemented, and use of certain dependencies added to the source code by a third party may be enabled. This third party may, for example, convert JSON to an HTML file as needed. One or more dependencies inherent in each microservice may be involved in security risks and / or other vulnerabilities. Components of a microservice may be considered third parties.

[0065] In one example, let P be a DTrack project having n dependencies D. The DTrack EPSS dependency score ES D is the product of the EPSS vulnerability score and the dependency score, e.g., it may be TIFF0007866689000002.tif20156. If a dependency does not have an associated EPSS D as shown in FIG. 4, the CVSS D metric may be used (which may be mapped as follows, for example, or mapped to other values depending on experience).

[0066] EPSS D For dependencies without a value, DTrack may provide a CVSS D string. For each range, a worst-case scenario may be estimated. For example, in that scenario, there may be nothing executable in the project. And in another example or scenario, a medium vulnerability may be evaluated based on experience to have a CVSS D = 0.69 or other value.

[0067] In one example, let P be k vulnerabilities having EPSS D values, and let l vulnerabilities have a CVSS D score. The DTrack EPSS project score ES P is the sum of the product of the EPSS dependency score and all dependency scores, i.e., It could be TIFF0007866689000003.tif15158.

[0068] In one example, P might be given vulnerabilities found in components nested across m layers of dependencies. Nested dependency score DS Dm This is the CVSS dependency score and Multiplication with the depth value of TIFF0007866689000004.tif3017, i.e. It could be TIFF0007866689000005.tif30121. And nested dependent project score DS P This is the sum of all nested dependency scores, i.e. It could be TIFF0007866689000006.tif30142.

[0069] Total DTrack Project Score TS p The total score is the sum of the nested dependency score and the DTrack EPSS project score, i.e. It could be TIFF0007866689000007.tif30170.

[0070] For example, ShiftLeft can be used to check for vulnerabilities in source code. In another example, Sonar can be used as a static code review tool to provide all the necessary data, as shown in Figure 7-8. Figure 7-8 illustrates an example of the data available to a source code scanning tool.

[0071] For example, a Sonar dashboard might include a list of vulnerabilities, each with its own severity value. Severity names may differ from those in CVSS, but these values ​​may be the same in the backend. In this or another example, Blocker might be associated with Critical, and Critical might be associated with High. P might be given a Sonar project with m vulnerabilities. Sonar may not provide the number of vulnerabilities. Therefore, for each vulnerability D, CVSS D A metric can be used, which can be mapped as shown in the example in Figure 4. And the total sonar project score is This could be TIFF0007866689000008.tif30157. Total Project Security Score (TPSS) P This is the sum of all independent tool scores for each layer, i.e. It could be TIFF0007866689000009.tif20144.

[0072] The Holt-Winters model is a time-series behavior model, a method for modeling three aspects of a time series, for example. The first can be a standard value (representative), the second can be the slope over time (trend), and the third can be a periodic repeating pattern (seasonality). In one example, the release lifecycle is periodic, and seasonality requirements can be considered by default. In this example, or another, it can be assumed that the slope is at least the same as before. Also, the average value can be calculated as a representative value from historical project data.

[0073] Depending on the time-point model, the security value may be assumed to be the sum of a base (raw) value, a slope value, and a seasonality value, for example, the seasonality value being associated with the slope. The seasonality component in the model may describe a periodic change centered on the slope, which may be characterized, for example, by the length of the season.

[0074] Since the historical data for all layers can be defined and retrieved by the information component 30, the security assessment component 36 can implement a prediction method. The collected data can be associated with a fixed time, as opposed to random data, and therefore may contain additional extractable information.

[0075] In some embodiments, the model for the predictive database 60 is based on a Holt-Winters implementation, which may be involved, for example, in estimating the slope and determining a representative or mean value. For example, the release cycle of the Holt-Winters model may include the point at which a product, component, or microservice (for example, these may be fully functional) is ready for public release. In this example or another, the slope may be sufficient to facilitate one or more peer requests from customers and corresponding modifications (for example, with relevant dates).

[0076] In some embodiments, each season may have timing information, for example, from the beginning to the moment when components are periodically released. In each exemplary cycle, the number of vulnerabilities may increase relatively over the period, but may decrease absolutely over several cycles. Since a release can be at the end of a cycle, the date of that release may affect the project in its best state. The worst security score among all releases may serve as a threshold, and exceeding it marks the project as a "no go" for the release. That is, even if the security score can continuously increase in each cycle, it does not mean that the threshold will be reached in 1, 2, or N cycles. For example, a score of 50 may be achieved at the end of a cycle, but a score of 2 may be achieved at the start of a new cycle. During a cycle, the score can increase by up to 15; that is, the relative score may be +13, but the absolute score may be -35.

[0077] Starting with the simple idea that tomorrow will be the same as yesterday, a reasonable assumption might be that the future depends on the median of n past values. This is called the moving average and can be calculated as follows: TIFF0007866689000010.tif30139. A weighted average, a simple modification of the moving average, allows for more precise predictions through the addition of weight parameters (the sum of the weights is 1). The values ​​can be calculated as follows: TIFF0007866689000011.tif30165.

[0078] The concept behind Brown's model is to weight all available historical data and exponentially decrease the weight values: TIFF0007866689000012.tif20142. Model values ​​can be a weighted average of current and historical values. The weight α is a smoothing coefficient that defines, for example, how quickly the last available historical value is forgotten. For example, by decreasing α, the influence of historical data on the prediction results may increase. And by adding α values, it may be possible to create only one prediction value. For example, by multiplying by the value of y from t, the value may be directly affected.

[0079] Holt et al.'s model can be modified to allow the series to be divided into two parts: level (l) and trend / slope (b). For example, the predicted value can be calculated as follows: l x =α*y x +(1-α)*(l x-1 +b x-1 );b x =β*(l x -l x-1 )+(1-β)*b x-1 and TIFF0007866689000013.tif3041=l x +b x

[0080] The first function (l x) can define levels according to the current value, for example. However, the value can be divided based on past historical data values ​​and trends. Second function (b x The trend can be defined, for example, based on the level change of the current value and past trend values. β can be a new weight value of the weight function.

[0081] The database 60 model can then be modified again to implement the Holt-Winters model, for example, by adding a new component (e.g., seasonality). In some implementations, the seasons could be the software release cycle. The seasonality component could, for example, describe periods centered around trends and levels. Thus, the values ​​can be expected as follows: x =α*(y x -s x-L )+(1-α)*(l x-1 +b x-1 );b x =β*(l x -l x-1 )+(1-β)*b x-1 ;s x =γ(y x -l x )+(1-γ)s x-L and TIFF0007866689000014.tif3072=l x +mb x +s x-L+1+(m-1)modL

[0082] The coefficients α, β, and γ can be calculated using time-series cross-validation. Historical data can have a time-based basis, and this dependency can be protected. Therefore, some implementations can involve stepwise cross-validation. In one example using this model, the security value can be assumed at any given time to be the sum of the base (raw) value, the slope value, and the seasonality value. The seasonality component in the model can describe periodic changes centered on the slope and can be characterized by the length of the season.

[0083] In some embodiments, an algorithmic Holt-Winters model may be implemented for short-term (i.e., for the next release) predictions to identify, for example, security values ​​that are likely to be attainable by an application or microservice. For example, a new database of software releases may describe multiple nested vulnerabilities in a third-party component. Figure 9 shows an exemplary chart of predictions for the same when weighted, and Figure 10 shows information on score reduction patches (which may be applied, for example, in response to an increase in vulnerabilities detected). Figure 10 shows an example where the current project score may be 2.3 and the predicted value may be 7.52, so it may be determined that no further steps are needed to secure the project. The project average may be 3.0, so the component may be acceptable and can be released because it is at least worse than what may have already been released. In other embodiments, the monitoring component 34 and / or the security rating component 36 may tune the model (which may be obtained, for example, from the prediction database 60) for one or more long-term predictions. The time criterion to be met during monitoring for making short-term predictions may be longer than the length of time for each iteration.

[0084] In some embodiments, a set of coefficients may be determined using stepwise time-series cross-validation. For example, the above cross-validation may involve assuming, according to the model, that the security value at each point in time is the sum of the base (raw) value, the slope value, and the seasonality value. The seasonality value may be associated with the slope value. The seasonality component in the model may describe a periodic change centered on the slope and may be characterized by the length of the season.

[0085] Furthermore, since application degradation may manifest as a trend, the project average is taken into consideration. For this reason, this method treats this as a characteristic and does not issue a warning.

[0086] The electronic storage 22 in Figure 1 comprises an electronic storage medium for electronically storing information. The electronic storage medium of the electronic storage 22 may include system storage provided integrally with the system 10 (i.e., substantially inremovably) and / or removable storage that can be detachably connected to the system 10 via, for example, a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage 22 may be a separate component (whole or in part) within the system 10, or the electronic storage 22 may be provided integrally with (whole or in part) one or more other components of the system 10 (e.g., a user interface (UI) device 18, a processor 20, etc.). In some embodiments, the electronic storage 22 may be located in a server together with the processor 20, in a server that is part of an external resource 24, in a UI device 18, and / or elsewhere. The electronic storage 22 may comprise a memory controller and one or more of the following: optical-readable storage media (e.g., optical discs, etc.), magnetic-readable storage media (e.g., magnetic tapes, magnetic hard drives, etc.), charge-based storage media (e.g., EPROMs, RAMs, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage 22 may store software algorithms, information acquired and / or determined by the processor 20, information received via the UI device 18 and / or other external computing systems, information received from external resources 24, and / or other information that enables the system 10 to function as described herein.

[0087] External resources 24 may include information sources (e.g., databases, websites, etc.), external entities participating in System 10, one or more servers outside System 10, networks, electronic storage, equipment related to Wi-Fi technology, equipment related to Bluetooth® technology, data input devices, power supplies (e.g., battery-powered, or directly connected to 110-volt AC or indirectly connected to line power via AC / DC conversion), transmitting / receiving elements (e.g., antennas configured to transmit and / or receive radio signals), network interface controllers (NICs), display controllers, graphics processing units (GPUs), and / or other resources. In some embodiments, some or all of the functionality attributed to external resources 24 herein may be provided by other components or resources included in System 10. The processor 20, external resources 24, UI device 18, electronic storage 22, network, and / or other components of system 10 may be configured to communicate with each other via wired and / or wireless connections such as networks (e.g., local area network (LAN), internet, wide area network (WAN), radio access network (RAN), public switched telephone network (PSTN), etc.), cellular technologies (e.g., GSM, UMTS, LTE, 5G, etc.), Wi-Fi technologies, other wireless communication links (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.), base stations, and / or other resources.

[0088] The UI device 18 of system 10 may be configured to provide an interface between one or more users and system 10. In some embodiments, the UI device 18 may be configured to provide information to and / or receive information from one or more users. The UI device 18 includes a UI and / or other components. The UI may be and / or include a graphical UI configured to present views and / or fields configured to receive input and / or selections relating to a particular functionality of system 10 and / or to provide and / or receive other information. In some embodiments, the UI of the UI device 18 may include a plurality of separate interfaces accompanying the processor 20 and / or other components of system 10. Examples of interface devices suitable for inclusion in the UI device 18 include touchscreens, keypads, touch-sensitive and / or physical buttons, switches, keyboards, knobs, levers, displays, speakers, microphones, indicator lights, audible alarms, printers, and / or other interface devices. The disclosure also assumes that the UI device 18 includes a removable storage interface. In this example, information can be loaded into the UI device 18 from removable storage (e.g., a smart card, flash drive, or removable disk), which allows the user to customize the implementation of the UI device 18.

[0089] In some embodiments, the UI device 18 can be configured to provide the system 10 with a user interface (UI), processing performance, a database, and / or electronic storage. Thus, the UI device 18 may include a processor 20, electronic storage 22, external resources 24, and / or other components of the system 10. In some embodiments, the UI device 18 may be connected to a network (e.g., the Internet). In some embodiments, the UI device 18 does not include the processor 20, electronic storage 22, external resources 24, and / or other components of the system 10, but instead communicates with these components via a dedicated line, bus, switch, network, or other means of communication. The communication may be wireless or wired. In some embodiments, the UI device 18 may be a laptop, desktop computer, smartphone, tablet computer, and / or other UI device.

[0090] Data and content can be exchanged between different components of system 10 through communication interfaces and communication paths using one of a number of communication protocols. For example, data may be exchanged using the Internet Protocol Suite, also known as TCP / IP, employing protocols used to communicate data across packet-switched internetworks. Data and content may be delivered using datagrams (or packets) from a sending host to a destination host based solely on their addresses. For this purpose, the Internet Protocol (IP) defines addressing methods and structures for encapsulating datagrams. Of course, other protocols may also be used. Examples of Internet Protocols include Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6).

[0091] In some embodiments, the processor 20 may form part of a user device, consumer electronic device, mobile phone, smartphone, personal digital assistant, digital tablet / pad computer, wearable device (e.g., wristwatch), augmented reality (AR) goggles, virtual reality (VR) goggles, reflective display, personal computer, laptop computer, notebook computer, workstation, server, high-performance computer (HPC), vehicle (e.g., a computer embedded in the dashboard of a car or airplane, or in front of a seated passenger), game or entertainment system, set-top box, monitor, television (TV), panel, spacecraft, or other device (e.g., in the same or separate housing). In some embodiments, the processor 20 is configured to provide information processing performance in system 10. The processor 20 may comprise one or more digital processors, analog processors, digital circuits designed for information processing, analog circuits designed for information processing, state machines, and / or other mechanisms for electronically processing information. In Figure 1, the processor 20 is shown as a single entity, but this is for illustrative purposes only. In some embodiments, the processor 20 may comprise multiple processing units. These processing units may be physically located within the same device (e.g., a server), or the processor 20 may represent the processing capabilities of multiple collaborating devices (e.g., one or more servers, a UI device 18, a device that is part of an external resource 24, electronic storage 22, and / or other devices).

[0092] Figure 11 illustrates a method 100 for obtaining information to adjust platform security conditions, according to one or more embodiments. Method 100 may be performed by a computer system comprising one or more computer processors and / or other components. The processors may consist of machine-readable instructions for executing computer program components. The operation of Method 100 presented below is intended to be illustrative. In some embodiments, Method 100 may be achieved by one or more additional operations not described and / or without relying on one or more of the operations described. In addition, the order of operations of Method 100 illustrated in Figure 11 and described below is not intended to be limiting. In some embodiments, Method 100 may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed for information processing, analog circuits designed for information processing, state machines, and / or other mechanisms for electronically processing information). The processing device may include one or more devices that perform some or all of the operations of Method 100 in response to instructions electronically stored on an electronic storage medium. The processing device may include one or more devices configured through hardware, firmware, and / or software specifically designed to perform one or more operations of method 100.

[0093] In operation 102 of method 100, the (i) source code, (ii) base image (BI), and (iii) runtime environment of each of the multiple microservices in the stack may be retrieved and monitored via a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively. In some embodiments, operation 102 is performed by the same or similar processor components as the information component 30, the sensor scoring component 32, and the monitoring component 34 (shown in Figure 1 and described herein).

[0094] In operation 104 of method 100, the security rating of the microservice stack may be iteratively predicted through a model based on, for example, first, second, and third scores. In some embodiments, operation 104 is performed by a processor component identical or similar to the security rating component 36 (shown in Figure 1 and described herein). The security rating component 36 cannot detect intrusions and cannot react from them in real time. Therefore, in some embodiments, this component may instead track potential vulnerabilities. In some embodiments, possible remediations may be generated for a given situation. For example, the operations assumed herein may be rule-based and / or behavior-based (e.g., on the backend).

[0095] In operation 106 of method 100, the amount of resources required by the security team to enhance the security rating, for example through resource implementation, may be determined based on the predicted rating. In some embodiments, operation 106 is performed by the same or similar processor component as the resource estimation component 38 (shown in Figure 1 and described herein).

[0096] Operation 108 of Method 100 may determine the time to reserve a quantity of resources. In some embodiments, operation 108 is performed by the same or similar processor component as the resource estimation component 38 (shown in Figure 1 and described herein).

[0097] Operation 110 of Method 100 can determine the security state of the next release of the microservice stack. In some embodiments, operation 110 is performed by the same or similar processor component as the microservice releasing component 40 (shown in Figure 1 and described herein).

[0098] In operation 112 of method 100, information technology over a configurable period of time is used. TechniqueA UI may be provided that is configured to obtain a selection of a script level. In some embodiments, the operation 112 is performed by the same or similar processor component as the management / UI component 42 (shown in Figure 1 and described herein).

[0099] In operation 114 of method 100, the mean values ​​may be aggregated or summed by the estimated slope value and the seasonal value, with the seasonal value being associated with the slope value. In some embodiments, operation 114 is performed by the same or similar processor component as the monitoring component 34 and / or the security assessment component 36.

[0100] Operation 116 of Method 100 may track project state changes individually from each layer according to the release lifecycle and automatically apply additional checks, for example, to eliminate false positive errors in one or more security tool reports. In some embodiments, operation 116 is performed by the same or similar processor component as the monitoring component 34.

[0101] In operation 118 of method 100, the model may be adjusted so that long-term predictions are made, for example, in subsequent iterations. In some embodiments, operation 118 is performed by the same or similar processor component as the management / UI component 42.

[0102] In operation 120 of method 100, the periodicity of the iterations can be adjusted via the UI. In some embodiments, operation 120 is performed by the same or similar processor component as the management / UI component 42.

[0103] The techniques described herein may be implemented in digital electronic circuits, or in computer hardware, firmware, software, or a combination thereof. The techniques may be implemented as computer program products, i.e., as computer programs tangibly embedded in information carriers, such as machine-readable storage devices, machine-readable storage media, computer-readable storage devices, or computer-readable storage media, to be executed by or control the operation of data processing devices, such as programmable processors, computers, or multiple computers. Computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as standalone programs, modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs may be deployed to run on a single computer, at a single location, or on multiple computers distributed across multiple locations and interconnected by a communication network.

[0104] The method steps of this technique may be performed by one or more programmable processors that execute a computer program to perform the function of this technique by operating on input data and generating an output. Alternatively, the method steps may be performed by dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the apparatus of this technique may be implemented as such.

[0105] Processors suitable for executing computer programs include, for example, both general-purpose and dedicated microprocessors, and one or more processors in any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random-access memory, or both. Essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer further includes one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or is operablely coupled to them to receive or transfer data from them, or both. Suitable information carriers for incorporating computer program instructions and data include all forms of non-volatile memory, for example, semiconductor memory devices such as EPROMs, EEPROMs, and flash memory devices, magnetic disks such as internal hard disks or removable disks, magneto-optical disks, and CD-ROMs and DVD-ROMs. Processors and memory may be complemented by or incorporated into special-purpose logic circuits.

[0106] Several embodiments of this disclosure are specifically illustrated and / or described herein. Modifications and variations are intended and are within the scope of the appended claims.

Claims

1. A computer implementation method, To provide a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively, Monitoring the (i) source code, (ii) base image (BI), and (iii) runtime environment of each of several microservices in the stack via the first, second, and third sets of security tools, wherein each of the security tools comprises at least one selectable scanner or sensor configured to output historical data, and the microservices operate with respect to the same set of operational parameters. Based on two or more of the first, second, and third scores, the security rating of the microservice stack is iteratively predicted through the model, A method comprising determining, based on the aforementioned predicted assessment, the amount of resources required to enable the security team to enhance security through resource implementation.

2. The method according to claim 1, further comprising determining a time for making a reservation of the amount of resources, wherein the reservation includes the allocation or scheduling of resources for the security team.

3. The method according to claim 1, further comprising determining the security state for the next release of the stack of microservices.

4. The method according to claim 1, wherein the microservice comprises a set of one or more cloud services.

5. The method according to claim 1, further comprising providing a user interface (UI) configured to obtain a selection of information technology (IT) risk levels over a configurable period of time.

6. The method according to claim 1, wherein each of the aforementioned scores is a representative value.

7. The method according to claim 6, further comprising aggregating or summing the representative values ​​by an estimated slope value and by seasonality values ​​associated with the slope value.

8. The method according to claim 1, wherein each of the iterative predictions is performed within a first period, the first period is longer than the duration of each of the iterations, and the iterations are periodic.

9. The method according to claim 8, wherein each of the first and second periods is configurable via a UI.

10. Sending a notification based on the aforementioned decision, further comprising sending a notification in which the amount of the resources is determined based on the security assessment that satisfies a first criterion, The method according to claim 1, wherein the notification enables the development team to be activated if, in a subsequent iteration, the security assessment is predicted to meet a second criterion having a higher risk level than the first criterion.

11. The method according to claim 1, wherein each of the predictions is made such that it is possible to increase a first false positive amount and decrease a second false negative amount.

12. The method according to claim 1, further comprising tracking changes in project status individually from each layer according to the release lifecycle and automatically applying additional checks to exclude false positive errors in one or more security tool reports.

13. The method of claim 8, further comprising adjusting the model so that long-term forecasts are made in subsequent iterations, wherein the model is a Holt-Winters model.

14. The method according to claim 1, further comprising adjusting the periodicity of the repetitions via a UI.

15. A memory having stored computer-readable instructions, and a processor, To provide a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively, Monitoring the (i) source code, (ii) base image (BI), and (iii) runtime environment of each of several microservices in the stack via the first, second, and third sets of security tools, wherein each of the security tools comprises at least one selectable scanner or sensor configured to output historical data, and the microservices operate with respect to the same set of operational parameters. Based on two or more of the first, second, and third scores, the security rating of the microservice stack is iteratively predicted through the model, A system comprising a processor configured to determine, based on the predicted assessment, the amount of resources required to enable the security team to enhance security through resource implementation.

16. The aforementioned processor, The system according to claim 15, further configured to determine a time for making a reservation of the amount of resources, wherein the reservation includes the allocation or scheduling of resources for the security team.

17. The aforementioned processor, The system according to claim 15, further configured to determine the security state for the next release of the stack of microservices.

18. The system according to claim 15, wherein the microservice comprises one or more sets of cloud services.

19. The aforementioned processor, The system according to claim 15, further configured to provide a user interface (UI) configured to obtain a selection of information technology (IT) risk levels over a configurable period of time.

20. The aforementioned processor, Aggregating or summing representative values ​​by estimated slope values ​​and seasonal values, further configured to perform aggregation or summing such that the seasonal values ​​are associated with the slope values, The system according to claim 15, wherein each of the aforementioned scores is one of the aforementioned representative values.

Images