CS 513 - System Security
Lecturer: Professor Fred B. Schneider
Notes by: Vicky Weissman
Lecture Date: 2/3/00
- Policy Vs. Mechanism
- Principle of Least Privilege
- Ways to Build Secure Systems
Policy Vs. Mechanism
A policy is a specification. It's what you want.
A mechanism is an implementation. It's how you get what you want.
A mechanism should be designed to support various policies.
Principle of Least Privilege
The Principle of Least Privilege dictates that each task, process, or user
(generically referred to as a subject or a principal) is granted exactly those
rights needed to perform its job. In spy movies, following the Principle of
Least Privilege is equivalent to operating on a need-to-know basis.
To create a system that follows the Principle of Least Privilege, you must determine
what the subjects are, what set of privileges should be given to each subject, and
how/when should the set change. Often, a set of privileges will change based on the
corresponding subject's previous actions (such as file accesses) or on the context
(such as which machine is being used.)
Every real-world system violates the Principle of Least Privilege, since
regulating every bit and every instruction is not reasonable. Real systems, however,
do practice the Principle of Least Privilege at a higher level. For example, if complete
mediation is done, then every access to every object is checked.
In accordance with the Principle of Least Privilege, failsafe defaults require explicit
permission before an access is granted. This method detects permission errors
automatically, since denial of legitimate access will cause complaints.
Separation of Privilege facilitates the Principle of Least Privilege by requiring each
privilege to have a distinct key/means of access.
Ways to Build Secure Systems
- diversity of mechanism
- use multiple lines of defense, forcing attackers to change tactics for each line
- example: accessing a system with both a fingerprint and a password
- keep everyone out
- example: put info on a non-networked PC
- problem: the method precludes sharing
- keep the 'bad guys' out
- example: a firewall
- problems: insider attacks, increasing need for bandwidth to/from outside
- let some 'bad' guys in, but minimize or prevent damage
- example: a system in which each computer has its own firewall
- problem: difficult to manage the configuration
- let the 'bad guys' in, then prosecute
- example: in the real-world, convenience stores often do this
- problem: approach requires good auditing
- plaintext is readable by anyone
- cipher text is not readable by a wiretapper
- an encryption algorithm coverts plaintext to cipher text
- a decryption algorithm converts cipher text to plaintext
- there are 2 types of wiretappers
- passive wiretappers monitor what goes across the wire
- active wiretappers change data along the wire and observe the response
- cryptographers invent cryptosystems
- cryptanalysis is the science of breaking cryptosystems
- cryptology is the study of cryptosystems
- there are 2 ways to conceal a message
- encode according to a codebook
- a codebook is a dictionary mapping words and phrases to other ones
- example: a codebook entry that says the coded word 'kitten' means 'attack'
- decoding a message is considered impossible, but gaining access to a codebook is not
- ciphering involves a mechanical transformation from plaintext to cipher text and back again
- secure messages from passive eavesdroppers
- reassure recipient that the message was not altered since it was sent
- verify who sent the message (authentication)
Designing cryptosystems is difficult to get right. There are only handful of good
cryptographers in the world.