K Anonymity (privacy through generalization and suppression).

Problem: Publishing private data while, at the same time, protecting individual privacy
Sanitization: Automated de-identification of private data with certain privacy guarantees Opposed to formal determination by statisticians requirement of
HIPAA.
Two major research directions 1. Perturbation (e.g. random noise addition) 2. Anonymization (e.g. k-anonymization)
Anonymization: 1.) Removing unique identifiers is not sufficient. 2.) Quasi-identifier (QI) Maximal set of attributes that could help identify individuals
Assumed to be publicly available (e.g., voter registration lists)
As a process
TOOLS
1. Remove all unique identifier
2. Identify QI-attributes, model adversarys background knowledge.
3. Enforce some privacy definition (e.g. k-anonymity)

Multiple k-minimal generalizations may exist E.g., [1,0] and [0,1] from the example
Precision metric indicates the generalization with minimal information loss, maximal
usefulness.

The L-Diversity and the T-closeness address the limitations of

k-anonymity.

Complementary release attack: different releases linked

together to compromise k-anonymity.

Homogeneity attack

Background Knowledge Attack

L-diversity principle: A q-block is l-diverse if contains at least L well represented
values for the sensitive attribute S. A table is l-diverse if every q-block is l-diverse.
Types of L-Diversity:

Distinct: Each equivalence class has at least l well-represented sensitive

values
Limitation: Doesnt prevent the probabilistic inference attacks Ex. In one
equivalent class, there are ten tuples. In the Disease area, one of them is Cancer,
one is Heart Disease and the remaining eight are Flu. This satisfies 3-diversity,
but the attacker can still affirm that the target persons disease is Flu with the
accuracy of 80%.

Entropy: Each equivalence class not only must have enough different
sensitive values, but also the different sensitive values must be distributed
evenly enough.
It means the entropy of the distribution of sensitive values in each equivalence class
is at least log(l)
Sometimes this maybe too restrictive. When some values are very common, the
entropy of the entire table may be very low. This leads to the less conservative notion of l-diversity.

Recursive (c,l) diversity: The most frequent value does not appear too frequently

Limitations of L- Diversity:

T Closeness: t-closeness requires that the distribution of a sensitive

attribute in any eq. class is close to the distribution of a sensitive
attribute in the overall table.

Privacy of Numeric Queries Via Simple Value Perturbation (The Laplace Mechanism): Differential Privacy

Basic Lower Bound: Blatant Non Privacy

How much noise needed to guarantee privacy?
A simple model

One-Time Password:
Problems: Syncing user / system, Distribution, & Generation of good random
passwords
One-time password scheme based on idea of Lamport using oneway MD5 or
SHA-1.
User chooses seed K, The key generator calculates: h(k) = k1, h(k1) = k2, ,
h(kn1) = kn
Passwords are in reverse order: p1 = kn, p2 = kn1, , pn1 = k2, pn = k1
Attacker gets pi , he would have invert the hash to get the next pi+1
Remember pi = kn-i+1 , pi+1 = kn-i, and h(kn-i) = kn-i+1, we have that h(pi+1) = pi

How one-time passwords work:

System stores maximum number of authentications n, number of next
authentication i, last correctly supplied password pi1. System computes h(pi)
= h(kni+1) = kni = pi1. If match with what is stored, system replaces pi1 with pi
and increments i.
Location: Needs special HW GPS or LSS (location signature sensor). You can
also combine them. Have multiple device for different roles (plug-in
authentication modules)
Summary:
Authentication is not cryptography You have to consider system
components
Passwords are here to stay They provide a basis for most forms of
authentication
Protocols are important They can make masquerading harder
Authentication methods can be combined

Cryptograph: Symmetrical

MAC: Message authentication involves hashing the message to produce a "digest," fingerprint and encrypting the digest with the private key to produce
a digital signature. Thereafter anyone can verify this signature by (1) computing the hash of the message, (2) decrypting the signature with the signer's public key,
and (3) comparing the computed digest with the decrypted digest. Remember Encryption doesnt protect against modification.
A hash is a many to one function so collision can happen.

