Invented by Hassan Sultan, John Schweitzer, Donald Lee BAILEY, JR., Gregory Branchek Roth, Nachiketh Rao Potlapally, Amazon Technologies Inc

The market for threat detection through run-time instrumentation and introspection is growing rapidly as organizations seek to protect their data and systems from cyber attacks. Run-time instrumentation and introspection refer to the process of monitoring and analyzing the behavior of software applications while they are running. This approach allows for the detection of threats that may not be visible through traditional security measures such as firewalls and antivirus software. The need for run-time instrumentation and introspection has become increasingly important as cyber criminals have become more sophisticated in their attacks. Traditional security measures are often unable to detect these attacks, leaving organizations vulnerable to data breaches and other security threats. Run-time instrumentation and introspection provide a more comprehensive approach to security, allowing organizations to detect and respond to threats in real-time. The market for run-time instrumentation and introspection is expected to grow significantly in the coming years. According to a report by MarketsandMarkets, the market for runtime application self-protection (RASP) is expected to grow from $294.7 million in 2017 to $1.1 billion by 2022, representing a compound annual growth rate (CAGR) of 30.4%. The growth of the market is being driven by several factors, including the increasing frequency and sophistication of cyber attacks, the growing adoption of cloud computing and mobile devices, and the need for organizations to comply with regulatory requirements such as GDPR and HIPAA. There are several key players in the market for run-time instrumentation and introspection, including IBM, Cisco, Symantec, and Trend Micro. These companies offer a range of solutions that use run-time instrumentation and introspection to detect and respond to threats in real-time. One of the key benefits of run-time instrumentation and introspection is that it allows organizations to detect threats that may not be visible through traditional security measures. For example, a cyber criminal may use a legitimate user account to access sensitive data, making it difficult to detect through traditional security measures. However, run-time instrumentation and introspection can detect anomalous behavior and alert security teams to potential threats. In conclusion, the market for threat detection through run-time instrumentation and introspection is growing rapidly as organizations seek to protect their data and systems from cyber attacks. The increasing frequency and sophistication of cyber attacks, the growing adoption of cloud computing and mobile devices, and the need for organizations to comply with regulatory requirements are all driving the growth of the market. As the threat landscape continues to evolve, run-time instrumentation and introspection will become an increasingly important tool for organizations to protect their assets and maintain their competitive edge.

The Amazon Technologies Inc invention works as follows

A graph representing a plurality resources in a computing environment is created. The graph associates a first resource with a second. A graph representing the relationship between first and second resources is generated, at least partially, using measurements taken at a location in a test computing area. The graph is used to create a threat model that identifies potential threats to the computing environment.

Background for Threat detection through run-time instrumentation and introspection

A distributed computing system can include a range of resources such as software applications, data storage and network resources. It can be difficult for security experts to determine the relationships and interactions between these resources and resources outside of the distributed computing environment. As applications become more complex and use the system more frequently, it becomes harder to maintain security in the distributed computing system. It can be hard to identify and fix problems with the system. Even if issues are found, it may be difficult to secure the system reliably. These distributed computing systems might not be able to automate mitigation of these vulnerabilities.

The following description will describe various embodiments. Specific configurations and details will be described in order to give a clear understanding of the embodiments. It will be obvious to those skilled in the art, however, that embodiments can be used without requiring specific details. In order to not obscure the embodiment being described, certain well-known features can be removed or simplified.

Techniques discussed and suggested include the determination, by a computing service provider, of a set introspection points within a distributed computing systems. A distributed computing system can include both virtual and physical computing systems. A number of computing network environments may also be included in the distributed computing system. The introspection point set may be determined by the identifying characteristics available at each individual introspection point of the set. These include network protocol addresses, encryption keys or decryption key versions, software library version, process names and IDs, and virtual machine identities. The individual introspection points may allow for measurement of identifying characteristics. A graph can be generated using measurements and/or configuration information from the distributed computing system. A graph generated may contain a number of nodes that represent elements (also known as resources or components) in the distributed computing system. Edges between nodes indicate the relationships between them.

