KR20070032312A - Methods, computer program products and data structures for intrusion detection, intrusion response and vulnerability remediation across target computer systems - Google Patents

Abstract

Computer security threat management information is generated by receiving notification of a security threat and / or a notification of a test that detects an intrusion of a computer security threat. A computer-executable TMV is generated from the notification received. TMV can be applied to computer-readable fields that provide identification information about one or more system types that are affected by computer security threats, computer-readable fields that provide deployment level identification information for system types, system types, and deployment levels. Computer-readable, which provides identification of tests to detect intrusions of computer security threats against computer-readable fields, system types, and deployment levels. Field, and a computer-readable field providing identification information of a method for treating a vulnerability governed by exploitation of computer security threats for system type and distribution level. The TMV is sent to the target systems for processing by the target systems.

Description

METHODS, COMPUTER PROGRAM PRODUCTS AND DATA STRUCTURES FOR INTRUSION DETECTION, INTRUSION RESPONSE AND VULNERABILITY REMEDIATION ACROSS TARGET COMPUTER SYSTEMS}

The present invention relates to computer systems, methods, program products and / or data structures, and more particularly to security management systems, methods, program products and / or data structures for computer systems. will be.

Computer systems are widely used for data processing and many other applications. As used herein, a “computer system” refers to an enterprise, application and personal computer systems, ubiquitous computer systems such as personal digital assistants, and home appliances with other primary functions. It encompasses embedded computer systems embedded in other devices.

As information technology continues to evolve at an alarming rate, computer systems are susceptible to more security threats and vulnerabilties. Not only can system administrators be burdened with collecting and maintaining information about new vulnerabilities and patches, but system administrators may have to struggle with determining which patches should be applied to which systems. have. The desire to keep computer systems up to date against known and emerging security threats can create significant problems.

Many vendors and independent developers have sought to create and develop ways that computer system administrators can find the latest vulnerability status for their systems. In particular, vendor programs, utilities, and locally generated scripts have been provided that can reveal specific information about computer programs. Thus, for example, Microsoft has provided a utility called HFNETCK, created by Shavlik that scans host systems for missing patches. Unix systems also have built-in instructions that can enumerate operating system and patch level information. Several databases have also been created, as repositories of information about computer systems, including IP addresses, operating system vendor version, and potential final patches applied.

For example, Miter Corporation (Mitre.org) has published Common Vulner abilities and Exposures (CVEs) that use chronological identification vectors and text strings with free-form text to represent and reveal vulnerabilities. "CVE-2001-0507 + free form text" is an example of CVE. The National Institute of Standards and Technology (NIST) also created the ICAT Metabase, a searchable index of information about computer vulnerabilities. Using CVE names, the ICAT Metabase Vulnerability Indexing Service provides a short description of each vulnerability, a list of features for each of the vulnerabilities (such as the associated attack surface and the likelihood of compromise), a list of vulnerable software names and version numbers, and It provides recommendations and links to patch information. See icat.nist.gove / icat.cfm. Also, in the fourth quarter of 2002, Miter launched the Open Vulnerablity Assessment Language (OVAL) initiative to extend the CVE concept to a common way of testing vulnerabilities.

The Open Web Application Security Project (owasp.org) is an open source community project that develops software tools and knowledge-based documentation to help secure web applications and web services. . The purpose of OWASP's VuInXML project is to develop an open standard data format for describing web application security vulnerabilities. This project focuses on web application security vulnerabilities. This project focuses on building http transactions such as specific headers and requests. See VuInXML Proof of Concept Vision Document, Version 1.1, July 18, 2002.

Introduced for the first time in November 2002, the Patch Authentication and Dissemination Capability (PADC) project, sponsored by the General Service Administration company, the Federal Computer Incident Response Center (FedCIRC), addresses a more common case of application and operating system vulnerabilities. See padc.fedcirc.gov.

The OASIS Consortium (oasis-open.org) has published plans to define a standard way of exchanging information about security vulnerabilities in web services and web applications. See OASIS Members Collaborate to Address Security Vulnerabilities for Web Services and Web Applications, RSA Security Conference, 14 April 2003.

The Vulnerability Intelligent Profiling Engine (VIPE) is based on technology by B2Biscom (b2biscom.it). VIPE includes two elements, products and services. A product is a combination of an inventory and patch management tool that has a central database as its main part, which contains all known vulnerabilities and patches for a large list of products. Other parts of the database are filled with inventory information. A set of scripts has been developed. The service analyzes the inventory, associates the inventory with an existing dictionary of vulnerability vulnerabilities, and provides a knowledge-based approach to accessing vulnerabilities for specific supported operating systems.

Citadel Hercules Automated Vulnerability Remediation from Citadel Security Software (citadel.com) integrates with industry-leading vulnerability assessment tools, allowing administrators to review appropriate remedies and implied vulnerabilities on five different classes of vulnerabilities. Software is provided that provides a console to apply the treatment to the correct system. See Citadel Hercules Automated Vulnerability Remediation Product Brochure, Citadel Security Software, Inc., 2003.

Symantec proposes to compile threat management information into a pay service. See eweek.com/article2/0,4149,1362688,00.asp. DeepSight Alert Services is billed $ 5K annually, as described at enterprisesecurity.symantec.com/products/products.cfm?ProductID=160. Threat Management Services starts at $ 15K annually for every user, as described at enterprisecurity.symantec.com/content/displaypdf.cfm?pdfid=301.

Finally, the "Cassandra" Incident Response Database allows the user to create preserved profiles of services and applications running on the user's networks, conventional (standard configurations) hosts or critical hosts. It is a tool sponsored by the CERIAS Center. Cassandra can then email the user with working-copy vulnerabilities regarding these profiles. See cassandra.cerias.purdue.edu. Queries (including incremental queries) can also be performed live. However, these results may be missing recently discovered vulnerabilities that are not yet available from ICAT, or may be missing vulnerabilities that have not yet been disclosed. Since the content is derived from NIST's ICAT servers, CERIAS also only provides the best delivery of content available from ICAT.

In view of the above, in order for security threat management to determine the applicability of security advisories at present, an operator of the computer system may individually configure security advisories, alerts, and APARs (Authorized Program Analysis Reports). It can be a labor intensive process of screening. The operator then uses research to determine how passive techniques can be used to mitigate the threat or apply treatment.

