WO2002014988A2

WO2002014988A2 - A method and an apparatus for a security policy

Info

Publication number: WO2002014988A2
Application number: PCT/IB2001/001877
Authority: WO
Inventors: Ofer Gadish; Yuval Baharav; Leon Flysher; Eliyahu Dichterman; Yaacov Brumm; Amichai Zalzman
Original assignee: Camelot Information Technologies Ltd.; Rubin, Yair
Priority date: 2000-08-18
Filing date: 2001-08-20
Publication date: 2002-02-21
Also published as: AU2001294083A1; WO2002014987A8; WO2002015122A3; AU2001294089A1; WO2002014989A2; WO2002014989A8; WO2002014988A8; WO2002014987A2; AU2001294110A1; AU2001294084A1; WO2002015122A2

Abstract

A method and apparatus is disclosed for the creation of a centralized, unified and adaptive security policy to be used in conjunction with agents and access analyzers. The security policy provides flexibility to grant access rights based on adaptively generated permission levels as well as predefined threshold. The security policy operates on users, groups of users, resources and groups of resources and hence provides for a security policy system that is capable of adapting to the actual needs of its users and is easy to maintain. Specifically this apparatus and method may be used for security policy in conjunction with network resources.

Description

A METHOD AND AN APPARATUS FOR A SECURITY POLICY

CROSS REFERENCE TO RELATED APPLICATIONS

[001] This application claims priority to U.S. Provisional Application 60/226,128, filed

August 18, 2000 and U.S. Provisional Application 60/259,575, filed January 04, 2001.

FIELD OF THE INVENTION

[002] The present invention generally relates to computer security systems, and relates more particularly to a system and method for managing and enforcing complex security requirements in a distributed computer network by the use of a central security policy. Moreover, the security policy provides for real-time and adaptive security behavior.

BACKGROUND OF THE INVENTION

[003] Modern computer systems are used by a large number of users having access to system resources through intensive networking systems. These systems are further interlinked in multiple ways to create a world-wide connectivity network that allows differen systems to access resources of another system. However, each system may have resources, such as files, databases, computer peripherals, and other computer resources, having different degrees of importance, frequently requiring the prevention of free, or unrestricted, access from outside as well as from inside a particular network. For example, a business or corporation may have its own local area-network (LAN) that is connected to the Internet in order to allow certain individuals to gain access to the LAN from remote locations. However, the business or corporation often does not want everyone to be able to gain access to all of the resources on their LAN.

[004] A common solution to preventing unrestricted access to system resources from the outside comprises providing a firewall that separates typical resources from the outside, and thus prevents access by individuals outside, or in front of the firewall, to data behind the firewall. For example, Shwed, in U.S. patent 5,606,668 describes such a method where data packets are allowed to either pass through a system, or they are rejected, based on a filter code. Consequently, packets rejected based on the security rule enforced, will either not enter, or be prevented from leaving, the system. While the method disclosed in Shwed deals with packets flowing in to and out of a system, it does not address unauthorized access initiated from within the system.

[005] Another system was suggested by Barlow in U.S. patent 5,204,961, where a

"trust realm" between predefined computers defines a security policy with respect to messages to be transmitted between- the computers. A level of access is determined by multiple factors in addition to the user's identification, such as, the particular computer used, secrecy level, time, and so on.

[006] In U.S. patent 5,996,077, Williams suggests a security system where first and second security devices are connected to form a protected communication link, each such device operating under a specific security policy. The method disclosed by Williams allows for protection of messages between computer systems. Yet another solution for protection from external access is demonstrated in U.S. patent 6,098,173, by Elgeressy et al. The inventors here suggest a system capable of enforcing a security policy to prevent the downloading and execution of undesirable executable objects. By using a software agent on the computer, capable of marking packets, the system disclosed by Elgeressy et al. suggests the possibility of enforcing a predefined security policy. In U.S. patent 6,163,383, Ota et al. suggest a system that further provides a security policy for securing a printer. This allows verification of the right to print and/or distribute certain printed content. Touboul suggests, in U.S. patent 6,167,520, a method of preventing downloads to a computer based on a security policy. A "suspicious" download is defined and a determination is made as to the appropriate response in the event a suspicious download is discovered. The conventional systems discussed above provide methods directed to protecting the system from outside access, however, there is also a need to protect the system from inside access. For example, not all employees of a particular company should be given unrestricted access to all company data. Some of the protection is simplistic, allowing for only limited user control over the access to resources. In other cases, such as the UNIX Operating System (UOS), more sophisticated controls are available. In the UOS, for example, all access levels for the user, her group and the world are defined by the user. Hence, a user can define full access for herself, limited access, e.g., read only, to her group of peers, and no access to anyone else. Another common method of controlling access to a system's resources is an access list that matches resources (documents, files, databases, etc.) with users, and associates, thus defining a user's access permissions to the associated listed resource. Each permission is called a rule or a policy rule, and a system that comprises such rules may be called a security system or a security policy system. When an access is attempted on a resource by a user, this action is referred to as an "access attempt". When an access attempt is made, the access list is consulted to determine whether the access should be permitted or denied, and actual permission is granted or not granted, accordingly. [008] Yet another method of controlling access to resources is according to a table, which is also known as a security policy table. Such a table contains more than one policy rule, preferably one policy rule per entry. When a request for access occurs, the event is checked against each entry, starting from the first one (or from any other predetermined entry) until a matching rule is found and applied. However, such a table is difficult to maintain and is typically updated manually, which is both time consuming and error prone. U.S. patent 5,991,879 suggests a method for gradual deployment of a user-access security within a system, to overcome the update problems mentioned above.