One or more rules can be evaluated against the graph. For example, a rule might specify that credentials should not have higher privileges than are necessary to access requested resources. Based on graph data, it could be found that credentials that were used to access a resource have greater privileges that they actually have. The system can take security actions such as notifying the appropriate entity (e.g. network security personnel, a customer of the computing service provider, etc.). the rule violation, or automatically modifying a security policy in order to limit the privileges of respective credentials to the minimum. A threat model can be created from the graph in some embodiments to show the potential vulnerabilities and/or rules violations in the distributed computing environment.

The proposed techniques and the described methods improve computing in distributed systems and, specifically, the field and field of threat detection in distributed systems. They provide a useful and new system to detect threats to large-scale distributed computing systems. The described and suggested methods improve the functionality of computer systems by allowing automatic updates to be made in response to rule violations and vulnerabilities. This reduces the risk of security breaches. The described and suggested methods offer significant advantages over other monitoring systems in that they allow customers of a computing resource provider to monitor a variety of resource types within a computing environment from locations normally only available to them.

FIG. “FIG. FIG. FIG. 1 illustrates that the computing resource service provider (102) may be part of the environment 100. This provider provides services through a distributed computing platform. These services could include, among other things, a virtual computer service 104 hosting a group of virtual machines, 106, a data store service 108 hosting data storage resources 110 and a policy management 112 for managing an entire set of policies. Users and customers may have access to resources within the environment 100 via the Internet 118 using an application programming interface provided 102 by the computing resource provider 102. FIG. FIG. 1 illustrates also a set 120A-120E of introspection points for gathering information about resource use within the system.

In embodiments, the present disclosure provides a distributed computing environment where a variety resource types, including hardware and software, are provided. This allows for the collection of information at various introspection points within an overall system. An “application system” may be used in some cases. An?application system? may be a group of computers that executes a particular software application. The set of computers may include multiple computing systems such as servers that are in communication with one another and/or with other resources. Configuration information can be used to store the configuration information of virtual computer systems. This includes the number of virtual machines in use, firewall rules, type, amount, location, and storage locations for each virtual machine. The configuration information could be stored in a format that is accessible to the computing resource provider 102 of virtual computer system service104, such as tables/records from an data store. Information that could be considered configuration information includes information such as the list of virtual machines (e.g. the set of virtual machines 106) ascribed by a customer owner, the number and identity processors of a particular virtual machine instance and the open and closed firewall ports for that virtual machine instance. The internet protocol addresses for the virtual computer and the software applications running on it.

The computing resource provider 102 may also detect and track all processes that are running within each virtual machine. The computing resource provider 102 can detect and flag when a previously unidentified process launches within a virtual computer. The computing resource provider 102 can also detect software dependencies between processes running in the virtual machine instance. The computing resource provider 102 might create a threat model that identifies potential security threats in the monitored system based on the data. Analyzing the data might include walking every node/edge of the graph and determining at each node whether or not there are security risks (e.g. Ya, etc.). ), and determine whether each resource represents a resource that is in compliance with the rules specified by a customer or computing resource service provider.

From this threat model, a customer, computing resource provider 102, or another authorized entity (e.g. network security personnel) may implement a security policy to reduce risks. A rule could be created based on the software dependencies of the processes in the environment to take a security measure if the process is found to use a different version of a software program. This rule could be driven by the possibility that older software libraries might have security vulnerabilities that were corrected in a newer version. A “security action” may be defined as: A?security action? may be an action taken by the computing service provider’s computing system to alert or mitigate a threat or violation to one or more elements of a computing environment. These security actions can include preventing the process running, logging the event (e.g. date, time and location of the process), logging the event (e.g. version of the software library), or sending an alert to the customer. You can send an alert to your customer or network security personnel, and the library will be automatically updated to the latest version.