1 is a block diagram illustrating traditional security threat management techniques. As shown in FIG. 1, new computer vulnerabilities and hacking tools are discovered by computer security professionals 110 in various roles. Similarly, APARs are provided by vendors 120. Computer vulnerabilities, hacking tools, and APARs (commonly called A ³ (Advisories, Alerts, APARs)) are typically researchers in the Computer Emergency Response Team (CERT / CC), SysAdmin, Audit, Network and / or Security (SANS) researchers (130 Is investigated. Threat and vulnerability information is distributed by these agencies primarily through mailing lists 140 subscribed by computer Security Systems Administration (SSA) employees 150. Diligent SSAs can subscribe to a number of mailing lists 140 and, accordingly, frequently receive information that can be duplicated or conflicted. Then, the SSAs carry out individual studies to determine the coping process and how to perform it. Most of the time, they will use Mitre's CVE listings 160 and / or Oval database 170, and / or NIST's ICAT database 180 to manually collect information for countermeasure applications. This can be quite inefficient and expensive. Even commercialized vulnerability management products and services may not substantially improve efficiency.

According to embodiments of the present invention, computer-actionable Threat Management Vectors (TMVs) are generated and responded to detect intrusions and respond across target systems. Some embodiments of TMVs are described in US patent application Ser. No. 10 / 624,344, filed on July 22, 2003, filed by Bardsley et al., Entitled "Systems, Methods and Data Structures for Generating Computer-Actionable Computer Security Threat Management Information." US Patent Application No. 10 / 624,158 filed by Bardsley et al. On July 22 entitled "Systems, Methods and Computer Program Products for Administration of Computer Security Threat Countermeasures to a Computer System," and March 2, 2004. US Patent Application No. 10 / 791,560, filed by Bardsley et al., Entitled " Domain Controlling Systems, Methods and Computer Program Products for Administration of Computer Security Threat Countermeasures to a Domain of Target Computer Systems, " Assigned to the assignee of the invention, all of which are hereby incorporated by reference in their entirety. Applications 10 / 624,344, 10 / 624,158 and 10 / 791,560 will collectively be referred to herein as "prior applications." As described therein, TMV is a first computer-readable field that provides identification information for one or more system types affected by computer security threats, and a second that provides distribution level identification information for that system type. A computer-readable field, and a third computer-readable field providing identification information for a set of possible measures for system type and distribution level. The system type may include a computer operating system type or an application program type.

According to some embodiments of the present invention, computer security threat management information is generated by receiving a notification of a security threat and / or a notification of a test that detects an intrusion of a computer security threat. From the received notification, a computer-actionable TMV is generated. TMV is a computer-readable field that provides identifying information about one or more system types affected by computer security threats, a computer-readable field that provides distribution-level identification information for the system type, and a system type and deployment level. And a computer-readable field providing identification information of the test to detect the intrusion of computer security threats to. The generated TMV is transmitted to the plurality of target systems for processing by the plurality of target systems.

In some embodiments, the TMV further includes a computer-readable field that provides identification information of possible countermeasures for the system type and distribution level. In other embodiments, the TMV provides a computer for providing identification information of a plurality of tests for detecting the intrusion of a computer security threat to a system type and deployment level and / or identification information of a plurality of possible countermeasures for the system type and deployment level. It further includes a readable field.

In other embodiments, the second TMV is generated in response to a notification from the target system that an intrusion of a computer security threat was detected. The second TMV includes a computer-readable field that identifies instructions for removing the intrusion of the detected computer security threat. The second TMV is sent to the target system for processing by the target system.

In still other embodiments a null TMV is generated in response to a notification from the target system that an intrusion of a computer security threat has been detected. The null TMV includes a computer-readable field that identifies that there are no instructions available to eliminate the intrusion of the detected computer security threat. The null TMV is then sent to the target system. Thereafter, a second TMV may be generated in response to receiving the instructions to eliminate the intrusion of the detected computer security threat. The second TMV includes a computer-readable field that identifies instructions for removing the intrusion of the detected computer security threat. The second TMV is sent to the target system for processing.

Computer security threat management information may be processed at the target computer system by receiving a computer-executable TMV at the target system, in accordance with some embodiments of the present invention. The TMV includes a computer-readable field that provides identifying information for the test that detects the intrusion of computer security threats for the system type and distribution level. The test is performed at the target system in response to receiving the TMV.

According to other embodiments, the target system sends a notification that an intrusion of a computer security threat has been detected. The target system then receives a TMV that includes a computer-readable field that identifies instructions for removing the intrusion of the detected computer security threat. The target system then performs instructions to eliminate the intrusion in response to receiving the second TMV.

In other embodiments, in response to sending a notification from the target system that an intrusion has been detected, a null TMV is received that indicates that there are no instructions available to eliminate the intrusion of the detected computer security threat, as described above. . Thereafter, a TMV may be received at the target system that identifies the instructions for removing the intrusion. The instructions are then executed on the target system.

Computer-executable TMVs, in accordance with some embodiments of the present invention, include computer-readable instructions described above that include identification information of a test that detects an intrusion, identification information of a possible countermeasure, and / or identification information of instructions for removing the intrusion. Contains fields. In some embodiments, the TMV may provide identification information of a plurality of tests and / or identification of a plurality of possible countermeasures for system type and deployment level. The TMV can also identify that no instructions are available. In accordance with other embodiments of the present invention, similar systems and computer program products are also provided.

1 is a block diagram illustrating traditional security threat management techniques.

2 is a block diagram of an environment in which computer-executable computer security threat management information may be generated, in accordance with conventional applications.

3 is a flow diagram of operations that may be performed to generate computer-executable security threat management information, in accordance with conventional applications.

4 is an overview of the data structure of a threat management vector (TMV), according to conventional applications.

5 is a block diagram of systems, methods and / or computer program products for generating computer-executable security threat management information, in accordance with conventional applications.

6 is a flow diagram of operations that may be used to generate a threat management vector by a message encoder in accordance with conventional applications.

7-14 illustrate detailed data structures of threat management vectors and sub-vectors, according to conventional applications.

15 is a block diagram of systems, methods and / or computer program products for generating computer-executable computer threat management information, in accordance with conventional applications.

16 is a flow diagram of operations that may be performed to manage computer security threat countermeasures in accordance with conventional applications.

17 is a flowchart of operations that may be performed to manage computer security threat countermeasures, in accordance with conventional applications.

18 is a block diagram of systems, methods and computer program products, in accordance with conventional applications.

19 is a flowchart of operations that may be performed to manage a computer security threat, in accordance with conventional applications.

20-22 illustrate threat management vectors in accordance with embodiments of the present invention as threat management vectors in accordance with embodiments of the present invention undergo a TMV transformation in accordance with prior applications.

FIG. 23 is a flowchart of operations that may be performed for TMV history file maintenance, in accordance with conventional applications. FIG.

24 is a flowchart of operations that may be performed for a Threat Management Information Base (TMIB), in accordance with conventional applications.

25 and 26 are flowcharts of operations that may be performed for TMV induction, in accordance with conventional applications.

27 is a flowchart of operations that may be performed for vulnerability state management, in accordance with conventional applications.

28 is a flow diagram of operations that may be performed for treatment management, in accordance with conventional applications.

29 is a block diagram of systems, methods and computer program products for management of computer security threat countermeasures for a domain of target computer systems, in accordance with conventional applications.

30 and 31 illustrate detailed data structures of threat management vectors and transformed threat management vectors, according to conventional applications.

FIG. 32 illustrates a detailed data structure of threat management vectors and subvectors, including program instance vectors and program instance locations, according to conventional applications.

33A-33C illustrate detailed data structures of threat management vectors, according to conventional applications.

34 and 35 are block diagrams of program instance registration, in accordance with conventional applications.

36 is a flowchart of operations that may be performed for program instance registration, in accordance with conventional applications.

37 is a block diagram of threat management vector refreshing, in accordance with conventional applications.

38 is a flowchart of operations that may be performed for threat management vector refreshing, in accordance with conventional applications.

39 is a block diagram of program instance deregistration, in accordance with conventional applications.

40 is a block diagram of input threat management vector processing, in accordance with conventional applications.

41 is a flowchart of operations that may be performed for input threat management processing, in accordance with conventional applications.

42A and 42B are flow charts of operations that may be performed by a threat management vector issuer and responder for input threat management vector processing, respectively, according to conventional applications.

43 is a block diagram of threat management vector synchronization, in accordance with conventional applications.

44 illustrates a data structure of a countermeasure vector, in accordance with some embodiments of the present invention.

45 illustrates a data structure of countermeasures vector including logical representations, parentheses and / or groups, in accordance with certain embodiments of the present invention.

46 illustrates a data structure of a countermeasure vector, according to other embodiments of the present invention.

47 is a block diagram of a countermeasure staging in accordance with certain embodiments of the present invention.

48 is a block diagram of intrusion detection, in accordance with certain embodiments of the present invention.

49 is a flowchart of operations for intrusion-detected vulnerable state management, in accordance with certain embodiments of the present invention.

50 is a flowchart of operations for intrusion detection, in accordance with certain embodiments of the present invention.

51 illustrates a data structure of a root vulnerability vector, in accordance with conventional applications.

52 illustrates a data structure of a threat management vector, in accordance with embodiments of the present invention.

53 is a block diagram of an intrusion response, in accordance with certain embodiments of the present invention.

54A, 54B, 55, 56A, and 56B are flowcharts of operations for intrusion response, in accordance with various embodiments of the present invention.

57 is a block diagram of intrusion response countermeasure relays, in accordance with certain embodiments of the present invention.

Hereinafter, with reference to the accompanying drawings showing embodiments of the present invention will be described in more detail the present invention. However, the present invention may be embodied in many other forms and, therefore, the present invention should not be construed as limited to the embodiments set forth herein.

Thus, although various modifications and other forms of the invention are possible, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein. However, there is no intention to limit the invention to the particular forms disclosed, but rather, the invention covers all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the claims. You should be able to understand that it is to. Like reference numerals refer to like elements throughout the description of the drawings.

The invention is described below with reference to block diagrams and / or flow diagrams illustrating methods, apparatuses (systems) and / or computer program products according to embodiments of the invention. It will be appreciated that each block of the block diagrams and / or flowchart illustrations and a combination of blocks of the block diagrams and / or flowchart illustrations may be implemented by computer program instructions. Such computer program instructions are provided to a processor of a general purpose computer, a special purpose computer, and / or another programmable data processing device for generating a machine, and thus executed through the processor of the computer and / or other programmable data processing device. The instructions that result generate means for implementing the functions / acts specified in the block diagrams and / or the flowchart block or blocks.

Such computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer readable memory are block diagrams. And / or instructions that implement instructions / implementation of the function / operation specified in the flowchart block or blocks.

In addition, computer program instructions may be loaded into a computer or other programmable data processing apparatus such that a series of operational steps are performed on the computer or other programmable apparatus such that the instructions executed on the computer or other programmable apparatus are executed in block diagrams and / or the like. Or generate a computer-implemented process that provides steps for implementing the functions / acts specified in the flowchart block or blocks.

It should also be noted that in some other implementations, the functions / acts indicated in the blocks may occur out of the order indicated in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently, or, depending on the functionality / acts involved, the blocks may sometimes be executed in the reverse order.

Generating computer-executable computer security threat management information

2 is a block diagram of an environment, in accordance with conventional applications in which computer-executable computer security threat management information may be generated. As shown in FIG. 2, the multiple sources (S) of vulnerability threats and / or APAR information may be a Computer Security Incident Response Team (CSIRT) or other over a network, which may be a LAN and / or WAN including a web. You are connected to a security- responsible server. Sources S may be one or more and / or other sources of sources 110, 120, 130, 160, 170, 180 of FIG. 1. A CSIRT server is a plurality of target computers that can be computer-executable computer security threat management information, which can be one or more enterprise, application, personal, ubiquitous and / or embedded systems that can be connected to CSIRT directly and / or via a network. Transmit to systems T. According to the prior applications, the computer-executable computer security threat management information includes one or more computer-executable Threat Management Vectors (TMVs), which will be described later.

3 is a flow diagram of operations according to conventional applications that may be performed, for example, by a CSIRT server to generate computer-executable computer security threat management information. As shown in FIG. 3, at block 310, a notification of a computer security threat is received. At block 320 a computer-executable TMV is generated from the received notification. Furthermore, in FIG. 4 a description of the TMV will be provided. Next, in block 330 the generated TMV or one type of TMV is transmitted to the plurality of target systems for processing by the plurality of target systems.

4 is an overview of the data structure of a TMV in accordance with conventional applications. Will be elaborated in the following. As shown in FIG. 4, TMV 400 identifies a first computer-readable field 401, a system type, that provides identification information for one or more system types, such as operating system types affected by security threats. A second computer-readable field 402 which provides identification of distribution level for the second computer-readable field 403 which provides identification information on a set of possible measures for system type and distribution level. ). Furthermore, in some embodiments, the TMV includes a fourth computer-readable field 404 and a subsystem type that provide identifying information for one or more subsystem types, such as application program types that are affected by computer security threats. And a fifth computer-readable field 405 providing identification information of a distribution level for the device. In these embodiments, the third computer-readable field 403 also provides identifying information for a set of possible countermeasures for the subsystem type and distribution level in addition to the system type and distribution level. Furthermore, in some embodiments, the TMV is a sixth computer-readable field 406 that identifies a vulnerability specification, also referred to herein as a "root VKey vector," to identify the vulnerability or security threat. Also includes.

5 is a block diagram of systems, methods and computer program products, in accordance with conventional applications, for generating computer-readable security threat management information. As shown in FIG. 5, notification of computer security vulnerability threats or countermeasures against vulnerabilities or threats is provided by the central clearinghouse, also referred to herein as CSIRT 510, from the various sources 110-130 described above. Is received from. Other sources may be used. In CSIRT 510, message encoder 520 converts vulnerabilities, threats, APARs and / or information into a clear computer-interpretable form called TMV via human analysis and / or computer-assisted encoding. The common semantics database 530 establishes and maintains the metadata used by the message encoder 520 to generate the TMV, via human analysis and / or computer-assisted encoding. One example is a set of assigned numbers representing computer operating system names. Message encoder 520 generates a TMV in computer-executable format. For each characteristic vulnerability, threat or countermeasure, the TMV specifies target system components and parameterized countermeasure installation instructions for the automated application. The TMV is then sent to the target systems 540. Target SSAs (550) may recommend interventions and / or specific instructions that may be required to be performed if there is no full automatic intervention. By that, the labor of the person can be reduced drastically.