HMAC: One might assume the same security that HMAC provides could be achieved with MAC = H(key message). However, this method suffers from a serious
flaw: with most hash functions, it is easy to append data to the message without knowing the key and obtain another valid MAC ("length-extension attack"). The
alternative, appending the key using MAC = H(message key), suffers from the problem that an attacker who can find a collision in the (unkeyed) hash function
has a collision in the MAC (as two messages m1 and m2 yielding the same hash will provide the same start condition to the hash function before the appended key
is hashed, hence the final hash will be the same). Using MAC = H(key message key) is better, but various security papers have suggested vulnerabilities with
this approach, even when two different keys are used.
No known extensions attacks have been found against the current HMAC specification which is defined as H(key H(key message)) because the outer
application of the hash function masks the intermediate result of the internal hash.
function hmac (key, message)
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
end if
if (length(key) < blocksize) then
key = key [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded (where is concatenation)
end if
o_key_pad = [0x5c * blocksize] key // Where blocksize is that of the underlying hash function
i_key_pad = [0x36 * blocksize] key // Where is exclusive or (XOR)
return hash(o_key_pad hash(i_key_pad message)) // Where is concatenation
end function

Asymmetrical

Digital Signatures

RSA

Access Control Distributed Systems SAML and XACML:

XML (eXtensible Markup Language) focuses on What data is not looks like. OASIS: SAML Framework for exchanging security information between online
business partners. Xml based provide several trusted mechanism (-identify Provider: systems or Domains that provide info about a subject. -Service provider that
relies on info from another supplier. It is up to the service provider to trust the data. However, the local access policy defines whether the subject is granted
access.)
DOM: Document Object Model Internal representation of an XML document as a tree Allows one to specify an element and all the data inside it as a subtree
Also allows one to specify a search pattern over the document (e.g. XPath)
SOAP: Simple Object Access Protocol SOAP provides the definition of the XML-based information which can be used for exchanging structured and typed
information between peers in a decentralized, distributed environment SOAP is a stateless, one-way message Extensible messaging framework Issues such as
security not part of specification, addressed as ext.

SAML Assertion Statement is the main element which is a package of information (-Authentication (verification) - Attribute: Specify - Authorization decisions)
Identity Provider (IdP): The system, or administrative domain, that asserts information about a subject. Service Provider (SP): The system, or administrative
domain, that relies on information supplied to it by the Identity Provider. It is up to the Service Provider as to whether it trusts the assertions provided to it.
Four main drivers Limitation of browser cookies Single Sign On (SSO) interoperability - Web services: WS security is still being defined - Federation: the
need to simplify identity management across organizational boundaries, allowing users to consolidate many local identities into a single federated identity
Sample SAML Assertion: <saml:Assertion MajorVersion=2" MinorVersion="0"AssertionID="128.9.167.32.12345678" Issuer="Company.com"
IssueInstant="2002-03-21T10:02:00Z"><saml:Conditions NotBefore="2002-03-21T10:02:00Z" NotAfter="2002-03-21T10:07:00Z" /> <saml:AuthnStatement
AuthenticationMethod="password" AuthenticationInstant="2002-03-21T10:02:00Z"> <saml:Subject> <saml:NameIdentifier SecurityDomain="Comany.com"
Name="joeuser" /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>
XACML: GOALS: Define a core XML schema for representing authorization and entitlement policies Target - any object - referenced using XML Fine access
control grained control Access control based on subject and object attributes Access control based on the object contents; if the object is not an XML
document, the object attributes can be used Consistent with and building upon SAML
XACML(Key Aspects): General-purpose authorization policy model and XML-based specification language XACML is independent of SAML specification
Triple-based policy syntax: <Object, Subject, Action> Negative authorization is supported Input/output to the XACML policy processor is clearly defined as
XACML context data structure Input data is referred by XACML-specific attribute designator as well as XPath expression Extension points: function,
identifier, data type, rule-combining algorithm, policy-combining algorithm, etc. A policy consists of multiple rules A set of policies is combined by a higher
level policy (PolicySet element)
XACML Protocol: When a client makes a resource request upon a server, the PEP is charged
with AC In order to enforce AC policies, the PEP will formalize the attributes describing the
requester at the PIP and delegate the authorization decision to the PDP Applicable policies are
located in a policy store, managed by the PAP, and evaluated at the PDP, which then returns the
authorization decision Using this information, the PEP can deliver the appropriate response to
the client. 1. The Policy Administration Point (PAP) creates security policies and stores these
policies in the appropriate repository. 2. The Policy Enforcement Point (PEP) performs access
control by making decision requests and enforcing authorization decisions. 3. The Policy
Information Point (PIP) serves as the source of attribute values, or the data required for policy
evaluation. 4. The Policy Decision Point (PDP) evaluates the applicable policy and renders an
authorization decision. Note: The PEP and PDP might both be contained within the same
application, or might be distributed across different servers.
XACML Request: Subject Object Action XACML Response Permit Permit with
Obligations Deny NotApplicable (the PDP cannot locate a policy whose target matches the
required resource) Indeterminate (an error occurred or some required value was missing)
Data Flow Model: 1. PAPs write policies and policy sets and make them available to the PDP.
These policies or policy sets represent the complete policy for a specified target 2. The access
requester sends a request for access to the PEP 3. The PEP sends the request for access to the
context handler in its native request format, optionally including attributes of the subjects,
resource, action and environment 4. The context handler constructs an XACML request
context and send it to the PDP 5. The PDP requests any additional subject, resource, action,
and environment attributes from the context handler 6. The context handler requests the
attributes from a PIP 7. The PIP obtains the requested attributes 8. The PIP returns the
requested attributes to the context handler 9. Optionally, the context handler includes the
resource in the context 10. The context handler sends the requested attributes and (optionally)
the resource to the PDP. The PDP evaluates the policy 11. The PDP returns the response
context (including the authorization decision) to the context handler 12. The context handler
translates the response context to the native response format of the PEP. The context handler
returns the response to the PEP 13. The PEP fulfills the obligations 14. If access is permitted,
then the PEP permits access to the resource; otherwise, it denies access.
XACML Schemas: Request Schema: Request (Subject, Resource, Action), Policy Schema:
PolicySet (Combining Alg) Policy* (Combining Alg) Rule* (Effect) Target Subject* Resource* Action* Environment Effect Condition Obligation*
Policies and PolicySet The key top-level element is the <PolicySet> which aggregates other <PolicySet> elements or <Policy> elements The <Policy> element is
composed principally of <Target>, <RuleSet> and <Obligation> elements and is evaluated at the PDP to yield and access decision. Since multiple policies may be
found applicable to an access decision, (and since a single policy can contain multiple Rules) Combining Algorithms are used to reconcile multiple outcomes into a
single decision The <Target> element is used to associate a requested resource with an applicable Policy. It contains conditions that the requesting Subject,
Resource, or Action must meet for a Policy Set, Policy, or Rule to be applicable to the resource. The Target includes a build-in scheme for efficient
indexing/lookup of Policies. Rules provide the conditions which test the relevant attributes within a Policy. Any number of Rule elements may be used each of
which generates a true or false outcome. Combining these outcomes yields a single decision for the Policy, which may be "Permit", "Deny", "Indeterminate", or a
"NotApplicable" decision.
Policies and Policy Sets: Policy Smallest element PDP can evaluate Contains: Description, Defaults, Target, Rules, Obligations, Rule Combining Algorithm
Policy Set Allows Policies and Policy Sets to be combined Use not required Contains: Description, Defaults, Target, Policies, Policy Sets, Policy References,
Policy Set References, Obligations, Policy Combining Algorithm Combining Algorithms: Deny-overrides, Permit-overrides, Firstapplicable, Only-one-applicable
Policy Element: <RuleSet ruleCombiningAlgId= DenyOverrides> <Rule ruleId=R1> ------- <Rule ruleId=R2> <Rule RuleId=R1 Effect=Permit>
<Target> <Resources> <Subjects> <Actions> <Condition>
Combining Algorithms: Policy & Rule Combining algorithms Permit Overrides: If a single rule permits a request, irrespective of the other rules, the result of the
PDP is Permit Deny Overrides: If a single rule denies a request, irrespective of the other rules, the result of the PDP is deny. First Applicable: The first applicable
rule that satisfies the request is the result of the PDP Only-one-applicable: If there are two rules with different effects for the same request, the result is
indeterminate.
Rules: Smallest unit of administration, cannot be evaluated alone > Elements Description documentation Target select applicable rules Condition
boolean decision function Effect either Permit or Deny Results If condition is true, return Effect value If not, return NotApplicable If error or
missing data return Indeterminate Plus status code.
Target: Designed to efficiently find the policies that apply to a request Makes it feasible to have very complex Conditions Attributes of Subjects, Resources
and Actions Matches against value, using match function Regular expression RFC822 (email) name X.500 name User defined Attributes specified by Id
or XPath expression Normally use Subject or Resource, not both
Rule Element: The main components of the <rule> element are: a <target> the <target> element consists of a set of <resource> elements a set of <action>
elements an environment the <target> element may be absent from a <rule>. In this case the <target> of the rule is the same as that of the parent <policy>
element an <effect> Two values are allowed: Permit and Deny a <condition>
Policy Element: The main components of a <policy> element are: a <target> element the <target> element consists of a set of <resource> elements a set of
<action> elements an environment the <target> element may be declared explicitly or may be calculated; two possible approaches: Make the union of all the

target elements in the inner rules Make the intersection of all the target elements in the inner rules a rule-combining algorithm-identifier a set of <rule>
elements obligations
PolicySet Element: The main components of a <policyset> element are: a <target> a policy-combining algorithm-identifier a set of <policy> elements
obligations.
A Policy Example The Policy applies to requests for the server called SampleServer The Policy has a Rule with a Target that requires an action of "login"
and a Condition that applies only if the Subject is trying to log in between 9am and 5pm. Note that this example can be extended to include other Rules for
different actions. If the first Rule does not apply, then a default Rule is used that always returns Deny (Rules are evaluated in order).
A Policy Example: <Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combiningalgorithm:permit-overrides"><!-This Policy only applies to requests on the SampleServer --><Target><Subjects> <AnySubject/> </Subjects> <Resources> <ResourceMatch
MatchId="urn:oasis:names:tc:xacml:1.0:function:stringequal"><AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">SampleServer
</AttributeValue> <ResourceAttributeDesignator DataType=http://www.w3.org/2001/XMLSchema#string
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/></ResourceMatch></Resources><Actions> <AnyAction/> </Actions></Target>
Condition: Boolean function to decide if Effect applies Inputs come from Request Context Values can be primitive, complex or bags Can be specified by id
or XPath expression Fourteen primitive types Rich array of typed functions defined Functions for dealing with bags Order of evaluation unspecified
Allowed to quit when result is known Side effects not permitted
Functions: Equality predicates Arithmetic functions String conversion functions Numeric type conversion functions Logical functions Arithmetic
comparison functions Date and time arithmetic functions Non-numeric comparison functions Bag functions Set functions Higher-order bag functions
Special match functions XPath-based functions Extension functions and primitive types
Request and Response Context: Request Context Attributes of: Subjects requester, intermediary, recipient, etc. Resource name, can be hierarchical
Resource Content specific to resource type, e.g. XML document Action e.g. Read Environment other, e.g. time of request Response Context Resource
ID Decision Status (error values) Obligations
SQL Injection:

SQL Injection: a) Browser sends malicious input to server b)

