Some PBaked Security Ideas

1
Some P-BakedSecurity Ideas

• Dennis Heimbigner
• University of Colorado at Boulder
• http//www.cs.colorado.edu/users/dennis
• http//www.cs.colorado.edu/serl

2
P-Baked Ideas

• Generalization of the notion of a
  half-baked idea (P 0.5)
• 0 ? P ? 1
• P close to 0 ? ill-formed or very speculative
• P close to 1 ? major issues solved, no obvious
  killers

3
Architecture-Level Vulnerability Analysis

• P ? 0.10
• Question Can we do useful vulnerability analysis
  at design time?
• Background
• Most vulnerability work (Bishop, Wagner) targets
  implementation
• Not surprising many vulnerabilities are based on
  detailed properties of the system
• Some work (Moriconi) on checking MLS at
  architecture level

4
Architecture Specification Languages

• Developed in last five years
• Goal support design-time analysis of software
  architecture
• Basic Elements
• Components - represent functionality
• Connectors - represent communication
• Interfaces (ports) - represent interfaces for
  both components and connectors
• Sub-Architectures - composition and hierarchy
• Constraints individual and whole architecture

5
Architecture Example
Transaction Service
Persistence Service
E-Commerce Service
Client
Client
Connector (e.g., http, CORBA, SOAP)
6
Architecture Analysis

• Common analysis technique
• Attach properties to architecture elements
• Propagate properties based on rules and
  constraints
• Analyze resulting annotated architecture
• Essentially a form of model checking

7
Vulnerability Analysis of Architectures

• Approach
• Annotate architecture with vulnerability
  properties
• Propagate using appropriate rules
• Analyze to look for flaws
• Similarity to Bishops TASPEC and Testers
  Assistant

8
Problems

• What can be detected at this level?
• I think I can do Moriconi MLS checking
• Interfaces and connectors annotated with MLS
  levels
• RISOS and PA provide vulnerability classification
  schemes
• Consistent parameter validation can be checked
• Unfortunately nothing else seemed to fit
• how could I handle access-open race conditions?
• What is the output?
• Constraints to enforce at implementation time
  (e.g. parameter validation)

9
Solutions?

• Add data flow to architecture specification?
• Design specific design-time models for each
  category of vulnerability?
• Forget architecture and focus on other
  specifications?
• E.g. StateCharts, UML, etc.

10
Architecture Degradation for Misuse Protection

• P ? 0.20
• Question Do interesting new uses exist for
  deception?
• Background
• Intrigued by Cohens use of deception
• Current uses
• Honeypots
• Security through obscurity (hall of mirrors
  effect)

11
Attack Context

• Attackers
• capture/steal computer
• Non-sysadmin Insider
• Goals
• Quickly extract sensitive information
• Propagate false information
• Constraints
• Attacker has limited time
• Attacker has limited physical access

12
Example

• PDA of soldier on battlefield
• Captured by enemy
• Extract battle information
• Insert false enemy strength/position
• Insider with non-physical access but insider
  knowledge
• Extract criminal histories
• Change credit information

13
Graduated Response to Misuse

• Assume we can detect possible misuse
• Form of IDS
• High rate of false positives
• Goal
• Gradually degrade the operation of the suspect
  computer in response to potential misuse
• Restore operation if false alarm can be verified
• Why not just blow up the PDA?
• Drastic response in event of false alarm
• Possible mechanism to learn about attacker

14
Role of Deception

• Dynamically replace components and data
• Properties of new components and data
• Deceptive they provide false information
• Disabled they lose selected functionality
• Multiple replacements over time implement a
  graduated response

15
Problems

• Is the attack context realistic?
• For false alarms
• How do we tell the user what we did?
• False alarms are not invisible
• How do we get back to a correct state?

16
Integrity Co-Processors

• P ? 0.40
• Question Can we exploit hardware to protect
  intrusion control mechanisms?
• Background
• All intrusion control mechanisms are subject to
  attack
• IDS can be disabled
• Response mechanisms can be subverted to amplify
  penetrations

17
Co-Processors in Aid of Security

• Hardware is being used to help with selected
  security problems
• Smith paper (Los Alamos) identifies many research
  applications
• Secure Persistent Storage
• Store keys, audit trails
• Secure computations
• Encryption, signing, licensing
• Reference Monitor
• Offload selected computations

18
Current Properties of Co-Processors

• Co-processors are used in peer fashion
• The host computer sends request to co-processor
  and receives response
• Host cannot forcibly interrogate co-processor and
  vice-versa
• Assumption is that co-processor is in a
  physically insecure environment
• Focus on secure co-processors
• E.g. Smartcards

19
Co-Processor as Controller

• A co-processor could forcibly control its host
• Non-peer relationship
• Co-processor
• Unmediated access to the CPU bus
• Host cannot interfere with access
• Unmediated read/write access to main memory
• Ability to interrupt host processor
• Goal use the co-processor to enforce host
  integrity
• validate the integrity of the software on the
  host
• repair damaged software on the host

20
Integrity Co-Processor Architecture
21
Problems / Solutions

• Is such a co-processor easily realizable?
• Realizable cheap and not requiring major
  changes to existing hardware hosts
• IBM 4758 PCI Cryptographic Coprocessor has PCI
  interface
• May not itself be usable, but some variant should
  work
• Why not just run the host software on the
  co-processor?
• Hardware secure ? Software secure

22
Problems / Solutions

• What about on-board cache?
• May be able to force CPU to flush it
• Assume latency on memory contents
• Attackers can attempt to game the co-processor
  software
• Need ability to securely update co-processor
  software as problems are identified
• Can Host hide its operations from co-processor?
• This is the open question

23
Summary

• I have identified several possible research
  topics in security
• Rummaging around in the security closet
• Extensions of previous ideas that seem to me to
  be under-exploited
• What P values should I assign?
• Are any of these worth exploring further?
• Integrity co-processor yes
• Architecture level vulnerabilities not until I
  can find good examples
• Deception not sure the attack assumptions are
  interesting

24
So long, and thanks for all the fish.
- Douglas Adams