[009] When a new security policy is deployed, a user who is not yet defined under the new policy may be denied access to resources. By using an intermediate security profile, when a user attempts to access a resource to which he previously had access, the system may provide such access to the resource, and possibly, additionally, notify the security administrator of the event. While providing some temporary relief, however, conventional systems still do not satisfactorily address the issue of the actual creation of the table and contending with the dynamic nature of the changes occurring within the organization requiring continuous manual updates to the security policy.

[010] Prior art solutions, for example, Moriconi et al. U.S. patent 6,158,010, may also suggest certain ways to distribute security policies, in Moriconi et al., the inventors disclose a system where a global security policy is distributed to various computers on the network to form the local security policies. Orchier et al. in U.S. patent 6,070,244, suggest a system and method for ensuring compliance of separate computers within a computer network to a centralized security policy. The advantage of this system is its ability to enforce a centrally defined security policy, on local security policies and methods developed in local systems. More specifically, it enforces the general security policies put in place over local procedures. In some cases it may be advantageous to authenticate a security policy through a digital signature as is suggested in U.S. patent 6,202,157, to Brownlie et al. [Oil] However, none of the systems mentioned above provide a single, flexible solution to providing a robust network security system. Thus, there exists a need for a more efficient and more flexible system and method for a security policy for a network of computers and resources,

SUMMARY OF THE INVENTION

[012] An object of the present invention is to provide an improved system to control access to certain system resources. It is a further object of this invention to provide an improved overall security policy system. A security policy in accordance with the present invention may reside in a further improved security policy table. Another objective of this invention is to provide for a security policy where rales may comprise a start time, an expiration period, or a duration of operation. It is a further objective of this invention to provide a security policy system where an action and/or notification may take place based upon permission levels provided by another system as a result of actual run-time data collected and analyzed. It is a further objective of this invention to provide a system where the permission levels are compared with predefined security thresholds. It is another objective of this invention to provide a security policy where rules may have a time scope of operation.

BRIEF DESCRIPTION OF THE DRAWINGS

[013] The object and features of the present invention will become more readily apparent from the following detailed description of the preferred embodiments taken in conjunction with the accompanying drawings in which: [014] FIG. 1 is a block diagram illustrating a system architecture in accordance with the present invention; [015] FIG. 2 is a representation of a security policy table (SPT) in accordance with the present invention; [016] FIG. 3 is an exemplary detailed security policy table in accordance with the present invention; [017] FIG. 4 is a flow chart illustrating a match checking routine between an event and a rule in accordance with the present invention; ^•

[018] FIG. 5 is a schematic illustration of thresholds for Action and Notification in f accordance with the present invention; and

[019] FIG. 6 is a schematic illustration, similar to FIG. 5, further illustrating the use of

Action and Notification thresholds.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[020] A preferred embodiment of the present invention is discussed in detail below.

While specific configurations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art- will recognize that other components and configurations may be used without departing from the spirit and scope of the invention. [021] The architecture illustrated in FIG. 1 is disclosed in the co-pending U.S. Patent

Application, filed on the same date herewith, entitled "An Adaptive System and Architecture for Access Control", and which is assigned to the same common assignee as the present application, and is hereby incorporated herein by reference in its entirety, for all it discloses. [022] Illustrated in FIG. 1 are the three elements comprising Architecture 10: agent

100, control unit 110 and access analyzer 120, having the relationship described in the above-referenced co-pending application. That is, Agent 100 monitors access attempts 108 to the resources (not shown), and provides: a periodic history of events, also known as event audit trail 102, to access analyzer 120; alarms (104) to control unit 120, and, optionally, enforcement 106 to the resource. If an agent 100 is operable to enforce permission grants or denials, also known as "enforcement", in response to access attempts, the agent is referred to as a "guardian" agent. Access analyzer 120 analyzes event audit trail 102, possibly usiμg first security policy 122, and responds, periodically, with a list of permission levels 134, to agent 100, and with statistical information 132 to control unit 120. Based on permission levels 134 received from access analyzer 120 and a second security policy 122' provided by control unit 110, a guardian agent 100 is capable of enforcing the security control of the resources by permitting, alerting, denying, or otherwise controlling access to the resource. The architecture illustrated may allow for use of multiple agents, access analyzers and control units.

[023] First security policy 122, may be identical to second security policy 122', or either one of the two may be a subset of the other. Also, security policies 122 and 122' may reside in control unit 110. Control unit 110, comprises at least a security table 200 illustrated in FIG. 2. Security table 200 comprises rows; each row in security table 200 represents a distinct policy rule 210A-210N (also referred to simply as a "rule"). In the example shown in FIG. 2, the first^'rule 210A has the highest priority and the last rule 2 ION has the lowest priority. However, it will be understood by those skilled in the art that any priority order is possible. [024] Each row, 210A-210N, further comprises at least four sections, identifier 220, event 230, action 240 and control 250. Identifier 220 is used to uniquely identify the rule in policy table 200. Event 230 defines an access attempt to which the respective rale 210A-210N refers. An access attempt may be, for example, an attempt to access a resource of the system. Such an, access attempt can be defined by an event 230, for example, as an attempt by a specific user to modify the content of a defined file during a certain period of time.

