TWI417737B - Real-time identification of an asset model and categorization of an asset to assist in computer network security - Google Patents

Description

Instant identification and asset classification of asset models to assist in computer network security

The present invention relates generally to security information/event management (SIM or SIEM) and in particular to accessing a model of a network node (e.g., a target node of an event) for use in conjunction with security information/events. The model data.

The Security Information/Event Management (SIM or SIEM) area generally relates to: 1) collecting information from network and network devices that reflects network activity and/or the operation of such devices; and 2) analyzing the data for enhanced security Sex. For example, the data can be analyzed to identify attacks on the network or a network device and determine which user or machine is responsible. If the attack is in progress, a countermeasure can be performed to block the attack or mitigate the damage caused by the attack. The collected data is typically originated in a message (eg, an event, alert, or alert) generated by a network device or in one of the log files.

The message or item generally indicates one or more computer network devices ("network nodes") involved in the network activity. For example, the message or item may indicate the node to which the activity is directed ("target node") and/or the node from which the activity originated ("source node"). Although it is possible to identify and investigate an attack using only the collected data, it is often useful to have additional information, such as information about the indicated network node.

Information about a network node (called an "asset model") can include, for example: the network protocol (IP) address of the node, the host name of the node, the network to which the node belongs, and the role of the node within the enterprise. One of the nodes is open Software, software (eg, operating systems and applications) installed on the node and known disadvantages or weaknesses of the node (referred to as "disadvantages of exposure").

Access the asset model during security analysis. Security analysis can be performed in batch mode or on-the-fly. In batch mode, when a security message/event is received, it is stored. Analyze the stored security information/events later. In the immediate mode, when security information/events are received, they are analyzed on-the-fly or near-instant.

In order for security analysis to occur on-the-fly (or near-instant), these asset models must be accessed on-the-fly (or near-instant). This is difficult to achieve because thousands of events are generated per minute, and each event indicates one or more nodes. For example, one event rate of one 5,000 events/second and four nodes/event produces 20,000 nodes/second. For each node, identify and access its asset model.

There is a need for a method of accessing an asset model in an efficient manner so that the asset model can be used immediately in conjunction with security information/events.

