Lesson 01: Operating System Security Models

Advanced Computer Security Module

Kushan Sharma
[email protected]
 Review Questions…
1. Briefly describe the processes of encryption and decryption in relation to cryptography?
2. What is the difference between Symmetric and Asymmetric key encryption?
3. Encryption uses an algorithm and a key. Explain the role of a key and outline why the size of the key is
important in the encryption process?
4. How do you use asymmetric key cryptography for key management?
5. TLS is widely used security protocol. Explain how the handshake mechanism ensures a symmetric key
is securely distributed to both a browser and a web server?
6. DAC & MAC are two types of access control mechanisms. What type of access control is implemented
where a database administrator can grant “Update” privilege in a database to specific users or group?
Briefly explain your answer.
7. Prior to installation of an intrusion prevention system (IPS), a network engineer usually place packet
sniffers on the network, why do they use a packet sniffer here?
8. What should be a reasonable response from an intrusion detection system (IDS) when it detects
Internet Protocol (IP) packets where the source address is the same as the destination address?
9. A security engineer is evaluating methods to store user passwords in an information system. How
should they store passwords ensuring the confidentiality security objective?
10. When a communication link is subjected to monitoring, what is the advantage for using an end-to-end
encryption solution over link encryption solution?

Prepared by: Kushan Sharma

 Assignments & Reference Materials
◼ Recommended Text Books
◼ Information Security: The Complete Reference, 2nd Edition, by Mark
Rhodes-Ousley
◼ Chapters 20 to 25
◼ Computer Security Principles and Practices, 3rd Edition, by William Stallings
& Lawrie Brown
◼ Chapters 12 & 13
◼ Assignments (40% of final marks)
◼ Four take home quizzes - Each carries 5% of final marks
◼ Quizzes will be published on Moodle
◼ Answers should be submitted via Moodle
◼ Individual Assignment – 20% of final marks
◼ Final Exam (60% of final marks)
◼ 150 minutes
◼ Open book exam

Prepared by: Kushan Sharma

 Topics to be Covered
◼ OS Architectures
◼ Discretionary Access Control
◼ Mandatory Access Control
◼ Classic Security Models
◼ Trustworthy Computing
◼ International Standards for Operating System Security

Prepared by: Kushan Sharma

 Early Architectural Developments
◼ In 1950s, Dr. John von Neumann wrote The Computer and the Brains that
described a system architecture for the modern micro-processor computing
machine.
◼ Most of the computers in use today are based on the fundamental principle of
Von Neumann architecture.
◼ It has evolved to more complex
structures with:
◼ Parallel processing units (Cores)
◼ Buses (HyperTransport)
◼ Limitation of VNA was with system
bus. Had only one common bus for
both data and instructions.
◼ In Harvard architecture, the CPU can
both read an instruction and perform
a data memory access at the same
time.

Prepared by: Kushan Sharma

 Operating Systems
◼ Operating System's job is to provide user programs with a better, simpler,
cleaner, model of the computer and to handle managing all the resources.
~ by Andrew S. Tanenbaum
◼ Perform two essentially unrelated functions:
◼ Providing application programmers (and application programs, naturally) a clean
abstract set of resources instead of the messy hardware ones
◼ Managing these hardware resources.

Prepared by: Kushan Sharma

 Operating Systems
◼ Operating systems turn the ugly into the beautiful
◼ Real processors, memories, disks, and other devices are very complicated and
present difficult, awkward, idiosyncratic, and inconsistent interfaces.
◼ Hide the hardware and present programs with nice, clean, elegant, consistent,
abstractions to work.
◼ Provide for an orderly and controlled allocation of the processors, memories,
and I/O devices among the various programs wanting them.

Prepared by: Kushan Sharma

 Operating System – Resource Management
◼ Resource management includes multiplexing (sharing) resources in two
different ways: in time and in space.
◼ Determining how the resource is time multiplexed — who goes next and for how
long—is the task of the operating system.
◼ Space multiplexing - each one gets part of the resource. Ex: each running application
gets part of the memory.
◼ Issues such as fairness, protection, and so on, is up to the operating system to
solve.

The structure
of a large
x86 system.

Prepared by: Kushan Sharma

 Exercise 01
◼ Briefly explain the below terms pertaining to operating systems:
◼ Processes:
◼ Process Table
◼ Child Process
◼ System Calls
◼ Process Scheduling:
◼ Scheduling algorithm goals
◼ Scheduling Techniques in Batch Systems
◼ Scheduling Techniques in Interactive Systems
◼ Memory management
◼ Pyhiscal and logical organization
◼ Relocation
◼ Protection
◼ Paging
◼ Page fault
◼ Swapping
◼ Memory Addresses
◼ Physical address
◼ Logical Address
◼ Relative address

