MODULE II SECURITY INVESTIGATION
Need for Security, Business Needs, Threats, Attacks, Legal, Ethical and Professional
Issues - An Overview of Computer Security - Access Control Matrix, Policy-Security
policies, Confidentiality policies, Integrity policies and Hybrid policies
AN OVERVIEW OF COMPUTER SECURITY
Protection
provided by a set of mechanisms (countermeasures) to prevent bad things (threats)
from happening
Authorization
protection against breaking rules
Authentication is proving a claim – usually that you are who you say you are,
where
you say you are, at the time that you say it is.
Rule examples:
Only registered students should be able to take exam or fill out surveys
Only the bank account owner can debit an account
Only hospital’s medical personnel should have access to the patient’s medical
records
Accountability
You can tell who did what when
Accountability means that the system is able to provide audit trails of all
transactions.
The system managers are accountable to scrutiny from outside the system and
must be able to
Provide details of all transactions that have occurred.
Audit trails must be selectively kept (and protected to maintain their integrity)
so that actions affecting security can be traced back to the responsible party.
(security) audit -- actions are recorded in audit log
Non-Repudiation -- Evidence of actions is generated and stored
Non-repudiation is the prevention of either the
sender or the receiver denying a transmitted
message.
Availability
Information should be accessible and usable upon appropriate demand by an
authorised user.
Service continuity -- you can always get to your resources
Disaster recovery -- you can always get back to your work after the
interruption
Assurance
Set of things the system builder and the operator of the system do to convince you
that it is
really safe to use.
the system can enforce the policy you are interested in, and
the system works as intended
The sequence of steps
includes detailed specifications of
the desired (or undesirable) behaviour;
an analysis of the design of the hardware, software, and other components to
show that the system will not violate the specifications; and arguments or
proofs that the implementation, operating procedures, and maintenance
procedures will produce the desired behaviour
ACCESS CONTROL MATRIX
Object System
Access Matrix Structure
Access Control Matrix Model
The simplest framework for describing a protection system is the access control
matrix model,
which describes the rights of users over files in a matrix.
The set of all protected entities (that is, entities that are relevant to the protection
state of the system) is called the set of objects O.
The set of subjects S is the set of active objects, such as processes and users
The relationship between these entities is captured by a matrix A with rights
drawn from a set of rights R in each entry a[s, o],
where s ∈ S, o ∈ O, and a[s, o] ⊆ R.
The subjects has the set of rights a[s, o] over the object o.
The set of protection states of the system is represented by the triple (S, O, A)
Here, process 1 can read or write file 1 and can read file 2;
process 2 can append to file 1 and read file 2.
Process 1 can communicate with process 2 by writing to it, and
process 2 can read from process 1.
Each process owns itself and the file with the same number.
Note that the processes themselves are treated as both subjects (rows) and objects
(columns).
This enables a process to be the target of operations as well as the operator.
Why access matrix is not used
➢ Access control matrix has all relevant info
➢ But how to manage a large access control (AC) matrix?
➢ Could be 1,000’s of users, 1,000’s of resources
➢ Then AC matrix with 1,000,000’s of entries
➢ Need to check this matrix before access to any resource is allowed
➢ Hopelessly inefficient
Access Control Lists
ACL: store access control matrix by column
Example: ACL for insurance data is in yellow
Capabilities (or C-Lists)
Store access control matrix by row
Example: Capability for Alice is in blue
ACLs vs Capabilities
ACLs
Good when users manage their own files
Protection is data-oriented
Easy to change rights to a resource
Capabilities
Easy to delegate
Easy to add/delete users
Easier to delegate rights
Harder to control the delegation
More difficult to implement
The “Zen of information security
SECURITY POLICIES
A security policy is a statement that partitions the states of the system into a set of
authorized, or secure, states and a set of unauthorized, or nonsecure, states.
A security policy sets the context in which we can define a secure system.
What is secure under one policy may not be secure under a different policy
Types of Security Policies
A military security policy (also called a governmental security policy) is a
security policy developed primarily to provide confidentiality
A confidentiality policy is a security policy dealing only with confidentiality.
A commercial security policy is a security policy developed primarily to provide
integrity
An integrity policy is a security policy dealing only with integrity.
Types of Access Control
Identity-Based Access Control (IBAC):
If an individual user can set an access control mechanism to allow or deny
access to an object, that mechanism is a discretionary access
control (DAC), also called an identity-based access control (IBAC).
Rule-Based Access Control:
When a system mechanism controls access to an object and an individual user
cannot alter that access, the control is a mandatory access control (MAC),
occasionally called a rule-based access control
CONFIDENTIALITY POLICIES
Goals of Confidentiality Policies
A confidentiality policy, also called an information flow policy
prevents Unauthorized disclosure of information
Unauthorized alteration of information is secondary
The Bell-LaPadula Model
BLP security model designed for MLS (Multilevel Security)
BLP deals with
confidentiality => To prevent unauthorized reading
O is an object,
S is a subject
Object O has a classification
Subject S has a clearance
Security levels are denoted by L(O) and L(S)
Simple Security Condition:
S can read O if and only if L(O) ≤ L(S)
S can write O if and only if L(S) ≤ L(O)
Example
Alice can read all files
Chiang cannot read Personnel or E-Mail Files
Fred can only read Telephone Lists
INTEGRITY POLICIES
Goals of Integrity Policies
Commercial requirements differ from military requirements in their emphasis on
preserving data integrity
Requirements
1. Users will not write their own programs, but will use existing production
programs and databases.
2. Programmers will develop and test programs on a nonproduction system; if
they need access to actual data, they will be given production data via a
special process, but will use it on their development system.
3. A special process must be followed to install a program from the
development system onto the production system.
4. The special process in requirement 3 must be controlled and audited.
5. The managers and auditors must have access to both the system state and
the system logs that are generated.
Requirements suggest several principles of operation
Separation of duty.
The principle of separation of duty states that if two or more steps are
required to perform a critical function, at least two different people should
perform the steps
Separation of function
Developers do not develop new programs on production systems because of
the potential threat to production data.
Depending on the sensitivity of the data, the developers and testers may
receive sanitized production data.
Auditing
Commercial systems emphasize recovery and accountability
Auditing is the process of analysing systems to determine what actions took
place and who performed them.
commercial systems must allow extensive auditing and thus have extensive
logging
Auditing is, in many senses, external to the model.
HYBRID POLICIES
Few organizations may limit their security objectives to confidentiality or integrity
only but most organizations desire both, in some mixture
Chinese Wall Model
Derived from the British laws concerning conflict of interest
A model of a security policy that refers equally to confidentiality and
integrity. It describes policies that involve a conflict of interest in business,
1. The objects of the database are items of information related to a
company.
2. A company dataset (CD) contains objects related to a single
company.
3. A conflict of interest (COI) class contains the datasets of companies
in competition.
Simple Security Condition:
S can read O if and only if any of the following holds.
1. There is an object O´ such that S has accessed O´
and CD(O´ ) =CD(O).
2. For all objects O´, O´ ∈ PR(S) ⇒ COI(O´) ≠ COI(O).
3. O is a sanitized object.
Simple Security Condition:
A subject S may write to an object O if and only if both of the following
conditions hold.
1. The CW-simple security condition permits S to read O.
2. For all un-sanitized objects O´, S can read O´ ⇒ CD(O´) = CD(O).
Example
If Anthony reads any Company dataset (CD) in a conflict of interest
(COI), he can never read another CD in that COI
Susan may have access to no more than one CD in each COI, so she
could access Citibank’s CD and ARCO’s CD, but not Citibank’s CD
and Bank of America’s CD.
Clinical Information Systems security model
Derived from medical ethics and laws about dissemination of patient data
➢ Medical records require policies that combine confidentiality and integrity
➢ Conflict of interest is not a critical problem.
➢ Patient confidentiality, authentication of both records and the personnel
making entries in those records, and assurance that the records have not
been changed erroneously are critical.
Entities in the policy
1. A patient is the subject of medical records, or an agent for that person who
can give consent for the person to be treated.
2. Personal health information is information about a patient’s health or
treatment enabling that patient to be identified.
3. A clinician is a health-care professional who has access to personal health
information while performing his or her job.
Set of principles deals with access to the medical records
Access Principle 1:
Each medical record has an access control list naming the individuals
or groups who may read and append information to the record.
The system must restrict access to those identified on the access control
list.
Access Principle 2:
One of the clinicians on the access control list (called the responsible
clinician) must have the right to add other clinicians to the access
control list.
Access Principle 3:
The responsible clinician must notify the patient of the names on the
access control list when the patient’s medical record is opened and
must obtain the patient’s consent.
Except for situations given in statutes, or in cases of emergency
Access Principle 4:
The name of the clinician, the date, and the time of the access of a
medical record must be recorded.
Creation Principle:
A clinician may open a record, with the clinician and the patient on the
access control list. If the record is opened as a result of a referral, the
referring clinician may also be on the access control list.
Deletion Principle:
Clinical information cannot be deleted from a medical record until the
appropriate time has passed.
Confinement Principle:
Information from one medical record may be appended to a different
medical record if and only if the access control list of the second record
is a subset of the access control list of the first.
Aggregation Principle:
Measures for preventing the aggregation of patient data must be
effective.
a patient must be notified if anyone is to be added to the access control
list for the patients’ record
Enforcement Principle:
Any computer system that handles medical records must have a
subsystem that enforces the preceding principles.
The effectiveness of this enforcement must be subject to evaluation by
independent auditors.
Auditors are given access to copies of the records, so the auditors cannot alter
the original records in any way.