Patent Application
20110035781
1. Technical Field
The subject matter herein relates generally to real-time monitoring, auditing and protection of information assets in enterprise repositories such as databases, file servers, web servers and application servers.
2. Description of the Related Art
“Insider” intrusions are damaging to enterprises and cause significant corporate risk of different forms including: brand risk, corporate trade secret disclosure risk, financial risk, legal compliance risk, and operational and productivity risk. Indeed, even the specification of an insider intrusion creates challenges distinct from external intrusions, primarily because such persons have been authenticated and authorized to access the devices or systems they are attacking. Industry analysts have estimated that insider intrusions have a very high per incident cost and in many cases are significantly more damaging than external intrusions by unauthorized users. As such, it is critical that if an insider intrusion is detected, the appropriate authorities must be alerted in real-time and the severity of the attack meaningfully conveyed. Additionally, because users who have complete access to the system carry out insider intrusions, it is important to have a mitigation plan that can inhibit further access once an intrusion is positively identified.
Classically, intrusion detection has been approached by classifying misuse (via attack signatures), or via anomaly detection. Various techniques used for anomaly detection include systems that monitor packet-level content and analyze such content against strings using logic-based or rule-based approaches. A classical statistical anomaly detection system that addressed network and system-level intrusion detection was an expert system known as IDES/NIDES. In general, statistical techniques overcome the problems with the declarative problem logic or rule-based anomaly detection techniques. Traditional use of anomaly detection of accesses is based on comparing sequence of accesses to historical learned sequences. Significant deviations in similarity from normal learned sequences can be classified as anomalies. Typical similarity measures are based on threshold-based comparators or non-parametric clustering classification techniques such as Hidden Markov models. While these known techniques have proven useful, content-based anomaly detection presents a unique challenge in that the content set itself can change with time, thus reducing the effectiveness of such similarity-based learning approaches.
It is also known that so-called policy languages have been used to specify FCAPS (fault-management, configuration, accounting, performance, and security) in network managements systems. For example, within the security arena, policy languages sometimes are used to specify external intrusion problems. These techniques, however, have not been adapted for use in specifying, monitoring, detecting and ameliorating insider intrusions.
In typical access management, it is also known that simple binary matching constructs have been used to characterize authorized versus unauthorized data access (e.g., “yes” if an access request is accompanied by the presence of credentials and “no” in their absence). In contrast, and as noted above, insider intrusions present much more difficult challenges because, unlike external intrusions where just packet-level content may be sufficient to detect an intrusion, an insider intrusion may not be discoverable absent a more holistic view of a particular data access. Thus, for example, generally it can be assumed that an insider has been authenticated and authorized to access the devices and systems he or she is attacking; thus, unless the behavioral characteristics of illegitimate data accesses can be appropriately specified and behavior monitored, an enterprise may have no knowledge of the intrusion let alone an appropriate means to address it.
U.S. Pat. No. 7,415,719 issued to Moghe et al, describes a method, system and appliance-based solution that enables an enterprise to specify an insider attack and to respond to that attack. The subject matter herein is an enhancement to that approach.
This disclosure describes a system that comprises of a set of components that interact together to achieve large-scale distributed data auditing, searching, and analytics. Traditional systems require auditing data to be captured and centralized for analytics, which leads to scaling and bottleneck issues (both on network and processing side). Unlike these systems, the system described herein leverages the combination of distributed storage and intelligence, along with centralized policy intelligence and coordination, to allow for large-scale data auditing that scales. This architecture allows for data auditing in “billions” of events, unlike traditional architectures that struggled in the realm of “millions” of events.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
As will be seen below, this disclosure describes a distributed monitoring architecture having both “client” and “server” components, together with a management console that interacts with these components to facilitate execution of distributed search and/or audit queries across multiple client appliances, each of which may monitor a plurality of data servers across an enterprise computing environment. Before described the distributed approach in detail, the following background is provided.
As used herein, and by way of background, an “insider” is an enterprise employee, agent, consultant or other person (whether a human being or an automated entity operating on behalf of such a person) who is authorized by the enterprise to access a given network, system, machine, device, program, process, or the like, and/or one such entity who has broken through or otherwise compromised an enterprise's perimeter defenses and is posing as an insider. More generally, an “insider” can be thought of a person or entity (or an automated routine executing on their behalf) that is “trusted” (or otherwise gains trust, even illegitimately) within the enterprise. An “enterprise” should be broadly construed to include any entity, typically a corporation or other such business entity, that operates within a given location or across multiple facilities, even worldwide. Typically, an enterprise in which the distributed search/audit and analytics features of the present invention is implemented operates a distributed computing environment that includes a set of computing-related entities (systems, machines, servers, processes, programs, libraries, functions, or the like) that facilitate information asset storage, delivery and use.
One such enterprise environment is illustrated in
As also illustrated in
In the illustrated embodiment, the network appliance monitors the traffic between a given switch and a given cluster to determine whether a given administrator- (or system-) defined insider attack has occurred. As used herein, the phrases “insider intrusions,” “access intrusion,” “disclosure violations,” “illegitimate access” and the like are used interchangeably to describe any and all disclosure-, integrity- and availability-related attacks on data repositories carried out by trusted roles. As is well-known, such attacks can result in unauthorized or illegitimate disclosures, or in the compromise of data integrity, or in denial of service. As already noted, the nature and type of data repositories that can be protected by the appliance include a wide variety of devices and systems including databases and database servers, file servers, web servers, application servers, other document servers, and the like (collectively, “enterprise data servers” or “data servers”). This definition also includes directories, such as LDAP directories, which are often used to store sensitive information.
Referring now back to
The monitoring layer may act in other than a promiscuous mode of operation. Thus, for example, given traffic to or from a given enterprise data server may be encrypted or otherwise protected. In such case, it may be desirable to include in the monitoring layer additional code (e.g., an agent) that can be provisioned to receive and process (through the filtering and decoding steps) data feeds from other sources, such as an externally-generated log.
The monitoring layer advantageously understands the semantics of the one or more data access protocols that are used by the protected enterprise data servers. As will be described in more detail below, the policy management layer 118 implements a policy specification language that is extremely flexible in that it can support the provisioning of the inventive technique across many different kinds of data servers, including data servers that use different access protocols. Thus, for example, the policy language enables the administrator to provision policy filters (as will described) that processe functionally similar operations (e.g., a “READ” Operation with respect to a file server and a “SELECT” Operation with respect to a SQL database server) even though the operations rely on different access protocols. Because the policy management layer 118 supports this flexibility, the monitoring layer 110 must likewise have the capability to understand the semantics of multiple different types of underlying data access protocols. In addition, the monitoring layer can monitor not only for content patterns, but it can also monitor for more sophisticated data constructs that are referred to herein (and as defined by the policy language) as “containers.” “Containers” typically refer to addresses where information assets are stored, such as table/column containers in a database, or file/folder containers in a file server. Content “patterns” refer to specific information strings. By permitting use of both these constructs, the policy language provides significant advantages, e.g., the efficient construction of compliance regulations with the fewest possible rules. The monitoring layer 118 understands the semantics of the underlying data access protocols (in other words, the context of the traffic being monitored); thus, it can enforce (or facilitate the enforcement of) such policy.
The second module 112 (called the analytics layer) implements a set of functions that match the access commands to attack policies defined by the policy management layer 118 and, in response, to generate events, typically audit events and alert events. An alert event is mitigated by one or more techniques under the control of the mitigation layer 116, as will be described in more detail below. The analytics are sometimes collectively referred to as “behavioral fingerprinting,” which is a shorthand reference that pertains collectively to the algorithms that characterize the behavior of a user's information access and determine any significant deviations from it to infer theft or other proscribed activities.
With reference again to
A given attack expression developed using the policy management layer is sometimes referred to as a policy filter. As seen in
The third module 114 (called the storage layer) preferably comprises a multi-step process to store audit events into an embedded database on the appliance. To be able to store with high performance, the event information preferably is first written into memory-mapped file caches 115a-n. Preferably, these caches are organized in a given manner, e.g., one for each database table. Periodically, a separate cache import process 117 invokes a database utility to import the event information in batches into the database tables.
The fourth module 116 (called the risk mitigation layer) allows for flexible actions to be taken in the event alert events are generated in the analytics layer. As will be described in more detail below, among the actions preferably supported by this module are user interrogation and validation, user disconnection, and user de-provisioning, which actions may occur synchronously or asynchronously, or sequence or otherwise. In a first mitigation method, the layer provides for direct or indirect user interrogation and/or validation. This technique is particularly useful, for example, when users from suspicious locations initiate intrusions and validation can ascertain if they are legitimate. If an insider intrusion is positively verified, the system then can perform a user disconnect, such as a network-level connection termination. If additional protection is required, a further mitigation technique then “de-provisions” the user. This may include, for example, user deactivation via directories and authorization, and/or user de-provisioning via identity and access management. Thus, for example, if an insider intrusion is positively verified, the system can directly or indirectly modify the authorization information within centralized authorization databases or directly modify application authorization information to perform de-provisioning of user privileges. The mitigation layer may provide other responses as well including, without limitation, real-time forensics for escalation, alert management via external event management (SIM, SEM), event correlation, perimeter control changes (e.g., in firewalls, gateways, IPS, VPNs, and the like) and/or network routing changes.
Thus, for example, the mitigation layer may quarantine a given user whose data access is suspect (or if there is a breach) by any form of network re-routing, e.g, VLAN re-routing. Alternatively, the mitigation layer (or other device or system under its control) undertakes a real-time forensic evaluation that examines a history of relevant data accesses by the particular user whose actions triggered the alert. Forensic analysis is a method wherein a history of a user's relevant data accesses providing for root-cause of breach is made available for escalation and alert. This reduces investigation time, and forensic analysis may be used to facilitate which type of additional mitigation action (e.g., verification, disconnection, de-provisioning, some combination, and so forth) should be taken in the given circumstance.
As has already been described, the fifth module 118 (called the policy management layer) interacts with all the other layers. This layer allows administrators to specify auditing and theft rules, preferably via an English-like language. The language is used to define policy filters (and, in particular, given attack expressions) that capture insider intrusions in an expressive, succinct manner. The language is unique in the sense it can capture signatures as well as behavioral anomalies to enable the enterprise to monitor and catch “insider intrusions,” “access intrusions,” “disclosure violations,” “illegitimate accesses” “identity thefts” and the like regardless of where and how the given information assets are being managed and stored within or across the enterprise.
A given appliance may be operated in other than promiscuous mode. In particular, the monitoring layer (or other discrete functionality in the appliance) can be provided to receive and process external data feeds (such as a log of prior access activity) in addition to (or in lieu of) promiscuous or other live traffic monitoring.
While the above-described appliance provides many useful advantages, it is desirable to extend this functionality to provide for “distributed” data search, audit and analytics. This distributed functionality is now described.
As shown in the
According to this disclosure, the system 300 has the ability to run a distributed query across multiple appliances—each of which may monitor many data servers—and returns consolidated results at the TMC 302 console. This paradigm of distributed queries can also be used to create reports and analytics. The distributed query and reporting functionality is described with reference to
1. From the CMC server 304, push the query to all CMC client appliances 306 in the target appliance group.
2. On each client appliance 306, estimate the results set size and report the estimate to the server 304.
3. On the server 304, if the query is interactive, report consolidated query time and size estimates to the user and ask for confirmation to proceed.
If “yes,” or if the query is non-interactive:
4. On each client appliance 306, extract and sort query-matching events from a client-resident event database.
5. On each client appliance, stream (or otherwise provide) the local results set back to the CMC server 304, e.g., via a GCL connection.
6. On the server 304, collect per-appliance query results.
7. Convert all event date-times to server time zone, sort the collective results by date-time, apply any range arguments, and present results to the user in a desired format.
This completes the processing.
As one of ordinary skill will appreciate, the above-described solution provides many benefits. The scaling facilitated by the distributed data auditing architecture described herein has impact in three areas:
Storage—A distributed architecture reduces the amount of storage required. An N-appliance system reduces centralized storage by a factor of N.
Processing—A distributed data auditing approach leverages local intelligence in each appliance, thus allowing for high performance analytics to be performed on local data events.
Network overhead—An analytics architecture that is centralized creates a huge network bottleneck, because all the data audit events have to be centralized. In contrast, a distributed data auditing architecture preferably performs analytics locally, retrieving only the result set for centralized reporting and consolidation. The amount of network bandwidth is reduced significantly in the distributed data auditing architecture.
A typical purely centralized data auditing system with N appliances (each holding K events) is limited by a fixed centralized threshold determined by manager storage, processing, and the acceptable network throughput. Usually such systems scale out when the total data auditing event capacity hits millions of events. In contrast, the current invention scales to N*K events. Assuming N>10, and K is in the order of hundreds of millions, the current invention scales into billions of data auditing events.
More generally, although the appliance has been described in the context of a method or process, the present invention also relates to apparatus for performing the operations herein. As described above, this apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including an optical disk, a CD-ROM, a magnetic-optical disk, a read-only memory (ROM), a random access memory (RAM), a magnetic or optical card, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
A server appliance comprises commodity hardware and software and executes one or more software applications or utilities. The management console is a machine having a web-based interface or the like. In an illustrated embodiment, an application instance executes on a base operating system, such as Red Hat Linux 10.0. A communications middleware layer provides a distributed communication mechanism. Other components may include FUSE (Filesystem in USErspace), which may be used as a file system. A data store for storing data in a database may be implemented, for example, by PostgreSQL (also referred to herein as Postgres), which is an object-relational database management system (ORDBMS). A machine may execute a Web server, such as Jetty, which is a Java HTTP server and servlet container. Of course, the above mechanisms are merely illustrative.
As used herein, the word “location” is not necessarily limited to a “geographic” location. While client and server appliances are typically separated geographically, this is not a requirement. A cluster of clients may be located in one data center in a city, while a cluster of server appliances is located in another data center in the same city. The two clusters may also be in different locations within a single data center. Some clients may be located in different locations and be managed by the same server appliance. All such configurations and variants are within the scope of this disclosure.
This disclosure describes a system that comprises of a set of components that interact together to achieve large-scale distributed data auditing, searching, and analytics. Traditional systems require auditing data to be captured and centralized for analytics, which leads to scaling and bottleneck issues (both on network and processing side). Unlike these systems, the system described herein leverages the combination of distributed storage and intelligence, along with centralized policy intelligence and coordination to allow for large-scale data auditing that scales. In the current technology cycles, we expect this new architecture to allow for data auditing in “billions” of events, unlike traditional architectures that struggled in the realm of “millions” of events.
This application is based on and claims priority to Ser. No. 61/167,426, filed Apr. 7, 2009. This application also is related to Ser. No. 10/750,070, filed Sep. 24, 2004.
| Number | Date | Country | |
|---|---|---|---|
| 61167426 | Apr 2009 | US |