Prepared by: Kushan Sharma

 Process & Threads
◼ Process has its own memory space.
Threads exist within a process and every
process has at least one thread (Primary
thread).
◼ Threads run in a shared memory space,
while processes run in separate memory
spaces.
◼ Single heap per process shared by all
threads.
◼ Each thread has its own stack memory.
◼ Threads have direct access to the data
segment of its process but a processes
have their own copy of the data segment
of the parent process.
◼ Changes to the main thread may affect the
behavior of the other threads of the
process while changes to the parent
process does not affect child processes.

Prepared by: Kushan Sharma

 Process Scheduling
◼ Process Behavior
◼ CPU Bound Processes
◼ I/O Bound Processes

◼ Algorithm Goals:
◼ All systems
◼ Fairness - giving each process a fair share of the CPU
◼ Balance - keeping all parts of the system busy
◼ Batch systems
◼ Throughput - maximize jobs per hour
◼ Turnaround time - minimize time between submission and termination
◼ CPU utilization - keep the CPU busy all the time
◼ Interactive systems
◼ Response time - respond to requests quickly
◼ Proportionality - meet users’ expectations
◼ Real-time systems
◼ Meeting deadlines - avoid losing data
◼ Predictability - avoid quality degradation in multimedia systems

Prepared by: Kushan Sharma

 Process Scheduling
◼ Scheduling in Batch Systems
◼ First-Come, First-Served – Easy to implement
◼ Shortest Job First – Minimize turn around time
◼ Shortest Remaining Time Next

◼ Scheduling in Interactive Systems

◼ Round-Robin Scheduling - Each process is assigned a time
interval, called its quantum, during which it is allowed to
run.
◼ Priority Scheduling - Runnable process with the highest
priority is allowed to run.
◼ Shortest Process Next
◼ Lottery Scheduling
◼ Fair-Share Scheduling - Each user is allocated
some fraction

Prepared by: Kushan Sharma

 Memory Management: Storage
◼ Types of memory:
◼ Real (A program or application defined storage location in memory and direct access
to peripheral devices e.g. Comm. buffer)
◼ Virtual (Extended primary memory to secondary storage medium)
◼ Types of storage:
◼ Primary (Memory direct accessible to CPU e.g. Cache and RAM)
◼ Secondary (Non-volatile storage medium e.g. Disk Drives)

◼ Memory allocation changes as process come in to memory and leave it.

Prepared by: Kushan Sharma

 Memory Management: Virtual Memory
◼ Memory Management Unit:
◼ Maps the virtual addresses onto the
physical memory addresses
◼ Relation between physical memory and
virtual memory.

Prepared by: Kushan Sharma

 Memory Management: Paging & Swapping
◼ Paging involves:
◼ Splitting memory into equal sized small chunks
that are called page frames.
◼ Splitting programs (processes) into equal sized
small chunks are called pages.
◼ OS maintains a list of free frames
◼ Pages are fixed blocks of memory usually 4K
or 8K bytes
◼ A page-fault is when a program accesses a
page that is not mapped in physical memory.
◼ Swapping is the act of transferring pages
between physical memory and the swap
space on a disk.
◼ Paging & Swapping Steps:
1. Application request access to memory
2. Management looks up which segment is
allocated to the given process
3. Access memory frame for process
4. Returns data held in memory
Prepared by: Kushan Sharma
 System Calls
◼ The interface between user programs and the
operating system is primarily about dealing
with the abstractions.
◼ Functions which change the execution mode
of the program from user mode to kernel
mode.
◼ For example:
◼ change the date and time of the system
◼ create a network socket
are services provided by kernel and hence
these cases require system calls.
◼ There are certain tasks that can only be done
if a process is running in kernel mode.
◼ System calls make possible to do tasks which
only can be achieved in kernal mode
processes.

Prepared by: Kushan Sharma

 System Call: Example
◼ This is invoked from C programs by calling a
library procedure with the same name as the
system call: read. A call from a C program
might look like this:

◼ Count = read(fd, buffer, nbytes);

◼ Ex: Read System call has three parameters

◼ the first one specifying the file,
◼ the second one pointing to the buffer,
◼ the third one giving the number of bytes to
read
◼ Return the number of bytes actually read in
count.

Prepared by: Kushan Sharma

 Linux System Calls and Library Functions
◼ What are Linux System Calls and Library Functions?
◼ strlen(), open(), fopen()
◼ Standard functions can be classified into two major
categories:
◼ Library function call - Functions which are a part of standard
C library. i.e. strlen()
◼ System function calls - Functions which change the execution
mode of the program from user mode to kernel mode. For
example, change the date and time of the system, create a
network socket. i.e. socket() is a system call.