A manager receives one or more events and analyzes the events to detect the attack. An event description involves one of the actions of a computer network device (referred to as a "network node"). An event includes reference to one or more nodes (eg, a node to which the action is directed ("target node" and/or a node initiated by the action ("source node")), which is referred to as a "node reference" A node reference includes multiple fields, such as Internet Protocol (IP) addresses, network areas, host names, media access control (MAC) addresses, and asset identifiers (asset IDs).

The asset ID field is used to store a unique identifier (ID) assigned to one of the network nodes. When the manager receives an event for the first time, a node refers to it. The asset ID field is an empty field. Later, one of the "asset models" identifiers corresponding to the node is stored in the asset ID field. The ID is used to obtain an asset model corresponding to the network node associated with the ID and determine whether the network node is a member of a particular category. The manager accesses an asset model of a network node to perform a security analysis.

An asset model is a collection of information about a network node. This information may include, for example: the network protocol (IP) address of the node, the host name of the node, the network to which the node belongs, the role of the node within the enterprise, one of the nodes open, and installed on the node. A list of software (eg, operating systems and applications) and one of the known shortcomings or weaknesses of the node (referred to as "disadvantages of exposure").

The manager includes an identifier module and a category module. The identifier module provides functionality associated with a unique ID assigned to a network node and includes a lookup module and a management module. The lookup module determines the ID of the network node based on various characteristics of a network node (eg, IP address, host name, network area, and/or media access control (MAC) address). These pieces of information are used as index keys for placing one or more lookup data structures (eg, lookup tables). If a lookup is successful (for example, finding a value associated with the index key), the value is returned (which is the ID of the asset model of the node). The management module tracks which IDs have been assigned to the network node and which IDs have not been assigned.

The category module provides category-related functionality and includes a lookup module and a management module. The lookup module determines whether a particular network node (asset) is a member of a particular category (ie, belonging to a particular category). For this decision, the category module uses category information. Category data use one hand transfer The package (TC) to model can be attached to one of the classifications (characteristics) of an asset model, hierarchical and dynamic. The TC is stored in the memory as a set of meta-maps, where the one-bit mapping corresponds to a particular asset class or group. One of the one-dimensional mappings, 0/1, indicates whether there is a link between the particular asset class/group and an asset. The unique ID of an asset is used as an index into one of the recursive closure bit maps. The management module updates the category data as needed.

This document describes a computer-based system for extracting security incidents from heterogeneous sources that formalizes such events into a common schema and interleaves such formalized events with rules to generate mediation events. The system (an embodiment of which is embodied as a computer software) enables aggregation, correlation, detection, and investigative tracking of suspicious network activity from multiple security devices. The system also supports response management, random query resolution, reporting and replay for analytics analysis, and graphical visualization of cyber threats and activities.

Although the present system is described with reference to the various illustrated examples, these examples should not be construed as limiting the broader spirit and scope of the invention. For example, the examples presented herein illustrate distributed agents, managers, and consoles, which are merely one embodiment of the present invention. The general concepts and extensions of the present invention are much broader and extend to any computer-based or network-based security system. Moreover, the examples of the components that can be passed to the system and the information transmitted from the components of the system, as well as the information available to the components of the system, are presented in an attempt to further illustrate the invention, but are not provided as an illustrative example. Intention should not be treated as such.

Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data in a computer memory. These algorithmic descriptions and representations are tools used by those skilled in the computer science and technology to convey the substance of their work most effectively to those skilled in the art. In this context and in general, the algorithm is conceived to produce a sequence of steps that are self-consistent with one of the desired results. These steps are those steps that require entity manipulation of the number of entities. Usually, though not necessarily, the quantities are in the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated. Such signals have proven to be convenient, sometimes based on common reasons, as bits, values, elements, symbols, characters, terms, numbers or the like. However, it should be borne in mind that all such and similar terms should be associated with the appropriate number of entities and are only applied to the convenience of such quantities. Unless otherwise expressly stated, it is to be understood that throughout the description, a computer system or similar electronic computing device is used, such as "processing" or "computing" or "computing" or "decision" or "display" or similar terms. Actions and procedures for manipulating and converting data represented by physical (electronic) quantities in the scratchpad and memory of the computer system into memory or scratchpads or other such information in such computer systems Other materials in the storage, transmission or display device are also represented as the number of entities.

As indicated above, one embodiment of the present invention is exemplified in a computer software that is a computer readable command that indicates the processors when executed by one or more computer processors/systems. / The system performs the specified action. Such computer software can reside in one or more computer readable media, such as a hard disk drive, CD-ROM, DVD-ROM, only Read memory, read and write memory, and more. Such software may be distributed on one or more of the media, or such software may be downloaded across one or more computer networks (eg, the Internet). Regardless of the format, the computerized stylization, reproduction, and processing techniques described herein are merely simple examples of types of stylization, reproduction, and processing techniques that can be used to implement various aspects of the present invention. The scope of the patent application is to be understood by reference to the appended claims.

system structure

1 is a high level diagram of one of the environments having a security information/event management system 10 in accordance with an embodiment. System 10 includes an agent 12, one or more managers 14, and one or more consoles 16 (which may include a browser-based console version). In some embodiments, the agents, managers, and/or consoles can be combined in a single platform or distributed across two, three, or more platforms (eg, in the illustrated example). The use of this multi-layer architecture supports scalability as a computer network or system grows.

The agent 12 is a software program that extracts and filters high-efficiency, instant (or near-instant) local event data from various network security devices and/or applications. The main source of security incidents are commonly used network components, including firewalls, intrusion detection systems, and operating system logs. The agent 12 can collect events from any source that generates an event log or message and can operate at the local device, a merge point within the network, and/or through a simple Network Management Protocol (SNMP) trap.

The agent 12 can be associated with the automated program and via the manual Configuration file to configure. Each agent 12 can include one or more software modules including a normalization component, a time correction component, an aggregation component, a batch component, a parser component, a transport component, and/or other further components. . These components can be activated and/or deactivated through appropriate commands in the configuration file.

Manager 14 is a server-based component that further merges, filters, and interconnects events received from such agents by employing a rules engine 18 and a centralized event repository 20. One of the roles of the manager 14 retrieves and stores all real-time and historical event data (via the repository manager 22) to build a complete enterprise-wide security activity picture. The manager 14 also provides centralized management, notification (via one or more notifiers 24) and reports, and a knowledge base 28 and case management workflow. The manager 14 can be deployed on any computer hardware platform and a particular embodiment implements the event data storage component using a relational database management system (e.g., an Oracle ^(TM ) repository). The communication between the manager 14 and the agent 12 can be bidirectional (e.g., the manager 14 can send commands to the platform host agents 12) and encrypted. In some configurations, the manager 14 can act as a concentrator for multiple agents 12 and can forward information to other managers (eg, deployed to a corporate headquarters).

The manager 14 includes one or more agent managers 26 responsible for receiving event data messages transmitted by the agents 12. In the event that two-way communication with the agents 12 is implemented, the agent manager 26 can be used to send messages to the agents 12. If the agent and the manager communicate with encryption (this is optional), then the agent manager 26 It is responsible for decrypting the messages received from the agent 12 and encrypting any messages sent to the agents 12.

The console 16 is a computer-based (eg, workstation-based) application that allows security professionals to perform day-to-day management and operational tasks such as event monitoring, rulemaking, incident investigation, and reporting. Access control lists allow multiple security professionals to use the same system and event database, and each professional has its own perspective, association rules, alerts, reports, and knowledge base that are appropriate to its responsibilities. A single manager 14 can support multiple consoles 16.

In some embodiments, a browser-based version of the console 16 can be used to provide access to security events, knowledge base documents, reports, notifications, and cases. That is, the manager 14 can include accessing one of the web server components via a web browser resident on a person or handheld computer (which replaces the console 16) to provide some of the console 16 Or full functionality. Browser access is particularly useful for security professionals who are remote from such consoles 16 and for amateur users. The communication between the console 16 and the manager 14 is bidirectional and may be encrypted.

Through the above architecture, the system can support a centralized or decentralized environment. This is useful because an organization may want to implement a single instance of system 10 and use an access control list to classify users. Alternatively, the organization may choose to deploy separate systems 10 for each of several groups and combine the results at a "master" level. This deployment also enables an "all-weather" configuration in which geographically dispersed point groups collaborate by communicating primary monitoring responsibilities to groups currently working in standard business hours. System 10 can also be deployed in a corporate hierarchy at the corporate level Each business unit works and supports the roll-to-centralized management function.

The security information/event management system 10 is further described in U.S. Application Serial No. 10/308,415, filed on Dec. 2, 2002, the entire disclosure of which is incorporated herein.

Introduction to the asset model

A manager 14 receives one or more events and analyzes the events to detect the attacks. An event description involves one of the actions of a computer network device (referred to as a "network node"). Exemplary network nodes include laptop or desktop computers, servers (such as email servers, access control servers, and domain name system (DNS) servers), firewalls, routing devices, and intrusion detection. Test systems, virtual private network (VPN) systems, and printers.

In a specific embodiment, an event indicates one or more nodes (eg, the node to which the action is directed ("target node" and/or the node initiated by the action ("source node")). In this embodiment The event includes a reference to one of each node (referred to as a "node reference"). A node reference includes multiple fields, such as Internet Protocol (IP) addresses, network areas, host names, media. Access control (MAC) address and asset identifier (asset ID), (a network area is a network segment, a tag identifies a network area and is used to distinguish private address spaces from each other). An IP address is used to address a network node. Some devices (eg, multi-connection servers) may be addressed via any of a plurality of IP addresses. In this case, each IP address is treated as a Separate network nodes to handle. Therefore, a single device can "place" multiple network nodes.

The asset ID field is used to store a unique identifier assigned to a network node. Do not match (ID). When the manager receives an event for the first time, the asset ID field referenced by a node is an empty field. Later, one of the "asset models" identifiers corresponding to the node is stored in the asset ID field. In a specific embodiment, the ID is used to obtain an asset model corresponding to the network node to which the ID is associated. In another embodiment, the ID is used to determine whether the network node is a member of a particular class (described below). An asset model is a collection of information about a network node. This information may include, for example: the IP address of the node, the host name of the node, the network to which the node belongs, the role of the node within the enterprise, one of the nodes open, and the software installed on the node. (for example, operating systems and applications). In a specific embodiment, an asset model includes a list of known shortcomings or weaknesses of the node, which is referred to as "exposure weakness." A vulnerability is generally defined as a configuration or condition of one of the nodes that may be used to produce an effect that is not what the manufacturer of the node desires.

The manager 14 accesses an asset model of a network node to perform a security analysis. For example, an event can be described as attempting to make use of one or more known weaknesses, referred to as "utilized weaknesses." The manager 14 can determine the vulnerability of the target node's exposure (by accessing the asset model of the node) and then compare it to the utilized vulnerability. If a weak point appears as both an exposed weak point and a used weak point, a threat is detected. Threat detection is further described in U.S. Patent No. 7,260,844, issued on Aug. 21, 2007, the entire disclosure of which is incorporated herein by reference.

As another example, consider a standard within the Federal Information Processing Standard (FIPS) that needs to be based on a node's tolerance for confidentiality. class. An event can describe one of the actions that could result in a confidentiality failure on a particular node. The manager 14 may notice this event and decide how critically confidential the node is (by accessing the asset model of the node). If confidentiality is critical, a ticket can be generated to track the violation.

4. A network node (asset) can be classified to describe its characteristics. One category is implemented as a "group." For example, to specify that a particular node is executing a Windows 2003 server operating system, the node's assets are placed in the group "/AllCategories/OperatingSystems/Microsoft/Windows/2003Server". Categories can be hierarchical. For example, "2003Server" is a subclass of the category "Windows", while the category "Windows," is a subclass of the category "Microsoft", and so on. Another example of a hierarchical category is geographic classification (eg, continent/country/state/region).

Given a node reference and a category, the manager 14 can determine whether the node is a member of the category (ie, belongs to the category). It is also possible to classify an asset group, as well as a network area and a network area group.

Therefore, security analysis involves identifying and accessing an asset module and checking category membership. To perform security analysis on-the-fly (or near-instantaneous), the model identification and access and category checking should also be performed on-the-fly (or near-instantaneous). This is difficult to achieve because thousands of events are generated per minute, and each event indicates one or more node references. For example, one of 5,000 events/second and one of the four node reference/event events yields 20,000 node references/second. For each node reference, identify its asset model and perform several categories of membership checks.

Manager architecture

2 is a high level block diagram of a computer 200 used as a manager 14 of a security information/event management system 10 in accordance with one embodiment. At least one processor 202 coupled to a bus bar 204 is shown. A memory 206, a storage device 208, a keyboard 210, a graphics adapter 212, a pointing device 214, and a network adapter 216 are also coupled to the bus bar 204. In one embodiment, the functionality of the busbar 204 is provided by an interconnected chip set. A display 218 is coupled to the graphics adapter 212.

The storage device 208 is any device capable of storing data, such as a hard disk drive, a compact disk read only memory (CD-ROM), a DVD, or a solid state memory device. The memory 206 stores instructions and data used by the processor 202. The pointing device 214 can be a mouse, trackball or other type of pointing device and is used in conjunction with the keyboard 210 for inputting data into the computer 200. The graphics adapter 212 displays images and other information on the display 218. The network switch 216 couples the computer 200 to a regional or wide area network.

As is known in the art, a computer 200 can have different components and/or other components than those shown in FIG. Additionally, the computer 200 may lack specific graphical components. For example, computer 200, which is used as a manager 14, may lack a keyboard 210, pointing device 214, graphics adapter 212, and/or display 218. In addition, the storage device 208 can be attached to the local and/or remote end of the computer 200 (eg, embodied in a storage area network (SAN)).

A software agent 12 (such as the SmartConnector from ArcSight, Inc. of Cupertino, Calif.) receives information about a network node from a sensor. The agent 12 then processes the message to generate an event. In a In a specific embodiment, an event representation includes a data structure of one or more fields, wherein each field can include a value. The value of a field is determined based on the message received from the sensor. The agent transmits the event to a manager 14 (eg, enterprise security management software from ArcSight) for storage and analysis.

The manager 14 includes a module (not shown) called an event asset parser (EAR). Reviewing an event can include a node reference. The EAR module associates this node reference with its corresponding asset model and marks the node reference with a unique identifier (ID). For example, the EAR module modifies the event by storing the ID in the asset ID field of the node reference (which was previously empty). In one embodiment, an event includes references to four nodes: a network traffic source, a network traffic destination, an agent host, and a sensor host that reports events. For each node reference, the EAR module associates the node reference with its corresponding asset model and marks the node reference with a unique ID.

3 is a high level block diagram of a module within a manager 14 of a security information/event management system 10 in accordance with an embodiment. As shown in FIG. 3, one embodiment of a manager 14 includes an identifier module 300 and a category module 310. In addition to the modules shown in the figures, other embodiments may have different and/or additional modules. For example, the manager 14 can include the modules shown in FIG. 1, but FIG. 3 omits such modules for the sake of brevity. Moreover, the functions may be distributed among the modules in a manner different from that described herein.

The identifier module 300 provides unique knowledge associated with a network node Do not match (ID) related functionality. In a specific embodiment, an ID is based on an integer (eg, a value of one of the original data types "int"). In a specific embodiment, an ID is "local" unique. For example, it is unique within a particular manager 14 but not necessarily unique across multiple managers. In another embodiment, an ID is a Universally Unique Identifier (UUID) or a Globally Unique Identifier (GUID). In this particular embodiment, an ID is "global" unique. For example, it is unique across multiple managers. The amount of memory required to store a UUID or GUID is at least 16 bytes. Storing an integer-based value requires less memory. This memory is more distinct because more than one million IDs may need to be stored in memory at the same time.

In a specific embodiment, the ID is used to obtain an asset model corresponding to one of the network nodes associated with the ID. For example, an asset management module (not shown) maintains asset model information and returns an asset model when accepting queries made using an ID. An asset model is represented, for example, by an object data structure (using an object-oriented stylized language such as Java). In another embodiment, the ID is used to determine whether the network node is a member of a particular category.

In the illustrated embodiment, the identifier module 300 includes a lookup module 320, a management module 330, a gap table 340, and one or more lookup tables 350. The lookup module 320 determines the ID of a network node based on various characteristics of the network node. These features exist in the node reference within the event, as described above. The ID of a particular network node is determined based on the node's IP address, host name, network area, and/or media access control (MAC) address. In one embodiment, the pieces of information are used as index keys for placing one or more lookup data structures (refer to table 350, as described below). If a lookup is successful (for example, finding a value associated with the index key), the value is returned (which is the ID of the asset model of the node).

4 is a flow chart showing one of the methods of determining one of the identifiers associated with a network node in accordance with an embodiment. Information about a network node has been received prior to the start of the method 400. This information includes one or more of the following: the IP address, network area, host name, and MAC address of the node.

A lookup 410 is attempted by using the MAC address of the node. If a successful match is thus generated, the ID 420 is returned. If the MAC lookup does not result in a successful match, then a lookup 430 is attempted by using the node's IP address and network area. If a successful match is thus generated, the ID 420 is returned. If the IP lookup does not result in a successful match, then a lookup 440 is attempted by using the host name and network region of the node. If a successful match is thus generated, the ID 420 is returned. If the host name lookup does not result in a successful match, then a lookup 450 is attempted by using an asset range that covers one of the node's IP locations within the network region of the node. If a successful match is thus generated, the ID 420 is returned. In one embodiment, the order of each review (MAC lookup, IP lookup, host name lookup, and asset range lookup) is configurable.

The lookup module 320 uses the lookup tables 350 to determine the ID of a network node based on various characteristics of the network node. In one embodiment, there are four types of lookup tables 350: IP address/network area lookup table, host name/network area Domain lookup table, MAC address lookup table, and asset scope lookup table. Each lookup table of the lookup tables is populated by the asset management module (described above). IP address / network area view

In one embodiment, an IP address lookup table uses the index key and value of the original data type "int" (integer). One of the index keys used to perform a lookup represents a 32-bit integer representing one of the IP addresses. The value returned by a lookup is the integer ID of the corresponding asset model. Since the IP address is unique within a network area, each network area has its own IP lookup table.

In a specific embodiment, the lookup table is customized and optimized to present lower memory usage and/or high speed. The optimized table can be a hash map or an array.

Figure 5 shows an exemplary data structure for an IP address lookup table. The illustrated data structure includes an open addressed hash map 500 and a direct access array 510. In a conventional implementation of open addressing hash mapping, three arrays are used: one for storing index keys, one for storing values, and one for indicating whether pairs of index keys and values are valid. Here, the index key (IP address) is stored in a single integer array 500 along with the value (ID). In the illustrated embodiment, an index key and its associated values are placed adjacent to each other (e.g., adjacent to one another) in the array for better cache memory locality. In other words, an open addressing hash map is implemented by interleaving an index key array with the value of a value array using an array. Implementing an open addressing hash map by using a single array is well known to those skilled in the art and is described in the Data Structure/Hash Table Wikibook, available at http://en.wikibooks. Org/wiki/Data_Structures/Hash_Tables.

The fixed IP address may not be valid in a network area. In one embodiment, an invalid address is used in a lookup data structure to indicate that the corresponding value (here an ID) is empty.

Alternatively, a direct access array 510 can be used in which each value (here an ID) is stored as an element of the array. The index of the element within the array is determined by the index key (here, an IP address). In a specific embodiment, an index is equal to an offset of one of the IP addresses within a particular address range. For example, consider a network area that includes one of the IP addresses ranging from 192.168.0.100 to 192.168.0.200. The IP address 192.168.0.150 will have an index equal to 50 because its offset is 50 from the lower end of the range. Therefore, its ID is stored in array[50], where array is the name of the array and 50 is placed into the index of the array. In this way, it is not necessary to store an index key. Alternatively, it is converted to an index, which is then used to access a particular element of the array.

Consider another network area and its IP address range (for example, 192.168.0.0 to 192.168.0.255). If the IP address within this range is densely populated (this would be the case), then a direct array is used. This provides a faster lookup when saving the memory, as it is not necessary to explicitly store the IP addresses in the lookup table.

If the IP address is only sparsely populated in a network area, direct array lookups can create a significant memory burden, instead using a hash map. In one embodiment, the internal data structure type for the IP address lookup table is based on the IP address usage (eg, padding density) within the IP address associated with the network region. You can view 510 and hashes in the array as needed. Switch the data structure between 500s (for example, if the IP address fill density changes).

Host name / network area view

Since the host name is unique within a network area, each network area has its own host name IP lookup table. In a specific embodiment, the lookup table is customized and optimized to present lower memory usage and/or high speed.

In a specific embodiment, host name lookup is performed by using two lookup tables. Each lookup table can be implemented as a hash map or an array. Figure 6 shows two lookup tables for performing host name lookups. For simplicity, the lookup tables are illustrated in a column/row format, with each list showing a pair of index keys/values.

A host name is divided into two parts: the machine name and the domain name. For example, the host name "test.arcsight.com" is divided into "test" (machine name) and "arcsight.com" (domain name). A first lookup table 600 uses the index key of the original data type "string" and the value of the original data type "int" (integer). One of the index keys used to perform a lookup represents a string of domain names (illustrated as "DN1"). The value returned by a lookback is an integer reference to one of the second tables 610 associated with the domain name (illustrated as "Ref1"). This avoids wasting memory space by storing multiple copies of the same domain name.

A second lookup table 610 uses the index key and value of the original data type "int" (integer). One of the index keys used to perform a lookup represents an integer of one machine name and one domain name (illustrated as "MN1/DN1") (see below) Exemplary embodiment). The value returned by a lookup is the integer ID of the corresponding asset model (illustrated as "ID1").

In one embodiment, one of the index keys for the second lookup table 610 is an integer reference of the one of the machine names and an integer reference to the domain name (eg, as stored in the domain name table). In one embodiment, a machine name is stored as a UTF-8 (8-bit UCS/Unicode conversion format) byte array for compressed storage. If Java is used, a character is encoded as UTF-16, which requires 2 bytes of memory for each character. If the machine name contains only ASCII characters, UTF-8 encoding requires only 1 byte for each character, which is the case for most of the time. (The DoD Internet Host Table Specification (RFC 952) specifies that a host name should contain only ASCII characters.)

In a conventional implementation of open addressing hash mapping, three arrays are used: one for storing index keys, one for storing values, and one for indicating whether pairs of index keys and values are valid. Here, for the second lookup table 610, an index key (indicating a machine name and an integer of a domain name) and a value (ID) are stored together in a single integer array. An index key and its associated values are placed adjacent to each other (e.g., adjacent to one another) in the array for better cache memory locality. In other words, an open positioning hash map is implemented by interleaving an index key array with the value of a value array using an array.

In one embodiment, the second lookup table 610 is implemented by using an integer array for each table entry (eg, each host name corresponds to an array). This array includes the machine name UTF-8 byte array, machine name miscellaneous Code, domain name reference and association ID. Since the object is not used, the burden associated with it is avoided, further reducing the use of memory. It also improves the locality of the cache memory unit, thereby increasing performance.

In the open addressing hash map, a hash is computed, the item at that point is extracted, and the index key is tested to determine if a single element exists. Here, the domain name is used in conjunction with the first table 600 to obtain the domain name reference. In a specific embodiment, to optimize the index key check, the obtained reference (an integer) is compared to a reference (also an integer) stored in the item. Next, one of the machine names is hashed (an integer, which is calculated as part of the hash calculation for this lookup), compared to the hash (also an integer) stored in the item. Finally, the machine name string is compared to the string stored in the project. The value returned is the integer ID of the asset model associated with the given host name.

MAC address view

The MAC lookup table 600 uses the index key of the original data type "long" (long integer) and the value of the original data type "int" (integer). One of the index keys used to perform a lookup represents a 64-bit integer representing a MAC address. The value returned by a lookup is the integer ID of the corresponding asset model. Since the MAC address is globally unique, only one MAC lookup table is used.

In a specific embodiment, the lookup table is customized and optimized to present lower memory usage and/or high speed. The customized table can be a hash map or an array.

Figure 7 shows an exemplary data structure for a MAC address lookup table. The illustrated data structure is an open addressing hash map 700. Open location miscellaneous In a conventional implementation of mapping, three arrays are used: one for storing index keys, one for storing values, and one for indicating whether pairs of index keys and values are valid. Here, the index key (MAC address) is stored in a single integer array along with the value (ID). An index key and its associated values are placed adjacent to each other (e.g., adjacent to one another) in the array for better cache memory locality. In other words, an open positioning hash map is implemented by interleaving an index key array with the value of a value array using an array.

A specific MAC address may be invalid. In one embodiment, an invalid address is used in a lookup data structure to indicate that the corresponding value (here an ID) is empty.

Asset range review

One of the index keys used to perform a lookup together represents one of the IP address ranges to the IP address. The value returned by a lookup is the integer ID of the corresponding asset model. Since the IP address is unique within a network area, each network area has its own asset range lookup table. Before performing the lookup, the IP address of interest is checked to determine the range of IP addresses that will include the IP address.

The management module 330 tracks which IDs have been assigned to the network node and which IDs have not been assigned. The management module 330 also provides an ID when requested (eg, for association with a new network node). The IDs are established close to each other to minimize the gap therebetween. When a network node (and its associated asset model) is removed from a system, gaps may begin to appear between the IDs used. In a specific embodiment, the management module 330 manages the gap between the IDs as follows: at the time of initial loading, a gap table is created (gap table) 340). An ID is assigned when a new network node is added (and thus a new asset model is created). If there is a gap, one of the existing IDs in a gap is used. If a gap does not exist, a new ID is created and used.

