MXPA04011271A

MXPA04011271A - Security-related programming interface.

Info

Publication number: MXPA04011271A
Application number: MXPA04011271A
Authority: MX
Inventors: W Townsend Stephen
Original assignee: Microsoft Corp
Priority date: 2003-12-05
Filing date: 2004-11-12
Publication date: 2005-06-09
Also published as: RU2004135454A; AU2004218703A1; JP4676744B2; AU2004218703B2; KR101122787B1; CN1624657B; EP1542426A3; RU2377639C2; EP1542426A2; EP1542426B1; KR20050054818A; BRPI0403523A; US7430760B2; CA2485062A1; US20050125687A1; CN1624657A; JP2005327239A

Abstract

A programming interface includes a first group of functions related to communicating a new security policy to multiple security engines. Each of the multiple security engines is configured to replace an existing security policy with the new security policy. The programming interface also includes a second group of functions related to communicating an indication of each security engine's readiness to implement the new security policy.

Description

PROGRAMMING INTERFACE RELATED TO SECURITY TECHNICAL FIELD The systems and methods described herein relate to computer systems, and more particularly, to an interface associated with the processing of events, such as security-related events, and other information.

BACKGROUND Computer systems are continually growing in popularity and are often interconnected with other computer systems, such as local area networks (LANs) and the Internet. Features such as electronic mail (email), instant message transmission, and online entertainment stimulate the use of computer systems coupled to networks. These features allow users, for example, to communicate with other users, retrieve video and / or audio content, and buy products or services through online sources.

This increased interconnection of computer systems increases the likelihood of attacks against computer systems by malicious users. These attacks can include the installation of a malicious program on the computers of other users (for example, pretending to disable the computers of other users, to obtain information from the computers of other users, launch attacks against other computers and the like). Attacks can also include trying to disable a continuous stream of requests sent to the computer). These attacks can be a nuisance for the computer user and can result in lost data, corrupted data, confidential data being copied from the computer, or making the computer inoperable. To prevent or minimize the severity of such attacks, several security programs and services have been developed. These programs and services run on the computer system and protect the computer system from malicious attacks. Examples of programs include antivirus programs and firewall programs. Typically, these programs or services are directed to the prevention of a particular type of attack. For example, an antivirus program protects against the face and / or execution of computer viruses, and a firewall program that protects against unauthorized access to the computer through an external user. These different programs typically do not communicate with one another. For example, an antivirus program typically does not communicate the fact that a virus was detected in the firewall program. In this way, the various security programs in a computer system can not learn about certain attacks on the computer system. It would be desirable to provide an interface that allows communication of security policies and event information between various components and security programs in a computer system.

COMPENDIUM OF THE INVENTION The systems and methods described herein provide an interface associated with the processing of events and other information to improve the security of a computer system. In a particular embodiment, a programming interface includes a first group of functions related to the communication of a new security policy to the multiple security engines. Each of the multiple security engines is able to replace an existing security policy with the new security policy. The programming interface also includes a second group of functions related to the communication of an indication of each availability of the security engine to implement a new security policy.

BRIEF DESCRIPTION OF THE DRAWINGS Similar reference numbers are used throughout the Figures to reference similar components and / or features. Figure 1 illustrates an example environment in which several events are generated and processed. Figure 2 is an example of a security policy that contains data and rules. Figure 3 illustrates an example of a frame maintained by a security module with respect to data requested by several security engines. Figure 4 is a flow chart illustrating a method of a procedure for retrieving and distributing security policy data and rules. Figure 5 is a flow diagram illustrating a method embodiment for handling updated security policy data. Figure 6 is a flowchart illustrating one embodiment of a method for handling the distribution of information to one or more security engines. Figure 7 is a flow diagram illustrating one embodiment of a procedure for updating a security policy. Figure 8 is a flow chart illustrating another embodiment of a procedure for updating a security policy. Figure 9 illustrates a general computer environment. Figures 10-21 illustrate several exemplary implementations of a programming interface.

DETAILED DESCRIPTION The systems and methods discussed herein process a variety of information, such as events generated by one or more programs or services. In addition, an interface is described that allows the communication of information, such as information related to security, between various components and programs in a computer system. The computer system includes an event manager that receives events and other information from multiple sources, such as security engines and other computer systems. Examples of security engines include antivirus engines, firewall engines, and intrusion detection engines. The event administrator communicates the event information received from a particular source to one or more security engines that could use the information to improve the level of security provided by the computer system.

Although the particular examples discussed here refer to events related to security and other information related to security, alternative modalities may process any type of event or information. This information includes any information that could be used by components related to security on a host computer. Alternative modalities may receive, process and distribute information that is not necessarily related to the security of a host computer. The terms "interface", "program interface", and "application program interface (API)" are used interchangeably herein.

