http://csiweb.ucd.ie/staff/acater/comp30150.html security & integrity information maintained in...

http://csiweb.ucd.ie/staff/acater/comp30150.html

Security & Integrity

Information maintained in a DBMS is often used both in day-to-day operation of an enterprise, and in management support: forecasting, budgeting, financial control.

This information is a very valuable resource for an enterprise, and must be protected.

Threats are of three basic types:– Loss of availability / Denial of service

– Loss of reliability / Corruption of data

– Loss of confidentiality / Snooping


• Security: concerned with protection of database against unauthorised disclosure, alteration, or destruction; granting access to confidential information for authorised users only. Some info can be so crucial that its loss could ruin an enterprise.

• Integrity: concerned with preserving the consistency and the accuracy of data; protecting against both malicious and accidental interference even by authorised users. (Recovery techniques and Concurrency Control may be seen as ways of defending database integrity)


Examples of sensitive data:

Financial Banks Customer accountsCredit reference Credit ratings

Medical Hospitals, clinics Patient data

Military Army, Navy etc Secret weaponsForce deployments

Commercial Retail sales Mailing listsDistribution Selling strategies

Industrial Manufacturing ProcessesNew product plans


How much should one invest in security and integrity?

It can be difficult to quantify the value of information. Often it does have a clear economic value; but in a hospital, data corruption in the DBMS might lead to patients receiving the wrong treatment, or none at all.

Another important consideration is privacy of individuals:

many countries now have privacy laws; these may require that information be used only for that purpose for which it was collected, and that it be accurate.


Kinds of misuse of Computer Systems:

• theft of money eg EFT

• theft of goods managed by computer

• access to proprietary information such as trade secrets

• access to sensitive information, for blackmail, for espionage, for terrorism

• harmful/illegal revelation of personal data

• theft of computer services

• theft of computer software

• long-term or short-term denial of service (by virus, worm)

(Only the last 3 unique to computer systems)


DBMS security, integrity

DBMS give rise to different problems than general systems, problems which are therefore amenable to different solutions.• DBMS have many different users• DBMS store many kinds of information

Data is shared, hence need to restrict users to those portions of database that are required for their legitimate activities, and need to control the changes that users can make.

When data is changed, in a DBMS the old data is lost; hence need for a recovery mechanism.

Because data is shared, concurrency control is needed to maintain integrity.


Some security issues are external to DBMS:

•operating system & hardware - vulnerabilities, security mechanisms

•physical controls - locked rooms & terminals, guards at doors

•fireproof safes for backups

•policy questions:– how to decide who sees what?

– what about hiring and using and trusting computer staff?

•legal/social/ethical issues:– perhaps the public has a legal right to see certain data


Some terminology exists: (page 1 of 5)

Information security: protection of information against unauthorised disclosure, alteration, destruction.

Database security: protection of information maintained in a database.

Protection: refers to techniques that control the access of executing programs to stored information; includes hardware and OS features. [All access to computerised data must be by program].

[Printouts thrown in bins, forensic scans of disks, are beyond scope]


Terminology 2/5

Auditing: examination of information by persons other than those who produced it, often a considerable time after it was created or modified, focusing on what was done and by whom.

Privacy: all legal and ethical aspects of personal data systems (systems containing information about individuals). Individuals usually have a legal right to some control over information maintained about them.

Authorisation: the specification of rules about who has what type of access to what information. An “authoriser” writes “access rules”.


Terminology 3/5

Access control: ensuring that information is accessed only in authorised ways.

Information transfer to program is permitted subject to access rules.

DB Program

Access rules


Terminology 4/5

Intentional resolution: when rules aim also to control actions on data once legally accessed.

System limits the user program actions.

Information flow control: prevention of security leaks as information flows through the system.

DB Program

Access rules


Terminology 5/5

Integrity: consistency, reasonableness, correctness of data

Integrity subsystem: the mechanisms that help ensure integrity of data

System integrity: ability of system to function according to specification even in the face of “hacking”.

Semantic integrity: concerned with the correctness, especially the internal consistency, of the data in the database in the presence of user updates. Data model may impose specific integrity constraints. Concurrency control & recovery mechanisms are significant here.


Relationship between security & integrity:

User

information

modification

security violation

(unauthorised modification)

no security violation

(authorised modification)

no modification

possible

correct (doesn't

usually exist)

inadvertently

incorrect

maliciously

incorrect

correct