The management module 330 uses the gap table 340 to manage the gaps between the IDs, as described above.

The category module 310 provides functionality related to the category. A review can classify a network node (asset) to describe its characteristics. One category is implemented as a "group." For example, to specify that a particular node is executing a Windows 2003 server operating system, the node's assets are placed in the group "/AllCategories/OperatingSystems/Microsoft/Windows/2003Server". Categories can be hierarchical. For example, "2003Server" is a subclass of the category "Windows", while the category "Windows" is a subclass of the category "Microsoft", and so on. Another example of a hierarchical category is geographic classification (eg, continent/country/state/region). It is also possible to classify an asset group, as well as a network area and a network area group.

In the illustrated embodiment, the category module 310 includes a lookup module 360, a management module 370, category information 380, and update data 390. The lookup module 360 determines whether a particular network node (asset) is a member of a particular category (ie, belonging to a particular category). For example, a question may be "Is this asset a member of this category or any of the subcategories?" To make this decision, the category module 310 uses the category material 380.

The category material 380 uses a Recursive Closure (TC) to model one of the hierarchical and dynamic spaces that can be attached to a classification (characteristic) of an asset model. A TC is basically a non-cyclic graph (DAG), where a link may exist. Between each ancestor (a category or group) and each of the descendants (an asset). The presence of a link indicates that the child asset is a member of the source category or group or a member of any of the categories or groups of the source. The link is built on top of the parent-child link already in the DAG. The existence of such TC links implements O(1) time efficiency to check whether a given child (asset) is one of any given parent (category or group).