Event processing Figure 1 illustrates an example environment 100 in which various events are generated and processed. Events include, for example, the detection of a computer virus, the detection of an attempt to access confidential data, the notification that a computer virus was destroyed, the notification of which particular application program was stopped or prevented from be executed, changes to the system status information, etc. A host computer 102 is coupled to multiple servers 104 and 106 through a network 108. The host computer 102 and the servers 104 and 106 can be any type of computer device, such as the device discussed below with respect to the Figure 9. The network 108 can be any type of data communication network, such as a local area network (LAN), wide area network (WAN), the Internet and the like. Although Figure 1 shows the host computer 102 coupled to two servers 104, and 106, the host computer 102 may be coupled to any number of servers or other devices capable of communicating with the host computer. The environment 100 can represent any of a variety of configurations, such as home, business, educational, research, etc., network configurations. For example, the server 104 may be a server device in a corporate LAN, and the host computer 102 may be a desktop computer or a portable computing device in the corporate LAN. As another example, the server 104 may be a server device on the Internet, and the host computer 102 may be a desktop computing device in the user's home. Host computer 102 includes a security module 110 that performs various security-related functions, such as monitoring, detecting and responding to attacks on host computer 102. Security module 110 includes an event manager 112 which is coupled to three security engines 114, 116 and 118. A security engine can be any service that helps in the protection against malicious users and / or malicious programs. Security engines 111-118 can be implemented in software, hardware, or a combination of software and hardware. Particular security engines are application programs related to security, such as antivirus programs and intrusion detection programs. The security engines 114-188 can also be referred to as "services". A particular security module 110 may include any number of security engines coupled to the event manager 112. The security module 110 may also include other modules, components or application program (not shown), such as a policy reader related to security or other policy management mechanism. The security module 110 is also coupled to the system status information 120 and system configuration information 122. The system status information 120 includes information regarding the current operating state or operating mode of the host computer 102. The System configuration information 122 includes information regarding how the host computer 102 is configured. The system status information 120 and the system configuration information 122 can be stored in a non-volatile storage device, such as a memory device or a hard disk drive. In one embodiment, the event manager 112 and security engines 114-118 are capable of receiving system status information 120 and system configuration information 122. Host computer 102 also includes an application program interface (API) 124 that allows the communication of security policies and event information between various components and programs on the host computer 102 or other devices. For example, API 124 allows components or programs to communicate with security engines 114-118 or event administrator 112 to send or receive information related to security. The API 124 also facilitates, for example, loading new security engines, uploading existing security engines, sending security policy to security engines, communicating changes in data to security engines, user interaction with security engines. security, and the administration of the centralized configuration of security engines. Further details are discussed below with respect to API 124. Although not shown in Figure 1, additional data sources or data providers may communicate information and events to security module 110 and event manager 112. These Additional data include, for example, configuration information related to an Internet Information Service (US), data provided by a system administration application, data contained in a system registry, and information provided by a user to administrator. of the system. Each security engine 114-118 performs certain security-related functions to help secure the host computer 102 from malicious users or malicious application programs. These users or malicious application programs may attempt to disable the host computer 102 or disable the functionality of the host computer 102, obtain data from the host computer 102 (such as passwords or other confidential information), or use the host computer 102 (such as to help in the attack to other computer systems). For example, security engine 14 detects computer viruses, security engine 116 provides firewall protection, and security engine 118 blocks the execution of particular application programs based on one or more user privileges or features. In this example, the security engine 114 protects the host computer 102 from being infected by viruses, worms, computer Trojan horses, and the like. Additionally, the firewall protection includes protecting the host computer 102 from being accessed by other devices through a network connection. Blocking execution of particular application programs includes preventing the execution of application programs on the host computer 102 through a user who does not have the appropriate privileges. Additionally, the execution of an application program can be blocked if an inappropriate behavior is detected, such as improper access to the network, or inappropriate access to the storage device. In other modes, one or more security engines can perform intrusion detection or vulnerability analysis. Intrusion detection includes, for example, Identifying when a malicious application and / or user program has accessed the host computer 102 and takes the appropriate action to notify the user or administrator, attempts to disable the malicious application program, or stops access of the malicious user. Vulnerability analysis includes, for example, trying to detect vulnerabilities in the host computer 102 because security engines or other components that have not been installed or updated correctly, patches or settings that have not been installed, passwords that do not comply with the required lengths or required characters, and the like. A particular security engine 114-118 may not be aware of the existence and functionality of other security engines coupled to event manager 112. Each security engine 114-118 communicates event (e.g., detection of a computer virus, detection of an attempt to retrieve data from the host computer 102, or stop the execution of an application program via a user) to the event manager 112. These events include information collected through a security engine, actions taken by the security engine, data collected by the event administrator from one or more data sources, and the like. The sample information includes a list of all virtual servers exemplified in a particular installation. The event manager 112 processes these events and communicates the information contained in particular events to other security engines 114-118 that may be beneficial to said information. The security module 110 also receives security-related policies that include one or more rules and various data. Event manager 112 distributes the rules to the appropriate security engines 114-118 and provides the data to the security engines, as necessary. Each security engine 114-118 stores these rules and data received from the event manager 112. The operation of the security module 110, the event manager 112, and the security engines 114-118 is discussed in more detail below. Figure 2 illustrates an example security policy 200 that contains data and rules. In one embodiment, security policy 200 is stored in security module 110. A particular security module can receive and store any number of different security policies 200 received from any number of different data sources. Alternatively, security policy 200 may be stored in another module or component within host computer 102. In the example of Figure 2, a data portion 202 of security policy 200 includes one or more data elements. As shown in Figure 2, these data elements include values assignable to variables (for example, a value of "1" is assigned to variable "A" and a value of "4" is assigned to variable "B" ). In alternative variables, other types of data may be included instead of or in addition to the data shown in Figure 2. The data contained in security policy 200 was used, for example, through one or more rules contained in a or more than other security policies. The security policy 200 also includes a portion of rules 204 that contains multiple rules. The rules in security policy 200 may be associated with one or more security engines. For example, certain rules can only be applied through particular security engines. These rules can be configured in security policy 200 in 102. Examples of results include the prevention of a resource being accessed, prevent data from being written to particular locations, prevent a program from being executed, or generate a notification that the occurrence of the condition in the rule was detected (for example, by recording its occurrence in a record, or by sending a message to a user or another computer). The particular results may also be permissive in nature rather than preventive. For example, the results could indicate that a particular resource or place can be accessed only if the condition in the rule is satisfied by the host computer 102, or that a particular program can only be run if the condition in the rule is satisfied by the host computer 102. Additional examples of rules include allowing certain application programs or services to update data files in a director or particular folder, enabling reception of traffic on port 21 if the file transfer protocol (FTP) is enabled, and generate a virus warning message if a particular virus signature is detected. Other examples include the generation of an event if a particular application program has not been updated to a particular revision level, preventing access to a network if the application program has not been updated to a minimum revision level, and preventing the host computer receives data through the network port 35. Figure 3 illustrates a table of examples 300 maintained by a base to the security engine with which the rules are associated. Alternatively, an identifier associated with each rule can identify the security engines that are capable of applying the rule. In particular modes, a rule can be associated with any number of security engines. In other modalities, a host computer may not contain a security engine that applies a particular rule. In this situation, the rule is not associated with any security engine. In the example of Figure 2, the rules are defined using a structure IF-THEN. Alternatively, the group of rules can take a variety of different forms. By using the SI-THEN structures shown in Figure 2, the rule defines a particular condition (s) and a particular action (s) or corresponding result (s). During the application of the rule, if the particular condition (s) is detected, then the particular action (s) or corresponding result (s) is carried out. A rule can identify a variety of different conditions and corresponding actions or results. Examples of conditions include attempts to access a resource (for example, memory locations, addresses or network ports, other programs, or files on a storage device), attempts to write data to particular locations (for example, particular memory locations). , or particular locations in a storage device), attempts to run particular programs, and various aspects of the current operating state of the host computer security module with respect to data requested by various security engines. In one embodiment, the frame 300 is stored in the security module 110. Alternatively, the frame 300 can be stored in another module or component within the host computer 102. Each time a security engine requests data from the security module, the security module updates the table (if necessary) to include the requested data. A first column 302 of the frame 300 identifies a particular data element, such as a variable or other identifier or information. A second column 304 of frame 300 identifies any security engines that previously requested the associated data item. For example, the frame 300 identifies that the data element "A" was previously requested by the security engine "1". Similarly, the data element "D" was previously requested by the security engines "1", "4", and "6". As discussed in more detail below, the information contained in Table 30.0 is used through the security module to determine which security engines should receive updated data. Figure 4 is a flow diagram illustrating one embodiment of a method 400 for retrieving and distributing security policy data and rules. The procedure 400 can be carried out, for example, on the initialization of a host computer. Initially, a security module receives security policies from the host computer (block 402). An event manager identifies the rules in the security policies related to each security engine (block 404). The event administrator then communicates the rules to the appropriate security engines (block 406). Each security engine identifies the necessary data to apply its associated rules (block 408), for example identifying the data elements contained in the rules that the security engine will apply. Each security engine then requests its identified data from the event administrator (block 410). After receiving the requested data from the security engine, the event administrator records the requested data element in a table (for example, box 300 of Figure 3) or other data structures for future reference (block 412). Finally, the event administrator locates the requested data and provides that data to the requesting security engine (block 414). In this way, instead of providing all data to all security engines, the event administrator provides the requested data to each requesting security engine. Figure 5 is a flowchart illustrating a method mode 500 for handling updated security policy data. Initially, the security module receives updated data (block 502). For example, the updated data may include updated values for the existing variables. The security module identifies one or more security engines for the existing variables. The security module identifies one or more security engines that previously requested the data that has been updated (block 504). In one embodiment, the security module identifies these security engines using a frame such as frame 300 shown in Figure 3. After identifying the appropriate security engines, the security module provides updated data for each of the engines of identified security (block 506). Finally, security engines update their data elements with updated data. The procedure 500 is repeated each time a security module receives updated data. In another mode, the security module periodically checks the various data sources for the updated data. If the data has been updated, the security module retrieves the updated data and distributes the data according to the procedure 500. In a mode, when a rule is updated, the security module identifies the security engine associated with the rule and Distribute the updated rule to the identified security engines. If a new rule is received, the security module identifies the security engines that could use the new rule and distributes the new rule to the appropriate security engines. Similarly, if an existing rule is removed, the security module removes the rule from all the security engines associated with the rule. In another modality, when a rule is updated, the security module creates a new group of rules (including the updated rule) and distributes the new group of rules to the security engines, thus replacing the existing rules contained in the security engines. security. Figure 6 is a flowchart illustrating a modality of a method 600 for managing the information distribution, such as event information or system status information, to one or more security engines. Initially, the event administrator receives an event from a security engine (block 602). The event administrator then identifies the information contained in the event (block 604), such as the type of event or the nature of the attack that generated the event. The event administrator also identifies other security engines that could use the information contained in the event (block 606). The relationships between the different security engines are specified, for example, in the security policy received by the host computer. These relationships can be defined totally or in part through a system administrator or other system operator when the security policy is created. Next, the event administrator provides the information contained in the event to the identified security engines (block 608). The identified security engines then apply the received information (block 610). This sharing (or mapping) of event information improves the level of security provided by a host computer against malicious attacks. The sharing of the event information is handled through the event manager that the individual security engines do not need to know about the other security engines in the host computer. The information related to the security discussed here can be stored in a central location, therefore allowing other devices, components and application programs to access the information. For example, other security engines, or computer systems can access information related to stored security. In an example of method 600, an antivirus security engine detects repeated attempts to access a network through a particular port. The antivirus security engine reports this information (for example, dates and times of access trying and the port in which the access was attempted) to the event administrator. In this example, the antivirus security engine is not responsible for responding to such access attempts. The event administrator receives the information from the antivirus security engine and determines that an intrusion detection security engine and a firewall security engine can use that information. After receiving the information, the intrusion detection security engine and the firewall security engine can adjust their operations based on the information received. For example, the intrusion detection security engine can increase the frequency with which it checks intruders. Additionally, the firewall security engine can temporarily disable the port on which access was attempted. In this way, the overall security of the host computer against attacks is increased by allowing the security engines to adjust their operations based on shared information regarding security-related events. In another example of procedure 600, a vulnerability security engine detects whether a particular patch is installed on the host computer. If the patch is not installed, the vulnerability security engine generates an event indicating that the patch is not installed. A host firewall security engine and a behavior blocking security engine have been registered with the event administrator for notifications if the patch is not installed. When the host firewall security engine and the behavior blocking security engine receive a notification that the patch is not being installed, the security engines apply rules that limit the functionality (or prevent execution) of the application program that does not It was patched. In another modality, the information of the state of the system is shared among several components (for example, the event administrator and the multiple security engines) in the security modules. Information on the state of the system can be provided through various data sources. Examples of the system status information include information on the current network status, whether a network connection is wired or wireless, whether the host computer is accessing a corporate network or an unknown network, and the configuration of the host computer. In this way, the security engine identifies the information of the state of the particular system, that identified information can be shared between other security engines and other components or modules in the host computer. In a particular embodiment, the system status information collected through various components is stored in a central location, thereby providing access to the information through other devices, components and application program. For example, system status information collected through a security engine is accessible to other security engines, security modules and computer systems.

Updates to the Security Policy As discussed above, a security policy can be used to describe the rules that will be applied, for example, through the security engines or security providers. When changes are made to the security policy, the updated rules are supplied to the various security engines, and these various security engines change to start using the updated rules at substantially the same time.

