Patent Description:
A computer security "vulnerability" may be a weakness, exposure, or gap in a computer system that can be exploited, for example, by unauthorized third parties to gain access to private data on the computer system. An attack surface of the computer system is the sum of the different points of vulnerability through which an unauthorized third party can penetrate and harm the system, for example, by entering data into or extracting data from the computer system.

Establishing good computer security (which may include processes and mechanisms by which equipment, information, and services are protected from unauthorized access, changes, or destruction) is essential for secure operation of the computer system whether in a cloud or an on-premise environment.

The security of on-premise and cloud environments is the protection of data, applications on and infrastructures of on-premise and cloud computing platforms. An aspect of security involves receiving alerts of potential security threats. Another aspect of security involves fixing or remediating the underlying conditions giving rise to the potential security threats. The remediation process can be conducted, for example, by a security and operations (SecOps) team. However, in the context of modern computing networks, including extensive cloud computing networks, there can be too many alerts that provide too little context making it hard for SecOps teams to prioritize and resolve security threats in a timely manner.

In networked computer systems, the term "blast radius" is used to define the extent or reach of a faulty configuration or problem at a computer resource. For example, if a change is made incorrectly to a firewall or router that prevents it from passing traffic, the extent or reach of the disruption to other computer resources in the networked computer system is known as the blast radius.

<CIT> illustrates two computing devices interacting with each other. If a security device detects a malicious file at a client device, the access rights for the security device to the client device are modified such that the security device can trigger remediation actions on the client device, comprising the deletion of the malicious file.

<CIT> illustrates an approach to identify policy to remediate vulnerabilities for a plurality of computer components. Interrelations between the components are considered by accessing a topology descriptor.

Computer-implemented methods and systems for securing a networked computer system hosting an application are disclosed herein.

Throughout the figures, unless otherwise stated, the same reference numerals and characters are used to denote like features, elements, components, or portions of the illustrated embodiments.

A networked computer system (e.g., a public cloud, a private cloud, or an on-premise system) can provide a platform for executing one or more applications. The networked computer system may include a variety of hardware, software, and firmware components ("computer resources") used to support execution of the applications. <FIG> is a schematic illustration of an application <NUM> hosted on a networked computer system <NUM>. Networked computer system <NUM> may, for example, include a plurality of computer resources (e.g., computer resources <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-n, etc.) including, for example, one or more servers (e.g., web servers, application servers, etc.), databases, software code, network components, and other applications and services. In example cloud implementations of networked computer system <NUM>, the plurality of computer resources can include thousands of servers and interconnected cloud resources.

Application <NUM> may, for example, be a web-based retail transaction application, a printing service application, etc. A service model <NUM> may represent the particular computer resources (e.g., particular computer resources <NUM>-<NUM> and <NUM>-<NUM>) in the networked computer system that support execution of the application and the relationships between the particular computer resources.

Application availability is the extent to which an application is operational, functional and usable for completing or fulfilling a user's or business's requirements. Typically, application availability is measured through application-specific key performance indicators (KPIs). These can include, for example, the overall or timed application uptime and downtime, the number of transactions completed, application responsiveness, errors, and other availability-related metrics. Application availability is affected by the state or condition of the computer resources used to support execution of the application on the networked computer system.

To keep applications (e.g., application <NUM>) executing on a networked computer system (e.g., system <NUM>) secure from attacks by an unauthorized third party, it is important to detect security vulnerabilities (real or potential) in the networked computer system (including the networked computer system infrastructure) and to promptly remediate the security vulnerabilities. A remediation action may, for example, involve closing access, or modifying access permissions, to one or more of the computer resources in the networked computer system. Other remediation actions may, for example, involve closing or modifying ports, updating configurations of one or more of the computer resources, etc. The detected security vulnerabilities in the networked computer system may be vulnerabilities in computer resources that are within the application's service model (e.g., in service model <NUM>, particular computer resources <NUM>-<NUM> and <NUM>-<NUM>) or in computer resources that are outside the service model (e.g., computer resources <NUM>-<NUM>, <NUM>-<NUM>, etc.). Both types of computer resource vulnerabilities (i.e., within or outside the service model) and corresponding remediations can affect application availability on the networked computer system.

Many automated vulnerability detection and reporting systems (e.g., the BMC Helix® Cloud Security solution, the BMC® Automated Mainframe Intelligence™ (BMC AMI®) solutions, as well as the Oracle® Cloud Security, Palo Alto Network security, and CloudGuard Dome <NUM> public cloud security solutions, etc.) that can automatically scan, detect, and report security vulnerabilities (e.g., an open Amazon Simple Storage Service (S3) bucket or an open firewall port) in computer systems, are now commercially available. The security vulnerabilities may be a result, for example, of misconfigurations, or weaknesses in the configuration, of computer resources that are connected by the networked computer system. While the detection and reporting using the automated vulnerability detection and reporting systems can be quick, traditional remediation processes, such as those implemented by SecOps, for cloud security vulnerabilities in dynamic cloud computing environments are likely to be slow and incomplete.

The traditional remediation processes can be slow at least because of the long lead times involved in deciding and implementing proper remediation actions. Even when a remediation fix (e.g., a point fix such as an ingress rule change on an open firewall port) for a security vulnerability is available, the remediation fix's blast radius in the computing network is generally not known to SecOps. In other words, the extended effect of the remediation fix (i.e., the point fix) on applications executing on the networked computer system is not known to SecOps. SecOps operators may be reluctant to implement the remediation fix without knowledge of its impact on applications executing on the networked computer system and on the applications' availabilities on the networked computer system. The SecOps operators may spend considerable time in discussions with application teams to determine the impact of the remediation fix on application availability before implementing the fix. In other words, lack of knowledge of the remediation fix's blast radius and lack of knowledge of the remediation fix's impact on application availability slows down implementation of the remediation fix by SecOps.

