Dynamic network traffic sniffer

Techniques are disclosed relating to data discovery. A control program that is executing on a computer system may receiving a request to locate instances of data on a computer network having a plurality of computer systems that are managed by an orchestration program. The control program may perform multiple, limited-time-period deployments of a sniffer program to different portions of the computer network in order to sample network traffic from the different portions to determine whether instances of the data appear in the network traffic. The control program may receive, from the sniffer program, information that identifies one or more of the different portions of the computer network whose network traffic included instances of the data.

BACKGROUND

Technical Field

This disclosure relates generally to a data management system and, more specifically, to a probe capable of discovering the data topology of a computer network.

Description of the Related Art

Many companies gather and store data about their users, customers or employees. This data can include any manner of information, such as individual profile information, financial information, medical information, and activity information (e.g., location history). The amount of data that is gathered and stored can often be extremely large and it continues to grow quickly. The collection and management of data, however, can be problematic for companies. Companies are normally unaware of all the different types of personal data that they have on their system and even where that data is stored. This usually occurs because unstructured data (e.g., documents, photos, videos, etc.) accounts for most of the available data and such data is often scattered around layers of a network (e.g., a cloud network, a data center network, etc.) with poor structuring and visibility. As a result, companies are unable to identify and locate all the data that they have stored for individual customers/users across a myriad of computers and networks.

DETAILED DESCRIPTION

Without proper knowledge about how data is stored within a company's computer network, a company can neither protect that data from being stolen nor ensure that data privacy provisions are enforced on that data. As an example, without the proper knowledge, a company cannot know where to deploy a security system within their computer network to ensure that data is not stolen or misused. It may thus be desirable to identify portions of a computer network that store data that is deemed significant or is of interest to an entity (e.g., a company) so that the data can be properly managed. As used herein, the phrase “data of interest” broadly refers data that has been designated by an entity as having a certain level of importance to that entity. Data that is of interest to a first entity may not be of interest to a second entity—that is, the data itself does not have an inherent property that makes it important, rather it is only the opinion of an entity that causes that data to be important to that particular entity.

One approach for identifying portions of a computer network that store data that may be of interest to an entity is to monitor network traffic for such data. In various cases, a software program called a traffic sniffer can be deployed that monitors network traffic to help an entity to understand the topology of their network (e.g., what applications and services are running on the network). In one approach for deploying a traffic sniffer, the traffic sniffer is connected to the spam port of an aggregation switch, which connects a number of top-of-rack switches (including all the systems of those switches) to a central core switch of the network. In a virtual environment, however, traffic that flows between systems within a data center may not hit on the aggregation switch when that network traffic is forwarded directly by a virtual switch of a system within the network. As a result, the traffic sniffer misses traffic that may be helpful in understanding the topology of the network. In yet another approach, multiple traffic sniffers are deployed where at least one traffic sniffer is running on each TOR or even for each hypervisor of a virtualized computer network. Running one traffic sniffer per hypervisor or per TOR, however, introduces huge management and performance overhead, especially when trying to correlate all the traffics collected from different sniffers. Moreover, as the computer network grows, this approach becomes difficult to scale as more and more traffic sniffers have to be deployed, each of which is consuming resources of the computer network. Due to the very high cost that is required in that approach to analysis the traffic for an entire network, it can be difficult to find an appropriate insertion point for a program that can provide visibility of the enter network. Thus, it may be desirable to deploy traffic sniffers in a manner that allows for low overhead, low resource cost, and high scalability while also providing full coverage of the network so that the topology of the network can be understood and interested data can be discovered.

