Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0894—Policy-based network configuration management
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2101—Auditing as a secondary aspect
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2113—Multi-level security, e.g. mandatory access control
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2115—Third party
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0803—Configuration setting
  • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings

Definitions

• the policy implementation module 136 is part of a larger proprietary module (not shown).
• the proprietary module is loaded onto a device that already has a management module 132 and a management module configuration 134, thereby transforming the device from an unmanaged device 140 to a managed server 130.
• the policy implementation module 136 is further described below with reference to FIGS. 4, 6, and 7.
• the global manager 120 is a computer (or set of computers) that generates management instructions for managed servers 130 and sends the generated management instructions to the servers.
• the management instructions are generated based on a) the state of the administrative domain's computer network infrastructure 320 and b) an administrative domain-wide management policy 330.
• the state of the administrative domain's computer network infrastructure 320 includes descriptions of managed servers 130 and (optionally) descriptions of unmanaged devices 140.
• the global manager 120 also processes local state information received from managed servers 130.
• V US or EU (physical), us-west-1 or us-east-2
• segmentation can be used with access control policies to define groups of managed servers 130 that are subject to particular policies.
• segmentation can be used with secure connectivity policies to define groups of managed servers 130 and the policies that apply to intra-group communications and inter-group communications.
• Each managed server 130 in the environment 100 implements the administrative domain- wide management policy 330 (to the extent that the policy concerns the managed server 130).
• the administrative domain- wide management policy 330 is applied in a distributed fashion throughout the administrative domain 150, and there are no choke points.
• the administrative domain-wide management policy 330 is applied at the logical level independent of the administrative domain's physical network topology and network addressing schemes.
• the network exposure information concerns the managed server's network interfaces.
• the network exposure information includes, for each of the managed server's network interfaces, an identifier of a "bidirectionally-reachable network" (BRN) to which the network interface is attached and zero or more IP addresses (and their subnets) that are used for operating within the BRN.
• BRN is a set of subnets, within an organization or across organizations, where any node within the BRN can establish communication with any other node in the BRN. For example, all of the nodes in a BRN have unique IP addresses. In other words, a BRN does not contain any NATs.
• Network exposure information e.g., a network interface's BRN identifier
• the network exposure information includes routing information and/or whether the managed server is behind a network address translator (NAT) (and, if it is behind a NAT, what type of NAT - 1 : 1 or 1 :N).
• the global manager 120 can determine whether a managed server 130 is behind a network address translator (NAT) (and, if it is behind a NAT, what type of NAT - 1 : 1 or 1 :N). For example, the global manager 120 determines whether a NAT exists between the global manager 120 and the managed server 130 by comparing (a) the server's IP address according to the TCP connection between the global manager and the server and (b) the server's IP address according to the local state information received from the server.
• NAT network address translator
• a NAT exists between the global manager 120 and the managed server 130. If a NAT does exist, then the global manager 120 determines the type of NAT (1 : 1 or 1 :N) by performing data center detection. For example, the global manager 120 identifies the server's data center by the data center's public IP address. (Alternatively, the managed server performs data center detection by querying information that is external to the server but inside the data center. The server then sends that information to the global manager as part of the local status.) Configuration information indicates which types of NATs are used by which data centers. If no NAT information is associated with a particular data center, then the global manager 120 assumes that the NAT type is 1 :N.
• label/configured characteristic engine (not shown) that calculates labels and/or configured characteristic (“CC”) values.
• the label/CC engine calculates labels/CC values based on label/CC assignment rules.
• a label/CC assignment rule is a function that accesses data from the administrative domain state 320 and assigns (or suggests assignment of) a label or a CC value.
• a label/CC assignment rule can be preset or user-configurable. For example, the global manager 120 includes a set of predefined rules, but the end-user can modify and/or delete those rules and add new rules based on the user's own custom requirements.
• Label/CC assignment rules can be evaluated for a managed server 130 during the initialization process. Label/CC value suggestions can then be made for any
• the end-user can accept or reject those suggestions.
• a managed server 130 is executing the Postgres database or the MySQL database, then the suggested label could be ⁇ Role, Database>. If a managed server is executing the Linux operating system, then the suggested value for the operating system CC could be "Linux.”
• Rule Function The relationship is subjected to a "rule function", which is the practical effect of the rule.
• the rule function could be access control, secure connectivity, disk encryption, or control of executable processes.
• a rule with an access control function specifies whether a consumer may use a provider's service. In one embodiment, the access control function uses a pure "whitelist" model, which means that only the allowable relationships are expressed, and all other relationships are blocked by default.
• a rule with a secure connectivity function specifies over what secure channels (e.g., encrypted network sessions using point-to-point data encryption) a consumer may use a provider's service.
• a rule with a secure connectivity function could specify that usage of a provider's services must be encrypted when the provider is located in the US and the consumer is located in the EU.
• a rule with a disk encryption function specifies whether a provider must store its data on an encrypted file system.
• a rule with an executable process-control function specifies whether a process is allowed to execute.
• a rule function can be associated with one or more settings (referred to herein as a "function profile") that specify details regarding the practical effect of the rule.
• settings associated with a secure connectivity rule function can be a list of cryptographic algorithms used to encrypt network traffic.
• a rule function is associated with multiple function profiles, and a function profile includes a priority. This priority is used by the function-level instruction generation module 360, as described below.
• Service - is an arbitrary process executing on a specific network port using a specific network protocol.
• a service of a rule within the management policy 330 is specified by a port/protocol pair and (optionally) additional qualifications, such as process information and/or package information (described above with respect to a description of a managed server 130 within the administrative domain state 320). If a managed server 130 has multiple network interfaces, then a service can be exposed on all networks or on only a subset of those networks. The end-user specifies on which networks the service is exposed. Note that, depending on the rule function, a service might not use any network resources. For example, a service for an executable process-control rule function does not execute on a network port using a network protocol.
• Providers/Consumers The one or more providers of the service and the one or more consumers (i.e., users) of the service are managed servers 130 and/or unmanaged devices 140.
• the provided-by (PB) portion describes which managed servers 130 and/or unmanaged devices 140 can provide the service (i.e., who the "providers" are). If the PB portion indicates "Anybody”, then anybody (e.g., any managed server 130 or unmanaged device 140) can provide the service. If the PB portion indicates "Any managed server”, then any managed server 130 can provide the service. ("Any managed server” is equivalent to specifying a label set that contains a wildcard, thereby matching all managed servers 130.)
• the used-by (UB) portion describes which managed servers 130 and/or unmanaged devices 140 can use the service (i.e., who the "consumers" are). Similar to the PB portion, the UB portion can also indicate "Anybody” or "Any managed server.”
• a managed server 130 is specified by using a label set (i.e., one or more labels that describe the managed server) or a UID.
• label set i.e., one or more labels that describe the managed server
• UID i.e., one or more labels that describe the managed server
• An unmanaged device 140 is specified by using a UID of an unmanaged device group (UDG). If a rule specifies an UDG, then the rule includes additional information regarding the unmanaged devices 140 in that group (e.g., the devices' network exposure information).
• the PB portion of a rule and/or the UB portion of a rule can include multiple items, including label sets (to specify managed servers 130), managed server UIDs, and/or UDG UIDs.
• the rule condition portion specifies whether the rule applies to a particular managed server 130 and/or a particular network interface of that managed server.
• the rule condition portion is a Boolean expression that includes one or more configured characteristics ("CCs"; part of a managed server's description in the
• a CC portion of the expression specifies whether the rule applies to the particular managed server, while a network exposure information portion of the expression specifies whether the rule applies to a particular network interface of that managed server. If the expression evaluates to "true" for a particular managed server's configured characteristics (specifically, for the values of that managed server's configured characteristics) and a particular network interface's information, then the rule applies to that managed server and that managed server's relevant network interface. If the expression evaluates to "false", then the rule does not apply to that managed server and that managed server's relevant network interface. For example, if a configured characteristic stores an indication of which operating system is running on the managed server, then a rule condition portion that includes that configured characteristic can control whether the rule applies to a particular managed server based on that server's operating system.
• Different scopes can be applied to a single rule list.
• an end-user can build a set of rules that express how the web service tier (managed servers 130 with a ⁇ Role, Web> label) consumes services from the database tier (managed servers with a ⁇ Role, Database> label), how the load-balancing tier consumes services from the web service tier, and so on. Then, if the end-user wants to apply this rule list to his production environment (managed servers 130 with an ⁇ Environment, Production> label) and to his staging environment (managed servers with an ⁇ Environment, Staging> label), he does not need to copy or duplicate the rule list.
• the administrative domain- wide management policy 330 includes two instances of this application: one in a production environment and one in a staging environment.
• the web servers and the database servers are managed servers 130, and their descriptions (e.g., label sets) are present in the administrative domain state 320.
• their label sets are:
• Rule List #1/Rule #2 allows a web server to connect to PostgreSQL on a database server. Specifically, the allowance of a connection is specified by "Access Control” in the Function portion.
• the "web server” is specified by “ ⁇ Role, Web>” in the UB portion.
• the "PostgreSQL” is specified by “PostgreSQL” in the Service portion.
• the "database server” is specified by " ⁇ Role, Database>” (a label set that includes only one label) in the PB portion.
• Rule List #1 also prevents inter-environment connections.
• a web server is allowed to connect to PostgreSQL on a database server if the web server and database server are both in the same environment (e.g., both in the production environment or both in the staging environment).
• Both servers in the production environment is specified by " ⁇ Environment, Production>” (a label set that includes only one label) in the Scope portion
• both servers in the staging environment is specified by " ⁇ Environment, Staging>” (a label set that includes only one label) in the Scope portion.
• a web server is not allowed to connect to PostgreSQL on a database server if the servers are in different environments (e.g., if the web server is in the staging environment and the database server is in the production environment).
• Rule List #2 states that whenever any managed server connects to a database server, that connection must be performed through an encrypted channel.
• the "database server” is specified by “ ⁇ Role, Database>” in the PB portion.
• the "encrypted channel” is specified by “Secure Connectivity” in the Function portion.
• the "any managed server” is specified by “Any managed server” in the UB portion.
• the “whenever” is specified by “All" in the Service portion.
• Server 1 is a web server that is part of production, part of appl, and owned by engineering in California. It would be labeled as:
• Server 2 is a database server that is part of production, also part of appl, and also owned by engineering but in Germany. It would be labeled as:
• the processing server 310 generates management instructions for managed servers 130 and sends the generated management instructions to the servers.
• the processing server 310 also processes local state information received from managed servers 130.
• the processing server 310 includes various modules such as a policy engine module 340, a relevant rules module 350, a function-level instruction generation module 360, an actor enumeration module 370, a relevant actors module 380, an administrative domain state update module 385, and a global security module 390.
• the processing server 310 includes a computer (or set of computers) that communicates with the repository 300 and processes data (e.g., by executing the policy engine module 340, the relevant rules module 350, the function-level instruction generation module 360, the actor enumeration module 370, the relevant actors module 380, the administrative domain state update module 385, and the global security module 390).
• data e.g., by executing the policy engine module 340, the relevant rules module 350, the function-level instruction generation module 360, the actor enumeration module 370, the relevant actors module 380, the administrative domain state update module 385, and the global security module 390).
• the relevant rules module 350 takes as input the administrative domain- wide management policy 330 and an indication of a particular managed server 130 (e.g., that server's UID), generates a set of rules that are relevant to that server, and outputs the set of rules. This is a filtering process by which the relevant rules module 350 examines the management policy 330 and extracts only the relevant rules for the given managed server 130. The relevant rules module 350 performs the filtering by iterating through all of the rule lists in the management policy 330, analyzing the scopes of each rule list to determine whether the scopes apply to this managed server 130 and (if the scopes do apply to this managed server 130) analyzing the rules of each rule list to determine whether those rules apply to this managed server 130.
• a rule applies to a managed server 130 if a) the PB portion of the rule and/or the UB portion of the rule specifies the managed server and b) the condition portion of the rule (if present) evaluates to "true" for that managed server (specifically, for the values of that managed server's configured characteristics and network exposure information).
• the end result (referred to herein as a "management policy perspective") is a collection of two sets of rules: rules where this managed server 130 provides a service and rules where this managed server 130 consumes a service.
• the function-level instruction generation module 360 takes as input a set of rules (e.g., a management policy perspective generated by the relevant rules module 350), generates function-level instructions, and outputs the function-level instructions.
• the function-level instructions are later sent to a managed server 130 as part of the management instructions.
• a function-level instruction is similar to a rule in that each one includes a rule function portion, a service portion, a PB portion, and a UB portion.
• a rule can include multiple items within its PB portion and/or UB portion (including label sets, managed server UIDs, and/or UDG UIDs)
• a function-level instruction includes only one item within its PB portion and only one item within its UB portion.
• a rule can specify a managed server (including its multiple network interfaces) within its PB portion and/or UB portion
• a function-level instruction includes only one network interface within its PB portion and UB portion.
• the function-level instruction generation module 360 analyzes a rule and generates one or more function-level instructions based on that rule. If the rule's PB portion includes multiple items, the rule's UB portion incudes multiple items, or a managed server referenced by the rule (in the PB portion or UB portion) has multiple network interfaces, then the function-level instruction generation module 360 generates multiple function-level instructions (e.g., one function-level instruction for each possible combination of a PB item, a UB item, and a particular network interface).
• the function-level instruction generation module 360 analyzes the rules, the functions within those rules, and the function profiles referenced by those rules. If a rule list includes multiple scopes, then the function-level instruction generation module 360 applies those scopes multiple times to the rule list iteratively (thereby generating a complete set of function-level instructions for each scope). Recall that a rule function can be associated with multiple function profiles, and a function profile can include a priority. The function-level instruction generation module 360 orders the rules based on the priorities of the various function profiles such that the function profile with the highest priority is used. The function- level instruction generation module 360 translates the ordered rules into function-level instructions for the managed server 130 to execute. Function-level instructions reference the appropriate managed servers 130 and/or unmanaged devices 140 (e.g., the managed servers 130 and/or unmanaged devices 140 that were referenced in the input rules), taking into account the network exposure details of the services associated with the rules.
• Function-level instructions reference the appropriate managed servers 130 and/or unmanaged devices 140 (e.g., the managed servers 130
• the function-level instruction generation module 360 can generate a function-level instruction for a particular managed server 130 that turns out to be irrelevant for that server. For example, that managed server is covered by the provided-by (PB) portion of a rule, so the function-level instruction generation module 360 generates a corresponding function-level instruction.
• the rule also includes a portion that specifies the managed server's local state (e.g., a service portion that describes the provided service). Since the global manager 120 does not know the managed server's local state (e.g., whether the managed server is actually providing that service), the generated function-level instruction is sent to the managed server. The managed server checks its local state (e.g., whether it is providing that service) and processes the function-level instruction accordingly, as explained below with reference to the policy compilation module 410.
• PB provided-by
• the actor enumeration module 370 takes as input a collection of descriptions of managed servers 130 and unmanaged device groups (UDGs) (e.g., the state of the administrative domain's computer network infrastructure 320), generates representations of those descriptions of servers and UDGs in an enumerated form (referred to as "actor-sets"), and outputs the actor-sets.
• UDGs unmanaged device groups
• the actor enumeration module 370 enumerates the managed servers 130 and the UDGs within the administrative domain state 320 and the possible label sets and assigns each a unique identifier (UID).
• UID unique identifier
• the actor enumeration module 370 enumerates all label sets that are possible based on the logical management model, which are equal to the Cartesian product given by Si x S 2 x ... x SN- The size of this set is Mi x M 2 x ... x MN.
• the enumeration process collapses the multi-dimensional label space of the managed servers 130 into a simple enumerated form.
• the actor enumeration module 370 enumerates only those label sets that are possible based on the administrative domain state 320 (e.g., based on descriptions of managed servers within the administrative domain 150). For example, consider a logical management model that includes 2 dimensions (X and Y), and each dimension includes 3 possible values (A, B, and *).
• the actor enumeration module 370 enumerates only those label sets that are used in the administrative domain-wide management policy 330 (e.g., in UB portions and PB portions of rules and scopes).
• An actor-set includes a UID and zero or more actor-set records.
• An actor-set record includes a UID (either a managed server UID or an UDG UID), an identifier of the actor's operating system, and the IP address of the actor (managed server 130 or unmanaged device 140) given the specific BRN.
• an actor-set might include actor-set records whose IP addresses correspond to all of the managed servers 130 covered by the label set of ⁇ Role, Database> and ⁇ Environment, Productions
• an actor-set might include actor-set records whose IP addresses correspond to all of the unmanaged devices 140 in the Headquarters UDG.
• a single actor e.g., managed server 130 or unmanaged device 140
• the actor enumeration module 370 can also update actor- sets based on changes to the administrative domain state 320. For example, the actor enumeration module 370 takes as input actor-sets (previously output by the actor enumeration module) and a change to a managed server's description (within the administrative domain state 320), generates updated actor-sets (which are consistent with the changed server description), and outputs the updated actor-sets. The actor enumeration module 370 generates the updated actor-sets in different ways depending on the type of change to the managed server's description.
• management policy perspective The policy engine module 340 compares the management policy perspective that was just output to the cached management policy perspective to determine whether they differ. If the just-output management policy perspective and the cached management policy perspective are identical, then the policy engine module 340 takes no further action. In this situation, the previously-generated managed server's management instructions (specifically, the function-level instructions and relevant actor-sets) are consistent with the change to the administrative domain state 320 and do not need to be regenerated and re-sent to the managed server.
• step 510 the administrative domain state 320 and the administrative domain- wide management policy 330 are accessed.
• the policy engine module 340 sends a request to the repository 300 and receives the administrative domain state 320 and the administrative domain-wide management policy 330 in response.
• management instructions are received from the global manager 120.
• the policy compilation module 410 receives function-level instructions and relevant actor-sets from the global manager 120.
• step 750 the management module configuration 134 is re-generated (because the contents of the local state repository 400 have changed), and the management module 132 is re-configured accordingly.
• the LSU module 420 executes the policy compilation module 410, which re-generates the management module configuration 134.
• step 810 a change regarding a particular managed server 130 is received.
• the administrative domain state update (ADSU) module 385 receives an
• the received information is stored.
• the ADSU module 385 stores the received online/offline indicator, network exposure information, and/or service information in the administrative domain state 320 (specifically, in the description of the managed server 130 to which the information pertains).
• the ADSU module 385 determines whether to update the administrative domain's actor-sets based on a change to the managed server's description. If a determination is made to update the administrative domain's actor-sets, then the method proceeds to step 850. If a determination is made not to update the administrative domain's actor-sets, then the method proceeds to step 860.
• step 860 a determination is made regarding whether to update the managed server's management instructions. For example, the ADSU module 385 determines whether to update the managed server's management instructions based on a change to the managed server's description. If a determination is made to update the managed server's management instructions, then the method proceeds to step 870. If a determination is made not to update the managed server's management instructions, then the method proceeds to step 880.
• the policy implementation module 136 of a managed server 130 includes a local security module 430.
• the local security module 430 collects security-related information ("security metadata") from the managed server 130 and sends the collected information to the global manager 120.
• Local security modules 430 enable managed servers 130 to act as distributed detection nodes or probes in the administrative domain 150.
• the local security module 430 collects and sends any or all of the following security-related information:
• the access control rule states that a connection is allowed if the provider is a database server and the consumer is a web server, then a database server attempting to act as a consumer with a web server acting as a provider would be a rogue action.
• the local security module 430 accesses instructions that describe the
• process information includes, for example, names of processes that the managed server 130 is running, which network ports and network interfaces those processes are listening on, which users initiated those processes, configurations of those processes, command-line launch arguments of those processes, and dependencies of those processes.
• a rogue action can concern any type of process information. For example, listening on the "wrong" network port or network interface (e.g., a network port or network interface that is not specified by the management policy as being allowed) can be a rogue action. As another example, executing under the context of the "wrong" user or users (e.g., a user that is not specified by the management policy as being allowed) can be a rogue action. As yet another example, loading unusual or unauthorized shared objects can be a rogue action.
• FIG. 9 is a flowchart illustrating a method 900 of detecting and reporting a rogue process, according to one embodiment.
• Other embodiments can perform the steps in different orders and can include different and/or additional steps.
• some or all of the steps can be performed by entities other than those shown in FIG. 1.
• step 910 a request to perform an action is received from a process executing on the managed server 130.
• the local security module 430 receives the request.
• step 920 a determination is made that the action is improper according to the configured management module 132 within the managed server 130.
• the local security module 430 sends the request to the management module 132, which then analyzes the request to determine whether the request complies with the administrative domain-wide management policy 330.
• the local security module 430 receives a response from the management module 132 indicating that the request does not comply with the administrative domain- wide management policy 330. Based on the received response, the local security module 430 determines that the action is improper.
• the local security module 430 obtains logs from the managed server 130 and sends the logs to the global manager 120.
• the logs include, for example, firewall logs (e.g., web-based L7 rule and signature-based attacks reported by a web application firewall (WAF) engine), intrusion detection system (IDS) logs (e.g., traditional L7 signature- based intrusion detection events from an IDS engine), and authentication logs (e.g., secure shell (SSH) authentication logs).
• WAF web application firewall
• IDS intrusion detection system
• authentication logs e.g., secure shell (SSH) authentication logs.
• these logs are normalized into a standard format so that they are easier to analyze. The normalization can be performed at the managed server 130 and/or at the global manager 120.
• the local security module 430 also performs its own security functions. For example, the local security module 430 detects when a process on the managed server 130 creates a new outbound connection. The local security module 430 accesses a list of known bad actors (unmanaged devices 140 and/or managed servers 130) and determines whether the destination device of the outbound connection is on the list. If the destination device is on the list, then the local security module 430 blocks the outbound connection in order to prevent extrusions. In another embodiment, the local security module 430 uses local attack thresholds and heuristics to apply blocking policy locally.
• the global security module 390 also analyzes information stored in the global security data repository 335 and modifies the administrative domain state 320 and/or the administrative domain-wide management policy 330 based on the results of the analysis, as appropriate.
• the analysis of information stored in the global security data repository 335 detects attacks and/or vulnerabilities.
• the global security module 390 can detect an attack or a vulnerability on a single managed server 130 as well as across the administrative domain 150 as a whole.
• the modification of the administrative domain state 320 and/or the management policy 330 performs global enforcement.
• the administrative domain state 320 includes descriptions of managed servers 130 and (optionally) descriptions of unmanaged devices 140.
• the administrative domain state 320 stores information regarding policy violations of managed servers 130.
• the global security module 390 analyzes, for a particular managed server 130, the rogue process/action information stored in the global security data repository 335. The global security module 390 then sets a policy violation-specific configured characteristic of that managed server to a particular value, such as a number of violations performed or attempted (1, 2, 3, etc.).
• the administrative domain state 320 stores information regarding tampering with managed servers 130.
• the global security module 390 analyzes, for a particular managed server 130, the operating system-level tampering information stored in the global security data repository 335. The global security module 390 then sets a tampering-specific configured characteristic of that managed server to a particular value, such as a Boolean value that indicates the presence/absence of tampering.
• the administrative domain state 320 stores information regarding one or more Unmanaged Device Groups (UDG).
• UDG Unmanaged Device Groups
• Members of a first UDG are known attackers or bad actors (e.g., unmanaged devices 140 that pose security threats).
• the global security module 390 maintains this bad-actor UDG by adding or removing
• the global security module 390 uses the log information, detected intrusion information, and/or bad actor information stored in the global security data repository 335 to identify a "bad" unmanaged device 140. If the global security module 390 identifies a particular attacker or bad actor, then the global security module adds that actor to the bad-actor UDG.
• the bad-actor UDG is used to identify unmanaged devices 140 whose network connections (to or from a managed server 130) should be blocked, as described below.
• the bad-actor UDG is used in the administrative domain-wide management policy 330 (e.g., within the provided-by or used-by portion of a rule).
• the global security module 390 maintains the risky UDGs by adding or removing unmanaged devices 140 as necessary. For example, the global security module 390 uses the log information, detected intrusion information, and/or bad actor information stored in the global security data repository 335 to identify a risky unmanaged device 140 and that device's risk score.
• a risky UDG is used to tweak, tune, refine, or improve the operation of the local security module 430, as described below.
• a risky UDG is used in the administrative domain-wide management policy 330 (e.g., within the provided-by or used-by portion of a rule).
• the administrative domain state update module 385 receives changes to the administrative domain state 320 and processes the changes accordingly, as explained above. This enables the detection of an attack on one managed server 130 to be distributed as a dynamic enforcement policy to other managed servers so that they are protected. In other words, a feedback loop exists where the managed servers 130 send security-related information to the global manager 120, and the global manager 120 generates management instructions based on the security-related information and sends the instructions to the managed servers 130.
• updated relevant actor-sets (e.g., actor-sets associated with changed UDGs or changed managed servers) might be sent to various managed servers 130.
• receipt of the updated relevant actor-sets causes those managed servers to reconfigure their management modules 132.
• the reconfigured management modules 132 might cease allowing communications to and/or from unmanaged devices 140 that are members of the first UDG (thereby blocking all of these communications).
• receipt of the updated relevant actor-sets causes the local security modules 430 in those managed servers to operate differently.
• the local security modules 430 might modify or tune their analyses such that data is analyzed differently based on the risk score of an unmanaged device 140.
• the threshold for reporting security information regarding a particular unmanaged device 140 might be lower if the device's risk score is high.
• the local security modules 430 might block different outbound connections based on an updated bad-actor UDG.
• the global security module 390 can detect attack patterns across the administrative domain 150 that no single probe in any one part of the domain could see in isolation. When a domain-wide attack is detected by the global security module 390, the global security module can follow the same mechanism as described above (namely, modifying the administrative domain state 320) to distribute dynamic enforcement policy to other managed servers 130 so that they are protected. [00173] Since the global security module 390 has access to both application-based anomalies and network-based anomalies, its analysis of information stored in the global security data repository 335 is more accurate.
• the global security module 390 can also act more quickly and does not need to wait for longer periods of time before taking enforcement action (e.g., modifying the administrative domain state 320). Also, the global security module 390 can identify an attack that is unique to a particular administrative domain 150. That attack could be targeting only that domain, and the attack would be "in the noise" on other internet-scale security systems. Also, because of the placement of the managed servers 130 (specifically, their policy implementation modules 136) in the administrative domain 150, the global security module 390 is also capable of catching internal threats from within the domain from insiders or, alternately, botnets that have made it through the domain's perimeter defenses and are now trying to move sideways within the domain.
• the global security module 390 also performs one or more of the following functions:
• the global security module 390 analyzes information stored in the global security data repository 335 to determine the top "N" items in different categories.
• the categories can be, for example, the top individual nodes that are communicating, the top pairs of nodes that are communicating, the top IP addresses blocked by managed servers 130, and the top IP addresses allowed by managed servers with high risk scores.
• the statistics can be calculated on multiple levels, such as per managed server, per datacenter, per business unit, and per administrative domain 150.
• the global security module 390 identifies bad actors using configured thresholds of activities.
• the global security module 390 is extensible and/or security analytics functions can be implemented to provide both global alerting and dynamic enforcement based on different threats and attack types.
• the environment 100 (especially the global manager 120 and the managed servers 130) enables a managed server to be put into "quarantine mode." Quarantine mode isolates a particular managed server 130 from other managed servers. For example, an infected or badly-behaving managed server 130 is quarantined from the rest of the "healthy" managed servers.
• a managed server 130 When a managed server 130 is in quarantine, other managed servers (specifically, their management modules 132) block inbound network traffic that originated from the quarantined server.
• the management module 132 installed on the quarantined server puts itself into a configurable self-quarantine mode where (by default) outbound network traffic is blocked, and only administrative inbound network traffic is allowed. If the quarantined server has been rooted and the attacker is smart enough, then the self-quarantine mode can be circumvented. However, in a large number of cases of less sophisticated viruses (and in cases where an infected system does not yet have a malicious payload and is just performing reconnaissance), self-quarantine mode helps provide an additional layer of protection. Even in the case of a very advanced threat, other managed servers 130 provide isolation from the quarantined server.
• quarantine mode is implemented as follows: First, the global security module 390 determines to quarantine a particular managed server 130. For example, the global security module 390 determines that a network attack originated from the particular managed server 130 or the particular managed server 130 has a vulnerability. This determination can be based on, for example, an action performed by the global manager 120 (e.g., analysis of information stored in the global security data repository 335) and/or a notification received by the global manager from an external source (e.g., a managed server 130, a third-party vulnerability scanner, or a user command).
• a notification received from a managed server 130 can concern, for example, a rogue process/action or operating system- level tampering.
• a notification received from a vulnerability scanner can concern, for example, devices that have vulnerabilities.
• a notification received from a user command can concern, for example, a bad actor that was identified by a person using any possible means.
• the global security module 390 sets a quarantine-specific configured characteristic (referred to herein as "CCQ") to a particular value, such as a threat level (1, 2, 3, etc.).
• CCQ can be used to define Actor-Set Q conditionally, where each member of Actor-Set Q has a CCQ value greater than zero ("CCQ>0").
• CCQ can also be used to conditionally define multiple quarantine actor-sets (e.g., one quarantine actor-set for each threat level, where each member of that actor-set has the same CCQ value).
• CCQ can also be used in conjunction with a rule's condition portion (a Boolean expression) to specify whether the rule applies to a particular managed server 130. For example, a condition portion of
• a quarantine actor-set whether defined conditionally or by explicitly-assigned members, can be used in the administrative domain-wide management policy 330 within a rule's used-by (UB) portion or provided-by (PB) portion. Specifically, a quarantine actor-set can be used as part of a set difference calculation (e.g., subtraction of common set members).
• the UB portion "* - ⁇ quarantine actor-set>" specifies that anybody except members of the quarantine actor-set can use a service, where the wildcard character "*" denotes anybody, the subtraction character "-” denotes "except”, and " ⁇ quarantine actor- set>” denotes any type of quarantine actor-set (whose members could be, for example, all quarantined managed servers or only managed servers with particular CCQ values (e.g.,
• a quarantine actor-set can also be used to positively indicate a provider or consumer.
• the PB portion " ⁇ quarantine actor-set>" specifies that members of the quarantine actor-set provide a service, such as allowing connections from devices that are part of an administrative security response team.
• CCQ in a rule's condition portion can be logically equivalent to using a quarantine actor-set in a set difference calculation in a rule's UB portion or PB portion.
• the administrative domain state update module 385 receives this change to the administrative domain state 320 and processes the change accordingly, as explained above.
• updated management instructions e.g., relevant actor-sets and/or function-level instructions
• Receipt of the updated management instructions causes those managed servers (specifically, their policy compilation modules 410) to generate new management module configurations 134 and reconfigure their management modules 132 accordingly.
• the new management module configurations 134 are generated based on the updated management instructions.
• the received updated management instructions cause that server to enter self-quarantine mode.
• the function-level instructions follow a whitelist-type model (e.g., providing an exhaustive list of what the server may do)
• the updated function-level instructions might be a subset of the previously-received function-level instructions.
• the quarantined managed server 130 will not be allowed to perform as many tasks as it did when it was not quarantined.
• the received updated management instructions (specifically, any quarantine actor-sets and/or quarantine function-level instructions) cause that server to isolate the quarantined server.
• the quarantine function-level instructions need not be sent again from the global manager 120 to the managed servers 130 if those instructions were previously sent and have not changed.
• the policy compilation module 410 applies the quarantine function-level instructions to members of the quarantine actor-sets and does not apply the standard function- level instructions to those members.
• the reconfiguration of the management module 132 causes the management module to block inbound traffic from the members of the quarantine actor-sets (i.e., the quarantined managed servers 130).
• a quarantined managed server 130 i.e., release the server from quarantine mode. For example, if the quarantined managed server 130 has been made safe (e.g., by removing malicious software or
• releasing a quarantined managed server 130 from quarantine mode is implemented as follows: First, the global security module 390 determines to release a particular managed server 130 from quarantine. For example, the global security module 390 determines that the managed server 130 no longer poses a security threat. This determination can be based on, for example, an action performed by the global manager 120 (e.g., analysis of information stored in the global security data repository 335) and/or a notification received by the global manager from an external source (e.g., a third-party vulnerability scanner or a user command).
• an action performed by the global manager 120 e.g., analysis of information stored in the global security data repository 335
• a notification received by the global manager from an external source e.g., a third-party vulnerability scanner or a user command.
• a notification received from a vulnerability scanner can concern, for example, devices that have vulnerabilities.
• the vulnerability notification lists devices that previously had vulnerabilities but no longer do.
• the vulnerability notification lists devices that currently have vulnerabilities.
• the global security module 390 can compare a recent vulnerability notification to an old vulnerability notification to determine which devices previously had vulnerabilities but no longer do.
• a notification received from a user command can concern, for example, a managed server 130 that was identified by a person as no longer posing a security threat.
• the global security module 390 modifies the administrative domain state 320 to indicate that the particular managed server 130 is released from quarantine. For example, the global security module 390 removes the particular managed server 130 from a special quarantine actor-set. In another example, the global security module 390 sets a quarantine-specific configured characteristic to a particular value, such as a threat level (e.g., 0 for no threat).
• a threat level e.g., 0 for no threat
• the administrative domain state update module 385 receives this change to the administrative domain state 320 and processes the change accordingly, as explained above.
• updated management instructions e.g., relevant actor-sets and/or function-level instructions
• Receipt of the updated management instructions causes those managed servers (specifically, their policy compilation modules 410) to generate new management module configurations 134 and reconfigure their management modules 132 accordingly.
• the new management module configurations 134 are generated based on the updated management instructions.
• the received updated management instructions cause that server to exit self-quarantine mode.
• the function-level instructions follow a whitelist-type model (e.g., providing an exhaustive list of what the server may do)
• the updated function-level instructions might be a superset of the previously-received function- level instructions.
• the unquarantined managed server 130 will be allowed to perform more tasks than it did when it was quarantined.
• the received updated management instructions (specifically, any quarantine actor-sets and/or quarantine function-level instructions) cause that server to stop isolating the newly-unquarantined server.
• the policy compilation module 410 applies the quarantine function-level instructions to members of the quarantine actor-sets (which no longer include the newly-unquarantined server) and does not apply the standard function-level instructions to those members.
• the reconfiguration of the management module 132 causes the management module to block inbound traffic from the members of the quarantine actor-sets.
• FIG. 10 is a flowchart illustrating a method 1000 of quarantining a managed server 130 within an administrative domain 150, according to one embodiment.
• the administrative domain 150 includes a plurality of managed servers 130 that use management instructions to configure management modules 132 so that the configured management modules implement an administrative domain- wide management policy that comprises a set of one or more rules, so that the quarantined managed server is isolated from other managed servers in the plurality of managed servers.
• Other embodiments can perform the steps in different orders and can include different and/or additional steps. In addition, some or all of the steps can be performed by entities other than those shown in FIG. 1.
• a description of a managed server 130 (the managed server that will be quarantined) has already been stored in an administrative domain state 320 of a global manager 120. Also, actor-sets for the administrative domain have already been cached in the global manager 120. Finally, a management policy perspective and relevant actor-sets have already been cached in association with another managed server 130 (different from the quarantined managed server). At this point, the method 1000 begins.
• step 1010 the description of the managed server 130 is modified to indicate that the managed server is quarantined.
• the global security module 390 modifies the administrative domain state 320 by setting a quarantine-specific configured characteristic of the managed server 130 to a particular value, thereby specifying a description of the quarantined managed server.
• step 1020 cached actor-sets are updated to indicate the quarantined managed server's changed state.
• the global security module 390 uses the actor enumeration module 370 to update the cached actor-sets for the administrative domain, thereby specifying updated actor-sets.
• step 1030 a determination is made regarding which updated actor-sets are relevant to the other managed server 130.
• the global security module 390 uses the relevant actors module 380 to determine which updated actor-sets are relevant to the other managed server 130, thereby specifying currently-relevant updated actor-sets.
• step 1070 the updated actor-set and an instruction to add, remove, or modify the updated actor-set are sent to the other managed server.
• the global security module 390 sends the updated actor-set and the instruction to the other managed server.
• FIG. 11 is a flowchart illustrating a method 1100 of processing a change to a state of a group of unmanaged devices 140 within an administrative domain 150, according to one embodiment.
• the administrative domain 150 includes a plurality of managed servers 130 that use management instructions to configure management modules 132 so that the configured management modules implement an administrative domain- wide management policy that comprises a set of one or more rules.
• Other embodiments can perform the steps in different orders and can include different and/or additional steps. In addition, some or all of the steps can be performed by entities other than those shown in FIG. 1.
• step 1110 the description of the unmanaged device group is modified to add an unmanaged device to the unmanaged device group.
• the global security module 390 modifies the administrative domain state 320 by adding an unmanaged device to the unmanaged device group.
• step 1120 cached actor-sets are updated to indicate the unmanaged device group's changed state.
• the global security module 390 uses the actor enumeration module 370 to update the cached actor-sets for the administrative domain, thereby specifying updated actor-sets.
• step 1130 a determination is made regarding which updated actor-sets are relevant to the managed server 130.
• the global security module 390 uses the relevant actors module 380 to determine which updated actor-sets are relevant to the managed server 130, thereby specifying currently-relevant updated actor-sets.
• step 1140 a determination is made regarding whether the currently-relevant updated actor sets differ from actor-sets previously sent to the managed server 130.
• the global security module 390 compares the currently-relevant updated actor sets to actor-sets previously sent to the managed server 130 (which were cached in association with the managed server as "relevant actor-sets"). Responsive to determining that the currently-relevant updated actor-sets do not differ from (e.g., are identical to) the previously- sent actor-sets, the method 1100 proceeds to step 1150. Responsive to determining that the currently-relevant updated actor-sets do differ from the previously-sent actor-sets, the method 1100 proceeds to step 1160.
• step 1150 no further action is taken.
• the global security module 390 takes no further action.
• step 1160 an updated actor-set that should be added, removed, or modified relative to the previously-sent actor-sets is determined.
• the global security module 390 compares the currently-relevant updated actor sets to actor-sets previously sent to the managed server 130.
• step 1170 the updated actor-set and an instruction to add, remove, or modify the updated actor-set are sent to the managed server.
• the global security module 390 sends the updated actor-set and the instruction to the managed server.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Software Systems (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Virology (AREA)
• Computing Systems (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Multi Processors (AREA)

Priority Applications (4)

Applications Claiming Priority (4)

Publications (2)

Family

ID=53180366

Family Applications (1)

Country Status (5)

Cited By (3)

Families Citing this family (2)

Family Cites Families (11)

• 2014
  • 2014-09-08 JP JP2016552416A patent/JP6491221B2/ja active Active
  • 2014-09-08 WO PCT/US2014/054505 patent/WO2015076904A2/en not_active Ceased
  • 2014-09-08 CN CN201480060318.7A patent/CN105683943B/zh active Active
  • 2014-09-08 EP EP14863433.0A patent/EP3066581B1/en active Active
  • 2014-09-19 TW TW103132517A patent/TWI526872B/zh active

Also Published As

Similar Documents

Legal Events