6 is a flow diagram of operations that may be used to generate a TMV by a message encoder, such as message encoder 520 of FIG. 5. FIG. 6 refers to vulnerability alerts and advisories and patch or other countermeasure information as Threat Management Information (TMI). As shown in block 610, the TMI may originate from security organizations, vendors, proprietary security professionals, and / or other sources. TMI may include, but is not limited to, data about vulnerabilities in operating systems or application programs or software utilities, measures to correct vulnerabilities, or both. Examples of TMI include new or revised security alerts and recommendations from CERT / CC or SANS labs and new or revised patch notifications from vendors.

Referring to FIG. 6, conceptually, TMV generation may be considered a two-stage process. In practice, however, it may be implemented in a single set of integrated operations.

At block 610 of the first stage, the TMI operates as input stimuli for the analysis, qualification and quantification (AQQ) process at block 620. Analysis may involve general analysis and research of inputs for completeness and coherence. Qualification may involve evaluating the accuracy, consistency, source integrity, and validity of information for use in threat management. In addition, entitlement may involve details when testing a proposed patch or script against an operating system, application program, or program utility instance in a laboratory or simulated production environment. Finally, quantification means that all relevant TMIs have a clear representation of a catalog entity called the Threat Management Control Book (TMCB), so that each information component 630 is distinguishable through assigned numbers. To ensure that it is Indeed, the AQQ team can represent the TMANA (threat management assigned number authority) by its authority to create, delete, and ensure the associated integrity of each of the externally assigned number authorities (ANAs) of the TMCB. have.

In some embodiments it may be desirable that all ANs and corresponding information encodings for the complete configuration of the TMV representing the TMI are available in the TMCB. Any TMI that is found not so represented may be formulated and listed by the TMANA as a TMCB at block 640. The TMI categories may include, but are not limited to, vulnerability identification information and specifications, system identification information, system level identification information, subsystem identification information, subsystem level identification information, and countermeasure identification information and specifications.

The second stage may involve systematic encoding of the physical TMV using TMCB content (blocks 650-680) and its subsequent transmission to the target systems for automatic threat management processing (block 690). TMV encoding is as shown in FIG. 6, where each affected system type 652 is identified, and for each of these 662, each affected level 670 is identified and these 672 are identified. For each, cascading nested sequence of encoding operations 650, 660, 670, 680 for a given vulnerability 650 such that all applicable measures 680 are encoded in a machine-readable format. nested sequences). Cascading nested sequences of encoding operations may also be performed for the affected subsystems.

7 illustrates a general form of a TMV in accordance with conventional applications. As described above, the TMV may convert computer opaque information, such as CVE information and / or other information, into precise specifications of vulnerability attributes and countermeasure attributes. The obtained encoding can then be used by the programs to automate the adjustment of characteristic threats to a well-defined set of compensation measures to be applied to specific target computer systems.

As shown in FIG. 7, a TMV according to conventional applications may include a vector header, a VKey such as a CVE key, a pointer to a system vector, a pointer to a subsystem vector, and a VKey description. CVE is used herein as an example of a vulnerability key (VKey), but it will be understood that any other key (s) may be used. It will also be appreciated that the VKey description may be an encyclopedia reference key to a free form text description and / or text description held somewhere, and may be included as an aid available in the vector header. In addition, as shown in FIG. 7, the vector header may include a TMV control field and a vector length field. The VKey field may include the VKey type, VKey length, and VKey value fields. Finally, the VKey description may include a description type, description length, and free form text or may include an array of control fields and encyclopedia reference keys. 8-12 provide detailed descriptions of system vectors, system level vectors, countermeasure vectors, countermeasure metadata and subsystem vectors.

8 illustrates a general form of a system vector according to the prior applications. The system vector identifies the operating system (OS) type (s) to which the vulnerability applies. The system vector may include a vector header and an array and / or linked list of system identifiers corresponding to particular OS types, such as Sun Solaris, AIX, and the like. In addition, as shown in FIG. 8, the vector header may include a control field and a vector length field. The system identifier may include a pointer to a system ID field, a system control field, and a system level vector field. The system control field is used to hold system oriented processing controls. System IDs are globally unique codes that map to specific operating system types. The correspondences to the code values and their traditional system names are held in machine-readable form in a common semantics database called the Threat Management Control Book (TMCB) described below.

9 illustrates the general form of a system level vector. As shown in FIG. 9, a system level vector may include a vector header and an array and / or a linked list of system level identifiers. The vector header may include a control field and a vector length field. The system level identifier may include a level ID field, a system level control field, and a pointer to a countermeasure vector. The system level vector identifies the specific operating system version and distribution levels to which the vulnerability or countermeasure applies. The system level control field is used to hold system level oriented processing controls. Level IDs are system-wide unique codes that map to specific operating system versions and distribution levels. The code values and their correspondence to their traditional product version and distribution names are held in machine-readable form in the TMCB, which will be described later.

10 illustrates a general form of a countermeasure vector according to the prior applications. As shown in FIG. 10, the countermeasure vector may include a vector header and an array of countermeasure data and / or a linked list. The vector header may include a control field and a vector length field. The countermeasure metadata may include a countermeasures (CM) ID, a CM type, a CM control field, and CM parameters. Countermeasure vectors identify specific countermeasures that can be applied to a particular version or distribution level of a particular operating system (system) or application (subsystem) to counteract vulnerabilities. Thus, the countermeasure vector identifies a trace of points in the TMV subspace indicated by the system vector, level vector and / or subsystem vector, subsystem level vector representing the applicable set of countermeasures such as patches. do.

FIG. 11 illustrates the general form of the countermeasure metadata of FIG. 10. Countermeasure metadata provides information used to apply a countermeasure. Referring to FIG. 11, Countermeasure ID (CMID) is a globally unique code that maps to a specific countermeasure, as defined in the TMCB (described below). CM type and CM parameters allow specification of countermeasure installation commands. Examples of CM types include "local", "server", "URL", "binary" or "manual" representing various modes of countermeasure installation. The CM control field is used to hold processing controls associated with countermeasure deployment. Examples of CM parameters include interface parameters to a local or remote patch application service, URLs, built-in countermeasure installation instructions (text or executable program code) and / or metadata representing an encyclopedia reference to the same. It may include. The specific control mechanisms for the installation of the specifications and countermeasures of the CM parameters are a function of the individual countermeasures themselves and need not be described here.

12 is an overview of subsystem vectors. As described above, security vulnerabilities may involve operating systems as well as subsystems such as protocol engines, application programs and utilities. The subsystem vector identifies the subsystems or application types to which the vulnerability applies. It contains an array of system identifiers that correspond to specific software entities, such as Microsoft IIS. The subsystem vector may be structurally identical to the system vector except that it applies to application software that uses the operating system, not the operating system itself. It will also be appreciated that the semantics of countermeasure vector elements may be repeated in the subsystem vector classification.

FIG. 13 illustrates a general form of a TMCB in accordance with conventional applications that may correspond to the common semantics database 530 of FIG. 5. As already described, the TMCB includes an indexing structure containing metadata associated with standard values used for TMV encoding. It enables the conversion of non-standard or bulk information into ambiguous and compact equivalent forms for packaging into TMV. Such data transformations are established by TMANA. In general, the TMCB is a registry of standard values encoded in TMV configurations.

13 illustrates tables that may be held in the TMCB. As shown in FIG. 13, a system table may include a system ID, system name, and system level table fields, and may be indexed by system ID and system name. The system level table may include level ID and version and distribution name fields. The subsystem table may include a subsystem ID, a subsystem name, and a subsystem level table, and may be indexed by the subsystem ID and subsystem name. The Threat Severity Table may include a Severity ID and a Strict Name field, and may be indexed by the Severity ID and Severity Name. The countermeasure table may include a CM ID, CM type and CM name fields, and may be indexed by the CM ID, CM type and CM name fields. However, it will be appreciated that these tables are illustrative only and that other configurations may be provided in other embodiments of the present invention.

FIG. 14 provides a summary of the TMV classifications described in detail in FIGS. 7-12.

As mentioned above, prior applications can integrate human interpretation of threat management information into a single point, establish a clear representation of information using a common semantic information base, and use it for use by an automated threat management system. Generate a suitable computer-executable message unit (TMV). Vulnerable systems can then identify themselves, apply appropriate countermeasures, track their status, and hire SSAs only if "intervention is required."

15 is a block diagram of systems, methods, and computer program products for generating computer-readable computer security threat management information, in accordance with conventional applications. In FIG. 15, the functionality of the message encoder 520 of FIG. 5 is provided by the TMV generator 520 ′, and the functions of the common semantic metadata 530 are the TMANA 530 ′ of the CSIRT or central clearing house 510 ′. Is replaced by

Referring to FIG. 15, the TMV generator 520 ′ converts vulnerability, threat, and APAR information into a clear computer interpretable form, TMV, through human analysis and computer-assisted encoding. TMV generator 520 'refers to the set of standard encodings held by TMANA 530' in the form of TMCB (Figure 13). While the TMANA 530 'retains the TMCB's associated integrity, the actual task of assigning values to standard encodings can be delegated to an external assigned numbers authority (ANA) such as NIST. The TMV in computer-readable format is provided to the target systems 540. For each particular vulnerability, threat or countermeasure, the TMV specifies target system components and parameterized countermeasure installation instructions that allow for automated application of countermeasures in the target computer systems.

In view of the foregoing, some embodiments of the present invention address the need for extensive threat management research and analysis from multiple points, such as each and every SSA 550, to one point, such as the TMV generator 520 '. Can be reduced. This may reduce labor associated with threat management at the operational threat analysis level. Furthermore, through the introduction of standard encodings for its key data, embodiments of the present invention can automate threat management activities in target systems. Furthermore, this may reduce the labor associated with managing threats at operational security maintenance levels.

Managing computer security threat countermeasures for computer systems

16 is a flowchart of operations that may be performed to manage computer security threat countermeasures for a computer system, in accordance with conventional applications. These operations may be performed in a target system, eg, one of the target systems T of FIG. 2 or one of the target systems 540 of FIG. 5 or 15.