The present disclosure describes various techniques for identifying portions of a computer network that include data that is deemed of interest by an entity or may be of interest to that entity and for presenting the topology of the computer network and discovering the interested data from the network traffic, including portions of interest, to enable the entity to make an informed decision on where to deploy data collectors (discussed in greater detail below) or other systems within the computer network. In various embodiments that are described below, a control program performs multiple, limited-time-period deployments of a sniffer program to different portions of a computer network. Throughout this disclosure, the sniffer program can be referred to as a “dynamic” network traffic sniffer as it can be deployed to monitor the network traffic of a first portion of a computer network and then redeployed to monitor the network traffic of a second, different portion of the computer network. A dynamic network traffic sniffer stands in contrast to a “static” network traffic sniffer that is not redeployed to monitor the network traffic of different portions of a computer network. In a non-cloud-based environment, a sniffer program may be deployed to run on a virtual machine executing on a host system of the computer network. The sniffer program being described as deployed for a limited-time-period refers to the notion that the sniffer program does not remain on a host system for an unspecified amount of time. Instead, the sniffer program is deployed on a host system, removed, and then subsequently re-deployed to another host system of the computer network such that the sniffer roams the computer network as opposed to being fixed to a particular location. In a cloud-based environment, the sniffer program may be deployed as an instance in the cloud environment in which the cloud environment is configured to mirror network traffic from other individual instances to the sniffer program. The sniffer program being described as deployed for a limited-time-period within the context of the cloud environment refers to the notion that the sniffer program has network traffic mirrored from a first instance for a period of time and then the cloud environment is reconfigured to mirror traffic from a second instance to sniffer program. As such, the sniffer program does not have to be instantiated multiple times and does not move throughout the network, rather the cloud environment is reconfigured each time to permit the network traffic of a different portion (e.g., a different instance) of the cloud environment to be routed to the sniffer program.

While deployed, in various embodiments, the sniffer program monitors the network traffic of the area where it has been deployed in order to learn about the characteristics of that traffic. As an example, the sniffer program may sample the network traffic of a host system in order to identify if data of interest (e.g., financial information) is included in that traffic. The sniffer program may send its findings to the control program and then may be redeployed to monitor the network traffic of another portion of the computer network. In this way, the sniffer program can be said to “roam” the computer network, inspecting the network traffic of different portions of the computer network in order to help build a map of the topology of the computer network (e.g., to identify applications and services running on the network and where data of interest is or may be located). In some embodiments, the sniffer program can continue to roam the network to revisit portions of the network that have already been visited, as the landscape of the network can change (e.g., new software instances are instantiated).

The control program may generate a map of the topology of the computer network based on information collected by the sniffer program. Such a map may identify portions of the network that store data of interest to the entity. In various cases, once the topology of a computer network is understood, the amount of network traffic that is really of interest to an entity is much smaller than the entire network traffic of the network. As a result, instead of deploying a system, such as a data collector, to each hypervisor of the network (or for each instance of the cloud network), the entity may deploy the system (e.g., a data collector) to specific portions of the network. Thus, the entity may be able to gain a deeper visibility into their network and ensure that data is properly handled within the network without incurring the high resource cost of deploying a data collector to each hypervisor of the network.

In one example implementation, there are at least four separate systems that together enable the topology of a computer network to be understood and protected. These systems include a traffic sniffer that continually roams the network to discover portions of the network that may be of interest to entity, a data collector that provides real-time monitoring of traffic and enforcement of security policies against that traffic, a control program that deploys the traffic sniffer (and data collector) and generates a map describing the topology of the network, and an orchestrator program that deploys software programs on computer systems in the network. In various cases, multiple sniffer programs and/or data collector programs may be deployed within a computer network. For example, if a computer network has thousands of computer systems, it may not be feasible for a single sniffer program to analyze the network traffic of most or all of those computer systems. As such, multiple sniffer programs may be deployed in order to analyze the network traffic of such a computer network.

In the example implementation, the computer network includes multiple computer systems that are managed by the orchestrator program. A user may initially identify, to the control program, samples or information about data that is deemed of interest by the user. That is, the user may have a preference to know where particular data is located within a computer network and thus may provide an indication of such data to the control program—the user's input can denote the type of data that is deemed of interest to the user. For example, the user may provide a regular expression (or regex) to the control program that can be usable to extract certain information (e.g., social security numbers) from data (e.g., financial data). In some cases, the user may be presented with a set of predefined templates (e.g., a financial template) that have each been designed for identifying specific data within a computer network. As an example, the financial template may include machine learning models that have been trained to identify certain financial information from data objects extracted from network traffic.