Some other examples of security actions include the updating one or several security policies (i.e. information defining permissions or constraints on users and applications and other entities to use resources) that correspond to one or multiple entities (e.g. users, resources, apps, etc.). You can also send notifications to a notification service from a computing resource provider and queue a message in the message queue of a service. Other security actions include changing a network (e.g. change to a secure protocols) or initiating a forensics (e.g. capturing network traffic, memory or any other state of a virtual computer). Other security actions include terminating a virtual machines instance, isolating processes or virtual machines from a network for further analysis, rotating or blocking security credentials, rotating one- or more cryptographic key, revoking access to a resource by a user or another entity, and installing a software upgrade. Other security actions include saving a snapshot of the resource, terminating or re-instating a virtual machines instance that is behaving abnormally, storing a dump of a virtual machines instance and/or reverting back to an earlier version of a data storage.

A security action could also include the updating of a computer resource’s configuration to conform with one or more specific rules (e.g. close certain network ports, refuse communication from certain internet protocol addresses ranges, etc.). These rules can be implemented in many ways. For example, you could modify firewall rules (e.g. allowing/blocking specific ports, internet protocol addresses or network protocols), or update a configuration that corresponds to a virtual computing environment and/or the virtual machine 106 running under a Virtual Computer System Service. The present disclosure describes a variety of security actions. Any reference to security actions is intended to include any other security actions that are not explicitly mentioned.

Similarly, the computing resource provider 102 can track communications between processes or other entities that are connected to the local network of virtual machines. These tracked communications can be used by a customer, computing resource provider 102, or another authorized entity to detect firewall vulnerabilities. The computing resource provider 102 might determine that the virtual machine can communicate with another computing system (virtual and physical), based at minimum in part on the firewall configuration. After a period of monitoring, communication between the first and second virtual machine instances is not possible in this case. The computing resource provider 102 might decide that communication between the virtual machine instances is not possible, at least partially, because the firewall does not allow for it. The computing resource provider 102 can make a security decision based on this determination. This could include automatically updating firewall rules to prevent communication between the first virtual machine and the second virtual machine or communicating security concerns to customers.

Similarly, the computing service provider 102 can track requests (e.g. for access, data, etc.). “Similarly, the computing resource service provider 102 may track requests (e.g., for access, for data, etc.) by users and virtual machines and may also track the credentials associated with those requests. The computing resource provider 102 can determine if the credentials grant more privileges than they actually allow by performing an analysis of the requests tracked over a period. The credentials might be associated with write and read permissions to a database. However, they are only used for reading from the database. In such cases, the write permission could be unnecessary or even a security risk. The computing resource service provider, 102, may take security measures, such as notifying the customer account owner of a track virtual machine account of any excess privileges. Or, if requested, it may automatically reduce privileges to the ones actually required by the requesting entity.

Tracked data may also include information about which network connections use an encrypted protocol and which ones are not. This information could be used to create a threat model. If the computing resource provider 102 discovers that a virtual machine instance is communicating with another computing system using an unencrypted protocol then the computing resource provider 102 might notify the customer owner of one virtual machine instance about the possible risk associated with this unencrypted communication channel.

In addition, data collected at different times can be compared to detect changes in behavior, performance, or security threats. A software application could be updated to a newer version and then implemented in one or more virtual machines within the virtual computer environment. The information described in this disclosure can be tracked over a time period and then compared with information that was previously tracked for the same software application at a prior version. These comparisons can be used by the computing resource provider 102 or the customer owner to detect anomalies and security threats. In the above example of a virtual computer and another computing system that were initially allowed to communicate but never had, the computing resource provider 102 might detect that the virtual machine has started communicating with the other computing systems (or vice versa) after a software upgrade. This communication might be desirable behavior in some cases (e.g. they may have intended to communicate but were unable due to a configuration or software error), and the tracking information could serve as confirmation that the software upgrade had the desired effect. This communication might not be expected in other circumstances, such as when a software update contains security vulnerabilities that an entity is trying to exploit to gain access the second virtual machine. The computing resource service provider, 102, may take security measures such as alerting the customer of the virtual machines instances and/or blocking communication between them until the customer owner confirms that such communication is allowed.