The term "safe" remediation is used herein to refer to a remediation that has little or no impact on application availability in a networked computer system. In other words, a safe remediation of a vulnerable computer resource in the networked computer system should not bring down or otherwise hinder an application executing on the networked computer system.

The disclosure herein provides systems and methods (collectively "solutions") for securing a networked computer system. The solutions involve determination of, and use of, safe remediations to address security vulnerabilities in the networked computer system, in accordance with the principles of the present disclosure. Further, the disclosed solutions utilize the safe remediations not merely to address individual points of security vulnerabilities in the networked computer system, but to also provide a multi-layered defense based on a defense-in-depth security architecture of the networked computer system. The defense-in-depth security architecture may be based on security controls (e.g., access controls) that are designed to protect the physical, technical, and administrative aspects of the networked computer system. In the defense-in-depth security architecture, an initial point of security vulnerability may be characterized as being in a first layer of the networked computer system having its computer resources organized in multiple layers (the first layer to the nth layer). The multi-layered defense may involve placing security controls in higher layers (e.g., the second layer, the third layer, etc.) of the networked computer system in consideration of the possible multiple attack paths that may be used to exploit the security vulnerability (e.g., in a complex cloud environment). Defending an application with multiple layers of security controls can prevent a single point of failure or vulnerability from compromising the security of the application, for example, in a complex cloud environment.

The solutions for securing the networked computer system involve defining a blast radius of a reported security vulnerability (or a corresponding remediation) by automatically performing a graph-based reachability analysis. The graph-based reachability analysis can determine accessible paths (e.g., internet or network paths) over which the security vulnerability can propagate from an attack surface (i.e., a publicly exposed (e.g., an internet-exposed) vulnerable computer resource) to other computer resources (such as a database, a storage bucket, or a server) in the networked computer system. The accessible paths can be determined based on access rights from the publicly exposed vulnerable resource and not based on traditional service or topology models. The blast radius may be defined based on identification of the paths in the networked computer system that must be traversed from the reported security vulnerability to access other computer resources (which may hold critical or sensitive information). This definition of the blast radius may allow prioritization of remediation efforts (e.g., by SecOps) by focusing remediation on protection of critical computer resources and data that may be within the blast radius. The graph-based reachability analysis, used by the solutions herein to define the blast radius, provides a more accurate measure of blast radius than service model or topology-based traversals.

Further, the solutions for securing the networked computer system involve monitoring networked computer system behavior along the vulnerability traversal paths to help determine safe remediations that will not impact application availability. Since the safe remediations are designed to preserve application availability, the safe remediations can be applied immediately (e.g., by SecOps operators) without the application team's involvement. An application will not go down or break if a safe remediation is implemented by the SecOps operators.

The networked computer system may have its linked computer resources arranged in layers of the network. The solutions for securing the networked computer system may include applying the remediations to multiple layers of the computer resources to ensure defense-in-depth security remediation of the networked computer system. For example, a first layer and a second layer of safe remediations may be derived from the graph-based reachability analysis of traversal paths of a vulnerability from the attack surface to other computer resources and applied to the first layer and the second layer of computer resources to ensure defense-in-depth security remediation.

<FIG> is a schematic illustration of a networked computer system <NUM> that may be secured by the foregoing solutions, in accordance with the principles of the present disclosure. Networked computer system <NUM>, which may be a cloud-based computer system, may include a plurality of linked computer resources (e.g., application server security group <NUM>, virtual servers (e.g., EC2 Instances) <NUM>, relational databases (e.g., PostGres RDS) <NUM>, third-party database (e.g., Oracle DB) <NUM>, data warehouse (e.g., Redshift cluster) <NUM>, object storage service (e.g., S3 bucket) <NUM>, protected ES Domain <NUM>, Elastic cache <NUM>, messaging queue service (e.g., SQS) <NUM>, EBS volumes <NUM>, elastic Internet Protocol (IP) addresses (e.g., IPs) <NUM>, Lambda function <NUM>, AWS glue <NUM>, MySQL RDS <NUM>, CloudTrail <NUM>, CloudWatch logs <NUM>, Elk stack <NUM>, Redshift cluster <NUM>, and S3 bucket <NUM>, etc.). The plurality of linked computer resources may be arranged in a plurality of layers (e.g., layer <NUM>, layer <NUM>,. ,layer <NUM>, etc.). Computer resources in any one layer (e.g., layer <NUM>) are directly linked or attached to resources in the next higher layer (e.g., layer <NUM>), and indirectly linked to resources in higher layers (e.g., layer <NUM>, layer <NUM>, etc.).

As shown in <FIG>, layer <NUM> of networked computer system <NUM> may, for example, include an application server security group <NUM> that can provide narrow access or broad access via the public internet to applications (launched, for example, from application servers (not shown)) to other computer resources (sites) in computer system <NUM>.

In example implementations, the other computer resources of networked computer system <NUM> may include one or more virtual servers <NUM> that can run applications in a cloud computing environment. Virtual servers <NUM> may be instances of a webserver hosted on, for example, Amazon's Elastic Compute Cloud (EC2) for running applications on an Amazon Web Services (AWS) infrastructure.

Further, the other computer resources (e.g., in layer <NUM>) may, for example, include one or more relational databases <NUM> (e.g., an open source PostgreSQL relational database), a third-party database <NUM> (e.g., an Oracle database) hosted on a virtual server instance of EC2, and a data warehouse <NUM> (e.g., an Amazon Redshift cluster). One or more instances of virtual servers <NUM> may host objects (e.g., in layer <NUM>) such as an object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket), a protected ES Domain <NUM>, an Elastic cache <NUM>, and a messaging queue service <NUM> (e.g., an Amazon SQS Queue URL), etc..

