Lecture 2
---------
cooperation & trust in the context of evolution
Darwinian evolution
- population of individuals
- reproduction w/ variation + selection
life is a game of survival
- if you don't survive you're dead
your life is a resource for others
- can help them live, achieve their goals
so Darwinian evolution leads to "fight for survival" thinking
- kinda sounds like the Internet today right?
- only the secure survive
The metaphors of computer security are all around survival, fighting
- "arms race"
- military metaphors
- attacker, defender
But what does it take to win a war?
- logistics is a HUGE part of what it takes to win
(without good logistics, you lose)
Is logistics a competitive process?
- not if it works!
Logistics is a problem of coordination
- every part of the system working together to achieve a shared goal
- might be producing and distributing food, clothing, weapons, or other things
- if production or distribution fails, you lose
So where does security come into logistics?
- supply chain security, sure
- but think more fundamental
What do you need to make a supply chain work?
- TRUST
Readings for next week will be about trust
How I define trust
- model of behavior
- aligned interests
If A trusts B
- A can predict B's actions with some accuracy
- A's model of B predicts actions that are compatible with A's goals
If B is trustworthy
- others can model B's behavior
- B's general goals are not incompatible with those of others
(generally pro-social, i.e., not in conflict with the group)
Compare this with authentication
- A authenticating B does not mean that A trusts B
Why might an agent behave in an untrustworthy manner?
- because their personal goals no longer align with those of others,
or those of the group in general
Trust isn't really about morality
- it is more about predictability and alignment of interests
Trusted computing base (TCB)
- what does trust mean in this context?
- the TCB is the part of the system that, if its security is compromised, the security of the entire system is compromised
Explicit vs implicit trust
- explicit trust involves models
- so you can detect model deviations
- implicit trust, there's no model per se
- but the functioning of the system depends upon certain
conditions holding
- if those conditions are violated, system will not function properly
- but nothing in the system guarantees those conditions hold
- (has to be guaranteed by external methods/factors)
I would argue that most of computer security practice is based on systems of implicit trust
- mechanisms that, if they work as intended, provide security guarantees
- but, if they are compromised, nothing in the system inherently notices or cares
Code injection defenses
- no-execute memory, ASLR: implicit trust defenses
- stack canaries: explicit trust
Consider authentication technologies
- passwords: if an attacker steals a password, no way for the system to know
How can you tell if an attacker is using compromised credentials?
- intrusion detection, particularly anomaly-based intrusion detection
(user or program based)
Basic idea behind anomaly-based intrusion detection:
- is the targed behaving as we'd expect?
- or, does their behavior conform to our model of their behavior?
You have to have a profile of behavior
- which is typically built through "training"
You then detect deviations from the profile
- while "testing"
Sounds like a good candidate for machine learning right?
- not quite
The key for any anomaly IDS is that it differentiates between "allowed" and "normal"
- the model of behavior is NOT what that entity is authorized to do
Consider an email daemon
- may need root access to deliver email as different users
- but it won't ever read random files in user directories or change system files
So of course we could just use fine-grained permissions, make sure the email daemon can only write to mail files and can't access anything else
- but it is very hard to do such fine-grained permissions everywhere
- generally easier to learn automatically
even doing legit things in weird ways can be an anomaly
- delivering email using different programs, APIs than it typically does
- could detect a trojan version
REST OF SEMESTER
- readings assigned for each class
- will need to turn in a response the night before (by midnight)
- excerpt from your journal
- around 500 words
- don't summarize readings, I've read them!
- more discuss what you thought of it, other related thoughts
- I'll review in the morning before class
- when we first meet, we'll break into groups
- you'll discuss
- we'll then meet together to discuss in more depth
- groups will often present their thoughts
Don't worry if you don't understand the papers in depth
- try to extract the basic arguments, not the details
- read the abstract, intro, conclusion, look at the figures & tables
- look at related work
- then, look at the rest of the paper
And we'll focus on project-related things of course
Trusted computing
-----------------
- multiple meanings, we'll discuss a few
- trust really first comes up in computer security in the context of *assurance*
- processes for creating computing systems that will have certain
properties, particularly security properties
I see assurance as a bit like quality control
- process for creating "good" things
To get assurance when building a secure system
- get trusted people
- have them create the correct requirements
- have a process to make sure requirements are correct
- implement requirements
- have a process to make sure implementation achieves requirements
- do testing & formal validation
- this is the stuff of the "orange book", common criteria
If you don't start with a secure design, your system will forever be insecure
- I DON'T AGREE
Why?
- because we can never follow the assurance process properly!
So classic assurance doesn't work, isn't practical. So what do we do instead?
- FEATURES
Biggest feature: cryptography
Example: trusted computing
- i.e., sign all the code
Even in its primary use case of DRM (digital rights management), it fails all the time
- and even more importantly, it is circumvented
- e.g., tricking users into installing malicious apps
trust => code is signed
- but signed code won't necessarily behave as you expect