Category: Security

Why securing data stored in databases so important and different?
– Databases store massive amounts of sensitive data
– Data has structure that influences how it is accessed
– Accessed via queries or programs written in languages like SQL
– Transactional nature of queries
– Derived data or database views

Relational Database System (RDBS)
– Relational model based database systems are widely used in real-world envrionments
– A relational database consists of relations or tables
– A table is defined by a schema and consists of tuples
– Tuples store attribute values as defined by schema
– Keys used to access data in tuples

Employee Table: Foreign Key, Primary Key

Operations on relations:
– Create, select, insert, update, join and delete
– Example: SELECT * FROM EMPLOYEE WHERE DID = ’15’
– It returns tuples for Robin and Cody

Queries written in a query language(e.g., SQL) use such basic operations to access data in a database as needed.

Two commands: GRANT and REVOKE
GRANT {privileges|role}
TO {user|role|public}
e.g. GRANT SELECT ON ANY TABLE TO Alice

Privileges can be for operations such as SELECT, INSERT, UPDATE OR DELETE.

Testing:
Demonstrate existence of problem
Cannot demonstrate absence of problem
Regression testing: ensure that alterations do not break existing functionality / performance

Challenges:
test case generation, code coverage, exponential number of different executions, different execution environments

Penetration testing:
Ethical hackers attempt to defeat security measures
Cannot demonstrate absence of problem

Formal verification: Checking a mathematical specification of program to ensure that security assertions hold.
– Model checking, automated theorem proving
– State variables w/initial assignment, program specification describing how state changes, boolean predicates over state variables
– Difficulty: exponential time & space worst case complexity
– Model checking pioneers won the 2007 turning award

Common Criteria(2005) international standard replaced orange book
– Originated out of European, Canadian, and US standards
– Idea: users specify system needs, vendors implement solution and make claims about security properties, evaluators determine whether vendors actually met claims
– Evaluation assurance level(EAL) rates systems
– EAL1 most basic, EAL7 most rigorous

Trusted path from user to secure system
prevents programs from spoofing interface of secure components
prevents programs from tapping path(e.g. keyloggers)

Audit log showing object accesses – only useful if you /look/ at the log
detect unusual use of the system

Kernel Design
Security kernel enforce all security mechanisms
Good isolation, small size for verifiability, keeps security code together
Reference monitor controls access to objects (monitors all references to objects)
Tamperproof[impossible to break or disable]
Un-Bypassable[always invoked, complete mediation]
Analyzable [small enough to analyze & understand]

All parts of OS needed for correct enforcement of securioty policy
handles primitive I/O, clocks, interrupt handling, hardware capabilities, label checkikng
Virtual machine provides hardware isolation, logical OS separation

Assurance: Ways of convincing ourselves that a model, design, & implementation are correct

Methods of assurance validation:
Testing / Penetration testing
Formal verification validation
Checking that developers have implemented all requirements
Requirements checking, design & code reviews, system testing

Trusting Software:
Functional correctness
Does what it was designed to do
Maintains data integrity
Even for bad input
Protects disclosure of sensitive data
Does not pass to untrusted software
Confidence
Experts analyze program & assure trust
Statement giving security we expect system to enforce
Do this formally when and where possible

TCB Design Princeples
Least privilege for users & programs, Economy, Open design, Complete mediation, Fail-safe defaults, Ease of use

How do we build a TCB:
Support key security features
-Must implement certain security relevant functions
Authentication
Access control to files & general objects
Mandatory access control(SELinux)
Discretionary access control(standard file permissions)

-Protection of data used by OS(OS must protect itself)
Security features of trusted OSes
Object reuse protection
Disk blocks, memory frames reused
Process can allocate disk or memory, then look to see what’s left behind
Trusted OS should zero out object before reuse
Secure file deletion: overwrite with varying patterns of zeros & ones
Secure disk destruction: degaussing, physical destruction

Biba is dual of BLP
– Focuses on integrity rather than confidentiality
– Read-up and write-down rules

Examples
– Integrity level could be high, medium or low
– Compartment could be similar to BLP and captures topic(s) of document
– Low integrity information should never flow up into high integrity documents

Policies for Commercial Envrionments
– User clearance is not common
– Other requirements exist
Data only be accessed by certain application(e.g., payroll)
Separation-of-duty and conflict-of-interest requirements

Clark-Wilson Policy
Users -> Programs(transactions) -> Objects
same user cannot execute two programs that require separation-of duty
Chinese Wall Policy
deals with conflict of interest

Objects are put into conflict classes:
the user can access any object as long as he/she has not accessed an object from another company in the same conflict class

Trusted Computing Bases(TCB)
Revisiting Trusted Computing Base(TCB)
– How do we know TCB can be trusted?
Secure vs. trusted vs high assurance
set of all hardware and software trusted to operate securely
required for all other trust in the system security policy