As shown in FIG. “As illustrated in FIG. 1, the computing resource provider 102 may designate a series of introspection point 120A-120E to track the described information. A customer, computing resource provider or another authorized entity may designate a set of introspection point 120A-120E as data collection points. One or more introspection agents may collect information at these introspection points. Introspection points can be between a web request and the target, points in a network between applications and the endpoint of the communication. They also include error logs and other logs, information about the infrastructure for the computing environment, security controls (e.g. users, credentials and permissions). Policies for the computing environment, billing records, and database permissions. The set of 120A-120E introspection points may collect the following types of information: requestor identifiers (ID), date/time, service ID, date/time and application programming interface methods called. Source and destination interne protocol addresses, cryptographic key, hostnames, process IDs and/or user IDs are some examples. The introspection points can be used to identify which application programming interfaces are used in the environment 100, and to what degree, which credentials/cryptographic keys are being used, information on network traffic flow, hostnames domain names, running systems processes or user IDs.

Introspection point 120A, for example, is an introspection point that collects metadata about communications between virtual machines 106. Introspection point 120B is another example of an introspection point that collects metadata when a virtual device of the set 106 attempts access to or receive data from one or several data storage resources in the set data storage resource 110. Introspection point 120B monitors network communication between virtual machines and data storage resources. This may allow them to determine whether data being transmitted between the virtual machine (and the resource) is encrypted. The network communication between the virtual machine’s computer and the data storage resources at the introspection points 120B could also reveal information such as the identity of the logical storage container accessed at the resource, the credentials used to access it, and so forth.

Introspection point 120C also illustrates an introspection spot for collecting metadata about credential use and associated permissions, according to the set of policies. Introspection point 120C also illustrates an introspection way to collect metadata about communication between computing devices and a virtual machine 106 via the Internet 118. Introspection point 120E is a third example of an introspection points for collecting metadata about the utilization of one or several of the other services. 116, as may be provided to a virtual machine by the computing resource provider 102 of the virtual computer service 104. While the introspection point 120A-120E is shown as individual points, it’s possible that each of the introspection point 120A-120E could be considered a subset.

Introspection” may be used in some cases. It may be used to refer to the examination of systems behavior and data flows. The term “introspection point” may be used in some cases. The term “introspection point” may be used to refer to a data collection location, such as within the hypervisor or injection of executable software in application memory. It may also refer to a software program with elevated access permissions (also known as an “introspection agent?”). Executing on a computing device within the environment 100. Introspection point (or “sensor”) is a location where a computing system can be accessed. The introspection point (or?sensor?) may be an endpoint for a network connection, or it may include reading logs generated by the computing resource provider’s application programming interfaces. Introspection points for customers of computing resource service providers could also include billing records or a system with access to billing records. For example, a customer might request notification if there are any charges that exceed a certain rate or amount, if additional charges arise in any area of the computing environment, or if cumulative charges are higher than a normal or expected range. Introspection points can be used to gather metadata that may help determine the activity at that particular point. An example of an introspection point is an interface that uses a public-key cryptography (PKCS) system interface. This interface must comply with PKCS#11 and/or other appropriate standards. This would allow metadata to be collected about signing data when the interface is called to sign data.

An introspection point can also be identified at any other interface within the computing resource provider 102 environment 100.

In certain embodiments, the customer owner of one or several virtual machine instances can specify to computing resource provider 102, such through a web interface the set of 120A-120E introspection points (i.e. sensors), where an introspection agent will take measurements (i.e. gather information). A customer owner can also specify expected values and ranges for the measurements. The customer owner can also specify security measures that the agent should take (or cause to be taken) when certain measurements are outside of expected ranges or values. Additionally, they may specify allowed and disallowed behavior from components of their systems. The customer owner might request the computing service provider 102 to create a group of application agents that will monitor software applications running on the virtual machines 106. The customer owner might provide the interface with a list containing software applications that the customer expects to run on one or more of the virtual machines. If the computing service provider 102 finds any deviations, they may request notification. The computing resource service provider (102) may respond to this request by configuring the set of introspection agent to notify the customer owner if any process is executed that is not on the approved list of the set of virtual machine 106. This allows a customer owner to place (or deploy) sensors in specified locations in his environment within the distributed computer system. If such sensors are not already deployed, the application programming interface will allow the customer owner to do so without the need for separate software applications.

Click here to view the patent on Google Patents.