[025] The corresponding response 240 defines the response or responses resulting from the match to event 230. For example, in response to a specific event 230, action 240 may be a denial of permission to modify the specified file.

[026] The corresponding control 250 may define certain control functions with respect to the application of an action 240. For example, control 250 may indicate that the rale expired on a previous date, or that the rale should not be applied to the first attempt to modify the file, but should be applied thereafter.

[027] Lastly, control 250 may include a bias column indicating a particular bias that should be provided with respect to the corresponding event. For example, it might be desired that an executive in a company be given a certain bias that increases his or her chances of being permitted access to certain, or all, resources. In this manner a certain level of confidence can be initially provided to certain individuals. On the other hand, it may be desired that the chances of being granted access to certain, or all, resources be reduced for certain individuals. This might occur if, for example, a company is dealing with a particularly difficult employee. In addition to the parameters defined above, it is foreseeable that a person skilled in the art would be able to identify additional ways to define identifiers, events, responses, constraints, delegations (explained below), controls and biases, respective to the subject matter of this invention.

[028] An exemplary detailed embodiment of a security policy table (SPT) 200 is presented in FIG. 3. The security policy table (SPT) 300 comprises at least one of rows 310A-310N, where a single row corresponds to a single rule, and when multiple rows exist, they are prioritized as explained above. Each row has several fields grouped into four groups as explained above. Identifier 220 is implemented in the exemplary SPT 300, by two fields, the "No" field 315 and the "Name" field 320. Using at least one of these two fields allows for unique identification of the rule defined in any given row 310A-310N. The "No" field 315 may contain a sequential number indicating the location of rale 310 in the SPT 300. The "Name" field 320 may be a unique identifier of the rule. For example, name 320 maybe a string of characters such as "access to finance files", "printing on color laser printer", "xyz-123", and so on.

[029] Event 230, which describes a potential access attempt to a system resource, is implemented in the exemplary SPT 300, by four fields, the "User" field 325, the

"Resource" field 330, the "Time Scope" field 335, and the "Access Type" field 340. By using one or more of these fields a system event can be defined. "User" field 325 may identify a single user or a group of users (user group), as defined elsewhere in the system. "Resource" field 330 may be a system resource or system resources to which a particular access attempt is directed. "Time Scope" field 335 may be an indication of a time, possibly including a date, or a time range, possibly including starting and ending dates of the event. "Access Type" 340 indicates the type of access attempted and includes, for example, any combination of read, write, execute, delete, rename, take ownership of, change permissiojas of, modify or create. However, it will be understood by those skilled in the art that any parameter regarding the access attempt is possible. Thus, it is possible to classify the rales according to these parameters, for example: a resource group, a user group, a <resource group, user group> pair, a <resource group, user group, time> triplet, or any other parameters like access type 340, which may be in any combination with the above parameters. Furthermore, it will be understood by those skilled in the art that additional identifier and/or event columns may be added to the embodiment of the SPT.

[030] Optionally, a "Location" column (not shown) may be added to Event 230. In the

Location field a rule can provide information respective to the location from which an access attempt 108 was made. Location may include an Internet protocol (IP) address, a console name, a terminal identifier, and so on. A rule using the Location field could, for example, catch an access attempt 108 to a specific resource if it is made from a designated location.

[031] The response column 240 of FIG. 2 is implemented in the exemplary SPT 300 of

FIG. 3, by four fields, the "Action" field 345, the "Action Threshold" field 350, the

"Notification" field 355, the "Notification Threshold" field 360, and the "Ignore" field

365. Any one or more of these fields defines a specific response to a corresponding event. The "Action" field 345 may contain the specific action taken as a result of the occurrence of a certain event, and may include, but is not limited to, actions such as

"Permit", "Deny" or "Adaptive". A more detailed description of these actions is provided below. A person skilled in the art may easily add additional types of actions.

For example, the action "Delegate" may be added, followed by a reference to another table. This allows to shorten the main SPT 300 table and use a sub-table to address a set of specific cases. For example, the rale in SPT 300 can catch accesses to a resource and delegate further action to a sub-table containing additional rales with finer granularity, such as time scopes, access types, and so on, as well as a variety of possible responses. Another possible action is "Bias" designated to add a positive or negative bias to permission levels associated with the give rule as they apply to a user or a group of users. This can be useful when due to usage patterns it is desirable to increase or decrease permission levels automatically generated by access analyzer 120.

[032] In conjunction with the "Adaptive" parameter the user may use the "Action

Threshold" field 350. Action Threshold field 350 provides a threshold level below which access is denied and above which access is permitted to the resource. Additional detail of the operation is provided below.

[033] "Notification" field 355 may contain the specific notifications) required as a result of the occurrence of an event. The notifications may include, but are not limited to a combination of several types of predefined alerts (including E-mail, ICQ, SNMP Trap and Logging) or the execution of a user-supplied executable program, allowing different types of notifications directed towards different users (the system administrator, for example). A "Notification Threshold" 360 may further be defined, typically in conjunction with the "Adaptive" parameter. In this field, a user may provide a threshold level below which an alarm is issued and above which an alarm is not issued.

[034] The "Ignore" field 365 comprises at least "yes" or "no" values, indicating whether to collect or ignore an event from the event audit trail point of view. If the "Ignore" field has a "yes" value then no event audit trail of the event is provided, i.e., the information of the event is not passed to access analyzer 120 as part of event audit trail 102. Additional detail of the operation is provided below. It will be understood by those skilled in the art that additional response columns may be added to the embodiment of the SPT.