In addition to the components, programs and modules discussed above with respect to Figure 1, host computer 102 receives security policies from one or more source devices, such as servers 104 and 106. Security policies describe how various security engines in the host computer 102 they must operate. Although only a host computer 102 is illustrated in Figure 1, it will be appreciated that multiple guest computers 102 may obtain security policies from the same source device. Examples of source devices include desktop computing devices or workstations, server computing devices, portable or handheld computing devices, game consoles, network devices, cell phones, personal digital assistants (PDAs), networked devices (for example, routers, access doors, firewalls, wireless access points, etc.), and etc. The host computer 102 may also include a policy reader module, a rules administrator, a rule group generator module, and a dynamic rules data store. It will be appreciated that one or more of these modules may be combined in an individual module, and / or one or more of these modules may be separated into two or more modules. Generally, to update the security policy being applied by security engines 114-118, the policy reader obtains a security policy from a source device. The generator of the group of rules uses the newly obtained security policy to generate, for each of the various security engines, a group of one or more rules, and associated data. These rule groups are then communicated to several security engines, and the associated data is stored in the dynamic rules data store. Once the group of one or more rules is received, each security engine processes the new group of rules, preparing to start using the new group of rules. However, each security engine continues to use its current rule group until it is instructed to change to the new group. A rules administrator instructs all security engines to switch to the new rule group after the rules administrator receives an indication of each of the security engines that he is ready to switch to the new rule group. In certain embodiments, the rules administrator coordinates the updating of security policies on the host computer 102. The rules administrator receives indications from the various security engines indicating that the security engines are ready to switch to the new rule group , and gives an indication to the security engines when they should start using the new group of rules. The policy reader module obtains a new security policy for the source device. The policy reader module can be configured to verify if a new security policy is available from the source at regular or irregular intervals, or alternatively it can receive an indication of some other component (for example, the rule manager, the source device , or some other device not shown in Figure 1, which should obtain a new source security policy (or verify if a new security policy is available from the source.) The policy reader can identify the source a policy of particular security that the policy reader wants to obtain, or alternatively you can merely request the latest security policy for the host computer from the source. A comparison between the current security policy that is being used by the host computer and the latest security policy can be made to determine if the most recent security policy is already being applied on the host computer. This comparison can be made through the source, the policy reader, or alternatively through some other component. When a new security policy is obtained from the source, the generator of the rule group generates a group of rules for each of the different security engines 114-118. Different security engines can use different rules when they apply the security policy on the host computer 102. For example, a security engine 114 can be a firewall as long as another security engine 116 can be an antivirus component. The security policy can identify rules that are specific to the antivirus engine (and in this way the antivirus engine does not need to worry about these), and can also identify rules that are specific to the firewall engine (and thus the engine of the antivirus does not need to worry about these). In certain modalities, the security policy itself is a list of associated rules and data. The security policy can also include an indication of which rules and data are for which security engines, or alternatively none of those indications can be included (for example, relying on the host computer to determine which rules are for which security engines) . The security policy allows designers to have an individual record or file for all the rules involved in the protection of the host computer, without having to separate the rules through different registers or files for the different security engines. Additionally, by using the techniques described herein, new security policies can be prepared by designers who exchange responsibilities for protection against particular attacks from one security engine to another. For example, protection against a particular type of attack can be applied through an antivirus program in a security policy but changed to be applied by a firewall program in a new security policy. By using the techniques described here, designers can trust that this sharing in responsibility will occur in all security engines substantially concurrently, thereby reducing the vulnerability of the host computer from attacks during the exchange. The generator of the group of rules identifies, based on the security policy, which rules and associated data (if any) are used by the security engines. For each security engine, the rule group generator generates a group of rules for that security engine and makes the generated rule group available to that security engine (for example, the rule group can be transmitted or sent to the security engine, the security engine can be informed of a location in the memory where the generated group of rules can be obtained, etc.). This generation can be carried out in a variety of different ways. For example, a new group of rules can be generated through the generator of the group of rules without taking into account the current rules that are being applied by the security engines. By way of another example, the particular group of rules can be modified or changed to incorporate any differences between the current and the new group of rules. Additionally, the generator of the group of rules can simply copy the rules of the security policy, or alternatively the generator of the group of rules can generate the rules based on the information of the security policy that describes the rules.

In certain modalities, the security policy identifies which rules are to be distributed to which security engines. For example, each rule can be associated with a particular tag or identifier (for example, Security Engine 1, or Antivirus engine, etc.) - The generator of the rule group can use these identifiers in the generation of rule groups for the various security engines. In alternative modes, the generator of the rule group can infer which rules are going to be distributed to which security engines. In other modalities, a combination of these techniques can be used (for example, for some rules the security policy can identify which security engine they are going to assign, and for other rules the security policy generator can infer in which security engine security they will assign). The group of rules generated by the rule group generator can take any of a variety of different forms. In certain modalities, the rules follow a yes-then structure, as discussed above. When using these structures, the rule defines a particular condition (s) and a particular action (s) or corresponding result (s). During the application of the rule, if this particular condition (s) is detected, then the corresponding particular action (s) or result (s) is performed. Any of a variety of conditions and corresponding results can be identified through a rule. Examples of particular conditions include: attempts to access particular resources (for example, memory locations, addresses or network ports, other programs, files on a storage device, etc.). attempts to write data to particular locations (e.g., particular memory locations, or particular locations in a storage device), attempts to run particular programs, various aspects of the current operating state of the host computer (e.g., available resources, run programs, etc.) and etc. Examples of particular outcomes include preventing a resource from being accessed, preventing data from being written to particular locations, preventing a program from being executed, or generating a notification that the occurrence of the condition in the rule was detected (for example, registering its occurrence in a registry, or sending a message to a user or another computer). The particular results may also be permissive in nature rather than preventive. For example, the results could indicate that a particular resource or place can be accessed only if the condition in the rule is satisfied by the host computer. In certain embodiments, the host computer 102 includes a data store of dynamic rules which are data associated with the various rules that are being applied through the security engines. In certain modalities, the dynamic rules data store can include two groups of data: one group for the current rules that are being applied by the security engines, and another group for the new rules that the security engines are updating to apply . When a new security policy is received, the rule group generator updates the dynamic rules data store with the data associated with the groups of new rules that passed to the security engines. Each security engine includes a rule change module that receives a group of one or more rules from the generator of the rule group. The data associated with the rules can be received from the generator of the rule group together with the rules, or alternatively the rule change module can obtain the data it wants from the dynamic rule data. Additionally, it should be noted that although the generator of the group of rules was previously discussed as generating a group of rules for each security engine based on 1 the security policy, alternatively each security engine can receive the entire security policy (or most of the security policy) and generate its own group of rules instead of receiving the generator group from the rule group. The rule change module processes the new group of rules in order to generate new internal rules that apply the new policy. The processing of the new group of rules to generate new internal rules refers to any actions that are necessary for the security engine to take in order to place the new group of rules in a state in which they can be applied through the device of security. For example, this processing can include the conversion of the new group of rules to an internal format, storing rules in particular memory locations, organizing rules in a particular configuration or order, etc. The rule change module can generate new rules in any of a variety of ways: the rule change module can keep the rules in the same format they were received from the rule group generator or alternatively convert the rules to a internal format used by the security engine. Regarding how the new rules are generated, each security engine maintains a current set of rules that apply the previous security policy for the host computer (the security policy which is being updated). While the new rules are generated, and even after the new rules are generated, the security engine continues to apply the current rules. The security engine does not start the application of the new rules until it is instructed to do so (for example, through the rules administrator). After the rule change module has finished the generation of the new rules, the rule change module indicates to the rules administrator that it has finished and is ready to change to use the new rules (and thus starts the application of the new security policy). After the rule manager has received this indication from all the security engines, the rules administrator instructs each of the security engines to initiate the use of the new rules. The rules administrator waits to instruct each of the program modules to initiate the use of the new rules until after the rules administrator receives the indication of all the security engines. Once instructed to do so, each security engine begins to use the new rules. As soon as the security engine starts using the new rules, you can delete the rules you were previously using. In some situations, a security engine may fail to process the new rules. In such situations, the security engine returns an indication of such failure to the rules administrator. Alternatively, the rules administrator can impose a time limit on the responses of the security engines. If all the security engines have not responded with an indication that they are ready to start using the new rules within the time limit, the rules administrator can assume that one or more security engines have failed to process the new ones. rules. When the rules administrator identifies that one or more security engines have failed to process the new rules, the rules administrator does not instruct any of the security engines to start using the new rules. Instead, the rule manager sends an indication to abort the change to the new rules (this can also be referred to as a withdrawal). Said indication of abortion or withdrawal informs one of the security engines that ignore the new rules received from the generator of the group of rules as well as any new rules of its processing, and continue using the current rules. In certain modalities, security engines can safely remove the new rules that they generated (or are in the process of being generated) in response to such indication of abortion or withdrawal. In certain modes, each security engine waits until it can almost ensure that it can initiate the use of the new rules before informing the rules administrator that it is ready to start using the new rules. In other words, the security engine waits to inform the rules administrator that it is ready to start using the new rules until the security engine is at the point in processing the new rules that is virtually impossible for the engine security failed to start the application of those rules when instructed to do so. In certain modalities, this is achieved through the security engine generating the new group of rules, and maintaining a pointer to which of the groups of rules (old rules and new rules) you have to use. After the new rule group is generated, the security engine tells the rules administrator that the security engine is ready to start using the new rule group. Then, when instructed to start using the new group of rules, the security engine can simply change its pointer from the old rule group to the new rule group. The security engine can almost ensure that you can change your pointer and start using the new rules. It will be appreciated that "almost certainly" does not require a 100% guarantee that failure is absolutely impossible. It is possible that certain situations still arise which could result in a failure (for example, loss of power or virus attack that prohibits changing the pointer). However, it will also be appreciated that the probabilities of failure are very small. The rules administrator can instruct the security engines to initiate the use of the new rule group (also referred to as a change to the new rule group) in any of a variety of different ways. The form used, however, must operate to inform all security engines substantially at the same time so that all security engines can initiate the use of their new groups of rules substantially at the same time (also referred to herein). as substantially concurrently). By having all the security engines started using their new rule groups substantially at the same time, any vulnerability of the host computer due to the change of rules is reduced. Generally, the closer in time the security engines initiate the use of their new rule groups, the lower the vulnerability during the change to the new group of rules. Below are some examples of ways in which the rules administrator can instruct the security engines substantially at the same time to initiate the use of their new rule groups. One way in which the rules administrator can instruct the security engines to initiate the use of the new rule group is to use an event object that can be triggered through all the security engines at the same time. For example, each security engine, once they receive the new rules from the generator of the rule group, establish an internal flag to start polling a particular event each time the rules are accessed (during its normal operation to protect the host computer). The rules administrator can then instruct the security engines to initiate the use of their new rule groups by triggering the event (the same one that is being polled by the security engines). Therefore, after the event is triggered, any subsequent polling of the event will reflect that the event has been triggered and therefore informs the polling security engine that a new set of rules should be used. For example, in response to the detection of the event that has been triggered, the pointer in the security engine can be changed to point towards the new group of rules. In addition to polling the event, you can also run an argument using the security engine waiting for the event. When the event is triggered, the argument detects the trip so the security engine is informed that a new group should be used. For example, in response to the argument detecting that the event has been triggered, the pointer of the security engine can be changed to point towards the new group of rules. Once the event has been triggered and the new group of rules is being used, the security engine can stop polling the event. Addicionally, if an argument waiting in the event is run by the security engine, that argument can be terminated. Another way in which the rules administrator can instruct the security engines to initiate the use of the new rule group is to call a function exposed by each of the security engines (for example, a "change" function). When calling that function a security engine Instructs that security engine to initiate the use of a new group of rules. For example, in response to the function that is being invoked in a security engine, the security engine changes its pointer to point to the new group of rules. Another way in which the rules administrator can instruct the security engines to initiate the use of the new group of rules is to notify each of the security engines of a shared data structure that each security engine can access. The rules administrator can inform each security engine of the shared data structure at different times, that is, called a function in each security engine (for example, a function of "identifying the data structure") or identifying the Shared data structure when the new rules pass to the security engine. The shared data structure can take any of a variety of different forms, such as a place in memory (for example, in random access memory RAM) or a non-volatile memory such as a Flash memory), a stored file in a remote or local storage device, etc. Each security engine checks this shared data structure (for example, each time the rules are accessed (during its normal host computer protection operation)) to determine its value. The rules administrator instructs each of the security engines to initiate the use of the new rule group by changing the value (s) stored in the shared data structure. For example, the shared data structure may initially store a value of "previous" or a value of 0 to indicate that the current group of rules will be used, and when it is time to change to start the use of the new group of rules the administrator of rules can write a value of "new" or "change" or a value of 1 in the shared data structure to indicate that the new group of rules will be used. As discussed above, the dynamic rules data store stores the data associated with the various rules that are being applied by the security engines. That is, when the host computer is being updated to start the application of a new policy, the data used by the security engine can also change. This data can also change during the operation of the host computer (for example, a security engine can request data later from or store data in the dynamic rules data store). In order for the appropriate data to be made available to the security engines, when the security policy is updated the dynamic rules data store can operate in the same way as a security engine. That is to say, two groups of rules could be maintained, the first group could be used before the change and the second group could be used after the change. The new data could be stored in the dynamic rules data store, and the dynamic rules data store could return an indication to the rules administrator when it is ready to start using the new rule group. The dynamic rules data store then continues the use of the previous data group until it receives an instruction from the rules administrator to initiate the use of the new data group. It should be noted that the various components in the host computer can be implemented within the same application process executed on the host computer. For example, the policy reader, the rules administrator, the dynamic rules data, the rule group generator, and the security engines can all be part of the same application process. Alternatively, different components in the host computer can be implemented through one or more application processes running on the host computer. For example, one or more security engines can run in a process that is separate from the other security engines as well as separate from the policy reader, the rule manager, the dynamic rule data, the rule group generator. Allowing different components to run in different application processes allows, for example, different programmers to design different components of added programs (for example, different security engines of added programs) to improve the security of the host computer. These additional added components could be updated to apply new policies in the same way as other components not added. When components are separated through multiple application processes, a mechanism is used to allow the various components to communicate with one another. This communication allows, for example, that the groups of new rules and data that will be passed to the security engines in different processes, data that will be passed from security engines in different processes, instructions that are being used in the new ones groups of rules that will be passed to security engines in different processes, etc. As an example, the components discussed here can be implemented as components of the Component Object Model (COM). Additional information regarding the architecture of the Component Object Model is available from Microsoft Corporation of Redmond, Washington. It should be noted that in the discussion of this, each security engine is instructed to initiate the use of its new group of rules through the rules administrator. Alternatively, this instruction can be implemented in other mechanisms that still allow each security engine to initiate the use of its new group of rules substantially concurrently. For example, instead of using the rule manager, a control mechanism to instruct each security engine to initiate the use of its new group of rules can be distributed through the various security engines. This can be achieved, for example, through each of the security engines by notifying each other that you are ready to start using the new group of rules, without any of the security engines initiating the use of your new security group. rules until all the security engines have notified all the other security engines that are ready to start using the new group of rules. Figure 7 is a flow chart illustrating an example process 700 for updating a security policy. The 700 process is implemented through a component (s) that is coordinating the update of the security policy on the host computer, such as the rules administrator discussed here. The process 700 can be performed in software, hardware, firmware, or combinations thereof. Initially, a new policy that will be applied to the device is obtained (block 702). The policy can be obtained in the form of "pull", where the host computer initiates access to the source of the new policy to verify if a new policy is available from the source. The policy can alternatively be obtained in a "push" way, where the host computer is informed of (for example, sending a message or other indication of) the availability of a new security policy or the new security policy. same With respect to how the new policy is obtained, once the new policy is obtained, a new group of rules and / or data associated with the rules for the new policy are provided to each of the security devices (block 704) . As discussed above, different groups of rules and / or data can be generated based on the new policy for each security engine. The return values are then received from the security engines (block 706). In certain implementations, each security engine returns, to the implementation process of component 700, a value meaning "OK" indicating that the security engine has processed the group of rules and / or data it received and is ready to start using it. of the new group of rules and / or data.

