Formal Models of Security

Define Security Levels: A >  B > C

Subject X is Level A, Subject Y is Level B

Rule: Access (S,O) if and only if Level(S) >= Level(O)

Define Security Policy for reference monitor: Allow(Subject, Object, Access) -> {True, False}

For example, Allow(S,O,A) <- -> Owner(S,O) OR IsAdmin(S)

Short: hierarchial levels, no read-up, no write-down.

The model focuses on data confidentiality and controlled acces to classified information.

Long:

a. There are four componets: (1) Subjects, (2) Objects, (3) Modes of access: read, write, execute, and (4) Security Levels

b. There are three principles:

(1) Simple security property: Read only if Level(S) >= Level(O)

(2) Confinement property (aka. "star" property): Write only if Level(O) >= Level(S).

(3) Tranquility principle: An operation may not change the classification level of the subject.

Issue:

Confidentiality of data is protected, but the fact that users with lower privileges are permitted to write data to objects with a higher sensitivity level does not sit well in many environments.

This security model is directed toward data integrity (rather than confidentiality) and is characterized by the phrase: "no read down, no write up".

The model is designed so that subjects may not corrupt objects in a level ranked higher than the subject, or be corrupted by objects from a lower level than the subject.

In general the model was developed to circumvent a weakness in the Bell-LaPadula which only addresses data confidentiality.

The model is primarily concerned with formalizing the notion of information integrity.

The model’s enforcement and certification rules define data items and processes that provide the basis for an integrity policy. The core of the model is based on the notion of a transaction.

• A well-formedtransaction is a series of operations that transition a system from one consistent state to another consistent state.
• In this model the integrity policy addresses the integrity of the transactions.
• The principle of separation of duty requires that the certifier of a transaction and the implementer be different entities.

An abstract machine that mediates all access control decisions.

1) A system's functional requirements.

2) A system's assurance requirements.

3) A methodology to determine if the system meets these requirements.

4) a measure of evaluation (i.e., a level of trust).

1) Security Policy

1a. DAC requirements

1b. Object reuse requirements: Threats of an attacker gathering information from cache and disk

1c. MAC requirements: BLP, etc.

1d. Marking, i.e., label requirements for subject and objects

2) Accountability

2a. Identification reqs

2b. Authentication reqs

2c. Trusted path reqs: How to communicatio between the TCB and the user process

2d. Audit requirements

3) Assurance

4) Documentation.

1) Mixes various levels of abstration in a single document

2) Does not address integrity of data

3) Combines functionality and assurance in a single linear rating scale.

1) File Level

2) Field level

Data Centric Model: Encryption Approach: File Level

(examples)

1) Discretionary Digital Rights Management (DDRM)

2) Manadtory Digital Rights Management (DRM) or Network Tethering

Data Centric Model: Encryption Approach: Field Level

(Examples)

1) Database-level encryption

2) Application field level encryption

Data Centric Model: Discretionary Digital Rights Management (DDRM)

(User path)

1) User Creates file

2) User selects community with which to share file

3) Software retrieves key for community and encrypts file

4) User shares file with community member

5) Member decrypts file using local key

Data Centric Model: Discretionary Digital Rights Management (DDRM)

(Pros and Cons)

Pros:

1) Allows mobile users to accress information remotely with minimal exposure to theft

2) Technology is mature (e.g., PKI, PGP, etc.)

Cons:

1) Mobile users may copy information to unencrypted media

2) Allows users to decide when to encrypt information

3) Admins have super-decryption keys

Data Centric Model: Network Tethering or Mandatory Digital Rights Management (MDRM) or just DRM

(User path)

1. User Creates file

2. User selects community with which to share information

3. Software retrieves key for community, encrypts file and stores on secure storage

4. User share file with community member.

5. Member must authenticate within network to retrieve key and view file.

Data Centric Model: Network Tethering or Mandatory Digital Rights Management (MDRM) or just DRM

(Pros and Cons)

Pros:

1) Allows mobile users to accress information remotely while data never leaves netork.

2) Technology is mature (e.g., PKI, SSL, etc.)

Cons:

1) Mobile users may copy information to unencrypted media, usually with difficulty.

2) Allows users to decide when to encrypt information

3) Admins have super-decryption keys

1. Database Administrator (DBA) createa database scema, specifying fields requrieing encryption.

2. DBA grants rights to certain application community (perhaps at server level)

3. DBMS encrypts specified fields with keys and restricts key access to application users.

4. All users log into app to either store or retrieve data.

Pros:

1) Users cannot copy unencrypted data in bulk, restricted to application functionality.

2) Does not rely on correct user behavior or application code.

Cons:

1) DBA and Application Support still have keys to kingdom (though may be audited)

2) Anyone with direct DB access using application DB ID may still bulk-download (audit not likely)

3) Makes cross-DB queries difficult if not impossible.

Application Field Level (sometimes just Field Level)

(User path)

1) Application developer designs encrytion Application Programming Interfaces (APIs) that encrypt prior to store and decrypt up DB retrieval; DB schema is equipped with shadow query field.

2) Application admin grants rights to users based on need to know

3) APIs encrypt specified fields with keys encrypted by user-level keys and requires user to present private key to decrypt.

4) All users log into app and present keys to store or retrieve data.

Application Field Level (sometimes just Field Level)

(Pros and Cons)

Pros:

1) Users cannot copy unencrypted data in bulk, restricted to application functionality.

2) Technology is mature (e.g., PKI, SSL, etc.)

Cons:

1) Correct implementation relies on application source code.

2) Shadow field may introduce synchronization issues

3) Super-admin still has keys to kingdon (though can be minimized via obscurity)

1) Identity and Entitlements

2) Information Confidentiality and Integriy Mechanisms

3) Configuration

4) Real Time Monitor

5) Log Management

6) Alerting Mchanisms

7) Recovery Processes

Services Model (Main Parts)

A. Prevent

1) Authenication

2) Authorization

3) Acces Control Enforcement

4) Transaction Privacy

5) Non-repudiation

6) Protected Communications

B. Recover

7) Audit

8) Proof of wholeness

9) Restore "Secure" state

10) Intrusion Detection and Containment

C. Support

11) Identification (and naming)

12) Cryptographic Key Management

13) Security Administration

14) System Protections (least privilege, object reuse, process separtion, etc.)

Breaks systems into:

A. Layers: Are a hierarchy of equipment and facilities groupings.

1) Infrastructure Security layer

2) Services Security Layer

3) Applications Security Layer

B. Planes: Represent the types of activities that occur on a network.

1) Management Security Plane

2) Control/Signaling Security Plane

3) End-User Security Plane

Each security plane is applied to every security layer to yield nine security perspectives.

Agile Security Patterns (acronym definition)

SAREPH

S - Self organizing

A - Adapting to upredictable situations with reconfigurable, readily employed resources

R - Reactively resilient: Able to continue, perhaps with reduced functionality, while recovering.

E - Evolving in concert with a changing environment

P - Proactively innovative: acting preemptively, perhaps unpredictably, to gain advantage

H - Harmonious with system purpose: aiding rather than degrading system and user productivity.

Intercept and disperse; resource accepts requests as desired