integrity violation

no integrity violation

attempted


Privacy requirements

Decision making is increasingly based on impersonal recorded information rather than on personal knowledge.

What is privacy - the right to be let alone?

Information privacy has been defined as

“… the claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others.”


The concept of “administrative secrecy” is related, and is usually covered by much more powerful legislation: e.g. the British Official Secrets Act makes it an imprisonable crime for a government servant to reveal official information.

Different legislatures take different approaches to privacy legislation.


USA

Fair Credit Reporting Act

- affects private sector information systems

- obliges credit bureaux to allow customers of credit institutions to review their own files

It is a law tailored to one specific industry. Other specific laws cover other industries.


USA

Code of Fair Information Practices

- for health, education & welfare depts

- no secret systems

- individuals can find out what info is kept and how it is used

- individuals may correct info

- info collected for one purpose is not to be used for any other without consent

- an organisation maintaining personal information must guarantee its reliability and must take precautions against its misuse

Last stipulation is very important for DBMS.


USA Privacy Protection Study Commission opted for laws tailored to specific private sector industries rather than using same provisions as for public sector (which is the approach taken in Europe). It recommended 3 basic objectives:

minimise intrusiveness:

• individuals must be informed about any record-keeping taking place

• some info not collected at all

• limit methods of collection


-maximise fairness:

-• subject should be able to see records, correct errors, & (refuse to) authorise disclosure

-• fairness implies integrity must be maintained

establish obligations about using and disclosing personal data

Laws passed in 1978-79 embody some of its recommendations.


Europe

Swedish Data Act (1973) was the first national privacy law anywhere. It requires record-keeping systems to be licensed by, and inspected by, a board which may issue directives for the system.

Germany, Denmark, Norway, France followed with similar laws. France's law additionally requires purging of obsolete information.


European 1981 Convention for the Protection of Individuals with regard to the automatic processing of personal data, led in time to Britain’s Data Protection Act (1984) Ireland's Data Protection Act (1988)

These two similar laws protect "personal data" - data relating to living individuals; they apply only to computer-based records; they exempt those using records solely for accounting, pay, or pension purposes.

They establish- a data protection registrar (commissioner) of personal data users & computer bureaux, who has powers to ensure that data is used according to the data protection principles.- appeals tribunal for data users- right of access for data subjects- right to compensation


UK & Ireland: Obligations for data users

- must register

- • describing personal data to be used and its purpose

• source of data

• persons to whom it will be disclosed

• places to which it will be transferred

• addresses for requests from data subjects

- after registration, must not process data except as specified

- must not transfer out of the country (UK, Ireland) except as specified

- must allow subjects access to data about them (maybe with a fee)

- may not allow anyone access to data about anyone else who has not consented to this. Can even refuse a person access to his own data if this involves revealing someone else’s.


Registrar (commissioner) may prosecute for breach, and may seize data (subject to various conditions)

Appeal may be made to Data Protection Tribunal (Circuit Court).

Various principles for data protection, not just for personal data. Eg:• data held only for clearly defined purpose

• data should be minimum necessary for job

• all data as accurate as possible

• data held only as long as necessary

• access restricted to authorised users


Data Protection Acts lay down 8 principles for data users:1. personal data information must be both obtained and processed

fairly and lawfully2. p. data should be held only for the specified lawful purposes3. p. data shall not be used or disclosed for any purpose other than

those specified4. p. data should be adequate, relevant, and not excessive for its

purpose to the system5. p. data should be accurate and up-to-date where necessary6. p. data should be kept no longer than necessary for required purpose7. individual is entitled to

a) without undue cost or delay,be informed if data is held,and be given access to it

b) have it corrected or erased


Eighth principle applies also to bureaux, not just data users, and was the most far-reaching from computer community viewpoint:

8. all who run computer systems dealing with p. data, whatever the size of the system, are to adopt security measures against

• unauthorised access

• unauthorised alteration/destruction

• unauthorised disclosure

• accidental loss/destruction

The essence of the law: data must be true and must be fairly processed.


Some privacy issues

Electronic Funds Transfer (EFT)

EFT systems automatically process deposits, withdrawals, and transfers of money: eg Pass, Paypath, Banklink, Direct Debits, Debit/Credit cards.

Expansion of EFT allows more details to be recorded and to be easy to retrieve; could be used e.g. to trace an individual’s movements or e.g. to classify for direct advertising purposes. (Like Tesco, Dunnes …)