[035] Control 250 is implemented in the exemplary SPT 300, by one field, the

"Activation" field 370. In the activation field 370, the time(s) and date(s) applicable for a rale are indicated. The activation field may include; a start time and date after which the rule becomes effective; the expiration time and date after which the rule becomes ineffective; or a duration, identified as a start time and date and expiration time and date. In the latter case the user may define whether a rale is in effect during such time frame, or not in effect during such time frame. The activation field 370 may be further used with bypass rules as described below. It will be understood by those skilled in the art that additional constraint columns maybe added to the embodiment of the SPT.

[036] In another embodiment of the invention control 250 may have an additional column marked 'Tlow" (not shown), which may contain the parameters: "stop", "continue", or "skip". The purpose of "Flow" is to determine the behavior of the system in the case where multiple matches are allowed. The parameter "stop" is used, when no further rules should be checked for a possible match. The parameter "skip" is used when the respective rale should be skipped and no action or notification should take place. The parameter "continue" is used when the action or notification should take place but match against additional rales must be checked for. In yet another embodiment of the invention, control 250 may delegate further processing to another table. For example, if there exists, within control 250 a delegate column (not shown), an indication that the particular event in the corresponding column should be handled in another server, another table, or otherwise another unit capable of handling a response 240 to event 230, the responsibility for that event is immediately handed over to the specified unit and its corresponding table will be searched, accordingly.

[037] The operation of security system 10 (FIG. 1), in general, may be described in the following example. When an access attempt 108 is intercepted (e.g. when access to a resource is attempted) by the agent 100, SPT 300, may be scanned for the security policy 122, starting at rule 310A, until a match is found between the rule's event definition and access attempt 108. At this stage, the rale's response, as identified in the action field 345 and the notification field 355 may be applied, while considering any applicable constraint 250. In one embodiment of this invention the search of SPT 300 stops when a first match is found. In another embodiment of this invention, the search of SPT 300 is further controlled by the "Flow" column of constraint 250. In another embodiment of this invention, in a case in which there are a number of possible matches between an access attempt 108 and an event in rales 310A-310N, the rule that is the most restrictive in SPT 300 is applied. Alternatively, the most restrictive combination of rules that matched may be applied. Furthermore, in an alternate embodiment, the most permissive of the combination of rales may be applied.

[038] In some embodiments of the present invention, a general rule may be defined for all unknown users and may be located before the last rale 310N of SPT 300. The last rale 3 ION includes all possible access attempts, and thus is considers as a "default rule". If a match is not found, the last rule 31 ON is effected and its response applied.

[039] A user may define a bypass rule, which is a rule that has its activation field set such that it expires by a given date; date and time; after passing a predefined time; completing a predefined number of activations; and the like. Bypass rules may further reside in a SPT dedicated to bypass rales. This may be used by a system administrator to assist in handling transient cases, such as allowing access by a certain user to a certain resource for a specific period of time, or establishing a basic permission level 134 for a new user. FIG. 4 provides an exemplary flow chart 400, illustrating the steps for using the

SPT 300. In step 410 the system waits for the next access attempt 108, which may be, for f example, an access attempt to a system resource. When such an access attempt 108 is present, the parameters of the access attempt are compared against the content of the

SPT in step 415. If a match is not found in step 420 then the system returns to step 410 to wait for the next access attempt. Otherwise, the rule which was found to match is checked, in step 425, to determine whether the rule is active. This is done by checking activation field 370 of the constraint 250 group. If the rule is inactive, the system will return to wait (410) for the next access attempt 108. Otherwise, the system checks, in step 430, whether the rale is of the Adaptive type. Action and Notification thresholds are defined in "Action Threshold" 350 and "Notification Threshold" 360, respectively. If the rule is not of the adaptive type then, in step 435, the applicable Action and

Notification are executed in accordance with the content of fields 345 and 355 of the respective rule. However, if the rale is of the adaptive type, then the system compares the permission level with the activation thresholds. Permission levels 134 are provided by access analyzer 120 to the agent 100 and in conjunction with security policy 122 or

122', which may reside in the SPT 300, a final resolution of action and notification takes place. A more detailed description is provided with respect to FIG. 5 below. If the permission level is greater or equal to the Activation Threshold then the access is permitted 445, otherwise access is denied 450. Next, the necessity for providing a notification is also assessed such that if the permission level is greater or equal to the Notification Threshold 455 then no notification is provided, otherwise a notification is provided 460. The system then waits for the next access attempt 108 to occur 410.

[041] The operation of the adaptive rule can be further described referring to FIG. 5.

Assuming that the permission levels are provided as a number between "0" and "1", a threshold can be defined which distinguishes between two distinct possibilities. In the case of the Action 510 two possible values are "Deny" 530 and "Permit" 540. The border between the two is defined by "Action Threshold" 550. If a permission level 134 is above the Action Threshold 550, then the Action 510 is to permit access to the system resource. If a permission level 134 is below the Action Threshold 550 then the Action

510 is to deny access to the system resource. Similarly, the system can operate on

Notification 520, by defining whether a notification takes place "560" or is unnecessary

