Intrusion Management Using Architecture and Configuration Models.

1
Intrusion ManagementUsingArchitecture and
Configuration Models.

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

2
Background Willow Project

• Goal Survive intrusions and other faults
• Continue sufficient level of service in the
  face of unintended and malicious disruptions
• analogy load shedding in national power grid
• System context
• Large-scale, heterogeneous, and distributed
• Component-based and evolving
• Interdependent
• E.g. Banking and
• Telecomm

3
Primary Tool Reconfiguration

• Any and all planned changes applied to the
  communication, interconnection, componentization,
  and functionality of a system

4
High-Level Research Hypotheses

• Reconfiguration in an assured, secure, and
  automated fashion is a powerful approach to
  surviving non-maskable service disruptions
• Automated reconfiguration can react to
  disruptions with a speed, accuracy, and scale not
  achievable by manual procedures
• Reconfiguration can proactively protect against
  threats and reactively recover from disruptions

5
Role of Models in Willow

• All phases of reconfiguration are driven by
  architectural models of the distributed system
• Survivability Analysis
• Driven by a coarse architecture model in Zed
• (Re-)Configuration
• Driven by models of system families (variants)
  and executing systems

6
Extending Willow Approach

• Hypothesis configurable architecture models
• Can provide a common framework for organizing and
  integrating all phases of defending against
  intrusions
• Can provide a framework around which to organize
  existing data
• Goal extend Willows capabilities to support
  more than just intrusion response
• Complement, not replace
• Willow focus is on software systems not hosts or
  networks (but cant ignore them)

7
Intrusion Management Life Cycle

• Define the steps for handling intrusions
• From initial attack to final prevention
• From the defenders point of view
• Not an attack model (but related)
• Goal is to provide a theme for integrating
  existing intrusion management components

8
Intrusion Management Life Cycle
Detect
Intrusion Detection
Repel
Firewall, Re-posturing
Warn
Repair
Reconfiguration, Tripwire,...
Analyze
Forensics
Prevent
Patch,Deploy
Willow
- Response process
9
What is Architecture?

• The architecture of a system represents the
  components of the system and the interconnections
  and dependencies between those components
• Defined in terms of elements appropriate to the
  models level
• For e.g. deployment - it is the set of files
  (code and data) comprising the system
• For e.g. runtime - it is the set of executable
  components plus various properties (e.g. ports)
  plus interconnections

10
What is Configuration?

• A system family represents the possible versions
  and variants of the architecture of the system
• Version revisions of the system architecture
  over time
• Variant range of alternative architectures for
  any version
• Configuration
• Process of choosing a specific family instance
• Properties that determine that instance
• Orthogonal to Architecture models

11
Configuration Process

• We have a specific configuration process

• From Software Dock via Willow

12
Model Sources

• Goal Maximum reuse of existing models
• Following slides are not intended to be exhaustive

13
Model Sources (cont.)

• Software Engineering architecture models
• Target component level architecture
• Sources UCI (x)ADL, CMU (x)ARCH
• Model elements
• Components, Ports/Interfaces, Connectors,
  Constraints, Dependencies

14
Model Sources (cont.)

• Deployable Software Description (DSD)
• Target deployment of artifacts
• Source Colorado Software Dock project
• Model elements
• properties (internal, external), assertions,
  dependencies, artifacts, processes

15
Model Sources (cont.)

• Common Information Model (CIM)
• Target Host environment (limited) software
  system architecture
• Source Desktop Management Task Force (DMTF)
• Model elements
• Complex class structure

16
Model Sources (cont.)

• Autoconfig
• Target Host environment
• Source FSF
• Model elements
• No declarative model as such
• Procedures for interrogating host environment
• Source of raw data

17
Model Sources (cont.)

• Simple Network Management Protocol
• Management Information Bases (MIBs)
• Target Device and software system properties
• Source IETF
• Model elements
• Tree of properties with single or sequences of
  values
• Too primitive to be more than source of raw data

18
Architectural Model Classification

• System Model
• Represents the structure and properties of the
  software system to be configured
• May be multi-part to cover distributed systems
• Environment Model
• Represents the structure and properties of the
  site in which systems operate
• E.g., OS, hardware, etc
• Think autoconfig but more sophisticated

19
Architecture Sub-Models

• System Model
• I Family
• II Deployment
• III Activation
• Environment Model
• I Host
• II Network
• III Administration

20
System Model I Family

• Model the range of legal configurations of a
  software system
• More or less a product-line description
• Basis DSDxADLCIM
• Technically includes all other system models

21
System Model II Deployment

• Model the chosen configuration
• with respect to some environment
• Defines installed artifacts
• Derived by choosing a specific family instance
  from family model
• Basis Software Dock internal model

22
System Model III Activation

• Model the running system
• E.g., the actual number of clients and servers
  and their connections over time
• with respect to some environment
• Define startup/shutdown dependencies
• Derived from deployment model architecture
  model for running system
• Basis xADL

23
Environment Model I Host

• Lowest level of granularity in environment model
  OS, hardware
• Basis SNMP autoconfig CIM
• Not (currently) target for Willow reconfiguration

24
Environment Model II Network

• Interconnections of hosts plus properties of the
  whole network.
• Strong overlap with existing network manager
  (e.g. HP OpenView)