◼ Library functions can be of two types :

◼ Functions which do not call any system call -
strlen()do not make any system calls.
◼ Functions that make a system call - fopen() function
which a standard library function but internally uses the
open() sytem call.

Prepared by: Kushan Sharma

 Exercise 02
◼ What is the difference between fopen() vs open()?
◼ fopen() is a library function which provides buffered I/O services for opening a file
while open() is a system call that provides non-buffered I/O services.

◼ Though open() function is also available for applications to use but

application should avoid using it directly. Briefly explain?
◼ If a library function corresponding to a system call exists, then applications should
use the library function because:
◼ Library functions are portable and standard library functions will run on all systems.
◼ Sometimes the corresponding library function makes the load to system call lesser resulting
in non-frequent switches from user mode to kernel mode. Using fread() instead of
read() would provide buffered I/O

Prepared by: Kushan Sharma

 System Calls Cont.
◼ Some of the major
POSIX system calls.
◼ The return code s is −1
if an error has
occurred.
◼ The return codes are as
follows:
◼ pid is a process id,
◼ fd is a file descriptor,
◼ n is a byte count,
position is an offset
within the file,
◼ seconds is the
elapsed time.

Prepared by: Kushan Sharma

 UNIX vs Win32
◼ A UNIX program consists of
code that does something or
other, making system calls to
have certain services
performed.
◼ A Windows program is normally
event driven. The main program
waits for some event to
happen, then calls a procedure
to handle it.
◼ Microsoft has defined a set of
procedures called the Win32
API that programmers are
expected to use to get
operating system services.

Prepared by: Kushan Sharma

 OS Structure: Monolithic Systems
◼ Most common structure
◼ Entire operating system runs as a single program in kernel mode.
◼ The operating system is written as a collection of procedures, linked together
into a single large executable binary program.
◼ Each procedure in the system is free to call any other one.
◼ Ability to call any procedure you want is very efficient.
◼ Thousands of procedures that can call each other without restriction may also lead to
a system that is unwieldy and difficult to understand.
◼ A crash in any of these procedures will take down the entire operating system.
◼ Information hiding is very difficult or none, since every procedure is visible to every
other procedure,

Prepared by: Kushan Sharma

 OS Structure: Monolithic Systems
◼ Monolithic organization suggests a basic structure for the operating system:
◼ A main program that invokes the requested service procedure.
◼ A set of service procedures that carry out the system calls.
◼ A set of utility procedures that help the service procedures.

◼ Examples: Linux, BSDs (FreeBSD, OpenBSD, NetBSD), Solaris, OS-9, AIX, HP-
UX, DOS, Microsoft Windows (95,98,Me), OpenVMS

Prepared by: Kushan Sharma

 OS Structure: Microkernal Systems
◼ With the layered approach, the designers have a choice where to draw the
kernel-user boundary.
◼ Bugs in the kernel can bring down the system instantly.
◼ Microkernel design is to achieve high reliability by splitting the operating system
up into small, well-defined modules.
◼ Microkernel—runs in kernel mode and the rest run as relatively powerless
ordinary user processes.
◼ Dominant in real-time, industrial, avionics, and military applications that are
mission critical and have very high reliability requirements.
◼ Examples: Integrity, K42, L4, PikeOS, QNX, Symbian, and MINIX 3.

Prepared by: Kushan Sharma

 Monolithic vs Microkernel
◼ Monolithic design is proved to be less than effective.
◼ The trend in operating systems has been toward a microkernel architecture.
◼ Microkernels are platform independent. Although they lack the performance of
monolithic systems, they are catching up in terms of speed and optimization.
◼ In microkernel, kernel is small and easy to port to other systems.
◼ Using a microkernel or compartmentalized approach, possibility of damagingg
to system is contained to a given compartment.

Prepared by: Kushan Sharma

 OS Structure: Client Server Model
◼ Slight variation of the microkernel idea
◼ Distinguish two classes of processes,
◼ the servers, each of which provides some service
◼ the clients, which use these services
◼ Communication between clients and servers is often by message passing.
◼ The clients need not know whether the messages are handled locally on their
own machines, or whether they are sent across a network to servers on a
remote machine.
◼ The client-server model is an abstraction that can be used for a single machine
or for a network of machines.

Prepared by: Kushan Sharma

 Security of Underline Protocols
◼ Underlying protocols are insecure and operating systems are at risk.
◼ TCP/IP - the language of the Internet and, clearly, the most popular and
utilized protocol.
◼ The entire Internet and corporate computing infrastructure is built on and
running on an insecure infrastructure and foundation.
◼ TCP/IP's main problems are:
◼ Vulnerable to spoofing
◼ Vulnerable to session hijacking
◼ Predictable sequence guessing
◼ Vulnerable to SYN flooding
◼ No authentication or encryption

