Module 1: Classical Security Module 2: Access Control Mechanisms
Models in Computer Security
Bell-La Padula model Access control list (ACL)
Biba model Mandatory access control (MAC)
Clark-Wilson model Role-based access control (RBAC)
Brewer and Nash model Context-based access control (CBAC)
Graham-Denning model Lattice-based access control (LBAC)
Harrison-Ruzzo-Ullman (HRU)
Module 3: Advanced Security Module 4: Computer Security Models
Models in Computer Systems and Mechanisms
Capability-based security Object-capability model
Multi-level security (MLS) Take-grant protection model
Non-interference (security) Protection ring
High-water mark (computer security)
Module 1: Classical Security Models
Module Introduction
This module delves into classical security models, which are foundational to
understanding and implementing robust security policies in computer systems. These
models provide structured frameworks to manage and control access to sensitive
information, ensuring confidentiality, integrity, and preventing conflicts of interest. The
module covers six pivotal models: Bell-LaPadula, Biba, Clark-Wilson, Brewer and Nash,
Graham-Denning, and Harrison-Ruzzo-Ullman (HRU). Each model addresses specific
security requirements and challenges, offering unique mechanisms to enforce access
controls.
Unit 1: Bell-La Padula model
Unit 2: Biba model
Unit 3: Clark-Wilson model
Unit 4: Brewer and Nash model
Unit 5: Graham-Denning model
Unit 6: Harrison-Ruzzo-Ullman (HRU)
In each unit, I will explore a particular topic in detail and highlight self-assessment
exercises at the end of the unit. Finally, I highlight resources for further reading at the
end of each unit.
Unit 1: Bell-La Padula model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Definitions and Teminologies of Bell-La Padula model
3.2 Purpose of the Bell–LaPadula model
3.3 Security Levels
3.3.1 Definition and Purpose security levels
3.3.2 Classifications of security levels.
3.4 The Bell–LaPadula Model Security Properties
3.4.1 Subject
3.4.2 Object
3.5 Access Modes: Read, Write, and Execute
3.6 Interaction between Subjects and Objects
3.6.1 Simple Security Property (No Read Up)
3.6.2 Property (No Write Down)
3.7 Strengths and of the Bell–LaPadula Model
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit the definition, terminologies and purpose of the bell-
LaPadula model. After studying the unit, you will be equipped with skills of the basic
concepts of the Bell-Lapadula Model and its distinguishing features.
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Define the Bell–LaPadula model, terminologies.
Identify and classify different security levels in Bell–LaPadula model.
3.0 Main Content
3.1 DEFINITIONS OF BELL-LA PADULA MODEL
The definitions below cover various aspects of the Bell–LaPadula model, highlighting its
conceptual foundations, security properties, mathematical basis, practical applications,
and comparison with other security models.
Definition 1: Basic Conceptual Overview
The Bell–LaPadula model is a formal security model designed to maintain the
confidentiality of data in computer systems. It achieves this by defining access control
rules based on security labels assigned to both users (subjects) and data (objects),
ensuring that information does not flow from a higher security level to a lower security
level.
Definition 2: Security Properties Emphasis
The Bell–LaPadula model is a state machine model used to enforce data confidentiality
policies in multi-level security systems. It is characterized by two primary properties: the
Simple Security Property (which prevents subjects from reading data at a higher
security level) and the *-Property (which prevents subjects from writing data to a lower
security level).
Definition 4: Practical Implementation Perspective
The Bell–LaPadula model is an access control framework commonly implemented in
military and government systems to safeguard sensitive information. By assigning
security classifications to both data and users, and by restricting access based on these
classifications, the model effectively prevents data leakage and ensures compliance
with strict confidentiality requirements.
TERMINOLOGIES
The Bell–LaPadula model involves several key terminologies that are essential to
understanding how the model operates. Here are the primary terms associated with the
Bell–LaPadula model:
1. Subject: A subject is an active entity, usually a user or a process, that requests
access to objects. Subjects can perform actions on objects within the constraints
of the model's rules.
2. Object: An object is a passive entity that contains or receives information.
Examples of objects include files, databases, and documents.
3. Security Labels: Security labels are markings assigned to both subjects and
objects. They consist of:
Classification Levels: Hierarchical levels such as Top Secret, Secret,
Confidential, and Unclassified.
Categories: Non-hierarchical compartments or groups that further
specify access requirements.
4. Simple Security Property (ss-property): Also known as the "No Read Up"
(NRU) rule, this property stipulates that a subject at a given security level cannot
read data at a higher security level. It enforces the principle that subjects should
not access information for which they lack clearance.
5. Star (*) Security Property: Also known as the "No Write Down" (NWD) rule, this
property states that a subject at a given security level cannot write information to
a lower security level. This prevents the leakage of sensitive information to less
secure levels.
6. Discretionary Security Property (ds-property): This property involves
discretionary access controls where the owner of an object can determine who is
allowed to access it. It supplements the mandatory access controls (Simple
Security and *-Properties) by adding a layer of user-defined access restrictions.
7. Access Modes: Different types of access actions that subjects can perform on
objects:
Read (R): Accessing the contents of an object.
Write (W): Modifying the contents of an object.
Execute (X): Running or executing an object.
8. Security Levels: The hierarchical levels of security clearance and classification,
which define the sensitivity of information and the clearance required to access it.
9. Secure State: A state where the only permitted access modes of subjects to
objects are in accordance with the security policy.
10. Trusted Subjects: Subjects that are not restricted by the Star-property and must
be shown to be trustworthy with regard to the security policy.
11. Tranquility Principle: Ensures that subjects cannot change their current security
level or drop to a lower level than the highest level they have read so far.
12. Discretionary Access Control (DAC): Gives individual users control over who
can access the information they own.
13. Lattice-Based Access Control: A mathematical framework used in the Bell–
LaPadula model where security levels form a lattice structure, allowing for the
definition and enforcement of access control rules based on the relationships
between different security levels.
14. State Machine Model: The Bell–LaPadula model is represented as a state
machine, where the system is defined by a set of states, state transitions, and
access control rules that ensure transitions between states do not violate security
policies.
15. Mandatory Access Control (MAC): A type of access control enforced by the
system rather than the user's discretion, based on security labels and predefined
rules like the Simple Security and *-Properties.
16. Information Flow Control: The mechanism that regulates how information can
be transferred between subjects and objects, ensuring that it adheres to the
confidentiality rules set by the Bell–LaPadula model.
Understanding these terminologies is crucial for grasping the principles and functioning
of the Bell–LaPadula model, as they form the foundation of its access control
mechanisms and security policies.
3.2 PURPOSE OF THE BELL–LAPADULA MODEL
The Bell–LaPadula model serves several key purposes, primarily focused on
maintaining the confidentiality and control of sensitive information within a system. Here
are the main purposes itemized:
1. Ensure Data Confidentiality: The primary purpose is to protect sensitive
information from unauthorized access and disclosure.
2. Implement Access Control Policies: To provide a formal framework for
defining and enforcing access control policies based on security classifications
and clearances.
3. Prevent Unauthorized Read Access: To enforce the Simple Security Property
(No Read Up), ensuring that subjects cannot read data at higher security levels
than their clearance.
4. Prevent Unauthorized Write Access: To enforce the Star (*) Security Property
(No Write Down), ensuring that subjects cannot write data to lower security
levels, thereby preventing information leakage.
5. Support Mandatory Access Control (MAC): To implement a system-enforced
access control mechanism that does not rely on user discretion, enhancing
overall security by adhering to strict rules.
By fulfilling these purposes, the Bell–LaPadula model contributes significantly to the
integrity and security of information systems, particularly in environments where
confidentiality is paramount.
3.3 Security Levels
The Bell–LaPadula model categorizes information into security levels, typically
represented as labels such as "Top Secret," "Secret," "Confidential," and "Unclassified."
These security levels play a crucial role in enforcing data confidentiality and access
control policies within the model. The model's security levels are designed to control
access to classified information and prevent unauthorized access to sensitive data.
3.3.1 Definition and Purpose security levels
Security levels in the Bell–LaPadula model represent a hierarchy of sensitivity and
clearance within an information system. Each level indicates the degree of
confidentiality required for information and the corresponding clearance needed by
users to access that information. The purpose of these security levels is to establish a
structured and controlled environment where information flow is regulated to prevent
unauthorized access and disclosure.
3.3.2 Classifications of security levels (Top Secret, Secret, Confidential,
Unclassified)
The Bell–LaPadula model classifies security levels to control access to information
based on its sensitivity and the clearance of users. This classification helps maintain
data confidentiality by ensuring that information is accessed and handled appropriately
according to its level of sensitivity. Here is a detailed classification of security levels
commonly used in the model:
Common Security Levels
1. Top Secret (TS): This is the highest level of classification. Information classified
as Top Secret is extremely sensitive and its unauthorized disclosure could cause
exceptionally grave damage to national security.
Examples: Strategic military plans, intelligence operations, high-level
diplomatic communications.
2. Secret (S): Secret information is less sensitive than Top Secret but still critical.
Its unauthorized disclosure could cause serious damage to national security.
Examples: Detailed military plans, certain intelligence reports, sensitive
government communications.
3. Confidential (C): Confidential information requires protection as its unauthorized
disclosure could cause damage to national security.
Examples: Some military communications, lower-level intelligence data,
certain governmental or commercial information.
4. Unclassified (U): Unclassified information does not require protection under
national security terms but may still be protected under other policies (e.g.,
privacy, proprietary data).
Examples: Publicly available information, press releases, general
communications.
3.4 THE BELL–LAPADULA MODEL SECURITY PROPERTIES
In the Bell–LaPadula model, subjects and objects are core components, each playing a
distinct role in the enforcement of access control policies aimed at maintaining data
confidentiality. Understanding their definitions and roles is crucial to grasping how the
model operates.
3.4.1 Subject
A subject in the Bell–LaPadula model is an active entity, usually a user or a process,
that requests access to objects within a computer system. Subjects can perform
operations such as reading, writing, or executing on objects, and their actions are
governed by the security policies defined in the model.
Characteristics:
Clearance Level: Each subject is assigned a security clearance level (e.g., Top
Secret, Secret, Confidential, and Unclassified) which determines the highest
classification level of information they are authorized to access.
Categories/Compartments: Subjects may also be associated with specific
categories that denote their permissions to access certain types of information
within their clearance level.
Active Entity: Subjects initiate actions and interactions with objects.
Examples:
A military officer with Secret clearance who needs to access confidential battle
plans.
An application process running on a server that processes sensitive user data.
3.4.2 Object
An object in the Bell–LaPadula model is a passive entity that contains or receives
information. Objects are the targets of access requests by subjects and include data
structures, files, databases, documents, and other types of stored information.
Characteristics:
Classification Level: Each object is assigned a security classification level (e.g.,
Top Secret, Secret, Confidential, and Unclassified) which indicates the sensitivity
of the information it contains.
Categories/Compartments: Objects may also be tagged with specific
categories that provide additional constraints on access based on the type of
information they hold.
Passive Entity: Objects do not initiate actions; they are accessed or manipulated
by subjects.
Examples:
A document labeled Top Secret containing classified military intelligence.
A database table containing confidential financial records.
3.5 ACCESS MODES: READ, WRITE, AND EXECUTE
The Bell–LaPadula model defines specific access modes to regulate how subjects
interact with objects. These access modes are crucial for enforcing the model's
confidentiality policies, ensuring that information is accessed and manipulated in a
secure manner. Here are the primary access modes defined in the Bell–LaPadula
model:
1. Read Access (Read): Allows a subject to view the contents of an object.
Simple Security Property (No Read Up): A subject can read an object only if
the object's classification level is less than or equal to the subject's clearance
level.
Example: A user with Secret clearance can read documents classified as Secret,
Confidential, and Unclassified, but cannot read Top Secret documents.
2. Write Access (Write): Allows a subject to modify or update the contents of an object.
Star (*) Security Property (No Write Down): A subject can write to an object
only if the object's classification level is greater than or equal to the subject's
clearance level.
Example: A user with Secret clearance can write to documents classified as
Secret and Top Secret, but cannot write to Confidential or Unclassified
documents.
3. Execute Access (Execute): Allows a subject to execute an object, such as running a
program or script.
Considerations: Execute access typically does not involve reading or writing
data but may still be subject to security policies to prevent unauthorized actions.
Example: A user might need Top Secret clearance to execute a sensitive
program designed for Top Secret operations.
Additional Access Modes (Context-Dependent)
While the Bell–LaPadula model primarily focuses on read and write access, other
access modes can be defined based on specific system requirements. These might
include:
4. Append Access (Append): Allows a subject to add data to an object without being
able to modify existing content.
Example: Logging systems where users can add entries but cannot alter existing
log data.
5. Delete Access (Delete): Allows a subject to remove an object or its content.
Considerations: Deleting sensitive information must be carefully controlled to
avoid unauthorized data removal.
6. Create Access (Create): Allows a subject to create new objects within the system.
Example: A user with appropriate clearance can create new files or documents
within a classified information repository.
3.6 INTERACTION BETWEEN SUBJECTS AND OBJECTS
The interaction between subjects and objects in the Bell–LaPadula model is governed
by two main properties to ensure the confidentiality of information:
3.6.1 Simple Security Property (No Read Up)
The Simple Security Property, also known as the "No Read Up" rule, states that a
subject at a given security level may not read an object at a higher security level. This
means that a subject can only access information at the same security level or lower,
ensuring that sensitive information is not accessed by unauthorized individuals.
Example: A user with Secret clearance cannot read a Top Secret document.
3.6.2 Property (No Write Down)
The * (Star) Security Property, also known as the "No Write Down" rule, states that a
subject at a specific classification level cannot write data to a lower classification
level. This means that a subject can only write to objects at the same security level or
higher, ensuring that sensitive information is not modified or disclosed to unauthorized
individuals.
Example: A user with Secret clearance cannot write data to a Confidential document,
as this could result in leaking sensitive information to a less secure level.
3.7 Strengths of the Bell–LaPadula Model
1. Confidentiality: The Bell–LaPadula model effectively enforces data
confidentiality by controlling access to classified information based on security
levels and clearance levels.
2. Simple and Easy to Implement: The model is straightforward to implement and
understand, making it a popular choice for many secure operating systems.
3. Formal Security Policy: The Bell–LaPadula model provides a formal security
policy that ensures the security of sensitive information by controlling access
based on security levels and clearance levels.
4. Mandatory Access Control (MAC): The model forms the basis for Mandatory
Access Control (MAC) in many secure operating systems, ensuring that access
is strictly controlled based on security levels and clearance levels.
5. Trusted Subjects: The model allows for trusted subjects that are not restricted
by the Star-property, enabling them to perform operations that require higher
security levels
3.2 Limitations of the Bell–LaPadula Model
1. No Clear Distinction between Protection and Security: The model does not
clearly distinguish between protection and security, which can lead to confusion.
2. No Treatment of Covert Channels: The model does not extensively address
covert channels, which are channels that can be used to pass information without
being detected.
3. No Treatment of Networks of Systems: The model does not address networks
of systems, which can be a significant limitation in modern computing
environments.
4. No Integrity and Availability: The model primarily focuses on confidentiality and
does not address other security aspects like integrity and availability, which may
require additional security models and mechanisms.
5. Tranquility Principle: The tranquility principle ensures that subjects cannot
change their current security level or drop to a lower level than the highest level
they have read so far, which can be a limitation in certain scenarios
In summary, the Bell–LaPadula model is a robust security model that effectively
enforces data confidentiality and mandatory access control. However, it has limitations
in addressing other security aspects like integrity and availability, and does not clearly
distinguish between protection and security.
4.0 Self-Assessment Exercise(s)
1. Define the basic concept of the Bell–LaPadula model.
Answer:
The Bell–LaPadula model is a formal security model designed to maintain the
confidentiality of data in computer systems.
2. Define a Subject.
Answer
Subject: A subject is an active entity, usually a user or a process, that requests access
to objects. Subjects can perform actions on objects within the constraints of the model's
rules.
3. Define an Object.
Answer:
Object: An object is a passive entity that contains or receives information. Examples of
objects include files, databases, and documents.
4. List three different types of access actions that subjects can perform on objects.
Answer:
Read (R): Accessing the contents of an object.
Write (W): Modifying the contents of an object.
Execute (X): Running or executing an object.
5. What ae security labels?
Answer:
Security labels are markings assigned to both subjects and objects. They consist of
classification levels and categories.
6. Define Security level in Bell–LaPadula model.
Answer:
Security levels in the Bell–LaPadula model represent a hierarchy of sensitivity and
clearance within an information system.
7. What is the purpose of establishing security level?
Answer:
The purpose of these security levels is to establish a structured and controlled
environment where information flow is regulated to prevent unauthorized access and
disclosure.
8. What are the Classifications of security levels?
Answer:
Top Secret (TS)
Secret (S)
Confidential (C)
Unclassified (U)
9. Why is strategis military plans classified as Top secret?
Answer:
Information classified as Top Secret is extremely sensitive and its unauthorized
disclosure could cause exceptionally grave damage to national security.
10. Define a subject in the Bell–LaPadula model.
Answer:
A subject in the Bell–LaPadula model is an active entity, usually a user or a process,
that requests access to objects within a computer system.
11. Subjects can perform operations such as _______, _______ or ________on
objects.
Answer:
Reading, writing, or executing.
12. A document and database table are example of ________
Answer:
Object
5.0 Conclusion
The Bell-LaPadula model serves a crucial role in ensuring the confidentiality of sensitive
information in environments where data classification and security clearances are
essential. By enforcing strict access control rules through its simple security property
and *-property, the model prevents unauthorized access and leakage of classified
information, thereby maintaining data confidentiality and supporting the design of secure
systems.
6.0 Summary
At the end of this unit, you have learnt the definition of the Bell–LaPadula model, the
reasons and purposes for implementing the Bell–LaPadula model and some temilogies
associated the Bell–LaPadula model. In the next section, I will introduce you to Bida
Model.
7.0 References/Further Readings
Unit 2: Bida model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Introduction to the Biba Model and its history
3.2 Key concepts.
3.2.1 Integrity levels
3.2.2 Subjects
3.2.3 Objects
3.3 Core Properties of the Biba Model
3.3.1 Simple Integrity Property: no read down
3.3.2 Star (*) Integrity Property: no write up
3.3.3 Invocation Property: no invocation from lower levels
3.4 Real-world applications:
3.4.1 Secure file system
3.4.2 Secure databases
3.4.3 Secure networks
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit fundamentals of data integrity, how important it is in
information systems and some common threats. You will also be introduced to the biba
models and its history, the key concepts of integrity levels, subjects and objects, the
core properties and real world applications of Bida model
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Know data integrity and threats.
Know the basic concepts of Biba models.
3.0 Main Content
3.1 INTRODUCTION TO THE BIBA MODEL AND ITS HISTORY
Data integrity is a fundamental concept in computer security that ensures data remains
accurate, consistent, and reliable throughout its entire lifecycle. The Biba Model,
developed by Kenneth J. Biba in 1975, is a formal state transition system that
addresses data integrity by controlling access to data based on integrity levels.
The Biba Model groups data and subjects (processes) into ordered levels of integrity.
The model is designed to prevent subjects from corrupting data at a higher integrity
level than the subject, or being corrupted by data from a lower level.The Biba Model
defines three main goals for preserving data integrity:
1. Prevent data modification by unauthorized parties
2. Prevent unauthorized data modification by authorized parties
3. Maintain internal and external consistency (i.e., data reflects the real world)
The model is characterized by the phrase "read up, write down", which is the inverse
of the Bell-LaPadula model's "read down, write up" for confidentiality. In the Biba
Model, users can only create content at or below their own integrity level and view
content at or above their own integrity level.The Biba Model defines three main
security rules:
1. The Simple Integrity Property: a subject at a given level of integrity must not
read data at a lower integrity level (no read down).
2. The * (star) Integrity Property: a subject at a given level of integrity must not
write to data at a higher level of integrity (no write up).
3. The Invocation Property: a process from below cannot request higher
access; only with subjects at an equal or lower level.
The Biba Model has been implemented in various operating systems, such as
FreeBSD, Linux, and XTS-400, to ensure data integrity in secure systems.
3.2 KEY CONCEPTS: INTEGRITY LEVELS, SUBJECTS, AND OBJECTS
The Biba Model, developed by Kenneth J. Biba in 1975, is a security model that focuses
on maintaining data integrity. It is based on the premise that information should not be
corrupted by unauthorized or less trustworthy sources. The key concepts in the Biba
Model include integrity levels, subjects, and objects.
3.2.1 INTEGRITY LEVELS
Integrity levels are a hierarchical structure used to rank the trustworthiness of data and
users in a system. They are analogous to security levels in the Bell-LaPadula Model but
focus on data integrity rather than confidentiality.
High Integrity Level: Represents highly trustworthy and reliable data or users.
Low Integrity Level: Represents less trustworthy and less reliable data or users.
The primary goal is to prevent data from being contaminated by lower integrity levels.
3.2.2 SUBJECTS
In the Biba Model, subjects are active entities (users or processes) that have the
capability to interact with objects (data). Each subject operates at a specific integrity
level.
Integrity Level of Subjects: Subjects are assigned an integrity level that reflects
their trustworthiness and reliability in handling data.
Rules Governing Subjects: Subjects must adhere to the integrity policies to
ensure that data is not corrupted by less trustworthy entities.
3.2.3 OBJECTS
Objects are passive entities (files, databases, records, etc.) that store data. Each object
is assigned an integrity level based on the trustworthiness and reliability of the data it
contains.
Integrity Level of Objects: Objects are assigned an integrity level that reflects
the trustworthiness of the data they hold.
Rules Governing Objects: Objects are protected to ensure that their integrity
level is not compromised by interactions with lower-level subjects.
3.3 CORE PROPERTIES OF THE BIBA MODEL
The Biba Model is an information security model designed to maintain data integrity. It
establishes properties and rules to prevent unauthorized or less trustworthy sources
from corrupting data. Here are the key properties and rules of the Biba Model:
3.3.1 SIMPLE INTEGRITY PROPERTY: NO READ DOWN
Definition: A subject at a higher integrity level is not allowed to write to
an object at a lower integrity level.
Purpose: This rule prevents more trustworthy subjects from
contaminating less trustworthy data.
Example: A senior financial auditor (high integrity) cannot write or modify
the raw transaction records (low integrity).
3.3.2 STAR (*) INTEGRITY PROPERTY: NO WRITE UP
Definition: A subject at a lower integrity level is not allowed to read an
object at a higher integrity level.
Purpose: This rule ensures that less trustworthy subjects cannot read or
access more trustworthy data, preventing potential corruption of high-
integrity information.
Example: A data entry clerk (low integrity) cannot read the audited
financial statements (high integrity).
3.3.3 INVOCATION PROPERTY: NO INVOCATION FROM LOWER LEVELS
Definition: A subject cannot invoke (request services or actions) from a
subject at a higher integrity level.
Purpose: This rule prevents less trustworthy subjects from indirectly
affecting the operations of more trustworthy subjects.
Example: A junior developer (low integrity) cannot invoke administrative
commands on a high-integrity production server.
3.4 REAL-WORLD APPLICATIONS
The Biba Model, designed to maintain data integrity by preventing unauthorized
modifications, finds significant real-world applications in securing file systems,
databases, and networks. In file systems, it ensures that only authorized users can
modify critical files, protecting against data corruption. In databases, the Biba Model
controls access to sensitive records, ensuring their accuracy and preventing
unauthorized changes. For networks, it safeguards the integrity of transmitted data,
ensuring that communications and transactions remain trustworthy and unaltered.
These applications are crucial in environments like healthcare, finance, government,
and corporate settings, where data integrity is paramount.
3.4.1 SECURE FILE SYSTEM
Implementing the Biba Model in a secure file system involves integrating its principles to
ensure data integrity. This approach is crucial for environments where the accuracy and
reliability of data are paramount. Below are some real-world applications and how the
Biba Model is applied within secure file systems.
1. Healthcare Information Systems
In healthcare, the integrity of patient records is critical. The Biba Model can be used to
ensure that sensitive medical data remains uncorrupted.
Application:
Electronic Health Records (EHR): Implement the Biba Model to control
access to patient data.
Example: Doctors (high integrity subjects) can write updates to patient
records (high integrity objects), but administrative staff (low integrity
subjects) can only read these records.
2. Financial Systems
Financial institutions must ensure the integrity of transaction records and financial
statements to prevent fraud and errors.
Application:
Transaction Management Systems: Use the Biba Model to control who
can modify financial records.
Example: Auditors (high integrity subjects) can access and finalize
financial reports (high integrity objects), while clerks (low integrity
subjects) can input transaction data without modifying finalized records.
3. Government and Defense
Government and defense sectors handle highly sensitive information that must remain
accurate and secure.
Application:
Classified Information Systems: Implement the Biba Model to maintain
the integrity of classified documents and communications.
Example: Senior analysts (high integrity subjects) can write reports (high
integrity objects), while support staff (low integrity subjects) can read these
reports but cannot modify them.
4. Corporate Data Management
Corporations need to ensure the integrity of critical business data, including intellectual
property, strategic plans, and financial data.
Application:
Document Management Systems: Use the Biba Model to protect the
integrity of corporate documents.
Example: Executives (high integrity subjects) can update strategic plans
(high integrity objects), while regular employees (low integrity subjects)
can view but not modify these plans.
5. Software Development Environments
In software development, maintaining the integrity of source code and related
documents is essential to prevent errors and security vulnerabilities.
Application:
Version Control Systems: Apply the Biba Model to control access to
source code repositories.
Example: Senior developers (high integrity subjects) can commit changes
to the main repository (high integrity objects), while junior developers (low
integrity subjects) can only commit to feature branches.
3.4.2 SECURE DATABASES
The Biba Model, designed to ensure data integrity by controlling access to prevent
unauthorized or less trustworthy sources from corrupting data, can be effectively applied
to secure databases. Here are some real-world applications:
1. Healthcare Databases
In healthcare, databases store critical patient information, medical records, and
treatment histories. Ensuring the integrity of this data is vital.
Application:
Electronic Health Records (EHR): Implement the Biba Model to control
access and modifications to patient data.
Example: Doctors (high integrity subjects) can update patient records
(high integrity objects), while administrative staff (low integrity subjects)
can only read these records, preventing unauthorized modifications.
2. Financial Databases
Financial institutions maintain databases with sensitive data, such as transaction
records, customer information, and financial statements. Integrity is crucial to prevent
fraud and errors.
Application:
Transaction Processing Systems: Use the Biba Model to manage who
can alter transaction data.
Example: Auditors (high integrity subjects) can finalize transactions (high
integrity objects), while clerks (low integrity subjects) can input transaction
data without modifying finalized records.
3. Government Databases
Government databases often contain sensitive and classified information that must
remain accurate and secure.
Application:
Classified Information Systems: Implement the Biba Model to maintain
the integrity of classified documents and communication records.
Example: Senior analysts (high integrity subjects) can write and update
classified documents (high integrity objects), while support staff (low
integrity subjects) can only read these documents but cannot modify them.
4. Corporate Databases
Corporations need to ensure the integrity of business-critical data, including intellectual
property, strategic plans, and financial data.
Application:
Document Management Systems: Use the Biba Model to protect the
integrity of corporate documents stored in databases.
Example: Executives (high integrity subjects) can update strategic plans
(high integrity objects), while regular employees (low integrity subjects)
can view but not modify these plans.
5. Educational Databases
Educational institutions manage databases containing sensitive student information,
grades, and academic records.
Application:
Student Information Systems: Implement the Biba Model to ensure the
integrity of student records.
Example: Academic staff (high integrity subjects) can update student
grades and records (high integrity objects), while students (low integrity
subjects) can only view their own records.
3.4.3 SECURE NETWORKS
The Biba Model, designed to ensure data integrity by controlling how information flows
and is accessed, can be effectively applied to secure networks. Here are some real-
world applications:
1. Corporate Networks
In corporate environments, maintaining the integrity of network communications and
data is crucial to protect against unauthorized modifications and ensure reliable
information flow.
Application:
Internal Communication Systems: Implement the Biba Model to
manage the integrity of internal emails, messages, and documents
exchanged within the corporate network.
Example: Executives (high integrity subjects) can send and modify
strategic directives (high integrity objects), while regular employees (low
integrity subjects) can receive and read these directives without altering
them.
2. Healthcare Networks
Healthcare networks require stringent data integrity controls to protect patient
information and ensure the accuracy of medical data exchanged across the network.
Application:
Health Information Exchanges (HIE): Implement the Biba Model to
control the integrity of data exchanged between hospitals, clinics, and
other healthcare providers.
Example: Doctors (high integrity subjects) can update and share patient
records (high integrity objects) across the network, while administrative
staff (low integrity subjects) can view but not alter these records.
3. Government Networks
Government networks handling sensitive and classified information must maintain high
levels of data integrity to protect national security and public interests.
Application:
Classified Communication Networks: Implement the Biba Model to
safeguard the integrity of classified information transmitted over
government networks.
Example: Intelligence officers (high integrity subjects) can transmit and
modify classified reports (high integrity objects), while support staff (low
integrity subjects) can only access these reports for operational needs.
4. Financial Networks
Financial institutions must ensure the integrity of transactions and communications to
prevent fraud and maintain trust in financial systems.
Application:
Interbank Transfer Systems: Implement the Biba Model to control the
integrity of transaction data exchanged between banks.
Example: Auditors (high integrity subjects) can approve and modify
transaction records (high integrity objects), while bank tellers (low integrity
subjects) can process transactions without altering the records.
5. Educational Networks
Educational institutions manage sensitive student and academic data across their
networks, requiring strict integrity controls to ensure accurate and trustworthy
information.
Application:
Academic Information Systems: Implement the Biba Model to protect
the integrity of student records and academic data transmitted within
educational networks.
Example: Faculty members (high integrity subjects) can update student
grades and records (high integrity objects), while students (low integrity
subjects) can only view their own records without making modifications.
4.0 Self-Assessment Exercise(s)
1. The biba model was developed by who and what year?
Answer:
Kenneth J. Biba in 1975
2. Whats the main interest of Biba Model?
Answer:
It addresses data integrity by controlling access to data based on integrity levels.
3. State the three (3) properties of Biba model and give an example under each.
Answer
Simple Integrity Property: no read down
Star (*) Integrity Property: no write up
Invocation Property: no invocation from lower levels
Simple Integrity Property: no read down
Example: A senior financial auditor (high integrity) cannot write or modify the raw
transaction records (low integrity).
Star (*) Integrity Property: no write up
Example: A data entry clerk (low integrity) cannot read the audited financial statements
(high integrity).
Invocation Property: no invocation from lower levels
Example: A junior developer (low integrity) cannot invoke administrative commands on
a high-integrity production server.
5.0 Conclusion
The Biba Model's integrity levels, subjects, and objects work together to maintain data
integrity within a system. By enforcing rules that prevent data corruption, the Biba Model
ensures that information remains reliable and trustworthy. Understanding these key
concepts is crucial for implementing robust data integrity policies in any information
system.
6.0 Summary
In this unit, I explored the basic concepts of Bida model and the key concepts
associated with Bida model. I also explored the core properties and real-world
applications of bida model. In the next unit, you wil be learning about the concepts of
Clark-Wilson Model.
7.0 References/Further Readings
Recommended Resources:
Books:
o "Computer Security: Art and Science" by Matt Bishop
o "Security in Computing" by Charles P. Pfleeger and Shari Lawrence Pfleeger
Research Papers:
o "A Model of Data Integrity for Secure Systems" by Kenneth J. Biba
o "Foundations of Data Security" by Matt Bishop
Online Resources:
o Course materials and lecture slides (provided online)
o Additional reading links to IEEE and ACM digital libraries
Unit 3: Clark-Wilson model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Introduction to the Clark-Wilson Model and its history
3.2 Components of the Clark-Wilson Model
3.3 Core principles in the clark-wilson model
3.4 Practical Example
3.5 How the Clark-Wilson Model Works
3.6 Advantages of the Clark-Wilson Model
3.7 Disadvantages of the Clark-Wilson Model
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit the history, components, core principles, advantages,
disadvantages and practical applications of the Clark-Wilson model. After studying this
unit, you will be equipped with the knowledge and skills for implementing the Clark-
Wilson model
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Core principles and concepts of the Clark-Wilson model
3.0 Main Content
3.1 INTRODUCTION TO THE CLARK-WILSON MODEL AND ITS HISTORY
The Clark-Wilson model is a security model designed to ensure data integrity in
commercial environments by enforcing well-formed transactions and separation of
duties. Developed by David D. Clark and David R. Wilson in 1987, this model is
particularly effective for systems that manage sensitive and critical data. The following
sections shows a detailed explanation of the key concepts and components of the
Clark-Wilson model:
3.2 COMPONENTS OF THE CLARK-WILSON MODEL
1. Constrained Data Items (CDIs): These are data items that must maintain
integrity. The model protects these items through well-formed transactions.
2. Unconstrained Data Items (UDIs): These data items do not require the same
level of integrity protection as CDIs.
3. Integrity Verification Procedures (IVPs): These procedures verify that CDIs
are in a valid state.
4. Transformation Procedures (TPs): These are well-formed transactions that
change the state of CDIs. They must be certified to ensure they maintain
integrity.
5. Authentication and Audit: The model requires authentication of all users and
logging of all modifications to ensure accountability and detect potential security
breaches
6. Certification Rules (CRs): These rules ensure that IVPs and TPs maintain the
integrity of CDIs. There are specific certification rules:
CR1: All TPs must be certified to ensure they transform the system
from one valid state to another.
CR2: For all TPs, the security officer must maintain a list of authorized
users and the TPs they are allowed to execute.
7. Enforcement Rules (ERs): These rules enforce the execution of TPs and
ensure that users only perform authorized actions.
ER1: The system must ensure that only authorized users can execute
TPs.
ER2: The system must ensure that users can only access CDIs through
TPs.
3.3 CORE PRINCIPLES IN THE CLARK-WILSON MODEL
1. Role Division: The model mandates that critical tasks be divided into distinct
steps, with each step assigned to different roles. This ensures that no single
individual has complete control over the entire process, reducing the risk of
unauthorized modifications.
2. Well-formed Transactions: The concept of well-formed transactions requires
that data manipulations be performed in a manner that preserves integrity. By
enforcing SoD, the model ensures that these transactions are conducted by
multiple individuals, thereby reducing the chances of fraudulent or erroneous
data manipulation.
3. Enforcement through Certification and Enforcement Rules: These define the
constraints and procedures necessary to maintain data integrity. They specify
which roles can execute specific operations. Enforcement Rules (E-rules) also
enforces the separation of duties by ensuring that the system adheres to the
certification rules, typically through access control mechanisms.
4. Prevention of Conflicts of Interest: By separating duties, the Clark-Wilson
Model helps prevent conflicts of interest. For example, in financial systems,
separating the roles of transaction approval and transaction execution ensures
that no single individual can both authorize and execute a payment, thus
mitigating the risk of embezzlement.
5. Monitoring and Auditing: The model supports continuous monitoring and
auditing of transactions and roles. This oversight ensures that the SoD principle
is maintained and that any deviations or attempts to circumvent the controls are
detected and addressed promptly.
6. Separation of Duties: This principle ensures that no single individual has control
over all critical aspects of a transaction. It requires different users to perform
different roles in a process to prevent fraud and errors.
3.4 PRACTICAL EXAMPLE
Consider a payroll system:
Role 1: Employee A can input payroll data (e.g., hours worked, pay rate).
Role 2: Employee B can approve the payroll data entered by Employee A.
Role 3: Employee C can process the payroll after it has been approved by
Employee B.
In this scenario, no single employee has the ability to both input and approve payroll
data or to process payroll without it being approved. This separation of duties ensures
that payroll data integrity is maintained and reduces the risk of fraud.
3.5 HOW THE CLARK-WILSON MODEL WORKS
1. User Role Assignment: Users are assigned specific roles that determine which
TPs they can execute. This ensures that users cannot perform unauthorized
actions.
2. Certification of Procedures: All TPs must be certified by security officers to
ensure they maintain system integrity. This certification process includes
ensuring that TPs can only be executed in a way that preserves the integrity of
CDIs.
3. Logging and Auditing: The model requires logging of all TP executions to
create an audit trail. This helps in detecting and responding to any security
breaches.
3.6 ADVANTAGES OF THE CLARK-WILSON MODEL
1. Enhanced Security: By enforcing well-formed transactions and separation of
duties, the model significantly reduces the risk of data corruption and fraud.
2. Flexibility: The model can be adapted to different types of commercial systems
and is particularly effective in environments where data integrity is critical.
3. Auditability: The requirement for logging and auditing all transactions provides a
clear audit trail, making it easier to detect and respond to security incidents.
3.7 DISADVANTAGES OF THE CLARK-WILSON MODEL
1. Complexity: Implementing the Clark-Wilson model can be complex, especially in
large systems with many users and data items.
2. Performance Overhead: The need for certification, logging, and auditing can
introduce performance overheads.
3. Dependency on Human Factors: The effectiveness of the model relies heavily
on proper certification of procedures and diligent monitoring by security officers.
4.0 Self-Assessment Exercise(s)
1. What is the main purpose of designing the clark-wilson model?
Answer:
The Clark-Wilson model is a security model designed to ensure data integrity.
2. The clark-wilson model was developed in what year?
Answer:
Developed by David D. Clark and David R. Wilson in 1987
3. What are Constrained Data items (CDI)?
Answer:
These are data items that must maintain integrity. The model protects these items
through well-formed transactions.
4. Which data items do not require the same level of integrity protection as CDIs?
Answer:
Unconstrained Data Items (UDIs)
5. What is separation of duty in clark-wilson model?
Answer:
This principle ensures that no single individual has control over all critical aspects of a
transaction. It requires different users to perform different roles in a process to prevent
fraud and errors.
5.0 Conclusion
The Clark-Wilson Model is a fundamental principle designed to maintain data integrity
by dividing tasks among multiple roles. This prevents any single user from having
unchecked control over critical processes, thereby mitigating risks associated with fraud
and errors. The model's structured approach to enforcing SoD through certification and
enforcement rules, along with monitoring and auditing, ensures robust data integrity in
commercial environments.
6.0 Summary
In this unit, I explored the basic concepts of Clark-Wilson Model and the key concepts
associated with Clark-Wilson Model. I also explored the core properties and real-world
applications of Clark-Wilson Model. In the next unit, you wil be learning about the
concepts of Brewer and Nash model.
7.0 References/Further Readings
Unit 4: Brewer and Nash Model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Introduction to the Brewer and Nash Model and its history
3.2 Key Concepts of the Brewer and Nash Model
3.3 Core principles in the Brewer and Nash Model
3.4 How the Brewer and Nash Model Works
3.5 Implementation Challenges
3.6 Example Scenario
3.7 Advantages of the Brewer and Nash Model
3.8 Disadvantages of the Brewer and Nash Model
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit the definition, key concepts of Brewer and Nash Model.
After studying the unit, you will be equipped with skills know what Brewer and Nash
Model is all about. You will also have the required background knowledge of the history,
advantages and disadvantages Brewer and Nash Model.
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Know what Brewer and Nash Model is.
Identify the importance and history Brewer and Nash Model.
3.0 Main Content
3.1 Introduction to the Brewer and Nash Model and its history
The Brewer and Nash model, also known as the Chinese Wall model, is a security
model designed to prevent conflicts of interest by enforcing access controls based on
the user's previous actions. It was developed by David Brewer and Michael Nash in
1989, specifically to address issues in the financial and consulting industries where
conflicts of interest are a significant concern.
3.2 Key Concepts of the Brewer and Nash Model
1. Conflict of Interest Classes (COIs): These are groups of datasets that are in
conflict with each other. For example, in a financial context, datasets belonging to
competing companies would be in the same conflict of interest class.
2. Company Datasets (CDs): These are specific datasets within each conflict of
interest class. Each dataset contains information about a particular company.
3. Access Restrictions: The model restricts access based on the user's previous
accesses. If a user has accessed a dataset in a particular conflict of interest
class, they are restricted from accessing other datasets in the same class.
3.3 Core Principles of the Brewer and Nash Model
1. No Information Flow Across Conflicts of Interest: The primary principle is that
there should be no flow of information that could lead to a conflict of interest. This
means that if a user has accessed information from one dataset within a conflict
of interest class, they cannot access information from another dataset in the
same class.
2. Dynamic Access Control: Unlike other models that use static access control
lists, the Brewer and Nash model dynamically adjusts access permissions based
on the user's activity. This dynamic nature ensures that access decisions are
made in real-time to prevent conflicts of interest.
3.4 How the Brewer and Nash Model Works
1. Initial Access: When a subject (user) first attempts to access a dataset (object),
the access is granted if there are no conflicts of interest based on their previous
activities.
2. Conflict Check: For any subsequent access requests, the system checks the
conflict of interest classes. If the subject has accessed a dataset in a particular
class, they are denied access to other datasets in the same class.
3. Audit and Monitoring: The system maintains a history of access attempts and
grants to ensure that no conflicts of interest arise. This audit trail helps in
reviewing and ensuring compliance with the security policies.
3.5 Implementation Challenges
Implementing the Brewer and Nash Model can be complex due to several factors:
1. Tracking Access History: The system must continuously track which objects
each user has accessed to enforce the access rules dynamically.
2. Defining COI Classes: Clearly defining and maintaining the COI classes is
essential but can be challenging, especially in large and dynamic environments
where business relationships and competitive landscapes frequently change.
3. Performance Overhead: Evaluating access control decisions in real-time based
on access history can introduce significant performance overhead, particularly in
large systems with numerous users and objects.
3.6 Example Scenario
Consider a financial consulting firm where consultants provide advice to multiple clients.
Clients A and B are competitors and belong to the same conflict of interest class.
1. Initial Access: A consultant accesses Client A’s dataset. Since this is the first
access, it is granted.
2. Subsequent Access: The same consultant then tries to access Client B’s
dataset. The system checks the conflict of interest class and denies access
because the consultant has already accessed Client A’s dataset.
3.7 Advantages of the Brewer and Nash Model
1. Prevents Conflicts of Interest: By dynamically controlling access based on
previous activities, the model effectively prevents conflicts of interest.
2. Real-time Access Control: The model’s dynamic nature allows for real-time
decisions on access, enhancing security and compliance.
3. Flexibility: It can be applied to various industries where conflicts of interest are a
concern, such as finance, law, and consulting.
3.8 Disadvantages of the Brewer and Nash Model
1. Complex Implementation: The dynamic nature of the model and the need to
maintain access history can make implementation complex.
2. Performance Overhead: Continuous monitoring and dynamic decision-making
can introduce performance overhead.
3. Limited Scope: The model is specifically designed to address conflicts of
interest and may not be suitable for other types of security concerns.
4.0 Self-Assessment Exercise(s)
1. What is the main purpose of designing the Brewer and Nash model?
Answer:
The Brewer and Nash model is a security model designed to prevent conflicts of interest by
enforcing access controls based on the user's previous actions.
2. The Brewer and Nash model, also known as ________
Answer:
the Chinese Wall model
2. The Brewer and Nash model was developed in what year?
Answer:
It was developed by David Brewer and Michael Nash in 1989
3. What are Conflict of Interest Classes (COIs)?
Answer:
These are groups of datasets that are in conflict with each other.
4. Which datasets are specific datasets within each conflict of interest class. Each dataset
contains information about a particular company.
Answer:
Company Datasets (CDs)
5.0 Conclusion
The Brewer and Nash model is an effective security model for environments where conflicts of
interest must be strictly managed. By dynamically controlling access based on a user’s access
history and the conflict of interest classes, it ensures that sensitive information is not accessed
inappropriately, thus maintaining the integrity and confidentiality of the data.
6.0 Summary
At the end of this unit, you have learnt the definition, the importance of and the history of
Brewer and nsh model. In the next unit, you will be introduced to the Graham-Denning
model.
7.0 References/Further Readings
Unit 5: Graham-Denning model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Introduction to the Graham-Denning model and its history
3.2 Key Concepts of the Graham-Denning model
3.3 Components of the Graham-Denning model
3.4 Operations of the Graham-Denning model
3.5 Security Policies
3.6 Example Scenario
3.7 Advantages of the Graham-Denning model
3.8 Disadvantages of the Graham-Denning model
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit fundamentals of the Graham-Denning model and its history,
key Concepts, components and operations. You will also be introduced to the security
polices, exampl scenerio, advantages and disadvantages of Graham-Denning model.
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Know the basic concepts of Graham-Denning model.
3.0 Main Content
3.1 Introduction to the Graham-Denning model and its history
The Graham-Denning model is a formal model for computer security that provides a
framework for defining and managing the rights and privileges of subjects (users) over
objects (resources) in a computer system. This model was introduced by Graham and
Denning in 1972 and is fundamental in understanding how to control access and
maintain security in a system.
3.2 Key Concepts of the Graham-Denning model
1. Subjects: Entities (usually users or processes) that can perform actions on
objects.
2. Objects: Resources (such as files, databases, or devices) on which actions can
be performed.
3. Rights: Permissions that subjects have over objects, such as read, write,
execute, or delete.
3.3 Components of the Graham-Denning Model
The model is based on an access control matrix that defines the rights each subject has
over each object. The rows of the matrix represent subjects, the columns represent
objects, and the cells contain the rights of the corresponding subject over the
corresponding object.
3.4 Operations of the Graham-Denning model Works
The Graham-Denning model defines a set of eight primitive operations that can be
performed to manage and control access rights:
1. Create Object (CO): This operation allows a subject to create a new object and
specifies the initial rights associated with that object.
2. Delete Object (DO): This operation allows a subject to delete an existing object
from the system, thus removing all associated rights.
3. Create Subject (CS): This operation allows a subject to create a new subject
with specified initial rights.
4. Delete Subject (DS): This operation allows a subject to delete an existing
subject from the system, thus removing all associated rights.
5. Read Access Right (r): This operation allows a subject to read the rights that
another subject has over an object.
6. Grant Access Right (g): This operation allows a subject to grant specific rights
to another subject over an object.
7. Delete Access Right (d): This operation allows a subject to delete specific rights
of another subject over an object.
8. Transfer Access Right (t): This operation allows a subject to transfer rights they
possess to another subject.
3.5 Security Policies
The Graham-Denning model supports the implementation of security policies by
providing a formal way to define and manage access rights. Policies can be defined to
specify who can perform the primitive operations and under what conditions.
3.6 Example Scenario
Consider a simple scenario with three subjects (S1, S2, and S3) and two objects (O1,
O2):
1. Initial State:
S1 has read (r) and write (w) rights over O1.
S2 has read (r) rights over O1.
S3 has no rights over O1 or O2.
S1 has the right to grant (g) rights over O1.
2. Grant Operation: S1 uses the grant operation to give S3 read (r) rights over O1.
The access control matrix is updated to reflect this change.
3. Transfer Operation: S2 uses the transfer operation to transfer their read (r)
rights over O1 to S3. The access control matrix is updated accordingly.
4. Delete Operation: S1 uses the delete operation to remove S3's read (r) rights
over O1. The access control matrix is updated to reflect this change.
3.7 Advantages of the Graham-Denning Model
1. Granular Control: Provides detailed and granular control over who can access
what resources and what operations they can perform.
2. Flexibility: Can be adapted to various types of systems and security
requirements.
3. Formal Framework: Offers a formalized approach to defining and managing
access rights, which is useful for both theoretical analysis and practical
implementation.
3.8 Disadvantages of the Graham-Denning Model
1. Complexity: Managing the access control matrix and the primitive operations
can become complex, especially in large systems with many subjects and
objects.
2. Scalability: The model may face scalability issues as the number of subjects and
objects increases, leading to a large and potentially unwieldy access control
matrix.
3. Performance Overhead: The need to continuously manage and update the
access control matrix can introduce performance overhead.
4.0 Self-Assessment Exercise(s)
1. What is the main purpose of designing the Graham-Denning model?
Answer:
A formal model for computer security that provides a framework for defining and
managing the rights and privileges of subjects (users) over objects (resources) in a
computer system.
2. The Graham-Denning model was developed in what year?
Answer:
This model was introduced by Graham and Denning in 1972
3. List five (5) operations of Graham-Denning model?
Answer:
Create Object, Delete object, create subject, delee subject, read access right, grant
access right, delete access right, transfer access right.
5.0 Conclusion
The Graham-Denning model is a foundational security model that provides a structured
approach to managing access rights in a computer system. By defining a set of primitive
operations and using an access control matrix, it offers a formal framework for ensuring
that access to resources is controlled and managed in a secure manner. This model is
particularly useful in environments where precise and granular control over access
rights is required.
6.0 Summary
At the end of this unit, you have learnt the fundamentals of the Graham-Denning model
and its history, key Concepts, components and operations. You have also been
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Graham-Denning model. In the next unit, you will learn the Harrison-Ruzzo-Ullman
(HRU) model.
7.0 References/Further Readings
Unit 6: Harrison-Ruzzo-Ullman (HRU) model
Contents
1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Content
3.1 Introduction to the Harrison-Ruzzo-Ullman (HRU) model and its history
3.2 Key Concepts of the Harrison-Ruzzo-Ullman (HRU) model
3.3 Primitive Operations of the Harrison-Ruzzo-Ullman (HRU) model
3.4 Security Policies
3.5 Decidability and Security
3.6 Example Scenario
3.7 Advantages of the Harrison-Ruzzo-Ullman (HRU) model
3.8 Disadvantages of the Harrison-Ruzzo-Ullman (HRU) model
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
6.0 Summary
7.0 References/Further Readings
1.0 Introduction
You will learn from this unit fundamentals of the Harrison-Ruzzo-Ullman (HRU) model
and its history, key Concepts, components and primitive operations. You will also be
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Graham-Denning model.
2.0 Intended Learning Outcomes (ILOs)
At the end of this unit you will be able to:
Learn the fundamentals of the Harrison-Ruzzo-Ullman (HRU) model and its
history.
3.0 Main Content
3.1 Introduction to the Harrison-Ruzzo-Ullman (HRU) model and its history
The Harrison-Ruzzo-Ullman (HRU) model, introduced by Michael A. Harrison, Walter L.
Ruzzo, and Jeffrey D. Ullman in 1976, is a foundational model in the field of computer
security. It extends the Graham-Denning model by providing a more detailed framework
for understanding and managing access rights in a computer system. The HRU model
is particularly noted for its ability to express changes to the access control matrix
through a set of operations and for addressing the security implications of such
changes.
3.2 Key Concepts of the Harrison-Ruzzo-Ullman (HRU) model
1. Subjects: Entities that can perform actions (typically users or processes).
2. Objects: Resources upon which actions can be performed (files, databases,
devices, etc.).
3. Access Rights: Permissions that subjects have over objects (read, write,
execute, etc.).
4. Access Control Matrix: A matrix that defines the rights each subject has over
each object, with subjects as rows, objects as columns, and rights in the cells.
3.3 Primitive Operations of the Harrison-Ruzzo-Ullman (HRU) model Works
The HRU model defines a set of primitive operations that can be performed on the
access control matrix to manage rights. These operations are:
1. Create Subject: Adds a new subject to the system.
2. Delete Subject: Removes a subject from the system.
3. Create Object: Adds a new object to the system.
4. Delete Object: Removes an object from the system.
5. Enter Right: Grants a specific right to a subject over an object.
6. Delete Right: Revokes a specific right from a subject over an object.
Example Operations
To illustrate the primitive operations, consider an access control matrix with subjects S1,
S2 and objects O1, O2.
1. Create Subject (S3): Adds a new subject S3.
Access Control Matrix: Add a new row for S3.
2. Delete Subject (S1): Removes subject S1.
Access Control Matrix: Remove the row corresponding to S1.
3. Create Object (O3): Adds a new object O3.
Access Control Matrix: Add a new column for O3.
4. Delete Object (O2): Removes object O2.
Access Control Matrix: Remove the column corresponding to O2.
5. Enter Right (S2, O1, read): Grants read right to S2 over O1.
Access Control Matrix: Add "read" to the cell at (S2, O1).
6. Delete Right (S2, O1, read): Revokes read right from S2 over O1.
Access Control Matrix: Remove "read" from the cell at (S2, O1).
3.4 Security Policies
The HRU model supports the enforcement of security policies by specifying the
conditions under which each primitive operation can be executed. These policies ensure
that only authorized subjects can make changes to the access control matrix.
3.5 Decidability and Security
One of the significant contributions of the HRU model is its analysis of the decidability of
the safety problem: determining whether a given subject can ever acquire a particular
right to an object. The HRU model shows that this problem is undecidable in the general
case, meaning there is no algorithm that can determine this for all possible system
configurations.
3.6 Example Scenario
Consider a system with two subjects (Alice and Bob) and two objects (File1 and File2).
The access control matrix may look like this initially:
File 1 File 2
Alice Read Write
Bob Read
1. Grant Operation: Alice grants Bob read access to File1.
Update: Enter "read" in the cell (Bob, File1).
Resulting Matrix:
File 1 File 2
Alice Read Write
Bob Read Read
2. Revoke Operation: Alice revokes Bob's read access to File2.
Update: Delete "read" from the cell (Bob, File2).
Resulting Matrix:
File 1 File 2
Alice Read Write
Bob Read
3.7 Advantages of the HRU Model
1. Expressiveness: The HRU model can represent a wide variety of access control
scenarios and policies.
2. Formal Framework: Provides a rigorous mathematical foundation for
understanding access control.
3. Extensibility: Can be extended to include additional operations and policies as
needed.
3.8 Disadvantages of the HRU Model
1. Undecidability: The undecidability of the safety problem in the general case can
complicate security analysis.
2. Complexity: Managing the access control matrix and ensuring consistency can
be complex, especially in large systems.
3. Performance Overhead: Frequent updates to the access control matrix can
introduce performance overhead.
4.0 Self-Assessment Exercise(s)
1. _______ is the permissions that subjects have over objects (read, write, execute,
etc.)
Answer:
Access right
2. Harrison-Ruzzo-Ullman (HRU) model was introduced in the year___________
Answer
1976
3. Harrison-Ruzzo-Ullman (HRU) model was developed to ______________
Answer:
Understand and manag access rights in a computer system
4. What is the main purpose of “create object” in Harrison-Ruzzo-Ullman (HRU) model?
Answer:
Adds a new object to the system.
5.0 Conclusion
The Harrison-Ruzzo-Ullman model is a comprehensive framework for managing and
analyzing access rights in a computer system. Its formal approach to defining and
manipulating access control matrices provides a powerful tool for enforcing security
policies, though it also introduces challenges related to complexity and decidability.
6.0 Summary
You have learnt the fundamentals of the Harrison-Ruzzo-Ullman (HRU) model and its
history, key Concepts, components and primitive operations. You have also been
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Harrison-Ruzzo-Ullman (HRU) model.
7.0 References/Further Readings
Module 2: Access Control Mechanisms
Module Introduction
Access control mechanisms are critical components of information security, ensuring
that only authorized users can access specific resources within a system. This module
introduces several key access control models, each with its unique approach to
managing permissions and ensuring the security of sensitive data. The module covers
five pivotal access control mechanisms: Access control list (ACL), Mandatory access
control (MAC), Role-based access control (RBAC), Context-based access control
(CBAC) Lattice-based access control (LBAC).
Unit 1: Access control list (ACL)
Unit 2: Mandatory access control (MAC)
Unit 3: Role-based access control (RBAC) resources
Unit 4: Context-based access control (CBAC)
Unit 5: Lattice-based access control (LBAC)
In each unit, I will explore a particular topic in detail and highlight self-assessment
exercises at the end of the unit. Finally, I highlight for further reading at the end of each
unit.
Unit 1: Access control list (ACL)
Mandatory Access Control (MAC) is a security approach that restricts access to certain
assets and resources based on varying authorization levels. It is a centralized access
control system that regulates access to resources based on the clearance levels of
users and the attributes of objects they seek to access. MAC is known for its high
security levels and is often used in government, military, and financial institutions to
protect sensitive data and limit the risk of cyberattacks.
Key characteristics of MAC include:
1. Centralized Control: The access control policies are defined and enforced
centrally by the system administrator, rather than by individual users or resource
owners.
2. Security Labels: Each user and resource is assigned a security label that
defines their security clearance (for users) or classification (for resources). These
labels determine access rights.
3. Policy Enforcement: The system uses predefined policies to enforce access
control decisions, ensuring that users can only access resources for which they
have appropriate clearance.
4. Non-Discretionary: Unlike Discretionary Access Control (DAC), where resource
owners can set access permissions, MAC policies are not subject to user
discretion and cannot be modified by end users.
5. Granularity: MAC policies can be very granular, allowing for detailed control
over who can access what resources under what conditions.
Examples of MAC implementations include:
Security-Enhanced Linux (SELinux): A Linux kernel security module that
provides a mechanism for supporting access control security policies, including
MAC.
Multilevel Security (MLS): A system that uses MAC to enforce access controls
based on different security levels, often used in military and government
contexts.
Bell-LaPadula Model: A formal security model used to enforce access control in
government and military applications, focusing on data confidentiality.
What are the basic principles of MAC?
1. The utmost privacy and confidentiality of the organization’s resources are
paramount. No one has default privileges to access or edit someone’s data.
2. Access provisioning is centrally administered.
3. Each individual and resource in the system has security labels with their
classification and category.
How MAC works.
The administrator configures access policies and defines security attributes:
confidentiality levels and clearances for accessing different projects and types
of resources.
The administrator assigns a set of attributes to each subject (user or resource
that accesses data) and object (file, database, port, etc.).
When a subject attempts to access an object, the operating system examines
the subject’s security attributes and decides whether access can be granted.
To obtain access to the object, the user provides their credentials.
When to use MAC
Manatory Access control model is known for its high security levels and is often used in
government, military, and financial institutions to protect sensitive data and limit the risk
of cyberattacks. It’s mostly used by government organizations, militaries, and law
enforcement institutions. Here are some scenarios and contexts where using MAC is
advisable:
1. High-Security Environments: MAC is suitable for high-security environments
where data confidentiality and integrity are critical. Examples include government
agencies, military organizations, and financial institutions.
2. Sensitive Data Protection: MAC is effective in protecting sensitive data such as
classified information, financial records, and patient records.
3. Industrial Control Systems: MAC is used in industrial control systems to
protect against cyber threats and ensure the security of critical infrastructure.
4. Shared Servers or Workstations: MAC is useful in shared computing
environments where multiple users access the same resources. It prevents one
user from interfering with or accessing the data of another user.
5. Centralized Management: MAC is suitable for environments where centralized
management is necessary. It allows administrators to manage access control
policies uniformly across the organization.
6. High-Risk Industries: MAC is used in high-risk industries such as healthcare,
finance, and government to protect sensitive data and ensure compliance with
regulatory requirements.
7. Multilevel Security Systems: MAC is used in multilevel security systems where
different users have different clearance levels and access to different resources.
Use Cases
1. Government and Military: MAC is widely used in government and military
environments to control access to classified or sensitive information.
2. Financial Data: At banks, MAC is used to deal with highly sensitive customer
and financial records.
3. Healthcare: In healthcare, MAC is utilized to control access to electronic health
records (EHRs) and ensure patient privacy.
4. Industrial Control Systems: Critical industrial systems, like power plants, water
treatment facilities, and transportation systems, leverage MAC to protect against
cyber threats.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Mandatory Access Control (MAC) is a robust security approach that restricts access to
certain assets and resources based on varying authorization levels. It is a centralized
access control system that regulates access to resources based on the clearance
levels of users and the attributes of objects they seek to access. MAC is suitable for
high-security environments, sensitive data protection, industrial control systems,
shared servers or workstations, centralized management, high-risk industries, and
multilevel security systems. However, it is not suitable for small business settings,
consumer applications, low-security environments, and discretionary access control.
6.0 Summary
You have learnt the fundamentals of the Harrison-Ruzzo-Ullman (HRU) model and its
history, key Concepts, components and primitive operations. You have also been
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Harrison-Ruzzo-Ullman (HRU) model.
7.0 References/Further Readings
Alexander Babko https://www.ekransystem.com/en/blog/mac-vs-dac#id-when-to-use-
mac
Unit 3: Role-based access control (RBAC)
A Role Based Access Control (RBAC) is, as the name implies, an access control
method based on roles. Contrary to Mandatory Access Control (MAC) or Discretionary
Access Control (DAC), where the permissions are directly given to users (respectively
by the administrator or the data’s owner), the user is given one or more roles, and each
role allows for different permissions.
Role-based access control terms and concepts.
Role-Based Access Control (RBAC) involves several key terms and concepts that are
essential for understanding and implementing this access control model. Here are the
main terms and concepts:
1. Role: A collection of permissions that are grouped together based on job
functions or responsibilities within an organization. Example: Administrator,
Manager, Employee.
2. User: An individual who requires access to a system or resources. Users are
assigned roles that define their permissions. Example: Alice, Bob.
3. Permission: The authorization to perform a specific operation on a resource.
Permissions are assigned to roles, not directly to users. Example: Read patient
records, Write customer data.
4. Session: A mapping between a user and an activated subset of roles that the
user can assume during a login session. Example: Alice logs in and activates her
"Manager" role for the session.
5. Role Assignment: The process of assigning one or more roles to a user. Users
inherit the permissions associated with their assigned roles. Example: Assigning
the "Doctor" role to Bob.
6. Role Hierarchy: A hierarchical structure where roles can inherit permissions
from other roles. Higher-level roles include the permissions of their subordinate
roles. Example: The "Manager" role inherits permissions from the "Employee"
role.
7. Separation of Duties (SoD): A security principle that ensures no single
individual has control over all critical aspects of a task. This prevents conflicts of
interest and fraud. Example: A user cannot be assigned both the "Approver" and
"Requestor" roles to avoid conflicts.
8. Constraint: Conditions or rules that restrict role assignments or role activations
to enforce security policies. Example: A user cannot activate the "Auditor" role
while also activating the "Finance Manager" role.
9. Role Engineering: The process of defining and designing roles and permissions
based on organizational needs and job functions. Example: Creating a new
"Project Manager" role with specific permissions.
10. Least Privilege: A security principle that ensures users are granted the minimum
permissions necessary to perform their job functions. Example: An intern is given
read-only access to certain documents rather than full access.
11. Static Separation of Duties (SSoD): Constraints that prevent conflicting roles
from being assigned to the same user at any time. Example: Preventing a user
from being assigned both "Cashier" and "Accountant" roles.
12. Dynamic Separation of Duties (DSoD): Constraints that prevent conflicting
roles from being activated simultaneously by the same user. Example: A user
with both "Developer" and "Tester" roles can only activate one role at a time in a
session.
13. Access Control List (ACL): A list of permissions attached to an object
specifying which roles or users are allowed to access the object and what
operations they can perform. Example: An ACL for a file might specify that the
"Admin" role has read/write access, while the "User" role has read-only access.
14. Attribute-Based Access Control (ABAC): An extension or alternative to RBAC
where access decisions are based on attributes (such as user attributes,
resource attributes, and environmental conditions) rather than predefined roles.
Example: Allowing access to a document only if the user's department attribute
matches the document's department attribute.
Understanding these terms and concepts is crucial for effectively implementing and
managing RBAC within an organization. They provide the foundation for creating a
robust and scalable access control system that aligns with organizational policies and
security requirements.
Implementing RBAC in operating systems and Configuration and rule-setting.
Implementing Role-Based Access Control (RBAC) in operating systems and
applications involves several steps:
1. Define Roles and Permissions:
Identify the different roles within your organization and define the
permissions associated with each role.
Determine the resources and actions that each role should have access
to.
2. Create Groups and Assign Roles:
Create groups that represent each role and assign the corresponding
permissions to those groups.
Ensure that each user is assigned to the appropriate group based on their
role.
3. Configure Access Control Policies:
Configure the access control policies to enforce the roles and permissions
defined.
Ensure that the policies are applied consistently across the organization.
4. Test and Monitor the RBAC Model:
Test the RBAC model to ensure that it is functioning correctly and that
users have the appropriate access to resources.
Monitor the RBAC model to identify any issues or potential security risks.
5. Review and Update the RBAC Model:
Regularly review and update the RBAC model to ensure that it remains
effective and aligned with the organization's changing needs.
Best Practices for Implementing RBAC
1. Use a Centralized Management System:
Use a centralized management system to manage roles, permissions, and
access control policies.
This helps to ensure consistency and reduces administrative overhead.
2. Use a Hierarchical Role Structure:
Use a hierarchical role structure to simplify role management and reduce
the number of roles.
This helps to ensure that users have the appropriate access to resources
based on their role.
3. Use Role Inheritance:
Use role inheritance to simplify role management and reduce the number
of roles.
This helps to ensure that users have the appropriate access to resources
based on their role.
4. Use Role Activation and Expiration:
Use role activation and expiration to manage the lifecycle of roles and
ensure that users have the appropriate access to resources.
This helps to ensure that users do not have access to resources that they
are no longer authorized to access.
5. Use Auditing and Logging:
Use auditing and logging to track access to resources and identify
potential security risks.
This helps to ensure that security incidents are detected and responded to
promptly.
Tools and Technologies for Implementing RBAC
1. Active Directory:
Use Active Directory to manage roles, permissions, and access control
policies.
Active Directory provides a centralized management system for managing
roles and permissions.
2. RBAC Tools:
Use RBAC tools such as Auth0, Okta, or OneLogin to manage roles,
permissions, and access control policies.
These tools provide a centralized management system for managing roles
and permissions.
3. Scripting and Automation:
Use scripting and automation to simplify role management and reduce
administrative overhead.
This helps to ensure that roles are managed consistently and efficiently.
4. Security Information and Event Management (SIEM) Systems:
Use SIEM systems to monitor and analyze security-related data and
identify potential security risks.
SIEM systems provide real-time monitoring and analysis of security-
related data.
5. Compliance and Regulatory Requirements:
Ensure that the RBAC model complies with relevant compliance and
regulatory requirements.
This helps to ensure that the RBAC model is effective and aligned with the
organization's changing needs.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Implementing Role-Based Access Control (RBAC) in operating systems and
applications involves several steps and best practices. By following these steps and
best practices, organizations can ensure that their RBAC model is effective and
aligned with their changing needs.
6.0 Summary
You have learnt the fundamentals of the Harrison-Ruzzo-Ullman (HRU) model and its
history, key Concepts, components and primitive operations. You have also been
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Harrison-Ruzzo-Ullman (HRU) model.
7.0 References/Further Readings
GATIEN DUCORNAUD (2023). Role Based Access Control (RBAC) in the context of Smart Grids
Implementing and Evaluating a Role Based Access Control System for Configuration Loading in a
Substation from a Desktop. Stockholm, Sweden,
Unit 4: Context-based access control (CBAC)
Context-Based Access Control (CBAC) is a sophisticated access control model that
makes dynamic access decisions based on the context in which a request is made.
Unlike traditional models that rely on static roles or permissions, CBAC evaluates
various contextual factors such as time, location, device type, user activity, and other
environmental attributes to grant or deny access.
Key Concepts in CBAC
1. Context: Context refers to the circumstances or conditions in which access
requests occur. It encompasses various attributes, including:
o Time: The specific time or time range when access is requested.
o Location: The physical or logical location from where the access request
originates.
o Device: The type or identity of the device used to make the request.
o User Activity: The actions or behaviors of the user prior to the access
request.
o Environmental Factors: Any other conditions or states of the system or
environment, such as network security status or the presence of an active
threat.
2. Contextual Attributes: Attributes are the specific data points used to define the
context. These can be classified as:
o Intrinsic Attributes: Characteristics inherent to the user or device, such
as user roles, device ID, or user identity.
o Extrinsic Attributes: External conditions and environmental factors, such
as time of day, geolocation, or network status.
3. Policy Definition: Policies in CBAC are rules that define how different contextual
attributes influence access decisions. These policies are typically dynamic and
can adapt to changing conditions.
4. Decision Engine: The component that evaluates access requests against
contextual policies. It dynamically assesses whether to grant or deny access
based on real-time contextual data.
5. Logging and Auditing:
CBAC maintains detailed logs of access attempts and enforcement
actions for audit and compliance purposes.
Logging capabilities provide visibility into network traffic patterns, user
activities, and security incidents, facilitating effective monitoring and
forensic analysis.
Benefits of CBAC
1. Dynamic Decision-Making: Unlike static models, CBAC can adapt to changing
conditions, making it more flexible and responsive to emerging threats and
varying operational environments.
2. Enhanced Security: By considering a broader set of attributes, CBAC can more
accurately determine the legitimacy of access requests, thereby reducing the risk
of unauthorized access.
3. Fine-Grained Control: CBAC provides granular control over access
permissions, allowing for more precise and context-aware enforcement of
security policies.
4. Risk Management: CBAC can integrate risk assessment into access decisions,
adjusting permissions based on the perceived risk level of the context.
Implementing CBAC
1. Identify Contextual Factors: Determine which contextual attributes are relevant
to your organization's security needs. Common factors include time, location,
device type, and user activity.
2. Define Contextual Policies: Create policies that specify how access decisions
should be made based on the identified contextual factors. Use a policy language
or framework that supports dynamic conditions, such as XACML (eXtensible
Access Control Markup Language).
3. Collect Contextual Data: Implement mechanisms to collect and aggregate
contextual data in real-time. This may involve integrating with existing systems,
such as identity management systems, location services, and security
information and event management (SIEM) systems.
4. Develop a Decision Engine: Build or integrate a decision engine capable of
evaluating access requests against the defined policies. Ensure it can process
real-time contextual data and make quick decisions.
5. Implement and Test: Deploy the CBAC system in a controlled environment to
test its functionality and effectiveness. Monitor its performance and make
necessary adjustments to policies and data collection mechanisms.
How CBAC Works
CBAC operates by monitoring network traffic and evaluating the contextual information
associated with each access request. When a user or application attempts to access a
resource, CBAC's policy engine analyzes the relevant contextual factors and compares
them against the predefined access control policies.Based on this analysis, CBAC
makes a dynamic decision to either grant or deny access. If access is granted, CBAC
may also apply additional security measures, such as enforcing stronger authentication
requirements or limiting the user's privileges.CBAC's dynamic enforcement capabilities
allow it to adapt to changing security conditions in real-time. For example, if CBAC
detects suspicious activity or a potential security threat, it can automatically adjust
access control policies to mitigate the risk, such as by blocking access from certain
locations or devices.
CBAC in Practice
Use Case 1: Healthcare
Scenario: A hospital wants to control access to patient records based on the
context of the request.
Contextual Factors:
o Time: Access allowed only during working hours.
o Location: Access allowed only within the hospital premises.
o Device: Access allowed only from hospital-approved devices.
Policy: A doctor can access patient records only during working hours, from
within the hospital, and using a hospital-issued device.
Use Case 2: Corporate Environment
Scenario: A company wants to secure access to its internal network and
sensitive documents.
Contextual Factors:
o User Role: Different roles have different levels of access.
o Location: Remote access requires multi-factor authentication (MFA).
o Device Security: Access allowed only from devices with updated security
patches.
Policy: Employees can access sensitive documents remotely only if they
authenticate via MFA and use a device that meets security standards.
Challenges in Implementing CBAC
1. Complexity: CBAC systems can become complex due to the large number of
contextual attributes and policies that need to be managed.
2. Real-Time Data Processing: Efficiently collecting and processing contextual
data in real-time requires robust infrastructure and can be challenging.
3. Policy Management: Defining and maintaining dynamic policies that accurately
reflect organizational needs and security requirements is a continuous process.
4. Privacy Concerns: Collecting contextual data, especially those related to
location and user behavior, may raise privacy issues. It is essential to balance
security needs with privacy considerations.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Context-Based Access Control (CBAC) represents a significant advancement in access
control mechanisms, offering dynamic, context-aware decision-making capabilities. By
considering a wide range of contextual factors, CBAC can provide more precise and
adaptive security controls, enhancing the overall security posture of organizations.
Implementing CBAC requires careful planning and robust infrastructure but offers
substantial benefits in terms of flexibility, security, and risk management. As technology
evolves, CBAC will continue to adapt and integrate with emerging trends, ensuring its
relevance in the ever-changing landscape of cybersecurity.
6.0 Summary
You have learnt the fundamentals of the Harrison-Ruzzo-Ullman (HRU) model and its
history, key Concepts, components and primitive operations. You have also been
introduced to the security polices, exampl scenerio, advantages and disadvantages of
Harrison-Ruzzo-Ullman (HRU) model.
7.0 References/Further Readings
Unit 5: Lattice-based access control (LBAC)
Lattice-Based Access Control (LBAC) is a sophisticated access control model that
structures permissions and access rights using a lattice framework, where security
labels are assigned to both users and resources. In this system, access decisions are
determined by comparing the security labels based on predefined dominance
relationships within the lattice. The primary goal of LBAC is to enforce strict information
flow policies, ensuring that data is only accessible to authorized users based on their
security clearance levels and the classification of the information. This model is
particularly effective in environments requiring stringent security measures, such as
government and military applications, by preventing unauthorized access and potential
information leaks.
Key Concepts in LBAC
1. Security Labels:
Security labels are assigned to both subjects (users) and objects (resources) to
indicate their security levels.
Labels typically include classifications such as "Confidential," "Secret," and "Top
Secret."
2. Lattice Structure:
A lattice is a mathematical structure that defines a partial ordering of security
labels.
Each label is a point in the lattice, and the structure determines the hierarchical
relationship among these labels.
3. Dominance Relation:
Dominance (≥) is a key concept where a label A dominates label B if and only if
the security level of A is higher than or equal to B.
Access decisions are made based on whether the subject's label dominates the
object's label.
4. Meet and Join Operations:
The "meet" (greatest lower bound) and "join" (least upper bound) operations are
used to combine security labels.
These operations help in determining the effective security level when multiple
labels are involved.
5. Security Classes:
Security classes are specific levels or categories within the lattice.
These classes help in organizing and categorizing both data and users based on
their sensitivity and clearance levels.
Benefits of CBAC
1. Enhanced Security:
o LBAC provides a robust security framework by enforcing strict access
controls based on predefined security labels and dominance relationships.
This ensures that only authorized users can access sensitive information,
significantly reducing the risk of unauthorized access and data breaches.
2. Granular Access Control:
o The use of a lattice structure allows for fine-grained access control
policies. Security labels can be defined at various levels of granularity,
enabling precise control over who can access what information.
3. Prevention of Information Leakage:
o By enforcing policies such as "no read up" and "no write down" (in the
Bell-LaPadula model) or "no write up" and "no read down" (in the Biba
model), LBAC ensures that information does not flow inappropriately,
preventing data leaks and maintaining data confidentiality and integrity.
4. Flexibility and Scalability:
o The lattice structure can be easily extended to accommodate new security
labels and classes, making LBAC adaptable to evolving security
requirements. This flexibility allows organizations to scale their access
control policies as their security needs grow.
Implementing CBAC
1. Define Security Requirements: Identify sensitive information and determine the
necessary levels of confidentiality, integrity, and availability.
2. Classify Data and Users: Categorize data based on sensitivity levels and classify
users based on their roles and required access levels.
3. Design the Lattice Structure: Create security labels and establish dominance
relationships among them to define access control policies.
4. Implement LBAC Policies: Configure the system with security labels and
enforcement mechanisms to apply the defined policies.
5. Manage and Monitor: Continuously manage and monitor the LBAC system to
ensure compliance and address any security issues that arise.
How LBAC Works
Lattice-Based Access Control (LBAC) works by assigning security labels to both users
and resources, which are structured within a mathematical lattice that defines their
hierarchical relationships. Access decisions are made based on the dominance relation,
where a user's security label must dominate the resource's label for access to be
granted. This structure ensures that information flows only in permissible ways,
preventing unauthorized access and information leakage. LBAC enforces strict policies
such as "no read up" and "no write down" for confidentiality (as in the Bell-LaPadula
model) and "no write up" and "no read down" for integrity (as in the Biba model),
ensuring robust and consistent access control.
LBAC in Practice
Use Case 1: Government and Military Systems
Scenario: A government agency handles classified information, with data categorized
into "Confidential," "Secret," and "Top Secret" levels.
Implementation:
1. Classification: All documents are labeled according to their sensitivity level.
Employees are assigned security clearances matching these levels.
2. Access Control: Using the Bell-LaPadula model, employees can only read
documents at or below their clearance level (no read up) and write documents at
or above their clearance level (no write down).
3. Example: An employee with a "Secret" clearance can access both "Confidential"
and "Secret" documents but cannot access "Top Secret" documents. They can
create documents labeled "Secret" or "Top Secret," but not "Confidential."
Benefits:
Prevents unauthorized access to sensitive information.
Ensures that data is handled according to its classification level, maintaining
confidentiality.
Use Case 2: Healthcare Systems
Scenario: A hospital's information system contains patient records that need to be
accessed by various healthcare professionals, each with different roles and access
needs.
Implementation:
1. Classification: Patient records are labeled with sensitivity levels such as
"General," "Sensitive," and "Highly Sensitive."
2. Access Control: Using the Biba model, healthcare professionals can only read
records at or below their integrity level (no read down) and write records at or
above their integrity level (no write up).
3. Example: A nurse can access "General" and "Sensitive" patient records but
cannot access "Highly Sensitive" records. A doctor with higher integrity clearance
can access all levels but can only modify records within their clearance level.
Benefits:
Maintains data integrity by ensuring that only authorized personnel can modify
patient records.
Protects patient privacy by restricting access to sensitive health information.
Challenges in Implementing LBAC
Complexity of Lattice Structure: Designing and maintaining the lattice
structure requires a deep understanding of security requirements and the
relationships between different security levels. Organizations must invest time
and resources in defining security labels, establishing dominance relationships,
and ensuring consistency across the system.
Scalability Issues: As the organization grows or security needs evolve, scaling
the LBAC system can become challenging. Adding new security labels or
modifying existing ones may disrupt established access control policies and
require careful planning to maintain integrity and security.
Integration with Existing Systems: Integrating LBAC into existing IT
infrastructure, especially legacy systems, can be complex and may require
custom development or middleware solutions. Ensuring seamless interaction
with other access control mechanisms and applications is crucial to avoid
operational disruptions.
Performance Overhead: Enforcing LBAC policies can introduce additional
computational overhead, especially in systems with large numbers of users and
resources.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Lattice-based access Control (LBAC) represents a sophisticated approach to
access control, leveraging mathematical structures to enforce stringent security
policies based on defined security labels and dominance relationships. By
organizing access rights into a hierarchical lattice framework, LBAC ensures that
sensitive information is protected from unauthorized access and maintains data
confidentiality and integrity. Despite its benefits, implementing LBAC poses
challenges such as complexity in design and scalability, integration with existing
systems, and the need for user training and policy management. However, with
careful planning, robust technical solutions, and ongoing monitoring, LBAC can
be effectively deployed to meet stringent security requirements in various high-
security environments, including government agencies, healthcare institutions,
and financial organizations, thereby safeguarding critical assets and mitigating
risks of unauthorized data breaches.
6.0 Summary
LBAC, or Lattice-Based Access Control, is a security model that uses a hierarchical
lattice structure to enforce access control policies based on security labels and
dominance relationships. It ensures that only authorized users can access sensitive
information, maintaining confidentiality and integrity. While effective for high-security
environments like government and healthcare, LBAC implementation requires careful
planning due to its complexity and integration challenges.
7.0 References/Further Readings
Module 3: Advanced Security Models
Module Introduction
In today's digital landscape, security is a critical concern for organizations and
individuals alike. The constant evolution of cyber threats necessitates the development
and implementation of sophisticated security models to protect sensitive information and
ensure the integrity of systems. This module, "Advanced Security Models," delves into
the theoretical foundations and practical applications of cutting-edge security
frameworks designed to address contemporary cybersecurity challenges.
Unit 1: Capability-based security
Unit 2: Multi-level security (MLS)
Unit 3: Non-interference (security)
In each unit, I will explore a particular topic in detail and highlight self-assessment
exercises at the end of the unit. Finally, I highlight resources for further reading at the
end of each unit.
Unit 1: Capability-based security
This model is a highly granular and dynamic method for managing access control in
computer systems. It revolves around associating access rights directly with objects via
capabilities. Each capability is a unique token that defines specific permissions for
interacting with an object
Key characteristics of Capability-based security include:
Capability: A capability can be thought of as a digital key. It is an unforgeable token or
reference that grants a subject (such as a user or a process) certain access rights to an
object. The capability encapsulates the specific set of actions (e.g., read, write, execute)
that can be performed on the object.
Object: In this context, an object is anything that requires protection. Examples include
files, directories, memory locations, devices, or network resources.
Subject: A subject is an active entity that performs actions on objects. Typically, this
includes users, processes, or applications.
Comparison with Traditional Access Control Models:
ACLs (Access Control Lists): In ACL-based systems, permissions are
associated with objects. Each object maintains a list specifying which users or
groups can access it and what operations they can perform. This model is widely
used but can become cumbersome to manage, especially in large and dynamic
environments.
Capabilities: Unlike ACLs, capabilities are tied to subjects. A capability explicitly
defines the access rights a subject has over an object. This approach enables
fine-grained control and flexibility, particularly useful in distributed and
decentralized systems.
Key Differences:
o Granularity: Capabilities allow for more precise specification of access
rights.
o Delegation: Capabilities can be easily transferred between subjects,
facilitating dynamic and temporary access.
o Revocation: Revoking capabilities can be more straightforward compared
to managing ACLs.
System Architecture and Design Considerations:
Capability Table: A core component of capability-based systems is the
capability table, which maps subjects to their respective capabilities. Each entry
in the table represents a capability that a subject possesses.
Capability Registers: Some systems utilize hardware support for capabilities,
storing them in dedicated capability registers. This approach enhances
performance and security by leveraging specialized hardware features.
Capability-Based Operating Systems: Several operating systems have been
designed around the capability-based security model. Notable examples include
EROS and CapROS.
o EROS (Extremely Reliable Operating System): EROS is designed to
provide high reliability and security using capability-based security. It
offers fine-grained access control and efficient management of
capabilities.
o CapROS: An evolution of EROS, CapROS improves scalability and
performance while maintaining the core principles of capability-based
security.
Case Studies of Capability-Based Systems:
EROS: This operating system uses capabilities extensively to manage access
control. It demonstrates how capabilities can provide both security and
performance benefits in a real-world system.
CapROS: Building on the success of EROS, CapROS introduces enhancements
that address scalability and efficiency, making it suitable for more extensive and
complex environments.
Key Features:
o Object-Capability Model: This model encapsulates both data and the
capabilities required to access and manipulate the data. It promotes
secure design by ensuring that objects can only be accessed through
authorized capabilities.
o Fine-Grained Access Control: Each capability defines a precise set of
permissions, allowing for tight control over resource access.
Implementation Challenges and Solutions:
Performance Overhead: Managing capabilities can introduce performance
overhead, particularly in systems with high interaction rates. Optimizing capability
storage and verification processes is essential.
Compatibility: Integrating capability-based security with existing systems and
applications can be challenging. Solutions often involve hybrid models or
middleware to bridge the gap.
User Management: Ensuring that users understand and correctly manage their
capabilities is crucial. User interfaces and tools must be designed to simplify
capability management.
Examples:
Operating Systems: Systems like EROS and CapROS showcase the practical
implementation of capabilities in managing system resources and enforcing
security policies.
Cloud Services: In cloud computing, capabilities can be used to manage access
to virtual machines, storage, and other resources. A cloud service provider might
grant capabilities to users for accessing specific virtual machines or data stores,
ensuring secure and controlled access.
Performance Considerations:
Efficiency: Efficient management of capabilities is essential to minimize
performance impact. Techniques like caching, optimized data structures, and
hardware support can improve performance.
Hardware Support: Leveraging hardware features such as capability registers
can enhance performance and security, providing fast and secure access control.
Examples:
Dropbox: In file-sharing services, capabilities enable fine-grained control over
who can access or modify files, adhering to the principle of least privilege.
Smart Home Devices: In smart homes, capabilities can ensure that only
authorized devices and users can control specific functions, enhancing security
and flexibility.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Capability-based security provides a robust, fine-grained approach to access
control, emphasizing the principles of least privilege and flexible delegation.
Understanding its mechanisms, benefits, and practical applications equips
students and professionals with the tools to design and implement secure
systems in various domains. Through examples from file-sharing services, smart
home devices, secure operating systems, and emerging fields like IoT and
blockchain, the relevance and importance of capability-based security become
evident in the modern digital landscape.
6.0 Summary
Capability-based security is a granular and dynamic access control model where
permissions are encapsulated in unforgeable tokens known as capabilities, which grant
specific rights to subjects for interacting with objects. Originating in the 1960s and
exemplified by systems like EROS and CapROS, this model contrasts with traditional
Access Control Lists (ACLs) by enabling fine-grained control, flexible delegation, and
efficient revocation of permissions. Its applications span secure operating systems,
distributed systems, microservices, and emerging fields like IoT and blockchain,
providing robust security through principles like least privilege. Despite challenges such
as performance overhead and complexity in revocation, its advantages in precise
access control and adaptability make it a vital approach for modern security needs.
7.0 References/Further Readings
Unit 2: Multi-level security (MLS)
MLS is a security framework designed to handle information at various classification
levels and ensure that users only access data for which they have the appropriate
clearance. It is crucial in environments where information sensitivity varies widely, such
as military and government systems.
Key characteristics of Multi-level security include:
Classification Levels: Information is classified into different levels based on
sensitivity, such as Top Secret, Secret, Confidential, and Unclassified. Each level
dictates the security requirements for accessing the information.
Clearance Levels: Users are assigned clearance levels that determine the
highest classification of information they can access. A user's clearance must
match or exceed the classification level of the information for access to be
granted.
Mandatory Access Control (MAC): In MLS, access decisions are based on
fixed policies rather than user discretion. MAC enforces access controls based
on predefined rules regarding data classification and user clearances.
Importance of MLS in Modern Security:
In today's interconnected world, organizations manage vast amounts of sensitive
data across various domains. MLS provides a robust framework for ensuring that
information is accessed appropriately based on sensitivity and user clearance.
The principles of MLS are increasingly relevant in the era of cyber threats, where
unauthorized access to sensitive data can lead to significant security breaches
and data leaks.
System Architecture and Design:
Security Labels and Clearances: Every piece of data and every user/process in
the system is assigned a security label or clearance level. The system enforces
access controls based on these labels.
Access Control Mechanisms: MLS systems use a combination of hardware
and software mechanisms to enforce access controls. This includes kernel-level
enforcement, secure boot processes, and hardware-assisted security features.
Trusted Computing Base (TCB): The TCB is the set of all hardware, software,
and firmware components critical to the security of an MLS system. The TCB
must be trusted to enforce MLS policies correctly.
Examples of MLS Implementation:
Military Systems: Classified networks in the military use MLS to manage
information ranging from Unclassified to Top Secret. Secure terminals and
encryption are used to ensure data is only accessible to appropriately cleared
personnel.
Government Agencies: Agencies like the CIA and NSA use MLS to handle
sensitive information, ensuring that employees access only the data they are
cleared to see.
Commercial Applications: Financial institutions use MLS to segregate data
based on sensitivity, ensuring that customer data is protected while allowing
necessary access for operations.
Challenges and Solutions
Covert Channels and Information Leakage:
Covert Channels: These are unintended communication paths that can be
exploited to transfer information in ways that violate security policies. For
example, manipulating system resources or timing to infer data.
Mitigation: To mitigate covert channels, MLS systems often employ techniques
like traffic padding, rate limiting, and rigorous monitoring of resource usage.
Balancing Security and Usability:
User Frustration: Strict MLS policies can lead to user frustration if access
controls are too restrictive, impacting productivity.
Solutions: Implementing role-based access controls (RBAC) within MLS
frameworks can help balance security and usability by providing users with the
access they need for their roles without compromising overall security.
Performance and Scalability Issues:
Performance Overhead: Enforcing MLS policies can introduce significant
performance overhead, especially in systems with high volumes of data and
frequent access requests.
Optimization: Using efficient algorithms and hardware support for security
operations can help mitigate performance impacts. Additionally, designing
systems to minimize the number of security checks for common operations can
improve scalability.
Examples:
Covert Channel Mitigation: In a secure communications system, timing
variations could be used to infer classified information. By normalizing response
times and adding random delays, the system can prevent covert timing channels.
Balancing Security and Usability: In a corporate environment, implementing
MLS with RBAC allows employees to access the information needed for their
tasks without excessive restrictions, enhancing both security and productivity.
Performance Optimization: Using specialized hardware, such as Trusted
Platform Modules (TPMs) and secure processors, can offload security tasks from
the main CPU, reducing performance overhead in MLS systems.
Case Studies:
MLS in Military and Government Systems:
Classified Networks: Military networks segregate data based on classification
levels, ensuring that only authorized personnel access sensitive information. For
instance, the SIPRNet (Secret Internet Protocol Router Network) handles
information up to Secret, while the JWICS (Joint Worldwide Intelligence
Communications System) is used for Top Secret information.
Intelligence Agencies: Agencies like the CIA and NSA rely on MLS to manage
classified information, ensuring that data is compartmentalized and only
accessible to cleared personnel.
Diplomatic Communications: Embassies and consulates use MLS to secure
communications, protecting sensitive diplomatic information from unauthorized
access.
MLS in Commercial Applications:
Financial Institutions: Banks and financial institutions use MLS to protect
sensitive customer information, such as account details and transaction records.
MLS ensures that employees access only the data necessary for their roles.
Healthcare Systems: Hospitals and healthcare providers use MLS to protect
patient records, ensuring that only authorized personnel can access medical
histories and treatment plans.
Corporate Environments: Large corporations use MLS to protect intellectual
property and confidential business information, segregating access based on
roles and responsibilities.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Multi-Level Security (MLS) provides a robust framework for managing access to
sensitive information based on classification and clearance levels. By enforcing
mandatory access control policies and employing models.
6.0 Summary
Multi-Level Security (MLS) is a framework designed to handle information at various
classification levels, ensuring users access only data for which they have appropriate
clearance. Implementing MLS involves assigning security labels and clearances,
employing mandatory access control mechanisms, and managing performance
overhead and usability. MLS is crucial in military, government, financial, and healthcare
systems to protect sensitive data, mitigate covert channels, and balance security with
usability. Emerging applications include IoT and cloud computing, where MLS principles
enhance data security and integrity.
7.0 References/Further Readings
Unit 3: Non-interference (security)
In the context of computer security, non-interference is a property of a system where
actions performed at a higher security level do not affect or interfere with what is
observable at a lower security level. This ensures that sensitive information does not
leak to unauthorized users through indirect means.
Key characteristics of Non-Inteference security include:
Security Levels: The system is divided into different security levels, with high
security levels handling sensitive information and low security levels managing
less sensitive or public information.
Observability: Non-interference is concerned with what can be observed by
users or processes at different security levels. It guarantees that high-level
actions do not create observable changes at lower levels.
.
Importance of Non-Interference in Modern Security:
In today's digital landscape, where information systems handle vast amounts of
sensitive data, ensuring non-interference is crucial to protect against
unauthorized access and data breaches.
Non-interference provides a robust framework for designing systems that
maintain strict separation between different security levels, preventing
unintentional information flow.
This concept is particularly relevant in high-assurance systems, such as military,
government, and financial applications, where maintaining the confidentiality and
integrity of sensitive information is paramount.
Mechanisms for Ensuring Non-Interference
Design Principles and Techniques:
Isolation: One of the primary techniques for ensuring non-interference is
isolating processes and data based on security levels. This prevents
unauthorized interactions and information flow.
Controlled Channels: Systems must manage and control communication
channels to ensure that high-level information does not leak through legitimate
channels. This includes data channels, signaling, and resource usage.
Auditing and Monitoring: Continuous monitoring and auditing of system
activities help detect and prevent potential violations of non-interference policies.
Logs and audits provide a record of actions that can be analyzed for security
breaches.
Implementation Strategies:
Labeling and Classification: Every piece of data and process in the system is
labeled with a security level. The system enforces non-interference by controlling
interactions based on these labels.
Policy Enforcement: Security policies are enforced through a combination of
hardware and software mechanisms. This includes access control mechanisms,
encryption, and secure communication protocols.
Secure Programming Languages: Using programming languages and
frameworks designed with non-interference principles can help developers write
code that inherently respects security policies. Examples include languages with
built-in support for information flow control.
Examples:
Operating Systems: Secure operating systems like SELinux and seL4 use
mandatory access control (MAC) and isolation techniques to enforce non-
interference. These systems label processes and data, controlling access based
on security policies.
Cloud Services: Cloud providers implement non-interference by isolating tenant
data and processes. Techniques like virtualization and containerization ensure
that actions in one tenant's environment do not affect others.
Financial Systems: In banking applications, non-interference ensures that high-
level operations, such as financial audits, do not impact the day-to-day activities
visible to regular employees.
Challenges and Solutions
Covert Channels and Information Leakage:
Covert Channels: These are unintended communication paths that can be
exploited to transfer information in ways that violate non-interference policies. For
example, manipulating system resources or timing to infer data.
Mitigation: Mitigating covert channels involves techniques like traffic padding,
rate limiting, and rigorous monitoring of resource usage. Systems must be
designed to minimize side channels that could be exploited for information
leakage.
Balancing Security and Usability:
User Experience: Strict non-interference policies can impact usability, making
systems cumbersome for users. Balancing security with usability is a critical
challenge.
Solutions: Implementing role-based access controls (RBAC) within non-
interference frameworks can help balance security and usability by providing
users with the access they need for their roles without compromising overall
security.
Case Studies:
Non-Interference in Military and Government Systems:
Classified Networks: Military networks use non-interference to manage
information ranging from Unclassified to Top Secret. Secure terminals and
encryption ensure data is only accessible to appropriately cleared personnel.
Intelligence Agencies: Agencies like the CIA and NSA rely on non-interference
to manage classified information, ensuring data is compartmentalized and only
accessible to cleared personnel.
Diplomatic Communications: Embassies and consulates use non-interference
to secure communications, protecting sensitive diplomatic information from
unauthorized access.
Non-Interference in Commercial Applications:
Financial Institutions: Banks and financial institutions use non-interference to
protect sensitive customer information, such as account details and transaction
records. Non-interference ensures employees access only the data necessary for
their roles.
Healthcare Systems: Hospitals and healthcare providers use non-interference
to protect patient records, ensuring only authorized personnel can access
medical histories and treatment plans.
Corporate Environments: Large corporations use non-interference to protect
intellectual property and confidential business information, segregating access
based on roles and responsibilities.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Non-interference is a critical security concept that ensures actions at higher security
levels do not affect or leak information to lower levels, providing a robust framework for
maintaining confidentiality and integrity. By employing formal models, isolation
techniques, controlled channels, and secure programming practices, systems can
effectively enforce non-interference policies. Despite challenges such as covert
channels, performance overhead, and usability trade-offs, non-interference remains
essential in high-assurance environments like military, government, financial, and
healthcare systems. Emerging applications in IoT, cloud computing, and AI further
highlight the relevance and importance of non-interference in modern security practices.
6.0 Summary
Non-interference is a fundamental security principle ensuring that actions performed at
higher security levels do not impact or reveal information accessible at lower levels.
Non-interference finds crucial applications in military, government, financial, and
healthcare sectors, where protecting sensitive data is paramount. Challenges include
mitigating covert channels, balancing security with usability, and managing performance
overhead. As technologies like IoT and cloud computing expand, applying non-
interference principles becomes increasingly essential in securing diverse digital
environments.
7.0 References/Further Readings
Module 4: Computer Security Models and
Mechanisms
Module Introduction
In today's interconnected digital world, ensuring the security of computer systems and
data is paramount. Computer security models and mechanisms provide the foundational
framework for protecting information from unauthorized access, modification, and
destruction. These models are designed to enforce access controls, maintain
confidentiality, ensure data integrity, and mitigate risks from cyber threats. By
understanding various security models and the mechanisms they employ, professionals
can effectively design, implement, and maintain secure systems across diverse
domains, from government and military operations to financial institutions, healthcare
systems, and beyond. This module explores key concepts such as capability-based
security, multi-level security (MLS), and non-interference, offering insights into their
theoretical foundations, practical applications, and real-world examples. Through this
exploration, learners will gain a comprehensive understanding of how these models
safeguard sensitive information and contribute to robust cybersecurity practices in the
modern digital landscape.
Unit 1: Object-capability model
Unit 2: Take-grant protection model
Unit 3: Protection ring
Unit 4: High-water mark (computer security)
In each unit, I will explore a particular topic in detail and highlight self-assessment
exercises at the end of the unit. Finally, I highlight for further reading at the end of each
unit.
Unit 1: Object-capability model
The Object-capability model (OCap) is a security paradigm in computing that focuses on
granting permissions (capabilities) to objects, allowing them to interact with other
objects or perform specific actions. Each capability encapsulates the authority to
perform a particular operation, ensuring fine-grained access control.
Key characteristics of the Object-capability model (OCap) include:
Principles: OCap emphasizes least authority, meaning each object or
component only possesses the capabilities necessary to perform its intended
function. This principle reduces the risk of unintended actions or privilege
escalation.
Granularity: Capabilities are specific and unforgeable tokens that represent a
secure way to grant and manage permissions within a system.
Examples: Systems like EROS (Extremely Reliable Operating System) and
CapROS (Capability-based Reliable Operating System) exemplify OCap
principles by using capabilities to control access to system resources. In web
browsers, JavaScript sandboxes use capabilities to limit scripts' access to
sensitive browser functions and data.
Capability-Based Security vs. Traditional Models:
Comparison: Unlike traditional access control models (e.g., DAC, MAC), which
rely on user identities or roles, capability-based security focuses on the direct
delegation of specific privileges to objects or processes.
Advantages: Provides strong isolation between components, reduces the attack
surface, and supports flexible delegation of authority without compromising
system security.
Management: Capabilities are created by trusted authorities, managed securely,
and can be revoked as needed to enforce access control policies dynamically.
Confinement and Delegation:
Confinement: Objects are confined within their capabilities, preventing
unauthorized access to resources beyond their designated permissions.
Delegation: Secure delegation allows objects to pass capabilities to other
objects, enabling controlled sharing of resources while maintaining security
boundaries.
Case Studies and Practical Applications:
Secure Web Programming and Browser Security:
Example: In web browsers, JavaScript sandboxes use capability-based security
to restrict scripts' access to browser features and sensitive user data. This
prevents malicious scripts from accessing or modifying sensitive information.
Microservices Architecture: OCap principles are applied in microservices
architectures, where each service is granted specific capabilities to interact with
other services or access shared resources. This enhances security by limiting the
impact of potential breaches.
IoT and Decentralized Systems:
Implementation: IoT devices often use capability-based security to manage
access to device functionalities and data. Each device is equipped with
capabilities that define its authorized actions, ensuring secure communication
and operation within IoT networks.
Blockchain: Smart contracts in blockchain platforms utilize capabilities to
enforce access control and define permissions for executing transactions or
accessing blockchain resources.
Challenges and Future Directions
Scalability and Performance Considerations:
Overhead: Managing numerous capabilities and their associated permissions
can introduce computational overhead and complexity.
Optimization: Ongoing research focuses on optimizing capability management
and enforcement mechanisms to minimize overhead and improve system
performance.
Integration with Existing Systems:
Legacy Systems: Integrating capability-based security into legacy systems can
be challenging due to differences in access control models and architectures.
Interoperability: Efforts are underway to develop standards and frameworks for
interoperability between capability-based systems and traditional security
models.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
The Object-Capability Model (OCap) represents a powerful paradigm in computer
security, emphasizing precise access control through capabilities granted to objects. By
adhering to principles like least authority and granular delegation, OCap enhances
system security by reducing the attack surface and preventing unauthorized access.
Practical applications span from web browsers and IoT devices to emerging
technologies like blockchain and AI, where capability-based security ensures secure
and efficient operation. While challenges such as scalability and integration persist,
ongoing research and development aim to optimize capability management and extend
its applicability across diverse computing environments.
6.0 Summary
The Object-Capability Model (OCap) is a security framework focused on granting
specific permissions (capabilities) to objects or components within a system. It ensures
robust access control by adhering to principles such as least authority and granular
delegation, where each object possesses only the capabilities necessary for its
designated tasks. Examples include its application in web browsers through JavaScript
sandboxes and in IoT devices for secure resource management. OCap differs from
traditional access control models by directly linking permissions to objects rather than
user identities, thereby reducing the risk of unauthorized access and privilege
escalation. Despite challenges in scalability and integration with legacy systems,
ongoing advancements aim to optimize capability management and expand its utility
across diverse computing environments.
7.0 References/Further Readings
Unit 2: Take-grant protection model
The Take-Grant Protection Model is a formal approach to access control in computer
security, designed to manage and enforce permissions between subjects (entities
capable of making requests) and objects (resources or entities being protected).
Key characteristics of the Take-grant protection model include:
Elements: It defines a set of rules governing how rights (capabilities) can be
transferred from one entity to another, based on predefined conditions and
constraints.
Formal Representation: Typically represented using graph theory, where nodes
represent entities (subjects or objects) and edges represent rights or
permissions.
Elements and Mechanisms
Subjects and Objects:
Subjects: Entities capable of initiating actions or requests within a system.
Objects: Resources or entities that are protected and subject to access control
policies.
Rights and Rules:
Rights: Permissions or capabilities that subjects can possess to access or
manipulate objects.
Rules: Govern the conditions under which rights can be granted, transferred, or
revoked between subjects and objects.
Implementation and Examples
Enforcing Access Control Policies:
Example: In network security, routers apply the Take-Grant model to control
packet forwarding based on access control lists (ACLs). ACLs specify which
subjects (network devices or users) are allowed to access specific objects
(network resources) based on predefined rules.
Comparison with Other Models: Contrasted with discretionary access control
(DAC) where access rights are based on the identity of the subject, the Take-
Grant model emphasizes the dynamic transfer of rights between subjects based
on explicit rules.
Advantages and Limitations
Flexibility in Defining Rights:
Advantages: Offers flexibility in defining fine-grained access control policies by
enabling dynamic delegation and revocation of rights.
Use Cases: Used in systems where privileges need to be managed dynamically
based on changing conditions or user roles.
Vulnerabilities and Misuse:
Potential Misuse: Improperly defined rules or unrestricted transfer of rights can
lead to privilege escalation attacks, where unauthorized subjects gain access to
sensitive resources.
Mitigation Strategies: Implementation of strict validation mechanisms and
regular auditing of access control policies to detect and prevent misuse.
Case Studies and Practical Applications:
Network Security Protocols:
Case Study: In the context of Secure Shell (SSH) protocols, the Take-Grant
model is used to authenticate and authorize remote access based on
cryptographic keys and access control rules.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
The Take-Grant Protection Model provides a structured approach to access control,
emphasizing the dynamic transfer of rights between subjects and objects based on
predefined rules. It offers flexibility in defining and managing fine-grained access control
policies, making it suitable for environments where privileges need to be managed
dynamically. However, proper implementation and validation are crucial to mitigate
vulnerabilities and ensure secure operation. Ongoing research aims to enhance the
model's applicability in emerging technologies such as cloud computing, IoT, and
blockchain, highlighting its enduring relevance in modern computer security practices.
6.0 Summary
The Take-Grant Protection Model is a formal approach to access control in computer
security, defining rules for the dynamic transfer of permissions (rights) between subjects
and objects within a system. It utilizes graph theory to represent entities (subjects and
objects) and their interactions, emphasizing the flexibility to define fine-grained access
policies based on predefined conditions. Examples include its application in network
security protocols like Secure Shell (SSH), where it manages remote access based on
cryptographic keys and access control lists (ACLs). While offering advantages in
dynamic privilege management, such as facilitating secure delegation and revocation of
rights, the model requires careful implementation to prevent vulnerabilities like privilege
escalation. Ongoing research explores its extensions to accommodate evolving
technologies such as cloud computing and blockchain, ensuring its relevance in
contemporary cybersecurity practices.
7.0 References/Further Readings
Unit 3: Protection ring
Protection rings originated in early operating systems as a mechanism to enforce
security and isolation between different levels of system software and user processes.
They define hierarchical levels of privilege or access rights, with higher-numbered rings
having more privileges than lower-numbered ones.
Also known as privilege levels, protection rings categorize CPU modes and levels of
access authority.
Typically, modern systems like x86 architecture feature four rings, with Ring 0 having
the highest privilege (kernel mode) and Ring 3 the lowest (user mode).
Mechanisms and Functionality
Ring Levels and Privilege Levels:
Ring 0 (Kernel Mode): The most privileged level where the operating system
kernel executes with unrestricted access to hardware and system resources.
Rings 1 and 2: Historically used for device drivers and privileged software.
Ring 3 (User Mode): Least privileged level where user applications and
processes execute with restricted access to hardware and system resources.
Inter-Ring Communication and Transitions:
Communication: Interactions between rings are regulated by hardware
mechanisms such as gates and traps, ensuring controlled transitions without
compromising system security.
Transitions: Moving between rings involves switching execution modes,
managed by the operating system through context-switching mechanisms.
Case Studies and Practical Applications:
Operating System Security Models:
Example: Modern operating systems like Linux and Windows use protection
rings to enforce isolation and security between kernel-level operations and user-
level applications.
Virtualization: Hypervisors implement protection rings to isolate guest operating
systems from the host system and each other, ensuring secure multi-tenant
environments in cloud computing.
Virtualization and Cloud Computing:
Implementation: Cloud service providers utilize protection rings to isolate and
secure virtual machine instances, preventing unauthorized access between
different tenant environments.
Security Assurance: Ensures that breaches in one virtualized environment do
not compromise the security of others, maintaining data confidentiality and
integrity.
Challenges and Innovations
Security Implications of Ring Transitions:
Risk Factors: Vulnerabilities like privilege escalation attacks can occur if
transitions between rings are not properly managed or validated.
Mitigation Strategies: Implementing robust validation mechanisms and access
control policies to prevent unauthorized transitions and maintain system integrity.
Meltdown and Spectre Vulnerabilities:
Examples: These critical vulnerabilities exploited speculative execution in CPUs
to bypass isolation between protection rings, potentially exposing sensitive data
across different security levels.
Response: Mitigation efforts included software patches, microcode updates, and
redesigning CPU architectures to strengthen isolation mechanisms and prevent
future exploits.
Applications in Embedded Systems and IoT Devices:
Adaptation: Implementing protection rings in embedded systems and IoT
devices to ensure secure operation and data integrity in resource-constrained
environments.
Use Cases: Preventing unauthorized access and tampering in critical
infrastructure and connected devices through secure isolation mechanisms.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
Protection rings play a pivotal role in modern computer security by enforcing
hierarchical privilege levels and ensuring secure isolation between different levels of
system software and user processes. Originating in early operating systems, protection
rings continue to evolve with advancements in hardware and software technologies,
adapting to meet the challenges of cybersecurity threats. While critical vulnerabilities
like Meltdown and Spectre underscore the importance of robust security measures,
ongoing innovations in hardware security and virtualization aim to strengthen protection
ring mechanisms and enhance overall system resilience. As technologies such as cloud
computing and IoT expand, protection rings remain indispensable in safeguarding data
confidentiality, integrity, and availability across diverse computing environments.
6.0 Summary
Protection rings are hierarchical privilege levels integral to computer security, originating
in early operating systems to enforce isolation between system software and user
processes. They categorize CPU modes into levels like Ring 0 (kernel mode with
highest privilege) and Ring 3 (user mode with least privilege), ensuring controlled
access to hardware and resources. Modern applications include their use in operating
systems like Linux and Windows for secure kernel-level operations and in virtualization
to isolate guest systems in cloud environments. Challenges such as vulnerability to
privilege escalation, exemplified by vulnerabilities like Meltdown and Spectre,
underscore the need for robust security measures and continuous innovation in
hardware and software. Future directions focus on enhancing protection ring
mechanisms against emerging threats and adapting them for use in embedded systems
and IoT devices to ensure secure operation in diverse computing environments.
7.0 References/Further Readings
Unit 4: High-water mark (computer security)
The High-water mark (HWM) model is a security policy primarily used to ensure data
integrity within computer systems. It is designed to track and control the flow of
information by marking the highest security level of data a subject has accessed.
The model prevents contamination of lower-level data by ensuring that once a subject
accesses high-level information, they cannot write to lower security levels, thereby
maintaining data integrity and preventing unauthorized dissemination of sensitive
information.
Key characteristics of the High-water mark (computer security) model include:
Data Integrity: Ensures that data remains accurate, consistent, and unaltered by
unauthorized entities.
Information Flow Control: Regulates how information can move between
different security levels, preventing data leakage and maintaining confidentiality.
Implementation in Security Models
Use Cases in Access Control Policies:
Example: In a classified military environment, a user with access to top-secret
information can only read documents at the top-secret level. If they create a new
document or modify existing data, the document inherits the top-secret
classification to prevent information leakage.
Application: The HWM model is often used in multilevel security (MLS) systems
where maintaining data integrity across various classification levels is crucial.
Examples in Audit Trails and Logging:
Audit Trails: Implementing the HWM model in audit trails ensures that once a
user accesses sensitive information, all subsequent activities are logged at the
highest accessed security level. This helps in tracking potential security breaches
and unauthorized information flow.
Logging: Secure logging systems employ the HWM model to categorize logs
based on the highest security level of data accessed during the logging session,
ensuring that sensitive information is protected.
Mitigation and Best Practices
Preventing Resource Exhaustion Attacks:
Resource Management: Implementing the HWM model helps in managing
system resources by ensuring that high-level access does not lead to
unauthorized consumption or exhaustion of lower-level resources.
Example: In cloud computing, if a tenant accesses high-security resources, the
system restricts their ability to downgrade or misuse lower-security resources,
maintaining overall system stability and security.
Adaptive Algorithms and Heuristics:
Dynamic Adaptation: Employing adaptive algorithms that adjust security
policies based on the highest accessed data level ensures that the system
dynamically responds to potential threats and unauthorized access attempts.
Heuristic Approaches: Using heuristics to analyze access patterns and enforce
HWM policies helps in proactively identifying and mitigating security risks.
Case Study: Network Traffic Analysis:
Implementation: In network security, the HWM model can be applied to analyze
network traffic. Once a user accesses high-security network segments, their
subsequent network activities are monitored and controlled at the same security
level to prevent data leaks and unauthorized access.
Example: In financial institutions, network traffic involving sensitive transactions
is tagged with the highest security level, ensuring that subsequent traffic adheres
to stringent security protocols.
Emerging Challenges and Research Areas
Scalability in Large-Scale Systems:
Challenges: Implementing the HWM model in large-scale systems like cloud
environments or big data platforms can introduce scalability challenges due to
the complexity of managing and enforcing security policies across diverse and
distributed resources.
Solutions: Research focuses on developing scalable algorithms and distributed
enforcement mechanisms to maintain the efficacy of the HWM model in
extensive systems.
Big Data and Real-Time Analytics:
Application: In big data environments, the HWM model ensures that data
analytics processes respect the highest security level of accessed data,
preventing unauthorized information flow and maintaining data confidentiality.
Example: Real-time analytics platforms use the HWM model to dynamically
adjust security levels based on the data being processed, ensuring that sensitive
information remains protected throughout the analytics lifecycle.
Machine Learning for Anomaly Detection:
Integration: Integrating machine learning with the HWM model helps in
identifying anomalous access patterns that may indicate potential security
breaches.
Example: In cybersecurity, machine learning algorithms analyze access logs and
network traffic to detect deviations from normal behavior, applying the HWM
model to flag and investigate potential threats.
4.0 Self-Assessment Exercise(s)
5.0 Conclusion
The High-Water Mark (HWM) model is a crucial security policy in computer systems,
ensuring data integrity and controlling information flow by marking the highest security
level accessed by subjects. It is widely implemented in multilevel security systems, audit
trails, logging, and network traffic analysis, maintaining confidentiality and preventing
unauthorized dissemination of sensitive data. Despite challenges in scalability and
integration with large-scale systems, ongoing research and advancements in adaptive
algorithms, heuristics, and machine learning continue to enhance the effectiveness and
applicability of the HWM model. As technologies evolve, the HWM model remains vital
in safeguarding data integrity and ensuring robust security across diverse computing
environments.
6.0 Summary
The High-Water Mark (HWM) model is a security policy designed to ensure data
integrity by tracking the highest security level of data a subject has accessed,
preventing the subject from writing to lower security levels thereafter. This model is
crucial in environments requiring strict information flow control, such as multilevel
security systems, audit trails, and network traffic analysis. It helps prevent unauthorized
dissemination of sensitive information by dynamically enforcing access controls based
on the highest accessed data level. While implementation in large-scale systems
presents scalability challenges, ongoing research in adaptive algorithms, heuristics, and
machine learning aims to enhance the model's efficiency and applicability, ensuring
robust security across diverse computing environments.
7.0 References/Further Readings