570. The border between the two is defined by "Notification Threshold" 580. If a permission level 134 is above the Notification Threshold 580 then no notification 570 is f required when an access attempt is made to a system resource. If a permission level 134 is below the Notification Threshold 580 then the notification is required when an access attempt is made to a system resource. [042] The nature of the "adaptiveness" of the system should be specifically noted as a case where in system 10, access analyzer 120 provides periodically updated permission levels 134, and the security policy 122, 122' provides only the threshold levels for the responses. Such periodical update of permission levels 134 is done based on the event audit trail 102 provided by agent 100 to access analyzer 120. It should be further noted that the Action Threshold 550 and the Notification Threshold 580 do not have to have the same value and, as a result, an access attempt to a system resource may result in a combination of responses, including, but not limited to permission with no notification, permission with notification, and denial with notification. [043] In another embodiment, the thresholds can be designated with simple and homogenous values that allow the system to automatically adjust through its normal operation. It will be understood by those skilled in the art that additional threshold levels could be added. [044] The process of defining a security policy using SPT 300 (FIG. 3) and enforcing it according to the invention may be separated into two parts: the rules set-up (which may occur once a day or at other intervals) and the run-time process, which is continuous. [045] For example, security policy 122, 122' may be set-up in the following manner:

[046] 1. The administrator of security system 10 creates the rules and specifies to whom they apply, using control unit 120 (FIG. 1). [047] 2. Control unit 120 sends the data concerning the users, resources and their corresponding rales (arrows 122 and 122') to access analyzer 120 and agent 100. [048] 3. An agent sends the then available event audit trail (arrow 102) to access analyzer 120. [049] 4. Access analyzer 120 analyzes the data received from control unit 120 and agent 100 and responds with updated permission levels (arrow 134). [050] 5. Agent 100 stores the permission levels received from access analyzer

120. [051] It should be noted that multiple agents, control units with a central control, and access analyzers may be used to create the security system 10. The run-time process, which is the continuous behavior of security system 10, is described above and is repeated each time an access attempt 108 occurs. [052] An access attempt 108 is intercepted by agent 100, and a matching process (FIG.

4) is performed: agent 100 scans its copy of SPT 300, starting with the first rule 310A (or with any other rale), until a match is found with a rule. After a rule is matched to access attempt 108, it is activated by agent 100. The rale's response is determined by its action 345 and notification 355, and further based on the applicable constraints 250. The action of the matched rale is checked (decision 430) and may be strict (435) or adaptive. If action 345 is adaptive, then the specific action is determined according to the specific permission level 134 and action threshold 350, and similarly, the nature of notification 355 is determined according to the specific permission level 134 and the notification threshold 360. In some embodiments, agent 100 (FIG. 1) may send access analyzer 120 (FIG. 1) an event audit trail 102 which saves the information relative to access attempts 108. The may occur after a pre-defined number of events have occurred, an elapse of a certain time period, or for any other reason. Event audit trail 102 is used as an input to a learning algorithm. Event audit trail 102 may include all information regarding an access attempt, such as user(s), resource(s), access type, time, response, etc. The subject matter of the operation of an access analyzer and the process of learning is the subject matter of the co-pending U.S. Patent Application, filed on the same date herewith, entitled "Permission Levels Generation Based on Adaptive Learning", and which is assigned to the same common assignee as the present application, and is hereby incorporated herein by reference in its entirety, for all it discloses.

[053] FIG. 6 illustrates the different scenarios that are possible with respect to action threshold 550 and notification threshold 580. For example, as shown in FIG. 6, three different permission levels, LI, L2 and L3 are shown. If a particular access attempt 108

(FIG. 1) is determined to have a permission level 134 of LI, the access attempt would be denied, since LI is below action threshold 550, in addition, a notification 520 would be generated since LI is also below notification threshold 580. This type of scenario may occur when, for example, access to a particular resource is attempted by a user, group of users, etc., that has a very low probability of requiring access to this resource.

[054] If an access attempt 108 is determined to have a permission level L2, access to the resource would be granted, since L2 exceeds action threshold 550. However, a notification would be generated as permission level L2 is below notification threshold 580. This type of scenario might occur if, for example, access to a particular resource is attempted by a user, group of users, etc., that statistically might require access to the particular resource, thus access is granted, but the probability of that user needing access to the resource is small enough to warrant notifying the appropriate person(s), e.g., the system administrator, as a precautionary measure.

[055] Lastly, if an access attempt 108 is determined to have a permission level L3 with respect to a particular resource, access to the resource will be granted and no notification is generated. This might occur if, for example, a user that clearly has a need to access the resource has initiated the access attempt and, thus the resulting permission level is well above the action threshold 550 and also above the notification threshold 580.

[056] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

Claims

WHAT IS CLAIMED IS:

1. A computer network security system, the security system comprising:

at least one agent operable to identify an access attempt directed to a resource on the f network and further operable to respond to said access attempt in accordance with at least a permission level;

at least one access analyzer operable to analyze an event audit trail and provide said permission levels to said agent; and

at least one control unit operable to provide a first security policy to at least said access analyzer.

2. The system of claim 1, wherein said control unit provides a second security policy to said agent, wherein said second security policy can be the same as or different than said first security policy.

3. The system of claim 1, wherein said access analyzer provides said agent with only deny or permit status for each potential access attempt.

4. The system of claim 3, wherein permission levels correspond to at least said access attempt.

5. The system of claim 1, wherein said first security policy comprises at least one security rule.

6. The security system of claim 1, wherein said access attempt comprises at least one of: a user, a resource, a location, an access type, a time.

The security system of claim 6, wherein said user may be one or more users.

8. The security system of claim 6, wherein said resource may be one or more resources.

9. The security system of claim 6, wherein said location may be one or more locations.

10. The security system of claim 6, wherein said location may be an Internet protocol address.

11. The security system of claim 6, wherein said location may be a console identifier.

12. The security system of claim 6, wherein said location may be a terminal name.

13. The system of claim 6, wherein said access type includes at least one of; read, write, execute, delete, rename, take ownership of, change permissions for, modify or create, said resource.

14. The system of claim 1, wherein said permission levels are based on at least an event audit trail.

15. The system of claim 14, wherein said event audit trail is based on at least a user access attempt.

16. The system of claim 14, wherein said event audit trail is based on at least a resource use.

17. The system of claim 14, wherein said event audit trail is based on at least an access type.

18. The system of claim 17, wherein said access type includes at least one of; read, write, execute, delete, rename, take ownership of, change permissions for, modify or create, said resource.

19. The system of claim 14, wherein said event audit trail is based on at least a time scope.

20. The system according to claim 5, wherein said security rale(s) are comprised in a table.

21. The system of claim 20, wherein the security rules are prioritized from the highest priority to the lowest priority.

22. The system of claim 21, wherein the rale applied for said access attempt matches at least one of:

a) user or user group;