• Basis SNMP
• OpenView models proprietary?
• Not (currently) target for Willow reconfiguration

25
Environment Model III Administrative

• Security and administrative overlay on the hosts
  and network
• Administrative domains
• Firewall boundaries
• Overlays other environment models
• Basis unknown
• Not (currently) target for Willow reconfiguration

26
Applying Models to Intrusion Life Cycle

• Examine the roles that the identified models can
  play in the steps of the Intrusion Management
  Life Cycle

27
Intrusion Detection

• Most IDS operate at low level of detail
• e.g. packets
• That is where the big payoff occurs
• Specification-based IDS is closer to our level
• Primarily watches behavior of software systems
• at the level of e.g. system calls
• complementary to architecture models
• Architecture is framework for behavior info
• Reconfigure target system to include intrusion
  sensors
• Manage IDS system itself (HiDRA project)
• E.g., sensor deployment

28
Intrusion Repelling

• Firewall rule changes are common means for
  repelling attacks
• Reconfigure to temporarily add/drop/modify
  functionality
• This is Willow approach
• No free lunch repelling costs resources

29
Intrusion Warning

• Notify others of progress of this domain through
  the life cycle
• when intrusion is detected
• the local administrator
• other systems (networks, hosts, etc)
• when a repel or repair is successful
• Naively, there appears room for research here
• What happened to CDIF and its successors?

30
Intrusion Repair

• Determine state of the compromised system
• Restart components
• From trusted sources
• State repair is hard
• Requires careful checkpointing

31
Intrusion Analysis Forensics

• Current forensic tools are fairly low level
• Architecture model provides a high level
  framework for structuring the raw data produced
  by e.g. core dumps
• Allow an analyst to look for anomalies at the
  level of the architecture
• Automated Support
• Much of the initial mapping of the core-dump to
  the architecture can be automated
• Conversations with Rome Labs indicate movement in
  this direction

32
Intrusion Prevention

• Analysis can identify the nature of the attack
• This enables the development of mechanisms for
  mitigating future attacks of this type
• Patches - require deployment to all affected
  systems (including running instances)
• General reconfiguration

33
Issues

• Analysis of models
• For what? When (online vs offline)?
• Fidelity between running system and the models
• Ability of ADL or ARCH to model running systems
• State management
• Attacks on infrastructure
• Need common representation for all models
• RDF, DAML/OIL, CIM

34
Next Steps

• Complete our models for Willow
• Integrate models
• Explore architecture-based IDS
• UC Davis help would be invaluable here
• Explore architecture-based forensics system
• Again, need partner with forensics expertise
• Provide an integrated intrusion management
  infrastructure IDS Willow Forensics
• Hard
• Longer term

35
CU - UC Davis Collaboration Opportunity

• I see strong synergy with Karls proposal of last
  week
• Willow would provide strong candidate for
• the intrusion control actuation system
• Automated installation and maintenance system
• Willow provides one possible way to respond to
  intrusions
• Complementary to other approachs
• We currently dont do detection or forensics
• If there is interest, contact me

36
Willow - UC Davis Synergy
37
BACKGROUND SLIDES
38
Approach regional intrusion control actuation

• Regional CoA Playbooks are predefined to respond
  to single or multi-domain threats
• Playbooks consists of one or more response
  primitives
• Automated CoA selection will employ regional CoA
  playbooks in response to multi-enterprise threats
• Advance research will pursue automated playbook
  formulation
• Synchronization of regional intrusion control
  systems will resolve CoA conflicts and overkill

Example Actuator eResponder Primitives 1.
diagnose. For diagnosing, and possibly
restarting critical services or for filesystem
exhaustion handling.   2. lockout. For locking
out a user account via password disabling.
Usually used right before a killall (sometime
kill, as in non-anon FTP stuff). 3.
killall. For killing all processes owned by a
user.   4. kill. For killing a user session and
subprocesses.   5. checkcfg For Oki purposes.
Informative only. No response necessary.   6.
fixperms for performing chmod and chown.   7.
filter for firewall response directives.   8.
notify for forwarding notification to a
non-admin user that his/her data may have been
subject to some misuse attempt.   9. reset
provides information needed for a response engine
to sever malicious TCP connection via TCP reset.
This directive reports information from an
observed packet in the connection. The response
agent will use this information to craft a set of
RST packets so that one will be accepted by the
target (see RFC 793).   10. recovered provides
information that a diagnosed service failure has
recovered.   11. targeted provides information
that services have been the target of a probe
Regional Intrusion Control
INFOSEC alert aggregator
eResponder
Remote Directives R-Policy
local domain
eResponder
eResponder
eResponder
eResponder
39
Technology transition structuring for
adaptability

• Open source framework
• provisions for optional proprietary plug-ins
• Interfaces to standard management and security
  systems
• commercial network configuration and management
  systems
• OpenView, Tivoli, etc.
• commercial and open-source intrusion detectors
  and firewalls
• RealSecure, NetRanger, Dragon, snort, EMERALD,
  etc.
• Gauntlet, PIX, Check Point, Raptor, ipchains,
  etc.
• internet security management standards
• SNMP, Intrusion Detection Message Format, and
  others
• Automation for installation and maintenance
• network inventory and configuration
• intrusion sensor deployment, configuration, and
  activation
• security policy definition and dissemination
• isolation and recovery mechanisms and agents