This can also be referred to as a good provision of the security engine to implement the new group of rules and / or data. For example, all that remains is for the security engine to change its pointer to staple into the new rule group instead of the previous rule group. However, when a security engine returns a value meaning "Fail", it indicates that the security engine could not (or could not) process the group of rules and / or data and that the security engine is not capable of initiating the use of the new group of rules and / or data. Additionally, as discussed above, a time limit (also referred to as an exhausted time value or amount of time threshold) may be imposed on responses of the security engines if a security engine does not respond with value meaning "OK" or "Fail" within this time limit the component that implements the process 700 treats the security engine as if it had returned a value meaning "Failure". It will be appreciated that sending rules and receiving responses (blocks 740 and 760) is an asynchronous process. Different security engines can take different amounts of time to process the rules and / or data they receive, and process 700 simply waits until all security engines have finished their respective processing (up to any optional time limit that is imposed ). The process 700 proceeds on the basis of whether all the security engines have returned a value meaning "OK" (block 708). If all safety motors have returned an "OK" value, then all safety motors are ready to start using the new set of rules, so all safety motors are instructed to start using the new set of motors. rules (block 710). However, if at least one of the security engines does not return a value meaning "OK", then a recall call is issued to each security engine (block 712). This recall call essentially aborts the update process, so no security engine will initiate the use of the new set of rules yet (even though those security engines have returned a value meaning "OK"). Figure 8 is a flow chart illustrating another example process 800 for updating a security policy. The process 800 is implemented through a security engine in a device, such as a security engine 114-118 in the host computer 102. The process 800 can be carried out in software, hare, firmware, or combinations of these . Initially, a new group of rules and / or data are received for the new policy that will be applied (block 802). As discussed above, the rules and data may be received substantially at the same time, or alternatively the security engine may obtain the data from a data store (e.g., the dynamic rules data store discussed here) as necessary. The new rules and / or data are then processed (block 804). The processing of the new rules and / or data creates an internal group of rules to follow the security engine (for example, in an internal format of the security engine) in the application of the new security policy. Process 800 proceeds based on whether the processing of the rules was successful (block 806). If the security engine has finished processing the group of rules and / or data it received, and is ready to start using the new group of rules and / or data (for example, all that remains is that the security engine change your pointer to point to the new group of rules instead of the previous group of rules), then it's processing was successful. Otherwise, the processing was not successful. If the processing was successful then a value meaning "OK" was returned (block 808). However, if the processing was not successful then the value meaning "Fail" is returned (block 810). The values returned in blocks 808 and 810 are returned to a component (s) that is coordinating the update of the security policy on the host computer (for example, the rules administrator discussed here above). With respect to the returned value, the security engine continues to use the previous or old rule group until it is instructed to withdraw or initiate the use of the new rules (block 812). If instructed to initiate the use of the new rules, then the security engine initiates the use of the new rules and / or data (block 814), such as changing a pointer from its previous rule group to its new group of rules . The instruction to initiate the use of the new rules may be received through the security engine in any of a variety of ways, as discussed above. However, if instructed to withdraw, then the security engine discards any processing results of the new rules and / or data (block 816). This discarding can be done with respect to whether the security engine has finished processing the new group of rules it received. In this way, as can be seen in Figure 8, the security engine continues to use its previous group of rules until an indication of changing to the new group of rules is received. At the moment in which said indication is received, the safety motor is ready to start the use of the new rules and very little time is required for the change to occur. For example, the security engine may simply need to change a pointer to point to its new group of rules instead of its previous group of rules.

Application Program Interface (API) An API, such as API 124 discussed above with respect to Figure 1, allows communication of security policies and event information between various components and programs (for example, security engines) on the host computer. In an embodiment, the API is defined using the Component Object Model (COM). The API supports methods to upload and download security engines, sending security policy to the security engines, communicating changes in the security policy data to the security engines concerned, allowing the guest user to interact with the security engine in the moment of decision-making to allow or prohibit certain specified policy behaviors and the administration of centralized configuration for security engines. The systems and procedures discussed here enable the security of the computer system to be centrally managed by activating security policies for particular computer systems or a group of computer systems. Additionally, these systems and procedures collect and correlate events and other information, such as events related to security, generated by those computer systems or other data sources. In a modality, the inferióase supports the client's access to security policies and databases of events through authenticated, secure protocols. The interface allows communication between several components or application program and one or more security engines. The interface also defines how the security engines communicate with each other and with other devices, components, services or programs. In one embodiment, the interface is defined as a COM interface, using a common loader to reduce the likelihood of an attacker changing the security engines to the attacker's own code by changing the COM registry values. In an example mode, the function calls supported by the API are: Function Calls of the Next-to-Security Engine • Start • Shut Down • Prepare Policy • Remove Policy • Write Data • Write Config These seven function calls are referred to as the "Interfasel" Motor Security ".

Calling Engine Function Seq uid ad-a-Agent ReadyRegisterDataNotification WriteDataSE Data ARegistrationNotif ObtainDataRecipesRead andRegisterConfigNotifRegistration UnConfigNotif SearchUser Complete The first seven calls of previous functions are referred to as the "InterfaselAgentSecurity" and the last function call (Complete) is referenced like the "Inferid I Call DeVu the Agent ta". A function call can also be referred to as a "call", "function", or "service". The details regarding these function calls are provided below. Alternative modes may use additional function calls and / or omit one or more of the function calls discussed here. In one mode, an agent, such as an event administrator or security agent, communicates with the security engines through the API. An agent can also be referred to as an "administrator". In particular modes, the agent will not call a particular security engine when an API call is pending. There are exceptions to this rule for asynchronous API calls. In these cases, the allowed agent actions are defined below in the status box.

Start Function Call This method is called once for each security engine that is known to the agent. The method is called during the start of the agent. The Start function call loads the security engine and allows you to perform the initialization operations. This method is called synchronously in turn for each security engine by the agent, and the return calls are processed as they are received. The agent will wait for all return calls to complete before continuing. This method is defined as follows: HRESULT lniciar ([entry] Security Agent * pAgent, [entry] Call Return Agentl * pCallReturn): Agent is a COM interface that can be used by security engines to call the agent back. Return Call is the object of the return call defined above. If the call of the Start function fails, or if it does not return in a reasonable amount of time, then Shutdown will be called. Due to possible conditions of competition, the security engines handle Shut Down before Start has returned.