b) resource or resource group;

c) access type or access types;

d) time or time within time scope.

23. The system of claim 21 , wherein a most restrictive rule is applied in response to said access attempt.

24. The system of claim 21, wherein a most permissive rale is applied in response to said access attempt.

25. The system of claim 21 , wherein a most restrictive action within each of a respective number of fields conesponding to said security rales is applied in response to said access attempt.

26. The system of claim 21 , wherein a most permissive action within each of a respective number of fields conesponding to said security rules is applied in response to said access attempt.

27. The system of claim 5, wherein each security rale comprises an identifier field, an event field, a response field, and a control field.

28. The system of claim 27, wherein said identifier field comprises at least a numerical sub-field.

29. The system of claim 27, wherein said identifier field comprises at least an alpha-numerical sub-field.

30. The system of claim 27, wherein said event field comprises at least a user sub- field.

31. The system of claim 30, wherein said user sub-field comprises an identification of a group of users.

32. The system of claim 27, wherein said event field comprises at least a resource sub-field.

33. The system of claim 32, wherein said resource sub-field comprises an identification of a group of resources.

34. The system of claim 27, wherein said event field comprises at least a location sub-field.

35. The system of claim 34, wherein said location sub-field comprises at least an internet protocol address.

36. The system of claim 34, wherein said location sub-field comprises at least a console name.

37. The system of claim 34, wherein said location sub-field comprises at least a terminal identifier.

38. The system of claim 27, wherein said event field comprises at least a time- scope sub-field.

39. The system of claim 38, wherein said time-scope may contain at least one time interval.

40. The system of claim 39, wherein said time interval contains a daily start time and daily stop time.

41. The system of claim 39, wherein said time interval contains a weekly start time and weekly stop time.

42. The system of claim 39, wherein said time interval contains a monthly start time and monthly stop time.

43. The system of claim 39, wherein said time interval contains a yearly start time and yearly stop time.

44. The system of claim 39, wherein said time interval is a start time and start date as well as a stop time and stop date.

45. The system of claim 27, wherein said event field comprises at least an access type sub-field.

46. The system of claim 45, wherein said access type sub-field comprises at least one of; read, write, execute, delete, rename, take ownership, change permissions, modify or create.

47. The system of claim 27, wherein said response field comprises at least an action sub-field.

48. The system of claim 47, wherein said action sub-field comprises one of at least the following actions: permit, deny, adaptive, delegate or bias.

49. The system of claim 48, wherein if said action sub-field is adaptive, said adaptive action has a conesponding action threshold sub-field.

50. The system of claim 49, wherein said action threshold sub-field comprises at least one action threshold.

51. The system of claim 50, wherein said action threshold is a predefined constant applicable for all of said rales.

52. The system of claim 48, wherein said delegate results in the continuation of checking for at least one rule conesponding to said access attempt in a separate security policy indicated by said delegate instruction.

53. The system of claim 48, wherein said bias results in adding a bias value to a said permission level value.

54. The system of claim 53, wherein said bias value is a positive value.

55. The system of claim 53, wherein said bias value is a negative value.

56. The system of claim 27, wherein said response field comprises at least a notification sub-field comprising a type of notification.

57. The system of claim 56, wherein said type of notification comprises at least one of the following: no notification, e-mail, ICQ, SNMP Trap, logging, or program execution.

58. The system of claim 48, wherein if said action sub-field is adaptive said adaptive notification has a conesponding notification threshold sub-field.

59. The system of claim 58, wherein said notification threshold sub-field comprises at least one notification threshold.

60. The system of claim 59, wherein said notification threshold comprises a predefined constant applicable of all of said rales.

61. The system of claim 27, wherein said response field comprises at least an ignore sub-field.

62. The system of claim 61, wherein said ignore sub-field comprises an indication whether said event audit trail should be activated or deactivated with respect to a conesponding access attempt.

63. The system of claim 27, wherein said control field comprises at least an activation sub-field.

64. The system of claim 63, wherein said activation sub-field comprises at least a start date.

65. The system of claim 64, wherein said activation sub-field further comprises ; start time.

66. The system of claim 63, wherein said activation sub-field comprises at least an expiration date.

67. The system of claim 64, wherein said activation sub-field further comprises an expiration time.

