Method and system for generating access policies

[0001] This application is related to U.S. patent application Ser. No. 10/694,151, filed Oct. 27, 2003, entitled “Symmetric Data Security,” naming inventors Nils Bertelsen et al., which is hereby incorporated by reference.

[0002] This patent application claims benefit under 35 U.S.C. 119(e) of the U.S. Provisional application No. 60/587,094 filed on Jul. 12, 2004, entitled: “METHOD AND SYSTEM FOR GENERATING POLICIES”

[0003] The United States Government has a paid-up license in this invention and the right in limited circumstances to require the patent owner to license others on reasonable terms as provided for by the terms of Cooperative Agreement No. 70NANB1H3047 awarded by the United States Department of Commerce, National Institute of Standards and Technology (“NIST”), Advanced Technology Program (“ATP”).

[0004] 1. Field of the Disclosure

[0005] The present disclosure relates generally to generating security policies, and more particularly to generating security policies using a graphical user interface.

[0006] 2. Description of the Related Art

[0007] Configuring security policies for large data models of Enterprise Systems can be a daunting task. For example, modern Enterprise Systems, such as a semiconductor fabrication facility, which themselves may be part of a larger Enterprise System, can use large numbers of fabrication and control tools. Each one of these tools can have hundreds or thousands of data items, events, and alarms that are represented by a data model of the tool.

[0008] The ability to provide users accessibility to some or all of the information associated with an Enterprise System via its data models allows for advantageous collaborative efforts, such as the ability for remote users to assist with eDiagnostics of various portions of the Enterprise System. Security rules are written by security personnel and stored in various formats such as Clips, XML, or proprietary formats. These security rules are implemented by a rule interpretation engine, such as JESS™, which is commercially available from Sandia National Laboratories.

[0009] The writing of complex security rules for data models associated with complex Enterprise Systems can be error-prone, leading to undesirable access to equipment and information by unauthorized users. A system and or method of defining security rules that overcomes these issues would be advantageous.

[0015] The use of the same reference symbols in different drawings indicates similar or identical items.

[0016] A method and system for generating security rules for implementation by a rule interpretation engine to define accessibility to one or more aspects of an Enterprise System is described. The method and system allow a security officer to graphically indicate an operation to be affected by the security rule being defined; a specific aspect of the system affected by the rule; a security regulation to be implemented by the rule; and an access type to be permitted by the rule. Specific embodiments of the present disclosure are better understood with reference to FIGS. 1-18.

[0017] FIG. 1 illustrates, in block diagram form, an Enterprise System 10. The Enterprise system 10 includes aspects 20, data 30, Graphical Security Policy Generator 40, Security Module 50, and Graphical User Interface Device 60.

[0018] In operation, the Graphical Security Policy Developer 40 facilitates definition and generation of security access rules 45 that are to be provided to security module 50 as part of an overall security policy. The Graphical Security Policy Developer 40 supports the generation of security access rules by providing a graphical interface at a device 60 having a display area 62 to facilitate the identification of operations, aspects, and contexts of the Enterprise System 10 for which a security access rule is to be based.

[0019] The operations, aspects, and contexts as provided by the Policy Developer 40 are derived from a plurality of data models of the Aspects of Enterprise System 20. Some of the data models used by the Policy Developer 40 can be available directly from the System 20, i.e. an aspect of the physical System 20 can be accessed by the policy developer 40 directly or through the security module 50 to obtain data model information. In other embodiments, the data models for various aspects of the system 20 are not directly available from the system 20 and need to be provided as part of data 30. The accessed data model information whether received from system 20 directly or otherwise provided may be stored as part of the plurality of data models 35.

[0020] The various aspects and contexts of the Enterprise System 10 are graphically displayed by the Graphical Security Policy Developer 40 to allow development of a rule. Once a rule is developed, it is provided to the security module 50, which will authorize requests 75 to the Aspects of the Enterprise System 20 based upon the rule, and current data and states of the Aspects of the enterprise system 20. In the embodiment illustrated herein, a representation of the current data and states of enterprise system 20, i.e. Enterprise System Contexts 34, are accessed by the Security Module 50 from data area 30. For purposes of discussion, a specific embodiment where Enterprise System 10 is a semiconductor fabrication facility will be discussed. However, it will be appreciated that the Enterprise System 10 can be any of a wide variety of enterprises.

