Automatic whitelisting using provisioning information

A security system for a distributed application obtains and, in effect, preserves provisioning information for the purpose of auto-populating whitelists used to protect the distributed application from intrusions. The provisioning information identifies allowable connections on a software-package level. Entries mapping processes to connection destinations are added to a whitelist if a process requesting a connection results from execution of an executable file installed as part of a software package for which the connection was allowed according to the provisioning information.

BACKGROUND

Enterprise applications, especially those that are Internet-facing, are vulnerable to intrusions of increasing sophistication. Security systems often protect using blacklists, that is, lists of processes and executables known or suspected to be problematic. When a process or executable file is detected that is found on the black list, it can be stopped, quarantined, removed, etc. However, new processes/executables may cause problems before they are detected, characterized, and represented on a blacklist.

While blacklists list what should be disallowed, whitelists list what should be allowed. Accordingly, when a new problematic process is introduced, whitelists do not, in general, have to be updated. However, what should be allowed depends on what is installed. Thus, while a blacklist can be applicable to a wide variety of systems, whitelists may have to be custom-generated for each system. It is therefore desirable to generate applicable whitelists automatically.

DETAILED DESCRIPTION

The present invention provides for automatically populating process-connection whitelists for a distributed (i.e., multi-machine) application using provisioning information obtained from a provisioning system, e.g., Chef™, Puppet™, or Ansible™. It turns out that information used in provisioning a distributed application: 1) can be helpful in securing the distributed application against intrusions; but 2) is not available or is not readily discoverable from the deployed application itself.

A whitelist that only lists allowed processes may be ineffective against badly behaving processes that assume the identities of allowed processes or allowed processes that have been hijacked for unintended purposes. To address such vulnerabilities, a whitelist can list allowed connections in association with allowed processes. For example, allowed connections to other machines may be listed. If an allowed process attempts a connection to a non-whitelisted destination, the connection can be blocked and an alert can be issued.

Process behaviors are context dependent. For example, it cannot be assumed that, because a first instance of process is allowed to make a connection, a second instance of the process would be allowed to make the same connection. Thus, while diverse systems can use the same blacklist, whitelists specifying allowed connections or other behavior must, in general, be generated anew for each application context. Since standardized whitelists do not seem practical, automatic population of process connection whitelists becomes sin qua non for their practicality. Herein, provisioning information is repurposed for auto-populating process behavior whitelists.

A provisioning system is typically used for installing software on physical and virtual hosts. Some provisioning systems, e.g., vRA (vRealize Automation, available from VMware, Inc.) can be used to create virtual machines to host the software, while other provisioning systems, e.g., Chef™, Puppet™, and Ansible™, require the virtual machines or other hosts to be pre-installed, e.g., using a management product such as vCenter, available from VMware, Inc.

Provisioning can encompass installing software packages on virtual machines and setting up connections that allow certain software packages to communicate with certain of the virtual machines. However, once the desired connections have been set up, the allowed package-VM connection information used to guide the installation may be discarded. Furthermore, installing a software package typically dissociates the file in the package from the package itself, which may no longer exist on the deployed distributed application. As mentioned above, however, the present invention repurposes at least some provisioning information toward auto-populating whitelists.

More specifically, the provisioning information can be used to identify: 1) an application boundary (e.g., a sales booking application); 2) the services within an application (e.g., the sales booking application includes a web service, an app service, and a database service); 3) which virtual machines are to participate in which service; and 4) the software packages that are installed on the end services and, thus, the respective virtual machines; and 5) which connections the packages will be making and/or monitoring.

From the fact that a package is allowed to connect to a destination (e.g., a virtual machine), it may be deduced that at least one executable file in the package, when executed, implements a process that is allowed to connect to that destination. Therefore, if a process requesting a connection to a destination was a part of a package that was allowed to connect to that destination, it is relatively likely that the request should be granted. On the other hand, if a process requesting a connection to a destination was not part of any package that was allowed to connect to that destination, then it is relatively unlikely that that connection should be allowed.