Shutdown Function Call This method is called once for each security engine that was called to start through the agent. The method allows the security engine to start its shutdown processing. Even if Start fails, the agent calls Shutdown to allow the security engine to close any resources that were allocated. For example, this method allows the security engine to perform a complex shutdown that can not be performed while handling DLL_PROCESO_SE STOP Since this method can take a significant amount of time to complete, - uses a call back object to indicate that has completed shutdown processing. When this method is called as a result of shutting down the system in process, the time available for processing to complete is limited, and the agent can be terminated through the system before the call back is completed. This method is defined as follows: typedef enum tag AP AG AR_T I PO. { OFF_NORMAL = 0, SHUTDOWN_SYSTEM} TURN OFF_TIPO; RESET OFF ([entry] OFF AR_TI PO eType [entry] Call ReturnAgentl * pCallReturn): eType is an enumeration of either SHUTDOWN_NORMAL or SHUTDOWN_SISTE A. pLIamadaVuelta is the object of the callback defined above. DLL Download will occur after the call to turn off has been made (or time exhausted to occurred). Since the return call can be made asynchronously, the agent may have to wait for the argument that made the call back to exit before continuing to download the security engine DLL. This allows the store frame of the callback to unwind to a point outside the DLL that will be downloaded and avoids an exception in the process. If the callback is made during the Shutdown call, this extra step is not necessary, because the arguments of the security engine are assumed to be turned off. Errors are recorded as operational events that would otherwise be ignored because the Agent will still be closed anyway.

Functional Call of Policy Preparation This method is called by the agent when it receives an update policy. The resulting policies are merged and each ConfigureRegla is built to pass to the correct security engine. The XML data is passed as an Orient object that can be used by MSX L (Microsoft XML), either DOM (Document Object Model) or SAX (Simple API for XML), to read the XML data. This method is defined as follows: HRESULT PreparedPolicy ([entry] Current * Setsetscurrentp, [entry] CallAgentl * pCallbackReturn); Streaming Game Rules is a COM interface to a Stream object that allows the reading of the XML Rules Game. This current can be assumed as being local to the machine and there is no access to the data through the network. pLIamadaVuelta is the object of the return call defined above. If the call returns an error, the security engine is assumed to continue running the previously applied policy (which may be a reset time policy). The agent calls a Retirement Policy for all security engines whose Prepared Policy is successful, but not for any security engine. This process is initiated as soon as any security engine returns an error. Also, if the call - from Prepare Policy does not arrive in a timely manner, the agent treats this as a failure in the part of this security engine. Therefore, the security engines assume that the agent can call Retire Policy before the Call Prepare Policy has returned.

Function Call Policy This method is called by the agent when all the security engines have returned successful in the Prepare Policy calls. This call originates that they change to the new policy. This method is defined as follows: HRESULTADO AssignPolitica (null); This call is synchronous, and the agent will wait for a call to complete before moving to the next call. In one mode, it is expected that all work that could fail, a policy update is made in the call Prepare Policy and this call is a simple change from the old data structures to the new ones. The AssignPolitical method returns catastrophic failures, such as a failure in communications between the User's parties and the Kernel (central module of the operating system) of the security engine. When this call does not return an error, the agent tries to reload the previous policy and reapplies that policy. Since there was an error, this may not work and the application of the policy will be left in an unknown state. An operational error will be recorded by the agent if Assign Policy fails.

Calling the Remove Policy Function This method is called by the agent when a security engine returns an error in its call Prepare Policy. This call causes the agent to call all other security engines to abort the update and revert to the policy in application. This method is defined as follows: RESULT Politics Remove (null); This call is asynchronous because the expected withdrawal processing of the security engines is extensive, to large, features reflecting this in the handling of Prepare Policy. When the security engine finishes processing this call, the security engine calls Complete to indicate the retirement status. If the policy is withdrawn, any data recorded after PrepararPolítica is deregistered by the agent, the system is removed to the previous group of rules subscribed by each security engine. For this reason, security engines do not discard their local copies of orphaned data until they receive the so-called Political Agent Assignment call. The agent is responsible for the management of the timing window where the calls of ReadYRegistrarData of the security engines arrive during the withdrawal of the policy. The RemovePolicy and Complete calls can return catastrophic failures. It is expected that the security engines implement Prepare Policy in such a way that withdrawal can be supported. An operational error is recorded by the agent when Retire Policy fails. You can not assume anything about the status of the policy application through the security engine and there is no cooperation from any security engine after this happens. Future updates of the policy will continue to be sent to the security engine.

Calling the Write Function This method is called by the agent when a part of the data that the security engine has previously called ReadYRegisterData ofNotification for changes. The parameters are similar to the call ReadYRegistrarData, except that the property of the memory belongs to the agent, so the security engine should not eliminate the issue once it is processed. WriteData is not called when the security engine is in the process of receiving a new agent policy; that is, between calls to Prepare Policy and Assign Policy / Remove Policy. Any changes in the data detected by the agent at this time are assigned to batches and sent to the interested security engines once the new policy has been assigned or withdrawn. The waiting queue for pending updates is optimized by the agent to avoid as much as possible the communication of multiple consecutive changes to the same data part. The WriteData method is defined as follows: #define DF_DINAMICO 0x1 #define DF_COLECTION 0x2 #define DF PERSISTENT 0x8 HRESULT WrittenData ([entry] REFGUID guidIDData, [entry] DPALABRA Banderasdw, [entry] DPALABRA SizeDwdd, [entry] D VARI ANTE Datavar, [entry] DPALABRA SizeCalvedw, [entry] byte * ValueClavepb); The parameters to pass a key (ClavedValue, ClareValue) are used when passing context associated with a previous investigation back to the security engine. The security engine uses this context to correlate the result of the investigation with a previous InvestigatorUser call that is issued to the agent. These extra data are necessary because a given investigation can occur multiplied the different contexts in the same rule, for example, questioning the user if the application X has permission to modify a value of the record, then asking the same question about the application Y The errors registered as Operational Events in another way are ignored. Future updates to the same data part will still be reported to the failed security engine. If the security engine wants to prevent this, you can call DeregisterDataNotification for that part of the data.

Calling the Write Write Function This method allows the agent to distribute configuration data to the interested security engines. Once the security engine has read the configuration data using the Read and Write Notification Configuration method, you will be informed of the changes to that data through the agent call to this method. The method is defined as follows: H RESULT Write rConfiguration ([entry] WCHAR * NameDayswsz, [entry] VARIANT Datavar); NombreDatoswsz is the name of the Text of the article of the written configuration data, and is the name used in the registry for this data. Datosvar is the variant structure that contains the article of the individual data that the name represents. This data can be of various types, depending on what type of data is in the record. The agent does not write verifying, the security engine is expected to verify the type of data as required, according to the context. Errors are recorded as Operational Events but are otherwise ignored. Future updates to the parameter data of the same configuration will still be reported to the failed security engine. If the security engine wants to prevent this, you must call Deregister ConfigurationNotification for that data part. A particular security engine typically does not call the agent while an agent API call is already pending. The agent treats this as an error and ignores the second call.

Function Call ReadYRequestDataNotification This method allows a security engine to read data from the dynamic rules data subsystem for use in its data processing. Once the security engine has read the data, you will be informed of the changes to that data through the agent that calls the WriteData method of the MotorSecure I security. The method is defined as follows: H RESULT ReadYRegistrarDataNotification ([entry] REFGUID guidIDDAtos, [output] PALABRAD * Banderaspdw, [output] PALABRAD * SizeDadppw, [output] VARIANT * Datospvar); guidIDData is the GUID of the data item to retrieve. Banderaspdw is a group of flags that describes the data item. The example values can be DYNAMIC or STATIC as well as COLLECTION or BOOLEANS. SizeDatapdw is the variant structure that contains a reference to the arrangement of the data items, Datospvar is the variant structure that contains a reference to the arrangement of the data items, or the value of the data item for Boolean data types. The variant is empty at this point. It is a mistake for a security engine to ask for data that is no longer in the policy. The agent will generate an Operational Event in any error. In this case, there is no guarantee that the security engine and the agent have a consistent view of the affected data.

Calling the WriteDat function This method is called by the security engine when a part of the data changes that the security engine owns and publishes (due to persistence, or use through other security engines). The parameters are similar to the call WriteData, except that the property of the memory belongs to the security engine, so the agent does not delete the article once it is processed. The method is defined as follows: HRESULT WroteDataSE ([entry] REFGUID IDDataguid; [entry] PALABADADDATAdw; [entry] VARIANT Datavar); This method can be called at any time, including while another call to WriteDATA is still pending, or in any argument. It is the agent's responsibility to ensure serialization, if necessary. The owner of the data item is identified in the collection definition through a GUID that defines the owner. This could be the GUID of a security engine or an identifier for the agent, or possibly an identifier for another consumer. If a security engine defines a collection that it owns, it is assumed that the data will be published to the agent through this API. The agent will record any error as an Operational Event. The security engine decides whether or not to continue providing updates after an error. There is no guarantee that the agent's version of the data is consistent with the view of the security engine after an error.

Calling the Unregistration FunctionDataNotification This method allows a security engine to stop the receipt of written notifications for data items that it is no longer interested in. The method is defined as follows: I SULTED UnregisterDataNotification ([entry] REFGUID IDDatosguid); IDDatoguid is the GUID that identifies the item of data for which the security engine is no longer interested in change notifications. The security engine may indicate that you want to deregister all current notifications through passing in the Null GUID. { 00000000-0000-0000-000000000000 } . The agent will record any error as an Operational Event. This includes the case where the data is not known by the agent, to assist with diagnosis of the policy administration problems.

Calling the GetDataAttribute Function This method allows a security engine to retrieve a particular attribute associated with a data item. The name of the attribute is the same as the name that is in the XML Policy, including the case of the text. Attribute values can only change when a policy is changed, so there is no necessary notification system for this data. The method is defined as follows: RESTART Get DataAstribute ([entry] REFGUID dataID, [entry] WCHAR * NameAttributewsz, [output] VARIANT ValueAtributevar); This method can be called at any time.

IDDatosguid is the GUID that identifies the data item to retrieve the attribute. NameAttribute sz is the name of the attribute, exactly as it is in the policy document. ValorAtributopvar is the value of the attribute as a Variant.