[0021] FIG. 2 illustrates, in flow diagram form, a method in accordance with the present disclosure. At step 210, a first operation is identified from a plurality of operations using a graphical user interface (GUI). The first operation is one of a plurality of operations used to access specific information, provide specific information, or access control operations relating to one or more specific aspects of the Enterprise System 10. The individual aspects that can be affected by selecting the first operation form a set of aspects, that itself is a subset of all aspects of the Enterprise System. FIG. 3 illustrates a GUI having display areas 305, 310, 315, and a scroll bar 312. Display area 305 is illustrated to include user selectable features 306, 406, 506, and 606. Feature 306 is a button labeled OPERATION SELECT, which when selected facilitates graphical identification of the first operation. The user of the GUI defining security access rules is referred to herein, for clarity, as a security officer. Note that a default value of TRUE is displayed at location 507 and is associated with the button labeled ACCESS INDICATOR.

[0022] FIG. 4 illustrates the GUI subsequent to the security officer's selection of the OPERATION SELECT button 306. The selection of button 306 results in display of the drop-down list 307, which lists operations for selection by the security officer. It will be appreciated that drop-down lists are but one embodiment of providing a graphical interface to the security officer for the purpose of selecting items. Any other graphical method suitable for selecting items can be used, including check boxes, radio buttons, menus, and trees.

[0023] In the illustrated embodiment, a cursor 301 is positioned to select the operation labeled OPERATION 2. Examples of various operations that can be selected are illustrated in TABLE 1, and include a sensor read operation, a FTP (File Transfer Protocol) access operation, an equipment register access operation, a define system routine operation, a delete of system routine operation, an activate system routine operation, a de-activate system routine operation, an operation to allow remote operation/control of equipment, and an equipment login operation.

[0024]

TABLE 1
OPERATIONS
	SENSOR READ
	FTP ACCESS
	EQUIPMENT REGISTER ACCESS
	ROUTINE DEFINITION
	ROUTINE DELETION
	ROUTINE ACTIVATE
	ROUTINE DE-ACTIVATE
	REMOTE OPERATION
	EQUIPMENT LOGON

[0025] Additional operations are also anticipated. It will be appreciated that the listed operations can be broadly classified as a data access (read), or as data write operations, where data write operations can include control operations. Therefore, fewer operations may also be used. An example of a specific routine would be a data collection plan routine specified by a requestor to indicate a data collection plan that identifies data to be collected by a tool during processing. A data collection plan activate operation is an operation that can be used to actually activate a specific data collection plan.

[0026] FIG. 5 illustrates the GUI of FIG. 4 after selection of OPERATION 2. For purposes of discussion, OPERATION 2 is considered a sensor read operation used to read sensors associated with tools/equipment of the Enterprise System 10. With respect to the security rule being generated, OPERATION 2 is a specific context of the Enterprise System 10 to be evaluated. This context, OPERATION 2, will be identified by a security regulation in the rule being defined. A textual representation of the rule as currently defined by the security officer is illustrated in viewable area 315. Specifically, as a result of the selection of OPERATION 2 by the security officer, an IF statement is illustrated having a security regulation (clause) that will be true when an operation being evaluated is an OPERATION 2 operation. For example, the rule as currently defined would be found TRUE for any Sensor Read (OPERATION 2) operation. By selecting the WRITE RULE button 606 at this point in time would result in generation of a rule that would allow all sensors to be accessible by a Sensor Read operation (OPERATION 2). Such a rule, if generated, would allow access to sensors independent of any other system contexts. For example, all users would be capable of reading any sensor.

[0027] Note, that value TRUE is a logical access indicator shown at location 507 and is associated with button 506 of FIG. 3. The value at location 507 can be a default value or a selected value modified by selecting the button 506. In a specific embodiment, the logical access indicator may have values of TRUE, FALSE, or CONDITIONAL. The logical access indicator FALSE indicates the rule being defined will deny access to an aspect being accessed when all clauses (security regulations) are true. The logical access indicator CONDITIONAL indicates that a rule being defined will filter data being requested so that it may be modified from its original form, as discussed in greater detail herein, in response to the security regulation conditions being true.

[0028] FIG. 5 illustrates at viewable area 310 a tree-type hierarchical representation of the Enterprise System 10 that includes various branches and leaves. For purposes of discussion, the branch 321 represents a specific equipment type associated with a semiconductor fabrication facility, which in an alternate embodiment could be illustrated as the member of a parent branch. The branch 322 represents a specific piece of equipment of the equipment type associated with branch 321. Branch 323 represents a subsystem, which includes a specific data type, associated with the specific piece of equipment represented by branch 322. The nodes 331-333 are specific data nodes, or leaves, that represent data associated with sensors of equipment 323. It will be appreciated that only a limited number of branches have been illustrated, and that additional branches may exist above branch 321, as a branch belonging to any bottom level branch, or intervening between any existing branches, or branch and node.