Transborder Data Flow (TDF)

Data can pass across international borders via networks: rogue permissive economies?


Universal Identifiers

Social Security number; Citizen Number?

Great concern about the use of “universal identifier” to link personal records maintained in many different databases - making it easy for “Big Brother”; also dehumanising effect - eg if computer grades exams, sends results, and sends success/failure letters to job applicants.

US Privacy Commission recommended that steps be taken to prevent “Universal Labels”.


Security Threats & Defences

Additional reference:

Database Security, Castano, Fugini, Martella & Samarati

Addison-Wesley, 1995

Threats, malicious or accidental:

• Malicious attack: exploit system loopholes; abuse privileged position; use another’s password; etc...

• Accident: hardware/software failure; natural disaster (fire, flood,...)


DATABASE

ACCESS

RULES

DATABASE

Unauthorized access

Copying

Theft

PROCESSOR

HARDWARE

Failure of protection mechanisms

Contribution to software failure

SYSTEMS SOFTWARE

Failure of protection mechanisms

Information Leakage

Radiation

SYSTEMS PROGRAMMER

Bypass of security mechanisms

Disabling of security mechanisms

Installation of insecure system

Crosstalk

Tap

APPLICATION PROGRAMMER

Programming of applications

to behave contrary to

specification

Location in insecure

environment

TERMINAL USER

Fraudulent identification

Illegal leakage of authorized

information

Incorrect input

AUTHORIZER

Incorrect specification

of security policy

OPERATOR

Duplication of confidential reports

Loading of insecure system

Theft of confidential material

EXTERNAL ENVIRONMENT

Natural disasters

Malicious attacks

Unauthorized access to computer room


Security Procedures & Mechanisms - 1

DBMS security - weakest link amongst human, software, and hardware measures. Wide range of protective measures must be adopted.

• external:– security clearance of personnel– security policy formulation– measures to protect passwords– control over programming– auditing

• data storage– backup copies– replication– encryption


Security Procedures & Mechanisms - 2

• communication lines and physical environment– prevent electronic eavesdropping– secure areas for equipment & files– radiation shielding

• software– user identification & authentication– access control– recording audit trail

• hardware– memory protection– states of privilege


Confinement problem: while program legitimately conveys information to lawful user, it might also be conveying it to an unauthorised person, using legitimate or covert channels.

e.g. using a file intended to pass info - legitimate channel

e.g. using a file not intended to pass out info, or some coding scheme - covert channel.


Verification methods might be used to show that a program meets security requirements; but this may be too difficult.

It would be nice to verify those parts of the security system that check accesses of untrusted programs: beats Trojan Horse attack where flaw is deliberately left in security system.

Security Kernel approach

Some limited portion of the software contains all the basic security mechanisms; only the kernel needs to be verified.


Costs & Benefits of security

• Software costs:– lower performance– greater complexity– loss of flexibility

• Human costs:– must administer system– must maintain system

• Hardware costs:– may need special hardware, eg badge readers– may need bigger & better computers to offset performance hit

• Startup cost & Operational cost:– Finance– (privacy legislation has major cost implications for data users; this was a

cause of much opposition to the legislation.).


Costs & Benefits of security

• Protection benefit: against security losses, e.g.– trade secret loss, – military loss,– privacy loss.

• Reliability benefit– security may lead to more discipline and so maybe more reliability.


Security Evaluation Guidelines

• Completeness: depends on sensitivity of data• Confidence: will it do the job? No proof.• System flexibility: different policies possible - the law may change• Ease of administration• Flexibility for users: should not overburden users - user transparency• Tamperproofness: security system itself protected• Low processing overhead• Low operating costs: hardware, software, salaries

These factors have to be balanced for a particular enterprise in its particular environment.


Overview of DBMS security

Authentication follows identification and is a way to verify the identity of a user at log-on time. Fundamental to good security. Use of passwords is very common, also badges & physical characteristics (retina scan; voiceprint; handprint; etc)

Authorisation for each transaction is checked by system.

Access rules control access to system objects {= data, programs}.

DBMS checks authorisation, maintains integrity, synchronises concurrent transactions, looks after logging for security and recovery purposes.


Policies for DBMS security

“Security policy” = guidelines concerning security of information.

Implemented by security mechanisms (hardware, software, administration)

Different policies for different enterprises - may have legal aspects.