Prepared by: Kushan Sharma

 Vulnerable to Spoofing
◼ Spoofing - establishing a connection with a forged sender address.
◼ Exploiting trust relations between the source address and the destination
address.
◼ Possible to carry out DoS attacks by making it difficult for victims to block the
DoS traffic.
◼ RPF (reverse path forwarding) to prevent spoofing

Prepared by: Kushan Sharma

 Vulnerable to Session Hijacking
◼ An attacker can take control of a connection by intercepting the session key
and using it to insert his own traffic into an established TCP/IP communication
session.
◼ Usually perform in combination with a DoS attack against the legitimate sender
so that traffic cannot get through, as in a man in the middle attack.
◼ Example scenarios:

Prepared by: Kushan Sharma

 Vulnerable To SYN Flood
◼ Many implementations can keep track of only a limited number of connections.
◼ A malicious host can exploit the small size of the listen queue by sending
multiple SYN requests to a host but never replying to the SYN and ACK.
◼ The malicious host quickly fills up the other host’s listen queue, and that host
stops accepting new connections until a partially opened connection is
completed or times out.

Prepared by: Kushan Sharma

 Predictable Sequence Guessing
◼ The sequence number is a 32-bit pseudorandom number
◼ The odds of guessing the correct ISN would seem to be exceedingly low.
◼ If the ISN for a connection is assigned in a predictable way, it becomes
relatively easy to guess.
◼ This not a problem of the protocol but in implementation.
◼ Many implementations have ignored the pseudorandom nature.

Prepared by: Kushan Sharma

 Covert Channels
◼ Client and server do not trust each other.
◼ For example, the server’s job is to help clients with filling out their tax forms. The
clients are worried that the server will secretly record their financial data.
◼ The third process is the collaborator, which is conspiring with the server to
indeed steal the client’s confidential data.
◼ The collaborator and server are typically owned by the same person.
◼ Even in a system which has a proper security model, coverts channel may
exists.

Prepared by: Kushan Sharma

 Covert Channels
◼ Confinement Problem – Problem of confining things by designing a system in
which it is impossible for the server process to leak to the collaborator process
the information that it has legitimately received from the client process.
◼ Example for subtle communication:
◼ Use of bit streams:
◼ The server can try to communicate using a binary bit stream by sending a 1/0 bit in fixed
interval of times.
◼ Collaborator can try to detect the bit stream by carefully monitoring its response time.
◼ Modulating the CPU usage:
◼ To send a 1 bit, it computes as hard as it can for a fixed interval of time.
◼ To send a 0 bit, it goes to sleep for the same length of time.
◼ Modulating the paging rate:
◼ Many page faults for a 1
◼ No page faults for a 0

Prepared by: Kushan Sharma

 Access Control Lists
◼ Every resource that the operating system interfaces with (memory, files,
hardware, device drivers, and so on) must interact from a security perspective.
◼ Using ACL, OS can detail what an object can and can’t do by limiting its
privileges.
◼ Access control enables you to protect a server or parts of the server
(directories, files, file types, and so on)
◼ When a server receives a request, it determines access by consulting a
hierarchy of rules in the ACL.
◼ An access control list is defined as a table that tells OS which access rights each
user has to a particular system object (i.e. file, directories)

Prepared by: Kushan Sharma

 Access Control Lists
◼ Each OS implements ACL differently

Prepared by: Kushan Sharma

 Discretionary Access Control (DAC)
◼ Each resource has a list of users who can access it.
◼ DAC provides access by identity of the user and not by permission level.
◼ Depending on the context in which they are used, these controls are also called
Rule-based access control (RBAC), Identity-based access control (IBAC).
◼ The owner of the object specifies which subjects can access the object at the
time of creation.
◼ This model is called discretionary because the control of access is based on the
discretion of the owner.

◼ Most operating systems such as all Windows, Linux, and Macintosh and most
flavors of Unix are based on DAC models.
Prepared by: Kushan Sharma
 Mandatory Access Control (MAC)
◼ The system specifies which subjects can access specific data objects.
◼ Admins creates a set of levels and each user is linked with a specific level.
◼ Users can access all the resources that are not greater than his level.
◼ MAC model is based on security labels. Subjects are given a security clearance
(secret, top secret, confidential, etc.), and data objects are given a security
classification (secret, top secret, confidential, etc.).
◼ When the system is making an access control decision, it tries to match the
clearance of the subject with the classification of the object.
◼ Usually used in environments where confidentiality is of utmost importance.