[0029] In one embodiment, the Graphical Security Policy Developer 40 will illustrate only the set of Enterprise System branches and leaves (nodes) that relate to aspects that can be affected by the selected operation. For example, the nodes 331-335 of FIG. 5 can each represent only those aspects of the Enterprise System 10 accessible as part of a sensor read operation (OPERATION 2). In an alternate embodiment, the Graphical Security Policy Developer 40 will display branches and leaves of the Enterprise System that are not capable of being accessed by the sensor read operation (OPERATION 2). For example, branch 324 may represent an equipment register that stores an equipment identifier, and is therefore not accessible by a sensor access operation, even though it is illustrated.

[0030] At step 211 (FIG. 2), the security officer selects a subset of nodes capable of being affected by the first operation. The selected subset of nodes, which can include all nodes capable of being affected by the first operation, is selected using the GUI. In one embodiment of the present disclosure, all nodes that can be affected by the first operation are represented in a common data model, such as data model 31 (FIG. 1). In an alternate embodiment, the nodes that can be affected by the first operation are represented in separate data models, such as data model 31 and data model 32. Referring to FIG. 6, the nodes 331-333 each represent sensor nodes represented by a common data model of a semiconductor tool, such as a metrology tool, handling tool, processing tool, or any other tool type. However, there may be other nodes accessible through the viewable areas that are represented in a different data model. For example, one data model allows the policy developer 40 to display the nodes 331-332 of FIG. 6, while a different data model allows the policy developer 40 to display the nodes illustrated in FIG. 9 below 40 to select user and role information.

[0031] In FIG. 6, node 331 includes an asterisk (*) it to indicate it has been selected by the security officer as a member of the subset of nodes pursuant to step 211. The asterisk may represent any discernable graphical indicator, such as color or level of boldness, that indicates its selection. Typically, the security officer selects a node by positioning an arrow over it and clicking, or by similarly selecting a branch to which the node belongs, thereby selecting all nodes in the branch. The accessibility of this node is to be at least partially defined by the rule being defined by the current session. In an embodiment, the security officer through the GUI can select nodes whose accessibility cannot be affected by the selected operation. However, selected nodes not capable of being affected by the current operation will be subsequently ignored during the generation of the security rule, or their selection will otherwise not affect security regulations that incorporate them. Alternatively, nodes not capable of being affected by an operation may be illustrated but not selectable.

[0032] As a result of the node 331 being selected, the textual representation of the rule as currently defined, in area 315, is illustrated to include a security regulation further limiting the IF statement to the context of the operation (OPERATION=OPERATION 2), as described previously, and to the context of the selected aspect (ASPECT=NODE 331). Therefore, the rule as currently defined will only apply to sensor requests to node 331.

[0033] In accordance with an embodiment of the present disclosure, the individual branches and nodes displayed through area 310 can have specific visual properties to indicate whether they are affected by the rule currently being defined. For example, when the logical access indicator of the current rule is TRUE, nodes affected by the rule can have a color based visual property, such as green, to indicate the rule as currently defined will allow access to the node when all clauses of the rule are true. For example, each node and branch of FIG. 5 would be displayed as green to indicate that all aspects (nodes) relating to the selected operation will be accessible by the current rule being defined during a sensor read (OPERATION 2) operation. However, after the selection of node 331 in FIG. 6, only node 331 would be displayed as green, indicating it can be affected by the current rule being defined, and that it will be accessible (TRUE) when security regulations, i.e., IF statement clauses, or contexts, are true. When a rule has a logical access indicator of FALSE, access will be denied when all contexts are true. Nodes that will be denied access will have a different visual property than those when access is to be permitted. For example, a color based visual property on a node, such as red on a node, can indicate that accessibility to that node is to be denied. A different color based visual property, such as yellow, can indicate that the current rule can affect the node, and that the CONDITIONAL logic access indicator is being applied when all contexts are true. Nodes that are not capable of being affected by a current rule can be displayed as black. In one embodiment, the color of a branch reflects access to that node and through propagation, any node or leaf under it that doesn't have a more specific access defined to override it. In an alternative embodiment, a branch containing a single node capable of being affected can acquire that node's color, or it can have a unique color based upon whether there are multiple nodes that may or may not be affected.

