CS526: Information Security Chris Clifton

1
CS526 Information SecurityChris Clifton

• November 11, 2004
• Audit Mechanisms

2
What is Auditing?

• Webster a methodical examination and review
• Information Security An a-posteriori technique
  to identify security violations
• How does this help maintain security?

3
Issues

• What information do we need?
• After the fact current state of system isnt
  enough
• logging
• How do we perform an Audit?
• Audit methodology
• What do we do with the results?

4
Logging

• Goal Record all information that might be
  needed for an audit
• Authentication attempts
• Failed only?
• Access to trusted resources
• All? Just failed attempts?
• Log must enable detection of security violations
• Is this enough?

5
Example Bell-LaPadula

• What must be logged?
• Action (read/write)
• Level of subject
• Level of object
• Can now check
• Read S O
• Write O S
• Is this necessary?
• What if system validated as not allowing illegal
  read/write?
• What about change of security level?

6
Logging Trusted Operations

• Secure system prevents security violations
• Trusted components those that can violate
  security
• Assumptions made to justify system secure
• Log actions by trusted components
• Change in security level
• Operations performed while not at maximum level

7
Logging Implementation

• Log Format
• Standard
• Machine readable
• Transform to human readable
• Wrong
• Connection blocked from 128.10.3.4 to
  cs.purdue.edu
• Right Structured format, standards

8
Logging Implementation

• Log must be protected
• Doesnt do any good if security violations erased
  from log
• Sanitization
• Remove sensitive information from log
• Why?
• Before or after logging?

9
Audit

• Detect security violation
• State-based auditing identify if state at prior
  time is valid
• Transition-based auditing Identify if prior
  transition would lead to unauthorized state
• Detect attempts to breach security
• Not necessarily violations

10
Using Audit Results

• Repair
• Recover critical information
• Risk mitigation
• Restore integrity
• Punish
• Identify violator
• Both may demand additional logged information

11
Why Not Design a Secure System Up Front?

• Audit catches security violations
• Why allow them in the first place?
• Possible reasons
• (un)trusted components
• Changes in security policy

12
Other types of Audit

• Logging done for many reasons
• System tuning
• Backup / failure recovery
• ?
• Can this be used for security audit?
• Example Basic Security Module add-on to SunOS
• Defines audit events
• Captures identity, action

13
Example / Reading

• Network File System logging
• What is the policy?
• What requests logged?
• What information logged?
• Read Bishop 24.6

14
CS526 Information SecurityChris Clifton

• November 11, 2004
• Commit Protocols

15
Distributed Cooperation

• Problem Networks will fail
• Cant rely on perfect availability
• How to maintain integrity?
• Compensate at application level
• Solution Distributed commit
• All parties agree on an action
• Based on concept of Transaction

16
What is a Transaction?

• Atomic
• The external view is that either everything in
  the transaction happened, or nothing did
• Consistent
• If the start state is valid, the end state is
  valid
• Isolated
• A transaction in process is not affected by and
  does not affect any other transaction
• Durable
• Once complete, the effects of a transaction are
  permanent, even in the event of failure.

17
Distributed Transactions

• What is the difference with Distributed
  Transactions?
• NOTHING!
• Must still support ACID properties
• Important for all the same reasons
• Why do we study Distributed Transactions?
• Some properties harder to implement
• Basic single-system techniques not sufficient

18
What is a Distributed Transaction?
Data
Data
Transaction component
Transaction component
Transaction component
Transaction component
Data
Data
19
Why are Distributed Transactions Hard?

• Atomic
• Different parts of a transaction may be at
  different sites
• How do we ensure all or none committed?
• Consistent
• Failure may affect only part of transaction
• Isolated
• Commitment must occur simultaneously at all
  sites
• Durable
• Not much different when other problems solved
• Makes delayed commit difficult

20
Key Issues

• Commitment
• Standard techniques preserve properties when
  commit occurs
• Distributed systems need commit protocols so we
  know when commit has occurred
• Failures
• Standard techniques support durability for
  commit/abort
• What happens if a site fails during commitment?

21
Committing a Distributed Transaction
Data
Data
Transaction component
Transaction component
log
log
Transaction component
Transaction component
log
log
Data
Data
22
Two-Phase Commit(Lamport 76, Gray 79)

• Assumes central coordinator
• Coordinator initiates protocol
• Participants entities with actions to be
  committed/aborted
• Phase 1
• Coordinator asks if participants can commit
• Participants respond yes/no
• Phase 2
• If all votes yes, coordinator sends Commit
• Otherwise send Abort
• Participants send Have Committed / Have Aborted

23
Two-Phase Commit
Data
Data
Transaction component
Transaction component
log
log
CanCommit?
CanCommit?
Commit
Commit
Done
Done
Yes
Yes
Coordinator
Yes
Yes
Done
Done
Commit
Commit
Transaction component
Transaction component
log
log
CanCommit?
CanCommit?
Data
Data
24
Two-Phase CommitFault Tolerance

• Participant fails in Phase 1
• Coordinator doesnt get unanimous yes
• Abort
• Participant fails in Phase 2
• On reawakening, can ask coordinator if it should
  commit or abort
• Requires that both commit and abort states be
  durable before sending yes vote

25
Two-Phase CommitProblems

• Blocks on failure
• Timeout before abort if participant fails
• All participants must wait for recovery if
  coordinator fails
• While blocked, transaction must remain Isolated
• Hold locks on data items touched
• Prevents other transactions from completing
• Solution Three-Phase Commit
• See reading