Accordingly, the present invention thus preserves the allowed package-VM connection information normally available to the provisioning system and normally not available in the deployed distributed application so that it can be used as a basis for automatically populating whitelists that map processes (rather than packages) to connection destinations. Thus, each virtual machine can include a respective whitelist and a security agent that monitors connection requests. In a learning mode, the agent can auto-populate the respective whitelist with entries mapping processes (that request connections to respective destinations) to the requested destinations provided the source package (that included an executable that when executed resulted in the requesting process) was allowed to connect to that destination.

As shown inFIG. 1, a computer system100includes a three-tier distributed application102, a provisioning system104that is used to provision application102, and a security central106, used to protect application102from problematic processes. Application102includes a web-server tier108, an app tier110, and a database tier112. Such three-tier applications are commonplace; other embodiments provide for non-tiered applications and applications with different numbers of tiers.

Tiers108,110, and112, include respective sets of virtual machines114,116, and118. These virtual machines are supported by hypervisors120, which, in turn, run on hardware122. Hardware122includes processors124, communications devices126(including input-output devices and network devices), and non-transitory media128(including main memory and mass storage). Media128is encoded with code defining the functionality of hypervisors120, application102, provisioning system104, and security central106. In some embodiments, application components run directly on host hardware, while other embodiments provide for a variety of virtualization arrangements.

Each virtual machine of distributed application102hosts one or more software programs via a respective guest operating system (OS). Virtual machines114of web-server tier108host instances of a web-server program130via guest operating systems132. Virtual machines116of app tier110host app programs134via guest operating systems136. Virtual machines118of database tier112host instances of a database app138via guest operating systems140.

Provisioning system104provides for provisioning applications such as distributed application102. Examples of provisioning systems include provisioning software such as Chef™, Puppet™, Ansible™, and vRealize Automation™. To this end, provisioning system104includes a catalog of blueprints142that serve as templates for a variety of common application scenarios. Other embodiments have other sources of information required for provisioning an application.

Regardless of the form it takes, the provisioning information150can be used to identify: 1) an application boundary151(e.g., a sales booking application); 2) the services153within an application (e.g., the sales booking application includes a web service, an app service, and a database service); 3) mappings155of application services to their hosts (e.g., virtual machines); 4) mappings157of the software packages to the services they support; and 5) mappings159of software packages to allowed connections.

Security central106imports and analyzes the provisioning system. In some embodiments, the information can be imported via Restful State Application Programming Interfaces (REST APIs). In other embodiments, a collection agent, e.g., a plug-in, can be installed in the provisioning system to collect the provisioning information and transmit it to security central106. The imported provisioning information can be supplemented using information160from other, e.g., third-party sources. For example, software-package vendors may provide listings of files included in respective software packages. Security central162includes an analysis engine162that can analyze the provisioning information and supplemental information to assembly process information164, e.g., a knowledgebase regarding processes to be run in the context of distributed application102. Analysis engine160is also used to analyze alerts issued when a connection requested by a process is disallowed, e.g., because the requested connection is not represented in a whitelist.

Ultimately, deployment engine144provides a deployment plan150to be implemented to effect the desired deployment or modification. Deployment plan148includes the specifications for the application including characterizations of the virtual machines, software packages to be installed on the virtual machines, and the virtual-machines to which each software package is allowed to connect (e.g., for configuring firewalls). For each software package, the information shown in the software package descriptions table200ofFIG. 2is specified: a name or other identifier202for the package, the virtual machine204to host the package, the files206in the package (including executable files that, when executed, yield processes), and the allowed connections208for the package. The correspondences between files and connections are not typically specified.

Security central106includes an analysis engine150for analyzing alerts and other information. To this end, security central106maintains a knowledge base152of information about processes including those expected to be running in application102. The knowledgebase is initially populated with third-party information154which includes information from software vendors regarding the contents of the software packages installed in deploying and modifying application102. For example, process knowledgebase can include a software-package description table200, shown inFIG. 2, that maps each package identity202to the its host204, to the files206it contains, and to the connections208it is allowed to make. In addition, the knowledgebase152can include information resulting from analyses of alerts.