[0034] At step 212 (FIG. 2), a security regulation is selected that is based upon a first context represented in a data model separate from the data model containing context information of a node selected at step 211. A security regulation limits the applicability of a rule based on system or requester context. Each clause of a rule is a security regulation that limits the applicability of a rule. FIGS. 9-11 illustrate security regulations being added that are based upon the context of a requestor. Such security regulations specifically include or exclude a rule from applying to a request based on the requester.

[0035] FIG. 7 illustrates selection of the CONTEXTUAL ASPECT button 406. Selections of the CONTEXTUAL ASPECT button 406 by the security officer results in the drop down list 407 being displayed. The security officer can now select a specific aspect of the Enterprise System listed in the drop down list 342 that is to provide a context for the security regulation being selected. In one embodiment, the aspect selected is that of REQUESTOR, wherein the REQUESTOR aspect identifies a source that may attempt to access the aspect, or information associated with the aspect, of the Enterprise System identified at step 211. Selection of REQUESTOR as the particular aspect allows the security officer to generate security rules further based on requester contexts. In a specific embodiment of the present disclosure, information associated with the aspect selected at step 212, such as requestor information, is stored or represented in a data model that is separate from the data model that contains the system aspect selected at step 211 that is to be affected by the rule being defined. Allowing for information associated with separate data models to be accessed or displayed through a GUI facilitates the creation of complicated security rules in a simplified, less error-prone manner.

[0036] FIG. 8 illustrates a representation of a GUI interface, after the security officer has selected ASPECT 3. ASPECT 3 corresponds to a specific aspect of the Enterprise System whose context will affect whether the rule being defined for the subset of nodes selected at step 211 will affect access to the subset of nodes. For purposes of discussion, ASPECT 3 is presumed to be REQUESTOR, which is an aspect type that allows for requestor-based contexts to be identified by the security officer. The DEFINE button 410 is selected by the security officer to go to an alternate GUI display, FIG. 9, to identify aspect specific contexts of the selected aspect type for inclusion in the rule being defined.

[0037] The GUI FIG. 9 is provided by the Graphical Security Policy Developer 40 in response to the selection of ASPECT 3, aspect corresponding to requesters. In the embodiment of FIG. 9, a hierarchical representation of users is illustrated in viewable area 420. While the users listed are human users associated with specific roles, the hierarchical list can also include users that are non-human requesters, such as equipment or applications capable of making access requests. As indicated in FIG. 1, an access request can originate from within the Enterprise System, Access Request 71, or from external the Enterprise System, Access Request, 72. Access requests 71 and 72 can be received from either human or non-human generated requests.

[0038] The embodiment illustrated in FIG. 9 illustrates the group (branch) identified as managers as selected. In an alternate embodiment, selection of a group results in each member marked as selected as well. By marking each member of a group as selected, de-selection of a member of the group by the security officer is readily facilitated. For example, a each member of a group can be selected by selecting the common group indicator. Further indicating at least one member of the third set for exclusion from the second set can also be accomplished through the graphical interface.

[0039] Kate, who belongs to the Engineer group, has been individually selected at the node (leaf) level. To assist the security officer, the display area 425 illustrates a textual representation of the security regulation definition related to the current aspect (requester).

[0040] The logical format that the current textual representation is presented in FIG. 7 is but one possible embodiment that lists contexts in terms of roles and individuals. In an alternate embodiment, all contexts can be listed in the logical format by individuals only. Another embodiment of the disclosure would allow a security officer to select or define the manner in which the textual representation of the requestor clauses is displayed. When the security Officer is done selecting requestor contexts relative to the current aspect (ASPECT 3), the RETURN button 432 is selected to return to the previous screen, now represented in updated form as FIG. 10.

[0041] FIG. 10 represents the GUI of FIG. 8 subsequent to the identification of requestors to be affected by the current rule being defined. The representation of the security rule in viewable area 315 has been updated to include a security regulation based upon a context of Managers and a security regulation based upon a context of Kate. The security officer may continue to add security regulations by selecting additional contextual aspects, i.e. other than ASPECT 3 aspects, using the GUI in a manner similar to that described.

[0042] At step 213, a first rule of a security policy is generated that indicates the accessibility of information associated with each node of the subset of nodes selected at step 211. The generated rule is based upon contextual information selected at step 212, and associated with the second data model and contextual information relating to the subset of nodes selected at step 211 which is associated with the first data model, as well as based upon the operation selected at step 210. For example, with respect to the embodiment describe above, the generated rule will be based upon the OPERATION 2, i.e. sensor read operation, information from the first data model (information identifying node 331), and information from a second data model (user based information).