Further, one or more durable block storage devices (e.g., EBS volumes <NUM>) (in layer <NUM>) may be attached to each instance of virtual servers <NUM>. Virtual servers <NUM> may be addressed by elastic Internet Protocol (IP) addresses (elastic IPs) <NUM> (in layer <NUM>), which may be, for example, static, public IPv4 addresses designed for dynamic cloud computing.

One or more of the computer resources in networked computer system <NUM> may be critical computer resources that may, for example, store sensitive business data or personally identifiable information (PII). The critical computer resources may, for example, include one or more relational databases <NUM> (e.g., an open source Postgres RDS relational database), third-party database <NUM> (e.g., an Oracle database), data warehouse <NUM> (e.g., an Amazon Redshift cluster), object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket), and elastic cache <NUM>. These critical computer resources must be protected at all cost as any breach by an attacker via a vulnerable computer resource (such as application server security group <NUM>) can have a large financial or business impact (e.g., for a customer). The critical computer resources may be resources that have been previously identified (e.g., by the customer, or by administrators) as being critical computer resources in the networked computer system. By providing multi-layered remediation, the solutions described herein, are likely to protect the critical computer resources from breach via the vulnerable traversal paths (e.g., Internet paths) from an attack surface.

In the example shown in <FIG>, application server security group <NUM> may be a computer resource having a security vulnerability. The security vulnerability of application server security group <NUM> may arise, for example, from an "open port <NUM>" condition on its communications interface. Further, in the example shown in <FIG>, object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket) may be a computer resource having a security vulnerability because of the public access to the resource. Traditional remediation actions (e.g., "close port <NUM>", and "remove public access from S3") would secure the two computer resources (i.e., application server security group <NUM> and object storage service <NUM>). However, these traditional remediation actions would also cause an application launched from application server security group <NUM> to become unavailable or to stop working because the S3 bucket will become inaccessible to the application and because port <NUM> for launching the application will be closed.

In contrast to the traditional remediation actions, the solutions for securing the networked computer system described in the present disclosure determine and use safe remediations that will not impact application availability.

In example implementations, the safe remediations may be discovered or developed by applying artificial intelligence (AI) and machine learning techniques to behavioral models of the computer resources in the networked computer system. The behavioral models may be based on monitored behaviors of the computer resources over an extended time period (e.g., a few weeks). The Al and machine learning techniques may be applied to convert or develop a traditional remediation that is unsafe into a safe remediation for the networked computer system. The machine learning techniques may, for example, learn from the behavioral models which particular computer resources in the networked computer system are affected by the safe remediation action and learn what access controls or modifications to the particular computer resources are implemented by the safe remediation action.

For example, <FIG> shows a screenshot of an example traditional remediation procedure <NUM> that is publicly available from industry standards organizations such as the CIS (Center for Internet Security, Inc. , East Greenbush, New York) (CIS). Remediation procedure <NUM>, which relates to Internet security, includes a remediation action <NUM>:.

Remediation action <NUM> may or may not be a safe remediation action that will not have adverse impact on application functioning in the context of networked computer system <NUM>. However, remediation action <NUM> can be converted into (or confirmed to be) a safe remediation using Al and machine learning techniques. <FIG> schematically shows a method <NUM> for generating safe remediation actions using Al and machine learning techniques. Method <NUM> includes monitoring behaviors of the computer resources in the networked computer system over a period of time (<NUM>) and generating behavioral models of the computer resources (<NUM>). In example implementations, the monitored behaviors of a computer resource may, for example, include behaviors that describe: a configuration history of the computer resource; the entities that access the computer resource; the APIs used; the applications that talk to the computer resource; and the IP addresses that the computer resource talks to, etc. The period of time over which the behaviors of the computer resource are monitored may, for example, be a few weeks (e.g., one to two weeks). The behavioral models of the computer resources may be collections of the monitored behavioral data. An example behavioral model for a key computer resource may involve monitoring key usage scenarios, for example, over the past two weeks, and "learning" a list of Entities (e.g., HTTP referrers or iOs apps) that this key computer resource uses in normal behavior.

Method <NUM> further includes using the behavioral models as training data for machine learning to generate safe remediation actions for networked computer system <NUM> (<NUM>). Machine learning may be used to learn, for example, how access to different computer resources in networked computer system can be controlled to secure the vulnerability with little or no interference with application functioning.

For example, a known remediation action (e.g., remediation action <NUM>, <FIG>) may be:.

Remediation action <NUM> permits setting application restrictions to one of four Entities (i.e., (<NUM>) HTTP referrers, (<NUM>) IP addresses, (<NUM>) Android Apps, or (<NUM>) iOs Apps). Remediation action <NUM> may be used as a seed or starting remediation action that is converted into a safe remediation action by machine learning. Remediation action <NUM> may be converted into a safe remediation action <NUM>, for example, by limiting permission to set application restrictions on some of the Entities (e.g., HTTP referrers and iOs apps) that are specified by the behavioral models. The behavioral models may, limit application restrictions on two Entities, for example, IP addresses and Android Apps.

Restricting permission for setting application restrictions on two Entities (i.e., IP addresses and Android Apps) listed in remediation action <NUM> may result in a safe remediation action (e.g., remediation action <NUM>, <FIG>). Safe remediation action <NUM> may be based on a list of Entities (e.g., HTTP Referrers and iOs Apps) learned from the behavioral model. Safe remediation action <NUM> may, for example, be:.

<FIG> schematically shows, for example, remediation action <NUM> (<FIG>) being converted by machine learning on the behavioral models into a safe remediation action <NUM>. The machine learning on the behavioral models may be used, for example, to learn a list of specific entities (i.e., HTTP Referrers and iOs Apps) used by the key computer resource. Safe remediation action <NUM> may be based on the learned list of specific entities.

In <FIG>, for purposes of visual illustration, the two entities (i.e., IP addresses, Android Apps) that are removed from remediation action <NUM> (by machine learning) to arrive at remediation action <NUM> are shown in strikeout font.