Bad input checking leads to malicious SQL query. Cross-site
request forgery Bad web site sends request to good web site,
using credentials of an innocent victim who visits site. XSS
a)Cross-site scripting Bad web site sends innocent victim a
script that steals information from an honest web site.
SQL Injection: Change meaning of database command. CSRF
Leverage users session at victim sever. XSS Inject
malicious script into trusted context.
Sample PHP: $recipient = $_POST[recipient];$sql =
"SELECT PersonID FROM Person WHERE
Username=$recipient";$rs = $db->executeQuery($sql);Problem: - What if recipient is malicious string that changes the meaning of the query?
Bad Input: Suppose user = or 1=1 - - (URL encoded) Then scripts does: ok = execute( SELECT ... WHERE user= or 1=1 - - ... ) The - - causes rest of line
to be ignored.Now ok.EOF is always false and login succeeds.The bad news: easy login to many sites this way.
Suppose user = ; DROP TABLE Users - - Then script does: ok = execute( SELECT ... WHERE user= ; DROP TABLE Users ... ) Deletes user table
Similarly: attacker can add users, reset pwds, etc.
Suppose user = ; exec cmdshell net user badguy badpwd / ADD - - Then script does: ok = execute( SELECT ... WHERE username= ; exec ... ) If SQL server
context runs as sa, attacker gets account on DB server SQL Injection Prevention: Use parameterized/prepared SQL - Use ORM framework
CSRF Recommendations: Login CSRF Strict Referer/Origin header validation Login forms typically submit over HTTPS, not blocked HTTPS sites, such as
banking sites Use strict Referer/Origin validation to prevent CSRF Other Use Ruby-on-Rails or other framework that implements secret token method correctly
Origin header Alternative to Referer with fewer privacy problems Send only on POST, send only necessary data Defense against redirect-based attacks
What is XSS? - An XSS vulnerability is present when an attacker can inject scripting code into pages generated by a web application -Methods for injecting
malicious code: Reflected XSS (type 1) the attack script is reflected back to the user as part of a page from the victim site Stored XSS (type 2) the attacker
stores the malicious code in a resource managed by the web application, such as a database Others, such as DOM-based attacks.
XSS Defense: Input data validation and filtering Never trust client-side data Best: allow only what you expect Remove/encode special characters Many encodings,
special chars! E.g., long (non-standard) UTF-8 encodings
XSS Defense: Output filtering / encoding Remove / encode (X)HTML special chars &lt; for <, &gt; for >, &quot for 00 ... Allow only safe commands (e.g., no
<script>...) Caution: filter evasion tricks See XSS Cheat Sheet for filter evasion E.g., if filter allows quoting (of <script> etc.), use malformed quoting: <IMG
><SCRIPT>alert(XSS)... Or: (long) UTF-8 encode, or... Caution: Scripts not only in <script>! Examples in a few slides
Client-side XSS defenses Proxy-based: analyze the HTTP traffic exchanged between users web browser and the target web server by scanning for special HTML
characters and encoding them before executing the page on the users web browser Application-level firewall: analyze browsed HTML pages for hyperlinks that
might lead to leakage of sensitive information and stop bad requests using a set of connection rules. Auditing system: monitor execution of JavaScript code and
compare the operations against high-level policies to detect malicious behavior.
SQL Injection: Bad input checking allows malicious SQL query Known defenses address problem effectively CSRF Cross-site request forgery Forged request
leveraging ongoing session Can be prevented (if XSS problems fixed) XSS Cross-site scripting Problem stems from echoing untrusted input Difficult to prevent;
requires care, testing, tools,
Defenses: Web Application Firewalls Help prevent some attacks we discuss today: Cross site scripting SQL Injection Form field tampering Cookie poisoning
Sample products: Imperva Kavado Interdo F5 TrafficShield Citrix NetScaler CheckPoint Web Intel.
Defenses: Code checking Blackbox security testing services: Whitehatsec.com Automated blackbox testing tools: Cenzic, Hailstorm Spidynamic, WebInspect
eEye, Retina Web application hardening tools: WebSSARI [WWW04] : based on information flow Nguyen-Tuong [IFIP05] : based on tainting
Privacy Preserving Distributed Data Mining: (PPDDM)
Individual Privacy - Nobody should know more about any individual after the data mining than they did before. Organization Privacy - Protect knowledge about
a collection of entities.
Privacy Constraints dont prevent Data mining, the problem is calculating the result without disclosing the entities! Goal of data mining is summary results
(Association rules, Classification, Clusters). The results alone need not violate privacy (contain no individually identifiable value, Reflect overall results, not
individual organizations). Partial results may need to be kept private. Why? => Data needed for data mining maybe distributed among parties e. Credit Card
Fraud data. Inability to share data due to HIPPAA. Even partial results may need to be kept private.