Once the user has identified data of interest, the control program may interface with the orchestrator program to perform a series of deployments of the sniffer program onto the computer systems of the computer network. Accordingly, the orchestrator program can deploy the sniffer program on a computer system such that the sniffer program is connected to a network of that computer system and is able to sample data from that network. The sniffer program may sample the network traffic in order to identify (e.g., using regular expressions, machine learning models, etc.) instances of data (e.g., social security numbers) that are of interest to the user. The sniffer program may report discoveries of such data to the control program, including where that data was found. The sniffer program may be repeatedly removed and then redeployed to different computer system in order to provide the control program with information for generating a map identifying portions of the computer network where data of interest is stored. Accordingly, if the landscape of the network changes, the sniffer program may discover new portions of the network where data of interest can be found.

As part of generating the map of the topology of the computer network, the control program may score different portions of the network based on the information that is provided by the sniffer program (and/or data collectors). For example, a network portion that has high volume traffic and data of interest may be scored higher than a network portion with low volume traffic and data of interest. The user may use the map in order to determine where to deploy a set of data collectors for continuous monitoring of network traffic and to ensure that data is properly handled. The data collectors may further provide information to the control program to improve the map such that a user may gain greater visibility into the network.

These techniques may be advantageous as they allow for an entity to identify portions of a computer network where data of interest to the entity is stored. That is, these techniques discuss an approach that helps entities to understand the topology of their network, which includes understanding where data of interest is located, by deploying one or more traffic sniffers that roam around the network and sample network traffic to discover portions of the network that have data of interest. Once such portions are discovered, the entities may deploy only enough data collectors at the right locations so that they can receive real-time continuous monitoring with deep visibility into a specific set of traffic with lower cost and complexity than those other approaches discussed above.

Turning now toFIG.1, a block diagram of a system100is illustrated. System100includes a set of components that may be implemented via hardware or a combination of hardware and software routines. In the illustrated embodiment, system100includes host systems110A-C that are part of a computer network112(which may alternately be referred to as a target environment), an orchestrator120, a controller130, and a sniffer140. In some embodiments, system100may be implemented differently than shown. For example, system100may include multiple sniffers140that are deployed on different host systems110.

System100, in various embodiments, is a computer cluster that can implement a computing platform for providing services and functionality to users of system100. System100may be, for example, a cloud-based platform that provides services and resources from programs and hardware of system100to users via the Internet. System100may implement a private computing platform that is used exclusively by a single organization or a public computing platform that is accessible by various organizations. In either case, system100may store data for various users and operate on that data on behalf of those users or other entities. In order to provide such functionality, system100includes host systems110capable of implementing the appropriate software programs.

Host systems110, in various embodiments, are computer systems on a computer network112that provide services to users and other computer systems. A host system110may implement a hypervisor that allows for one or more virtual machines to be instantiated on the host system110for running various software programs. As an example, a host system110may implement, through a virtual machine, a database server that manages a database storing data for users associated with system100. In various cases, the software programs executing on a host system110may interact with other components inside system100(e.g., software programs executing on other host systems110) and outside system100(e.g., a service that is running on a cloud-based platform). In various embodiments, orchestrator120manages the deployment of software programs on a host system110.

Orchestrator120, in various embodiments, is a set of software routines that are executable to automate deployment, scaling, and management of software programs running on host systems110. Amazon Web Services™ and Kubernetes™ are examples of orchestrator120. Accordingly, in the Amazon Web Services™ context, orchestrator120may provide a mechanism for deploying instances (or workloads) onto host systems110that implement a cloud-based environment. In the Kubernetes™ context, orchestrator120may provide container-centric management environment for deploying and managing application containers, which can be portable, self-sufficient units having an application and its dependencies. As a result, orchestrator120may be used to instantiate software programs, such as sniffer140, on host systems110. In various embodiments, orchestrator120stores cluster information that describes the resources and configuration of the environment that is managed by orchestrator120. The cluster information may describe, for example, what host systems110make up computer network112, their computer resources (e.g., computer nodes and storage volumes), what software programs are running on those host systems, and the internal networks of each of those host system. Orchestrator120may use that cluster information to deploy software applications on host systems110. As explained below, orchestrator120can be used by controller130to deploy sniffers140on host systems110.

Controller130, in various embodiments, is a set of software routines that are executable to facilitate the discovery of locations on computer network112that include instances of data deemed interesting by a user of system100. Consider an example in which host systems110are operated on behalf of a financial institution that stores financial data for millions of users. Such financial data may include social security numbers, account balances, credit history, and other data that the financial institution deems of interest and wishes to ensure is properly handled. In various cases, the financial data may be stored as unstructured data across computer network112such that the locations where the data is stored are not readily apparent to the financial institution. As such, controller130may facilitate the discovery of where such financial data is stored and how it is used. To facilitate such discovery, in various embodiments, controller130performs limited-time-period deployments of sniffer program140.