The rules for assigning the normal output parameter apply. The agent assigns a new variant with the information and it is the responsibility of the caller to release it later.

Function Call Read and Manage Configuration Notification This method allows a security engine to read the agent configuration data. Once the security engine has read the configuration data, it will be informed of the changes to that data through the agent by calling the WriteConf method of the MotorSecurity I interface. The configuration data for the agent and its host security engines can be located under a common root. The method is defined as follows: RESULT ReadYRegistrarConfigurationNotification ([entry] WCHAR * NameDatsz, [exit] VARIANT * Datospvar); NombreDatoswsz is the name of the Text of the article of the configuration data to be retrieved, and is the name used in the registry for this data. This identifies the individual article relative to the root of the common agent. The driving character '\' is not required. The value is case-sensitive, but characters in white spaces are important. Datospvar is the variant structure that contains the article of the individual data that represents the name. This data can be of various types, depending on what type of data is in the record. The agent does not verify the type, the security engine is expected to verify the type of data as required, according to the context. The agent will record any errors as an Operational Event.

Calling the DecryptConfigurationNotification Function This method allows a security engine to stop receiving the WriteConfiguration notifications for the data items in which it is no longer interested. The method is defined as follows: HRESTED UnregisterSettingNotification ([entry] WCHAR * NameDayswsz); NameDatoswsz is the name of the Text that identifies the article of the configuration data in which the security engine is no longer interested in changing notifications.

The agent will record any error as an Operational Event. This includes the case where the data is not known to the agent, to help with a diagnosis of configuration management problems.

Calling the User Search Function This method allows a security engine to ask an agent to display a specific message to the user, returning a response that the user selected. The agent can also save this response in temporary memory, and persist with that value on the restart of the agent. The question that is presented to the user may contain specific information about why this question is being asked to the user. This information can be provided through the security engine and can be different each time the method is called. How the agent decides if this question has been questioned before and what the answer is, is determined through the key information that the security engine provides. The call returns to the security engine immediately. The security engine then suspends the operation of the session / argument that triggered this search until it is notified of a response. This happens when the user's keys in a response, or when the Search expires. The processing of the spent time is handled by the agent. At this point, the agent updates the article of the relevant data with the answer in code or by default, and notifies the security engine of the result with its associated context. Since obtaining a response to such searches is critical in terms of time, this API can be called at any time through a security engine that is applying a rule that requires a search to be issued. The method is defined as follows: H ESULTED UserSearch ([entry] REFGUID ArticleSearchguide, [entry] PALATE SizeClavedw, [entry] byte * ValueClavepb, [entry] ARREG THE EGURUS (VARI ANTE) Parameters Searchingvar); The SearchBreak article is the GUID of the data article that contains the base strings that are used to ask the user the question, and provide the possible answers to that question. SizeClavedw is the length of the Key Value, in bytes. ValorClavepb is the group of bytes that defines the unique key for this search. ParametersSearchpvar is a Secure Arrangement of the Variants that contains the search parameters that are to be substituted within the search text that is displayed to the user.

The order and syntax of the parameters is defined through the type of rule with which this SearchSearch action is associated. The agent will return an error if the data item is not identifiable. Errors in the execution of the search will be recorded as Operational Events. In this case, the default action is returned to the security engine.

Function Call Complete This method notifies the agent that a security engine has completed the processing associated with an earlier asynchronous call from the agent to that security engine. Although the particular security engine can potentially have more than one asynchronous agent call pending, the agent handles the internal state of each security engine in such a way that the context of the particular Completion callback is ambiguous. The method is defined as follows: HRESULT Complete ([entry] HRESULTADO CodeTermination hr); The TermRogTerm is the return code of the asynchronous call that the agent previously made to this security engine.

Using the user interface The following describes example restrictions on how these APIs are used to interact with one or more security engines. At a particular time, the security engine is in a certain state with respect to its interactions with the agent. The following list identifies the possible states of the safety motor.

The allowed interactions between the agent and the security engines can be formalized as a group of tables define the APIs that can be called by each entity, when a security engine is in a particular state, and what change of state or other actions need to be taken by the safety motor as a result. The state of the agent operation is assumed in normal operation at all times, while the security engines are loaded into memory. The status boxes cover the following phases of the life cycle of the safety engine: Start Update policy from the Shutdown agent Any combination of API call and security engine status not covered in these tables can be considered an abuse of the API. It is the responsibility of the one who calls the API to avoid such abuse. The following status box defines the permitted sequences of the APIs during the start of the security engine, and the state changes of the security engine according to the agent entries. A call to any API not listed as an allowed entry for the list of states associated with the initialization of the security engine involves a protocol error in the calling party's part.

Start Engine Status Pending Start Security Agent API Calls Start Start ERROR Shutdown ERROR Termination_ Pending Write Configuration ERROR OK Calls to the API of the Complete Security Engine (OK) ERROR EnOperation (not policy) Complete (Fail) ERROR Termlnación_Pendiente Read and Register Configured ERROR OK n Notification The following state table defines the allowed API sequences during the policy update, and the associated security engine state changes. A call to any API not listed as an entry allowed here for the list of states associated with the policy update implies a protocol error in the calling party's part.

State of the Engine of EnOperation Prepare_Policy Security Calls of API of the Agent PrepararPolítica Preparando_Política ERROR Write Settings OK OK Calls to API of the security engine Complete (OK) ERROR Policy_Prepared Complete (Fail) ERROR EnOperation (old policy) Read and Register Settings OK OK Notification Read and Record Data OK OK Notification An example of the update sequence of the global policy, taking into account multiple associated guest security engines, is described below: 1. Each Prepar Policy of the security engine is called. 2. The agent expects each safety engine to call Complete Success or Failure. 3. If no security engine reports a failure, each other security engine will have its called Remove Policy method. 4. If no security engine reports a failure, the ApplyPolitical method is called for each security engine. 5. If another failure is discovered, or if a Shutdown is necessary, before any Apply Policy methods are called the RemovePolitical method is called for each security engine. The following status box defines the allowed API sequences during the shutdown of the security engine, and changes the state of the security engine according to the agent's entries. A call to any API not listed as an allowed entry for the list of states associated with the initialization of the security engine involves a protocol error in the calling party's part.

State Start, Shutting calls API In operation, Agent Preparar_Política, Política_Preparada Withdraws r_Pol ít ica Shutdown Shutting ERROR API Calls Completed ERROR Terminación_Pendiente Next collection types sample supported by the agent are listed, and descriptions regarding how each collection passes as dynamic data through the calls to the methods LeerYReg istrarDatosNotif icacion y escribirDatas. Many of the data items discussed below can be handled by passing an individual BSTR string, or by packing unassigned integers in a variant type LONG or LARGOLARGO. Those items that do not fit easily into this model are: GrupoDirectorio, GrupoProtocolo, and GrupoDirecciónlPv4. For each of these types, a packet system is suggested that packages the data into a BSTR string to allow easy transfer in a SecureArrangement. FileFile Past data for each article: Filename-string Implementation: BSTR GroupDirectory Past data for each article: Directory Name - Repetitive Chain - Flag Balanced BSTR implementation - "Repetitive flag: Chain Repetitive flag is an individual character - 'R' - Repetitive 'F' - Plane Registration Group Past data for each article: Key Name Registration - Chain Implementation: Packed BSTR - "Repetitive flag: Repetitive flag chain is an individual character - 'R' - Repetitive 'F' - Planto Protocol Past data for each item: Primary / Secondary - String or Enumeration Type IP - String or Enumeration Address - String or Enumeration Port or Port Range - One or Two Integers (16 bits, integers not assigned).

I MPLEMENTATION: Packaging LARGOLARGO: 1 Byte - Primary / Secondary 1 Byte - Type UP TCP / UDP 1 Byte - Address Input / Output / Both 1 Byte - No use 2 Bytes - End Port Range (or zero) 2 Byte - Home of the Port Range (or Port) Process Group Past data for each item: Name or Path Process - Chain Implementation: BSTR GrupoPuertoRed Past data for each article: Port or Port Range - One or Two Integers (16 bits, unassigned integers) Implementation: Packed LONG: Start = Low Word, Fi nal = High Word Alta word is zero but there Puerto Range GrupoDirecciónRedlPv4 past data for each item: one of: IPv4 Address - Chain (may contain wildcards) IPv4 Address Range - 2 FQDN Chains - Chain Host Name = String Implementation: BSTR packed "T: Chain 1: Chain 2" T - type - A character for Address, Range Address, Host Name or FQDN String 1 - Address, Home Address, Host Name or FQDN Chain 2 - Final Address Range Address User Group Past data for each item: User Account Name - Chain Implementation: BSTR GroupUser Group Past data for each item: Name User Group - Chain Implementation: BSTR FileFileOp: Past data for each article: File - Chain (or Enumeration) Implementation: BSTR GroupQpDir Past data for each item: Operation Directory - Chain (or Enumeration) BSTR implementation GroupOpProceso Past data for each item: Operation Process - Chain (or Enumeration) Implementation: BSTR GroupOpClaveReqistro Past data for each item: Operation Key Record - Chain (or Enumeration) Implementation: BSTR GroupOpValue Register Past data for each item: Operation Value Register - Chain (or Enumeration) Implementation: BSTR UserGroup Past data for each item: User Account Operation - Chain (or Enumeration) BSTR implementation GroupOpGroupuser Past data for each article: Operation User Group - Chain (or Enumeration) Implementation: BSTR GrupoQpTrabaio Past data for each article: Operation Work - Chain (or Enumeration) Implementation: Generic BSTR Past data for each item: Value - Chain Implementation: BSTR Search Group For the security engine, the Search Group appears as a collection of individual items that contains the result of a user search. The associated context is passed to the security engine as a separate parameter. The internal structure of the Search Group is typically not necessary for a security engine, only the context and the search result.