[0043] In one embodiment, the WRITE RULE button 606 is selected by the security officer to generate the rule in a format to be interpreted by a rules engine. Examples of specific rules formats include CLIPS or XML. Security rules translated to the selected format are then written to text files or data base tables until ready for release. The generated rule is subsequently provided to a rules interpretation engine (not specifically illustrated) of a security module 50 to be interpreted as part of an overall security policy. Examples of rules interpretation engines include JESS, Mandarax, Drools, Eclipse, Common Rules, and iLog.

[0044] FIGS. 1-10 illustrate a specific embodiment of the present disclosure, it will be appreciated that many additional features and specific embodiments exist. Examples of additional features in accordance with the present disclosure are disclosed in FIGS. 11-13 below.

[0045] As previously discussed, a logical access indicator of TRUE indicates that when all contexts of a rule are met an access request is allowed. A logical access indicator of FALSE indicates that when all contexts of a rule are met an access request is denied. A logical access indicator of CONDITIONAL indicates that when all contexts of a rule are met conditional access is allowed. A conditional access is an access that filters, or otherwise modifies the requested information and provides this modified information to the requester. In a specific implementation, the CONDITIONAL indicator includes an indication of a filter to be applied to the data being accessed. For example, a security access indicator of “CONDITIONAL(FILTER1)” would apply a filtering function stored within the file named FILTER1 to the data being accessed. The filter information stored in the file FILTER1 defines how to filter the data being accessed can be a proprietary or standard protocol. Many types of data filtering protocols can be used, such as .XSL files for XML translation. An example of when a CONDITIONAL security access indicator would be used is when it is desirable for a requestor to not have visibility to sensor data when the sensor data is outside of a specific range. The filter function stored in the file FILTER1 would modify the data only when outside the range to change the observed value or to provide no data in response to this condition existing. Another embodiment converts specific values to a range, i.e. <50=Low, 50-100=Medium; and >100=High.

[0046] FIG. 11 illustrates a GUI displayed by the Graphical Security Policy Developer 40 in response to the security officer selecting an aspect referred to herein as a User Correlation aspect. The User Correlation aspect is used to identify specific combinations, i.e. correlations, of users or requesters that are not permitted. The GUI of FIG. 11 illustrates a single option in viewable area 415 labeled MUTUAL EXCLUSION. In a specific embodiment, this option is always selected and serves as a reminder to the security officer that the individuals being selected can access the system in a mutually exclusive manner only. In the viewable area 520, Larry and Kate are illustrated as having been selected. A logical representation of the User Correlation context is displayed as a textual representation in the viewable area 525, and illustrates that security regulations are generated that prohibit either Larry or Kate from being a requestor if the other is already an active requester, i.e. authorized to access information or accessing information. This feature can be used to prevent individuals from working together to determine system information that they would otherwise not be able to determine. Yet, another option allows MASTER/SLAVE operations, where the slave can only have access when the master is not an active requestor. In one embodiment, masters can be represented by a “right mouse click, and be identified by a unique visual indicator relative to a slave, which can be selected with a left mouse click.

[0047] FIG. 12 illustrates another embodiment, whereby the selected aspect, workpiece, relates to a workpiece of the system. The workpiece aspect is used to identify workpiece contexts that will limit access to the aspect(s) selected at step 211.

[0048] Returning to our previous example, the rule being defined applies to node 331, which was selected at FIG. 6. Node 331 is associated with a particular manufacturing tool that performs a manufacturing step one or more a workpieces at a time. However, a particular manufacturing tool does not typically have visibility to specific workpiece information, if any. For example, a particular tool may not have any knowledge of a workpiece that it is currently processing. Instead, workpiece information, including its present location, is typically stored in a separate data model that is used to control the flow of workpieces throughout the Enterprise System. However, selection of WORKPIECE as a specific aspect results in the Graphical Security Policy Developer 40 providing a GUI that allows selection of specific workpiece contexts to the rule being defined.

[0049] In FIG. 12, branch 560, labeled “Lots” indicates that the workpiece being modified is part of a lot, such as a lot associated with a semiconductor manufacturing facility. A branch 565, labeled “Lot ID” can be browsed to identify a specific lot identifier as a context of a security regulation for the rule being defined. Also, by browsing the branch labeled “Lot ID”, individual members (wafers) of the lot can be contextually identified. Therefore, nodes within branch 565 would list individual lot and wafer names or identifiers as specific contexts. Branch 571, labeled “Product Group” can be browsed to select a specific product or product group as a specific workpiece context of a security regulation. Branch 572, labeled “Priority” can be browsed to select a specific priority level as a specific workpiece context of a security regulation. Nodes 573-576 of the branch labeled PRIORITY indicate possible contextual values of HIGHEST, HIGH, RUSH, and NORMAL. As illustrated, the node 573 has been selected, resulting in a textual representation of a security regulation indicated below:

[0050] (WORKPIECE(PRIORITY)=HIGHEST)

[0051] The syntax “WORKPIECE(PRIORITY)” indicates the priority context of a workpiece associated with an aspect selected at step 211, i.e. the NODE 321. Note that the syntax has been chosen for clarity of discussion, and that many other syntax can be used to indicate a workpiece priority context is to be checked.

[0052] Branch 580, labeled “Owner” can be browsed to select a specific owner identifier as may be associated with a specific workpiece as a context of a security regulation. Branch 590, labeled “PROCESS” can be browsed to select a process flow or specific process parameters associated with a specific workpiece context.

[0053] FIG. 13 illustrates another example where CONTEXTUAL ASPECTS 406 has been selected to identify EQUIPMENT. Viewable portion 310 illustrates a tree-type structure for equipment that includes E10 states, as known in the semiconductor industry, 781-786 as leaves of a branch 775, which is a member of the branch 770 TOOL A, which is a member of the branch 765, TOOL TYPE, which is a member of the branch 760, EQUIPMENT. The leaf 784, corresponding to the E10 state Engineering is currently selected and a clause corresponding to the selection is illustrated in area 315.

[0054] FIG. 14 illustrates in flow diagram form, a method in accordance with the present disclosure. More particularly, the method of FIG. 13 indicates how multiple rules based on same or differing aspects can be generated for a specific security policy.

[0055] At step 651, a first operation is identified in a manner similar to that described with step 210 previously. At step 652, a first set of aspects, to be affected by the security rule, are identified in a manner similar to that described at step 211 previously. At step 655, a first set of security regulations are identified. For example, the first set of security regulations can be identified using the CONTEXTUAL ASPECTS button 406 described previously. At step 657, a first security rule is generated based upon the selections made at steps 651, 653, and 655.

[0056] At step 658, without identifying a different operation, a second set of aspects to be affected by the security rule, are identified. Since the current rule being generated is based upon the operation selected at 651, the second set of aspects can be selected to be the same or different from the first set of aspects. At step 659, a second set of security regulations, which may be the same or different from the first set of security regulations, are identified. At step 661, a second security rule is generated based upon the selections made at steps 651, 658, and 659.

[0057] At step 663, a second operation, different from the first operation, is identified in a manner similar to that described at step 210 previously. At step 665, a third set of aspects to be affected by the security rule being defined is identified in a manner described previously. Depending upon the specific operations, it may or may not be possible for an overlap between the third set of aspects and either the first or second set of aspects. At step 667, a third set of security regulations are identified. As before, the third set of security regulations can be identified using the CONTEXTUAL ASPECTS button 406 described previously. At step 669, a third security rule is generated based upon the selections made at steps 663, 665, and 667.

[0058] Though the present disclosure has been discussed primarily with respect to a semiconductor fabrication facility, it will be appreciated the rule generation system and method described can apply to a wide variety of enterprises. For example, an Enterprise System can be any tangible system involved in the manufacture, process, or sale of goods or services. An Enterprise System may itself be part of a larger Enterprise System, as well as comprise multiple Enterprise Systems of its own. For example, a large Enterprise System may have multiple manufacturing and assembly facilities. In turn, each of these facilities may be considered Enterprise Systems. A tangible system is a physical system as opposed to purely a simulated or modeled system. Table 2 illustrates specific examples of high-level tangible Enterprise Systems

[0059]

TABLE 2
ENTERPRISES
FACTORY -- MANUFACTURING
FACTORY -- ASSEMBLY/PACKAGING
REFINERY
SERVICE ORGANIZATIONS

[0060] An aspect of an Enterprise System is a feature of Enterprise System. A specific aspect of an Enterprise System is typically controllable or observable. For example, a temperature sensor is an example of an aspect of an Enterprise System. Examples of broad system aspects are listed in Table 3 and include specific tools (equipment), users, work pieces, and control states.

[0061]

TABLE 3
SYSTEM ASPECTS
EQUIPMENT
USERS
HUMAN RESOURCES
WORKPIECE/INVENTORY
SALES INFORMATION
CONTROL