Example of labels/MAC in a DoD Environment
1. Label = (Sensitivity lavel, compartment)
2. Lets us consider highly sensitive documents that have information about various arms stockpiles.
L1 = (TS,{nuclear, chemical})
L2 = (S,{nuclear, conventional})
1.Providing confidential access to documents(Bell and La Padula or BLP Model)

Comparing Labels
– Assume sensitivity levels are totally ordered(TS > S > C > U)
– Compartments are sets which can only be partially ordered
How do we order labels?

Comparing Labels
L1 = (X1, Comp1), L2 = (X2, Comp2)
L1 dominates L2 : L1 > L2 and Comp1 >= Comp2
or L1 is dominated by L2 : l1 < l2 and Comp1 <= Comp2 or L1 = L2 : l1 = :2 and Comp1 = Comp2 or L1 and L2 are not comparable : L1 > L2 and L1 < L2 and L1 = L2 Ordering Among Labels ordering among labels defines a structure called a lattice: Partial Order L1 = (TS,{A,B,C}) L1 > L2?
L2 = (S, {A,B}) L2 < L1? L3 = (S, {B,C,C}) L1 and L3 are not compared Using labels for MAC:confidentiality Bell and La Padua or BLP Model(Developed by DoD) - Assumes classification of data(TS, S,C,U) and clearances for subjects Read/Write rules - User with Label L1 can read document with label L2 only when L1 dominates L2 read-down rule(simple security property) - User with label L1 can write document with label L2 when L1 dominated by L2 Write-up rule(star property) Preventing Information Flow with BLP

Discretionary Access Control
– In discretionary access control(DCA), owner of resource decides how it can be shared
– Owner can choose to give read or write access to other users

Discretionary Access Control
Two problems with DAC:
You cannot control if someone you share a file with will no further share the data contained in it
Cannot control “information flow”
In many organizations, a user does not get to decide how certain type of data can be shared
Typically the employer may mandate how to share various types of sensitive data
Mandatory Access Control(MAC) helps address these problems

Mandatory Access Control(MAC) Models
User works in a company and the company decides how data should be shared
Hospital owns patient records and limits their sharing
Regulatory requirements may limit sharing
HIPAA for health information

Military and intelligence agencies:
Data has associated classification level and users are cleared at various levels
– top secret, secret, confidential etc.
– Limits on who can access data at a certain level
User cleared only at secret level should not be able to access top secret data
– Also called multilevel security(MLS)

Where should an ACL be stored?
– In trusted part of the system
– Consists of access control entries, or, ACEs
– Along with other object meta-data
– For example, file meta-data has a bunch of information where this can go as well
– Checking requires traversal of the ACL

Where do C-list go?
– A capability is an unforgeable reference/handle for a resource
– User catalogue of capabilities defines what a certain user can access
– Can be stored in objects/resources themselves(Hydra)
– Sharing requires propagation of capabilities

Efficieny, Accountability, Revocation

Access Control Implementation
How is Access Control Implemented in Unix-like Systems?
– In Unix, each resource looks like a file
– Each file has an owner(UID) and access is possible for owner, group and everyone(world).
– Permissions are read, write and execute
– Original ACL implementation had a compact fixed size representation(9 bits)
– Now full ACL support is available in many variants(Linux, BSD, MacOS,..)
– Few other things(sticky bit, setuid,…)

Access Control Implementation
How are files used(system calls for accessing files?)
– Create(filename)/* several ways to do it */
– fd = open(filename, mode)
– read (fd, buf, sizeof(buf))
– write(fd, buf, sizeof(buf))
– close(fd)

List all processes and subjects in a matrix
A11 A12 A13 … A1n
A21 A22 A23 … A2n
A31 A32 A33 … A3n
.
.
Am1 Am2 Am3 … Amn
List each object in a column and row

Access control matrix is large
How do we represent it in the system?
Column for object Oi is [(ul1, right1),(ui2, right2),…]
called access control list or ACL
Associated with each resource
For user ui, a row in the matrix is [(oil1, righ1),(oi2,righs2)…]
Called a capability-list or C-list
such a C-list stored for each user

ACLs
x->[(A,rwx)]
y->[(A,r)(B,rw)(c,rw)]
z->[(B,rx)(C,rx)]

C-lists
A->[(X,rwx)(y,r)]
B->[(y,rw)(Z,rx)]
C->[(y,rw)(Z,rx)]

Controlling Accesses to Resources
– TCB(reference monitor) sees a request for a resource, how does it decide whether it should be granted?
– Example: Should John’s process making a request to read a certain file be allowed to do so?

– Authentication establishes the source of a request
– Authorization or access control answers the question if a certain source of request(User ID) is allowed to read the file
– Subject who owns a resource(creates it) should be able to control access to it

Access Control
Basically, it is about who is allowed to access what.
Two parts
– Decide who should have access to certain resources
– Enforcement – only accesses defined by the access control policy are granted
Complete mediation is essential for successful enforcement

An access control matrix(ACM) abstracts the state relevant to access control.
Rows of ACM correspond to users/subjects/groups
Columns correspond to resources that need to be protected.
ACM defines who can access what