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

271

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
271
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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 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 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
    • 37. BACKGROUND SLIDES
    • 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

    ×