Referring now to FIG. 16, at block 1610 a baseline identification of an operating system type and operating system deployment level for a computer system is established. In block 1620, a first field providing identification information for one or more operating system types affected by a computer security threat, a second field providing identification information of an operating system deployment level for the operating system type, and an operating system type and A TMV is received that includes a third field that provides identification of a set of possible countermeasures for the operating system distribution level. In other embodiments, the TMV may include a fourth field providing identification information of one or more application program types affected by the computer security threat and a fifth field providing identification information of a distribution level for the application program type. have. In these embodiments, the third field also provides identification information of a set of possible countermeasures for the application program type and application program distribution level. In still other embodiments, the TMV may include a sixth field that provides identification information of the computer security threat.

Continuing with the description of FIG. 16, at block 1630 whether the TMV identifies an operating system type and an operating system deployment level and / or an application program type and an application program distribution level for a computer system as affected by a computer security threat. A determination is made. If yes, measures identified with the TMV are processed at block 1640. If no, the reception of a new TMV is awaited.

17 is a flowchart of operations that may be performed to manage computer security threat countermeasures, in accordance with conventional applications. Referring to FIG. 17, baseline identification information is set in block 1610, and a TMV is received in block 1620. If a match occurs at block 1630, at block 1710 one or more instance identifiers are added to the TMV to describe multiple instances of an operating system and / or application program mounted on a computer system. Then, when the operating system and / or application program is started in the computer system, measures are processed at block 1640 for instances of the operating system type and operating system distribution level and / or application program type and application program distribution level. Thus, these embodiments of the present invention may contemplate that there may be multiple instances of operating systems and / or application programs in a single computer system.

18 is a block diagram of systems, methods and computer program products according to prior applications. As shown in FIG. 18, based on the TMV input and tightly coupled side data, the target system 1810 may determine itself to be vulnerable to certain threats or require specific countermeasures. Identify, automatically initiate appropriate countermeasures, track status and hire security system administrators 1820 based on “intervention required”.

Still referring to FIG. 18, in the initiation of security management personnel or automatic equivalents, also referred to as the common semantics database 530 of FIG. 5 using standard values from the TMCB 530 of FIG. The Threat Management Information Base (TMIB) constructor 1830 uses the TMV compatible information structure and TMV history file 1840 held by the TMV generator 520 of FIG. 13, also referred to as the message encoder 520 of FIG. Establish baseline identity and vulnerability status of system 1810.

Still referring to FIG. 18, upon receiving a new TMV, the TMV Inductor 1850 checks the TMIB to see if any mounted system / subsystem images are affected. If so, the TMV inducer 1850 removes the TMV of irrelevant TMV subvectors and forwards it to Vulnerability State Manager (VSM) 1860 for processing.

The VSM 1860 incorporates new vulnerability or countermeasure information into the TMIB 1880 and uses state information from the TMIB 1880 to determine if any relevant system or subsystem images are active (if initiated). Call the Remediation Manager 1870 to supervise the application. During treatment, treatment manager 1870 interacts with TMIB 1880 to retain current vulnerability status and countermeasure applications. Similarly, VSM 1860 may call treatment manager 1870 upon initial program load of the system / subsystem. Thus, self-healing capabilities for security threat management in computer systems can be provided.

FIG. 19 is a flowchart of operations that may be performed to manage computer security threat countermeasures for a computer system, in accordance with conventional applications, and will refer to the block diagram of FIG. 18. Referring to FIG. 19, in block 1910 TMIB configuration is performed upon receipt of an installation, configuration, or maintenance stimulus. The TMIB configuration can obtain all conventional countermeasures for the system, also referred to as the TMV history file, so that the system can be provided with up-to-date information about all conventional security threats. The TMIB configuration will be discussed further below. In block 1920 TMV induction is performed in response to a new TMV input stimulus, as described below. In block 1930, the vulnerability state management of block 1930 is performed to allow all TMVs to be processed in response to the TMIB configuration block 1910, the TMV induction block 1920, or the system / subsystem booting or resuming the stimulus. In block 1940 treatment management is performed to process the measures identified in the TMVs. Vulnerability state management 1930 may maintain the conventional state of a computer system even if a processing interrupt or pause stimulus 1960 occurs. After treatment management is performed in block 1940, a new stimulus such as an installation configuration or maintenance stimulus, a TMV input stimulus, a system / subsystem boot / resume stimulus, or a processing interrupt or pause stimulus is queued.

In the following, a TMIB configuration according to the prior applications will be described. TMIB configuration may be performed by TMIB configurator 1830 of FIG. 18 and / or TMIB configuration block 1910 of FIG. 19. The TMIB configuration can build an information structure declaratively specifying the initial and subsequent software configuration and vulnerability status of the target system, so that the TMIB 1880 indicates that the target system is the type of system or subsystem to which the TMV should be directed. It can easily be used for a computational comparison with subsequent inbound TMV to determine whether it is either. This can provide quick recognition for efficiently matching the onboard system / subsystem type and level information with the TMV system / subsystem type and level information. Furthermore, treatment management based on initial TMIB configuration may be substantially the same as subsequent processing for inbound TMVs during steady state operation to allow computational consistency.

In some embodiments, the initial configuration of TMIB 1880 may be computerly equivalent to the configuration derived by processing TMVs with all vulnerability and countermeasure information to establish an initial non-vulnerable state. In other words, historically, all measures identified as related to the system / subsystem being initialized can be applied in bulk mode. Subsequent inbound TMV information can then be integrated into TMIB 1880 by simple calculation means, due to record consistency.

Thus, according to prior applications, the TMV generator 520 may, upon issuance of TMVs, record a history file (TMIB entries) in the form of TMIB entries that represent the history of applicable countermeasures for vulnerabilities applicable to applicable systems and subsystems. 1840). TMIB assembly, construction of TMV history file entries, and TMV derivation operation can all be closely related. In particular, all of these may involve well defined transformations for the TMV structure, as described below.

TMIB generation can occur using a process called " TMV transmutation " described herein with reference to FIGS. 20-22. As shown in FIG. 20, a system vector (for operating systems) or a subsystem vector (for applications) is extracted from the root TMV. Furthermore, the lower system level vector is expanded to the "instance ID" field to represent a specific system instance, such as a host name and / or an IP address. This forms a virgin TMIB structure that identifies the system or subsystem. 20 illustrates the case of a system vector, it will be appreciated that similar classifications may be used for the subsystem vector as well.

The classification shown in FIG. 20 can represent a very complex system. For example, the system illustrated in FIG. 20 has three bootable system types with three available boot images of the first system type, one for each of the three distribution levels of that system type. Machine architectures that support multiple concurrent LPARs may fall into this category. Systems with multiple boot images may be slightly simpler. The simplest systems have a single boot image, as shown in FIG.

As shown in FIG. 22, the root VKey vector is re-chained by replacing the countermeasure vector with a pointer to an array of root VKey vectors and extending each root VKey vector into a countermeasure vector pointer field. This creates the basic structure of the TMV history record, the TMIB fully populated with the VKey, and countermeasure status data, with the derived TMV as shown in FIG. It will be appreciated that Figure 22 illustrates a data structure for a system. However, the structure for the subsystem may be similar. Indeed, TMV conversion may translate TMV from a given language at the transmitter to a given language at the receiver.

23 is a flowchart of operations that may be performed for TMV history file maintenance, in accordance with conventional applications. These operations may be performed by the TMV generator 520 of FIG. 18. Referring to FIG. 23, in block 2310 a TMV History Record (HR) is constructed from a VKey or countermeasure stimulus. In block 2320 HR is retrieved for the affected system or subsystem. If HR is found at block 2330, and if new data replaces HR data at block 2340, HR data is replaced with new data at block 2350. These operations are performed for each affected system / subsystem of the input TMV. If no HR is found in block 2330, a new HR is stored in block 2370. If HR is found at block 2330 but the new data does not replace the HR data, the new data is added to the existing HR data at block 2360.

Referring now to FIG. 24, operations for a TMIB configuration, in accordance with conventional applications, will be described. These operations may be performed by the TMIB configurator 1830 of FIG. 18 and / or the TMIB configuration block 1910 of FIG. 19. Referring now to FIG. 24, in the event of an installation, configuration, or maintenance stimulus, the TMV HR for the system / subsystem being managed is retrieved at block 2410. If HR is found in block 2420, the system / subsystem MIB is updated with TMIB from HR data in block 2430. The update may be performed so as not to compromise existing associated vulnerability status management information for the system / subsystem. If not, at block 2440, the system or subsystem MIB is initialized with an unused TMIB. The operations of blocks 2410-2440 are performed for each of the system and subsystem being managed.

25 and 26 are flow diagrams of operations that may be performed for TMV derivation, in accordance with conventional applications. These operations may be performed by the TMV inductor 1850 of FIG. 18 and / or the TMV induction block 1920 of FIG. 19. Referring now to FIG. 25, in receiving a TMV stimulus, at block 2510, the above-described TMV transformation is performed. In block 2520 the TMIB system / level or subsystem / level vector data is compared with the TMV. If a match is found in block 2530, it is determined that the system / level or subsystem / level that may be vulnerable, identified in the TMV, is loaded. The operations proceed from block 2550 to FIG. 26 to determine the actual vulnerability. On the other hand, if a match is not found at block 2530, then at block 2540, the input TMV is ignored. The operations of blocks 2520, 2530, 2540, and 2550 may be performed for each of the mounted system / level and subsystem / level of the TMIB, regardless of whether they are active. Operation then proceeds to vulnerability status manager at block 2560 which will be described in conjunction with FIG. 27.

Referring now to FIG. 26, at block 2610, TMIB vulnerability / measure vector data for the TMV system or subsystem level is generated in response to the vulnerable system / level or subsystem / level identification of the TMV at block 2550. Is accessed. In block 2620 the TMIB vulnerability / measure vector data is compared with each TMV vulnerability vector. If a match is found in block 2630, and if TMV data replaces TMIB data in block 2640, then in block 2650 TMIB vulnerability / measure data is reset with data from the TMV. On the other hand, if a match is not found at block 2630, new TMIB vulnerability countermeasure vector data from the TMV is added at block 2670. Alternatively, if a match is found but the TMV data does not replace the TMIB data, then at block 2660, the TMV vulnerability / measure vector data may be ignored. The operations at blocks 2620-2670 may be performed for each of the vulnerability vectors of the TMV for the affected system / level or subsystem / level.

