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
Slide 4
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.
Slide 5
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
Slide 6
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
Slide 7
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
Slide 8
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
Slide 9
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
Slide 10
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
Slide 11
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
Slide 12
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
Slide 13
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
Slide 29
Visualizing Role Hierarchy 29
Slide 30
The Orange Book 30
Slide 31
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
Slide 32
CC Structure FAMILY CLASS Component PP or ST FAMILY Component
(Functional or Assurance) Flexibility of defining requirements. PP
Protection Profile ST Security Target
Slide 33
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)
Slide 34
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
Slide 35
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
Slide 36
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
Slide 37
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
Slide 38
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
Slide 39
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.
Slide 40
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
Slide 41
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