Secure Multi-Party Computation (SMC) The goal is computing a function f(x1,x2,.xn) without revealing xi - Semi-Honest Model (Parties follow the protocol) &
Malicious Model (Parties may or may not follow the protocol). We cannot do better then the existence of the third trusted party situation
Generic SMC is too inefficient for PPDDM.

In general, PPDDM protocols depend on few common sub-protocols that can be re-used.

Economics of Information Security:

Misaligned incentives could be a significant problem in Information Security which requires aligning carefully the
design with the incentives. Ex. UK banks vs US banks
Interdependences/Externalities - If more people have cell phones, than texting
Weakest Link - Program Security may depend on the weakest programmer
Sum of efforts Program testing may depend on all of the programmers efforts
Strongest Link - Efforts of whistleblower?
Lemon Market - Dishonest dealings may drive out honest dealings.
Unless we could differentiate between good data privacy versus bad data privacy than bad companies will drive out
good ones. More transparency is needed.
Certificates for Security can cause adverse selection problems According to one study, %3 of regular web sites and %8 of certified web sites are malicious
Counteracting Institutions *Warranties and guarantees - Sellers try to send signals about the quality of the goods. *Brand Names / Trusted Vendors * Chains How many of you chosen a restaurant chain during business trips? *Certification - Licensing of doctors and lawyers
Degrees (e.g., PhD in CS signals your expected quality.)
Implications of Lemon Markets for Information Security Develop approaches to measure software security *Vulnerability markets. Open markets for trading
vulnerability information? (You may gain more by selling to bad guys.) Two contracts for software payment. - First contract for if there is no vulnerability found
in some certain time period - Second contract for if there is some vulnerability found Trade such contracts in the market. Insurance, Hard to apply in information
security due to large scale interdependencies.
Digital Rights Management and Incentives DRM helps the system vendors more than the music industry- Apple is the dominant force for DRM and music
industry.
Economics of Privacy* In many cases, users do not have any incentive in privacy technologies due to lemon market effect and Cost of privacy lost is very little in
many domains. Using credit card reveals all your purchase history. Only exception could be health care where cost of privacy violation could be significant
(Revealing the fact that a patient is HIV positive)*: Professors thoughts.
Access Control:

SUBJECT

ACCESS REQUEST

REFERENCE MONITOR

OBJECT

The very nature of access control suggests that there is an active subject requiring access to a passive
object to perform some specific access operation.
A reference monitor grants or denies access
This fundamental and simple notion of access control is due to Lampson.
Subjects can be classified into:

users -- single individuals connecting to the system

groups -- sets of users

roles -- named collections of privileges / functional entities within the organization

processes -- executing programs on behalf of users

Operations that a subject can exercise on the protected objects in the system are called access modes. Eg. (read) -look at the contents of an object. (write) - change the
contents of an object.

Types of Access Controls:

In one, access control is left to the discretion of the owner (DAC): 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). Identity is the key. The owner states the constraint in terms of
the identity of the subject, or the owner of the subject.
Advtg: flexibility in policy specification and supported by all os & dbms
Dis-Advtg: no info flow control (Trojan horses)
In the other, the operating system controls access, and the owner cannot override the controls (MAC): based on fiat, and identity is irrelevant. 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 rulebased access control.
THE BELL - LAPADULA MODEL:
Corresponds to military-style classifications.
Set of security clearances arranged in a linear (total) ordering (TS > S > C > UC).
The goal of the Bell-LaPadula security model is to prevent read access to objects at a security classification higher than the subject's clearance.
Each security level and category form a security level. Category set is area of operation. {NUC, EUR, US}
Dominate: The security level (L, C) dominates the security level (L', C') if and only if L' L and C' C. (L, C) dom (L, C). We write (L, C) dom (L', C') when
(L, C) dom (L', C') is false. Strictly dominates is when L > L. Incomparable when both conditions dont hold.
Two conditions to BLP:
1. Simple security condition: S can read O if and only if S dom O and S has discretionary read access to O.
The simple security property prevents subjects from reading data with access classes dominating or incomparable with respect with the subject access class.
2. *-Property: S can write to O if and only if O dom S and S has discretionary write access to O.
The *-property has been defined to prevent information flow into objects with lower-level access classes or incomparable classes.
The simple security condition is often described as no reads up and the *-property as no writes down.
The model provides a mechanism for allowing this type of communication. A subject has a maximum security level and a current security level. The maximum
security level must dominate the current security level. A subject may (effectively) decrease its security level from the maximum in order to communicate with
entities at lower security levels.
Example: The Data General B2 UNIX System (Admin area, user area, virus protection area).
BLP only deals with confidentiality and not integrity. Also, it contains covert channels.
CHINESE WALL POLICY:
Was introduced by Brewer and Nash. (hence called BN)
Dynamically establishes access rights based on what the user has already accessed.
Subjects: users seeing access rights. Object: data arranged on the order >> (information, dataset, Conflict of Interest). Access rule: read & write.
Read Rule: A subject S can read object O if:

O is in the same Dataset as an object already accessed by S. OR

O belongs to a COI from which S has not yet accessed any information.

CWP = combination of free choice and mandatory control.

Initially free to access. Once accessed, builds a Chinese wall around the data set for the user

Read does not avoid indirect data flow. X: a, b. Y: c, b. if X writes to b (data of a to b) Y can read data of a from b (not supposed to happen).
Write Rule: A subject S can write an object O if:

S can read O according to the Read Rule. AND

No object has been read by S which is in a different company dataset to the one on which write is performed.

CWP ensures that the flow of information is confined to its own company dataset.

This is restrictive, so, use sanitization to disguise the companys information to mask their identity.
ROLE BASED ACCESS CONTROL (RBAC):
In case of a large system, providing access to each and every user is difficult. Instead, create roles and provide access to roles.
Attach the roles to the users as and when required.
Granting and revoking of user authorizations is greatly simplified.
RBAC models have been shown to be policy-neutral.
Types of RBAC:
Core RBAC or Flat RBAC
Hierarchical RBAC
Constrained RBAC
Core RBAC:
(Permissions = Operations on Objects)
Basics:
USERS, ROLES, OPS, and OBS.
UA USERS X ROLES
assigned_users: (r: ROLES) -> 2USERS
assigned_users(r) = {u USERS | (u, r) UA}