27 is a flowchart of operations that may be performed for vulnerability state management, in accordance with conventional applications. These operations may be performed by vulnerability state manager 1860 of FIG. 18 and / or vulnerability state management block 1930 of FIG. 19. Referring now to FIG. 27, in block 2710 TMIB vector data is accessed in response to a TMV induced stimulus or a system / subsystem boot or resume stimulus. At block 2720, the treatment manager is invoked as described in FIG. The operations of blocks 2710 and 2720 indicate for each active system / level and subsystem / level of the TMIB, for each vulnerability vector associated with it, and the status is “applied / verified”. It can be performed for each of the countermeasure vectors associated with the vulnerability that it does not.

Referring now to FIG. 28, operations for treatment management in accordance with conventional applications will be described. These operations may be performed by treatment manager 1870 of FIG. 18 and / or treatment management block 1940 of FIG. 19. Referring to FIG. 28, in response to a countermeasure selection stimulus, at block 2810, countermeasure vector data is accessed. In block 2820 the countermeasure status is checked by checking the CM control field. If verified at block 2930, the countermeasure is ignored at block 2870. If the countermeasure is not verified but is applied at block 2840, the countermeasure is verified and set to a "verified" state. If the countermeasure is not applied at block 2840, the countermeasure is applied at block 2850 and set to the "applied" state. The operations of blocks 2820-2870 can be performed for each countermeasure indicated in the countermeasure vector.

As mentioned above, due to the prior applications, the computer system can be automated (self-healing) to a considerable extent. This can reduce human labor and associated labor costs associated with the application of security patches. Because of the automation features of the prior applications, security patches can be applied more quickly, which can reduce the exposure time and the corresponding total cost associated with recovering from system penetration attempts.

Management of computer security threat countermeasures across domains of target computer systems

In the embodiments described above, the central operating component (sometimes referred to as the TMV generator) is each target system, the information that the systems use to access their vulnerability status and apply the appropriate set of countermeasures with reduced or minimized human intervention. Distribute the vector containing the. Each target system may operate automatically on its input, applying appropriate measures determined by the input and by the current configuration of the target system, and may retain state information regarding the progress of the treatment operations. . Embodiments to be described below may provide a Threat Management Domain Controller (TMDC) that can selectively distribute TMVs to domains of target computer systems. The TMDC is configured to respond to the TMV, process the received TMV for use by the domain of the target computer systems, and send the processed TMV to one or more of the target computer systems in the domain of the target computer systems. Thus, prior applications can improve the operational efficiency of TMV distribution and / or TMV processing in target systems.

29 is a block diagram of domain control systems, methods and / or computer program products for management of computer security threat countermeasures for a domain of target computer systems, in accordance with conventional applications. As shown in FIG. 29, the TMDC 2910 responds to a computer-executable TMV generated by the TMV generator 520. TMDC 2910 processes the received TMV for use by domain 2920 of target computer systems 540 and processes the processed TMVs in domain 2920 of target computer systems 540. And transmit to one or more of the fields 540.

Continuing with the description of FIG. 29, the TMDC 2910 can reside in one or more enterprise, application, personal, ubiquitous and / or embedded computer systems 2900 and have a TMV generator 520 and / or domain 2920. May operate at least in part on the same computer system 510 executing one or more of the target systems 540 of. TMDC 2910 operates within an administrative domain 2920 of a collection of target systems 540. TMDC 2910 may arbitrate between TMV generator 520 and target computer systems 540. In some embodiments, the TMDC can reduce or eliminate the need for the TMV generator 520 to retain knowledge of the uniqueness, configurations, and / or operating state of the target computer system. In some embodiments, TMDC 2910 can enhance or optimize the use of bandwidth used for TMV transmission and / or network infrastructure components for TMV transmission. In some embodiments, TMDC 2910 can reduce or minimize I / O subsystem, buffer storage space, and / or CPU usage for processing TMVs in target systems 540. Furthermore, in some embodiments, TMDC 2910 can provide a central source for target system program instance inventory information.

In some embodiments, rather than transmitting TMVs individually to each target system 540, the TMV generator 520 transmits TMVs to one or more TMDCs 2910. Each TMDC may then reliably deliver to each of the target computer systems 540 of its domain 2920, only those TMV elements that may be suitable for a particular target system environment. This capability may be provided based at least in part on instantiation of real or near real time replicas of TMIB data 2930 associated with each target system 540 at the TMDC. have. In addition, while FIG. 29 illustrates a single TMDC 2910 and four target systems AD, other embodiments provide multiple TMDCs 2910, each of which may be associated with one or more target systems 540. It will also be appreciated that it may.

As noted above, according to the prior applications, the TMDC is configured to process a received TMV for use by the domain of the target computer systems, and to process the processed TMV in one or more of the target computer systems in the domain of the target computer systems. Is configured to transmit. In some embodiments, if a TMV is applied to one or more of the target computer systems, this processing and transmission is performed by selectively transmitting the received TMV to one or more of the target computer systems. In other embodiments, this processing and transmission is provided by selectively transmitting selected TMV fields of the received TMV to one or more of the target computer systems. In still other embodiments, this processing and transmission is performed by converting the received TMV into a format compatible with the domain of the target systems. In still other embodiments, this processing and transmission generates a Program Instance (PI) vector identifying a program instance in a selected one of the target computer systems, and converts the TMV containing the PI vector into a selected one of the target computer systems. By transmitting. In still other embodiments, this processing and transmission is performed by transmitting TMVs when the program instance is available that was not previously available to the program instance in the target computer system because the program instance is unavailable. In still other embodiments, this processing and transmission is provided by storing the TMV until the TMV is removed from the TMV after it has been provided to all program instances in the domain of the target computer systems. In the following, these various embodiments will be described further.

In the following, conversion of TMV by TMDC according to some embodiments of the present invention will be described. In prior applications, the TMV generator has generated a TMV form that can be optimized to represent information in the form most suitable for calculation by the transmitter. The target systems receiving the TMVs then performed a “transformation” on the input to produce a TMV form that can be optimized to represent information in a form that is most suitable for computation by the receiver, which is the target system itself.

In comparison, according to other embodiments of the prior applications, TMV conversion is performed by TMDC 2910 on behalf of target systems 540 in its domain 2920. The transformed TMV can be extended to inventory management oriented data structures, for example by specialization of the "instance ID" field of the transformed TMV, which has been described in the prior applications. This TMV data structure can be used to regulate the installation of countermeasures in target computer systems by both TMDC and target systems in its domain in a coordinated manner. As part of its therapeutic function, which may be possible by replicating portions of TMIBs 1880 from target systems to TMIB '2930 at TMDC 2910, TMDC 2910 may be associated with a particular target system. Individualize the TMV contents transmitted to each target system 540 so that only relevant TMV data elements can be received by such target system.

30 illustrates the overall classification of the TMV, which has been described in detail in the prior applications. In FIG. 30, some vector field names are simplified and vector control fields are designated as "CF". Furthermore, the root vulnerability vector has also been referred to as "root CVE vector" in prior applications.

As also described in the prior applications, the target systems performed a transformation on the TMV to produce a form that can be optimized to represent information in a form that is most suitable for calculation by the receiver. 31 illustrates a classification for a transformed TMV of prior applications. Again, some vector field names are simplified and the vector control fields are designated as "CF".

In the following, generation and use of a PI vector according to the prior applications will be described. In prior applications, the contents of the "instance ID" field of the system level vector and subsystem level vector shown in FIGS. 31 to 20 as well as FIG. 31 provide a pointer to the PI vector. This pointer is referred to herein as a PI locator. PI locators and PI vectors are shown in FIG. 32. However, it will be appreciated that in other embodiments, the PI locator and / or PI vector may use an existing TMV field that is not an “instance ID” and / or may use a new TMV field.

The PI vector is a system or subsystem type and level of program instances, local addresses for routing information and program controls to program instances in each target system, and network routing TMV data to target systems in the management domain of the TMDC. Is a data structure that identifies a global address. For a given system / subsystem and level, there may be multiple PI vector components, each representing a particular instance of that type of onboard program in the target system environment. PI vectors may be instantiated and constructed as described below.

In the following, for tracking the TMVs processed by the TMDC, according to the prior applications and for transmitting the TMVs when the program instance is available, the TMVs were not available so that they were not first sent to the program instance in the target computer system. The generation and use of TMV Generation Numbers (TMVGNs) for controlling will be described. In particular, it may be common to have periods in which specific PIs of the target systems or their PIs are unavailable. Examples include the period between the initial configuration of the target system PI and the period before the Initial Program Load (IPL) and the IPLs of the PIs while the PI is "powered off". During these periods, it may be impossible to expect to be able to deliver TMVs directly to PIs, whereby while TMVs are generated and distributed by the TMV generator (TMVG) but not received by the target system PIs Gaps may result in time.

In order for the scope of these gaps to be known and determined accurately when the availability of such target system PIs is reestablished, prior applications may provide a data structure called TMVGN. TMVGN is initially instantiated with a TMV history file with an initial value equal to zero. Each time a TMV is generated by TMVG, the current TMVGN is retrieved from the TMV history file and its value is incremented by +1, for example. The new TMVGN is recorded in the TMV root vulnerability vector for transmission in the TMV. The new TMVGN also replaces the TMV history file (TMVGN) when new TMV data is incorporated into the TMV history file. When a PI is constructed and its PI vector component is instantiated in the target system TMIB according to the prior applications, the PI vector component is expanded with the TMVGN field. The TMVGN associated with the TMV history file data used for the configuration operation is stored in the TMVGN field. Thus, with such TMVGN maintenance, each target system PI can know exactly which TMVs are "missing" while it is unavailable and can fill the target system TMIBs with missing information as the target system PIs become available. .

33A-33C summarize the impact of TMVGN configuration on related data structures, according to conventional applications. As described above, a global scope TMVGN field is added to the entire TMV history file. The TMVGN field is added to the root vulnerability vector, as shown in FIG. 33A. The transformed TMVs are also shown in FIG. 33B. TMVGN moves with the vulnerability vector of the transformed structure as also shown in FIG. 33B. Finally, as shown in FIG. 33C, a field representing the TMVGN last known to the PI is added to the PI vector.