Sniffer140, in various embodiments, is a set of software routines executable to sample and analyze network traffic115for instances of data deemed of interest or may be of interest to a user of system100. In order to sample network traffic, sniffer140may be deployed on a virtual machine of a host system110and connected to the network of that host system110. Thereafter, sniffer140may extract data objects from network traffic115and/or behavior features of network traffic115in order to learn characteristics pertaining to that network traffic. As mentioned, a user may provide information that is usable for identifying data that is of interest to the user. For example, the user may provide a set of SQL commands or a set of regular expressions. In some embodiments, a set of machine learning models may be trained based on data samples of data of interest. In various embodiments, sniffer140analyzes extracted data objects for instances of data that is identified as interesting by the user. For example, sniffer140may determine if the data objects are associated with the provided set of SQL commands, contain data that can be extracted from content of those data objects through the regular expressions, or contain data that is flagged by the machine learning models.

In various embodiments, sniffer140provides controller130with network information145that identifies locations (e.g., host system110) of computer network112where data of interest was observed by sniffer140. Network information145may also identify behavior features of the network within a host system110. As an example, network information145may identify who is sending and receiving data on the network (e.g., what software programs, users, etc.), what is being sent or received, and at what time the data is being sent or received. In some embodiments, network information145is used by controller130to identify locations of computer network112that may be of interest to the user that is not based on knowledge provided by the user.

To facilitate a discovery of locations on computer network112where data of interest exists, in various embodiments, controller130performs limited-time-period deployments of sniffer140onto locations within computer network112. As explained in greater detail with respect toFIG.3, controller130may obtain information from orchestrator120that describes a topology of computer network112—such information may indicate what host systems110make up computer network112. Based on the information, controller130issues deployment requests135to orchestrator120that facilitate the deployment of sniffer140. For example, deployment request135may identify a host system110(e.g., host system110B) on which to deploy sniffer140. Accordingly, orchestrator120issues a deployment instruction125to the appropriate host system110to deploy sniffer140on that host system. Deployment instruction125, in various embodiments, instructs an agent that is executing on that host system110(e.g., the agent may be the Docker™ program) to instantiate sniffer140. At a later point in time, controller130may instruct orchestrator120to remove sniffer140from a host system110and redeploy sniffer140onto another host system110. By removing and redeploying sniffer140, sniffer140may analyze the network traffic of the host systems110of computer network112in order to assist controller130in building a map that identifies locations on computer network112where data of interest is observed.

Turning now toFIG.2, a block diagram of an example host system110is illustrated. In the illustrated embodiment, host system100includes virtual machines210A-D that are part of a host network220. Also as shown, virtual machine210A implements a database server212that interacts with a database214(which might be located on a network attached storage), and virtual machine110D implements sniffer140. Host system110may be implemented differently than shown. For example, host system100may include multiple host networks220, a different number of virtual machines210, and/or different software programs.

Virtual machines210, in various embodiments, are software routines executable to provide an environment in which other software programs (e.g., sniffer140) can execute. In various cases, the software programs executing on virtual machines210may manage data on behalf of an entity associated with system100. As illustrated for example, database server212interacts with database214; such interaction may involve providing database services such as data storage, data retrieval, and data manipulation. These database services may be provided by database server212to other components (e.g., software programs running on the same virtual machine210, software programs running on other virtual machines210, and entities outside of computer network112). As part of providing such database services, database server212may transmit data objects as network traffic115to the other components.

As shown, virtual machines210are connected to host network220. Host network220, in various embodiments, is a virtual network on which virtual machines210A-D are connected to a virtual switch through which their network traffic115flows. When sniffer140is deployed on host system110, sniffer140may be connected to that virtual switch in such a way that network traffic115from virtual machines210A-C is routed through sniffer140. Consequently, sniffer140may analyze network traffic115to extract data objects and behavioral features from that network traffic115. For example, database server212may receive a request specifying an SQL command to be executed against database214. As a result, database server212may return data from database214back to the requestor. On its way back, sniffer140may extract that data from network traffic115and use a regular expression to attempt to extract a particular instance of data from that data. For example, sniffer140may attempt to extract a social security number from the data using a regular expression designed to extract social security numbers.

