Lesson 18 Security Models and Practices

Subjects

Agents who interact with the system

Objects

Resources that security policy is designed to protect

Actions

Things that subjects may or may not do with respect to the objects

Permissions

Mappings between subjects, actions and objects which state what kind of actions are allowed or disallowed

Protections

Specific security features or rules that are included in the policy

Security Model

Provides conceptual language to specify security

Define hierarchies of access rights for members of an organization

Trust Management System

A formal framework for specifying security policies based on a security model in a precise language

Discretionary Access Control (DAC)

A scheme where users can determine the permissions governing access to their own files

Mandatory Access Control (MAC)

Does not allow users to define permissions on files, regardless of ownership. Security decisions are made by a policy administrator

Bell-La Padula Model (BLP)

Subjects at a lower security level cannot read data at a higher lever, and a subject at a higher level cannot write data to a lower level.

Biba Model

Designed to stop unauthorized changes; gives integrity levels to users and objects.

Low-watermark Level

Users with higher integrity levels can read objects with lower integrity levels, the user performing the reading is demoted such that his integrity matches that of the read object

Chinese Wall Model/Brewer and Nash Model

Each user can only access one resource from each conflict of interest class

Role Based Access Control

Associates access rights with roles rather than subject, a role is a collection of job functions

User

An entity that wishes to access resources of the organization to perform a task

Role

A collection of users with similar functions and responsibilities in the organization

Permisison

An allowed method of access to a resources

Session

Activation of a subset of roles of a user

Separation of Duty

One individual cannot be assigned as roles R1 and R2

Static

Enables the definition of a set of roles, if a user is assigned to one role it cannot be assigned to any other role

Dynamic

Limits the permissions available to a user by placing constraints on the roles that can be activated in one session

Constrained RBAC

Access control decisions are also influenced by additional constraints that limit the activation of certain roles based on contextual factors such as time, location and other conditions

Privacy Aware RBAC

-Purpose: Reason for accessing data

-Conditions: Prerequistes must be met before any action can be executed

-Obligation: Actions to be performed after access

Used mainly for scenarios that contain sensitive information that is subject to privacy regulations (health, finance, etc..)

Extensible Access Control Markup Language (XACML)

-Separates policy decision from enforcement

-Supports attribute based access control

-Defines and enforces fine grained access control policies

Policy Enforcement Point (PEP)

Responsible for intercepting access request and forwarding them to PDP

Policy Decision Point (PDP)

Responsible for evaluation access requests against the access control policies defined in PIP

Policy Information Point (PIP)

Responsible for providing additional information to the PDP, such as user attributes, resource attributes and other contextual information