• A given policy should not be built into a mechanism because as changes come about you may want to, or be obliged to, change policies.

• Some general-purpose mechanisms do allow a number of policies to be used (e.g. access rules)

• But special purpose mechanisms may be simpler to implement and may perform better because they can be tailored to a given system.

• Trade-off situation: penny-wise pound-foolish.


DBMS policy issues

•centralised vs. decentralised authorisation?

– will you have a single authoriser for the entire system, or different authorisers for different parts. (Not just an issue in distributed DB)

•ownership vs. administration functions

– is data owner (creator of data, if one exists) responsible for authorisation, or is there a separate administrator who defines & controls its use?

• owner has full access to the data;

• administrator merely controls access rights.

– (As in O.S., administrator can give himself full access - this is a problem. Who guards the guardians?)


Access Control Specification policies

• “need to know” policy

– restrict information to those who must have it. Also called “policy of least privilege” because users and programs operate with the minimal set of privileges necessary.

• “maximised sharing” policy

– make the most of the data in a database, as eg in a library. May still have restrictions.

• Open systems - allow access to data unless explicitly forbidden,

• Closed systems - allow access to data only if explicitly authorised

Closed systems are more safe (eg if an access rule is forgotten or destroyed), and are thus a basic requirement for a need-to-know policy.


• “Name-dependent access control”– Demands ability to restrict access to finest granularity of DBMS,

e.g. “salary” attribute of Person relation. An Access Rule names the attributes that can be accessed.

– Also called “content-independent access control” because the access rules do not use data values in making access decisions.

• “Content dependent access control”– Extends policy of least privilege further than name-dependent

access control. Rules refer to data values in DBMS, eg manager may see the salary field of records of employees managed by himself.


Access types

Degree of control over data is increased by having possibly different rules governing different types of access: read, write, update, delete, insert, etc.

In an office setting e.g.,– Manager may have all rights over all fields of employee records;– Mail room has only read access, and only to “name” & “dept”

fields.

Generally, each user has the minimum access rights required.

Implementation (use by authoriser) is simplified if access rights are partially ordered: e.g. update ---> read


Contrast with Functional Access Rights

For a statistical database, e.g. census data, one requires the ability to do “count” “average” and “sum” functions, but one wants to prohibit queries that allow inferences about individuals.

So-called “tracker queries” masquerade as statistical enquires but actually find information about an individual.

eg select sum (salary)where firstname like “A*” and lastname like “C*” and

school = “CSI”•(virtually?) impossible in practice to prevent construction of sets of queries designed to reveal information about an individual.•So, add noise?•Or, place upper & lower bounds on number of items in an aggregate


Context Dependent Control

Access Rules refer to combinations of items that are impermissible

May for example disallow queries that combine "name" and "salary", while permitting separate access to the two fields.

But this is not really adequate to prevent extracting information about forbidden combinations of items, e.g. names & salaries, because it might be possible to draw inferences from the results of separate queries: e.g.

q1: names and projects

q2: projects and salaries

Hence, goal of History Dependent Control

• To take account of the context of past and current requests.


Policies to control information flow

Previously mentioned policies control access to data, but not the use of data once accessed; they assumed "Discretionary Access Control", where the authoriser grants access rights to users.

In a "Compartmentalisation Policy" (also known as "non-discretionary access control"), data belonging to one user compartment cannot be accessed by users assigned to other compartments.

This can be extended to Multi Level Control where, besides having compartments, information is classified according to sensitivity:

Unclassified; Confidential; Secret; Top secret


Users, and data, are assigned a security level.

Security level is defined as a classification + a set of categories (Army, Navy, Air Force)

A User access is allowed iff

user security level >= data security level.

Level A >= Level B iff

classification(A) >= classification(B) and

categories(B) categories(A)

( meaning is subset of )


Relation of policies supporting least privilege:

Enforcement of security policies embraces• Detection of breaches and attempted breaches (auditing of log)• Prevention of breaches

need to know

nondiscretionary access control

security compartmen

ts

security levels

discretionary access control

name dependent

content dependent

context dependent

statistical queries

multilevel control history

dependent


Security Models

Basic model using access matrix, from O.S. work originally by Lampson, Graham, Denning.

Model has 3 components:

•set of objects– objects are entities known to system which must be protected: eg memory,

files, processes

•set of subjects– subjects are entities (e.g. processes) requesting access to objects

– Subjects are objects too

