EP1159812A1 - Systeme de securite informatique - Google Patents

Systeme de securite informatique

Info

Publication number
EP1159812A1
EP1159812A1 EP00910452A EP00910452A EP1159812A1 EP 1159812 A1 EP1159812 A1 EP 1159812A1 EP 00910452 A EP00910452 A EP 00910452A EP 00910452 A EP00910452 A EP 00910452A EP 1159812 A1 EP1159812 A1 EP 1159812A1
Authority
EP
European Patent Office
Prior art keywords
entity
security
gpe
access
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00910452A
Other languages
German (de)
English (en)
Inventor
Eugen Bacic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Texar Software Corp
Original Assignee
Texar Software Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Texar Software Corp filed Critical Texar Software Corp
Publication of EP1159812A1 publication Critical patent/EP1159812A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]

Definitions

  • This invention relates to the field of computer networks, and in particular to a security server for providing a network with sophisticated access controls.
  • suppliers may wish to give third party customers limited access to their networks in order to facilitate design, ordering and accounting functions.
  • Such third parties must not, however, have access to confidential corporate data, although in the case of co-operative design work, for example, there may be specific data files that the customer is authorized to access that would not normally be available to external organizations. This requires the ability to exercise highly sophisticated access control.
  • VPNs virtual private networks
  • virus protection To meet security concerns, many organizations have opted for firewalls, virtual private networks (VPNs), and virus protection. These are commonly referred to as first generation security solutions. General access to host systems is provided based on the premise that once authenticated, users can be given full freedom to perform their duties.
  • first generation products protect only the perimeter, but they are islands of security, each performing a single task very well. They operate under their own control and their own rules; they do not play well with others, such as in the case of the third party customer example given above. These products have been defined and refined to control external access to information and ensure that only legitimate users gain access to networks and their resources. Once a user is past these defences, little, if any, security exists to protect valuable corporate information assets.
  • Windows NT and UNIX systems offer access controls, but these are often implemented incorrectly, or disabled altogether, due to previous bad experiences on the part of users or systems administrators. Moreover, they are sufficiently different to offer little help in integrating security.
  • First generation security products can be viewed as offering a wall of protection around information stores. Even though this wall may be sufficiently strong to thwart outside attack, it does not dissuade attack from the most common access point: the inside. These products are not designed to stop authorized users from accessing information. They are meant primarily to authenticate that a user is authorized to access the resources on the network. Once inside, few checks are performed, giving the user free rein.
  • outsider Threat This is an external individual or group attempting to breach the security of the system. Outsiders breach communications access controls but operate under the constraints of the communications protocols. This is the standard cracker attack. Outsider attacks are typically defended against by proper system administration and correctly designed and implemented access-control protocols and mechanisms, such as virtual private networks (VPNs) and firewalls.
  • VPNs virtual private networks
  • Malicious Software This is a piece of malicious code introduced into the system. The attack takes place within the communications perimeter, but remains bounded by the general access available to the operating system and the executing user. Malicious software may be introduced with or without a user's consent. The most common forms of this attack are the virus and Trojan horse.
  • Insider Threat the perpetrator is an individual with authorized access to the system. An insider may have wide-reaching control of the system or its components. The perpetrator may opt to replace hardware or software, and may observe any communications channel. This attack occurs within the boundaries of the VPNs or firewalls as the perpetrator is an authenticated user. Insider threats commonly come from disgruntled or compromised employees.
  • a solid defense against insider threats can deter perpetrators by ensuring that they will get only a poor return on their investment. Such a defense can limit the damage done, minimize the information stolen or modified, and ensure that the perpetrator can be caught. In many cases, such a defence can stop most attacks, alerting authorities and ensuring that the threat is limited to system components which the insider generally has access to.
  • a second generation security product that provides security across the network, security which is highly trustworthy, which is configurable to the needs of clients, which can be fully integrated with existing technology, and which is centralized for audit and administrative purposes.
  • Security policy refers to the rules governing the flow of information between two entities via predefined means and channels.
  • a policy engine is a program that defines in logic those governing rules for a particular security policy, typically located within a trusted operating system. This patent presents a new method for the generation of policy engines using a high-level, verifiable language and generic security functionality.
  • security policies are accomplished in two stages, analysis followed by synthesis.
  • a natural language description of the security policy model is created so that it can be verified as reflecting the policy for the product being developed.
  • the second stage describes this security policy model as a contrivance of logic within the actual product.
  • a method of controlling access to a network wherein security policies are determined by using a verifiable language consisting of formal definitions of the syntax and semantics.
  • a generic policy engine uses the language to execute a policy in order to mediate access to an object entity by a subject entity.
  • the invention abstracts the security information from the physical data.
  • Denotational Semantics has gained particularly wide acceptance among semanticists and language designers. This patent bases the verifiability of the language defined on the provability of systems developed using Denotational Semantics, such as VLISP.
  • the invention provides a security policy engine known as Generic Policy Engine (GPE) for controlling access to a network in accordance with policies determined with the aid of a verifiable language consisting of formal definitions of the syntax and semantics.
  • GPE Generic Policy Engine
  • Security policies can be developed more efficiently, in a greater variety, and with comparable or greater trust than with traditional implementations.
  • Security policies developed with the Generic Policy Engine (GPE) using the security language can be customized to reflect end-user security requirements as opposed to single-purpose security policies in common usage today.
  • information neutral architecture In order to provide for a generic policy engine a general, information neutral architecture must be used, one that is applicable across all operating systems or applications (henceforth collectively called "products"). Information must be encapsulated by the security measures required.
  • the granularity of the information encapsulated defines the granularity of the security provided.
  • the information thus encapsulated is the entity against which the GPE operates.
  • the GPE provides a trusted, extensible mechanism by which to implement security not only on a local system but also across heterogeneous networks. Providing custom security policies that provide equivalent trust to those currently in use and with similar efficiency would be a major advancement in the information security field.
  • To attain this level of flexibility with the Generic Policy Engine one must have at one's disposal a high-level, verifiable language. All security relevant architecture must be written using this language which provides both the formalisms required for high security systems as well as the implementation specifics necessary to integrate it into a viable product. Such a language, which is referred to as Idyllic, will be described along with its use as the base language of the Generic Policy Engine.
  • Idyllic is a Scheme dialect.
  • the Generic Policy Engine comprises a language interpreter plus the associated security extensions and functionality coupled with the ability to generate executable security policies.
  • Idyllic provides a representation to easily define and implement verifiable security policies.
  • Entities are the unified security object against which all security related functions are performed. Both the base security application and any ancillary security relevant applications utilize entities in order to manage and maintain the security attributes of the applications.
  • entity-based approach to the name space being secured, the advantages of encapsulation and, to some extent, inheritance can be leveraged to create a succinct language definition for the creation of security policies.
  • the new approach is to utilize a language renown for its small footprint, efficiency, and simplicity and use it to implement security policies.
  • Embedding the GPE as a secure extension with a system provides a trusted, extensible mechanism by which to implement security not only locally but across networks, within operating systems or applications, such as Web servers.
  • the Generic Policy Engine provides system and application developers a means by which to provide equivalent trust to systems currently in use with smaller footprints and with at least equivalent verifiability, speed, and efficiency.
  • security policies can be developed more efficiently, in a greater variety, and with comparable or greater trust than traditional implementations.
  • Security policies developed with the Generic Policy Engine can be customized to reflect end-user security requirements as opposed to single-purpose security policies in common usage today utilizing an information neutral architecture applicable across operating systems and applications.
  • a working Bell-LaPadula Security Policy model has been implemented as has a Message Trusted Guard. Brief Description of the Drawings
  • Figure 1 is a Stylized Diagram of the Generic Policy Engine
  • Figure 2 is an overview of the Generic Policy Engine
  • Figure 3 shows a Classical Subject/Object Interaction as per TCSEC
  • Figure 4 illustrates the Dual Requirement for Object Reuse at the System and GPE Level.
  • Figure 1 illustrates a system that produces security policies from formal definitions of the security policy model using a higher order, lambda calculus based language. This provides several advantages. First, it creates a uniform, universal language for developing and proving the correctness of security policies and their models. Instead of the current assortment of policy verification mechanisms developers would have one language, one semantics, and one syntax to implement their security policies. Second, the proofs for the security policies could be automatically generated from the formal semantics of the base lambda calculus. Third, by providing a uniform language environment, connectivity between security policies can be improved since they would be based on higher level semantics than is currently available.
  • the GPE must provide a one-for-one mapping between the entities to be protected in the calling application and the security information maintained by it.
  • the GPE utilizes an entity-based approach defining an encapsulation with all the security relevant components within its boundary.
  • Security relevant application programming interfaces APIs are provided so applications can manipulate security attributes and determine proper information flow, call the security policy, examine audit logs, and perform regular maintenance on the entity.
  • APIs application programming interfaces
  • the GPE's purpose is to provide sufficient security to an application so that the application requires only minor security specific instructions to meet even the highest security requirements of the various international evaluation criteria.
  • FIG. 2 presents an overview of the Generic Policy Engine.
  • the GPE is written in and controlled by Idyllic. The language is fully extensible and comes with a highly capable library of functions.
  • the GPE's primary data structure is called the entity containing all the security data pertaining to an entity under its control along with the application programming interface (API) to manipulate the entity.
  • API application programming interface
  • Customizable elements which can differ from application to application, can be provided by application programmers and are referenced via the APIs.
  • the two programmer configurable components are the I&A mechanism and the security policy.
  • the various components of the GPE are the structure of the entity, its data elements, the facilities provided in the various APIs, the functionality provided by Idyllic, and the security functionality.
  • Mechanisms are put in place to uniquely identify and authenticate users and to dynamically track their actions within an application or system.
  • Security controls regardless of type, are not foolproof and to ensure a system of recourse after a security breach a non-circumventable, unalterable, continuous audit mechanism must be in place and operational.
  • a base set of auditable events must exist which can never be disabled.
  • the routines must be non-circumventable ensuring that neither accidental nor intentional modification of the audit system occurs.
  • the unique identification and authentication of every user or a particular user or system ensures that individuals utilizing the system can be held accountable for their actions.
  • the mechanics behind identification and authentication can vary greatly and as such the core elements should be customizable to suit the threat assessment and the particular architecture. The guarantee of a minimal auditable event list is vital to maximize the trustworthiness of an application.
  • Information flow is controlled so that access to and manipulation of information is restricted to a specific set of individuals utilizing specific tools. As such there must be a mechanism provided to store and manipulate access controls for the various entities that are to be controlled. Each entity contains its own access controls entries to which programmers have access via the Access Controls API. The Access Controls data elements themselves are accessible only to the Access Controls API. The API is the sole method of retrieving pertinent information concerning an entity so that the security policy can operate effectively.
  • the security policy itself is programmable by the developers though the Security Policy API is fixed. This provides the maximum flexibility: auditable events can be established at the API junction while removing any concern that the developers need remember to insert specific auditable events into the security policy they are writing.
  • the security policy is customizable but is restricted to using the Access Controls API to access the Access Controls.
  • additional security policies can be modeled which enhance, complement, or override the default security policy implemented within each entity.
  • Security policies written in Idyllic can be modified to reflect the requirements of the applications developers thus reflecting the general policies and procedures pertaining to information flow and control for a specific organization. Default security policies, those applicable to all entities, can be provided to simplify security policy maintenance.
  • compatible and cooperative security policies can be written to represent the nuances particular to a given department or section.
  • a virtual machine architecture for Idyllic and the Generic Policy Engine has been adopted to maximize portability and simplify the core and primitive elements of the language. Virtual Machines have been shown to be small and efficient and relatively simple to port.
  • the following table outlines the base entity within the Generic Policy Engine that represents the actual data stored by the calling application. The entity is subdivided into seven basic components: unique identifier, entity type, authentication information, security policy, audit history, privileges, and access controls.
  • Entity Type The type of entity There are two distinct types Those of type group are those which define a group of entities for a particular purpose Those of type entity ate for all other entities A strict entity can contain multiple groups to which it belongs A group contains a list of entities forming the particular group The delineation assists the GPE in quickly traversing associations in order to simplify the security policy's goal of determining whether or not an information flow is to be permitted
  • Security Policy The security policy for the entity Each entity can have a different policy or can adopt a general one for the specific machine, domain, network, or institution to which it belongs
  • Audit History Owner A history of who "owns” this entity, most recent 1 st , original owner (i e , creator) last including timestamps
  • Last Modified A history of who last modified this entity, most recent 1 st , original creator of file last including timestamps
  • Last Access A history of who last accessed this entity and by what means, most recent 1 st , onginal creator of file last including timestamps
  • Access Control Lists (ACLs) and Roles
  • I&A API Identification and Authentication API
  • Access controls are, in reality, split into two distinct portions: privileges and access controls.
  • the former is maintenance information used to track groups, associations, levels, etc. to which this particular entity is a member; included in the list of maintenance information are all those entities which reference this entity.
  • Access controls can be broken out into five standard "controls": read, write, execute, delete, and copy. Any number of these can be utilized, in any fashion required to assist the security policy in performing its duties. It is irrelevant whether the security policy is access control based, capabilities based, role based, or otherwise based. The information required to properly execute such policies is provided within the entity, and especially within the Privileges component.
  • Groups, associations, levels, categories, and caveats provide a mechanism by which like entities can be grouped together. For example, all entities classified Secret would have the same Level. Definition of a group, say Engineering, could further subdivide the entities classified as Secret to those that are Secret and available only to someone in Engineering. Each definition of a privilege for an entity further restricts access. Similarly, when an entity becomes active, its privileges define the domain to which it belongs and is utilized by the GPE to determine which passive entities can be accessed.
  • the other privileges provide a further refinement along traditional lines, namely categories and caveats.
  • the security policy dependent and written for a particular application, utilizes the access controls and privileges to determine what is considered appropriate information access.
  • a pointer to the security policy is provided within each entity allowing for individual policies per entity or for policies to follow the information as it is copied from one host or application to another. In this manner the information understands its policy and the validity of requests made by entities outside its original domain.
  • applications protected by Generic Policy Engine built security components could move information securely between themselves knowing that not only the base data is transmitted during the flow of information between the applications but that the security information is passed along as well. This can be utilized to ensure that information to which one individual has access remains with that individual, even though the information was moved to a secondary system for whatever reason.
  • the new security policy determined access controls. In this scenario, if the new security policy was not disclosure driven, for example, it might permit accesses to the information that would be forbidden under the original security policy. By having the security policy move with the entity it requires a conscious effort by the owner of the item to modify the security policy to the policy of the new host application along with all that it entails.
  • the base language, known as Idyllic, of the Generic Policy Engine is based on two simple premises:
  • the language must be provably correct in order for the GPE to attain the highest levels of trust within the various criteria.
  • Premise 1 removes most languages from contention, most notably Smalltalk and the other object oriented languages.
  • the class library overhead of OOP languages is unnecessary baggage that in turn impacts on Premise 2.
  • Premise 2 requires a simple language that is easily understandable.
  • the development language for secure components must be well defined.
  • a language must have a formally defined grammar, a stable history (few, well defined and delineated changes over time), and supporting documentation available to the computer industry.
  • Most computer languages i.e., C/C++, Smalltalk
  • C/C++, Smalltalk Most computer languages (i.e., C/C++, Smalltalk) meet these requirements.
  • C/C++ Smalltalk
  • Classical languages such as C/C++ and Smalltalk have large class libraries that preclude them from easily being proven correct.
  • test expressions are evaluated from left to right, and the value of the first expression that evaluates to a non- false (not ttf) value is returned. If all expressions evaluate to a false value, ttfis returned
  • test expressions are evaluated from left to right, and the value of the first expression that evaluates to a false (#f) value is returned. If all values evaluate to non-false values, the last expression's result is returned
  • a predicate is a procedure that always returns a boolean value (#t or #f ).
  • An equivalence predicate is the computational analogue of a mathematical equivalence relation (it is symmetric, reflexive, and transitive). Of the equivalence predicates found in Scheme only equal? is implemented in Idyllic. This is primarily for reasons of clarity rather than efficiency since equal ? is usually the least efficient equivalence predicates available.
  • Idyllic has but one type of number: integers. The reason for not implementing any other form of number is that, historically, operating systems and their components have never required floating point nor rational numbers, let alone complex numbers. To that end, Idyllic contains only integers.
  • Idyllic must support integers throughout the range of numbers that may be used for indices of lists, vectors, and strings or that may result from computing the length of a list, vector, or string.
  • the length, vector- length, and string- length procedures must return an integer. Mathematical functions always return an integer result.
  • Idyllic includes but a fraction of Scheme's control structures. Scheme allow for numerous looping constructs as well as numerous conditional expressions. Idyllic, on the other hand, has opted for simplicity. Programs executing under Idyllic need to be trusted and to be trusted they must be simple. Additional layers of complexity simply cloud the issues of security, complicate formal proofs, and obfuscate correctness.
  • Idyllic contains only eight control structures: apply, cond, def ine, lambda, let, map, quote , and set ! .
  • test> ⁇ expression> . . .
  • test> is any expression.
  • the last ⁇ clause> may be an "else clause", which has the form:
  • a cond expression is evaluated by evaluating each the ⁇ test> of each ⁇ clause> until one evaluates to true. The associated list of ⁇ expression>s is then evaluated. The final ⁇ expression>'s value is returned by the cond. If no ⁇ test> expression evaluates to true, then the else clause is evaluated. If no else exists, ttf is returned.
  • lambda ⁇ args> is a formal parameter list and ⁇ body> is a sequence of one or more expressions
  • the lambda expression ⁇ args> evaluates to a function
  • This lambda is the only method by ⁇ body> ) which programmable information can be stored within Idyllic
  • Evaluating the lambda expression along with the appropriate number of parameters is the method of calling functions in Idyllic
  • ⁇ bind> allowed to be the one exception that defines the rule of ⁇ body> )
  • Idyllic's simplicity ⁇ B ⁇ nd> is a list of variable/expression pairs evaluated in turn with each expression being evaluated and bound to the provided variable Once the binding is complete, the ⁇ body> is evaluated and the evaluation of the final expression found within the body returned
  • Map fn list (map fn list) List must be a list and fn must be a function taking as many arguments as there are lists If more than one list /s provided, then all must be the same length Map applies fn element- wise to all elements of the provided lists and returns a list of the results, in order
  • variable ⁇ var> (set! ⁇ var>).
  • the expression ⁇ expr> is evaluated and the resulting value is stored in the location to which the variable ⁇ var> is bound ⁇ expr> )
  • the variable ⁇ var> must have been defined within the current scope or within the global scope
  • a variable is defined within a scope by means of the define structure, above
  • Secu ⁇ ty is concerned with limiting access between entities to only those authorized by the security policy.
  • Secu ⁇ ty is usually defined m terms of an entity-based model which defines all entities controlled by the security policy as entities in one of two states' subject, the active state or object, the passive state, as shown in Figure 3. This definition has been shown to be limiting and causes problems when attempting to define security policies across an object-oriented system. The p ⁇ mary issue remains one of state and how the transitions from one state to another are accomplished.
  • An external application such as an operating system
  • the security policy There are two customizable portions to the security policy: the I&A mechanisms and the Security Policy, both indicated in white.
  • Login requests are handled via the standardized GPE API but the login mechanism can be any the developers feel would be most appropriate. This allows for rudimentary login facilities as found on most operating systems today or complex login facilities, such as those based on certificate authorities and X.500 directory services.
  • Figure 2 a stylized structural of the Generic Policy Engine is presented. Each application wishing to utilize the Generic Policy Engine's security features would instantiate their own copy.
  • Each GPE would be protected by the underlying hardware and memory management, ensuring information can't cross application boundaries. It is assumed that the GPE will be utilized in those environment which properly adopt memory management, object reuse, and 32 bit (or greater) architectures.
  • the Generic Policy Engine would allow for multiple environments by providing for instantiations capable of creating their own secure environments and namespaces governed by the GPE for a particular domain such as an operating system or a database.
  • the utility of multiple environments is that various applications can use the Generic Policy Engine to create and manage their security policies and their particular authorization rules. This provides, in the case of an operating system, the ability to provide a fully functional security API for applications to use courtesy of the operating system and one that is as powerful as the native operating system's security system. Since all security is handled by the GPE, it can resist tampering and ensure logs are properly maintained.
  • Boolean values are returned when a request is made for specific access to a given controlled data item, such as a file.
  • Strings are returned when the request must return other than true or false, such as a cryptographic key, the true location of a file, current access controls for a particular controlled entity, etc.
  • identification and authentication referred to the login/password pair which greeted users prior to the system allowing the user to begin processing.
  • I&A identification and authentication
  • the Generic Policy Engine To be generic from an I&A point of view it is sufficiently flexible to allow one or more varied identification and authentication mechanisms.
  • a fixed API To ensure that programming for the I&A mechanisms chosen remains as simple as possible, a fixed API is required guaranteeing programmers are met with a uniform interface regardless of underlying mechanism. To that end, the Generic Policy Engine must provide a standardized I&A API which interfaces to application specific identification and authentication mechanisms.
  • Access controls are further divided into the mechanism employed.
  • the classic method is the use of access control lists that place the control information on each entity with explicit user names as to who can and cannot access the information.
  • a modification of this form is role-based access controls whereby users are associated with roles and it is the role by which each entity determines whether or not an individual can have access.
  • Other access control mechanisms operate similarly.
  • the Generic Policy Engine must be flexible enough to handle any form of access control, regardless of whether the controlling action is performed by the active entity, passive entity, or some combination thereof.
  • the entity defines the information pertinent to the decision making of the security policy and contains sufficient information to model any known security policy. Since each entity controlled by the Generic Policy Engine is actually defined by an entity, the security policy defined is not restricted to a single form of access control. Thus, the application developer can define security policies that utilize information stored in an entity, regardless of state (active or passive) and determine via appropriate combination the access permissions.
  • the access control model is role-based then passive entities only indicate the type of access associated with a given role.
  • the user entities actually define the roles to which they belong.
  • UserPs only role is clerk and Entity 1 only allows a clerk to read its contents, then Userl will be granted read permission.
  • Entity 1 does not need to be modified since it has no direct reference to Userl. The same cannot be said for access control lists that reference the actual users in each entity's access list.
  • the entities under the control of the Generic Policy Engine encapsulators defining the security attributes of the data.
  • the Generic Policy Engine ensures that information between entities is not accidentally shared.
  • the Generic Policy Engine does provide object reuse so that entities no longer in use can be reclaimed.
  • the Generic Policy Engine has no mechanism to ensure that a trusted path has been set up between the application and the end user. This physical mechanism must be provided by the application whenever the user issues a predefined key sequence to the application.
  • the security policy for the application can be coded such that it requires specific information prior to performing specific actions, such as information downgrades. This then becomes an issue addressed by the programmable security policy.
  • LastModifled LIST of (Entity, Timestamp)
  • LastAccess LIST of (Entity, Timestamp)
  • PurgeRate Lambda
  • Default NEVER //* Privileges Groups : LIST of Entity Associations : LIST of Entity
  • the entity defined using pseudo-code above, itself that understands how it is to be manipulated or accessed and can control the type of access via the security policy embedded within it. This is accomplished by storing the security policy for each entity within the entity. This allows the security policy to travel with the entity, regardless of environment. Thus a user requesting access to a passive entity would have to be allowed access by the security policy of the entity itself, even though this policy may be a general one applicable to and shared by all entities in the system.
  • the Generic Policy Engine provides a mechanism by which the information can be transmitted to another GPE controlled system, retaining the original access controls and security policy.
  • Idyllic implicitly manages all its data structures as symbolic expressions.
  • the entity is by definition a symbolic expression and therefore properly handled by Idyllic.
  • each entity In order to differentiate between entities, each entity is uniquely identified so as to be accessible locally, internally to Idyllic, and externally to the calling application.
  • Each entity has a current state, which indicates whether it refers to a user, process, or data. The data remains private with access permitted only via an exported API.
  • an entity can be viewed as a database entry where the database management system is Idyllic and the database language is the GPE's APIs.
  • the entity is managed as are all symbolic expressions within Idyllic. Accessing and manipulating entities via the APIs provides the security functionality associated with audit, identification and authentication (I&A), access controls, privileges, and security policy.
  • the APIs can be subdivided into:
  • the API is used in order that the entity be useful outside the bounds of Idyllic.
  • the entity is stored as a series of symbolic expressions and each is uniquely identified and mapable to an external calling application. This one-to-one relationship between the external representation of the entity and the GPE representation of the entity is vital to the security and integrity of the system. As each entity is manipulated it is fetched and stored in the access controls database. Each entity is identical in look and can be utilized for any purpose. This lack of typing is crucial to ensure that the GPE be sufficiently flexible in implementing any form of security policy utilizing its framework.
  • the "defaultSecurityPolicy” defined below is an explicit denial security policy. In other words, any action taken while this security policy was in force would be summarily denied. It must be changed, a conscious decision to override the default with a custom built security policy. It is in the interest of the application developer to utilize an appropriate and secure security policy.
  • Each entity is uniquely identified to the calling application by its ⁇ uid> (wnique /Jentifier) allowing for full cross-referencing.
  • the cross-referencing is used to quickly remove all references to the entity should it ever be required.
  • ⁇ uid> wnique /Jentifier
  • Some fields contain lists that refer to various data instances such as time or entity identifiers (uid). For example, owner is a list of all the individuals who have ever owned a particular entity, with the first owner listed being the current owner and the last owner being the original owner, or creator. Similarly, LastModified lists in order, from most recent to least recent, which entities performed modifications to the entity.
  • Entities are utilized and referenced by the security policy, which places specific information within each.
  • Level would contain pointers to such entities as Secret, Unclassified, and Top Secret.
  • the security policy would be able to request which the Level for a particular entity, compare it to other entities, and determine the validity of information access requests.
  • a group of entities can be placed into a particular role via the Associations tag.
  • the ⁇ uid> for the entity could be Programmer and reference the entities which are programmers.
  • Categories can be used to define category subsets for use by the security policy.
  • a banking security policy could define valid categories as Teller, Bank Manager, Branch Manager, Loan Manager, Clerk, and Financial Analyst and compartmentalize information appropriately.
  • This cross- referencing could be graphically illustrated to visually create representations of how information, one way or another, is related. This could greatly assist the security officer in determining whether there are any information flows that should not exist, such as data path from a higher hierarchical level to a lower one.
  • the GPE is generic. It is the interpretation of the information stored within the various elements of the Entity by the security policy that determines the form of the security policy, be it role based or access control based, or otherwise. Generic use of the entity generalizes security to its constituent components.
  • Object oriented technologies provide a partial solution by formalizing the notion of data hiding with both the data and the procedures to manipulate the data stored within an object defined by a class. This notion can be extended to assist us in creating a viable storage mechanism for the Generic Policy Engine.
  • Each entity corresponds to an item on the application side that the application programmer wishes to secure.
  • the entity is the manifestation of the security attributes of the data in the application.
  • the combination of the data found within the entity and the procedures to manipulate the entity constitute the entity -based form of the GPE. This works well for static procedures which remain constant.
  • the GPE must allow the flexibility to insert custom portions that reflect the unique identification and authentication mechanisms and the unique security policies of various organizations. At the same time, it must be able to put forward a well defined interface and functionality that would meet international security criteria.
  • the solution is to utilize a standard API for each of the procedures while allowing specific procedures, such as the Security Policy and Identification and Authentication routines, to have replaceable internals.
  • the following sections present the various procedures and their respective APIs.
  • the final section presents the entire entity-based "class" for GPE-Entity that contains the data described above and all of the APIs and associated functions for manipulating the data within the confines of good security practice.
  • Creating a new entity requires no more than a call to define-entity. This special form accepts only a single parameter: the entity's name. It must be unique. Define-entity will ensure that the identifier provided is unique and if not, will issue an error. It is these structures that are maintained and manipulated by the GPE. They encapsulate the security of the items referred to by the calling application. Idyllic and the GPE maintain all the created entities in a persistent state. Each entity is a self-contained security module capable of determining whether or not another entity is granted access and the type of access allowed. Access to the entity is available only through the defined APIs.
  • the above code provides a completed entity structure for a generic entity, slightly stylized for readability.
  • many portions of the object-oriented paradigm are utilized in the design and implementation of the entity.
  • object oriented it cannot truly be called object oriented as the only elements of object oriented computing utilized in the GPE are garbage collection (inherent in Idyllic), polymorphism, and encapsulation. Inheritance is notably absent. This is the primary reason why the GPE is referred to as entity-based.
  • Uniquefdentifiers refer to the ⁇ uid>s found within the GPE entity. This provides closure between the various classes, linking them together explicitly in a large lattice. Code fragments have been removed for clarity and brevity. ⁇ creator> is the creator of the new entity. Each entity is created by another entity, which is its creator. All entities can trace their heritage back to the original entity, the system entity, similar to the class Object in Smalltalk. The other parenthesized elements ( ⁇ ... >) are self-explanatory.
  • a Trusted Computing Base is the term that defines a boundary within which all controlled entities reside.
  • developers typically define which entities are under the control of the reference monitor and which are not. The defined subset of entities are considered to be inside the TCB boundary while the remainder are considered to reside outside the TCB boundary.
  • the application using the GPE must provide the additional security features of memory management and non-circumventability of the security policy.
  • the GPE provides a security policy. This security policy must be invoked by the calling application in order to properly function. There is no mechanism by which the GPE can guarantee the proper invocation, but by simplifying the mechanics behind the actual call, we can ensure that overhead and complexity are removed as viable answers to not utilizing the security procedures of the GPE.
  • One of the most difficult areas in computer security is ensuring that the system being developed is trustworthy.
  • By using reference monitors and trusted computing bases it is possible to increase the amount of trust that can placed in a specific trusted product.
  • all aspects must be examined by an approved evaluation authority. This is a time consuming process.
  • One of the main goals of the GPE is to reduce the amount of time required to evaluate a trusted product.
  • the controlled entities must be readily available between invocations. Idyllic can store all of the entities in its address space, readily available to the GPE. On large scale applications a caching scheme is used that is capable of ensuring entities are fetched and stored on disk depending on usage and when modified. Modifications to an entity must be written to disk immediately to minimize the likelihood that security information would be lost for whatever reason. The caching scheme would ensure that the most used entities remain in RAM, those less often used would be removed from memory after Idyllic guarantees that the information has been saved properly. The simplest method of providing persistence is for the operating system to always keep the GPE and its associated entities in active memory. This would also provide for the quickest reaction time but may not be expedient when the number of entities controlled becomes large, as inevitably will be the case. Regardless of the system used to keep the entities readily available, it must ensure the isolation, availability, and correctness of all GPE data. Caching schemes are sufficiently well understood that one could be adopted for use by Idyllic to guarantee the integrity of its dynamic namespace.
  • the GPE Upon system shutdown, the GPE would have to be called to ensure orderly shut down of the security policy and proper storage of all databases. In a production version of the GPE a shutdown function would be used to initiate security shutdown. Similarly, when an application shuts down, it must properly terminate any copies of the GPE it instantiated.
  • the C-like API provides standard procedural prototypes for using the capabilities of the GPE. These C-like calls are converted into the internal LISP- like API. Provided in subsequent sections are the C-like APIs.
  • the full LISP-like API is provided as part of the full definition of the Entity found discussed above. Of note is that all LISP-like API calls are found within the entity as the exported public functions available to manipulate the data contained within. This gives the entity an object-based feel, retains strong encapsulation, and provides a single, cohesive unit to refer to the protected item in the calling application.
  • the GPE's purpose is to provide security to a calling application.
  • Each application requests its own instantiation of the GPE.
  • Each instantiation provides a fully functional copy of Idyllic and the GPE APIs.
  • a namespace In order for the GPE to operate, a namespace must be opened and available to the calling application.
  • gpelD gpeCreate ( ) Returns a reference to a new namespace. The application is expected to use gpelD whenever it requires access to the security functionality. If gpeCreate () could not create a new namespace, 0 is returned. gpelD is a long unsigned integer.
  • gpeOpen gpelD
  • the application requests a previously opened GPE namespace to be opened by calling the function with gpelD. If the namespace exists, #T otherwise ttF.
  • gpeStart All initialization and global sets must occur prior to the gpeStart () command being issued. This ensures that certain attributes are frozen for the running duration of the GPE, such as audit level.
  • gpeClose gpelD
  • Every entity has a unique identifier provided by the calling application.
  • This unique identifier (uid) uniquely identifies each entity managed by the GPE and provides a consistent mapping from the GPE entities back to the controlled items of the calling application. This simple, one-to-one mapping enhances the reliability and security of the GPE and ensures that identifier translation routines are not required thereby removing a source of possible error.
  • the GPE Entity API refers to what is normally called class methods in object-oriented programming.
  • the functions defined in this API see below, allow the programmer to manipulate the entity namespace in a coarse manner; strictly at the entity level
  • gpeEntity (uid create) Creates a new entity within the namespace with the unique identifier provided All information for the entity must be filled in piecemeal Returns #T on successful creation, ttF otherwise gpeEntity (uid remove) Removes the entity referred to as uid Returns #T on success, ttF otherwise gpeEntity (uid SP secu ⁇ tyPolicy) Sets the security policy for the entity referred to as uid to secuntyPolicy SecuntyPolicy must be a valid lambda expression. Returns #T on success, ttF otherwise gpe£ ⁇ t/f (u ⁇ d SP DEFAULT) Sets the security policy back to the GPE default Returns #T on success, #F otherwise
  • the GPE Identification and Authentication (I&A) API provides access to the I&A data of an entity. These calls allow for the creation of entities and the definition of unique identification and authentication of entities, regardless of whether they refer to a user or data object externally. The calling application need not track which users are valid nor which privileges they have.
  • the GPE API provides system calls that can authenticate individuals.
  • the GPE API provides additional system calls to add, remove, and update information concerning users of the application.
  • the I&A database is maintained and protected by the GPE within each unique entity. The following table provides a summary of the Identification and Authentication API.
  • gpeAuth (uid Add authStr) Adds uid, plus its authentication string (authStr) to the entity referred to by uid Returns ttT on success, #F otherwise gpeAuth (uid Remove) Removes uid (i e , the entity it refers to) Returns #T on success, #F otherwise gpeAuth (uid equal authStr) Is the uid and authentication string (authStr) correct?
  • gpeAuth (uid Expires date) Sets the expiry date for uid ttT on success, ttF on failure
  • gpeAuth (uid Expires?) Returns ttF if the uid's password never expires, the date of expiry otherwise.
  • gpeAuth (uid SetPaswd old new) Sets the password to the new one provided the old password matches the existing one. Returns ttT on success, ttF on failure.
  • gpeAuth (uid SetPassLen Sets the password length to the new one provided so long as it is between the predefined min and max password newlen) lengths.
  • gpeAuth (uid deactivate) Deactivate the uid. ttT on success, ttF otherwise. gpeAuth (uid activate) (Re)activates the uid. Returns ttT on success, otherwise ttF.
  • the Generic Policy Engine provides a built in audit capability capable of auditing every request by the calling application for mediation between a requesting entity and the targeted entity.
  • Each entity when accessed, logs all requests, the time of each request, and the status of the request to their internal logs.
  • Each entity has a default audit level. These audit levels can be adjusted so more or less information is gathered. Therefore, to collect less information the audit level is lowered; to gather more, the audit level is raised.
  • Entity level auditing cannot be completely shut off since a base number of auditable events must be tracked for security reasons, such as entity create, access, delete, etc. These typically correspond to system level actions such as file open, file close, file delete, add user, remove user, etc.
  • Logs are lists with each entry stored as a sublist. Each entry contains the following information: requesting entity, time of request, action requested, and return status of request. This information is available, typically to the security officer and the audit tools, via the Audit API.
  • the default log is provided to allow calling application to insert specific information on events the application feels are security relevant.
  • the default log can be used to create general logs by creating an entity whose entire purpose is restricted to logging information on behalf of the application.
  • the owner log tracks who the owner of the entity is from the entity's inception through to its final destruction.
  • the last modified log tracks all attempts at modification to a particular entity.
  • the last accessed log tracks all accesses made to a particular entity.
  • MinimalAuditLevel The only auditing done is the bare minimum, namely recording entity creates and destroys
  • the GPE defines a specific set of audit levels, as defined above. These are adjustable prior to the issuance of the gpeStart ( ) command. Once the GPE starts, these global audit values are immutable.
  • gpeLog (GetLevel) Return the currently set level of audit gpeLog (SetLevel ⁇ level>)
  • the GPE provides predefined levels of granularity for audit ⁇ level> must correspond to one of the predefined audit levels Returns ttT on success, ttF on failure gpeLog (setOptions . ) Sets the option list to the list provided (future) gpeLog (SetGMT) Sets the time to GMT, default for Time is local time gpeLog (SetLocal) Sets the time to local time, this is the default gpeLog (Time) Returns the current setting, either Local or GMT Audit Log API (Global)
  • Manipulating the fixed elements is provided by a set of global audit functions, defined above. These are the functions which must be called prior to gpeStart ( ). As time progresses in any security system, logs grow increasingly larger until they occupy all available space. There must be some mechanism to limit their size.
  • each entity has a lambda expression which defines the purge rate. This function determines when the log is to be purged, be it by age or by size. If by size, the log is truncated by removing the older data and retaining the newer information. If logs are never to be removed, then the purge date must be set as never. This ensures that the GPE never removes the logs but will, if the logs become full, halt the GPE.
  • logs can be accessed in one of two ways: read and append.
  • Many modern logs do not require the selective editing of the logs but rather only the wholesale purge, which is logged in the new log created after the existing log is closed for purging. This ensures a trace exists of all actions throughout the life of the system.
  • the destructive functions are typically restricted to the Security Officer user.
  • the following API defines the common log access functions.
  • the two system calls provided allow access to the four types of log, defaultLog, Owner, LastModified, and LastAccessed; ⁇ log> refers to one of these.
  • gpeLog (uid put ⁇ log> data) Appends data to ⁇ log> for the entity defined by uid.
  • gpeLog (uid get ⁇ log> expr) Returns all entries for the entity uid which match expr. expr can be a wildcard, which returns the entire log.
  • Privileges in the GPE retain grouping information.
  • grouping information There are two distinct types of group: hierarchical and non -hierarchical. Both are defined and accessible to security policies within the GPE framework and both are accessed using the calls defined in the API below. All relevant grouping information is stored within the entity. Groups, associations, categories, and caveats are all non-hierarchical grouping mechanisms. They follow the common mechanisms found in many security policies which provide for the ability to group users or information in specific ways. For example, UNIX allows users to be grouped so as to provide specific groups with certain functionality. The military groups information via categories and caveats in order to limit who within a specific organization, regardless of clearance, can actually see the information. For example, information labeled Secret NA TO would be visible only to those individuals holding a Secret clearance with the NATO category. Categories and caveats are often called compartments.
  • Hierarchical groupings are typically found in the military where the hierarchy is directly related to the classification system used to store information. The most common classifications are Unclassified, Confidential, Secret, and Top Secret. As a hierarchy, each is more restrictive than the former. Thus, Secret information is extremely sensitive but less so than Top Secret information. Typically, individuals with access to a higher level in the hierarchy also have access to information at lower levels in the hierarchy. Manipulation of the hierarchical mechanisms is performed in exactly the same manner as for non-hierarchical information.
  • gpePriv (uid put ⁇ priv> uid2) Adds uid2 to the ⁇ priv> list for uid. Returns ttT on success, ttF otherwise.
  • gpePriv (uid remove ⁇ priv> uid2) Removes uid2 from uid's ⁇ priv> list. Returns ttT on success, ttF otherwise.
  • gpePriv (uid get ⁇ priv>) Returns the complete ⁇ priv> list for the given uid.
  • Privileges usually form the most secure mechanism of a secure system. As such, they must be easy to access. Although the entity's Privileges API provides sufficient mechanisms to extract the required information, there must be additional functionality provided in order to extract individual fields from within a record. The granularity provided by the above functions is rather coarse. However, Idyllic provides a rich environment in which to extend the syntax by means of macros or user- defined functions. These extensions will be highlighted later when the GPE is illustrated by implementing a few well-understood security problems. The access controls subsystem is actually divided into two distinct pieces: the data storing the information and the API providing the access routines.
  • the authors of a particular security policy must create appropriate helper functions that retrieve and manipulate the entity information.
  • the helper functions would focus on retrieving classification levels for the mandatory controls.
  • the authors would provide functions to perform appropriate evaluations for set inclusion and dominance to further enhance readability.
  • the GPE provides sufficient syntactic enhancements to lessen the difficulty of programming in the GPE's base state.
  • gpeAC (uid put ⁇ right> allow uid2) Modifies uid's access controls to allow uid2 the specified ⁇ right>. Returns ttT on success, ttF otherwise.
  • gpeAC (uid put ⁇ right> deny uid2) Modifies uid's access controls to deny uid2 the specified ⁇ right>. Returns ttT on success, ttF otherwise.
  • gpeAC (uid remove ⁇ right> Removes uid2 privilege to access uid via ⁇ right>. Returns ttT on success, ttF otherwise.
  • allow uid2) gpeAC (uid remove ⁇ right> Removes uid2 explicit denial of access to uid via ⁇ right>. Returns #T on success, ttF otherwise. deny uid2) gpeAC (uid get ⁇ right> allow) Returns the allow list for the given ⁇ right> for the given uid. gpeAC (uid get ⁇ right> deny) Returns the deny list for the given ⁇ right> for the given uid
  • Access controls have a number of elements that must be easy to access. Although the entity's Access Controls API provides sufficient mechanisms to extract the required information, there must be additional functionality provided in order to extract individual fields from within a record.
  • the above table defines the API for accessing and manipulating the various aspects of the Access Controls data elements of the entity data structure.
  • the GPE provides for a generic API to access the security policy. This interface consists of a single call gpe ( ) defined in below. Valid actions are summarized in the subsequent table.
  • gpe entity 1 action entity2 Returns ttT if entityl can perform the indicated action against entity2, ttF otherwise.
  • Action read On access read the information protected by the entity.
  • write On access write into the information protected by the entity.
  • execute On access execute the information protected by the entity.
  • copy On access copy the information protected by the entity.
  • delete On access delete information protected by the entity.
  • the following table enumerates the valid calls to the GPE for invocation of the security policy.
  • the invocation is a simple entity x action x entity triple which can map elegantly to any security policy.
  • the simple invocation also allows for easy integration into procedural languages, such as C/C++ or Pascal.
  • gpe (entityl read entity2) According to the security policy, can entityl read entity2? gpe (entityl write entity2) According to the security policy, can entityl write entity2? gpe (entityl execute entity2) According to the security policy, can entityl execute entity2? gpe (entityl delete entity2) According to the security policy, can entityl delete entity2? gpe (entityl copy entity2) According to the security policy, can entityl copy entity2? gpe (entityl grant entity2) According to the security policy, can entityl grant ownership to entity 2?
  • the administrative secu ⁇ ty policy implicitly defines the behaviour of the explicit secu ⁇ ty policy by outlining exactly who, what, and how the va ⁇ ous fields of an entity can be examined and updated For example, Bell-LaPadula st ⁇ ctly restricts the motion of information An entity at a given hierarchical level cannot be downgraded A mechanism must exist to downgrade information for the system to be useful in the real world This special case must be handled by defining individuals, known as secu ⁇ ty officers, with the special ability to circumvent the security policy This power, obviously, must be controlled In order to ensure the use is minimized, or at best properly controlled, gpeManage ( ) contains special code which may circumvent the overall secu ⁇ ty policy Any code that must circumvent the explicit secu ⁇ ty policy must be placed withm gpeManage ( )
  • Secu ⁇ ty operates under a simple assumption every action must be approved Once the action has been approved, the specific action can occur Sometimes the action requires modifying one of the elements of an entity In these cases, a subsequent call is made via one of the previously defined APIs which perform the manipulation. All of the APIs, except for the Security Policy API, require only the targeted entity's uid. The GPE remembers the last access request, the requesting uid, the target uid, and the status of the request. For a subsequent call to one of the APIs the requester is therefore known. The action can proceed if and only if the status is ttT and the API provided uid is identical to the one remembered by the security policy for the target. If not, the request is refused.
  • the following pseudo-code shows how the GPE is used in-line to check on the validity of one entity, in this case a user, attempting to access another entity, a file. if gpe (user read file) then readLine (file) else warn ' access denied ' endif
  • the example illustrates a general use of the GPE to control access to a file by a user for a specific access method. If the security policy determines that the access should be allowed, the readLine is invoked; otherwise, a warning is issued. This general form is all that is required to invoke the security policy implemented in the GPE.
  • the former case must be handled by the underlying application, the latter is part of the garbage collection regimen of Idyllic. It must be guaranteed that the underlying application, prior to reallocation, clears any information stored within the entity. Similarly, the garbage collection routines for Idyllic must clear any security information from the entity prior to reallocation.
  • Disk files In some cases, such as UNIX, information at the memory level is cleared prior to reallocation. Disk files, however, must be cleared using an additional set of software either at file destruction time or just prior to reallocation. In the cases of other products, it may be necessary to create custom destruction routines to ensure the information is cleared prior to handoff to an underlying operating system or network. Encryption can be used to perform the object reuse either by the calling application or by Idyllic. It is logically infeasible to define interfaces to every possible kind of program to which the GPE may provide security.
  • the request to delete an entity automatically forces the system to delete the information associated with that particular entity. Prior to reallocation, Idyllic ensures any information within the entity is purged.
  • a trusted path mechanism if required for the evaluation of the application utilizing the GPE, must be provided for by the application itself since it is a direct user-system interaction. Additional logic in the security policy can be utilized to ensure the appropriateness of the trusted path command request.
  • the GPE is based on the premise that it will be embedded within a properly modular system with clearly defined and controlled flows of information against which policies implemented in the GPE can operate.
  • Idyllic and its associated Generic Policy Engines do not rely on any specific operating system or application type. The only requirement is that the underlying operating system or application provide information to the implemented security policy in a format compatible with the GPE API.
  • the Generic Policy Engine provides core functionality for implementing security policies. It is not concerned with the details of each and every security policy but rather provides the basic elements required for any security policy. To that end, the functionality provided is simple, and elegant.
  • Idyllic is a lambda-based language, extending the syntax is a straightforward exercise; syntactic extensions are used to address the readability limitations of the Generic Policy Engine's base functionality.
  • the following paragraphs present a number of security policies which, in order to make the security policies more readable, are provided with their own system calls.
  • Bell and LaPadula defined their security policy in terms of subjects (active entities) and objects (passive entities). In the original definition, subjects were processes and objects were files associated with an operating system. For our purposes we shall define the Bell- LaPadula Security Policy in terms of their classical use where subjects define active users and objects define passive files and peripherals, such as tape drives and printers.
  • the Bell-LaPadula Security Policy is described in terms of a simple triple containing the user (ox subject), the data (object), and the action. The two governing rules of the Bell- LaPadula Security Policy below.
  • Simple Security Property Also known as the no read up (NRU) rule, states that a subject with security label L s can only read information of an object with security label L 0 if and only if L s dominates (is greater than) L 0 .
  • NWD no write down
  • Trusted path is attainable only by the calling application and cannot be completely addressed by the Generic Policy Engine, it is not implemented below.
  • Object reuse requires corresponding code in both the calling application and the GPE. Within the GPE, object reuse is implicitly handled by housekeeping functions such as garbage collection.
  • the Bell-LaPadula Security Policy is known as an hierarchical model. This means that the information is segregated into distinct, hierarchical levels each separate and distinguishable from all others and each defined via a dominance relationship with the others.
  • the hierarchy consists of the military classifications Top Secret, Secret, Confidential, and Unclassified. They are related in that each in turn dominates the next in a simple mathematical relationship:
  • the Bell-LaPadula Security Policy has other aspects, namely categories and caveats that are not hierarchical in nature.
  • a given entity is not bound to a single category or caveat as they are to a single level of a hierarchy.
  • Categories and Caveats are viewed as sets with any entity within the Bell-LaPadula Security Policy belonging to a predefined set. These categories and caveats are, typically, available to each level and to all entities though not all categories or caveats may be utilized for all entities. Namely, each entity is allowed a specific, predefined subset of the category and caveat sets. Each entity is then restricted to any and all subsets of that predefined subset, including the null set.
  • Bell-LaPadula models an active set of processes, one where information is moved from one secure or trusted state to another. In order for information to be moved between states it must first be created. If it is to be created, there may come a time when it needs to be destroyed.
  • the Generic Policy Engine provides mechanisms to create and destroy entities and their associated linkages and information. For this implementation of the Bell- LaPadula Security Policy we require two functions as defined below.
  • createEntity type entity Creates one of the two types of entity required by the Bell- classification
  • LaPadula Security Policy subject or object.
  • the classification level for the new entity is passed as a parameter.
  • ttT On successful creation ttT is returned, ttF otherwise.
  • destroyEntity Entity Destroys the entity and removes all references within the GPE namespace to it. Returns ttT on successful destruction, ttF otherwise.
  • the least privilege requires that the person performing a duty must be granted only those system privileges necessary to properly perform a particular duty. This is contrary to many systems, such as UNIX, that provide all or nothing privileges under the guise of a super user or administrator.
  • the typical solution is to create privileges that ensure a particular task requires a particular privilege. Therefore, the tasks associated with an operator - mounting tapes, starting and stopping the printer queues, routine non-security related maintenance - would require operator privilege; the creation or modification of user accounts, upgrade or removal of applications, etc. would require system privilege.
  • the privileges are typically associated with roles such as operator or system administrator. Applying this solution to UNIX would result in at least three distinct user types: unprivileged user, operator, and system administrator. Security officer is typically added and is responsible for the system logs, maintenance of the security policy, security policy enforcement, and information flow, typically in the form of document downgrades.
  • Each entity must be assigned a privilege set at creation time.
  • the privilege set is used to determine which functionality the entity can utilize during its operation as an active entity.
  • Least privilege further stipulates that the entity activate only those privileges required to perform its duties.
  • the Bell-LaPadula policy does not require the inclusion of privileges, relying instead on the division of "subjects" and "objects" according to the defined hierarchy.
  • system applications By defining system applications as “System Low", i.e., below all other levels of the hierarchy, sensitive files can be protected from inadvertent modification.
  • system Low i.e., below all other levels of the hierarchy
  • specific tasks can be delegated to specific individuals. In this way we can subdivide all users into one of two types: privileged users and unprivileged users. We can further subdivide each of these groupings as required by allocating specific categories to differentiate specific privileged sets. For example, categories could be defined to represent the system administrator, operator, and security officer.
  • MAC Mandatory access controls
  • GPE provides for Levels which are used to compartmentalize entities to better control information flow through the system.
  • the compartmented entities are usually further subdivided by means of categories and caveats.
  • the definition of valid sensitivity levels, categories, and caveats must be defined prior to the first utilization of the GPE. This is accomplished by defining each valid level, the explicit hierarchy they represent, and the valid category and caveat sets. Using syntactic extensions that create and populates appropriate entities for us, we first create each hierarchical level. (createLevel 'SystemHigh)
  • Idyllic allows us to create the hierarchy simply as a list. This list explicitly defines the hierarchy and allows for simple arithmetic operations to be utilized to determine which security level dominates another relative to position in the list; the higher the position, the higher the level.
  • Categories and caveats are unordered sets and are similarly created. Instead of creating a hierarchy, they represent valid sets.
  • This triple defines the entity at SystemLow, and has empty sets for both the category and caveat lists.
  • One of the first actions performed is to upgrade the entity to its approp ⁇ ate current, minimum, and maximum levels, which in our example would be anything from Unclassified through TopSecret; the GPE would also insert the appropriate caveats and categories for the current active set and the full set. Therefore, an entity with a security level of:
  • Entity classification Sets the security level, categories, and caveats for entity to the classification information provided getMAC (entity) Returns the classification information for entity as a triple If entity doesn't exist, the request is refused.
  • Discretionary Access Controls correspond to Axiom 3 of the Bell-LaPadula model. DAC allows system users to restrict access of the entities that they own to specific active entities, in a discretionary way.
  • the TCSEC requires at C2 and above that "access controls ... be capable of including or excluding access to the granularity of a single user"
  • True access controls follow those outlined in Multics and implemented by the Generic Policy Engine. Permissions come in two primary flavours: role based and access control based. Both are very similar with role based access control defining what specific roles can or cannot access particular information and having all users within the system defined by specific roles.
  • Strict access controls define specific users or groups of users as having access to particular information. Both are equally valid. For our purposes, we will use access controls since they more closely correspond to a majority of the Bell-LaPadula interpretations currently in use throughout computer security. Permissions are typically defined by read, write, and execute controls.
  • removeACL entity access Access can be one of deny or allow. Entity2 is removed privilege entity2 from the provided privilege in the ACL. modify ACL (entity ACL) Modify an existing ACL by replacing the ACL with the one provided. getACL (entity) retrieve the access control lists for entity. If entity doesn't exist, return ttF otherwise the ACL.
  • FIG. 4 illustrates what happens when there is a request for the deletion or creation of a particular data file within the system. When a request is received by the system for the destruction of a particular data file, the system must ensure that the requesting entity has appropriate access. If all controls are correct, then the entity in question can be destroyed.
  • the GPE provides identification and authentication functionality fully capable of delivering sufficient uniqueness to describe all operational active entities within the model. For the purposes of this example a simple login ID and password suffices to properly and uniquely identify each active entity to the security policy. In order to facilitate the usage, the following routines are provided which provide I&A mechanisms for the Bell-LaPadula Security Policy.
  • Login user password Attempts to log in the user with the provided password, level category caveat) level, category, and caveat. On success, #T is returned, otherwise ttF.
  • the Generic Policy Engine implicitly handles the most common forms of audit found in many trusted systems. Auditable events such as entity creation, entity destruction, modification of an entity's security parameters, etc. are all logged by the Generic Policy Engine. Bell-LaPadula does not explicitly require audit since in a perfectly functioning Bell-LaPadula Security Policy, no breaches would be possible. It is only when the implementation moves from the realm of mathematics to one of computer logic that errors can occur that cannot be easily verified. These e ⁇ ors could result in breaches of security with a resulting improper disclosure or manipulation of protected information. Audit facilities are therefore utilized in an attempt to catch breaches as they occur for various reasons including possible prosecution.
  • the Bell-LaPadula Security Policy uses readable names to differentiate various entities. If the GPE were connected to a working operating system, however, unique identifiers understood by the operating system would be used instead. The GPE requires only that the identifiers be unique, regardless of syntax. Most operating systems use numeric representations to ensure uniqueness. This is sufficient for the GPE.
  • the Bell-LaPadula Security Policy definition utilizes five functions, as defined below, to assist in manipulating the security information properly and efficiently for the Bell- LaPadula Security Policy.
  • getLevel Returns the current security level for the entity as a numeric quantity.
  • getRight entity privilege
  • GetCategories entity
  • getCaveat entity
  • Setl set2 Returns ttT if the setl is a true subset of set2, ttF otherwise.
  • the Bell-LaPadula Security Policy controls the disclosure of information. To perform this task in a dynamic environment requires that the access controls be constantly updated with current and relevant information pertaining to valid subject-object (active entity- passive entity) interactions.
  • the following figures illustrate how the access controls can be updated and how the Bell-LaPadula Security Policy is invoked to mediate subject- object interaction.
  • gpeAC ebacic put write Request that ebacic be allowed to write to GPE.doc allow GPE.doc
  • gpeAC jagoda put read Request that jagoda be allowed to read GPE.doc allow GPE.doc
  • GPE.doc get read allow Returns all entities that are allowed to read GPE.doc gpe (DOR get execute deny) Returns all entities that are allowed to execute DOR
  • gpe (ed read GPE.doc) returns whether ed can read the file GPE.doc
  • gpe (dan delete John) returns whether dan has the right to delete John
  • Message Trusted Guards are defined in terms of users and electronic mail addresses. Controls are placed upon the destinations to which specific users can transmit electronic mail messages. No restrictions are placed on incoming e-mail, even though a Message Trusted Guard is capable of controlling both incoming and outgoing connections. Modern implementations of Message Trusted Guards are embedded within Firewalls, however, earlier this decade stand-alone MTGs were quite common and typically were thousands of lines of C code, much of which handled housekeeping functions for the security controls. The GPE implementation, described below, is less than 50 lines and offers the same functionality. Implementing a MTG Security Policy in the GPE is straightforward with the active entity being the actual e-mail message/sender pair and the passive entity being the recipient email address pair. The action is always "send". Therefore the calling sequence to the GPE coded security policy is: gpe (sender send recipient).
  • senders and recipients There are two types of entities that are maintained by the Message Trusted Guard: senders and recipients. The most common implementation places restrictions on who can transmit to a given recipient. If a given sender is not explicitly permitted, transmission is denied. In order for the e-mail messages to be transmitted from the current site to a desired destination both the sender and recipient must exist. To exist the entities must be created. There may come a time when an entity needs to be destroyed. We'll utilize the Generic Policy Engine's mechanisms to create and destroy entities and their associated linkages and information. For the Message Trusted Guard we will define two functions.
  • createEntity (type uid) Creates one of the two types of entity (site or user) with the provided unique identifier On successful creation ttT is returned, ttF otherwise.
  • destroyEntity (uid) Destroys the entity and removes all references Returns ttT on successful destruction, ttF otherwise
  • i f exists ( recipientAddress ) then return (user not in recipientAddress . deny) and (user in recipientAddress . allow) else return True ; * address is not expl ici tly indi cated - al low
  • the security officer should preconfigure the MTG to ensure some semblance of protection is provided.
  • the following functions are defined:
  • removeSite Remove site from the list of sites to which access is restricted.
  • addSite Add site to the list of sites to which access is restricted Initially the allow and deny lists are empty denySite (user site) Disallow user from transmitting to site allowSite (user site) Allow user to transmit to site removeUser (user site) Remove user from the allow or deny lists (the user can only reside on a single list)
  • a Message Trusted Guard requires user identification and authentication. All users must be registered with the Message Trusted Guard prior to being allowed to transmit. If they are not in the Message Trusted Guard's list of users, all e-mail by the user is rejected and the action audited for future actioning by the security officer.
  • the Generic Policy Engine implicitly handles audit for the Message Trusted Guard. All mail messages are audited as the flow through the system by explicitly calling the GPE audit routines. Information stored includes sender, recipient, message ID, and status of the transmission.
  • the Message Trusted Guard Policy Model controls the transmission of electronic mail between a host site and select destinations.
  • the following illustrates how a calling application can quickly deduce whether or not a message can be transmitted to the destination: gpe (usertcb.secret.ora send dictator&banana. republic)
  • the function gpe () invokes the security policy Mess ⁇ ge-Trusted-Gu ⁇ rd ( ) and either a true is received granting transmission rights to the electronic mail message or a false is received, denying transmission rights.
  • the GPE offers a unique and flexible approach to creating security policies.
  • the policies are defined solely as security policies performing a singular task: that of mediating information flow.
  • the security policies implemented utilizing the GPE are short and easy to read guaranteeing fewer errors and omissions.
  • Two example security policies have been provided illustrating the elegance of GPE implemented security policies. These security policies illustrate two popular security policies currently in use.
  • the following provides the code for the Biba Integrity Secu ⁇ ty Policy utilizing the existing code of the Bell-LaPadula Security Policy.
  • Biba is the complement of the Bell-LaPadula Security Policy it should be a simple matter to modify Bell-LaPadula into Biba.
  • the only changes required are trivial.
  • the support routines for Bell-LaPadula remain unchanged.
  • Idyllic is small and interpreted. It offers adequate performance in its interpreted state. However, being small allows it to be easily optimized and the use of a simple language based on Scheme allows for faster, compiled implementations.
  • GSSAPI Generic Security Services API

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Selon cette invention, un moteur de politique générique (GPE) utilise un langage vérifiable, du type de Scheme, pour générer des politiques de sécurité allant des modèles classiques hiérarchiques aux modèles modernes commerciaux. Le moteur GPE offre aux concepteurs de systèmes des points d'entrée de sécurité bien connus, une définition générique d'un 'objet' et un moyen pour manipuler ces objets en termes de politique de sécurité. La nature centralisée du système permet d'expérimenter différentes politiques de sécurité de façon rapide et économique.
EP00910452A 1999-03-15 2000-03-15 Systeme de securite informatique Withdrawn EP1159812A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12448799P 1999-03-15 1999-03-15
US124487P 1999-03-15
PCT/CA2000/000276 WO2000056027A1 (fr) 1999-03-15 2000-03-15 Systeme de securite informatique

Publications (1)

Publication Number Publication Date
EP1159812A1 true EP1159812A1 (fr) 2001-12-05

Family

ID=22415169

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00910452A Withdrawn EP1159812A1 (fr) 1999-03-15 2000-03-15 Systeme de securite informatique

Country Status (4)

Country Link
EP (1) EP1159812A1 (fr)
AU (1) AU3266900A (fr)
CA (1) CA2368000A1 (fr)
WO (1) WO2000056027A1 (fr)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7290266B2 (en) 2001-06-14 2007-10-30 Cisco Technology, Inc. Access control by a real-time stateful reference monitor with a state collection training mode and a lockdown mode for detecting predetermined patterns of events indicative of requests for operating system resources resulting in a decision to allow or block activity identified in a sequence of events based on a rule set defining a processing policy
WO2005032042A1 (fr) 2003-09-24 2005-04-07 Infoexpress, Inc. Systemes et procedes de controle d'acces reseau
US20050198283A1 (en) * 2004-01-07 2005-09-08 Sundaresan Ramamoorthy Managing a network using generic policy definitions
US8181219B2 (en) 2004-10-01 2012-05-15 Microsoft Corporation Access authorization having embedded policies
US7818781B2 (en) 2004-10-01 2010-10-19 Microsoft Corporation Behavior blocking access control
KR20060050768A (ko) * 2004-10-01 2006-05-19 마이크로소프트 코포레이션 액세스 인가 ａｐｉ
EP1788505A1 (fr) * 2005-11-21 2007-05-23 Research In Motion Limited Méthode et système pour l'opération d'une application dans un appareil portatif
US8045958B2 (en) 2005-11-21 2011-10-25 Research In Motion Limited System and method for application program operation on a wireless device
US7890315B2 (en) 2005-12-29 2011-02-15 Microsoft Corporation Performance engineering and the application life cycle
US7818788B2 (en) 2006-02-14 2010-10-19 Microsoft Corporation Web application security frame
US8332906B2 (en) 2006-02-27 2012-12-11 Research In Motion Limited Method of customizing a standardized IT policy
US7712137B2 (en) 2006-02-27 2010-05-04 Microsoft Corporation Configuring and organizing server security information
US8201215B2 (en) 2006-09-08 2012-06-12 Microsoft Corporation Controlling the delegation of rights
US8060931B2 (en) 2006-09-08 2011-11-15 Microsoft Corporation Security authorization queries
US7814534B2 (en) 2006-09-08 2010-10-12 Microsoft Corporation Auditing authorization decisions
US8095969B2 (en) 2006-09-08 2012-01-10 Microsoft Corporation Security assertion revocation
US8938783B2 (en) 2006-09-11 2015-01-20 Microsoft Corporation Security language expressions for logic resolution
US8656503B2 (en) 2006-09-11 2014-02-18 Microsoft Corporation Security language translations with logic resolution
US20090070853A1 (en) * 2007-09-12 2009-03-12 International Business Machines Corporation Security Policy Validation For Web Services
US8898304B2 (en) * 2012-07-11 2014-11-25 Ca, Inc. Managing access to resources of computer systems using codified policies generated from policies

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0056027A1 *

Also Published As

Publication number Publication date
AU3266900A (en) 2000-10-04
CA2368000A1 (fr) 2000-09-21
WO2000056027A1 (fr) 2000-09-21

Similar Documents

Publication Publication Date Title
Hu et al. Assessment of access control systems
Wallach et al. Extensible security architectures for Java
US7591003B2 (en) Security policies in trusted operating system
Samarati et al. Access control: Policies, models, and mechanisms
Gray et al. D’Agents: Security in a multiple-language, mobile-agent system
Zurko et al. A user-centered, modular authorization service built on an RBAC foundation
EP1159812A1 (fr) Systeme de securite informatique
Hu et al. Guidelines for access control system evaluation metrics
Gutmann The Security Architecture
Lang et al. Developing secure distributed systems with CORBA
Neumann Architectures and formal representations for secure systems
Bidan et al. Security benefits from software architecture
Holford et al. Using self-defending objects to develop security aware applications in java
Lee Essays about computer security
Zeleznik Security design in distributed computing applications
Karjoth An operational semantics of Java 2 access control
Rabin et al. An integrated toolkit for operating system security
Maamir et al. Adding flexibility in information flow control for object-oriented systems using versions
Gutmann The design and verification of a cryptographic security architecture
Nicomette et al. A multilevel security model for distributed object systems
Hale et al. A ticket-based access control architecture for object systems
Shin An extension of role based access control for trusted operating systems and its coloured petri net model
Syalim Controlling Access to Encrypted Databases Using Multipolicy Access Control System
Bodeau et al. Distributed Object Computing (DOC) Security: Paradigms and Strategies
van Staden The use of a virtual machine as an access control mechanism in a relational database management system.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20011010

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20031001