In cases where network traffic115is encrypted, sniffer140may analyze SSL fingerprints associated with network traffic115to identify abnormal traffic. If network traffic115is associated with SSL fingerprints that are not identified on a list provided to sniffer140, then sniffer140may identify the locations associated with such traffic to controller130. Accordingly, controller130may present the locations to a user so that the user can make an informed decision on whether to deploy data collectors (discussed in greater detail with respect toFIG.4) to those locations. In some embodiments, a data collector can be set up as a secure sockets layer (SSL) proxy that sits between the origin and the destination. As such, when network traffic115pass through the proxy, the data collector may decrypt that network traffic115in order to inspect its contents for instances of data of interest. After inspecting the network traffic115, the data collector may re-encrypt that network traffic115and transmit it to the destination.

As mentioned, sniffer140may identify behavioral features associated with network traffic115. These behavioral features may include what entities are communicating, what data is being communicated, how often that data is being communicated, etc. This information may be used to identify portions of computer network112that a user may want to deploy, for example, a security system. For example, sniffer140may notice that database server212services a high number of requests for data in database214and, as a result, there is high volume of network traffic115that originates from database server212. Sniffer140may note this behavioral feature associated with virtual machine210A and report it back to controller130. While no data of interest to a user may be observed within network traffic115of host system110, it might still be desirable to deploy, for example, a security system on host system110due to the high volume of traffic the flows between virtual machine210A and other components. That is, host system110be identified as a location of interest because it experiences a high volume of traffic, which may indicate its importance. As such, sniffer140may collect this behavioral information and provide it to controller130so that such locations may be suggested to the user as locations of interest. That is, sniffer140may not only identify instances of data of interest but also may identify locations that may be of interest to the user, even in cases when network traffic from those locations has not included data of interest.

In some embodiments, a cloud-based environment may be implemented instead of a virtual machine-based environment. In a cloud-based environment, sniffer140may not be deployed such that sniffer140“roams” computer network112. Instead, in various embodiments, network traffic mirroring features of orchestrator120may be used to route network traffic from specific instances or workloads to sniffer140. That is, sniffer140may be connected to a network port through which orchestrator120redirects network traffic so that sniffer140can sample that traffic. In some cases, sniffer140samples network traffic115of a particular instance for a specified period of time and then orchestrator120reconfigures the environment to route network traffic115of another instance of the cloud environment. In some embodiments, the user may identify a certain type of instance and orchestrator120may route network traffic115from instances of only that type. As a result, the user may selectively control what network traffic115is mirrored to sniffer140. As mentioned, in some embodiments, multiple sniffers140may be deployed that sniff network traffic115from different portions of computer network112.

Turning now toFIG.3, a block diagram of a controller130is illustrated. In the illustrated embodiment, controller130includes a deployment engine310and a map engine320. As further shown, deployment engine310includes host system information315and map engine320includes network information145. In some embodiments, controller130may be implemented differently than shown. For example, controller130may include an interface component for presenting data to users.

Deployment engine310, in various embodiments, is a set of software routines executable to facilitate the deployment of sniffer140. To facilitate the deployment of sniffer140, deployment engine310issues host request312to orchestrator120. Host request312, in various embodiments, is a request for information about the topography of computer network112. As shown, orchestrator120can provide back a host response314, which may include host system information315. Host system information315, in various embodiments, describes the topography of computer network112. Such a description may disclose how many host systems110are on computer network112, how many host networks220are on each host system110, how many virtual machines210are executing on each host system110(or host network220), and what software programs are running on each virtual machine210. For a cloud-based environment implementation, the description may disclose other or additional information such as how many instances or workloads are running and what the different types of software programs are executing in the cloud environment.

In some embodiments, deployment engine310periodically issues host request312in order to learn of any changes to computer network112. It may be desirable for deployment engine310to learn about new instantiations of virtual machines210so that it may deploy sniffer140to check network traffic115from those virtual machines210for data of interest. For example, orchestrator120may deploy a new database server212on a new virtual machine210running on a particular host system110. By periodically issuing host request312, deployment engine310may learn about the new database server212and deploy sniffer140to inspect network traffic115from that server212.