Prepared by: Kushan Sharma

 MAC vs DAC
◼ MAC provides access based on levels while DAC provides access based on
identity.
◼ DAC is more labor intensive than MAC:
◼ MAC is an easier way in establishing and maintaining access, especially when dealing
with a great number of users.
◼ DAC is more flexible than MAC:
◼ When level 2 user needs access to a single level 1 resource, imposible to provide
access to that user without giving him access to all other resources in the same
category.
◼ Lowering the level of the resource to the user would also result in all other users of
his level to gain access to that resource.
◼ MAC access can only be changed by admins while DAC access can be provided
by other.
◼ MAC is always prohibitive (i.e., all that is not expressly permitted is forbidden)
and not permissive.

Prepared by: Kushan Sharma

 MAC vs DAC

Prepared by: Kushan Sharma

 Information Security Models
◼ Address security issues of complex software systems when flaws or bugs are
found that subsequently needed to be fixed.
◼ Specify the operational and functional behavior of a “system” for security.
◼ Specify the rules of behavior for a “system” (/ system of systems) in meeting
the security objectives, where:
◼ Security objective: confidentiality, integrity
◼ Implementation rules: least-privilege, separation-of-duties
◼ There are many security models:
◼ Bell-Lapadulla Model
◼ Biba Model
◼ Chinese Wall Model
◼ Clark Wilson Model
◼ Graham-Denning Model – formal system of protection rules.
◼ Information-Flow Model – demonstrates the data flows, communications channels,
and security controls.
◼ Non-Interference Model – a subset of information-flow model that prevents subjects
operating in one domain from affecting each other in violation of security policy. (i.e.
Compartmentalized.)

Prepared by: Kushan Sharma

 Bell-LaPadula
◼ Designed to prevent users and processes from reading above their security
level - Confidentiality
◼ Focuses on sensitivity of data according to classification levels.
◼ Each subject and each object is assigned a security class
◼ Security classes form a strict hiearachy
◼ Subjects have security clearance of a given level; objects have security
classifications for a given level.
◼ Two Rules:
◼ The simple security property: A process running at security level k can read only
objects at its level or lower.
◼ The * property: A process running at security level k can write only objects at its
level or higher.

Prepared by: Kushan Sharma

 Exercise 03
◼ Why does Bell-LaPadula model require * Property?

◼ Simple Security Property and * Property of Bell-LaPadulla model together

address the MAC requirement but cannot facilitate DAC. Briefly explain?
◼ DS-Property: An individual (or role) may grant to another individual (or role) access
to a document based on the owner’s discretion, constrained by the MAC rules. Thus,
a subject can exercise only accesses for which it has the necessary authorization and
which satisfy the MAC rules.

Prepared by: Kushan Sharma

 Bell-LaPadula
◼ Processes can read down and write up, but not the reverse.
◼ Processes read and write objects, but do not communicate with each other
directly.

◼ Process is reading the object

◼ Process is writing into the object

Prepared by: Kushan Sharma

 Exercise: Bell-LaPadula Example
◼ Alice and Bob are users of the system. Alice is a student (s) in course c1
(Alice: (c1-s)). Bob is a teacher (t) in course c1 but may also access the
system as a student; thus two roles (Bob: (c1-t), (c1-s)) are assigned
to Bob. Briefly explain how Alice and Bob achive below listed task within the
implementation of BLP.
1. Alice needs to submit the assignment f2 and it should be reviewed by Bob.
2. Bob needs to send comments f3 to the assignment f2 submitted by Alice.
3. Bob needs to create a exam paper f4 using an existing template file store at level c1-
t.
4. Bob wants Alice to take the exam f4 and so must provide her with read access. (Hint:
Security level can be downgraded once by security administrator outside the BPL model)
5. Alice needs to write the answers to the exam into a file f5.

Prepared by: Kushan Sharma

 Biba Model
◼ Bell-LaPadula model was devised to keep
secrets, not guarantee the integrity of the
data.
◼ Biba model addresses the integrity problem.
◼ Prevent unauthorized modifications.
◼ Two Rules in Biba:
◼ The simple integrity property: A process
running at security level k can write only objects
at its level or lower (no write up).
◼ The integrity * property: A process running
at security level k can read only objects at its
level or higher (no read down).
◼ Some organizations want both the Bell-
LaPadula properties and the Biba properties,
but these are in direct conflict so they are
hard to achieve simultaneously.

Prepared by: Kushan Sharma

 Limitation of Bell-LaPadula & Biba Model