Consider the above categories: AllCategories/OperatingSystems/Microsoft/Windows/2003Server. We are interested in knowing whether a network node is performing an operating system or not knowing that the node is performing a general Microsoft operating system (eg, can be of any type). If there is no link between the "Microsoft" category and the node, then a tree walk will have to be performed. For example, a search may begin in the Microsoft category and search for a match between the children. Alternatively, a search may begin with the network node and search upwards. A tree-like search consumes an unpredictable amount of time, and in theory is always better than a complete list (ie, a recursive closure) for a complete list (ie, a recursive closure) between all source categories and all child categories. The review is more expensive. The disadvantage of using a TC is that it requires a lot of information to be stored. For example, the number of ancestor-descendant links is exponentially greater than the number of parent-child links.

The data structure representing the recursive closure will be used for instant reference of 5,000 events per second with 4 nodes per event reference and 100 categories of membership checks per node (corresponding to 2,000,000 checks per second) . If the data structure (for example, the least recently used, ie LRU) When stored in a secondary storage or cached in a conventional manner, the performance of the category check is neither fast nor predictable. In one embodiment, the TC data structure is stored in memory in an indexed manner so that category membership checks can be performed quickly.

In a specific embodiment, the recursive closure is stored in the memory as a set of meta-maps, wherein the one-bit mapping is a one-dimensional array, and each bit stores a Boolean Value. This is similar to a bit map index. Here, a one-bit map corresponds to a particular asset class or group. One of the one-dimensional mappings, 0/1, indicates whether there is a link between the particular asset class/group and an asset. If there are 1 million assets and 1,000 asset classes/groups, you may need 1 million * 1,000 = 1 billion bits of storage. Recall that an asset model is identified by an ID (which is an integer value). In a specific embodiment, this ID is used as an index into one of the recursive closure bit maps.