[0062] A first type of aspect listed is equipment. Within a complex Enterprise System, there can be multiple types of equipment, and within each type, multiple equipment pieces of that type.

[0063] As discussed previously, specific states of aspects are referred to as contexts. Multiple contexts can be associated with a given aspect of an Enterprise System. For example, a manufacturing facility can have a context that indicates it is a production mode or a maintenance mode, and a context to indicate a current operating capacity. A specific aspect may or may not have visibility to its own contexts. For example, a specific tool (aspect) may have visibility, or knowledge, of the existence (context) of its own sensors, or even visibility to states (context) of each sensor, such as ON or OFF. However, the specific tool may not have visibility through its own data model to its own operational state, which can be a context visible only to a different aspect of the Enterprise System, such as a factory control aspect. For example, a control aspect of the Enterprise System can associate a tool with a specific factory, workpiece, or operational context, such as a maintenance mode or a production mode. Table 4 indicates an example of an aspect pertaining to operational states. An operational state is an aspect that may be associated with a tool or other operation of a factory, without the tool having visibility to the state through its data model. Other aspects that may not be visible to the tools to which they apply include: availability of a tool (up or down); amount of use of a tool (time or runs) since last preventative maintenance; qualification state of a tool, etc.

[0064]

TABLE 4
OPERATIONAL STATES
	PRODUCTION
	SCHEDULED MAINTENANCE
	UN-SCHEDULED MAINTENANCE
	ENGINEERING
	STANDBY
	NON-SCHEDULED OPERATION

[0065] A graphical method of identifying specific contexts of pertinence for a rule being defined was described herein with reference to aspect identification (step 211), requestor identification (step 212), and identification of prioritization of workpieces (FIG. 12).

[0066] Various aspects 20 of the Enterprise System 10 of FIG. 1 are illustrated as reference numerals 21, 22, and 23. The data models of these aspects can be stored at the aspects 21-23 themselves, or can be represented in the data portion 30 as corresponding data models, i.e. data models 31, 32, and 33. The actual data and state information for the various aspects 20 of the Enterprise System can be stored at the aspects 21-23, or can be stored as contextual information at the location Enterprise System Contexts 34. For example, for an aspect that is a manufacturing tool with sensors, the sensor data can be accessed at the tool directly, i.e. at Aspect 21. However, other data, such as the tool's E10 state or the priority of a lot at the tool, may not be available at the tool, but instead from the Enterprise System Contexts 34 or directly from a different aspect of the Enterprise System 10. Note, in one embodiment, the security module 50, which contains a rules engine, determines current contexts of the Enterprise System based on data stored in the data portion 30, and not by accessing the aspects of the Enterprise System 20 directly. The specific system aspects of Table 3 can themselves contain additional aspects.

[0067] In many industries, such as the semiconductor industry, the data models of tools are readily accessible from the tools through query operations that can be employed by the Graphical Security Policy Developer 40 or other tool, thereby readily facilitating configuration of the data models 31-33, and the Developer 40 in a dynamic manner to identify aspect changes of the Enterprise System 10. In an alternate embodiment, the data models 31-33 and Graphical Security Policy Developer 40 can be pre-configured with information identifying where their data models representing system aspects and their contexts are stored.

[0068] FIG. 15 illustrates a flow diagram in accordance with a specific method of the present disclosure. At step 831, one or more security rules are generated. For example, the methods and systems described in FIGS. 1-14 can be used to generate one or more security rules. In one embodiment, a plurality of security rules is selected to form a security policy.

[0069] At step 832, a rule simulator is selected from a graphical user interface for operation. In one embodiment, the rule simulator is selected by a button, drop-down menu, or other means, through one or more of the GUI interfaces illustrated previously herein. In one embodiment, the rule simulator may use a rule interpretation engine of an actual security system to provide simulated results.

[0070] At step 833, one or more contexts of the enterprise system are selected from a GUI of the simulator to indicate a current operating condition or state of the enterprise system. FIG. 16 illustrates a specific example of GUI for a simulator that allows aspects including a requester, operation, active users, and facility contexts, i.e. enterprise contexts, to be selected for simulation.

[0071] In the specific example of FIG. 16, the SET REQUESTOR option 806 has been previously selected to identify Larry, who belongs to the group of Managers, as the requester. The ACTIVE USERS window 812 has been previously updated from within the simulator of FIG. 16 to identify David as an active user. An active user can include a user that is currently logged on, or receiving information from the enterprise system. Specific facility contexts are listed in area 822. Presently, a facility context indicating that the equipment is in an E10 state of engineering has been identified, and selection of the button labeled ADD CONTEXT will add the context to further indicate a current E10 state of Engineering to the area 822, see of FIG. 17.