PRMS = 2(OPS X OBS) , the set of permissions

PA PRMS X ROLES,
assigned_permissions: (r: ROLES) -> 2PRMS
assigned_permissions(r) = {p PRMS | (p, r) PA}

Hierarchical RBAC:
Structuring roles to reflect an organizations line of authority and responsibility.
RH ROLES X ROLES
It has to be irreflexive and acyclic : dominance relation
SEMANTICS:
i. User Inheritance (UI): user authorized for r is also authorized for r where r r.
ii. Permission Inheritance (PI): A role r is authorized for all permissions for which
iii.

any role r, such that r r, is authorized

Activation Inheritance (AI): Activating a role r automatically activates all roles r.

Constrained RBAC: RBAC with capability of supporting Separation of Duty (SoD).

What is SoD?? >> ANSI: Dividing responsibility for sensitive information so that no individual acting alone can compromise the security of the data processing
system.
Two Types: STATIC SoD and DYNAMIC SoD
SSoD Constraints

DSoD Constraints

INTEGRITY POLICIES:

The state and the correctness of the data should

be maintained.

Lipner [1982] requirements suggest several

principles: Separation of Duty, Separation of Function and
Audit.
Two types of integrity models discussed:
i. Biba Model
ii. Clark Wilson Model
BIBA MODEL:

Associates integrity levels with object and

subjects.

Clean higher levels and dirty lower levels.

Information flows down in the integrity lattice.

higher the level, more confidence that,

o Program will execute correctly
o The information is reliable.
o Integrity levels are NOT security levels.

CLARK WILSON INTEGRITY MODEL:

Based on two important principles:
o
Separation of Duty
o
Well formed transactions: data
items can be modified only by a set
of authorized transactions. Moves
relation from one valid state to
another.
This approach relies on application level
controls.
Example : Integrity constraint: D + YB
W
Certification and Enforcement Rules:
Certification rule 1 (CR1): IVP ensure that all CDIs are in a valid state.
Certification rule 2 (CR2): For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state. TP may
corrupt CDIs if TP were not certified to work on the portfolio.
Enforcement rule 1 (ER1): The system must maintain the certified relations, and must ensure that only TPs certified to run on a CDI manipulate that CDI.
TP f operates on a CDI o, then (f, o) C.
Enforcement rule 2 (ER2): The system must associate a user with each TP and set of CDIs. The TP may only access those CDIs on behalf of the
associated user. triples (user, TP, { CDI set }) to capture the association.
Certification rule 3 (CR3): The allowed relations must meet the requirements imposed by the principle of separation of duty.
Enforcement rule 3 (ER3): The system must authenticate each user attempting to execute a TP but not to log in (can change UDI w/o authentication). Log
= CDI where TP only append.
Certification rule 4 (CR4): All TPs must append enough information to reconstruct the operation to an append-only CDI. Record all transaction (User
UDI => teller CDI).
Certification rule 5 (CR5): Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the
UDI. The transformation either rejects the UDI or transforms it into a CDI.
Enforcement rule 4 (ER4): Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an entity associated
with that TP, may ever have execute permission with respect to that entity.
Comparison with other models:

Biba is based on multilevel integrity

CW is based on separation of duty and transactions.

DATABASE SECURITY:

All Commercial Systems use the DAC model. Currently uses the System R model. .

System R Authorization Model:

o
To be protected: Objects >> Tables and views
o
Privileges: SELECT, UPDATE, INSERT, DELETE, DROP (for tables and views), and
ALTER AND INDEX (for tables).
o
Groups are supported but roles are not.
o
Privileges can be given by GRANT OPTION.
o
GRANT OPTION: can be given to whole relation or view. For UPDATE the column should
be specified.
GRANT PrivilegeList| ALL[PRIVILEGES]
ON Relation | View
TO UserList | PUBLIC
[WITH GRANT OPTION]
The authorization catalogs keep track for each users of the privileges the user possesses and of the ones that the user can delegate

Whenever a user u executes a Grant operation, the system intersects the delegable privileges of u with the set of privileges specified in the command
if the intersection is empty, the command is not executed.
Ann has SELECT with GRANT and INSERT on the Employee table.
o
Ann: GRANT select, insert ON Employee TO Tim; this statement is partially executed.
REVOKE OPERATION:

REVOKE PrivilegeList| ALL[PRIVILEGES]