An asset is generally classified into approximately thirty of a total of 1,000 categories. Therefore, the probability that a particular asset belongs to a particular category is 30/1,000 = 3%. This means that about 3% of the bits in a one-bit map are set (ie, have different values than the other bits). Therefore, a one-bit map will be very sparse. In a specific embodiment, the one-bit mapping is compressed by using a technique such as word-aligned mixing to reduce memory requirements.

When performing a class check, using an uncompressed bit map is faster than a compressed bit map. In a specific embodiment, the bit map system for accepting the more frequently checked categories is stored in an uncompressed form, and the bit map system for accepting the less frequently checked categories is stored as a compressed form. formula. This results in an extremely fast class check for most inspections at a small cost of additional memory requirements, thereby increasing the average class inspection performance.

The management module 370 updates the category information 380 as needed. The asset model can change over time and will update the recursive closure data structure. If a meta-map is compressed, its update includes decompressing it, applying an update, and compressing it again. In a specific embodiment, an update is applied directly to the associated bit map, whether or not it is compressed.

In another embodiment, if a one-bit map is compressed, it is not immediately updated. Alternatively, the update is temporarily stored (in update material 390) and later applied to the same bit map (eg, via a periodic (eg, once per minute)) in conjunction with other updates. Since decompressing and compressing a one-dimensional mapping is time consuming, it is faster to map the bit map once, perform multiple updates, and then compress the bit map. In this particular embodiment, when the request includes a category check of a compressed bit map, the temporary update store (update data 390) is accessed to determine if there are any updates. If the lookup fails in the temporary update store (which is smaller and therefore supports faster lookup), then a lookup is performed on the compressed bit map. If a meta-map is uncompressed, it is immediately updated.