Boolean (Definirbool) Past data for the individual item: Boolean - True or False I implementation: LONG - False = 0, True = 1 Figure 9 illustrates a computer environment 900, which can be used to implement the techniques described herein. The 900 computer environment is only one example of a computing environment and is not intended to suggest any limitations on the scope of use or functionality of computer and network architectures. Neither shall the 900 computer environment be interpreted as having any dependency or requirement related to any or a combination of the components illustrated in the 900 computer environment of the example. The computer environment 900 includes general purpose in the form of a computer 902. One or more media player applications may be executed by the computer 902. The computer components 902 may include, but are not limited to one or more processors or processing units 904 (optionally includes a cryptographic processor or co-processor), a system memory 906, and a common conductor of system 908 that couples various system components including processor 904 to system memory 906. The driver common system 908 represents one or more of any of several types of common conductor structures, including a memory driver or memory controller, a point-to-point connection, a small factory, peripheral common driver, an accelerated graphics port, and a local common processor or driver, using any of a variety of common driver architectures. As an example, such architectures may include a common conductor of the Industry Standard Architecture (ISA), the common conductor of the Micro Channel Architecture (MCA), the ISA Enhanced Common Driver (EISA), a local common conductor from the Association of Electronic Video Standards (VESA), and a common Peripheral Component Interconnect (PCI) driver also known as the Mezzanine common driver. Computer 902 typically includes a variety of computer readable media. Said means can be any available means that can be accessed through computer 902 and includes both volatile and non-volatile media, removable and non-removable media. System memory 906 includes computer readable media in the form of volatile memory random access memory (RAM) 910 and / or non-volatile memory, such as read-only memory (ROM) 912. A basic input / output system 914 (BIOS), which contains basic routines that help transfer information between elements within computer 902, such as during startup, are stored in ROM 912: RAM 910 typically contains data and / or program modules that are immediately accessible to and / or currently being operated in processing unit 904. Computer 902 may also include other removable / non-removable, volatile / non-volatile storage media. By way of example, Figure 9 illustrates a hard disk drive 916 that reads from or writes to a non-removable, non-volatile magnetic medium (not shown), a magnetic disk unit 918 that reads from or writes to a removable magnetic disk , non-volatile 920 (eg, a "floppy disk"), and an optical disk drive 922 for reading from or writing to a removable, non-volatile optical disk 924 such as a CD ROM, DVD-ROM, or another optical medium. The hard disk drive 916, the magnetic disk unit 918 and the optical disk unit 922 each are connected to the common conductor of the system 908 through one or more data medium interface 925. Alternatively the hard disk drive 916 , the magnetic disk unit 918 and the optical disk unit 922 each can be connected to the common conductor of the system 908 through one or more interfaces (not shown). The disk drives and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structure, program modules and other data for computer 902. Although the example shows a hard drive 916, a disk removable magnetic 920 and a removable optical disk 924, it will be appreciated that other types of computer-readable media that can store data that are accessible through a computer, such as magnetic cassettes, or other magnetic storage devices, non-volatile memory cards , CD-ROM, digital versatile discs (DVD) or other optical storage, random access memory (RAM), read-only memory (ROM), electrically editable programmable read-only memory (EEPROM), and the like can also be used to implement the system example and computing environment. Any number of program modules can be stored on the hard disk 916, the magnetic disk 920, the optical disk 924, ROM 912 and / or RAM 910, including by way of example, an operating system 926, one or more application program 928, other program modules 930, and program data 932. Each of said operating systems 926, one or more application program 928, other program modules 930, and program data 932 (or some combination thereof) can implement all or part of the resident components that support the distributed file system. A user may capture commands and information on the computer 902 through input devices such as a keyboard 934 and a pointing device 936, (eg, a "mouse"). Other input devices 938 (not specifically shown) may include a microphone, joystick, gaming pad, satellite dish, serial port, scanner, and / or the like. These and other input devices are connected to the processing unit 904 through input / output interfaces 940 which are coupled to the common conductor of the system 908, but may be connected through another interface and common conductor structures, such as a parallel port, a game port, or a universal serial common driver (USB). A monitor 942 or other type of deployment device is also connected to the common conductor of the system 908 through an interface, such as a video adapter 944. In addition to the monitor 942, other peripheral output devices may include components such as speakers ( not shown) and a printer 946, which may be connected to computer 902 through 940 I / O interfaces. Computer 902 may operate in a networked environment using logical connections to one or more remote computers, such as the remote computing device 948. By way of example, the remote computing device 948 can be a personal computer, a server, a router, a network computer, an even device, or another common network node, console of game and the like. The remote computing device 948 is illustrated as a portable computer which may include many or all of the elements and features described herein in relation to the computer 902. The logical connens between the computer 902 and the remote computer 948 are described as a network of local area (LAN) 950, and a general wide area network (WAN) 952. Such networked environments are common places in offices, large enterprise computer networks, intranets and the Internet. When implemented in a LAN-connected environment, computer 902 is connected to a local network 950 through a network interface or adapter 956. When deployed in a WAN-connected environment, computer 902 typically includes a 956 modem or other means for establishing communications through the wide network 952. The modem 956, which can be internal or external to the computer 902, can be connected to the common conductor of the system 908 through the input / output interfaces 940, or other appropriate mechanism. It will be appreciated that the illustrated network connens are illustrative and that other means for establishing a communication link (s) on computers 902 and 948 can be employed. In a networked environment, such as that illustrated with the computing environment 900, the program modules described in relation to the computer 902, or portions thereof, may be stored in the computer storage device. By way of example, and not limitation, the remote application programs 958 reside in the memory device 948. For purposes of illustration, the application programs and other executable program components such as the operating system are illustrated here as discrete blocks, although it is recognized that said programs and components reside at various times in different storage components of the computing device 902, and are executed through the computer's data processor (s). Various modules and techniques may be described herein in the general context of computer executable instruns, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement abstract data types. Typically, the funnality of the program modules can be combined or distributed as desired in various modalities. An implementation of these modules and techniques can be stored in or transmitted through some form of computer-readable medium. Computer-readable media can be any medium that can be accessed through a computer. By way of example, and not limitation, computer readable media may comprise "computer storage media" and "media." "Computer storage media" includes both volatile and non-volatile media, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instruns, data structure, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, non-volatile memory, or other memory technology, CD-ROM, digital versatile discs (DVD), or other optical disk storage, magnetic cassettes magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other means that can be used to store the desired information and that can be accessed through the computer. "Media" typically modalizes computer-readable instruns, data structure, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism. The media also includes any means of information distribution. The term "modulated data signal" means a signal having one or more of its characteristics set or changed in such a way that it encodes the information in the signal. By way of example, and not limitation, the media includes wired media such as a wired network, or direct wired connection, and wireless media such as acoustic wireless, RF, infrared and other wireless media. Combinations of any of the foregoing should also be included within the scope of computer readable media.

Ideally, a programming interface can be viewed in a generic manner, as shown in Figure 10 or Figure 11. Figure 10 illustrates an Interfasel interface as a channel through which a first and a second code segment communicate. Figure 11 illustrates an interface as comprising interface objects 11 and 12 (which may or may not be part of the first and second code segments), which enables the first and second code segments of a system to communicate through of a medium M. In the view of Figure 11, interface objects 11 and 12 can be considered as separate interfaces of the same system and it can also be considered that objects 11 and 12 plus medium M comprise the interface. Although Figures 10 and 11 show a bidirectional flow and interfaces on each side of the flow, certain implementations can only have information flow in one direction (or no information flow as described above) or can only have one interface object in one direction. side. By way of example, and not limitation, terms such as application programming or program interface (API), entry point, method, function, subroutine, remote procedure call, and model interface of the component object (COM) , are included within the definition of programming interface. The aspects of said communication interface may include the method by which the first code segment transmits information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) to the second code segment; the method by which the second segment of the code receives the information; and the structure, sequence, syntax, organization, scheme, timing and content of the information. In this regard, the underlying transport medium itself may not be important for the operation of the interface, whether the medium will be wired or wireless, or a combination of both, as long as the information is transported in the manner defined by the interface. In certain situations, the information may not be passed in one or both directions in the conventional sense, since the transfer of information may be either through another mechanism (for example, information placed in a buffer, file, etc.). ., separated from the information flow between the code segments) or non-existent, such as when a code segment simply accesses the functionality performed through a second code segment .. Any or all of these aspects may be important in a given situation , for example, depending on whether the code segments are part of a system in a loosely coupled or strongly coupled configuration, and as such this list should be considered as illustrative and not limiting. This notion of a communication interface is known to those of skill in the art and is clear from the aforementioned detailed description of the invention. There are, however, other ways to implement a programming interface, and, unless expressly excluded, they are also intended to be encompassed by the claims set forth at the end of this specification. These other forms may seem more sophisticated or complex than the simplistic view of Figures 10 and 11, but nonetheless perform a similar function that achieves the same overall result. Now some alternative implementations of a programming interface will be briefly described.

Factoring A communication from one code segment to another can be achieved indirectly by interrupting communication in multiple discrete communications. This is schematically described in Figures 12 and 13. As shown, some interfaces can be described in terms of divisible groups of functionality. In this way, the functionality of the interface of Figures 10 and 11 can be factored to achieve the same result, it can precisely be mathematically provided 24, or 2 times 3 times 2. Therefore, as illustrated in Figure 12, the function provided by the Interfasel interface can be subdivided to convert the communications of the interface between multiple interfaces Interface 1A, Interface 1B, Interphase 1C, etc., while logging the same result. As illustrated in Figure 13, the function provided by the interface 11 can be subdivided into multiple interfaces 11a, 11b, 11c, etc., while achieving the same result. Similarly, the interface 11 of the second code segment that receives information from the first code segment can be factored into multiple interfaces I2a, 12b, I2c, etc. When factored, the number of interfaces included with the 1st. Code segment does not need to match the number of interfaces included in the 2nd. code segment. In none of the cases of Figures 12 and 13, the functional spirit of the interfaces Interfasel e 12 remains the same as Figures 10 and 11, respectively. The factoring of the interfaces can also follow associative, communicative and other mathematical properties such as factorization can be difficult to recognize. For example, the ordering of operations may not be important, and consequently, a function carried out through an interface may be carried out either before reaching the interface, through another part of the code or interface, or carried out through a separate component of the system. In addition, one with experience in the programming technique may appreciate that there is a variety of ways to make different function calls that achieve the same result.