ON Relation | View

FROM UserList | PUBLIC

A user can only revoke the privileges he/she has granted; it is not possible to only revoke the grant option.
Recursive revocation: whenever a user revokes an authorization on a table from another user, all the authorizations that the revokee had granted because of the
revoked authorization are removed
The revocation is iteratively applied to all the subjects that received the access authorization from the revokee.
G1,, Gn be a sequence of grant operations with a single privilege on the same relations, such that i,k = 1,., n, if i<k, then Gi is executed before Gk.

Types:
Recursive revocation (with time stamp)
Recursive revocation without Time stamp
Non-cascading Revoke
Recursive revoke
(with time stamp):
-takes into account the
time stamps denoting
when the authorization
was provided.
-Variations without
timestamps have been
proposed to avoid
cascading.

Recursive revoke without time

stamp:

Non-Cascading Revoke :
-Recursive can be disruptive.
-The non-cascading revoke allows a user to revoke a
privilege on a table from another user without
entailing automatic revocation of the authorizations
for the privilege on the table the latter may have
granted.
-Instead of deleting the authorizations the revoke may
have granted by using the privilege received by the
revoker, all these authorizations are restated as if
they had been granted by the revoker,
-The semantics of the revocation without cascade of
privilege p on table t from user y by user x is:
To restate with x as grantor all authorizations that y
granted by using the authorization being revoked.

Views and Content-Based Authorization:

Define a view containing the predicates to select the tuples to be returned to a
given subject S
2. Grant S the select privilege on the view, and not on the underlying table
Example : CREATE VIEW Vemp AS
SELECT * FROM Employee
WHERE Salary < 20000;
GRANT Select ON Vemp TO Ann;
3. The view composition operation combines in AND the predicates specified
in the query on the view with the predicates which are part of the view definition
Ann: SELECT * FROM Vemp
WHERE Job = Programmer;
Query after view composition:
SELECT * FROM Employee
WHERE Salary < 20000 AND
Job = Programmer;
4. Steps in Query Processing :
Parsing
Catalog lookup
Authorization checking
View Composition
Query optimization

1.

Authorizations on Views:
User creating a view : View Definer
Definer gets the privileges that he has on the base-table on the views.
Also on view semantics.
Operations that cannot be performed on a view is not given as a privilege to the
definer. Eg: alter and index.
Bob: GRANT Select, Insert, Update ON Employee to Tim;
Tim: CREATE VIEW V1 AS SELECT Emp#, Salary FROM Employee;
Tim: CREATE VIEW V2 (Emp#, Annual_Salary) AS SELECT Emp#,
Salary*12 FROM Employee;
Tim can exercise on V1 all privileges he has on relation Employee, that is,
Select, Insert, Update
By contrast, Tim can exercise on V2 only the privileges of Select and Update on
column Emp#;
Most of the commercial DBMSs also support RBAC features (Informix, Sybase,
Oracle). However, in most cases they only supports flat RBAC.
CREATE ROLE role-name IDENTIFIED BY
password |NOT IDENTIFIED;
DROP ROLE role-name;
Example:
CREATE ROLE teller IDENTIFIED BY cashflow;
GRANT teller TO Bob;
GRANT select ON Employee TO teller;
SET ROLE teller IDENTIFIED by cashflow;
SET ROLE ALL [EXCEPT role-name]; it can only be used for roles not requiring
passwords
SET ROLE ALL; SET ROLE ALL EXCEPT banker;
SET ROLE NONE; It disables roles for the current session (*MLR)

AUTHENTICATION:
Reasons for authenticating users:
o The user identity is a parameter in access control decisions
o The user identity is recorded when logging security-relevant events in the audit trail
User has to enter:
User name this step is called identification
Password this step is called authentication (process of verifying a claimed identity)

Authentication System:
(A, C, F, L, S)
A : information that proves identity
C : information stored on computer and used to validate authentication
information
F : complementation function f : A C
L : functions that prove identity
S : functions enabling entity to create, alter information in A or C

Authentication process:
Obtaining the authentication information from an entity
Analyzing the data
Determining if the authentication information is associated with
that entity

Passwords:
Sequence of characters
Examples: 10 digits, a string of letters, etc.
Generated randomly, by user, by computer with user input
Sequence of words
Examples: pass-phrases
Note: A pass-phrase is a sequence of characters that it is too long to be a password
and it is thus turned into a shorter virtual password by the password system.
Algorithms
Examples: challenge-response, one-time passwords