Safe remediations (such as safe remediation action <NUM>) may be stored in a data store (not shown). A safe remediation from the data store may be automatically suggested (e.g., to SecOps operators) as a safe fix to secure networked computer system <NUM> each time a security vulnerability in networked computer system <NUM> is detected or reported.

<FIG> is a schematic illustration of an example method <NUM> for reachability graph-based safe remediation of a networked computer system, in accordance with the principles of the present disclosure.

Method <NUM> may include, at step <NUM>, scanning the networked computer system (e.g., networked computer system <NUM>) to identify one or more vulnerable computer resources (e.g., Vulnerable Resource Nos. <NUM> - M <NUM>). The scanning may be performed by commercially-available vulnerability detection and reporting systems (e.g., BMC Helix® Cloud Security solution, BMC® Automated Mainframe Intelligence™ (BMC AMI®) solutions, Oracle® Cloud Security, Palo Alto Network security, CloudGuard Dome <NUM> public cloud security, etc.) that can automatically scan, detect, and report security vulnerabilities. Any number of vulnerable computer resources <NUM> may be identified.

<FIG> shows, for example, M vulnerable computer resources <NUM> labeled as Vulnerable Resource Nos. Further, method <NUM> may include conducting a graph-based reachability analysis (<NUM>) of networked computer system <NUM> showing paths to different computer resources in the networked computer system that are accessible from the vulnerable computer resources <NUM>. Method <NUM> may include, based on the graph-based reachability analysis <NUM>, determining a blast radius of each vulnerable computer resource (<NUM>) in the networked computer system. The vulnerable computer resources for which blast radii are determined may include the vulnerable computer resources (e.g., vulnerable computer resources <NUM>) identified at step <NUM> or any other resources that may have been otherwise identified as being vulnerable.

After the blast radius of a vulnerable computer resource has been determined, method <NUM> may include determining if any critical computer resources are impacted (<NUM>) by the vulnerable computer resource. The critical computer resources may be computer resources that have been previously identified (e.g., by a customer or an administrator) as being critical computer resources. The customer or administrator may, for example, identify one or more buckets, databases, and servers as critical resources. A critical resource may be considered to be impacted if it is within the blast radius of the vulnerable computer resource.

If no critical computer resources are impacted (i.e., no critical computer resources are within the blast radius of the vulnerable computer resource), method <NUM> may include assigning a low priority (<NUM>) to the remediation of the vulnerable computer resource. The vulnerable computer resource that has been assigned a low priority may, for example, be referred to a SecOps application team for non-urgent remediation on the SecOps application team's schedule.

If one or more critical computer resources are impacted (i.e., the one or more critical computer resources are within the blast radius of the vulnerable computer resource), method <NUM> may include identifying a remediation action on the vulnerable computer resource (<NUM>). The remediation action on the vulnerable computer resource may, for example, be a point fix of the vulnerable computer resource (in the layer of the networked computer system to which the vulnerable computer resource belongs). The remediation action may be an industry standard remediation action available, for example, from CIS.

Further, method <NUM> may include monitoring (<NUM>) the behavior of the networked computer system to determine interactions between computer resources (that are used, for example, by an application). The monitoring may, for example, include monitoring traffic flows (data exchanges) between the computer resources over a period of time (e.g., the past <NUM> days) using commercially-available monitoring solutions (e.g., Amazon Virtual Private Cloud flow logs (which capture information about Internet Protocol traffic to and from network interfaces in a Virtual Private Cloud (VPC)), AWS CloudTrail logs (which publishes VPC flow log data), and AWS Config (which allows the assessment, audit, and evaluation of configurations of Amazon Web Services resources, etc.).

Based on the monitored behavior of the networked computer system, method <NUM> may include determining whether the remediation action (identified at <NUM>) on the vulnerable computer resource is a safe remediation (i.e., a remediation that does not impact application availability) or an unsafe remediation (i.e., a remediation that impacts application availability) (<NUM>).

In an example implementation, method <NUM> may further include (in conjunction with the monitoring at <NUM>) determining safe and unsafe remediation actions (<NUM>) for computer resources that may be in one or more higher layers (e.g., a second layer, a third layer,. an nth layer) of the networked computer system.

Method <NUM> may, at <NUM>, include building remediation action chains (i.e., a series of one or more remediation actions) including the previously determined safe remediation actions (e.g., first layer remediation at <NUM>, and second, third, and nth layer remediations at <NUM>) for each of computer resources <NUM> that have security vulnerabilities. A remediation action chain that includes safe remediation actions at multiple layers may provide a defense-in-depth security remediation for the networked computer system.

Method <NUM> further includes executing or implementing the remediation action chains (<NUM>). The remediation action chains may be executed automatically (e.g., by SecOps without a need for consulting with application teams), while preserving application availability on the networked computer system.

Further details of some of the different stages and steps of method <NUM> (e.g., step <NUM>, step <NUM>, step <NUM>, step <NUM>, step <NUM>, step <NUM>, step <NUM>, and step <NUM>) to secure a networked computer system are discussed below with reference to securing, for example, networked computer system <NUM> (<FIG>).

As shown in <FIG>, networked computer system <NUM> includes two vulnerable computer resources (i.e., application server security group <NUM> with an open port <NUM>, and object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket) with public access. Scanning networked computer system <NUM>, at step <NUM> of method <NUM>, would identify the foregoing two resources (i.e., application server security group <NUM> and object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket)) as being computer resources that are vulnerable to external attack.

The graph-based reachability analysis may include determining links between different computer resources beginning, for example, with a vulnerable computer resource. <FIG> shows, for example, a reachability graph depicting links between the different computer resources beginning with the vulnerable computer resource (e.g., application server security group <NUM>) in layer <NUM> of networked computer system <NUM>.