The following describes Domain Store and Forward Repositories (DSFRs), according to the prior applications, which are configured to store the TMV and then remove the TMV until the TMV is provided to all program instances in the domain of the target computer systems. Will be. Assuming the target systems already have the ability to register their PI inventory and TMVs integrated into each of the PI TMIBs described below, the TMDC will not be received by the target systems of the TMDCs, although some TMVs were generated by the central TMV generator. You can see exactly if you did not. DSFR provides a mechanism for constructing this knowledge. In general, in a suitable network topology there is a certain point in time where the presence of a TMDC "leads" target systems in its domain, i.e., a point in the sequence of TMV occurrences. Another way to describe this is that in its TMIB, there is no target system in the domain with a TMNGN larger than the highest TMNGN known to the TMDC.

Thus, for well-behaved behavior within a stable threat management domain, the TMDC may, at any given point in time, have its occurrence number (TMVGN) configured at the "latest" target system PIs in its domain (not available). It may only have TMVs greater than the highest TMVGN (either last constructed or last contacted after time). Otherwise, the TMDC may have TMVs whose TMVGN is less than or equal to those known by any target system PI in its domain, but, as described in the prior applications, the target systems always reach the time of configuration operations. Since it can be configured to have all TMVs generated up to, it will be unnecessary information.

Thus, in the prior applications, the DSFR is such that each of the TMVs received from the TMNG by the TMDC is listed there until its TMVGN is below the lowest TMVGN reported by the target system PIs registered in its domain. Is provided. The purge point may be defined as such TMVGN meets quality criteria. Thus, the point of removal can provide an efficient system to keep the size of the DSFR small. Thus, the DFSR can be considered as a subset of the TMV history file that contains all the TMV data whose TMVGNs are greater than the time of removal. DSFR is illustrated as TMV storage & delivery in 2940 of FIG. 29.

In the following, PI registration according to the prior applications will be described. According to some embodiments, one or more of the target systems includes a plurality of PIs and the target system is configured to register the plurality of PIs with the TMDC. In some embodiments, each of the PIs itself is configured to register with the TMDC. In other embodiments, the target system itself is configured to register a plurality of PIs of the target system with the TMDC.

More specifically, within a given threat management domain, the TMDC may have a known address, such as an IP address host name and / or another address. The address may be known to the target systems, for example, during the target system configuration process already described. At the first convenient point of time, the PIs of each of the target systems in the threat management domain are registered with the TMDC, for example through an assigned service port. A “PI Registration Request” Protocol Data Unit (PDU) is sent to the TMDC and, accordingly, for each PI in the target system, its system containing system / subsystem vectors, system / subsystem level vectors and PI vectors. The TMIB portion is reported to the TMDC and stored by the TMDC in TMIB replicas (TMIB ') 2930 representing the registration information. According to the prior applications, registration can be controlled in at least two ways: In some embodiments, program instances are responsible for establishing a session with a TMDC and transmitting their TMIB information, for example, during a program initialization sequence. You can register yourself. Alternatively, a target system control program or system running for PIs in its environment may establish a session with the TMDC and progressively register all of its PIs.

34 is a block diagram of a PI registration in accordance with conventional applications. As shown in FIG. 34, two simple (single PI) target systems 540, along with their last known TMVGN, display their PI for a particular system / subsystem type and level TMDC 2910. Register each at). The information is then stored in a TMIB replica 2930 held by the TMDC. In FIG. 34, note that TMIB '(A) represents a set of TMIB' (PI) associated with the target system A. FIG.

To complete the registration, the TMDC is responsible for any system / subsystem type and level associated with the original request data expanded with the requested vulnerability / measure information, that is, TMVGN greater than the TMVGN reported by the target system during registration. Returns a "Registration Response PDU" containing the vulnerability vectors. When incorporating return vulnerability / measure information (if present), the target system returns a "PI Registration Acknowledgment PDU" containing the highest TMVGN of the newly integrated information. The TMDC then updates its TMIB '(A) with a positive response TMVGN. FIG. 35 illustrates a registration sequence for the embodiments illustrated in FIG. 34. PDUs are transmitted in the sequence shown by reference numerals 3510-3530 in FIG. 36 is a flowchart of operations that may be performed for PI registration, in accordance with conventional applications.

In the following, TMV refreshing according to the prior applications will be described. As described above in connection with PI registration with the TMDC, the TMDC may use a DSFR "removal time" to reduce or minimize the physical size of the DSFR. Prior applications may provide a TMV refresh protocol for controlling the refreshing of TMVs.

1. Under the TMV refresh protocol, there may be excessive time between the configuration of the target system PIs and their initial registration with the TMDC. In such cases, the highest TMVGN incorporated by the configuration process may be as low as a value greater than one that can represent a gap in TMV information readily available to the TMDC for the value used for PI registration. In such cases, according to the prior applications, the target system registration process may be interrupted while the TMDC applies the TMV refresh protocol to the TMVG to obtain missing TMV information.

2. PDUs are exchanged between TMDC and TMVG as illustrated in FIG. 37. The "TMV Refresh Request" PDU is a request ID for correlation of the response, the lowest TMVGN known to the TMDC, the PI registration information of the target system including the system / subsystem types and levels being registered, and the PI vector. Include them. These vectors also include the highest TMVGN known by the target system PI for each of the system / subsystem types and levels being registered. In its "TMV Refresh Response" PDU, TMVG applies to each of the system-level vectors of the requesting PDU a vulnerability that is applicable to system types and levels whose TMVGN is larger than reported for PI but smaller than reported for TMDC. Fill in the information gap by attaching vulnerability vectors that represent them. Upon receipt of the response, the TMDC may complete the PI registration by incorporating the refresh information into the PI Registration Response PDU. Thus, FIG. 37 illustrates the PI registration protocol with the TMV refresh protocol included. The message flow may proceed as indicated by 3710-3750 of FIG. 37.

3. FIG. 38 is a flowchart of operations that may be performed to provide TMV refresh in accordance with conventional applications. As shown in FIG. 38, to establish a TMV refresh, the logic of FIG. 38 is inserted into junction A of the flowchart of FIG. 36. In FIG. 38, TMVGN (L, H) means a TMVGN pair representing the lowest (L) and highest (H) of the range.

4. In the following, PI recalibration according to the prior applications will be described. It has already been described that the PIs themselves can start registration or registration can be performed by the target system control program or system for PIs within its control range. The same may generally apply to exchanges between TMIBs, PIs and TMDC. Throughout the process involved in PI registration, certain PIs may not be available (hence their TMIBs may not be accessible to the TMDC and the TMDC may not be able to access the PI TMIB). The PI may be paused (eg, between IPLs) or the entire target system may be unavailable.

5. During such time periods, the TMDC may continue to receive TMVs related to the PI, and may think that distribution of such new information to the target system PI is temporarily prohibited. By DFSR, the TMDC is equipped to withhold delivery of TMVs to PI TMIBs until they are subsequently available.

6. When such target systems or PIs are subsequently available, they may need to be recalibrated with new threat management information by delivering them all relevant TMVs received by the TMDC during their unavailable period. .

7. According to the prior applications, PI recalibration can be realized substantially the same as PI registration, except that TMDC may already own a TMIB 'representing the PI when registration occurs. Thus, PI recalibration can be defined as a PI registration where the TMDC owns an existing TMIB 'for the PI. The ultimate effect may be that the PI receives all of the relevant TMVs missing during its unavailable period.

8. In the following, PI deregistration according to the prior applications will be described. In particular, certain PIs of target systems may be considered to be uninstalled or permanently removed from the target system-operating environment. Such an operation may naturally involve removing the TMIB of the PI from the target system. According to the prior applications, PI deregistration may be performed concurrently with PI removal. PI deregistration can completely remove knowledge of the PI from TMDC's information base.

9. Figure 39 illustrates an example of PI deregistration. During PI (A1) removal from target system A, the PI or target system sends a “PI Deregistration Request” PDU to the TMDC as shown in 3910 (in any case). Upon receipt, the TMDC destroys that portion of its TMIB 'for the target system A representing the designated PI, as shown at 3920. The TMDC then returns a "PI Deregistration Response" PDU to the target system A, as shown by 3930, indicating that deregistration is complete. Upon receiving a response at the target system, the TMIB representing the PI being removed is destroyed as shown at 3940.

10. In the following, input TMV processing according to the prior applications will be described. Input TMV processing may incorporate some or all of the various embodiments described above. In particular, according to prior applications, TMDCs that are not target systems receive TMVs. Within each threat management domain, TMDCs target processed TMVs in their domains, for example, customized to allow improved target system CPU and / or buffer usage and / or to allow enhanced network usage within the domain. Deliver to systems In order to realize this potential efficiency, in addition to the preparations described above, the prior applications may also include the following operations. These operations are shown as 4910-4960 in FIG. 40 and described as follows.

11. The "TMV transformation" of "TMV induction" is removed from the target systems and replaced by a similar or identical TMV induction associated with the TMDC at 4910 so that the transformation is only once within the threat management domain, not multiple times throughout the target system population. Is performed. At 4920 following the TMV conversion, the TMV content is integrated into the DSFR and the TMVGN of the DSFRs is updated to reflect the new input. At 4930, for each target system in its domain, the TMDC queries the PI system / subsystem and level information in each TMIB 'for each target system to match the corresponding vector components of the transformed input TMV. Find. For each PI that is found to match the comparison criteria, at 4940 an individualized and transformed TMV containing only the system / subsystem and level vectors corresponding to the matching criteria, the vulnerability vector and the countermeasure vector is replicated from the TMV.

12. The TMV is sent to the target system PI at 4950 using the routing information supplied by the target system during the PI registration described above. If a TMV derivator for the PI is available, it acknowledges the reception at the PDU containing the receiving TMVGN. Otherwise, the TMV distribution is self corrected and will be realized as a result of the PI recalibration when the PI becomes available again, in accordance with 4920 and the previously described embodiments of the present invention. When all of the removable and available PIs in the domain have been serviced, the translated input TMV is destroyed at 4960. In FIG. 40, note that the target system A has one PI A1 and that it is affected by the input TMV content. Target system B has two PIs B1 & B2, all of which are affected by the input TMV content. Finally, the target system C also has two PIs (Cl & C2), but none of them are affected by the input TMV content.

13. FIG. 41 is a flowchart of operations for input TMV processing described in connection with FIG. 40. 42A is a flowchart of input TMV processing by a TMV issuer. 42B is a flowchart of TMV processing by a TMV responder.