Various deployment schemes may be used by deployment engine310for deploying sniffer140onto host systems110throughout computer network112. In some embodiments, deployment engine310may implement a round robin scheme in which deployment engine310rotates through the host systems110identified by host system information315, deploying sniffer140on each host system110for a limited period of time. In some embodiments, deployment engine310presents a list of host systems110to a user and allows that user to identify which host systems110to deploy sniffer140onto and the order of deployment. The user may specify the amount of system resources and time that sniffer140can expend running on a particular host system110. In some embodiment, deployment engine310selects host systems110based on current resource usage of those systems110. For example, deployment engine310may skip a host system110if it is currently busy (e.g., it has a high CPU usage) and choose a less busy host system110. Deployment engine310might return to the former host system110when it is less busy and has systems resources to support the deployment of sniffer140. As mentioned, how long sniffer140can remain on a host system110may be specified by a user; sniffer140may also remain on a host system110until it has observed a certain amount of network traffic115.

Based on host system information315and user preferences, deployment engine310may send deployment request135to orchestrator120to deploy sniffer140on a host system110. After a specified amount of time has elapsed, deployment engine310may send deployment request135to orchestrator120to remove sniffer140from that host system110and, if appropriate, redeploy sniffer140onto another host system110. Deployment engine310may continue to deploy sniffer140after all host systems110have been visited—that is, deployment engine310may implement multiple rounds of deployments. In some embodiments, deployment engine310may deploy more than one sniffer140. For example, if computer network112is reasonably large (e.g., has thousands of host systems110) such that one sniffer140would take an unreasonable amount of time to scan the entire computer network112, then deployment engine310may deploy multiple sniffers140to more quickly cover computer network112. In some cases, where deployment is repeatable, how often it is repeatable, and how many sniffers140can be deployed may be defined a user associated with system100. In some cases, a host system110may include multiple host networks220. As a result, deployment engine310may perform multiple deployments of sniffer140to a host system110, where each deployment connects sniffer140to a different host network220of the host system110.

Map engine320, in various embodiments, is a set of software routines that are executable to generate a map indicating portions of computer network112where a user might wish to deploy a data collector or a security system, for example. To generate the map, map engine320may use network information145received from sniffer140as sniffer140is deployed to different portions of computer network112. As mentioned, network information145may indicate where (e.g., what host system110) data of interest to a user has been observed in network traffic115and may indicate behavioral features associated with the network traffic115of different host systems110. Accordingly, map engine320may generate a map based on network information145such that the map indicates locations of interest to the user.

In some embodiments, map engine320may score different portions of computer network112based on network information145. For example, if the network traffic115of a particular host system110has included instances of different types of data of interest (e.g., bank account numbers, social security numbers, driver license numbers—examples of three different types), then that host system110may be scored higher than a host system110whose network traffic115included only instances of one type of data of interest. The behavioral features may also affect the score. A host system110that experiences a high amount of network traffic115might be scored higher than a host system110that experiences a low amount of network traffic115. As another example, a host system110that runs database servers may be scored higher than a host system110that runs only application servers. In various embodiments, map engine320presents these scores to the user for different portions of computer network112so that the user may prioritize particular portions of computer network112over others for deploying more permanent sniffers, for example.

Turning now toFIG.4, a block diagram of an example set of three host systems110A-C is illustrated. In the illustrated embodiment, host systems110A and110C include identified data410and a data collector420. In some embodiments, the illustrated embodiment may be implemented differently than shown. For example, there may be more or less host systems110, one or more of which may include identified data410and a data collector420.

Identified data410, in various embodiments, is data identified by sniffer140as potentially being of interest to the user. As shown, host systems110A and110C include identified data410A and410B. As an example, host system110A's identified data410A may include social security numbers while host system110C's identified data410B may include bank account numbers. Since identified data410has been discovered on host systems110A and110C and not host system110B, then a user may wish to deploy a data collector to both host systems110A and110C.

