Showing posts with label ME CSE. Show all posts
Showing posts with label ME CSE. Show all posts

Thursday, July 2, 2015

Uses of E-mail

•Anonymity allowed
–Exception: if it violates laws or other policies
•Can’t interfere with others’ use of e-mail
–No spam, letter bombs, e-mailed worms, etc.
•Personal e-mail allowed within limits
–Cannot interfere with university business

–Such e-mail may be a “university record” subject to disclosure

Security of E-mail
•University can read e-mail
–Won’t go out of its way to do so
–Allowed for legitimate business purposes
–Allowed to keep e-mail robust, reliable
•Archiving and retention allowed
–May be able to recover e-mail from end system (backed up, for example)

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 e-mail contents
Backups


Tuesday, June 30, 2015

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
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

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
Electronic Mail Policy
•Systemwide, not just one campus
•Three parts
–Summary
–Full policy
–Interpretation at the campus

Monday, June 29, 2015

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

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?

Sunday, June 28, 2015

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
Trust in Formal Verification
•Gives formal mathematical proof that given input i, program P produces output o as specified
•Suppose a security-related program S formally verified to work with operating system O
•What are the assumptions?
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)

Saturday, June 27, 2015

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
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

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

Friday, June 26, 2015

Security Policies

•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

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

Thursday, June 25, 2015

Computer Security

Trust and Assumptions
•Underlie all aspects of security
•Policies
–Unambiguously partition system states
–Correctly capture security requirements
•Mechanisms
–Assumed to enforce policy

–Support mechanisms work correctly

Assurance
•Specification
–Requirements analysis
–Statement of desired functionality
•Design
–How system will meet specification
•Implementation
–Programs/systems that carry out design

Wednesday, June 24, 2015

Computer Security

Basic Components

Confidentiality
–Keeping data and resources hidden
•Integrity
–Data integrity (integrity)
–Origin integrity (authentication)
•Availability

–Enabling access to data and resources
Classes of Threats
Disclosure
–Snooping
•Deception
–Modification, spoofing, repudiation of origin, denial of receipt
•Disruption
–Modification
•Usurpation
–Modification, spoofing, delay, denial of service