Redefinition In some cases, it may be possible to ignore, add or redefine certain aspects (for example, parameters) of a programming interface while still achieving the intended result. This is illustrated in Figures 14 and 15. For example, assume that the Interfasel of Figure 10 includes a square function call (input, precision, output), a function call that includes three parameters, input, precision, and output, and which is issued from the 1st. segment of code to 2nd. segment of the code. IF the parameter in between precision does not have to be seen in a given scenario, as shown in Figure 14, it could only be ignored or even replaced with a parameter with no meaning (in this situation). You can also add an unimportant additional parameter. In any event, the functionality of the square can be achieved, while the output is returned before the entry is square by the second segment of the code. Precision can very well be a significant parameter for some downstream or other portion of the computer system; however, once it is recognized that such precision is not necessary for the narrow purpose of calculating the square, it can be replaced or ignored. For example, instead of passing a valid precision value, a significant value such as a date of birth can be passed without adversely affecting the result. Similarly, as shown in Figure 15, the interface 11 is replaced by the interface 11 ', redefined to ignore or add parameters to the interface. The interface 12 can similarly be defined as an interface 12 ', redefined to ignore unnecessary parameters, or parameters that can be processed elsewhere. The point is that in some cases a programming interface can include aspects, such as parameters, that are not necessary for some purpose, and can be ignored or redefined, or processed elsewhere for other purposes.

Online code It may also be feasible to merge some or all of the functionality of two separate code modules just as the "interface" between them changes shape. For example, the functionality of Figures 10 and 11 can be converted to the functionality of Figures 16 and 17, respectively. In Figure 16, the Prior Code Segments 1o. and 2nd. they are merged into a module that contains both. In this case, the segments of the code will still be communicating with each other but the interface can be adapted to a form in which it is most suitable for an individual module. In this way, for example, formal Call and Return arguments may no longer be necessary, but similar processing or response (s) consistent with the Interfaser interface may still be in effect. Similarly, as shown in Figure 17, part (or all) of the interface 12 of Figure 11 can be written online at the interface 11 to form the interface 11. As illustrated, the interface 12 is divided into I2a and I2b, and the portion of the interface I2a has been coded in line with the interface 11 to form the interface 11". For a concrete example, consider that interface 11 of Figure 11 makes a call to the square function (input, output), which is received by interface 12, which after processing the value passed with input (to square it) through the second segment of the code, it passes back to the square result with output. In such a case, the processing performed by the second segment of the code (square entry) may be performed by the first segment of the code without a call to the interface.

Di orcio A communication from one segment of the code to another can be achieved indirectly through the division of communication into several multiple discrete communications. This is described schematically in Figures 18 and 19. As shown in Figure 18, one or more parts of the middleware (Divorce Interface (s)), since these divorce the functionality and / or functions of the interface of the original interface) are provided to convert the communications of the first interface, Interfasel, to conform them to a different interface, in this case the interfaces lnterfase2A, lnterfase2B and lnterfase2C. This could be done, for example, where there is an installed base of applications designed to communicate with them, an operating system according to an Interfasel protocol, but then the operating system is changed to use a different interface, in this case Interfaces lnterfase2A, lnterfase2B and lnterfase2C. The point is that the original interface used by the 2nd. Segment of the Code is changed, in such a way that it is no longer compatible with the interface used by the 1st. Segment of the Code, and therefore an intermediary is used to make the old and the new interface compatible.

If similarly, as shown in Figure 19, a third code segment can be introduced with the divorce interface DI1 to receive the communications of the interface 11 and with the divorce interface DI2 to transmit the functionality of the interface to, for example, the I2a and 12b interfaces, redesigned to work with DI2, but to provide the same functionality result. Similarly, DM and DI2 can work together to translate the functionality of interfaces 11 and 12 of Figure 11 to a new operating system, while providing the same or a similar functional result.

Rewriting Still another possible variant is to dynamically rewrite the code to replace the functionality of the interface with something else but achieving the same overall result. For example, there may be a system in which a segment of the code presented in an intermediary language (for example, Microsoft IL, Java ByteCode, etc.) is provided to a Fair-A-Time (JIT) compiler or interpreter in an environment of execution (such as that provided by the .Net framework, the Java operation time environment, or other similar operating time environments). The JIT compiler can be written as to dynamically convert the communications of the 1st. Segment of the Code to 2nd. Segment of the Code, that is, to conform them to a different interface as may be required by the 2nd. Segment of the Code (either the original Code Segment or a different one). This is described in Figures 20 and 21. As you can see in Figure 20, this method is similar to the Divorce scenario described above. It could be done, for example, where an installed application base is designed to communicate with an operating system according to an Interfasel protocol, but then the operating system changes to use a different interface. The JIT Compiler could be used to configure the communications on the fly from the base applications installed to the new interface of the operating system. As described in Figure 21, this method of dynamically rewriting the interface (s) can be applied to dynamically factor or otherwise alter the interface (s) as well. It is also observed that the previously described scenarios to achieve the same or a similar result as an interface through alternative modalities can also be combined in several ways, seriously and / or in parallel, or with another code intervening. In this way, the alternative modalities presented above are not mutually exclusive and can be mixed, compared and combined to produce the same or equivalent scenarios to the generic scenarios presented in Figures 10 and 11. It is also observed that, with most of the programming constructions, there are other similar ways to achieve the same or a similar functionality of an interface which will not be described herein, but nevertheless they are represented by the spirit and scope of the invention, ie, it is observed that it is for at least partially the functionality represented by, and the advantageous results enabled by, an interface that underlies the value of an interface. Although the above description uses a language that is specific to structural features and / or methodological actions, it is understood that the invention defined in the appended claims is not limited to the specific features or actions described. Instead, the specific features are described as illustrative ways of implementing the invention.

Claims

1. A programming interface modeled in one or more computer-readable media, comprising: a first group of related functions for communicating a new security policy to a plurality of security engines, wherein each of the security engines is configured to replace an existing security policy with the new security policy; and a second group of related functions to communicate an indication to each good disposition of the security engine to implement the new security policy.

2. A programming interface according to claim 1, wherein the first group of functions includes a method that instructs each of the plurality of security engines to eliminate the new security policy.

3. A programming interface according to claim 1, wherein the first group of functions includes a method that initializes a particular security engine. A programming interface according to claim 1, wherein the first group of functions includes a method that instructs each of the plurality of security engines to implement the new security policy. 5. A programming interface according to claim 1, wherein the first group of functions further comprises a method that communicates the new data associated with an existing security policy to at least one of the plurality of security engines. 6. A programming interface according to claim 1, wherein the first group of functions further comprises a method that communicates the configuration information to at least one of the plurality of security engines. A programming interface according to claim 1, wherein the second group of functions includes a method that indicates whether a particular security engine has implemented the new security policy. 8. A programming interface according to claim 1, wherein the second group of functions further comprises a method that retrieves the updated data associated with a particular security policy. 9. A programming interface according to claim 1, wherein the second group of functions further comprises a method that communicates the new data identified through one of the plurality of security engines to a security agent. 10. A programming interface according to claim 1, wherein the second group of functions further comprises a method that allows one of the plurality of security engines to search for a user of a system containing a plurality of security engines. 11. A programming interface according to claim 1, wherein at least one of the plurality of security engines implements an antivirus service. 12. A programming interface according to claim 1, wherein at least one of the plurality of security engines implements a firewall application (f irewall). 13. A programming interface according to claim 1, wherein the plurality of security engines implements the new security policy after all security engines have indicated a willingness to implement the new security policy. 1

4. A computer system that includes one or more microprocessors and one or more software programs, the one or more software programs uses an application program interface to implement a security policy in a plurality of security engines, the interface of the application program comprises the following functions: a first function that communicates a new security policy to the plurality of security engines; a second function that identifies if each one of the plurality of security engines is prepared to apply the new security policy; and a third function that instructs each of the plurality of security engines to implement the new security policy after determining that all security engines are prepared to implement the new security policy. A computer system according to claim 14, further comprising a fourth function that causes each of the plurality of security engines to eliminate the new security policy if at least one of the plurality of security engines is unable to apply the new security policy. 16. A computer system according to claim 14, further comprising a fourth function related to the communication of the event information identified through a first security engine to the other security engines. A computer system according to claim 14, further comprising a fourth related function for communicating security-related information identified by a first security engine to an event administrator. 18. A computer system according to claim 17, wherein the event administrator communicates security-related information to at least one of the plurality of security engines. 19. A computer system according to claim 14, wherein at least one of the plurality of security engines is associated with a first type of security attack. 20. A computer system according to claim 19, wherein at least one of the plurality of security engines is associated with a second type of security attack. 21. A method that comprises: calling one or more of the first functions that facilitate the communication of a security policy to a first security engine; call one or more of the second functions to facilitate the determination of whether a first security engine has applied the security policy; and calling one or more of the third functions to facilitate the communication of the information related to security from the first security engine to a second security engine. 22. A method according to claim 21, wherein the information related to security identifies a type of security attack. 23. A method according to claim 21, further comprising calling one or more of the fourth functions to facilitate interaction with a user of a system containing the first security engine. 24. A method according to claim 21, further comprising calling one or more of the fourth functions to facilitate communication of the configuration information to the first security engine. 2

5. A method according to claim 21, further comprising calling one or more of the fourth functions to facilitate instruction to the first security engine and the second security engine to implement the security policy. 2

6. A method according to claim 21, further comprising calling one or more of the fourth functions to facilitate communication of a revised security policy to the first security engine. 2

7. A system comprising: means for displaying a first function that communicates a security-related event to an event administrator; means for exhibiting a second function identifying a plurality of security engines associated with the security-related event; and means to expose a third function that communicates the security-related event to the identified security engines. 2

8. A system according to claim 27, further comprising: means for displaying a fourth function that communicates a new security policy to the plurality of security engines; and means for exhibiting a fifth function that instructs the plurality of security engines to replace an existing security policy with a new security policy. 2

9. A system according to claim 28, further comprising means for displaying a sixth function that instructs the plurality of security engines to eliminate the new security policy if at least one of the plurality of security engines can not. implement the new security policy. 30. A system according to claim 27, wherein the event related to security is the detection of a virus. 31. A system according to claim 27, wherein the event related to security is an unauthorized attempt to access a storage device. 32. A system according to claim 27, further comprising means for displaying a fourth function that notifies the event administrator that a particular security engine has finished processing another function call.