Determination of the blast radius of a vulnerable computer resource (e.g., application server security group <NUM>, <FIG>) may involve identifying which network interfaces are directly (or indirectly) attached to the vulnerable computer resource. Identification of the interfaces attached to the vulnerable computer resource can lead to a determination of what services or resources in the networked computer system access, or can be accessed from, the vulnerable computer resource. The blast radius of the vulnerable computer resource may be determined to extend over the set of all services or resources that can access, or can be accessed from, the vulnerable computer resource. For example, as shown in <FIG>, the vulnerable computer resource - application server security group <NUM>, is attached to four computer resources (i.e., virtual servers <NUM> (e.g., Amazon's Elastic Compute Cloud (EC2), one or more relational databases <NUM> (e.g., an open source Postgres RDS relational database), a third-party database <NUM> (e.g., an Oracle database), and a data warehouse <NUM> (e.g., an Amazon Redshift cluster)) in layer <NUM> of networked computer system <NUM>. Thus, the blast radius of application server security group <NUM> may be determined by method <NUM> to extend over, or include, at least the foregoing set of four computer resources to which application server security group <NUM> is attached. <FIG> illustrates the set of four computer resources in layer <NUM> of networked computer system <NUM> that are within the blast radius of application server security group <NUM>. The blast radius of application server security group <NUM> may extend to include computer resources in higher layers (e.g., layer <NUM>, <FIG> and <FIG>, and layers <NUM> to <NUM>, <FIG>) of networked computer system <NUM> via the foregoing four computer resources in layer <NUM>.

Determining whether any critical computer resources are impacted by the vulnerable computer resource may involve determining if paths ("vulnerability paths") exist over which the critical computer resources can be reached from the vulnerable computer resource. The reachable critical computer resources may be within the blast radius of the vulnerable resource or may be indirectly accessible via another computer resource within the blast radius. Reachability analysis is used to determine which critical computer resources are reachable and are potentially impacted (i.e., rendered vulnerable over the vulnerability path from the vulnerable resource).

As an example of the reachability analysis consider, a resource - virtual server <NUM> (e.g., Amazon's Elastic Compute Cloud (EC2)), shown in <FIG>. Determining whether any critical computer resources can be impacted via virtual server <NUM> involves a check of what resources are accessed by virtual server <NUM>, and to what resources virtual server <NUM> has permission access. In example implementations, AWS Identity and Access Management (IAM) roles (which control individual and group access to a computer system resource), and a description of the resource configuration, may be used to discover the computer resources accessed by, and the permission access of, virtual server <NUM>.

In the example networked computer system <NUM> shown in <FIG>, consideration of the IAM roles assigned to virtual server <NUM> may discover that four resources (i.e., object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket), protected ES domain <NUM>, elastic cache <NUM>, and a messaging queue service <NUM> (e.g., an Amazon SQS Queue URL)) in layer <NUM> can be accessed by virtual server <NUM>. Further, consideration of the description of resource configuration may discover that virtual server <NUM> has permission access to EBS volumes <NUM> and elastic IPs <NUM> in layer <NUM>.

The reachability analysis further involves scanning all of the discovered resources to determine if there is any vulnerability path to a critical computer resource from the vulnerable computer resource. In the example networked computer system <NUM> shown in <FIG>, the scanning may reveal the existence of a vulnerability path to a critical computer resource (i.e., object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket), which has public access) from the vulnerable computer resource (application server security group <NUM>) via virtual server <NUM>.

On the basis of the analysis, a reachability graph from public vulnerabilities to critical computer resources in networked computer system <NUM> may be plotted. <FIG> shows an example reachability graph <NUM> depicting vulnerability path <NUM> (in bold line) extending from a publicly vulnerable computer resource (i.e. application server security group <NUM>) to a critical business resource (i.e., object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket)) via virtual server <NUM>.

<FIG> shows, for visual clarity, only the specific computer resources (i.e., application server security group <NUM>, virtual server <NUM>, and object storage service <NUM>) along reachability graph <NUM> (in the example of <FIG>) that need to be considered for determining safe remediation action on the vulnerable computer resource (i.e., application server security group <NUM>).