The management module 370 uses the update profile 390 to delay updating the category material 380, as described above.

The above description is intended to illustrate the operation of the preferred embodiments and is not intended to limit the scope of the invention. Therefore, the scope of the invention is limited only by the scope of the following claims. From the above description, those skilled in the art will understand Many variations are covered by the spirit and scope of the invention.

10‧‧‧Security Information/Event Management System

12‧‧‧Agent

14‧‧‧Manager

16‧‧‧Main console

18‧‧‧Rules Engine

20‧‧‧Concentrated event database

22‧‧‧Database Manager

24‧‧‧Notifier

26‧‧‧Agent Manager

28‧‧‧ Knowledge Base

200‧‧‧ computer

202‧‧‧ processor

204‧‧‧ Busbar

206‧‧‧ memory

208‧‧‧Storage device

210‧‧‧ keyboard

212‧‧‧Graphic Adapter

214‧‧‧ pointing device

216‧‧‧Network Adapter

218‧‧‧ display

300‧‧‧identifier module

310‧‧‧Class Module

320‧‧‧Check module

330‧‧‧Management module

340‧‧‧ gap table

350‧‧‧ lookup table

360‧‧‧View Module

370‧‧‧Management module

380‧‧‧Catalogue Information

390‧‧‧Updated information

500‧‧‧Open Addressing Hash Mapping/Integer Array

