Patent Grant
12050696
Existing compliance and security systems for enterprise environments employ the use of agents for monitoring system integrity and reporting changes to one or more centralized compliance servers. However, existing agents are limited in a number of ways. Known examples of compliance agents are implemented as a monolithic Java agent that must be connected to a server almost continuously. Further, existing agents do not allow for plugins, quarantine, prioritizing of messaging, or disconnected operation. Accordingly, there is ample opportunity for improvement in the implementation of agents for monitoring system integrity and reporting changes.
Apparatus and methods for agent-based vulnerability management (ABVM) are disclosed for generating, sending, and receiving messages in a networked environment using autonomous (or semi-autonomous) agents.
The disclosed agent platforms are designed to address challenges presented in enterprise deployments of agents by, for example: reducing agent footprint, improving scalability, dealing with erratic computer networks, providing semi-autonomous operation, enhancing enterprise security, or providing a self-correcting framework. Practical applications of certain examples of the disclosed technology include performing operations relating to vulnerabilities, for example, identifying vulnerabilities (e.g., by scanning computer assets using agents), remediating vulnerabilities (e.g., by generating configuration changes to mitigate or eliminate identified vulnerabilities), report generation (e.g., providing a risk score used to assess a degree of vulnerability in one or more computing assets in an environment), and using these vulnerability operations for file integrity management (FIM), security configuration management (SCM), real-time detection, logging, and/or reporting of threats or anomalies, vulnerability and/or risk scoring, and policy compliance.
A system of one or more computers can be configured to perform disclosed operations by having computer-executable instructions, circuits, or other software, firmware, or hardware provided in the system that when in operation causes or cause the system to perform the disclosed operations. One general aspect of the disclosed technology includes a method of analyzing vulnerabilities with an agent, the method including: with a vulnerability scanner, searching for first data associated with a vulnerability test to determine whether the first data associated with the vulnerability is available or not available. The method of analyzing vulnerabilities also includes when the first data associated with the vulnerability test is available in a vulnerability scanner database, providing the first data to a vulnerability aggregation server. The method of analyzing vulnerabilities also includes when the first data associated with the vulnerability test is not available in the vulnerability scanner database, performing a scan of the host to obtain second data associated with the vulnerability test. Other aspects include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
Certain examples can include one or more of the following features: The method further including: with the vulnerability scanner, receiving first data from a host including data generated by performing a vulnerability test on the host with an agent and storing the first data in a vulnerability scanner database. The method further including: with the vulnerability scanner, sending the first data or the second data to a vulnerability aggregation server. The method where the first data includes an input command file. The method where the first data includes execution results generated by executing at least one command encoded within an Open Vulnerability Assessment Language (OVAL) file. The method further including performing the scan during a time period when the vulnerability server does not have an active network connection to the host. The method further including: sending a prequalifier indicator indicating a prequalifier conditional associated with the vulnerability test to the host. The method can also include with the host, comparing a configuration aspect of the host to the prequalifier conditional. In some examples, performing the scan is not performed unless the comparing indicates the configuration aspect is suitable for the prequalifier conditional. In some examples, the prequalifier conditional indicates an operating system, an operating system version, an application, or an application version installed on the host. In some examples, the method further includes searching for the data by using a description of the vulnerability test as a search key. In some examples, the method further includes performing the scan by executing operations specified by the search key. In some examples, the method further includes providing the search key to the agent for executing the search key. According to another aspect, examples can include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
One general aspect of the disclosed technology includes computer-readable storage media storing computer-executable instructions, which when executed, cause a computer to perform a method, the instructions including: instructions that cause the computer to invoke a database search for first data associated with a vulnerability test to determine whether the first data precludes scanning a host. The computer-readable storage media also includes instructions for, when the first data associated with the vulnerability test is available in a vulnerability scanner database, providing the first data to a vulnerability aggregation server. The computer-readable storage media also includes instruction for, when the first data associated with the vulnerability test is not available in the vulnerability scanner database, performing a scan of the host to obtain second data associated with the vulnerability test. Other aspects include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
Certain examples can include one or more of the following features: The computer-readable storage media where the first data includes a registry entry or signature. The computer-readable storage media where the first data includes a description of the vulnerability test including an instruction executed by the host as part of performing the scan. In some examples, the instructions further include: instructions that cause the computer to compare a prequalifier indicated in the first data or in the second data to a configuration aspect of the host. The computer-readable storage media can also include instructions for, based on the comparing, determining to perform the scan. In some examples, the first data or the second data include OVAL data. According to another aspect, examples can include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
In some examples, an apparatus includes at least one processor, memory, and any one or more computer-readable storage media disclosed herein.
Another general aspect of the disclosed technology includes a method that, with a host, executes at least one command specified by an input file. The method also includes with the host, sending results from the executing the at least one command to a vulnerability scanner to store the results in a cache at the vulnerability scanner as a key-value pair, where the at least one command is the key of the pair, and the results are the value of the pair. Other aspects include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
Certain examples can include one or more of the following features. The method further including, with the vulnerability scanner: searching for a result in the cache using a key. The method can also include when data associated with the key is not available or is determined to be invalid, causing the host to execute the at least one command. In some examples, the host executes the at least one command when the host does not have an active network connection to the vulnerability scanner. In some examples, the method further includes, with the vulnerability scanner, and responsive to receiving the results from the host: storing the results in the cache at the vulnerability scanner. The method can also include sending a prequalifier description to the host. The method can also include receiving from the host a description of the host. The method can also include based on the description, selecting the at least one command to be sent to the host. In some examples, the key specifies a vulnerability test expressed using OVAL. According to another aspect, examples can include corresponding computer systems, apparatus, and computer-executable instructions stored on one or more computer readable media that cause a processor to perform one or more of the disclosed methods.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. All trademarks used herein remain the property of their respective owners. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The foregoing and other objects, features, and advantages of the disclosed subject matter will become more apparent from the following Detailed Description, which proceeds with reference to the accompanying figures.
I. General Considerations
This disclosure is set forth in the context of representative embodiments that are not intended to be limiting in any way.
As used in this application the singular forms “a,” “an,” and “the” include the plural forms unless the context clearly dictates otherwise. Additionally, the term “includes” means “comprises.” Further, the term “coupled” encompasses mechanical, electrical, magnetic, optical, as well as other practical ways of coupling or linking items together, and does not exclude the presence of intermediate elements between the coupled items. Furthermore, as used herein, the term “and/or” means any one item or combination of items in the phrase.
The systems, methods, and apparatus described herein should not be construed as being limiting in any way. Instead, this disclosure is directed toward all novel features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with one another. The disclosed systems, methods, and apparatus are not limited to any specific aspect or feature or combinations thereof, nor do the disclosed things and methods require that any one or more specific advantages be present or problems be solved. Furthermore, features or aspects of the disclosed embodiments can be used in various combinations and subcombinations with one another.
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed things and methods can be used in conjunction with other things and methods. Additionally, the description sometimes uses terms like “produce,” “generate,” “display,” “receive,” “evaluate,” “vulnerability,” “weakness,” “scan,” and “perform” to describe the disclosed methods. These terms are high-level descriptions of the actual operations that are performed. The actual operations that correspond to these terms will vary depending on the particular implementation and are readily discernible by one of ordinary skill in the art having the benefit of the present disclosure.
Theories of operation, scientific principles, or other theoretical descriptions presented herein in reference to the apparatus or methods of this disclosure have been provided for the purposes of better understanding and are not intended to be limiting in scope. The apparatus and methods in the appended claims are not limited to those apparatus and methods that function in the manner described by such theories of operation.
Any of the disclosed methods can be implemented using computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable storage media, such as one or more optical media discs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as hard drives and solid state drives (SSDs))) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). Any of the computer-executable instructions for implementing the disclosed techniques, as well as any data created and used during implementation of the disclosed embodiments, can be stored on one or more computer-readable media (e.g., non-transitory computer-readable storage media). The computer-executable instructions can be part of, for example, a dedicated software application, or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., as an agent executing on any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.
For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C, C++, Java, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well-known and need not be set forth in detail in this disclosure.
Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
II. Example Computing Network Environment
A vulnerability scanner 140 is used to scan the host that is hosting the agents. The agents can also send data to the vulnerability scanner that is generated by executing commands previously, such as when the host is off-line or otherwise not available. These results can be stored in a database or cache at the vulnerability scanner 140 and used to assess vulnerabilities on the host. Thus, by not requiring real-time access to the host 105 hosting the agents, system performance can be improved by allowing for cache results to be used. A person of ordinary skill in the relevant art having the benefit of the present disclosure could adapt existing commercial vulnerabilities, for example, a Tripwire® Device Profiler appliance, for implement technologies disclosed herein.
Each of the agents 110-112 communicates with the rest of the system depicted in the computing environment 100 via a vulnerability scanner agent platform server 150. As shown, the vulnerability scanner agent platform server 150 includes an agent bridge 160 for sending messages to and from agents (e.g., agents 110-112). The agent bridge 160 can send messages over a computer network to agents executing on other computers, using inter-process and/or inter-thread communication to agents executing on the same computer as the communication bridge, or by using other suitable communication means.
An agent reconciliation service 163 can be used to match previous agent identifiers and operating system information with current identifiers and current operating system information. This reconciliation service ensures continuity in data and logging information stored in the agent data consumers 190.
An agent provisioning service 165 can be used that informs agents about their initial configuration information, configures the agents with specific combinations of plugins, or provides an upgrade of agent or plugin executable code. The agent provisioning service 165 can send discovery and configuration templates to the agents for execution and configuration of the respective receiving agent.
The illustrated vulnerability scanner agent platform server 150 also includes a message broker 170 with multiple message queues for temporarily storing messages received from and sent to, for example, the agent bridge 160, an agent manager 180, an affinity service 185, and agent data consumers 190. In some examples, the message broker 170 has a single message queue. The vulnerability scanner agent platform server 150 coordinates operation of the agents by sending and receiving messages using the message broker 170.
Some vulnerability scanner agent platform server implementations can contain more than one message broker 170 organized as a network of message brokers. Additionally, some implementations can include additional instances of the agent bridge 160 or the agent manager 180. Various combinations of message brokers, agent bridges, and agent managers can be used to support high-availability and redundant capabilities.
As shown in
In some examples of the disclosed technology, for example, in large networks with multiple vulnerability scanner agent platform servers 150 and multiple agent data consumers 190, the affinity service 185 would be external to the vulnerability scanner agent platform server and centralized to improve communications with all instances of the vulnerability scanner agent platform server and destination agent data consumers.
The exemplary computing environment 100 includes a number of destination agent data consumers 190, including, but not limited to, multiple log servers (190-1 and 190-2), a compliance server 191, a policy server 193, a change management server 194, multiple file integrity monitoring (FIM) servers (195-1 and 195-2), and a vulnerability aggregations server 196. In some examples the multiple log servers and/or the multiple FIM servers are hosted on separate virtual machines on the same physical hardware (e.g., a computing server). In some examples, the multiple log servers and/or the multiple FIM servers are hosted on separate physical machines in the same computer network environment. In some examples, multiple log servers and/or the multiple FIM servers are hosted on separate physical machines in different computing environments.
The affinity service 185 provides mappings to the message broker 170 and/or agent bridge 160 in order to direct message flow from the agents (e.g., agents 110-112) to one of the multiple log servers and/or multiple FIM servers. The affinity service 185 can utilize universally unique identifiers (UUIDs) in order to identify the agents 110-112 and destination agent data consumers 190.
In some examples, the affinity service 185 maintains a table representing the associations between agents (e.g. agents 110-112) and one or more of the destination agent data consumers 190). The agents can be assigned using a number of methodologies, including but not limited to assignments based on: round robin, load and/or capacity of one or more of the destination agent data consumers 190, geographic location of the agents and/or the destination agent data consumers, network topology (e.g., by physical subnets or virtual local area network (VLAN), function roles (e.g., a respective consumer and/or agent is deployed for product development, testing, staging, or production), version of an agent, and/or version of a destination agent data consumer.
In some examples, the affinity service 185 directs routing of messages from agents by intercepting an agent online message emitted by the agent manager 180. The agent online message is enhanced by providing the product server UUID assigned to the agent by the affinity service 185.
In some examples, the affinity service 185 maintains an affinity map that defines relationships between agents and destination agent data consumers. In some examples, the affinity service is configured to map each of the agents to a respective one of the data consumers. In some examples, the affinity service mapping is based at least in part on one or more of the following: a geographic location of one or more of the agents and/or the destination agent data consumers; topology of a network carrying communication between the destination agent data consumers, vulnerability scanner agent platform servers, and/or agent computing hosts; a functional role of one of the agents and/or one of the destination agent data consumers; a version of an agent; and/or a version of a destination agent data consumer.
Different combinations of destination agent data consumers 190 can be deployed in the environment 100 according to the desired compliance and security applications to be performed. These combinations are not limited to a single machine. The agent bridge 160, message broker 170, agent manager 180, or any combination of the destination agent data consumers can execute on separate computers, or separate virtual machines on a single or multiple computers. For example, the compliance server 191 can host a Compliance and Configuration Control (CCC) tool used to detect, analyze, and report on change activity in an IT infrastructure. The CCC tool can assess or receive configurations of the one or more assets at one or more locations and determine whether the assets comply with internal and external policies (e.g., government, regulatory, or third-party standards, such as Sarbanes-Oxley, HIPAA, ISO 27001, NIST 800, NERC, PCI, PCI-DSS, Basel II, Bill 198, CIS, DISA, FDCC, FFIEC, GCSx, GLBA, GPG 13, IBTRM, or other IT infrastructure compliance standards). The CCC tool can identify and validate changes to ensure these configurations remain in known and trusted states.
In particular implementations, the CCC tool operates by capturing a baseline of server file systems, desktop file system, directory servers, databases, virtual systems, middleware applications, and/or network device configurations in a known good state. Ongoing integrity checks then compare the current states against these baselines to detect changes. The CCC tool collects information used to reconcile changes detected by the agents 110-112, ensuring they are authorized and intended changes. The CCC tool can crosscheck detected changes with defined IT compliance policies (e.g., using policy-based filtering), with documented change tickets in a change control management (“CCM”) system, with a list of approved changes, with automatically generated lists created by patch management and software provisioning tools, and/or against other desired and approved changes. This allows the CCC tool to automatically recognize desired changes and expose undesired changes.
The CCC tool can also generate one or more reports concerning the monitored assets showing a wide variety of information (e.g., compliance information, configuration information, usage information, etc.) The compliance-related reports generated by the CCC tool can, in some instances, comprise a score for an asset that indicates the relative compliance status of the asset as a numerical value in a range of possible values (e.g., a score of 1 to 100 or other such numeric or alphabetical range). The CCC tool can also apply a set of one or more tests to the assets to evaluate the compliance status of one or more assets. In such embodiments, the compliance-related reports generated by the CCC tool can include the number of devices that passed a particular test as well as the number of devices that failed the test. Further, the CCC tool can store detected change event data in an event log or transmit the event data as soon as it is detected or shortly after it is detected. Event logs typically comprise a list of activities and configuration changes at assets of the IT network.
An exemplary CCC tool that is suitable for use with the disclosed technology is the Tripwire® Enterprise tool available from Tripwire, Inc. The examples described below are sometimes shown or discussed as being used in connection with the Tripwire Enterprise tool. This particular usage should not be construed as limiting, however, as the disclosed technology can be adapted by those skilled in the art to help monitor and manage IT assets using other compliance and configuration control tools as well.
The compliance server 191 can also include a security information and event management (SIEM) tool that is used to centralize the storage and interpretation of events, logs, or compliance reports observed and generated in an IT management infrastructure. The event, log, and compliance report information is typically produced by other software running in the IT network. For example, CCC tools generate events that are typically kept in event logs or stored in compliance reports, as discussed above. The SIEM can be used to provide a consistent central interface that an IT administrator can use to more efficiently monitor and manage activity and configuration changes in an IT network. As needed, the IT administrator can access and use the CCC tool, which may provide deeper information than that provided by the SIEM. A SIEM tool can also integrate with external remediation, ticketing, and/or workflow tools to assist with the process of incident resolution. Furthermore, certain SIEMs include functionality for generating reports that help satisfy regulatory requirements (e.g., Sarbanes-Oxley, PCI-DSS, GLBA, or any other such requirement or standard such as any of those listed above). For these reasons, SIEM tools are becoming more widely adopted by IT administrators who desire to use a single, centralized interface for monitoring and managing their increasingly complex IT infrastructures.
Logging tools can operate similarly to SIEM tools. Accordingly, for any of the embodiments disclosed below, a logging tool may take the place of a SIEM tool. For ease of readability, however, reference will typically be made to just a SIEM tool. An exemplary tool for logging and SIEM that is suitable for use with the disclosed technology is the Tripwire® Log Center tool available from Tripwire, Inc.
III. Example Agent Implementation
In some examples of the disclosed technology, the agent 110 provides a common platform for executing pluggable platform and/or native code in a manner that does not require a concurrently active connection to either the agent bridge 160 or destination agent data consumers 190. By allowing unconnected operation, the agent 110 is better able to tolerate intermittent network connections, delays, and/or errors in the vulnerability scanner agent platform server 150, destination agent data consumers 190, or interconnecting networks.
The agent 110 includes functionality for automatically adjusting the rate at which data on the host system is acquired based on, for example, currently-available host system resources including cache resources, host system workload, or other host system resources. In some examples, cached data can be resequenced based on priority changes and observed behavior of the host system. In some examples, the agent can automatically adjust and prioritize transmission of cached data to the agent bridge 160, based on, for example, the amount of time the agent has been connected to the network, a network reconnection event, and/or using a pseudorandom number to determine when to send cached data to the agent bridge. In some examples, the adjusted rate is based on the amount of lag between messages in a spool (e.g., spooler lag can be defined by an agent as the amount of time between the oldest and newest unsent messages in a spool). In some examples, certain messages can be prioritized over others (e.g., messages carrying Security Content Automation Protocol (SCAP) data can be prioritized so that they are sent with higher priority than other types of messages).
In some examples of the disclosed technology, the agent 110 is implemented in a microkernel-based operating system platform, while in other examples, the agent is implemented using a more traditional monolithic kernel. The agent can include an embedded scheduler (e.g., executed by the local agent process 120 or another process) that determines when to execute agent tasks, even when the agent is not connected to a bridge or server.
In some examples, the agent 110 is a container-based agent that implements Federal Information Processing Standard (FIPS) cryptographic services for communicating and/or storing data. In some examples, information regarding FIPS containers, names, or other relevant FIPS fields are removed from data (e.g., before transmitting or storing FIPS data) to increase the difficulty of unauthorized decryption of FIPS communications and stored data.
In some examples, the agent 110 includes autonomous configuration capabilities. For example, the agent 110 can determine software versions and installed hardware associated with its host system or with installed plugins and based on the determined software and hardware, negotiate a more detailed configuration with any of the destination agent data consumers 190.
In some examples, the agent 110 includes support for on-demand push down of plugin modules. In some examples, the agent 110 includes the capability to automatically switch to different pre-designated endpoints by automatically switching to particular ports and/or bridges.
In some examples, the compliance server 191 communicates a desired spool depth to agents, which in turn adjust the rate at which data is sent to server. In some examples, when a spool associated with an agent becomes completely full, the agent can insert a mark in the spool and then, once space in the spool becomes available, peel off logs when data transmission resumes.
As shown in
An agent information module 225 is used to send messages with information about the agent and its associated plugins, including identification information (e.g., one or more UUIDs), catalogs of available messages the agent is capable of consuming or producing, and other agent information.
A message dispatcher 230 sends messages between an agent bridge (e.g., via a bridge connector) and agent plugins. In some examples, the message dispatcher 230 can send commands to an agent spooler. A message builder 235 is used to build messages sent by the message dispatcher, including envelopes for such messages.
A plugin manager 240 including a number of plugin connectors 245-247 for connecting the agent to its plugins. A thread manager 250 is used to manage agent threads (e.g., bridge writer threads, plugin manager threads, asynchronous I/O threads, or other agent threads).
A bridge connector 260 is used to connect to one or more agent bridges and send messages from, for example, the message builder.
A multi-file spooler 270 includes multiple spool files 275-277 that can store data from the plugin manager before the data is sent to, for example, one or more of the agent bridges.
A plugin configurer 280 can be used to configure agent plugins according to a received configuration template. The configuration template describes data to be gathered by the agent, frequency with which to gather the data, and formats to be used for generating augmentation and tag data generated by the plugin for sending to a vulnerability scanner.
In some examples of the disclosed technology, agents are designed to provide multi-platform functionality, thus allowing developers to develop agents for, e.g., both Windows and Posix platforms concurrently.
In some examples, agents and their corresponding plugins are written in C++ using multi-platform libraries and coding methodologies. In some examples, using languages such as C++ allows for a smaller agent memory footprint than agents implemented using other languages, e.g., Java.
In some examples, one or more agents (e.g., agents 110-112), agent bridges (e.g., agent bridge 160), and/or destination agent data consumers 190 (e.g., compliance server 191) can be co-located on the same computer system. In other examples, each of the agents, agent bridges, and compliance servers are installed on separate computing systems that are connected using a network or other communication means, or are installed within separate virtual machines connected on a single computing system.
In some examples of the disclosed technology, the agent is executed as a non-root/non-administrator user. This provides additional security by restricting access, but in some deployments, it may be desirable to allow limited administrator access to the agent and/or a subset of agent plugins to, for example, allow access to administrator resources (e.g., to access the Windows Event Log (WEL)).
The agents can communicate to the bridge using, for example, a proxy provided that supports the SOCKS5 protocol, although other protocols can be employed. In some examples, it is desirable to utilize authentication features provided by the network protocol to limit access to, for example, the bridge and/or compliance server to authenticated agents. In some examples, the SOCKS5 proxy used can be previously installed by a system administrator, and be used to support other communications unrelated to agent traffic. One desirable aspect of not including a proxy server within an agent is that the attack surface of the agent is reduced, as there is no open SOCKS5 port for attackers to attempt to attack.
A number of different aspects can be realized by using agent-based vulnerability management according the certain examples of the disclosed technology. For example, by using a credentialed agent on the host, bottlenecks created by performing external credentialed scans can be avoided. As another aspect, the use of agent-based vulnerability management allows for distribution of agents with machine images for deployment in cloud environments, thereby providing vulnerability assessment from the initiation of a new virtual machine instance. As another aspect, agent-based vulnerability management can be used to provide event-based scanning for vulnerabilities, for example triggered by configuration or file system changes detected on the agent's host. As another aspect, the use of network resources to discover and assess vulnerability state of associated hosts can be reduced. For example, vulnerability assessment data can be collected by the agent and then reported at a later point in time. As another aspect, agent-based vulnerability management improves the use of hosts at dynamic network addresses as the agents can provide the host with a universally-unique identifier (UUID) used to identify the host. As another aspect, devices that may be intermittently connected to a network can be scanned by the agent at any time the host is active, and results of vulnerability assessment can be provided at a later point in time, when the host becomes connected to the network and able to communicate with the vulnerability scanner.
In some examples, the spooler 270 is supplemented by a parallel Last-In First-Out buffer (LIFO) for certain types of messages. For example, because consumers of SCAP information often prioritize the most recent data available over older data, the agent can use a LIFO as a second spool for data coming from, e.g., an OVAL plugin, such that the newest messages are transmitted to the server first.
IV. Example Data Collection and Transmission System
As shown in
The vulnerability scanner 320 is implemented with a computing system and can include one or more physical processors and memory implemented using any suitable computing hardware. For example, the computing system processor(s) can be implemented with general-purpose CPUs and/or specialized processors, such as graphics processing units (GPUs) or tensor processing units (TPUs); application-specific integrated circuits (ASICs), or programmable/reconfigurable logic, such as field programmable gate arrays (FPGAs) executing on any suitable commercially-available computer), or any suitable combination of such hardware. In some examples, the processor can be implemented as a virtual processor executing on a physical processor under control of a hypervisor. In some examples, the processor can be implemented using hardware or software emulation to execute at least some instructions formatted in a different instruction set architecture than the native instruction set of the host processor providing instruction emulation. The vulnerability scanner memory can include volatile memory (e.g., registers, static random access memory (SRAM), dynamic random access memory DRAM), non-volatile memory (e.g., read only memory (ROM), programmable read only memory (PROM), electrically erasable programmable memory (EEPROM), flash memory, etc.), or some combination of volatile and non-volatile memory types. The vulnerability scanner 320 can further include a network interface that interfaces the vulnerability scanner to a wired and/or wireless communications network. In a virtual host environment, the network interface can be a virtualized network connection provided by the virtual host.
The vulnerability scanner 320 can be further configured to initiate discovery services by sending discovery requests to one or more of the agents to gather data regarding resources and plug-ins available on each respective agent. A discovery script or other computer-executable instructions are executed by a respective agent and can send a report back to the vulnerability scanner or can configure the agent itself. For example, the discovery script can cause the agent to be configured to augment data that it collects to allow for routing by the vulnerability scanner. For example, the augmented data can allow the vulnerability scanner to forward data to one of the destinations using a stateless protocol, thereby reducing the amount of computation performed by the vulnerability scanner in order to determine a destination. The destination agent data consumers can include relational databases, non-relational databases, map-reduce computing clusters (e.g., Hadoop), or resilient distributed dataset clusters (e.g., Apache Spark). Examples of some methods that can be performed in conjunction with the pipelines 340 are discussed in further detail at
The vulnerability scanner 320 can establish network connections to hosts and their agents using any suitable protocol, including unsecure network access protocols (e.g., file transport protocol (FTP) or Telnet), or desirably, secure network access protocols such as Secure Shell (SSH), Hypertext Transfer Protocol Secure (HTTPS), Transport Layer Security (TLS), or Virtual Private Networking (VPN). Once a secure tunnel has been established, communication between the vulnerability scanner 320 can be bi-directional. Scripts or other programs can be executed on the host or by an agent on the host to gather data regarding vulnerabilities. In some examples, some vulnerability analysis is provided by external tests that are not executed by an agent (e.g., identifying to which ports a host is listening), while in other examples, vulnerability analysis is carried out solely by one or more agents executing on the host.
In some examples, the vulnerability scanner 320 is configured using a programmable template 370. The template 370 provides a way to create rules, and logic for implementing such rules in a programmable fashion, allowing for improved flexibility and vulnerability scanner performance. In some examples, the template 370 includes rules based on at least one or more types of information about the host machine, including: operating system, operating system version, hypervisor, hypervisor version, system patches, programs installed, and/or other information. The rules can configure the behavior of the routers 330 and/or pipeline 340 to direct messages from the agents according the types of information. In some examples, data messages from the agent include an indication of the host machine information. In other examples, the vulnerability scanner 320 discovers such information about the host machines and associates this information with agents and/or their associated plugins. Messages received from the agents are then cross-referenced to determine which rules to apply to configure the routers 330 and/or pipelines 340.
In some examples, the template rules include rules based on assigned information for agents themselves. For examples, certain agents can be tagged at deployment to associate the agent with certain groups of agents. The rules are used to configure the routers 330 and/or pipelines 340 to direct messages based on tags associated with the agent. Examples of types of data agents can be tagged include associated owners of the agent, associate vulnerability scanners, load balancing, allocated resources, and other suitable types. In examples, the agent tags can be used to scale the destination set for agent message traffic. In some examples, data associated with a particular tag can be distributed to a plurality of two or more destinations. In some examples, data associated with a particular tag is distributed to a particular destination, in a one-to-one mapping. In some examples, messages are assigned to destination sets based on the type of data being carried by the agent message.
In some examples, the vulnerability scanner 320 initiates a scan by profiling a range of network addresses (e.g., IP addresses) and identifying computing assets accessible on the network. The vulnerability scanner 320 can initiate a port scan, which can include testing one or more ports for a response, identifying protocols provided on particular port (e.g., port 80 provides http services), and identifying underlying application services and versions. When scanning of a device commences, vulnerabilities to check for can be selected based on protocols, ports, applications, services, or versions of applications or services provisioned on the host. Examples of data that can be analyzed to identify vulnerabilities include, but are not limited to: network traffic, registry key values, file versions, file contents, command output, access control list, and service interrogation data. For example, vulnerabilities associated with a particular version of Apache web server, SSH, or other application/service can be selected based on the identified version of the application. In some examples, vulnerabilities are identified on a present or not present basis. In other words, a binary score is provided for a given particular vulnerability. In some examples, a variable score from a number of possible values is determined for one or more vulnerabilities. A host score can be generated for a host based on a metric calculated from individual vulnerability scores. A number of different techniques can be used to calculate a host score, include a sum of scores, a weighted sum of scores (e.g., where certain vulnerability scores are multiplied by a weight based on the underlying vulnerability), a geometric sum, an average, mean, or media, or other suitable technique. Examples of suitable scoring systems include proprietary scoring systems, such as those provided by Tripwire®, and openly-available scoring systems, such as Common Vulnerability Scoring System (CVSS).
The vulnerability scanner 320 can generate a number of responses for detected vulnerabilities. For example, the vulnerability scanner can generate an alert or warning that is communicated to one or more of the agent data consumers 190 for reporting or reconciliation. One or more vulnerability scores can also be reported to the agent data consumers for reporting or reconciliation. One or more of the agent data consumers can mitigate the vulnerability by, for example, restricting access or authentication to the vulnerable host, changing configuration of the vulnerable host, installing or updating software to mitigate the vulnerability, or by taking other suitable mitigation actions.
V. Example System Including Host, Vulnerability Scanner, and VnE Server
As shown in
Also shown in
VI. Further Discussion of Disclosed Agents, Vulnerability Scanners, and Vulnerability Servers
As shown in
An agent transformer 521 may be used in some implementations in order to transform results received from agents into a consistent form for storage in the vulnerability server database 530. For instance, agents may provide results in different formats, and so using the agent transformer offloads processing of reports for consistency to the vulnerability server 510, and may also allow for the vulnerability server to use reports provided by legacy agents that provide reports in different formats. As one example, the agent transformer 521 can transform the following OVAL system characteristic for a registry key:
into an agent hint key/value pair:
An agent data loader 522 is used to couple agents to the vulnerability server database 530 and can pass messages between the agents and the database. Examples of suitable messages include messages based on data stored in the database 530 including agent hints, agent vulnerability results, OVAL system characteristics, OVAL results, agent inventory, and transformation rules which can be between host agents and the database via the agent data loader 522. The agent supervisor 520 can receive OVAL content stored in one or more storage devices 535 coupled to the vulnerability server 510 that is used to maintain and configure the host agents. Further, the agent supervisor 520 stores agent information in the database 530. One operation performed by the agent supervisor are sending agent request messages, which are broadcast to agent access points, and processing the resulting response messages. Sending the requests can occur on a configurable interval and processing the responses will occur asynchronously as they arrive. When an agent request is sent the agent supervisor 520 will track which known agent access points (e.g., access point 547) have responded. Once all known agent access points have responded, any existing agent records in the agent_agent table that were not updated are marked offline. In a similar fashion, the agent supervisor 520 can send configuration requests to agents and request client data from the agents.
In some examples, the configuration of an agent for vulnerability management is a two-phase process: qualification and configuration. Before an OVAL policy can be sent to an agent the agent supervisor determines which is the correct policy to send. In the first phase, the agent is configured with the pre-qualification content. If the supervisor inventory thread finds the agent to be unqualified, it is queued for processing by the configuration thread. The configuration thread will configure the agent's plugin to run the qualification bundle. This OVAL configuration will be run on a schedule so that changes, like OS upgrades or service pack installations, will be accounted for soon after they happen. Unlike the regular OVAL content, the results will be returned to the agent supervisor 520 rather than the agent data loader 522. If this cannot be accomplished directly, the Agent Transformer will be updated to ignore the qualification results. The inventory thread also assesses a qualified agent against its OVAL configuration.
The second phase occurs once an agent is recorded and qualified. Using the results of the qualification and the contents of an agent configuration identifier, the inventory thread can determine whether the agent should be re-queued for update by a configuration thread. For example, If the agent identifier string does not match the config value for the current ASPL and schedule, the agent is added to a task queue for updating. Alternatively, the agent identifier could include a bundle ID for a policy that no longer applies because of a service pack update.
The vulnerability server 510 further includes an alerting module 537, that can be used to send alerts for logging or analysis to servers in a computing cloud 540, or to send data to other consumers of vulnerability alerts, for example an administrative interface used to identify and respond to vulnerabilities detected in one or more of the target hosts.
In some examples of the disclosed technology, the vulnerability server 510 communicates directly with the target asset 570 host in the agent 575. In other examples, a messaging service is used including for example, an agent gateway 545 and an agent access point 547. The gateway and access points are optional to some implementations. The access point 547 receives and sends messages to the agent 575. For example, the access point 547 can be configured to receive and send data to and from a large plurality of target hosts in a network. It can use various identification techniques in order to track and select the right agent on the network for sending and receiving messages to and from. The agent gateway 545 can be used to access networks outside the local-area network that the target assets 570 are communicating on. The agent gateway 545 or the agent access point 547 can include a message queue that is used to temporarily store messages to be received from or sent to the target asset 570, prioritize messages, and control message volume, for example, by stalling messages or deleting low priority messages when bandwidth is scarce or the number connection is temporarily inactive.
The vulnerability scanner 550 can use data collected from agents running on the hosts 570 there are also scanned remotely by the vulnerability scanner. Being able to use agent data as well as scan data can provide speed, efficiency, and/or flexibility in using the vulnerability scanner 550. Further, agent plugins can allow for modular configuration and operation of the agents 575. The vulnerability scanner 550 scans can be augmented with agent data by augmenting date of the rules are run against, agent hints, and by augmenting the eventual result of performing such rules, agent vulnerability results. These two techniques can be used independently but also in a complementary fashion. In some examples of the disclosed technology, only one of these techniques is implemented.
Vulnerability scanner scans performed using agent hints can be improved by using data gathered by agents during agent-based scans. This can increase scanning productivity and reduce the use of credentialed access. Agent-less scans executed by the vulnerability scanner 550 can use a caching mechanism that uses hints. A hints cache is maintained for each context that is scanned, for example, each protocol/port pair. Each unique request and response can be cached in the profiler cache so that subsequent rules that use the same scan data can get it from the cache instead of making an additional request to the target asset 570. Data received from the agent can be used to pre-populate the cache, removing the use of an initial scanning request.
The vulnerability scanner 550 can be provided with a unique agent identifier for each agent 575. This agent identifier is used to populate the agent hints module 555 and the agent profiler cache 556. The vulnerability scanner can inquire the vulnerability server 510 in order to associate and agent identifier with a network address (e.g., an Internet protocol (IP) address).
The vulnerability scanner 550 can be implemented using one or more processors and includes a profiler module 551 that manages sending vulnerability data, performing external profiler scans of hosts, and receiving results from the agents. As shown, the scanner includes an agent hints module 555, an agent vulnerability results model 556, and a profiler cache 557. The cache 557 is used to map agent hints to commands that will be executed on the target asset when performing scans. The agent vulnerability results are received from the target asset 570 and can be stored in the profiler cache. In some examples, the profiler cache 557 is indexed by the command or commands used to generate a vulnerability results are used as the key of a key value pair, and the result of a previous execution of the commander commands is the value of the key value pair stored in the cache. In some examples, hints are manually populated, while in other examples, hints for a host can be retrieved from the vulnerability server 510.
The profiler 551 communicates with the host daemon and the database daemon at the vulnerability server 510 to implement methods of vulnerability scanning described herein. For example, some vulnerability scans may be performed by the agent 575 executing at the target asset 570. In some examples, when vulnerability scans cannot be performed by the agent 575, the vulnerability scanner 550 implements the scan. In some examples, the vulnerability scanner searches for data associated with the vulnerability test to determine whether the first data associated with the vulnerability is available or not available. When the data is available in the profiler cache 557, the vulnerability scanner 550 skipped scanning of the target asset 570 and instead provides result data from the profiler cache 557 to the vulnerability server 510. On the other hand, when data associated with the vulnerability test is not available in the vulnerability scanner database, example, because the device scan has not been run, or is out of date, or the agent at the target asset 570 cannot be reached or is otherwise unavailable, the vulnerability scanner performs a scan of the host to obtain data associated with the vulnerability test. This data from performing the scan can be stored in the profiler cache 557 and provided to the vulnerability server 510 responsive to requests for host results. Thus, the load on target assets by performing scans either using in the agent, or with the vulnerability scanner can be reduced. When the vulnerability server 510 collects data produced by scans and by agents executed on host, the vulnerability server acts as a vulnerability aggregation server.
In some examples, the system characteristics used to populate the cache database can include, but are not limited to, registry entries, object attribute metadata, including file attribute metadata (e.g., file versions, creation/modification dates, file size), object content metadata (e.g., hash-based signatures such as MD5 or SHA-1 for all or a portion of an object, or YARA descriptions or rules) or other objects at the target asset generated by the agent or by the scan. In some examples, execution results generated by executing the commands can be encoded within an OVAL file. In some examples, the scan can be performed during a time when the vulnerability server 510 or the vulnerability scanner 550 do not have an active network connection to the host. In some examples, the vulnerability scanner can send a prequalifier indicator that indicates a prequalifier condition associated with a vulnerability test to the target asset 570. The target asset can compare configuration aspect of the host to the prequalifier conditional, and determine whether to perform a scan based on this comparing. For example, the prequalifier can be a version of an operating system or application, and the host can skip a scan if the prerequisite version not available at the target asset 570. For example, vulnerabilities can be associated with specific versions of host operating systems or applications. In some examples, the vulnerability scanner 550 searches for data by using the description of the vulnerability test as a search key. In some examples, the vulnerability scanner performs a scan by executing operations that are specified by the search key. In some examples, the vulnerability scanner provides a search key to the agent for executing commands specified by the search key.
The vulnerability server can further provide modules, daemons, services, or other threads or processes for communicating to the vulnerability scanner 550. As shown, the vulnerability server 510 is hosting a host daemon 531 that receives results from the vulnerability scanner 550 and sends them to the vulnerability server database 530 for storage. The vulnerability server 510 also hosts a database daemon 532 that retrieve data from the vulnerability server database 530 and sends the data to the vulnerability scanner 550 responsive to queries from the vulnerability scanner.
In the illustrated process diagram, the vulnerability server 510 hosts an agent configuration thread 610, an agent task queue 612, and agent inventory thread 614. The vulnerability server queue to case with the agent 624 via the agent access point gateway 620 and agent access point 622.
In the illustrated example, the process begins by the agent inventory thread 614 sending an online agent request to the agent access point 622. An online agent response message is sent to the agent access point gateway 620, which in turn sends an online agent response call back to the agent inventory thread 614. The agent inventory thread 614 updates the database 530 with information received in the agent response. Operations to be performed by the agent are sent by the agent inventory thread 614 to the agent task queue 612, which in response sends a command to the agent configuration thread 610, which in turn initiates an agent transfer request, which sends an agent transfer request message to the agent 624. This agent transfer request includes prequalification data that is used by the agent 624 to determine whether various scans initiated by the vulnerability server are applicable to the particular agent at this particular host. The agent then sends OVAL qualification results back to the vulnerability server, and the agent inventory thread 614 updates that database 530. The agent configuration thread 610 then sends a second agent transfer request to the agent that includes applicable vulnerability scanning data, based on their prequalification response sent by the agent in the first response. Data can be collected and compressed to reduce network load, for example by sending a number of files collected as an archive, which can be compressed using gzip or other appropriate compression software. For example, vulnerability definitions and rules can be contained in the archive, which may be produced as a gzip-compressed tar archive.
Before an agent is configured to run a platform-specific policy, the platform may be determined. One flexible way is to actually run an OVAL policy to determine the platform. Included in the OVAL content is a special prequalification content bundle. This content is a set of platform checks where the OVAL definition IDs correspond to the OVAL bundle platform IDs. When this content is executed whichever platform matches is recorded for the agent and used for subsequent configuration. By placing both policy creation and platform determination under vulnerability server control, new platforms can be added or platforms can be changed without needing any vulnerability scanner changes.
For each distinct platform version, such as Linux CentOS 6 or RHEL 7, the policy bundle can be provided as a tar file or other archive, which includes an OVAL definition eXtensible Markup Language (XML) file. The OVAL definition is executed by the agent with all results returned together. To reduce load, the agent may be configured to return minimal results, being the OVAL definition ID and the result value (pass, fail, error, etc.). XML need not be returned because this can generate an overwhelming amount of data to transfer and process. In some examples, both positive and negative results are returned.
For each platform, the policy bundle can be an OVAL definition file designed so that OVAL system characteristics can be used in the agent hints cache. The agent is configured to return full results so that the system characteristics XML is included.
VII. Example Schemas and Other Details of an Example Agent-Based Vulnerability Management System
Further details regarding example schemas and other details for implementing a particular example of an agent-based vulnerability management system are described below. As will be readily understood to one of ordinary skill in the relevant are having the benefit of the present disclosure, variations in the illustrated schemas and other aspects can be adapted to other examples of the disclosed technology.
A. Example ABVM Agent Groups
In some examples, settings for agents can be applied to all agents in a system. Agents can also be grouped by creating a network/agent through-table, creating a representational state transfer (REST) application programming interface (API) for agent networks, adding a user interface for agent networks, and/or providing a system for automatically grouping agents.
For example, a network/agent through-table can be created by using nc_network to create networks which are network_type=‘agent’ just like the system network. This will define the agent group.
The nc_network_range table can be used to define ranges for normal scans, and thus create a new table that defines the agents for this new network type.
B. Create REST API for Agent Networks
A new API endpoint can be created that lets the agent supervisor control these new agent groups. An example JSON (JavaScript object notation) file for a REST API can be expressed as shown in Table 1 below:
C. Adding User Interface for Agent Networks
In some examples, the system can provide a user interface (or a voice interface) that displays the new agent groups and lets users manually put agents into a group. This allows customers to manually fix groups as desired. The system can change the scan wizard to only allow selecting an agent network when an agent-only scan profile is selected.
D. System for Automatically Grouping Agents
In some examples, the system can automatically group agents. This will happen when a new agent is discovered, or if an administrator manually runs the created rules on a group (or on all non-grouped agents).
In some examples, this can be performed using a regular expression created for certain fields and grouped if matched. For example, a rule can be created for the “os_name” column in the table with a regex of “(windows|microsoft)” and then in Django the existing regex/iregex filters used to filter the columns securely. This allows for customization without resorting to lua scripts or other complications.
Further, using the “match_priority” column an administrator can control which group it should use if multiple fields are matched. This allows putting all fields for a specific version of an operating system into one group, and all other versions of the operating system into a catch-all group. To accomplish this, the table illustrated in Table 2 can be used:
A REST API can be used as well as a user interface and the ability to run the rules on existing agent groups (or all ungrouped agents). The supervisor can run the match rules when a new agent is added, and a system setting to turn that on and off in case the administrator wants to manually control it.
VIII. Example Method of Using a Vulnerability Scanner
At process block 1010, a host executes at least one command specified by an input command file. For example, an agent process configured to execute on the host can execute the specified command.
At process block 1020, the host can send results from executing the at least one command to a vulnerability scanner. For example, the result can be sent as a key-value pair, where the key indicates the specified command, and the value indicates the results of executing the at least one command.
At process block 1030, the vulnerability scanner stores results received from the host and a cache at the vulnerability scanner as a key-value pair. At least one of the commands is used to generate the key of the pair, and at least a portion of the results are used as the value of the key-value pair.
At process block 1040, the vulnerability scanner searches for result in the cache using a key. When data associated with the key is not available, or is determined to be invalid, the method proceeds to process block 1050. When the data associated with the key is available, the method proceeds to process block 1060.
At process block 1050, the vulnerability scanner causes the host execute the least one command. For example, the vulnerability scanner can access the host by tunneling, for example, using a Secure Shell (SSH) tunnel and executing the specified command on the host. Results obtained from executing the command in real-time are returned as the results of the selected scan.
At process block 1060, results stored as the key-value pair are returned as if the selected command associated with the key had been executed on the host. Thus, commands that have been stored in the vulnerability scanner cache can be used instead of performing commands at the host using, for example, a tunnel to access the host.
In some examples, the method further includes sending a pre-qualifier description to the host. The pre-qualifier can be expressed in an OVAL format. The host executes commands associated with the pre-qualifier, for example, identifying the system type or operating system installed on the host. This data can be used by the vulnerability scanner to select a set of commands to run selected based on the particular system type or operating system specified by performing the pre-qualifier test.
IX. Example Method of Using a Vulnerability Scanner
At process block 1110, the vulnerability scanner is used to search the cache for first data associated with vulnerability test to determine whether the first data is available are not available in the vulnerability scanner cache. For example, a key value pair where the key is the command used to scan and agent can be searched for in the profiler cache. If the first data is available in the profiler cache, the method proceeds to process block 1120 and the value associated with the first data is provided to a vulnerability aggregation server. In this instance, performing an additional scan of the agent can be avoided and results (second data) from a previous scan provided instead. If the first data is not available in the vulnerability scanner cache, the method proceeds to process block 1130 and a scanning of the host is performed to obtain second data associated with a vulnerability test. After the scan completes, resulting values from the scan are written to the cache and sent to the vulnerability aggregation server for storage in the vulnerability database.
X. Example Method of Using a System Characteristics File
At process block 1210, the host executes at least one command specified in the input command file. For example, shell commands or other system commands can be specified in the file and then executed. The commands are selected to generate data that will indicate whether a vulnerability exists on the host computer.
At process block 1220, the host sends results including system characteristics generated from executing the command to a vulnerability scanner. The vulnerability scanner can be implemented using systems described above regarding other vulnerability scanner examples.
At process block 1230, vulnerability scanner stores the results generated by the host in a cache at the vulnerability scanner as a key-value pair. The command used to generate the result is the key of the pair, and the results generated by the command are the value of the pair. The key is used to index the profiler cache such that future requests to obtain vulnerability data can be produced from the profiler cache instead of re-executing a scan on the host. In some examples, the vulnerability scanner additionally includes a local profiler database.
XI. Example Computing Environment
The computing environment 1300 is not intended to suggest any limitation as to scope of use or functionality of the technology, as the technology may be implemented in diverse general-purpose or special-purpose computing environments. For example, the disclosed technology may be implemented with other computer system configurations, including hand held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The disclosed technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to
The storage 1340 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and that can be accessed within the computing environment 1300. The storage 1340 stores instructions for the software 1380, plugin data, and messages, which can be used to implement technologies described herein.
The input device(s) 1350 may be a touch input device, such as a keyboard, keypad, mouse, touch screen display, pen, or trackball, a voice input device, a scanning device, or another device, that provides input to the computing environment 1300. For audio, the input device(s) 1350 may be a sound card or similar device that accepts audio input in analog or digital form, or a CD-ROM reader that provides audio samples to the computing environment 1300. The output device(s) 1360 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 1300.
The communication connection(s) 1370 enable communication over a communication medium (e.g., a connecting network) to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed graphics information, video, or other data in a modulated data signal. The communication connection(s) 1370 are not limited to wired connections (e.g., megabit or gigabit Ethernet, Infiniband, Fibre Channel over electrical or fiber optic connections) but also include wireless technologies (e.g., RF connections via Bluetooth, WiFi (IEEE 802.11a/b/n), WiMax, cellular, satellite, laser, infrared) and other suitable communication connections for providing a network connection for the disclosed agents, bridges, and destination agent data consumers. In a virtual host environment, the communication(s) connections can be a virtualized network connection provided by the virtual host.
Some embodiments of the disclosed methods can be performed using computer-executable instructions implementing all or a portion of the disclosed technology in a computing cloud 1390. For example, agents can be executing vulnerability scanning functions in the computing environment while agent platform (e.g., bridge) and destination agent data consumer service can be performed on servers located in the computing cloud 1390.
Computer-readable media are any available media that can be accessed within a computing environment 1300. By way of example, and not limitation, with the computing environment 1300, computer-readable media include memory 1320 and/or storage 1340. As should be readily understood, the term computer-readable storage media includes the media for data storage such as memory 1320 and storage 1340, and not transmission media such as modulated data signals or transitory signals.
In view of the many possible embodiments to which the principles of the disclosed subject matter may be applied, it should be recognized that the illustrated embodiments are only preferred examples and should not be taken as limiting the scope of the scope of the claims to those preferred examples. Rather, the scope of the claimed subject matter is defined by the following claims. We therefore claim as our invention all that comes within the scope of these claims.
This application is a continuation of U.S. patent application Ser. No. 16/895,928, filed Jun. 8, 2020, which claims the benefit of U.S. Provisional Application No. 62/858,662, filed Jun. 7, 2019, each of which is incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7243348 | Good et al. | Jul 2007 | B2 |
| 7316016 | Difalco | Jan 2008 | B2 |
| 7360099 | Difalco et al. | Apr 2008 | B2 |
| 7587754 | Difalco et al. | Sep 2009 | B2 |
| 7620715 | Difalco et al. | Nov 2009 | B2 |
| 7765460 | Difalco et al. | Jul 2010 | B2 |
| 7822724 | Difalco et al. | Oct 2010 | B2 |
| 8140635 | Difalco | Mar 2012 | B2 |
| 8176158 | Difalco et al. | May 2012 | B2 |
| 8819491 | Whitlock et al. | Aug 2014 | B2 |
| 9634951 | Hunt et al. | Apr 2017 | B1 |
| 9741017 | Good et al. | Aug 2017 | B2 |
| 9766873 | Steigleder | Sep 2017 | B2 |
| 10158660 | Reguly et al. | Dec 2018 | B1 |
| 10313257 | Hunt et al. | Jun 2019 | B1 |
| 10318894 | Difalco et al. | Jun 2019 | B2 |
| 10382486 | Rivers | Aug 2019 | B2 |
| 20020196330 | Park et al. | Dec 2002 | A1 |
| 20040024843 | Smith | Feb 2004 | A1 |
| 20040075738 | Burke et al. | Apr 2004 | A1 |
| 20040122962 | Difalco et al. | Jun 2004 | A1 |
| 20060206883 | Sabbouh | Sep 2006 | A1 |
| 20060242277 | Torrence et al. | Oct 2006 | A1 |
| 20070016960 | Glaser | Jan 2007 | A1 |
| 20070124255 | Difalco et al. | May 2007 | A1 |
| 20070239862 | Bronez et al. | Oct 2007 | A1 |
| 20080016501 | Muhlestein et al. | Jan 2008 | A1 |
| 20080021912 | Seligman et al. | Jan 2008 | A1 |
| 20080168420 | Sabbouh | Jul 2008 | A1 |
| 20100005107 | Difalco | Jan 2010 | A1 |
| 20100043066 | Miliefsky | Feb 2010 | A1 |
| 20110066951 | Ward-Karet et al. | Mar 2011 | A1 |
| 20110197094 | Wagner | Aug 2011 | A1 |
| 20110197189 | Wagner et al. | Aug 2011 | A1 |
| 20110197205 | Wagner et al. | Aug 2011 | A1 |
| 20110208841 | Robertson et al. | Aug 2011 | A1 |
| 20120023076 | Torrence et al. | Jan 2012 | A1 |
| 20120179805 | Difalco | Jul 2012 | A1 |
| 20120210434 | Curtis | Aug 2012 | A1 |
| 20170244622 | Salgueiro | Aug 2017 | A1 |
| 20170271027 | Childs | Sep 2017 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20230229788 A1 | Jul 2023 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62858662 | Jun 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16895928 | Jun 2020 | US |
| Child | 18186688 | US |