◼ Bell-LaPadula Model:
◼ Incompatibility of confidentiality and integrity within a single system.
◼ This is a confidentiality model and not a model to support integrity.
◼ Cooperating conspirator problem in the presence of covert channels.
◼ In the presence of shared resources the *-property may become unenforceable.
◼ Biba Model:
◼ Incompatibility of confidentiality and integrity within a single system.
◼ This is a integrity model and not a model to support confidentiality.

Prepared by: Kushan Sharma

 Chinese Wall Model
◼ Address the problem of potential for conflicts of interest and inadvertent
disclosure of information by a consultant or contractor.
◼ This is not an integrity policy, but an access control confidentiality policy.
◼ Example: If you access a file from GM, you subsequently will be blocked from
accessing any files from Ford or Chrysler.
◼ The access rights that any subject enjoys depends on the history of past
accesses.

Prepared by: Kushan Sharma

 Chinese Wall Model
◼ The elements of the model are the following:
◼ Subjects: Active entities that may wish to access protected objects; includes users
and processes
◼ Information: Corporate information organized into a hierarchy with three levels:
◼ Objects: Individual items of information, each concerning a single corporation
◼ Dataset (DS): All objects that concern the same corporation
◼ Conflict of interest (CI) class: All datasets whose corporations are in competition
◼ Access rules: Rules for read and write access

◼ Formally, the policy restricts access according to the following two properties:
◼ (Chinese Wall) Simple Security Rule: A subject S can read on object O only if
◼ O is in the same DS as an object already accessed by S, OR
◼ O belongs to a CI from which S has not yet accessed any information
◼ (Chinese Wall) *-property: A subject S can write an object O only if
◼ S can read O according to the simple security rule, AND
◼ All objects that S can read are in the same DS as O.

Prepared by: Kushan Sharma

 Chinese Wall Model

Prepared by: Kushan Sharma

 Clark Wilson Model
◼ Attempts to define a security model based on accepted business practices for
transaction processing.
◼ Aimed at commercial than military applications.
◼ Based on two concepts:
◼ Well-formed transactions: A user should not manipulate data arbitrarily. But only
in constrained ways that preserve integrity of data.
◼ Separation of duty among users: Any person permitted to create or certify a
well-formed transaction may not be permitted to execute it.
◼ The policy is constructed in terms of the following categories:
◼ Constrained Data Items: CDIs are the objects whose integrity is protected
◼ Unconstrained Data Items: UDIs are objects not covered by the integrity policy.
Unchecked data items. An example is a simple text file.
◼ Transformation Procedures: TPs are the only procedures allowed to modify CDIs,
or take arbitrary user input and create new CDIs. Designed to take the system from
one valid state to another.
◼ Integrity Verification Procedures: IVPs are procedures meant to verify
maintenance of integrity of CDIs.

Prepared by: Kushan Sharma

 Clark Wilson Model
◼ There are two kinds of rules: Certification and Enforcement.
◼ C1: All IVPs must properly ensure that all CDIs are in a valid state at the time the
IVP is run.
◼ C2: All TPs must be certified to be valid. That is, they must take a CDI to a valid final
state, given that it is in a valid state to begin with.
◼ E1: The system must maintain the list of relations specified in rule C2 and must
ensure that the only manipulation of any CDI is by a TP.
◼ E2: Users must only access CDIs by means of TPs for which they are authorized. The
system must maintain a list of relations of the form (UserID, TPi, (CDIa, CDIb, CDIc))
◼ C3: The list of relations in E2 must be certified to meet the separation of duty
requirement. (Creators cannot execute transactions.)
◼ C4: The operation of TPs must be logged.
◼ C5: Any TP that takes a UDI as an input value must be certified to perform only valid
transformations, or else no transformations, for any possible value of the UDI. The
transformation should take the input from a UDI to a CDI, or the UDI is rejected.
◼ E3: The identity of each user attempting to execute a TP must be authenticated.
◼ Permissions are encoded as a set of triples of the form:
(user, TP, {CDI set})
(UserID, TPi, (CDIa, CDIb, CDIc, . . . ))
Prepared by: Kushan Sharma
 Summary of Clark Wilson System Integrity Rules

Prepared by: Kushan Sharma

 Clark Wilson Models Addresses Four Concerns
◼ Clark Wilson’s four fundamental concerns of any reasonable commercial
integrity model:
◼ Authentication: identity of all users must be properly authenticated.
◼ Audit: modifications should be logged to record every program executed and by
whom, in a way that cannot be subverted.
◼ Well-formed transactions: a user should not manipulate data arbitrarily, but only
in constrained ways that preserve or ensure the integrity of the data.
◼ Separation of duty: the system associates with each user a valid set of programs
they can run and prevents unauthorized modifications, thus preserving integrity and
consistency with the real world.

Prepared by: Kushan Sharma

 Reference Monitor