510‧‧‧Direct access array

600‧‧‧MAC lookup table

610‧‧‧ second look-up form

700‧‧‧Open Addressing Hash Mapping

1 is a high level diagram of one of the environments having a security information/event management system in accordance with an embodiment.

2 is a high level block diagram of a computer used as a manager of a security information/event management system in accordance with one embodiment.

3 is a high level block diagram of a module within a manager of a security information/event management system in accordance with an embodiment.

4 is a flow chart showing one of the methods of determining one of the identifiers associated with a network node in accordance with an embodiment.

Figure 5 shows an exemplary data structure for an IP address lookup table.

Figure 6 shows two lookup tables for performing host name lookups.

Figure 7 shows an exemplary data structure for a MAC address lookup table.

The drawings depict a specific embodiment for purposes of illustration only. It will be readily apparent to those skilled in the art from this description that <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt;

14‧‧‧Manager

300‧‧‧identifier module

310‧‧‧Class Module

320‧‧‧Check module

330‧‧‧Management module

340‧‧‧ gap table

350‧‧‧ lookup table

360‧‧‧View Module

370‧‧‧Management module

380‧‧‧Catalogue Information

390‧‧‧Updated information

Claims (18)

A method for determining a unique identifier associated with a network node, comprising: querying an IP address lookup data structure using one of the Internet Protocol (IP) addresses associated with the network node; Returning the unique identifier associated with the network node; and performing one of the following steps: using the unique identifier returned to obtain an asset model associated with the network node; and using the unique The identifier determines whether the network node is a member of a category. The method of claim 1, wherein the unique identifier associated with the network node is one of the original data type "int" (integer). The method of claim 1, wherein the IP address lookup data structure comprises a table comprising one or more pairs, a pair comprising an IP address associated with a particular network node and the particular network node Associate one of the unique identifiers. The method of claim 3, wherein the IP address associated with the network node is one of the original data type "int" (integer). The method of claim 3, wherein querying the IP address lookup data structure by using the IP address associated with the network node comprises: determining to include a pair of the IP address associated with the network node. The method of claim 3, wherein the table is an open addressing hash map. The method of claim 3, wherein the table is implemented by using only one array One of the open addressing hash maps. The method of claim 1, wherein the IP address lookup data structure comprises an array comprising one or more elements, an element is stored at an index, the element comprising one of the unique associated with the particular network node The identifier is determined by one of the IP addresses associated with the particular network node. The method of claim 8, wherein the querying the IP address query data structure by using the IP address associated with the network node comprises: determining an index according to the IP address associated with the network node. The method of claim 1, wherein the IP address lookup data structure is configured to automatically change from a table-based implementation to an array-based implementation. The method of claim 1, wherein the IP address lookup data structure is configured to automatically change from an array-based implementation to a table-based implementation. The method of claim 1, wherein the determining, by using the returned identifier, whether the network node is a member of the category comprises: identifying a recursive closure, the recursive closure comprising a plurality of source nodes One or more links between a plurality of child nodes, a source node representing a category, a child node representing a network node, and a link indicating a child node being a member of a source node; Returning the unique identifier with the category to query the transfer closure; and returning a Boolean value indicating whether the network node is in the category The member. The method of claim 12, wherein the recursive closure is queried by using the returned unique identifier and the category: determining that one of the sub-nodes associated with the returned unique identifier is associated with the category Whether there is a link between the originating nodes. The method of claim 1, wherein determining whether the network node is a member of the category by using the returned unique identifier comprises: identifying a bitmap mapping associated with the category, the bitmap mapping comprising a plurality of bits, a one-bit value indicating whether a network node is a member of the category; querying the bitmap by using the unique identifier returned; and returning a Boolean value, the cloth The forest value indicates whether the network node is the member of the category. The method of claim 14, wherein the querying the bit map by using the returned unique identifier comprises: identifying by using the returned unique identifier as an index placed in the bit map One bit within the bit map; and returning the value of the identified bit. A method for determining a unique identifier of a network node association, comprising: querying a first lookup table by using a domain name associated with the network node, the first lookup table comprising one or Multiple pairs, one pair containing a domain name associated with a particular network node and one of the second lookup tables The second lookup table includes one or more pairs, one pair of one of the host names associated with the particular network node and one unique identifier associated with the particular network node; associated by using the network node a host name to query the second lookup table; returning the unique identifier associated with the network node; and performing one of the following steps: using the returned unique identifier to obtain an asset associated with the network node The model; and using the unique identifier returned to determine whether the network node is a member of a category. A computer program product for determining a unique identifier associated with a network node, the computer program product comprising a computer readable medium, the computer readable medium including a computer program code for performing a method, the method Including: querying an IP address lookup table by using one of the Internet Protocol (IP) addresses associated with the network node, the IP address lookup table including one or more pairs, and the pair includes a specific network The node associates one of the IP addresses with one of the unique identifiers associated with the particular network node; returns the unique identifier associated with the network node; and performs one of the following steps: using the unique identifier returned To obtain an asset model associated with the network node; and use the unique identifier returned to determine whether the network node is One of the members of a category. An apparatus for determining a unique identifier of a network node association, comprising: a query module configured to associate an Internet Protocol (IP) address by using the network node Querying an IP address lookup table, the IP address lookup table comprising one or more pairs, a pair of unique identifiers associated with the IP address of a particular network node associated with the particular network node; a return module configured to return the unique identifier associated with the network node; and one of the following modules: an asset model module configured to use the returned A unique identifier to obtain an asset model associated with the network node; and a class module configured to use the unique identifier returned to determine whether the network node is a member of a category.