68. The system of claim 27, wherein said control field comprises at least a flow sub-field.

69. The system of claim 68, wherein said flow sub-field may have at least one of: stop, skip, or continue values.

70. The system of claim 69, wherein said stop value forces the ceasing of further search within said security policy.

71. The system of claim 68, wherein said skip value forces the continuation of the search within said security policy without activation of said action of said rule.

72. The system of claim 68, wherein said continue value forces'the continuation of the search within said security policy with activation of said action of said rale.

73. A security system, said system comprising:

a security policy with at least one adaptive rule, wherein said adaptive rule, upon identification of at least one access attempt, determines a response.

74. A security system according to claim 73, wherein an access attempt comprises at least one of the following:

user access;

use of a resource;

a location;

an access type; or,

a time scope.

75. A security system according to claim 73, wherein the security policy is implemented within a security policy table.

76. A security system according to claim 73, wherein said response is selected from at least the group consisting of: permit, deny, adaptive, delegate or bias.

77. A security system according to claim 76, wherein said adaptive response conesponds with at least one threshold.

78. A security system according to claim 77, wherein a first threshold value of said adaptive rule defines whether to respond with a first action or with a second action.

79. A security system according to claim 78, wherein if said permission level value exceeds said first threshold value then said first action is a permission to access a resource.

80. A security system according to claim 78, wherein if said permission level value does not exceed said first threshold value then said second action is a denial of access to a resource.

81. A security system according to claim 77, wherein a second threshold value of said adaptive rale defines whether to respond with a notification or not to respond with a notification.

82. A security system according to claim 73, wherein said response comprises an action conesponding to said access attempt.

83. A security system according to claim 73, wherein said response comprises a notification conesponding to said access attempt.

84. A security system according to claim 73, wherein said rule further comprises of at least a control field.

85. A security system according to claim 84, wherein said control comprises at least a time period constraint.

86. The security system of claim 84, wherein said control field further comprises a flow sub-field that may have at least one of: stop, skip, or continue values.

87. The security system of claim 86, wherein said stop value forces the ceasing of further search within said security policy.

88. The security system of claim 86, wherein said skip value forces the continuation of the search within said security policy without activation of said action of said rale.

89. The security system of claim 86, wherein said continue value forces the continuation of the search within said security policy with activation of said action of said rule.

90. A security policy table used to implement security with respect to resources, said security policy table comprising:

at least one adaptive rule, wherein said adaptive rale, upon identification of at least one access attempt, determines a response.

91. The security policy table according to claim 90, wherein said resources are network resources.

92. A security policy table according to claim 90, wherein said access attempt comprises at least one of the following:

user access;

use of a resource;

location;

an access type; or,

a time scope.

93. A security policy table according to claim 90, wherein said response is selected from at least the group consisting of: permit, deny, adaptive, delegate or bias.

94. A security policy table according to claim 93, wherein an adaptive response conesponds with at least one threshold.

95. A security policy table according to claim 94, wherein a first threshold value of said adaptive rule defines whether to respond with a first action or with a second action.

96. A security policy table according to claim 95, wherein if said permission level value exceeds said first threshold value then said first action is a permission to access a resource.

97. A security policy table according to claim 95, wherein if said permission level value does not exceed said first threshold value then said first action is a denial of access to a resource.

98. A security policy table according to claim 94, wherein a second threshold value of said adaptive rule defines whether to respond with a notification or not to respond with a notification.

99. A security policy table according to claim 90, wherein said response comprises an action conesponding to said access attempt.

100. A security policy table according to claim 90, wherein said response comprises a notification conesponding to said event.

101. A security policy table according to claim 90, wherein said rale further comprises of at least a control field.

102. A security policy table according to claim 101, wherein said control comprises at least a time period constraint.

103. The security policy table of claim 101, wherein said control field further comprises a flow sub-field that may have at least one of: stop, skip, or continue values.

104. The security policy table of claim 103, wherein said stop value forces the ceasing of further search within said security policy.

105. The security policy table of claim 103, wherein said skip value forces the continuation of the search within said security policy without activation of said action of said rale.

106. The security policy table of claim 103, wherein said continue value forces the continuation of the search within said security policy with activation of said action of said rule.

107. An adaptive rale used for security of resources, wherein said adaptive rale, upon identification of at least one access attempt directed towards said resources, determines a response to said access attempt.

108. An adaptive rule according to claim 107, wherein said resources are network resources.

109. An adaptive rule according to claim 107, wherein said access attempt comprises at least one of the following:

user access;

use of a resource;

location;

an access type; or,

a time scope.

110. An adaptive rule according to claim 107, wherein said response is selected from at least the group consisting of: permit, deny, adaptive, delegate or bias.

111. An adaptive rule according to claim 110, wherein said adaptive response conesponds with at least one threshold.

112. An adaptive rule according to claim 111, wherein a first threshold of said adaptive rule defines whether to respond to said access attempt with a first action or respond to said access attempt with a second action.

113. An adaptive rule according to claim 112, wherein if said permission level value exceeds said first threshold value then said first action is a permission to access a resource.

114. An adaptive rule according to claim 112, wherein if said permission level value does not exceed said first threshold value then said second action is a denial of access to a resource.

115. An adaptive rule according to claim 111, wherein a second threshold of said adaptive rule defines whether to respond to said access attempt with a notification or not to respond to said access attempt with a notification.

116. An adaptive rule according to claim 107, wherein said response comprises an action conesponding to said access attempt.