14. Finally, TMV synchronization according to the prior applications will be described. In particular, prior applications generally assume that the TMDC will have a secure TCP / IP (or other) session with the TMVG, but it is contemplated that it may be disabled or unavailable for certain periods of time, such as a session. In certain situations, this may result in TMDCs missing any TMV or sequence of TMVs generated by the TMVG. In other words, TMDC and TMVG may be asynchronous. In order to accommodate such a situation, prior applications disclose that if a TMDC receives a TMV with a TMVGN exceeding the TMVGN for the DSFR of the TMDC by a value greater than 1, according to the following preparations and as shown in FIG. 43, A TMDC may be provided that initiates "TMVGN Synchronization" to obtain missing TMVs.

15. At 4310, a "Sync Request" PDU is defined that includes a "TMVGN Start" field and a "TMVGN End" field. These indicate the TMVGN + 1 from the DSFR and the TMVGN value-1 from the TMV, respectively, which caused the TMDC to detect disruption of synchronization. Accordingly, at 4320, TVMG initiates a gradual sequence of TMVs up to the requesting TMDC representing the range of TMVGNs specified in the request by reconstructing the TMVs from its history file.

16. Due to the fact that certain TMVs "supersede" previous TMVs, certain TMVGNs of the history sequence will actually be missed due to their obsolescence. For such cases, while meeting a given synchronization request PDU, the TMVG will generate one or more "null" TMVs indicating that the TMVGN should be ignored. A null TMV may be indicated in the appropriate control field of the root vulnerability vector (and / or by the absence of lower level vectors), and the TMVGN field of the vector indicates that the TMVGN is to be ignored. Other fields may be deprecated.

17. Accordingly, prior applications may provide a threat management domain controller that intervenes between a TMV generator and one or more domains of target computer systems. By providing a multi-layered threat management architecture, prior applications can improve or maximize scalability. Overall resource requirements, including network bandwidth and target system CPU and buffer usage, can be reduced and / or minimized. Reliable delivery of feasible threat management information to target systems can be enhanced. Furthermore, the need for labor intensive tasks can be reduced or eliminated. In particular, administrator-driven initial configuration of vulnerability inventory for target systems may be reduced or eliminated. TMVGNs can also be used to represent a form of time correction, i.e., clock scales in a threat management time continuum.

18. Prior applications can improve or optimize the information flow in that each target system can receive only the information it actually needs only when it is needed. Furthermore, computational efficiency can be provided. In addition, conventional applications are naturally self-correcting. The "removal time" configuration can reduce or minimize the storage space for TMV data in the TMDC. A "null TMV" configuration may have a time continuity. Finally, due to the convention of setting TMVGN to zero at initial registration, the system can automatically configure target systems with historical threat management information associated with them, which requires human intervention for initial configuration of the target system vulnerability inventory. May be substituted and may reduce or eliminate significant operational cost factors in implementation.

Intrusion Detection and Response Across Target Computer Systems

During the implementation operation of the prior applications, countermeasure vectors (CVs) are installed for appropriate systems and / or subsystems, such as PIs, and the treatments they specify are applied. These treatments can reduce or negate PI exposure to associated vulnerabilities (identified by the associated vulnerability vector).

However, in applying a measure or set of measures for a PI, the associated vulnerability results in a compromise of the PI, which may have been exploited by accident or intentionally. This will be called "invasion". In such cases, by themselves, the measures associated with invalidating the PI exposure to the vulnerability may be an almost irrelevant utility.

Some embodiments of the present invention may treat the vulnerability and may, in a coordinated manner, thwart and eradicate intrusions. In particular, it is common for intrusions to establish evidence of their existence. Although intrusions can disguise or attempt to disguise such evidence, there are usually techniques that can be used to penetrate such camouflage. For example, in a UNIX-based system, an intrusion can disguise its running processes by first replacing the "ps" command (which displays running processes). However, intrusion processes can be exposed if countermeasures in the form of an intact instance of the ps command can be implemented.

Some embodiments of the invention may deal with situations that may detect that a vulnerability has been exploited before its treatment is applied. Thus, some embodiments of the present invention, in addition to the ability to treat vulnerabilities established by prior applications, include systems, methods, and systems that can automate the detection and treatment of intrusions in systems and / or subsystems such as PI. Computer program products and / or data structures.

Some embodiments of the present invention describe extensions to the structure of TMVs introduced by prior applications in addition to and / or with the Vulnerability Remediation (VR) capability implemented by prior applications. ID "and" Intrusion Response (IR) ". In addition, some embodiments of the present invention also provide for the simultaneous operation of these mechanisms across a set of target computer systems.

Accordingly, some embodiments of the present invention include intrusion detection vectors containing the content of a countermeasure vector introduced by prior applications, including one or more tests for evidence of effective exploitation of the vulnerability identified by the vulnerability vector of the TMV. It can be specialized to incorporate multiple classes of functionality. Intrusion response vectors convey instructions for blocking and eliminating elements associated with an intrusion introduced by the exploit. Such elements may be detected by an intrusion detection vector associated with the vulnerability identified by the vulnerability vector of the TMV. Finally, vulnerability treatment vectors may generally be similar to the countermeasure vector specified in the prior applications. Vulnerability treatment vectors carry instructions for the treatment of the environments and characteristics identified as constituting the vulnerability identified by the vulnerability vector of the TMV.

Thus, a computer-executable TMV in accordance with some embodiments of the present invention is a computer-readable field that provides identification information for one or more system types affected by computer security threats, distribution level identification information for system types. It may include a computer-readable field for providing a computer-readable field for providing identification information of the test for detecting the intrusion of computer security threats for the system type and distribution level. Such TMVs may also be referred to herein as intrusion detection vectors. Other TMVs in accordance with embodiments of the present invention include a computer-readable field that identifies instructions for removing the intrusion of a detected computer security threat. These embodiments are referred to herein as intrusion response vectors. Finally, in still other embodiments, the computer-readable field also provides identifying information of possible countermeasures for the system type and distribution level. These embodiments may be referred to herein as vulnerability treatment vectors.

FIG. 44 illustrates a technique that may be used to distinguish countermeasure classes using the "control field" of the countermeasure vector. The countermeasure classes should not be confused with the countermeasure type (CM type) used to indicate the syntax and semantics of the countermeasure parameters (CM parameters) in the countermeasure vector component.

Countermeasure bracketing allows the delivery of a plurality of logically different classes of countermeasure vectors in a single TMV transmission. One way to logically express countermeasure bracketing is shown below. As shown below, there are two parentheses. The first parenthesis conveys a single measure CM1 and the second parenthesis conveys a choice between the two sequential measures CM2, CM3 and the other CM4. Within parentheses, round brackets () are used to indicate a logical group of measures.

[(CM1)] [(CM2 & CM3) │ (CM4)]

The above example may represent a countermeasure vector including an intrusion detection (ID) countermeasure bracket [(CM1)]. If the detection result is negative, as indicated in FIG. (CM4) is allowed. Note that the terms "unit brackets" and "unit groups" in Figure 45 refer to parentheses or groups, each containing a single countermeasure specification. Be careful.

Countermeasure bracketing allows delivery of a plurality of logically different classes of countermeasure vectors in a single TMV transmission, as shown in FIG. 46.

The following diagram shows an example of countermeasure vector parsing and logic control mechanism implementing the countermeasure bracketing method.

Function description of CM vector components BB CM class LE EB BG EG Syntax error (no parentheses begin with boolean) One ANY Not you * * * Unit Bracket Specification One ANY Board One * * Syntax error (the beginning of parentheses must begin with a group) One ANY Board 0 0 * Starting Parenthesis-Unit Group Specification One ANY Board 0 One One Starting parenthesis-starting group One ANY Board 0 One 0 Middle brackets-starting group 0 ANY = AND / OR 0 One 0 Middle parentheses-middle group 0 ANY = AND / OR 0 0 0 Middle parenthesis-end group 0 ANY = AND / OR 0 0 One Middle Brackets-Unit Group Specification 0 ANY = AND / OR 0 One One Syntax error (the end of parentheses must end with a group) 0 ANY = AND / OR One * 0 End Parenthesis-Unit Group Specification 0 ANY = AND / OR One One One End bracket-end group 0 ANY = AND / OR One 0 One

In the following, countermeasure staging according to certain embodiments of the present invention will be described. In particular, some embodiments of the present invention can extend the TMV data structure to include multiple (multiple) countermeasure vectors. In addition to the "Vulnerability Remediation Countermeasures (VRC)" generally introduced by prior applications, TMVs may also carry "Intrusion Detection Countermesures" (IDC) brackets and "Intrusion Response Countermeasures" (IRC) brackets.

If the exploit for a given vulnerability has a "footprint" associated with it-some way to detect the penetration of the target system PI by the exploit, the IDC parentheses pass instructions to test such evidence, and the IRC The parentheses convey instructions for blocking the exploit and removing its footprint, and in some embodiments for treating any incidental damage.

It will be appreciated that PIs with vulnerabilities will generally not be exploited, so they may not need to receive IR measures at first. "Replace measure" may provide transmission by the TMV generator component in IRC brackets for intermediate storage in its DSFR by the TMDC. The remaining TMV payload can be treated as the target payload, as in prior applications.

FIG. 47 illustrates countermeasure replacement for vulnerabilities affecting a single PI type and level, followed by parentheses of ID countermeasures, parentheses of IR countermeasures, and parentheses of VR countermeasures. As shown in FIG. 47, the TMV generator sends a TMV PDU 4710 to the domain controller 2910 ′. Domain controller 2910 'translates the input TMV and adds content to its DSFR 2940. Upon identification of the affected PI in its domain, domain controller 2910 'sends a TMV (-IR countermeasures) to the target system, which responds with a TMV ACK PDU at 4730. It will be appreciated that in other embodiments TMDC 2910 'need not be used for these operations. Further, in other embodiments, TMDC 2910 'and / or other functionality may deliver the overall CM payloads (all parentheses) to target system PIs upon initial delivery of the transformed TMV. This may be less efficient, depending on the likelihood that the target PIs of the domain have already been compromised.