•set of rules defining types of access a subject has for an object– e.g. read, write, execute,confer privilege


The set of all rules (conceptually) forms an Access Matrix [A], where•columns represent objects (O1..On),•rows represent subjects (S1..Sm),•an entry A[Si,Oj] contains a list of access types t1,t2,... specifying access privileges of subject Si to object Oj.

The list of objects that a subject may access, together with the access types, is termed a “Capability List”.

The list of subjects that may access an object, together with the access types, is termed an “Access Control List”.


This model treats the security of system objects in a uniform way and so one could consider DBMS security as a mere extension of OS security, allowing database objects in the access matrix: then OS would handle all security. But there are OS/DBMS differences:•Many more DBMS objects•DBMS security may involve levels of granularity - record, field•OS protects “real” resources, DBMS has complex “logical” resources

OS would become too complex: better to do DBMS security separately, and develop a separate model for DBMS.

Use similar ideas as above but:•objects are relations records & fields, whose names are known to DBMS•subjects are end users, or groups of them, or their programs•access types are operations such as read, write, update, delete•access matrix is modified only by the authoriser


The model does not imply any implementation:

• Actually using a matrix will very likely be storage inefficient.

• Using capability lists alone makes generation of ACLs expensive

• And vice versa

Object

Subject

name id addr salary

Manager

Clerk

all all all all

read read read none


Access matrix can model name dependent policy to any level of granularity. But it needs an extension for content-dependent policy:

Access rules must contain also a predicate, an expression defining a condition on set membership.

Let OP be the subset of the objects O for which the predicate P is true; notation OP = {O : P}

Now represent an access rule by a tuple: (s, O, t, Pprot)

specifying that subject s has access t to those members of O satisfying Pprot

eg access to employees with salary < 20000:

( s O t Pprot )( clerk employee read sal<20000 )

The set OPprot is the effective object of the access.


Predicate could also be used for constraints:• integrity constraints (see later)• access time control (eg Mon-Fri 9-5) ie uses data obtained from system

Some context-dependent access control is possible, if the predicate examines the whole query for fields that cannot occur together.

The data that is retrieved (from DB or otherwise) to evaluate the predicate is termed the protection data

Access control involves:• rule specification• validation process (all accesses authorised)

Validation rules govern interpretation of access rules.


Access requests of the form:

(s, O, t, Puser )

(s requests access t to set O:Puser )

are passed to validation process

(assume s is already authenticated).

If there is a rule (s, O, t, Pprot )

then protection data to evaluate the predicate Pprot is retrieved.

If no access rule exists, or the predicate Pprot evaluates to false, then request is denied.

Access request Access rules

any matching rule?

Deny requestRetrieve

"protection data"

yes no

Check predicate?

(s, O, t, Puser) (s, O, t, Pprot)

Pprot is true Pprot is false

Deny requestProcess request


(nb. must also have read access to fields specified in Puser, otherwise inferences may be drawn from either retrieval or non-retrieval of data; but can there be problematic recursion in validating this access?)

Partial match may arise, where access is permitted to some but not all fields; then validation might

•allow only the authorised fields go through - vertical subset;

•or do query modification, allowing through only those records in subset satisfying the predicate p - horizontal subset.


Extensions to basic model• control over set of access rules.

– eg only allow authoriser who wrote a rule to change it.– Rule specifies authoriser a: (a, s, O, t, P)

• the right to delegate rights is a kind of access to the rules (O, t, P). – Subjects may be allowed to do this – Principle of Attenuation Of Privileges is commonplace– Add "copy flag" f to the rule, specifying whether subject is allowed to

delegate access right: (a, s, O, t, f, P)

• extend rule further with auxiliary procedures to be used during validation (eg to specify what to do when access is denied - perhaps log on console). Their use may be contingent on validation decision: must specify conditions and procedures– ([C1,AP1], ... [Cn,APn])

Fully extended rule: (a, s, O, t, f, P, ([c1,ap1], ... [cn,apn]))But basic rule is sufficient for most purposes: (s, O, t, P)


Multilevel models

Non-discretionary access control:

- each subject has clearance level

- each object has classification level

A “subject” is a process executing on behalf of a user, and having a clearance level no greater than that of the user.

“objects” are storage areas, variables, files, I/O devices.


Security level comprises classification level+ set of categories

One level L1 dominates another L2 iff•L1’s classification-level ≥ L2’s-L1’s category set contains L2’s