117. An adaptive rule according to claim 107, wherein said response comprises a notification conesponding to said access attempt.

118. An adaptive rale according to claim 110, wherein said delegate results in the continuation of checking for at least one rale conesponding to said access attempt in a separate security policy indicated by said delegate instruction.

119. An adaptive rale according to claim 110, wherein said bias results in adding a bias value to a said threshold value.

120. An adaptive rale according to claim 119, wherein said bias value is a positive value.

121. An adaptive rule according to claim 119, wherein said bias value is a negative value.

122. An adaptive rule according to claim 107, wherein said rule further comprises of at least a control field.

123. An adaptive rale according to claim 122, wherein said control field comprises at least a time period constraint.

124. An adaptive rale according to claim 122, wherein said control field further comprises a flow sub-field that may have at least one of: stop, skip, or continue values.

125. An adaptive rale according to claim 124, wherein said stop value forces the ceasing of further search within said security policy.

126. An adaptive rale according to claim 124, wherein said skip value forces the continuation of the search within said security policy without activation of said action of said rale.

127. An adaptive rule according to claim 124, wherein said continue value forces the continuation of the search within said security policy with activation of said action of said rale.

128. A method for controlling at least one access attempt directed to at least a resource, the method comprising:

creating at least a security rale, wherein each of said security rules defines a response to a conesponding access attempt and at least one security rule is an adaptive security rule;

identifying each access attempt;

scanning said security rules until a.match is determined between each of said access attempts and a corresponding security rale; and,

upon finding said match, activating said response.

129. The method of claim 128, wherein said resource is a network resource.

130. The method of claim 128, wherein an access attempt comprises at least one of the following:

user access;

use of a resource;

location;

an access type; or

a time scope.

131. A method as claimed claim 128, wherein said response is selected from at least the group consisting of: permit, deny, adaptive, delegate or bias.

132. A method as claimed in claim 131, wherein said adaptive response conesponds with at least one threshold.

133. A method as claimed in claim 132, wherein a first threshold of a said adaptive rule defines whether to respond to said access attempt with a first action or to respond to said access attempt with a second action.

134. A method as claimed in claim 133, wherein if said permission level value exceeds said first threshold value then said first action is a permission to access a resource.

135. A method as claimed in claim 133, wherein if said permission level value does not exceed said first threshold value theri said second action is a denial of access to a resource.

136. A method according to claim 132, wherein a second threshold of a said adaptive rale defines whether to respond to said access attempt with a notification or not to respond to said access attempt with a notification.

137. A method according to claim 128, wherein said response comprises an action conesponding to said event.

138. A method according to claim 128, wherein said response comprises a notification conesponding to said access attempt.

139. A method according to claim 131, wherein said delegate results in the continuation of checking for at least one rule conesponding to said access attempt in a separate security policy indicated by said delegate instruction.

140. A method according to claim 131, wherein said bias results in adding a bias value to a said permission level value.

141. A method according to claim 140, wherein said bias value is a positive value.

142. A method according to claim 140, wherein said bias value is a negative value.

143. A method according to claim 128, wherein said scanning of said rules is performed in an order starting from high-priority rales and continuing to lower priory rules.

144. A method according to claim 143, wherein said scanning ceases upon a first match of said event to a said access attempt.

145. A method according to claim 128, wherein said rules are placed in a security policy table.

146. A method according to claim 128, wherein said activating said rule's response comprises gathering an event audit trail of said access attempt.

147. A method according to claim 146, wherein said gathering comprises periodically sending said event audit trail for analysis purposes.

148. A method according to claim 147, wherein said sending is done automatically.

149. A method according to claim 147, wherein said sending is done upon request.

150. A method according to claim 128, wherein said activating said rule's response does not include gathering an event audit trail of said access attempt.

151. A method according to claim 128, wherein said activating said response comprises reporting said access attempt.

152. A method according to claim 128, further comprising generating at least a permission level.

153. A method according to claim 152, wherein said permission level is based on at least an event audit trail.

154. The method according to claim 153, wherein said permission level is further based on at least a security policy.

155. A method according to claim 152, wherein said activating said response comprises granting permission with respect to said access attempt based on at least permission levels.

156. A method according to claim 152, wherein said activating said response comprises denying permission with respect to said access attempt based on at least permission levels.

157. The method of claim 128, wherein scanning rales continues until all matched access attempts have been identified.

158. The method of claim 157, wherein a most restrictive rule is applied in determining an appropriate response to said access attempt.

159. The method of claim 157, wherein a most permissive rale is applied in determining an appropriate response to said access attempt.

160. The method of claim 157, wherein a most restrictive action with respect to each respective field of the rales is applied in determining an appropriate response to said access attempt.

161. The method of claim 157, wherein a most permissive combination with respect to each respective field of the rales is applied in determining an appropriate response to said access attempt.

162. A method according to claim 128, wherein said security rule further comprises of at least a control field.

163. A method according to claim 162, wherein said control field comprises at least a time period constraint.

164. A method according to claim 162, wherein said control field further comprises a flow sub-field that may have at least one of: stop, skip, or continue values.

165. A method according to claim 164, wherein said stop value forces the ceasing of further search within said security policy.

166. A method according to claim 164, wherein said skip value forces the continuation of the search within said security policy without activation of said action of said rule.

167. A method according to claim 164, wherein said continue value forces the continuation of the search within said security policy with activation of said action of said rule.