Data collector420, in various embodiments, is a set of software routines that are executable to monitor network traffic115and enforce security policies on that traffic in some cases. In some embodiments, data collector420is the same as sniffer140except for data collector420is not time limited as sniffer140. That is, while sniffer140may roam computer network112, executing for a specified amount of time on each host system110, data collector420may be fixed to a location on computer network112where it will execute from an unspecified amount of time. Data collector420may continue to analyze network traffic115and report network information145to controller130for improving the map generated by map engine320. That is, because sniffer140monitors the network traffic115of a given location for a limited amount of time, the network information145provided by sniffer140may not provide a full picture of the network traffic that occurs at that given location. Accordingly, data controller420may continue to monitor network traffic115to provide a fuller picture of the network traffic115at a location.

Turning now toFIG.5, a flow diagram of a method500is shown. Method500is one embodiment of a method performed by a control program (e.g., a controller130) that is executing on a computer system (e.g., a system100) to locate instances of data (e.g., identified data410) on a computer network (e.g., a computer network112). Method500may be performed by executing a set of program instructions stored on a non-transitory computer-readable medium. In some cases, method500may include more or less steps than shown. For example, method500may include a step in which the control program is instantiated on the computer system.

Method500begins in step510with the control program receiving a request to locate instances of data on the computer network that includes a plurality of computer systems (e.g., host systems110) that are managed by an orchestration program (e.g., an orchestrator120). The request to locate instances of the data may include a regular expression that defines a search pattern and/or an SQL command.

In step520, the control program performs multiple, limited-time-period deployments of a sniffer program (e.g., a sniffer140) to different portions (e.g., different host systems110) of the computer network in order to sample network traffic (e.g., network traffic114) from the different portions to determine whether instances of the data appear in the network traffic. In various cases, sampling the network traffic may include extracting a set of data objects from the network traffic and applying the regular expression to content of the set of data objects to determine whether the content includes instances of the data. In some cases, sampling the network traffic may also include determining whether content of the network traffic is associated with the SQL command.

In various embodiments, the control program mat perform a particular one of the multiple, limited-time-period deployments by selecting one of the plurality of computer systems on which to deploy the sniffer program. The control program may than instruct the orchestration program (e.g., via a deployment request135) to deploy the sniffer program on the selected computer system such that the sniffer program is connected to a network (e.g., a host network220) of the selected computer system and is capable of sampling network traffic of the network. The control program may cause the sniffer program to be removed from the selected computer system before performing a subsequent deployment of the sniffer program on a different portion of the computer network. In some instances, removing the sniffer program from the selected computer system is performed in response to the control program determining that the sniffer program has executed on the selected computer system for an interval of time (e.g., one day) that satisfies a threshold specified by a user associated with the computer network.

In some embodiments, the control program causes a user interface to be presented to the user that identifies the plurality of computer systems. The control program may receive, from the user, a selection of a subset of the plurality of computer systems (e.g., the user may select a portion of their network to scan instead of all of it). Consequently, the selected computer system for the particular deployment may be selected from the subset of computer systems. The control program may also receive, from the user, user input that identifies an amount of computer resources (e.g., 10% of CPU) that the sniffer program is permitted to consume when executing on a given computer system. Consequently, the selecting may be based on the available computer resources of each of the plurality of computer systems. The control program may periodically communicate with the orchestration program (e.g., via host requests312and responses314) to identify a list of programs that are executing on the plurality of computer systems. The selecting may be based on the list of programs. Subsequent to the particular deployment, the control program may determine, based on the periodically communicating, that the list of programs identifies a program that was initiated on the selected computer system after the particular deployment. Accordingly, a second particular one of the multiple, limited-time-period deployments may involve redeploying the sniffer program on the selected computer system.

In step530, the control program receives, from the sniffer program, information (e.g., network information145) that identifies one or more of the different portions of the computer network whose network traffic included instances of the data. In various embodiments, the control program generates a map identifying particular portions of the computer network whose network traffic included instances of the data. The control program may then cause the map to be presented to the user and receive, from the user, a selection of one or more of the particular portions identified by the map. After, the control program may perform one or more deployments of a data collector program (e.g., a data collector420) to the selected one or more particular portions, which may be operable to sample network traffic and enforce a set of policies on the sampled network traffic. In some cases, the information that is received from the sniffer program identifies a set of behavioral features that describe the different portions of the computer network. The map may be generated based on the set of behavior features, where the map specifies scores for the different portions of the computer network. In some cases, a first portion of the computer network may be scored higher than a second portion of the computer network based on the set of behavioral features. The set of behavioral features may identify a specific portion of the computer network that is associated with a threshold amount of network traffic. The set of behavioral features may identify a specific portion of the computer network that is associated with accesses that originate from a threshold number of different entities.