Access primitives:•observe object (extract info from it)•alter object; • delete object; • (execute object)

Access types (for db):•none•observe only (READ)•alter only (APPEND)•observe & alter (WRITE)


States of a secure system are described by:

- current access set - (s, o, t)

- access matrix (optional; to provide additional discretionary control)

- security level of each object

- max. and current security levels of each subject

System state change is caused by requests:

- obtain/drop access to object

- change current security level

raise/lower classification level

extend/reduce category set

- create/destroy objects

System uses rules to decide its response to each request, taking account of current state. Rules specify how each request is to be handled.


Prove system is secure by proving that each rule is security-preserving.

Secure state possesses:

-Simple security property– for every access (s, o, ‘observe’), level(s) dominates level(o)

– The snag is that once a subject has got information from a high-level object (e.g. top secret), he might put it into another, low-level, object (eg unclassified)

-Confinement property (*-property) combats this:– For every access (s, o, t):

– if t = ‘read’, current level dominates level(o)

– if t = ‘append’, level(o) dominates current level

– if t = ‘write’, level(o) = current level

Extra rules govern creating and destroying objects, changing user level.


Information flow model (Lattice model; Denning)Generalises the information-flow aspects of multilevel model.

Sensitivity & category make up security class

For a specific system, the information flow model comprises1. set of objects2. set of subjects3. set of security classes4. A class-combining operator " "

• The class-combining operator specifies the class of the object formed by combining any two objects of any two classes.

• e.g. concatenating objects of classes A, B yields an object of class AB

5. A flow relation " "• The Flow Relation (A B): lists all pairs of classes A, B where

information in subjects/objects of class A may flow into subjects/objects of class B.


Flow model is secure if flow relation cannot be violated.

A lattice is formed by: {classes, , }

A lattice is a partially ordered set, plus least upper bound, greatest lower bound operators

Example lattice has 3 basic types of data - medical data, financial data, criminal data.

Information always flows into classes at least as inclusive.

for this lattice yields a union of 2 classes.

{m, f, c}

{m, c}{m, f} {f, c}

{m} {f} {c}

φ


Moving information from {m, f} into {m} ought to be regarded as a violation, assuming {m} is designated for medical information only.

A flow policy is a tuple < S, >

S: set of security classes

: flow relation (permissible flows between pairs of classes)

Each object x is bound to a security class, X.

(It is assumed that the bindings are static and are declared in programs.)

To allow us to regard the tuple < S, > as a lattice, we also assume:

- finite number of classes

- flow relation is reflexive and transitive


Information flows from an object x to an object y (written x y) either when information stored in x is transferred to y, or when information in x is used to derive other information that is transferred to y.

A program statement specifies a flow x y if execution of that statement could result in such a flow.

Flows may be explicit , or implicit e.g. if a=0 then b:=c

there are flows cb and also ab

A program P is secure iff all flows, explicit or implicit, are secure. i.e. no execution of P results in a flow x y unless XY


A necessary and sufficient, but undecidable, condition for the security of a program P is:

x y for some execution of P only if X Y

Deciding this reduces to halting problem: one must enumerate all execution paths. A decidable approximation is:

x y is specified by a statement of P only if X Y

This lacks precision.

Consider the statement if x<0 then if x>0 then y:=z

This statement specifies xy but no execution could cause the flow to occur. The code is secure, even in absence of XY, but would fail the certification test.


A Certification process can be built into a compiler’s program-analysis phase, provided that security classes are static and are declared. “Certification semantics” is used in a similar fashion to type checking.

Confinement problem: Procedure is confined if system guarantees that customer information cannot be retained and cannot be encoded for transmission.

In DBMS, a user (one kind of subject) has a clearance u. If user’s query is to retrieve a result composed from objects of classes x1…xn, then it must be verified that (x1… xn) u.


Processes have 3 information transmission channels (Lampson):

- legitimate channels (formal outputs)

- storage channels

these can be verified

- covert channels (eg runtime, paging)

provide only very slow transmission, but cannot be easily handled

Model comparison:

Access Matrix approach is flexible, permits a wide range of policies

With Information Flow approach, introduction of new objects may require new lattice structure, with runtime overhead costs .


…

http://csiweb.ucd.ie/staff/acater/comp30150.html security & integrity information maintained in...

Documents

dbms security

integrity dbms

kinds of information

security integrity information

data corruption

accuracy of data

old data

different users dbms