◼ A separable module that enforces access control decisions and security
processes for the operating system.
◼ All security operations are routed through the reference monitor, which decides
if the specific operation should be permitted or denied.
◼ Regulates the access of subjects to objects on the basis of security parameters
of the subject and object.
◼ For example RM accepts all system calls involving security, such as opening
files, and decides whether they should be processed or not.

Prepared by: Kushan Sharma

 Reference Monitor Cont.
◼ Security Kernel Database - Lists the access privileges (security clearance) of
each subject and the protection attributes (classification level) of each object.
◼ RM enforces security rules and has following properties:
◼ Complete mediation: The security rules are enforced on every access, not just, for
example, when a file is opened.
◼ Isolation: The reference monitor and database are protected from unauthorized
modification.
◼ Verifiability: The reference monitor’s correctness must be provable. That is, it must
be possible to demonstrate mathematically that the reference monitor enforces the
security rules and provides complete mediation and isolation.
◼ Pure software implementations impose too high a performance penalty to be
practical
◼ It must not be possible for attackers to change the RM.

◼ A system that can provide all these facilities is called a trustworthy system.

Prepared by: Kushan Sharma

 Reference Monitor
◼ Main elements of effective RM:
◼ Always on: Security must be implemented consistently and at all times for the
entire system and for every file and object.
◼ Not subject to preemption: Nothing should be able to preempt the reference
monitor. If this were not the case, then it would be possible for an entity to bypass
the mechanism and violate the policy that must be enforced.
◼ Tamperproof: It must be impossible for an attacker to attack the access mediation
mechanism such that the required access checks are not performed and
authorizations not enforced.
◼ Lightweight: It must be small enough to be subject to analysis and tests, proving
its effectiveness.

Prepared by: Kushan Sharma

 TCSEC – Trusted Computer Security Evaluation Criteria
◼ Informally known as Orange Book.
◼ Focused primarily on protecting information confidentiality.
◼ Basis of measurement is confidentiality, it is similar to the Bell-LaPadula model.
◼ Developed to meet below objectives:
◼ To give users a method for assessing how much they can trust computer
systems for the secure processing of classified or other sensitive information.
◼ To guide manufacturers in what to build into their new, widely available
commercial products to satisfy trust requirements for sensitive applications.
◼ To provide a basis for specifying security requirements for software and
hardware acquisitions.

Prepared by: Kushan Sharma

 TCSEC – Trusted Systems Security Evaluation Criteria
◼ Designed to rate systems and place them into one of four categories:
◼ A—Verified protection: An A-rated system is the highest security division.
◼ B—Mandatory security: A B-rated system has mandatory protection of the TCB.
◼ C—Discretionary protection: A C-rated system provides discretionary protection of
the TCB.
◼ D—Minimal protection: A D-rated system fails to meet any of the standards of A, B,
or C and basically has no security controls.
◼ Developed to evaluated standalone systems. Not suitable for the era of
client/server computing.
◼ The client/server computing world was embryonic when the TCSEC was
created, although its objectives were admirable.
◼ To go beyond Orange Book functionality to their networked systems, need to
apply the requirements of the Trusted Network Interpretation of the TCSEC
(TNI), also known as the Red Book.

Prepared by: Kushan Sharma

 TNI/TCSEC Matrix
◼ A1: Built, installed,
and delivered in a
secure manner.
◼ B1: Security labels
(MAC).
◼ B2: Security labels
and verification of no
covert channels (MAC)
◼ B3: Security labels,
verification of no
covert channels, and
must stay secure
during startup (MAC)
◼ C1: Weak protection
mechanisms (DAC)
◼ C2: Strict login
procedures (DAC)
◼ D1: Failed or was not
tested

Prepared by: Kushan Sharma

 Labels
◼ Security-related information that has been associated with objects such as files,
processes, or devices.
◼ Sensitivity Labels:
◼ Identify whether a user is cleared to view certain information
◼ Used to define the level of data classification
◼ Composed of a sensitivity level and possibly some number of sensitivity categories.
◼ The number of sensitivity levels available is dependent on the specific OS.
◼ Integrity Labels:
◼ Identify whether data is reliable enough for a specific user to see
◼ Composed of an integrity grade and some number of integrity divisions
◼ Number of hierarchical grades to classify the reliability of information depends on OS.
◼ Each file or program has one hierarchical sensitivity level.
◼ A user may be allowed to use several different levels, but only one level may be
used at any given time.
◼ TCSEC heavily uses labels
◼ Common Criteria also require security labels

Prepared by: Kushan Sharma

 TNI and ITSEC