Security central106is, in effect, the organizing entity for a security system190that includes a collection agent, if such an agent (plug-in) is installed in provisioning system104. In addition, security system includes guest agents installed in respective hosts, e.g., virtual machines, of distributed application102. More specifically, security system190includes guest agents, e.g., agents168,170, and172respectively installed in virtual machines114,116, and118of application tiers108,110, and112. Guest agents monitor app processes, detect when they request connections (e.g., to other virtual machines), decide whether to allow the connections based at least in part on co-resident whitelists178,180, and182. As shown inFIG. 3, an allowable-connection whitelist168maps process identifiers302to one or more connection destinations304and a verification type or source306. Other whitelists of distributed application102100(FIG. 1) provide corresponding information.

In the event a whitelist fails to indicate a given process is allowed to make the connection it is requesting, the guest agent issues an alert to a respective host agent188running on the hypervisor that also supports the virtual machine from which the alert is used. Host agents188collect and bundle alerts from its resident virtual machines. This reduces network traffic, especially in scenarios where many alert are issued concurrently, e.g., during a denial of service attack.

A security process400, implementable in computer system100and other systems, is flow charted inFIG. 4. Security process400includes three modes, provisioning410, learning420, and protect430. Although these modes area shown in a particular order for expository purposes, it should be noted that provisioning can occur at any time, e.g., to modify a previously provisioned application. Provisioning can occur during learning mode and/or protect mode. Furthermore, learning mode can be activated at any time, as can protect mode. In some embodiments, learning and protection are combined into a single mode, so that learning and protection do not corresponds to distinct modes of operation.

In provisioning mode410, at411, a distributed application is provisioned so as to create or modify the application. The provisioning can include installing software packages on physical or virtual machines. In the case of virtual-machine hosts, these may be created by the provisioning system (e.g., in the case of vRealize Automation™, or may be created prior to provisioning (as typical for Chef™, Puppet™, and Ansible™.

At412, security central ingests provisioning information. As listed above, the provisioning information can identify an application boundary, application services, hosts for application services, software packages for implementing application services, and allows package connections. At413, security central uses the provisioning information (along with3′ party information) to deduce which connections can be allowed for which processes. Basically, a process is allowed to connect to a destination if the package that contained the executable for the process is allowed to make the connection. In some embodiments, all such allowed connections are whitelisted. However, this would result in a whitelist with many entries that would never be requested. Accordingly, whitelist entries are entered automatically in response to actual connection requests.

During learning mode420, processes and their connect requests are monitored, as indicated at421. The connection may be for the purpose of transmitting messages or for listening for messages or both. At422, whitelist entries are made in response to connection requests. As shown inFIG. 3, entries map process identifiers302to connection destinations304and to verification sources and types306. In an event in which a requesting process was part of a package allowed to make the requested connection, then “provisioning information” can be indicated as the verification source. Other entries may be indicated as “well-known” or “administrator-identified”. If there is no verification source, then a “verification needed” can be listed as the verification type. In other words, during learning mode, all connection requests are “learnt”, but some require additional verification (or repudiation).

Not all allowed connection destinations result from requests for those destinations. An administrator can simply add entries manually. “Range augmentation” involves including non-requested destinations in a whitelist that are in ranges that include other destinations that were requested. “Sibling augmentation” involves adding entries to a local whitelist that are copies of entries made to another whitelist, e.g., where two hosts are provisioned with separate instances of the same software package. Application boundary information is used to preclude copying entries from separate instances of the same software package providing services for different distributed applications.

In the illustrated embodiment, learning also occurs in protect mode430, which represents normal (vulnerable) operation. The functional difference between protect mode430and learning mode420is that connection requests that cannot be verified are disallowed and trigger alerts. Guest agents monitor processes and their connection requests at431. At432, connection requests that can be verified as allowable are allowed; if they are not already represented in the respective whitelist, they can be added. For disallowed connection requests, alerts are sent to security central via host agent. At433, security central may take some automated remedial action and/or inform an administrator of the disallowance so that the administrator can initiate some action. One possible outcome of an alert is that the whitelist is updated so that the connection can be allowed in the future.

Herein, all art labelled “prior art”, if any, is admitted prior art; all art not labelled “prior art”, if any, is not admitted prior art. The illustrated embodiments, variations thereupon, and modifications thereto are provided for by the present invention, the scope of which is defined by the following claims.