Patent Application
20150156170
The disclosure relates generally to the field of network communication.
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.
In current network architectures, security features may be provided as an add-on feature after the network is configured. However, security is much easier to accept when it is part of the networking infrastructure than when it is a standalone requirement. In future networks, applications that have yet to be developed may be provided to network users, and such applications will likely have new and yet unseen security issues.
Among the current information security prevention systems such as firewalls and the Intrusion Detection System (IDS), there exist several deficiencies such as alert overload, high false alarm rate, absence of effective alert management mechanisms, etc. As a result, alert data overload may occur in the network, and these data alert could be redundant, irrelevant or meaningless. A result of this information flooding is sometimes the inability to correctly correlate the events to locate the security breach. Cloud computing exacerbates this situation further as newly instantiated services need to be protected and an unused virtual machine are taken out of service. This dynamicity results in a profile that is complex and not amenable to simple rate alert management systems.
One embodiment provides an apparatus, e.g. a content addressable network (CAN) gateway, that includes a processor and a memory coupled to the processor. The memory contains instructions that when executed configure the processor to operate to receive from a security event generator, e.g. a host, a security event log that includes a protocol tag. The processor is further configured to operate to securely forward the log to a selected one of a plurality of peers in a distributed hash table (DHT), based on the protocol tag.
In any embodiment of the apparatus the DHT may be a content addressable network. In any embodiment the processor may be configured to accept the security event log only on the condition that the log includes a valid security certificate. In any embodiment the processor may be configured to forward the log only on the condition that the selected one is authenticated with a receiving entity.
Another embodiment provides an apparatus, e.g. a peer of a distributed hash table (DHT), that includes a processor and a memory coupled to the processor. The memory includes instructions that when executed, e.g. by the processor, configure the processor to operate to receive security event logs from an event generator, e.g. via a gateway node. The processor is further configured to filter the events, and to produce a security report from the filtered events. The processor may then send the report to a security controller.
In any embodiment of the aforementioned apparatus, the processor is further configured to filter events by rejecting events associated with non-assigned communication protocols. In any embodiment the processor may be configured to receive the events from a single gateway computer. In any embodiment the processor may be one of a plurality of processors configured to filter the events, with only the processor being configured to send the report to a security controller.
Another embodiment provides an apparatus, e.g. a computer network defense (CND) controller, that includes a processor and a memory coupled to the processor. The memory includes instructions that when executed configure the processor to operate to receive one of a plurality of security reports from corresponding ones of a plurality of peers in a computer network. Each of the security reports is associated with a particular communication protocol. The instructions further configure the processor to defend, in response to the received security event reports, against a threat to the network based on the received reports.
In any embodiment of the aforementioned apparatus, the peers may be members of a distributed hash table (DHT). In any such embodiment the DHT may include a content addressable network. In any embodiment of the apparatus the processor may be configured to accept the security reports only on the condition that identity of each of the peers is authenticated. In any embodiment the processor may be configured to issue instructions that block traffic from an internet protocol (IP) address associated with the threat.
Another embodiment provides a method, e.g. of operating a CAN gateway. The method includes receiving from an event generator a security event log including a protocol tag. The security event log is securely forwarded to a selected one of a plurality of peers in a distributed hash table (DHT), based on the protocol tag.
In some embodiments of the method the DHT may be a content addressable network. In some embodiments the security event log is accepted only on the condition that the security event log includes a valid security certificate. In some embodiments the security event log is forwarded only on the condition that the selected one is authenticated with a receiving entity.
Another embodiment provides a method, e.g. of operating a peer in a computer network, e.g. a DHT. The method includes receiving security event logs from an event generator, e.g. via a gateway. Logged events are filtered based on an assigned communication protocol, thereby producing a security event report. The event report may be sent to a security controller.
Any embodiment of the aforementioned method may include filtering the events by rejecting events associated with non-assigned communication protocols. In any embodiment the filtering may include determining a statistical measure of the filtered events.
Another embodiment provides a method, e.g. of operating a CND controller. The method includes receiving one of a plurality of security event reports from each of a corresponding plurality of peers in a computer network. Each one of the security event reports is associated with a particular communication protocol. In response to the received security event reports, the method defends against a threat to the network based on the received security event reports. The defending comprises at least one of 1) electronically generating a visual or aural notification, and 2) directing instructions to a router via a physical data path to block internet traffic originating from an IP address associated with the threat.
In any embodiment of the aforementioned method the peers may be members of a distributed hash table (DHT). In any embodiment the DHT may include a content addressable network. In any embodiment the security event reports may be accepted only from ones of the peers that have an authenticated identity. In any embodiment instructions may direct the router to block IP packets from the IP address to a controller of the network.
In any embodiment of the aforementioned apparatuses and methods, the communication protocol may be one of hypertext transfer protocol (HTTP), secure hypertext transfer protocol (HTTPs), session initiation protocol (SIP), secure shell protocol (SSH), file transfer protocol (FTP), and secure file transfer protocol (sFTP) and Microsoft NetBIOS.
A more complete understanding of the present invention may be obtained by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
The disclosure is directed to, e.g. apparatus, systems and methods for defending a computer network from malicious network traffic.
Embodiments presented herein provide, e.g., an improved computer network defense (CND) architecture for responding to security threats directed against computer networks. Event generators, e.g. programs running on computer hosts connected to a network, may detect events related to a security threat, e.g. an attack by a malicious entity. The network may be part of, e.g. a cloud network, enterprise network or internet service provider (ISP) network. The generators may report the events to a gateway computer connected to network servers that may be members of a DHT. The servers may be organized in a virtual space in which each server may filter and/or aggregate security logs received from the gateway computer. The gateway computer may deterministically route the logs according to a protocol tag received with each log, wherein the tag corresponds to a particular communications protocol, e.g. HTTP, SIP, or FTP. Each server may aggregate the event logs received by it and securely forward a security report to a CND controller. The CND controller may analyze the received reports and determine if the network is under attack, and respond accordingly. Because the security reports are based on filtered and/or aggregated security events, computational load on the controller is reduced, reducing the possibility of an attacker overwhelming the ability of the controller to respond effectively to the threat. Furthermore, the security event log and aggregated reports may be transmitted securely within the CND architecture, the architecture is expected to be robust against attempts by an attacker to defeat countermeasures employed by the CND controller.
The CND can be implemented on one of several levels, e.g. on a departmental level, an enterprise level, or Internet Service Provider (ISP) level. When implemented at a very coarse-grain level (i.e. ISP-level), issues such as privacy of information between different cloud customers of the ISP become important, as does the confidentiality of data flowing between the ISP and its customers. Various embodiments address such a need for confidentiality by using an OpenSSL or a GnuTLS library with either self-signed certificates or certificates issued by a certificate authority to perform mutual authentication of the parties and negotiate the cryptographic properties for creating an encryption channel.
Some aspects of this disclosure are related to D. K. Al-Omari, et al., “A Novel Architecture for a Computer Network Defense (CND) System Using Content Addressable Networks (CAN)”, Globecom Workshops (GC Wkshps), 2012 IEEE vol., no., pp. 758,762, 3-7 Dec. 2012 (doi: 10.1109/GLOCOMW.2012.6477670), incorporated herein in its entirety.
Because the information from the collector engines 130 in sent unfiltered to the event correlation engine 120, the system 100 may be vulnerable to alert overload and high false alarm rate. Indeed, a malicious entity could exploit these vulnerabilities to render the system 100 unable to effectively guard against attack.
The event generators 210 may be or include, e.g. host computers, applications executing on hosts, routers, or other network elements. The event generators 210 produce security events. As used herein, the term “security event” refers to the occurrence of a particular event or pattern of events consistent with a possible attack on one or more members of the network 200. Such attacks may occur via communication by the attacker with an event generator 210 using one of several available communications protocols. Such protocols include, e.g. hypertext transfer protocol (HTTP), secure hypertext transfer protocol (HTTPs), session initiation protocol (SIP), secure shell protocol (SSH), file transfer protocol (FTP), and secure file transfer protocol (sFTP) and Microsoft NetBIOS. Those skilled in the pertinent art will appreciate that the listed protocols are a subset of available protocols, and the principles of the disclosure may be applied to any of the larger set of protocols. In two nonlimiting examples, an attacker may employ an enumeration attack or a denial of service (DOS) attack. These examples are described in greater detail below.
Security events may occur in discrete applications and/or agents executed on the event generators 210. These software entities may provide a detailed account of an attack, e.g. an event log 270 (or simply log) of communications events, also referred to as alerts. The event log 270 may include, e.g., a record of the type of communication protocol received from a particular attacker (e.g. identified by an internet protocol address of the attacker), and a timestamp of the communication.
The gateway 220 receives the logged security events from the event generators 210 and, as described further below, distributes the events to peers (or nodes) 250 of the DHT 230. Each peer 250 may be a computer, e.g. a server, that is configured to communicate with each of the other peers 250 in the network DHT 230, with the CAN gateway 220 and the controller 240.
Each peer 250 maintains a portion of the DHT 230 under its control. Because no one peer 250 is responsible for the entire DHT 230, important properties such as resilience, scalability, and fault tolerance can be provided. Compared to the linear complexity (O(N)) of finding a datum among N peers in an unstructured approach, a DHT may provide the ability to locate an item with a complexity of O (log N) equal to the complexity of well-known non-distributed search and indexing techniques. Necessary DHT maintenance operations like routing performance, peers joining and departing the DHT, and routing state maintenance each have a complexity of O (log N). The DHT may be organized under one of several available algorithms. For example, ring-based approaches such as Pastry, Tapestry and Chord, which each use similar search algorithms such as binary ordered B*trees. Content Addressable Networks (CAN) and Viceroy may use a geometric design, e.g. an n-dimensional torus, such that a peer 250 is assigned a portion of a search space [0, 2n−1] often referred to as a zone.
In some embodiments the gateway 220 accepts logs 270 only from event generators 210 that are authenticated. This authentication is expected to improve security of the network 200 by making it difficult for an attacker to mimic an event generator. Appropriate authentication procedures are well known to those skilled in the pertinent art, and may include, e.g. public-private key cryptography, in which one of the event generators 210 and the gateway 220 use their identities in a security certificate to perform mutual authentication, and a public key to encrypt the channel over which this information is transmitted.
There are two related aspects that may be addressed to maintain a level of security of the CND. First, the peer 250 associated with each of the zones in the DHT 230 may be authenticated. Lack of authentication may allow an entity to inject itself into the DHT 230 as a malicious peer. Second, the gateway 220 may reject event logs 270 of event generators 210 whose identity has not been well established. This exclusion may prevent unknown and possibly malicious hosts, routers, or applications to inject spurious or erroneous events into the CND. These security measures may be implemented by one of the peers 250 operating as a bootstrap node, and the gateway 220.
The first peer 250 to join the DHT 230 may be referred to as the bootstrap node. One of the peers 250 may be assigned as the bootstrap node when the network 200 is implemented. Each of the other peers 250 acquires the network address of the bootstrap node on startup. The peers 250 contact the bootstrap node, which admits the joining peers 250 nodes into the CAN by either splitting its own zone 260 or by redirecting the joining peer 250 to a neighboring peer 250. If the neighboring peer 250 is not the destination node, the neighboring peer 250 may redirect the joining peer 250 until the destination zone 260 is reached. The peer 250 associated with the destination zone 260 may then proceed to split its zone 260 with the joining peer 250 taking over responsibility of one portion of the split zone 260 as determined by the CAN protocol. In various embodiments all nodes in the DHT 230, including the bootstrap node and the peers 250, have certificates issued by a local or global certificate authority. In other embodiments the certificates are self-signed. However, this latter embodiment may require that the bootstrap node be provided a fingerprint related to the certificate of the joining peer 250.
In some embodiments the system 200 is configured such that the only configuration required is for the event generators to know the network coordinates of the gateway 220 so they can transmit event logs to the gateway 220. Such a configuration substantially automates the configuration of the network 200, thereby avoiding mis-configuration that can lead to suboptimal performance of the component parts of the network 200.
In some embodiments each event generator 210 may possess a certificate that asserts its identity for authentication and derivation of cryptographic keys related to encryption. The certificate may be, e.g. issued by an enterprise IT domain, global certificate authority, or may be a self-signed certificate with fingerprint validation. When the event generators 210 transmit security events to the CAN gateway 220, the gateway 220 may verify the identity of the sending event generators 210 before percolating the event into the DHT 230. When a particular event generator 210 is successfully authenticated, the alert information from that event generator 210 may flow between that generator 210 and the gateway node 220 confidentially by deriving appropriate an encryption key from the certificate. The peers 250 may be seeded with the network location of the gateway node 220 a priori.
The controller 240 is configured to receive from each of a plurality of the peers 250 a security event report 280. Each of the reports 280 may be associated with a particular communication protocol, e.g. as reported in the event logs 270. After receiving the event reports 280 from the peers 250, the controller 240 may correlate the reports to determine the nature of a possible attack, and may defend the network against such an attack. In some embodiments the defense includes making a notification available that may be perceived by a network administrator. For example, a suitable notification may be visual or aural, and may be displayed on a screen available to the administrator. In other embodiments the defense includes sending instructions to a router 290 that is configured to control traffic flow between the network 200 and the internet 295. The router 290 and the controller 240 may be connected by a physical data path, e.g. an electrical or optical path. For the purposes of this discussion a wireless electrical (e.g. radio frequency) signal is defined as an electrical physical data path. The instructions may, for example, direct the router 290 to block all IP packets originating from an IP address associated with the threat.
In various embodiments a network administrator may configure the controller 240 to implement a strategy to defend the network 200. Such a strategy may include a prioritization of attacks to defend against. The interaction between the administrator and the attacker can be modeled using game theory. Such a game may include zero-sum or general-sum, pure or mixed strategies, with simultaneous or sequential information, and perfect or imperfect information.
One example of an attack is referred to as an enumeration attack. The following example is presented without limitation. Those skilled in the pertinent art will appreciate that the disclosed principles may be extended to other types of attacks without undue experimentation. This attack may begin with a malicious entity guessing usernames and sending username requests to network servers. If the usernames are valid within the domain of the servers, some servers respond with a 401 SIP response code asking the attacker to provide a response to an HTTP Digest challenge. If the usernames are not valid within the domain of the server, some servers simply return a 403 SIP response code. Thus, the attacker may differentiate between the two responses, e.g. a 401 versus a 403, to determine whether a certain user account exists on the SIP server or not. Armed with a set of such accounts, the attacker can try to perform a brute-force attack by providing a dictionary-based response to the challenge issued in a 401 SIP response.
Returning to
In a step 435 the gateway 220 translates the message conveying the event log 270 to a CAN message format.
Referring again to
Aggregation algorithms performed by the peers 250, e.g. the peer 250b, may summarize a plurality of discrete security events and/or alarms originating from different ones of the event generators 210 for a specific class or type of event. Correlation algorithms may take the aggregated information, as well as other available information, and determine a root cause of the events. The peers 250 may also perform statistical analysis of the events, e.g. determine a number of events per unit time, a histogram of event counts over a time range, or an average number of events in one or more time units. Embodiments are not limited to any particular aggregation, correlation and/or statistical algorithms, of which further treatment is beyond the scope of the disclosure. Moreover, the suitability of an algorithm or algorithms may depend on the specific threat environment.
In another nonlimiting example, a DOS attack based on parsing may proceed in a similar manner to that described by
Returning again to
In some embodiments the DHT architecture is modeled as a toroidal surface.
For discussion purposes the zones 520 may be viewed as mapped onto a two-dimensional (2D) Cartesian space, e.g. a plane, with extents determined by (x, y) coordinates. Thus, a zone 520 may be represented by a first corner at (x1, y1) and an opposite corner at (x2, y2). This zone space is referred to without limitation as CAN C. The peer 250 within CAN C may be equivalently referred to as peer C. In a nonlimiting example to illuminate the discussion below, a zone file may implement a zone mapping as follows:
To provide secure communication between the peers 250, an arbitrary, e.g. random or pseudorandom, point P (x, y) within CAN C (x1<x<x2 and y1<y<y2) may be selected as a key. The key may be used by peer C to route a put( ) lookup( ) or get( ) request to the peer 250 responsible for the zone 260 that contains the point P. Each zone may be responsible for a specific intrusion related to a protocol; thus, one zone (e.g. the zone 260 occupied by the peer 250a) may be responsible for HTTP intrusions while another zone (e.g. the zone 260 occupied by the 250b) may be responsible for SIP intrusions, and so on. In some embodiments overloading of the peer 250 in a particular zone 260 may be allowed for reliability purposes. In some embodiments security and integrity of the DHT 230, put( ) get( ) and lookup( ) requests is provided by constraining these requests to pass through the gateway 220.
Thus, referring again to
The gateway 220 may determine the protocol associated with the logged events which it is receiving events for receives an event log (e.g. an alert) it knows. The gateway 220 may then use a hash function that takes as input an invariant for that event generator 210, e.g. an IP address, a unique key assigned to that event generator 210, or a universally unique identifier computed once at startup. The gateway 220 may then produce a point P in C that is bounded by the space of the zone 260 responsible for collecting the specific alert generated by the event generator 210. In some embodiments the gateway node 210 does not compute P for each alert, but instead computes and caches P once on startup. The gateway 210 then need only re-compute P if the topology of C changes, such as by the addition of a new zone 260, and the resulting resizing of the remaining zones 260.
Those skilled in the pertinent art will appreciate that computational entities in the described embodiments may be implemented by a processor and a memory coupled to the processor. The memory includes instructions that when executed by the processor configure the processor to operate to implement aspects of the described embodiments. Thus, the event generators 210, the gateway 220, the peers 250 and the controller 240 may each be implemented by a processor and a memory. The instructions stored in the memory may be provided by a nontransitory computer-readable storage medium, e.g. a magnetic or optical disk, or a flash drive. The instructions may alternatively or also be delivered via a network connection to a software provider.
Although multiple embodiments of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the present invention is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the invention as set forth and defined by the following claims.