In certain situations, it may be the case that upon receipt of a TMV PDU, the target system PI has already been infiltrated and compromised by an exploit targeting an associated vulnerability (identified by the TMV PDU). 48 illustrates how the protocol between the TMDC and target system PIs is changed by intrusion detection by exploitation of vulnerabilities associated with the TMV. In essence, instead of returning the TMV ACK PDU to the TMDC (as in previous applications), the target system PI returns an "Intrusion Response Countermeasures" REQ PDU (Request PDU), which is stored in the TMDC. Requests to retrieve IR measures and pass them to another TMV as IRC parentheses This signal may be used by the TMDC to indicate in its TMIB '2930 for the PI that the vulnerability has been found to be exploited. In particular, Figure 48 illustrates how the PDU flows illustrated in Figure 47 can be altered by detection of an intrusion associated with the TMV's primary vulnerability vector, in essence, instead of returning the TMV ACK PDU, the target system PI. Returns an IRC REQ PDU at 4830.

Further, in embodiments of the present invention, the "vulnerability state management" operation shown in FIG. 49, described in FIG. 27, is further extended, the scope of which is marked with dotted box 4910 and expanded in detail in FIG. It can be extended with an "intrusion detection" operation.

In addition, prior applications have introduced a data structure called "null TMV" within its "TMVGN Synchronization" operation to express that certain TMVGNs of the history sequence will be missing due to their obsolescence. These operations have been used in the protocol between the "TMV generator" and "threat management domain controller" components of the prior applications. As described by the prior applications, the null TMV may have the form shown in FIG. 51.

The null TMV is a TMV configured in a translated form, and the vulnerability vector indicates that there are no countermeasures for a given system / subsystem type and level. A null (converted) TMV is generally used in this way in prior applications. In embodiments of the invention different forms of null TMV may be used. It may be used to indicate that there are no IR countermeasures available, in particular in the embodiments of the present invention, in response to an "IRC REQ PDU." Null (converted) TMVs may have the form shown in FIG. 52.

In the following, an intrusion response according to various embodiments of the present invention will be described. Intrusion Response deals with the data and processing associated with responding to IRC REQ PDUs and subsequent applications for parentheses of the provided IR countermeasures. FIG. 53 illustrates how an intrusion response may be adapted within the overall message and control flow associated with a TMV including parentheses of IDC and IRC countermeasures. Reference numerals 5310-5330 identify flows associated with "replace measure", and reference number 5340 identifies flows associated with "intrusion detection." Reference numerals 5350-5360 identify flows associated with the “intrusion response”.

Referring now to FIG. 53, at 5350, the TMDC 2910 ′ retrieves the requested IRC parentheses, packages it into a TMV representing the associated vulnerability, and then returns it to the target system PI 1880 to thereby target the system. Respond to the IRC REQ PDU from the PI 1880. If no IRC parentheses are available, the TMDC instead transmits a "null transformed TMV" as defined in the prior applications. After receiving the TMV and incorporating the IRC parenthesis into the TMIB of the PI or after receiving the null TMV, the target system 540 responds with a TMV ACK PDU at 5360. The TMV ACK signal can in this context be used by the TMDC to indicate that the vulnerability at its TMIB '2930 for the PI has been scheduled for an intrusion response.

54A-56A illustrate how intrusion responses can affect the logic of prior applications. 54B shows its response to the “TMV responder” of the prior applications. 55A and 56B show its effect on “TMV derivation” of FIG. 26, also shown in FIG. 56A, block 2660.

Next, an intrusion response countermeasures (IRC) relay according to embodiments of the present invention will be described with reference to FIG. 57. The IRC relay deals with the situation where the TMDC receives parentheses from IR TM counters for IR vulnerabilities for which the target system PI has already issued an IRC REQ PDU. In other words, the target system PI detected an intrusion and requested IR countermeasures, but the IR countermeasures are only available subsequently. In this case, at 5710, if TMIB 'for PI indicates that an unsatisfactory IRC REQ PDU has been received, domain controller 2910' immediately sends a TMV with IR countermeasures to the target system, and the target system sends a TMV ACK at 5720. Responding as a PDU, TMDC marks TMIB 'to indicate that the IRC REQ has been met.

Thus, embodiments of the present invention can transform a vulnerability treatment system into a highly effective intrusion detection and response mechanism. Reliable delivery (by its self-healing feature) of executable intrusion detection and response information to target system program instances may be provided. Embodiments of the present invention provide that threat management vector generators (TMVGs) can provide brain functions, target system program instances can represent life support organs, and provide neural receptor / operator functions, and threat management domain controllers. Threat management can be modeled by analogy to an organic system that can provide spinal cord function (TMDC).

While the drawings and specification disclose embodiments of the invention and certain terms are employed, they are used only in a generic and descriptive sense, not in limitation, the scope of the invention is set forth in the following claims.

Claims (20)

A method of generating computer security threat management information. Receiving a notification of a computer security threat and / or a notification of a test that detects an intrusion of the computer security threat; Generating a computer-executable Threat Management Vector (TMV) from the notification received, wherein the TMV is a computer-readable field providing identification information of one or more system types affected by the computer security threat, the system A computer-readable field providing identification of a distribution level for a type, and a computer-readable field providing identification information of a test for detecting the intrusion of the computer security threat for a system type and a distribution level. Generating the TMV; And Transmitting the generated TMV to the plurality of target systems for processing by the plurality of target systems. Method of generating computer security threat management information comprising a. The method of claim 1, The TMV further comprises a computer-readable field for providing identification information of possible countermeasures for system type and distribution level. The method of claim 1, The TMV is a first TMV, The computer security threat management information generation method, Generating a second TMV in response to a notification from a target system where the intrusion of the computer security threat was detected, wherein the second TMV identifies instructions for removing the detected intrusion of the computer security threat. Generating a second TMV comprising a possible field; And Transmitting the generated second TMV to the target system for processing by the target system. Method of generating computer security threat management information further comprising. The method of claim 2, The TMV provides a computer-readable field that provides identification information of a plurality of tests for detecting the intrusion of the computer security threat to system type and distribution level and / or identification of a plurality of possible countermeasures for system type and distribution level. The computer security threat management information generation method further including. The method of claim 1, Generating a null TMV in response to a notification from the target system where the intrusion of the computer security threat was detected, wherein the null TMV identifies that there are no instructions available to eliminate the intrusion of the detected computer security threat. Generating said null TMV comprising a computer-readable field; And Transmitting the generated null TMV to the target system for processing by the target system. The method of claim 5, The TMV is a first TMV, Transmitting the null TMV, Generating a second TMV in response to receiving the instructions to remove the detected intrusion of the computer security threat, wherein the second TMV identifies the instructions for removing the intrusion of the detected computer security threat; Generating a second TMV comprising a readable field; And Transmitting the generated second TMV to the target system for processing by the target system. Is a method of generating computer security threat management information. The method of claim 2, The possible countermeasure includes a countermeasure for eliminating the intrusion and / or a countermeasure for treating the damage caused by the invasion. The method of claim 1, And wherein said receiving, generating and transmitting said TMV are performed by a threat management domain controller. A computer program product configured to process computer security threat management information, the computer program product comprising a computer usable storage medium having computer readable program code therein, The computer readable program code, Computer readable program code configured to receive a computer-executable Threat Management Vector (TMV) at a target system, wherein the TMV is a computer-readable field providing identification information of one or more system types affected by the computer security threat. A computer-readable field providing identification information of a distribution level for the system type, and a computer-readable field providing identification information of a test for detecting the intrusion of the computer security threat for the system type and distribution level. The computer readable program code comprising; And Computer readable program code configured to perform a test to detect an intrusion of the computer security threat at a target system in response to receiving the TMV Computer program product comprising a. The method of claim 9, The TMV is a first TMV, The computer program product, Computer readable program code configured to send a notification from a target system in which the intrusion of the computer security threat was detected; Computer readable program code configured to receive a second TMV comprising a computer-readable field identifying instructions for removing the intrusion of the detected computer security threat; And Computer readable program code configured to, in response to receiving the second TMV at a target system, perform instructions for removing the intrusion of the detected computer security threat Computer program product further comprising. 10. The computer-readable medium of claim 9, wherein the TMV further comprises a computer-readable field providing identification information of a plurality of tests for detecting the intrusion of the computer security threat for system type and distribution level And computer readable program code configured to perform the test comprises computer readable program code configured to perform a plurality of tests that detect intrusion of the computer security threat in response to receipt of the TMV at a target system. Program product. The method of claim 9, Computer readable program code configured to send a notification from a target system in which the intrusion of the computer security threat was detected; And Computer readable program code configured to receive a null TMV that includes a computer-readable field identifying that there are no instructions available to eliminate the intrusion of the detected computer security threat Computer program product further comprising. The method of claim 12, The TMV is a first TMV, The computer program product, Computer readable program code configured to receive a second TMV comprising a computer-readable field identifying instructions for removing the intrusion of the detected computer security threat; And Computer readable program code configured to, in response to receiving the second TMV at a target system, perform instructions for removing the intrusion of the detected computer security threat Computer program product comprising a. A computer-readable field for providing identification information of one or more system types affected by computer security threats; A computer-readable field for providing distribution level identification information for the system type; And Computer-readable fields that provide identification of tests that detect the intrusion of the computer security threats for system type and deployment level. Computer-executable TMV comprising a. 15. The computer-executable TMV of claim 14, further comprising a computer-readable field providing identification information of possible countermeasures for the system type and distribution level. 15. The computer-executable TMV of claim 14, further comprising a computer-readable field that identifies instructions for removing the intrusion of the detected computer security threat. 15. The computer-readable medium of claim 14, wherein the computer-readable information provides identification information of a plurality of tests for detecting the intrusion of the computer security threat to system type and distribution level and / or identification of a plurality of possible countermeasures for system type and distribution level. A computer-executable TMV further comprising a possible field. 15. The computer-executable TMV of claim 14, further comprising a computer-readable field identifying that there are no instructions available for removing the intrusion of the detected computer security threat. 15. The computer-executable TMV of claim 14, wherein the system type is a program instance type. As a computer security threat management system, Means for receiving a notification of a computer security threat and / or a notification of a test that detects an intrusion of the computer security threat; Means for generating a computer-executable TMV from the notification received, wherein the TMV is a computer-readable field for providing identification information of one or more system types affected by the computer security threat, distribution for the system type Means for including a computer-readable field for providing a level of identification information and a computer-readable field for providing identification information of the test for detecting an intrusion of the computer security threat for system type and distribution level; Means for transmitting the generated TMV to a plurality of target systems; Means for receiving the TMV generated in the plurality of target systems; And Means for performing the test, in response to receiving the TMV, to detect intrusion of the computer security threat at the target system Computer security threat management system comprising a.

Images