csuf chapter 9 1. policy, models, and trust 2 security policy a security policy is a well-defined...

CSUF Chapter 9 1

Policy, Models, and Trust 2

Security Policy A security policy is a well-defined set of rules that include the following: Subjects: the agents who interact with the system, which could be defined in terms of specific individuals or in terms of roles or ranks that groups of individuals might hold within an organization. Individuals could be identified by their names or by their job titles, like President, CEO, or CFO. Groups could be defined using terms such as users, administrators, generals, majors, faculty, deans, managers, and administrative assistants. This category also includes outsiders, such as attackers and guests. Objects: the informational and computational resources that a security policy is designed to protect and manage. Examples include critical documents, files, and databases, and computational resources include servers, workstations, and software. Actions: the things that subjects may or may not do with respect to the objects. Examples include the reading and writing of documents, updating software on a web server, and accessing the contents of a database. Permissions: mappings between subjects, actions, and objects, which clearly state what kinds of actions are allowed or disallowed. Protections: the specific security features or rules that are included in the policy to help achieve particular security goals, such as confidentiality, integrity, availability, or anonymity. 3

Security Models A security model is an abstraction that provides a conceptual language for administrators to specify security policies. Typically, security models define hierarchies of access or modification rights that members of an organization can have, so that subjects in an organization can easily be granted specific rights based on the position of these rights in the hierarchy. Examples include military classifications of access rights for documents based on concepts like unclassified, confidential, secret, and top secret. 4 U.S. government image in the public domain.

Discretionary Access Control Discretionary access control, or DAC, refers to a scheme where users are given the ability to determine the permissions governing access to their own files. DAC typically features the concept of both users and groups, and allows users to set access- control measures in terms of these categories. In addition, DAC schemes allow users to grant privileges on resources to other users on the same system. 5

Mandatory Access Control Mandatory access control is a more restrictive scheme that does not allow users to define permissions on files, regardless of ownership. Instead, security decisions are made by a central policy administrator. Each security rule consists of a subject, which represents the party attempting to gain access, an object, referring to the resource being accessed, and a series of permissions that define the extent to which that resource can be accessed. Security-Enhanced Linux (SELinux) incorporates mandatory access control. 6

Trust Management A trust management system is a formal framework for specifying security policy in a precise language, which is usually a type of logic or programming language, together with a mechanism for ensuring that the specified policy is enforced. A trust management system consists of two main components: a policy language a compliance checker Policy rules are specified in the policy language and are enforced by the compliance checker. 7

Trust Management Systems A trust management system typically has rules describing: Actions: operations with security- related consequences on the system Principals: users, processes, or other entities that can perform actions on the system Policies: precisely written rules that govern which principals are authorized to perform which actions Credentials: digitally signed documents that bind principal identities to allowable actions, including the authority to allow principals to delegate authority to other principals. 8

Access Control Models Various models have been developed to formalize mechanisms to protect the confidentiality and integrity of documents stored in a computer system. The Bell-La Padula (BLP) model The Biba model The Low-Watermark model The Clark-Wilson model The Chinese Wall model (The Brewer and Nash model) 9

The Bell-La Padula Model The Bell-La Padula (BLP) model is a classic mandatory access-control model for protecting confidentiality. The BLP model is derived from the military multilevel security paradigm, which has been traditionally used in military organizations for document classification and personnel clearance. 10

The Bell-La Padula Model The BLP model has a strict, linear ordering on the security of levels of documents, so that each document has a specific security level in this ordering and each user is assigned a strict level of access that allows them to view all documents with the corresponding level of security or below. 11

Total Orders and Partial Orders A linear ordering for documents can be defined in terms of a comparison rule,. We say that such a rule defines a total order on a universe set, U, if it satisfies the following properties: 1. Reflexivity: If x is in U, then x < x. 2. Antisymmetry: If x < y and y < x, then x = y. 3. Transitivity: If x < y and y < z, then x < z. 4. Totality: If x and y are in U, then x < y or y < x. All of the usual definitions of less than or equal to for numbers, such as integers and real numbers, are total orders. If we drop the requirement of totality, we get a partial order. The classic example of a partial order is the set of courses taught at a college or university, where we say that, for two courses A and B, A < B, if A is a prerequisite for B. 12

How the BLP Model Works The security levels in BLP form a partial order, R2, if R1 includes all permissions of R2 and R2 includes all users of R1. When R1 > R2, we also say that role R1 is senior to role R2 and that role R2 is junior to role R1. For example, in a company, the role manager inherits the role employee and the role vice president inherits the role manager. Also, in a university, the roles undergraduate student and graduate student inherit the role student. 28

Visualizing Role Hierarchy 29

The Orange Book 30

Foundations of the Common Criteria 3 European National & Regional Initiatives 89-93 Canadian Initiatives 89-93 Common Criteria Project 93-- ISO IS 15408 99 2005 2009s US TCSEC 83, 85 CTCPEC 3 93 Federal Criteria 92 Common Criteria 1.0 96 ITSEC 1.2 91 ISO Initiatives 92-- = Canadian

