November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-1 Chapter 1: Introduction Components of computer security Threats Policies and mechanisms The role of trust Assurance Operational Issues Human Issues

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-2 Basic Components Confidentiality –Keeping data and resources hidden Integrity –Data integrity (integrity) –Origin integrity (authentication) Availability –Enabling access to data and resources

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-3 Classes of Threats Disclosure –Snooping Deception –Modification, spoofing, repudiation of origin, denial of receipt Disruption –Modification Usurpation –Modification, spoofing, delay, denial of service

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-4 Policies and Mechanisms Policy says what is, and is not, allowed –This defines “security” for the site/system/etc. Mechanisms enforce policies Composition of policies –If policies conflict, discrepancies may create security vulnerabilities

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-5 Goals of Security Prevention –Prevent attackers from violating security policy Detection –Detect attackers’ violation of security policy Recovery –Stop attack, assess and repair damage –Continue to function correctly even if attack succeeds

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-6 Assurance Specification –Requirements analysis –Statement of desired functionality Design –How system will meet specification Implementation –Programs/systems that carry out design

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-7 Operational Issues Cost-Benefit Analysis –Is it cheaper to prevent or recover? Risk Analysis –Should we protect something? –How much should we protect this thing? Laws and Customs –Are desired security measures illegal? –Will people do them?

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-8 Human Issues Organizational Problems –Power and responsibility –Financial benefits People problems –Outsiders and insiders –Social engineering

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-9 Tying Together Threats Policy Specification Design Implementation Operation

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-10 Security Policy Policy partitions system states into: –Authorized (secure) These are states the system can enter –Unauthorized (nonsecure) If the system enters any of these states, it’s a security violation Secure system –Starts in authorized state –Never enters unauthorized state

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-11 Confidentiality X set of entities, I information I has confidentiality property with respect to X if no x  X can obtain information from I I can be disclosed to others Example: –X set of students –I final exam answer key –I is confidential with respect to X if students cannot obtain final exam answer key

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-12 Integrity X set of entities, I information I has integrity property with respect to X if all x  X trust information in I Types of integrity: –trust I, its conveyance and protection (data integrity) –I information about origin of something or an identity (origin integrity, authentication) –I resource: means resource functions as it should (assurance)

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-13 Availability X set of entities, I resource I has availability property with respect to X if all x  X can access I Types of availability: –traditional: x gets access or not –quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-14 Policy Models Abstract description of a policy or class of policies Focus on points of interest in policies –Security levels in multilevel security models –Separation of duty in Clark-Wilson model –Conflict of interest in Chinese Wall model

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-15 Types of Security Policies Military (governmental) security policy –Policy primarily protecting confidentiality Commercial security policy –Policy primarily protecting integrity Confidentiality policy –Policy protecting only confidentiality Integrity policy –Policy protecting only integrity

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-16 Integrity and Transactions Begin in consistent state –“Consistent” defined by specification Perform series of actions (transaction) –Actions cannot be interrupted –If actions complete, system in consistent state –If actions do not complete, system reverts to beginning (consistent) state

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-17 Trust Administrator installs patch 1.Trusts patch came from vendor, not tampered with in transit 2.Trusts vendor tested patch thoroughly 3.Trusts vendor’s test environment corresponds to local environment 4.Trusts patch is installed correctly

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-18 Trust in Formal Methods 1.Proof has no errors Bugs in automated theorem provers 2.Preconditions hold in environment in which S is to be used 3.S transformed into executable S whose actions follow source code –Compiler bugs, linker/loader/library problems 4.Hardware executes S as intended –Hardware bugs (Pentium f00f bug, for example)

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-19 Types of Access Control Discretionary Access Control (DAC, IBAC) –individual user sets access control mechanism to allow or deny access to an object Mandatory Access Control (MAC) –system mechanism controls access to object, and individual cannot alter that access Originator Controlled Access Control (ORCON) –originator (creator) of information controls who can access information

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-20 Question Policy disallows cheating –Includes copying homework, with or without permission CS class has students do homework on computer Anne forgets to read-protect her homework file Bill copies it Who cheated? –Anne, Bill, or both?

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-21 Answer Part 1 Bill cheated –Policy forbids copying homework assignment –Bill did it –System entered unauthorized state (Bill having a copy of Anne’s assignment) If not explicit in computer security policy, certainly implicit –Not credible that a unit of the university allows something that the university as a whole forbids, unless the unit explicitly says so

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-22 Answer Part 2 Anne didn’t protect her homework –Not required by security policy She didn’t breach security If policy said students had to read-protect homework files, then Anne did breach security –She didn’t do this

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-23 Mechanisms Entity or procedure that enforces some part of the security policy –Access controls (like bits to prevent someone from reading a homework file) –Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-24 Example English Policy Computer security policy for academic institution –Institution has multiple campuses, administered from central office –Each campus has its own administration, and unique aspects and needs Authorized Use Policy Electronic Mail Policy

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-25 Authorized Use Policy Intended for one campus (Davis) only Goals of campus computing –Underlying intent Procedural enforcement mechanisms –Warnings –Denial of computer access –Disciplinary action up to and including expulsion Written informally, aimed at user community

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-26 Electronic Mail Policy Systemwide, not just one campus Three parts –Summary –Full policy –Interpretation at the campus

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-27 Summary Warns that electronic mail not private –Can be read during normal system administration –Can be forged, altered, and forwarded Unusual because the policy alerts users to the threats –Usually, policies say how to prevent problems, but do not define the threats

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-28 Summary What users should and should not do –Think before you send –Be courteous, respectful of others –Don’t nterfere with others’ use of Personal use okay, provided overhead minimal Who it applies to –Problem is UC is quasi-governmental, so is bound by rules that private companies may not be –Educational mission also affects application

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-29 Full Policy Context –Does not apply to Dept. of Energy labs run by the university –Does not apply to printed copies of Other policies apply here , infrastructure are university property –Principles of academic freedom, freedom of speech apply –Access without user’s permission requires approval of vice chancellor of campus or vice president of UC –If infeasible, must get permission retroactively

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-30 Uses of Anonymity allowed –Exception: if it violates laws or other policies Can’t interfere with others’ use of –No spam, letter bombs, ed worms, etc. Personal allowed within limits –Cannot interfere with university business –Such may be a “university record” subject to disclosure

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-31 Security of University can read –Won’t go out of its way to do so –Allowed for legitimate business purposes –Allowed to keep robust, reliable Archiving and retention allowed –May be able to recover from end system (backed up, for example)

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-32 Implementation Adds campus-specific requirements and procedures –Example: “incidental personal use” not allowed if it benefits a non-university organization –Allows implementation to take into account differences between campuses, such as self-governance by Academic Senate Procedures for inspecting, monitoring, disclosing contents Backups

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-33 Chinese Wall Model Problem: –Tony advises American Bank about investments –He is asked to advise Toyland Bank about investments Conflict of interest to accept, because his advice for either bank would affect his advice to the other bank

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-34 Organization Organize entities into “conflict of interest” classes Control subject accesses to each class Control writing to all classes to ensure information is not passed along in violation of rules Allow sanitized data to be viewed by everyone

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-35 Definitions Objects: items of information related to a company Company dataset (CD): contains objects related to a single company –Written CD(O) Conflict of interest class (COI): contains datasets of companies in competition –Written COI(O) –Assume: each object belongs to exactly one COI class

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-36 Example Bank ofAmerica CitibankBank of theWest Bank COI Class Shell Oil Union ’76 Standard Oil ARCO Gasoline Company COI Class

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-37 Sanitization Public information may belong to a CD –As is publicly available, no conflicts of interest arise –So, should not affect ability of analysts to read –Typically, all sensitive data removed from such information before it is released publicly (called sanitization) Add third condition to CW-Simple Security Condition: 3.o is a sanitized object

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-38 Clinical Information Systems Security Policy Intended for medical records –Conflict of interest not critical problem –Patient confidentiality, authentication of records and annotators, and integrity are Entities: –Patient: subject of medical records (or agent) –Personal health information: data about patient’s health or treatment enabling identification of patient –Clinician: health-care professional with access to personal health information while doing job

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-39 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. –Idea is that clinicians need access, but no-one else. Auditors get access to copies, so they cannot alter records

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-40 Access Principle 2: One of the clinicians on the access control list must have the right to add other clinicians to the access control list. –Called the responsible clinician

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-41 Access Principle 3: The responsible clinician must notify the patient of the names on the access control list whenever the patient’s medical record is opened. Except for situations given in statutes, or in cases of emergency, the responsible clinician must obtain the patient’s consent. –Patient must consent to all treatment, and must know of violations of security

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-42 Access Principle 4: The name of the clinician, the date, and the time of the access of a medical record must be recorded. Similar information must be kept for deletions. –This is for auditing. Don’t delete information; update it (last part is for deletion of records after death, for example, or deletion of information when required by statute). Record information about all accesses.

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-43 Creation Principle: A clinician may open a record, with the clinician and the patient on the access control list. If a record is opened as a result of a referral, the referring clinician may also be on the access control list. –Creating clinician needs access, and patient should get it. If created from a referral, referring clinician needs access to get results of referral.

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-44 Deletion Principle: Clinical information cannot be deleted from a medical record until the appropriate time has passed. –This varies with circumstances.

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-45 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. –This keeps information from leaking to unauthorized users. All users have to be on the access control list.

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-46 Aggregation Principle: Measures for preventing aggregation of patient data must be effective. In particular, a patient must be notified if anyone is to be added to the access control list for the patient’s record and if that person has access to a large number of medical records. –Fear here is that a corrupt investigator may obtain access to a large number of records, correlate them, and discover private information about individuals which can then be used for nefarious purposes (such as blackmail)

November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #4-47 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. –This policy has to be enforced, and the enforcement mechanisms must be auditable (and audited)