Standard remediation actions may be available from industry standards organizations (e.g., CIS). The standard remediation actions can be in one of several categories (e.g., Network, Compute, Storage, Logging, Monitoring, Access, Application, and Database). TABLE A (below) lists three example standard remediation actions (e.g., "Close S3 bucket," "Close port X", Config DB to Secure Sockets Layer (SSL) only") and meta data related to the three example remediation actions.

As shown in TABLE A, meta data for each remediation action may include a "Safe Condition" criterion that is expressed in terms of values of "Behavioral Model Metrics" associated within each category of the remedial action, an indication of whether there is "Compensation Available" for exceptions, and a "Compensation Method", if available for the exceptions. An example Compensation Method (e.g., for the remediation action "Close port X") may be "add IP ingress rule method".

Each remediation action can be implemented as a command line instruction (CLI), application programming interface (API), or a script with parameters. As a rule, the safe condition must hold true if the remediation action is not to hinder or break any application functionality. If the rule cannot be satisfied, then a next step can be to specify compensation methods (if available) to the safe condition so that the remedial action can still be taken without breaking application functionality.

In example implementations of method <NUM>, monitoring <NUM> may, for example, include monitoring traffic flows (data exchanges) along the paths between the computer resources over a period of time (e.g., the past <NUM> days, the past <NUM> days, etc.) using commercially available monitoring solutions (e.g., Amazon Virtual Private Cloud flow logs (which capture information about Internet Protocol traffic to and from network interfaces in a Virtual Private Cloud (VPC)), AWS CloudTrail logs (which publishes VPC flow log data), and AWS Config (allows the assessment, audit, and evaluation of configurations of Amazon Web Services resources, etc.).

The monitoring solutions may identify paths in the networked computer system that have measurable traffic flows over a time period (e.g., the past <NUM> days), and thus are paths that are important for preserving application availability. Because traffic was exchanged on these paths, it is likely that the application would need to use them again. For safe remediation, these paths should not be completely blocked by any remediation action.

Other paths in the networked computer system (e.g., paths that have little or no traffic flow (over the past time period) may be trimmed, removed, or shutdown without affecting application availability. These other paths can be remediated using traditional approaches without a high risk of affecting application availability.

Monitoring <NUM> may include collecting tracking logs and event logs in different domains (e.g., Network, Access, Storage, Application, and Database domains) of networked computer system <NUM>: In an example implementation, a flow log may be collected in the Network domain, application programming interface (API) logs may be collected in the Access and Application domains, database logs may be collected in the Database domain, and application logs and configuration history may be collected in the Application domain.

Specific behavioral models that track the behavioral metrics (e.g. Behavioral Model Metrics, TABLE A) may be derived from the monitored data that is specific to each domain. The behavioral models may be created from the data based on an observation period, for example, of few days to a month. <FIG> shows example behavioral models (i.e., MATRIX <NUM>, MATRIX <NUM>, and MATRIX <NUM>) for the behavioral metrics (i.e., Resource_to_resource - #ofcalls, Resource_to_IP - #ofcalls, and Resource_to_API - #ofcalls) listed in TABLE A.

Determining whether a remediation action is a safe remediation or an unsafe remediation is directed to determining application availability upon implementation of the remediation action to secure the vulnerable computer resource. The determination of whether the remediation action is a safe remediation, or an unsafe remediation, may be based on behavioral data collected by monitoring the operation of the computer resources along high-risk paths (e.g., vulnerability path <NUM>) in the networked computer system.

Safe remediation actions may be created based on the behavior of computer resources along high-risk paths (e.g., vulnerability path <NUM>) in the networked computer system. A safe remediation action may include closing general open access over the vulnerability path to a critical computer resource and, instead, include providing specific access to the critical computer resource to only a selected computer resource used in proper execution of the application.

Data on traffic flows to, and from, the vulnerable computer resources (e.g., over vulnerability path <NUM>) may be used to identify networked computer system resources (e.g., virtual server <NUM>) that access the vulnerable computer resources (e.g., application server security group <NUM>, and object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket)) for proper purposes (i.e., proper execution of the application). Safe remediation actions may be created by providing specific access to only the identified resources that access the vulnerable computer resources for proper purposes while removing open access over the high-risk paths as part of the remediation.

TABLE B below shows examples of unsafe remediation actions and safe remediation actions for a networked computer system based on behavior monitoring data (collected, for example, over <NUM> days). The safe remediation actions may be obtained by adding compensatory or additional methods to the unsafe remediation actions. The examples in the table are for networked computer system <NUM> (<FIG>) having two vulnerable computer resources (i.e., application server security group <NUM> with an open port <NUM>, and object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket) with public access).

As shown in TABLE B, the behavior monitoring data shows that application server security group <NUM> is attached to virtual server <NUM>, and that a source (an example application) at IP address XX is accessing application server security group <NUM> on port <NUM>. A traditional remediation action to secure application server security group <NUM> is to delete open port <NUM>. However, this traditional remediation action would deny access to the source (the example application) at IP address XX and affect application availability. TABLE B shows an example safe remediation action that could secure application server security group <NUM> while preserving application availability. The safe remediation action chain includes an action that closes open port <NUM> on application server security group <NUM>, and a compensatory action that provides specific access to source (the example application) at IP address XX by additionally attaching open application server security group <NUM> to virtual server <NUM> IP addresses and opening source IP address XX for port <NUM>.

TABLE B also shows that virtual server <NUM> is attached to object storage service <NUM> (S3 bucket), which has public access, and that a user "YY" (an example application) is accessing object storage service <NUM> (S3 bucket). A traditional remediation action to secure object storage service <NUM> (S3 bucket) is to close its public access. However, this traditional remediation action would deny access to user YY (the example application) and affect application availability. TABLE B shows a safe remediation action that could secure object storage service <NUM> (S3 bucket), while preserving application availability. The safe remediation action chain includes an action closing public access to object storage service <NUM> (S3 bucket), and a compensatory action that provides specific access to source user YY by providing virtual server <NUM> access to object storage service <NUM> (S3 bucket) using IAM permission policies and giving access to user YY for object storage service <NUM> (S3 bucket).

In example implementations, the determination of whether the remediation action is a safe remediation, or an unsafe remediation may be based on evaluating the safe condition (TABLE A) of the remediation action with reference to the behavioral models (e.g., MATRIX <NUM>, MATRIX <NUM>, and MATRIX <NUM>, <FIG>) for the behavioral metrics (e.g., Resource_to_resource - #ofcalls, Resource_to_IP - #ofcalls, and Resource_to_API - #ofcalls, TABLE A). The behavioral models may be evaluated to determine if the safe condition of the remedial action is violated. If the safe condition of the remedial action is violated, an attempt can be made to include a compensatory action (e.g., when compensation methods (TABLE A) for the remedial action) are available). When one or more compensatory actions cannot be achieved, then the remediation action is determined to be an unsafe remediation.

The following is a snippet of pseudocode that may be used for automating the determination of whether the remediation action is a safe remediation, or an unsafe remediation. CompensationList=[] //empty list of compensations
CompensationNotAvailable = False
Action is the action being analyzed
SafeCondition = Action. SafeCondition //expression to evaluate
Model [i,j] is the value in each cell of the matrix for ith row and jth
column
For each model(i,j), evaluate SafeCondition
If SafeCondition for all interactions of the
resource is true Recommend =>
Safe remediation
(e.g. #ofcalls is applied to each resource -
IP interaction to determine if it violates
condition or not)
Else
Identify cells (i, j) in the behavioral model
that cause safe condition to be violated
If CompensationAvailable is true
Formulate a Compensation Action from this entry
Add it to the compensation list
Else
CompensationNotAvailable = True
If CompensationNotAvailable is True
Recommend => "Unsafe remediation"
Else
Recommend => Safe remediation with compensations from
CompensationList.

The foregoing reachability graph-based analysis can be extended to any number of layers (e.g., <NUM> to N layers) of the networked computer system to find additional safe remediation actions for computer resources in the multiple layers to obtain a defense-in-depth for the networked computer system.

<FIG> shows an example reachability graph <NUM> depicting vulnerability path <NUM> (in bold line) extending through virtual server <NUM> in layer <NUM> from a publicly vulnerable computer resource (i.e. application server security group <NUM>) in layer <NUM> to a critical business resource (i.e., object storage service <NUM> (e.g., an Amazon Simple Storage Service (S3) bucket)) in layer <NUM>; a critical business resource <NUM> (e.g., a Lambda Function to Access Resources in an Amazon VPC) in layer <NUM>; a critical business resource <NUM> (e.g., a publicly accessible MySQL relational database service) in layer <NUM>; and a critical business resource <NUM> (e.g., a S3 bucket with public access) in layer <NUM>.

Safe remediation actions may be created based on the behavior of computer resources along the high-risk paths (e.g., vulnerability path <NUM>) in the networked computer system extending across layer <NUM> to layer <NUM>. The safe remediation actions can be implemented in layer <NUM> to layer <NUM> as a multi-layer defense without affecting application availability on the networked computer system.

As another example of the use of method <NUM> (e.g., steps <NUM>-<NUM>) for determining whether a remediation action is a safe remediation or an unsafe remediation, consider a case of two vulnerable databases (e.g., database DB1 and database DB2) in a networked computer system that need remediation to ensure that these databases only accept Secure Sockets Layer (SSL) connections from other resources. An example traditional remediation action for this purpose may be a database reconfiguration action: Config DB to SSL only (shown in TABLE A).

<FIG> shows a behavioral model (e.g., MATRIX <NUM>) that may be based on monitoring traffic flows (e.g., for the last <NUM> days) between the two databases (e.g., database DB1 and database DB2) and other computer resources (e.g., Resource-<NUM>, Webserver-<NUM>, Web-<NUM> and IP-<NUM>, etc.) in the networked computer system. MATRIX <NUM> may show that DB1 already has all incoming connections (e.g., from Resource-<NUM>, Webserver-<NUM>, Web-<NUM> and IP-<NUM>, etc.) that are SSL encrypted, while DB2 has a mixed model (with a DB2-Resource-<NUM> connection not being an encrypted SSL connection). Based on MATRIX <NUM>, the remediation analytics at step <NUM> of method <NUM> may flag a "safe remediation" on DB1 but call out an unsafe remediation on DB2.

The meta data (e.g., TABLE A) for the remediation action - Config DB to SSL only, may include only the following data:.

The remediation action - Config DB to SSL, will remain an unsafe remediation on DB2 because no compensation action is available to modify the unsafe application breaking characteristics of the remediation.

<FIG> is a block diagram of an example system <NUM> for securing a networked computer system (e.g., networked computer system <NUM>) while preserving application availability on the networked computer system, in accordance with the principles of the present disclosure.

Networked computer system <NUM> may, like networked computer system <NUM>, include a plurality of linked computer resources (computer resource <NUM>-<NUM>, computer resource <NUM>-<NUM>, computer resource <NUM>-<NUM>, computer resource <NUM>-<NUM>,. computer resource <NUM>-n, etc.) arranged in one or more layers (not shown). The computer resources may include a variety of hardware, software, and firmware components for supporting execution of an application on the networked computer system. One or more of the computer resources may be identified as being critical computer resources (e.g., by customers or administrators) as containing sensitive data or information that should be kept private.

System <NUM> includes a safe remediation solution (e.g., application <NUM>) coupled to networked computer system <NUM>, one or more vulnerability and threat detection tools (e.g., scanner <NUM>, etc.), and one or more network monitoring tools (e.g., monitor <NUM>, etc.). Scanner <NUM> may identify computer resources in networked computer system <NUM> that have security vulnerabilities and are susceptible to attack. Monitoring tool <NUM> may monitor traffic flows between the different computer resources in networked computer system701, for example, while the application is being executed on networked computer system <NUM>.

In system <NUM>, safe remediation of networked computer system <NUM> may be carried out via application <NUM>, which may, for example, be hosted on one or more physical or virtual computers (e.g., a computing device <NUM> that, for example, includes a processor <NUM>, a memory <NUM>, an O/S <NUM>, an input/output port (I/O) <NUM> and a display <NUM>) coupled to networked computer system <NUM>.

In example implementations, application <NUM> may be configured to receive reports of computer resource vulnerabilities that are identified, for example, by scanner <NUM>, as being present in networked computer system <NUM>. Application <NUM> may be configured to receive data on the behavior of the computer resources in networked computer system <NUM> that may be collected, for example, by monitor <NUM> over a time period (e.g., <NUM> days, <NUM> days, etc.). The behavior data may, for example, include data on traffic flows between the computer resources.

Application <NUM> (e.g., hosted on computing device <NUM>) may include one or more modules (e.g., a list of vulnerable resources <NUM>, a reachability analyzer <NUM>, a blast radius determiner <NUM>, a vulnerability paths determiner <NUM>, a remediation actions selector <NUM>, an application availability analyzer <NUM>, a safe remediation planner <NUM>, and a remediation implementer <NUM>) to secure networked computer system <NUM>.

The functions and operations of the one or more modules <NUM>-<NUM> may be configured, for example, to implement the steps of a method (e.g., steps <NUM>- <NUM> of method <NUM>, <FIG>) for prioritizing safe remediation of the vulnerabilities in networked computer system <NUM>.

Application <NUM> may generate safe remediation action chains to secure vulnerable computer resources along vulnerability paths in the networked computer system and to protect and safeguard critical computer resources that contain sensitive or highly private data. The vulnerable computer resources or critical computer resources may exist in different layers of the computer resources in the networked computer system. The safe remediation action chains may include a series of one or more point remediation fixes for the vulnerable computer resources in the different layers and provide a multi-layer defense-in-depth for the networked computer system.

For purposes of generating safe remediation action chains, application <NUM> may consider "vulnerabilities" to include software vulnerabilities (i.e., vulnerabilities that can be remedied by code patches), system configuration vulnerabilities (i.e., vulnerabilities that can be remedied by system reconfigurations, such as server hardening, closing of network ports, etc.), and security policy violation vulnerabilities (i.e., vulnerabilities that can be remedied by policy remediation).

In example implementations, list of vulnerable resources <NUM> in application <NUM> may be a list of computer resources that have been identified as having vulnerabilities (e.g., by scanner <NUM>). Reachability analyzer <NUM> may be configured to prepare a reachability graph showing links between the different computer resources (including the vulnerable computer resources) in the networked computer system. Blast radius determiner <NUM> may be configured to determine a blast radius for each vulnerable computer resource. Vulnerability paths determiner <NUM> may be configured to identify possible attack paths (i.e., vulnerability paths) extending from the vulnerable computer resource to one or more critical computer resources. Remediation actions selector <NUM> may be configured to identify and select one or more possible remediation actions to remediate the computer resource vulnerabilities. Application availability analyzer <NUM> may be configured to determine whether a selected remediation action is a safe remediation action (i.e., a remediation having little or no impact on application availability) for the networked computer system. Safe remediation planner <NUM> may be configured to generate a safe remediation action chain (i.e., a series of one or more remediation actions) that can secure vulnerable computer resources and critical computer resources along a vulnerability path in the networked computer system. Remediations implementer <NUM> may be configured to automatically implement the safe remediation action chain (e.g., in conjunction with computer resource configuration tools (not shown)) to secure vulnerable computer resources and critical computer resources along a vulnerability path in the networked computer system.

<FIG> shows an example method <NUM> for securing a networked computer system that may be implemented using system <NUM>, in accordance with the principles of the present disclosure. The networked computer system may provide a computing platform on which applications are executed.

Method <NUM> includes identifying a vulnerable computer resource in the networked computer system (<NUM>) and identifying a remediation action (<NUM>). The method further includes determining whether the remediation action is a safe remediation action that does not reduce availability of the application on the networked computer system or an unsafe remediation action that reduces availability of the application on the networked computer system (<NUM>), and implementing the remediation action if it is the safe remediation action to secure the networked computer system (<NUM>).

Method <NUM> further includes prioritizing implementation of the remediation action to secure the vulnerable computer resource if a vulnerability path extends from the vulnerable computer resource to a critical computer resource that is used by an application. The safe remediation action may include closing open access to the critical computer resource over the vulnerability path to all users and providing specific access to the critical computer resource over the vulnerability path to only a selected computer resource used in proper execution of the application.

In method <NUM>, determining if the remediation action is a safe remediation action or an unsafe remediation action includes determining what computer resources in the networked computer system are accessible from, or are accessed by, the vulnerable computer resource. Determining what computer resources in the networked computer system are accessible from, or are accessed by, the vulnerable computer resource includes monitoring traffic flows between the computer resources over a period of time to identify vulnerability paths from the vulnerable computer resource to other computer resources in the networked computer system, and determining whether the vulnerability paths lead to a critical computer resource used in execution of the application.

If the remediation action is determined to be an unsafe remediation action, method <NUM> may involve converting the remediation action into the safe remediation action, wherein the safe remediation action includes closing open access to the critical computer resource over the vulnerability path to all users and providing specific access to the critical computer resource to the application.

Method <NUM> may include determining a blast radius of the vulnerable computer resource by determining what computer resources are directly or indirectly attached to the vulnerable computer resource. Determining what computer resources in the networked computer system are accessible from, or are accessed by, the vulnerable computer resource can include considering AWS Identity and Access Management (IAM) roles assigned to a computer resource to discover other computer resources that can be accessed from the computer resource, and considering a description of the computer resource's configuration to discover the computer resource's permission access to other computer resources.

Method <NUM> may further include monitoring computer resource behavior in the networked computer system over a period of time to check traffic flows between the computer resources in the networked computer system and using the traffic flows to assess an impact of the vulnerability path on application availability. The safe remediation action can include removing general open access to the vulnerable computer resource for all users, and, instead, include providing specific access only to a computer resource that has exhibited past traffic flows over the vulnerability path to the critical computer resource.

Implementations of the various techniques and systems described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may be implemented as a computer program product, i.e., a computer program tangibly embodied in a non-transitory information carrier, e.g., in a machine-readable storage device (computer-readable medium) for processing by, or to control the operation of, data processing apparatuses, e.g., programmable processors or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be processed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communications network.

Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

Processors suitable for the processing of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CDROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.

To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal or plasma display monitors, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.

Claim 1:
A computer-implemented method for securing a networked computer system (<NUM>) hosting an application (<NUM>), the method comprising:
identifying a vulnerable computer resource (<NUM>-<NUM> ... <NUM>-n, <NUM>-<NUM> ... <NUM>-n) in the networked computer system (<NUM>, <NUM>);
identifying a remediation action;
determining whether the remediation action is a safe remediation action that does not reduce availability of the application on the networked computer system or an unsafe remediation action that reduces availability of the application on the networked computer system,
wherein determining if the remediation action is a safe remediation action or an unsafe remediation action includes determining what computer resources in the networked computer system are accessible from, or are accessed by, the vulnerable computer resource,
wherein determining what computer resources in the networked computer system are accessible from, or are accessed by, the vulnerable computer resource includes monitoring traffic flows between the computer resources over a period of time to identify vulnerability paths from the vulnerable computer resource to other computer resources in the networked computer system;
implementing the remediation action if it is the safe remediation action to secure the networked computer system.