Turning now toFIG.6, a flow diagram of a method600is shown. Method600is one embodiment of a method performed by a control program (e.g., a controller130) that is executing on a computer system (e.g., a system100) to locate instances of data (e.g., identified data410) on a computer network (e.g., a computer network112). Method600may be performed by executing a set of program instructions stored on a non-transitory computer-readable medium. In some cases, method600may include more or less steps than shown. For example, method600may include a step in which the control program is instantiated on the computer system.

Method600begins in step610with the control program receiving a request to locate instances of data on the computer network that includes a plurality of computer systems (e.g., host systems110) that are managed by an orchestration program (e.g., an orchestrator120). The request to locate instances of the data may include a regular expression that defines a search pattern.

In step620, the control program performs multiple deployments of a sniffer program (e.g., a sniffer140) to locate instances of the data on different portions of the computer network. A given deployment includes, in step622, selecting one of the plurality of computer systems on which to deploy the sniffer program and, in step624, instructing the orchestration program to deploy the sniffer program on the selected computer system such that the sniffer program is connected to a network (e.g., a host network220) of that computer system. The sniffer program may be capable of sampling network traffic (e.g., network traffic114) of the network of that computer system to determine whether instances of the data appear on the network. In some embodiments, sampling the network traffic includes extracting a set of data objects from the network traffic and applying the regular expression to content of the set of data objects to determine whether the content includes instances of the data. The given deployment also include, in step626, removing the sniffer program from the selected computer system before performing a subsequent deployment of the sniffer program to another portion of the computer network.

In step630, the control program receives, from the sniffer program, information (e.g., network information145) that identifies one or more of the plurality of computer systems whose network traffic included instances of the data. In various embodiments, the control program generates a map that identifies particular portions of the computer network whose network traffic included instances of the data and causes the map to be presented to a user that is associated with the computer network. The control program may then receive, from the user, a selection of one or more of the particular portions identified by the map. The control program may perform one or more deployments of a data collector program (e.g., a data collector420) to the selected one or more particular portions. In various embodiments, the data collector program is operable to sample network traffic and enforce a set of data control policies on sampled network traffic.

Exemplary Computer System

Turning now toFIG.7, a block diagram of an exemplary computer system700, which may implement a host system110, orchestrator120, controller130, and/or sniffer140, is depicted. Computer system700includes a processor subsystem780that is coupled to a system memory720and I/O interfaces(s)740via an interconnect760(e.g., a system bus). I/O interface(s)740is coupled to one or more I/O devices750. Computer system700may be any of various types of devices, including, but not limited to, a server system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, tablet computer, handheld computer, workstation, network computer, a consumer device such as a mobile phone, music player, or personal data assistant (PDA). Although a single computer system700is shown inFIG.7for convenience, system700may also be implemented as two or more computer systems operating together.

Processor subsystem780may include one or more processors or processing units. In various embodiments of computer system700, multiple instances of processor subsystem780may be coupled to interconnect760. In various embodiments, processor subsystem780(or each processor unit within780) may contain a cache or other form of on-board memory.

System memory720is usable store program instructions executable by processor subsystem780to cause system700perform various operations described herein. System memory720may be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system700is not limited to primary storage such as memory720. Rather, computer system700may also include other forms of storage such as cache memory in processor subsystem780and secondary storage on I/O Devices750(e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem780. In some embodiments, program instructions that when executed implement orchestrator120, controller130, and sniffer140may be included/stored within system memory720.

I/O interfaces740may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface740is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces740may be coupled to one or more I/O devices750via one or more corresponding buses or other interfaces. Examples of I/O devices750include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system700is coupled to a network via a network interface device750(e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.).

The present disclosure includes references to “embodiments,” which are non-limiting implementations of the disclosed concepts. References to “an embodiment,” “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” and the like do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including specific embodiments described in detail, as well as modifications or alternatives that fall within the spirit or scope of the disclosure. Not all embodiments will necessarily manifest any or all of the potential advantages described herein.