◼ The Red Book: Trusted Network Interpretation
◼ Objective is to examine security for network and network components.
◼ The Red Book examines integrity and availability.
◼ Three areas of reviews of the Red Book include
◼ DoS prevention—Management and continuity of operations.
◼ Compromise protection—Data and traffic confidentiality, selective routing.
◼ Communications integrity—Authentication, integrity, and nonrepudiation.

◼ ITSEC: Information Technology Security Evaluation Criteria

◼ A European standard developed in the 1980s
◼ Evaluate confidentiality, integrity, and availability of an entire system.
◼ ITSEC designates the target system as the Target of Evaluation (TOE).
◼ The evaluation is actually divided into two parts:
◼ One part evaluates functionality (10 functionality (F) classes)
◼ and the other evaluates assurance (7 assurance (E) classes) - Assurance classes rate the
effectiveness and correctness of a system.

Prepared by: Kushan Sharma

 Common Criteria: A Single Global Standard
◼ A global security standard ensuring that there is a common mechanism for
evaluating the security of IT products.
◼ Enable users to have an objective yardstick by which to evaluate a product’s
security.
◼ Orange Book and the Common Criteria are not exactly the same types of
documents:
◼ Orange Book: a set of requirements that reflect the practice and policies of a specific
community
◼ Common Criteria: policy-independent and can be used by many organizations to
articulate their security requirements.
◼ Designed around TCB entities. These entities include:
◼ Physical and logical controls
◼ Startup and recovery
◼ Reference mediation
◼ Privileged states.

Prepared by: Kushan Sharma

 Development of Common Criteria
◼ In 1997, the ISO released the Common Criteria (ISO 15408), which is an
amalgamated version of TCSEC, ITSEC, and the CTCPEC.
◼ ISO 15408:1999. (The official name of the standard is the International
Common Criteria for Information Technology Security.)

Prepared by: Kushan Sharma

 Evaluation Assurance Levels of Common Criteria
◼ Categorizes assurance into one of seven increasingly strict levels of assurance.
These are referred to as Evaluation Assurance Levels (EALs).
◼ EAL 0 - Inadequate assurance
◼ EAL 1 - Functionality tested
◼ EAL 2 - Structurally tested
◼ EAL 3 - Methodically checked and tested
◼ EAL 4 - Methodically designed, tested, and reviewed
◼ EAL 5 - Semiformally designed and tested
◼ EAL 6 - Semiformally verified designed and tested
◼ EAL 7 - Formally verified designed and tested

◼ List of certified products:

◼ https://www.commoncriteriaportal.org/products/

Prepared by: Kushan Sharma

 Problems with the Common Criteria
◼ Administrative overhead The overhead involved with gaining certification
takes a huge amount of time and resources.
◼ Expense Gaining certification is extremely expensive.
◼ Labor-intensive certification The certification process takes months.
◼ Need for skilled and experienced analysts Availability of information
security professionals with the required experience is still lacking.
◼ Room for various interpretations The Common Criteria leave room for
various interpretations of what the standard is attempting to achieve.
◼ Paucity of Common Criteria testing laboratories There are only seven
laboratories in the United States.
◼ Length of time to become a Common Criteria testing laboratory Even
for those organizations that are interested in becoming certified, the process in
and of itself takes quite a while.

Prepared by: Kushan Sharma

 Trustworthy Computing
◼ Microsoft started this in year 2002
◼ The four goals of the Trustworthy Computing initiative are:
◼ Security As a customer, you can expect to withstand attack. In addition, you can
expect the data is protected to prevent availability problems and corruption.
◼ Privacy You have the ability to control information about yourself and maintain
privacy of data sent across the network.
◼ Reliability When you need your system or data, they are available.
◼ Business integrity The vendor of a product acts in a timely and responsible
manner, releasing security updates when a vulnerability is found.
◼ Microsoft created a framework to make their products secure by design.
◼ Secure by design simply means that all vulnerabilities are resolved prior to
shipping the product.

Prepared by: Kushan Sharma

 Trustworthy Computing
◼ Secure by design requires three steps.
◼ Build a secure architecture. This is imperative. Software needs to be designed
with security in mind first and then features.
◼ Add security features. Feature sets need to be added to deal with new security
vulnerabilities.
◼ Reduce the number of vulnerabilities in new and existing code. The internal
process at Microsoft was revamped to make developers more conscious of security
issues while designing and developing software.
◼ Secure in deployment means ongoing protection, detection, defense,
recovery, and maintenance through good tools and guidance.
◼ Communications is the key to the whole project.
◼ How quickly can Microsoft get the word out that a vulnerability exists and help you to
understand how to operate your system with enhanced security?
◼ Patch Tuesday

Prepared by: Kushan Sharma

[email protected]