Your SlideShare is downloading. ×
Intrusion Management
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Intrusion Management


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Talk is mostly words, few pictures (sorry) Represents an attempt to extend Willow research into new areas
  • Transcript

    • 1. Intrusion Management Using Architecture and Configuration Models. Dennis Heimbigner University of Colorado at Boulder
    • 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 Willow’s capabilities to support more than just intrusion response
        • Complement, not replace
      • Willow focus is on software systems: not hosts or networks (but can’t ignore them)
    • 7. Intrusion Management Life Cycle
      • Define the steps for handling intrusions
        • From initial attack to final prevention
        • From the defender’s 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 Repel* Repair* Analyze Prevent* [Firewall, Re-posturing] [Reconfiguration, Tripwire,...] [Forensics] [Patch,Deploy] Willow Warn* [Intrusion Detection] * - 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 model’s 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
      • From Software Dock via Willow
      • We have a specific configuration process
      Environment Compute Consistent Property Assignment Verify Consistency Configured Architecture Consistent PropertyAssignment System Properties Property-Annotated Architecture Model
    • 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: DSD+xADL+CIM
      • 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
      Detect Repel* Repair* Analyze Prevent* Warn*
    • 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 Karl’s 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 don’t do detection or forensics
      • If there is interest, contact me
    • 36. Willow - UC Davis Synergy
    • 38. Approach: regional intrusion control actuation 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 Remote Directives R-Policy eResponder local domain eResponder eResponder eResponder eResponder INFOSEC alert aggregator Regional Intrusion Control
      • 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
    • 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