[0072] Referring to FIG. 17, which lists a priority context and an equipment E10 state context in area 822, a selection of the SIMULATE button 825 will apply the identified state information to all rules associated with a tree-type hierarchical representation of a data model or a subset of a data model.

[0073] Once all of the rules are simulated based upon the current contexts, the results are displayed, see step 834. For example, as illustrated in FIG. 17, the results can be displayed in area 310 to illustrate the accessibility of various aspects of the enterprise system. For example, FIG. 17 illustrates the tool and node aspects illustrated in area 310 of FIG. 5 in a hierarchical manner to allow display of simulation results. In one embodiment, aspects not accessible given the enterprise state being simulating are displayed in red, aspects that are accessible given the enterprise state being simulated are displayed in green, aspects that are conditionally accessible, as previously described, are displayed in yellow. For example, node 331 may be red, node 334 may yellow, and nodes 332 and 325 may be green.

[0074] It will be appreciated that other visual indicators besides red, green and yellow can be displayed. It will be appreciated that when multiple rules are being simulated, such as with a specific security policy, that each individual rule may provide different accessibility result for a specific aspect of a system. For example, one rule may allow an aspect of a system to be accessible for a given set of simulation parameters, while another rule would not allow accessibility for the same set of simulation parameter. Typically, the most restrictive access result will be enforced, however, the simulator can be configured, such as through a graphical user interface, to enforce either more or less restrictive access results when differing results are generated for the same aspect by different rules. This allows the simulator to match the operation of the rule interpretation engine.

[0075] Because security rules and policies can be very complex, the ability to simulate specific conditions and graphically view results allows for a greater degree of accuracy during the rule generation process. Typically, the simulator will provide the security policy and simulation information to the security module, which includes a rules engine, for analysis, and receive from the security module 50 accessibility information for each node being viewed.

[0076] The present disclosure has been described with respect to specific embodiments. It will be appreciated that many variations to the disclosed system and method herein are anticipated. For example, a method of logically aggregating aspects of a request within a rule to determine existence of a condition provides further flexibility. For example, it may be desirable determine if an access request is attempting to obtain a certain combination of information, and if so, to prevent access to some or all of the information. FIG. 18 illustrates a flow diagram to facilitate such aggregation requests using a graphical user interface.

[0077] At step 841, a logical aggregation indicator is selected using the GUI to begin the aggregation process. Such an aggregation indicator identifies a clause being defined as an aggregation of contexts to be evaluated based upon an access request, and may be selected using a radio button, menu, list, or other graphical interface. At step 842, aspects to be aggregated, and any corresponding logical modifiers, are selected using a GUI. For example, referring to FIG. 5, nodes 331 and 333 could be selected along with logical modifiers to identify them as nodes to be included in the aggregation clause. Such an aggregation clause can be a logic clause having a syntax of (AGGREGATION ((ASPECT=NODE 331) AND NOT (ASPECT=NODE 333)), where the term AGGREGATION, for the present example, indicates a clause that when evaluated to TRUE by a rules engine will allow access to information associated with NODE 331. Therefore, an aggregation clause can be used to control access to a request for a first data, i.e. node 331 data, based upon whether an access request for a second data, i.e. node 333 data, has also occurred. Note that requests for information are typically submitted as a data collection plan that requests more than one specific piece of information. The use of an aggregation clause can be used to limit a single data collection plan from successfully requesting specific data combinations. For example, a rules engine will not allow NODE 331 to be accessed when the above clause evaluates to true. In an alternate embodiment, a temporal component can be used to prevent access to specific combinations of information within a predetermined time frame. For example, the predetermined time frame can be a fixed amount of time, such as one minute, that is implicit, as part of the aggregation clause itself, or explicitly specified as part of the aggregation clause. Alternatively, the predetermined time frame can be considered to be the amount of time needed to execute a data collection plan, thereby allowing generation of rules that prevent a common data collection plan from accessing specific combinations of information.

[0078] Realizations in accordance with the present disclosure have been described in the context of particular embodiments. These embodiments are meant to be illustrative and not limiting. Many variations, modifications, additions, and improvements are possible. Accordingly plural instances may be provided for components described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of claims that follow. Finally, structures and functionality presented as discrete components in the exemplary configurations may be implemented as a combined structure or component. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure as defined in the claims that follow.