CC Structure FAMILY CLASS Component PP or ST FAMILY Component (Functional or Assurance) Flexibility of defining requirements. PP Protection Profile ST Security Target

Products Based on the Common Criteria Protection Profile (PP) An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs (e.g., operating system protection profile) Security Target (ST) A set of security requirements and specifications to be used as the basis for evaluation of a specific TOE (e.g., security specification for a particular operating system)

Common Criteria Structure & Usage Part 1: Introduction and General Model Part 2: Security Functional Requirements and Annexes User/developer needs to consider the threats to the IT environment Pool of components that can be collated to form the security requirements definition of a trusted product or system User presents the security requirements in the PPs and the ST of the TOE Part 3: Security Assurance Requirements Pool of components from which assurance requirements for a TOE can be chosen User presents the security assurance requirements in the PPs and STs

CC Part 2 Security Functional Requirements Audit (FAU) Involves recognizing, recording, storing, and analyzing information related to security activities Communications (FCO) Concerned with assuring the identity of a party participating in data exchange Concerned with non-repudiation by the originator and by the recipient of data User Data Protection (FDP) Concerned with protection of user data within the TOE Identification and Authentication (FIA) Ensures the unambiguous identification of authorized users and the correct association of security attributes with users and subjects Determine and verify user identity, determine their authority to interact with the TOE, and with the correct association of security attributes with the user Privacy (FPR) Provides a user with protection against discovery and misuse of his identity by other users

CC Part 2 Security Functional Requirements (cont.) Protection of the Trusted Functions (FTP) Focused on protection of TSF (TOE security functions) data, rather than of user data Resource Utilization (FRU) Support the availability of required resources, such as processing capability and storage capacity TOE Access (FTA) Controls the establishment of a users sessions Limit the number and scope of user sessions, displaying access history, and the modification of access parameters Trusted Path / Channels (FTP) Concerned with trusted communications paths between the users and the TSF, and between TSFs Trusted paths are constructed from trusted channels, which exist for inter-TSF communications Guaranteed to be protected from modification by untrusted applications

CC Part 3 Security Assurance Requirements Configuration Management (ACM) Ensures that the integrity of the TOE is adequately preserved Provides confidence that the TOE and documentation used for evaluation are the ones prepared for distribution Delivery and Operation (ADO) Concerned with the measures, procedures, and standards for secure delivery, installation, and operational use of the TOE Ensures that the security protection offered by the TOE is not compromised during these events Development (ADV) Concerned with the refinement of the TSF from the specification defined in the ST to the implementation, and a mapping from requirements to the lowest level representation Guidance Documents (AGD) Concerned with the secure operational use of the TOE by users and administrators

CC Part 3 Security Assurance Requirements Life Cycle Support (ALC) Concerned with lifecycle definition, tools and techniques, the developers security and the remediation of flaws found by TOE consumers Tests (ATE) Concerned with demonstrating that the TOE meets its functional requirements Addresses issues of coverage, depth, TOE requirements, and independent testing Vulnerability Assessment (AVA) Identification of exploitable vulnerabilities Protection Profile Evaluation (APE) Demonstrate that the PP is complete, consistent, and technically sound Security Target Evaluation (ASE) Demonstrate that the ST is complete, consistent, and technically sound

Evaluation Assurance Levels The Common Criteria defines Evaluation Assurance Levels (EALs) from 1 to 7. There are several simplified ways of characterizing the EALs, for example: Untested No assurance EAL 1-4 Risk Management EAL 5-7 Risk Avoidance Basic Assurance ~ EAL 1-2 Medium Assurance ~ EAL 3-4 High Assurance ~ EAL 5-7 The Higher the Level of Assurance the harder, more expensive, time consuming and risky to achieve.

CC Part 3 Evaluation Assurance Levels (EALs) Set of defined assurance levels constructed using components from the assurance families Provides a uniformly increasing scale which balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance Defines a scale for measuring the criteria for evaluation Components in each family are mapped into these EALs EAL 1: Functionally Tested EAL 2: Structurally Tested EAL 3: Methodically Tested and Checked EAL 4: Methodically Designed, Tested, and Reviewed EAL 5: Semiformally Designed, and Tested EAL 6: Semiformally Verified, Designed, and Tested EAL 7: Formally Verified, Designed, and Tested At the top, EAL7, level there are significant limitations on the practicability of meeting the requirements, partly due to substantial cost impact on the developer and evaluator activities, and also because anything other than the simplest of products is likely to be too complex to submit to current state-of-the-art techniques for formal analysis from Common Criteria: An Introduction

Required Robustness (likelihood of compromise) Highest Value of Resources Associated with the System Authorization Defined for Least Trustworthy Entity Fully Authorized Partially Authorized Not Authorized Low Value High Value Robustness Concept is Related to CC Assurance Basic Medium High