Intrusion Management Using Architecture and Configuration Models. Dennis Heimbigner University of Colorado at Boulder http...
Background: Willow Project <ul><li>Goal: Survive intrusions and other faults </li></ul><ul><ul><li>Continue “sufficient” l...
Primary Tool: Reconfiguration <ul><li>Any and all planned changes applied to the communication, interconnection, component...
High-Level Research Hypotheses <ul><li>Reconfiguration  in an  assured ,  secure , and  automated  fashion is a powerful a...
Role of Models in Willow <ul><li>All phases of reconfiguration are driven by architectural models of the distributed syste...
Extending Willow Approach <ul><li>Hypothesis: configurable architecture models: </li></ul><ul><ul><li>Can provide a common...
Intrusion Management Life Cycle <ul><li>Define the steps for handling intrusions </li></ul><ul><ul><li>From initial attack...
Intrusion Management Life Cycle Detect Repel* Repair* Analyze Prevent* [Firewall, Re-posturing] [Reconfiguration, Tripwire...
What is Architecture? <ul><li>The  architecture  of a system represents the  components  of the system and the  interconne...
What is Configuration? <ul><li>A system  family  represents the possible  versions  and  variants  of the architecture of ...
Configuration Process <ul><li>From Software Dock via Willow </li></ul><ul><li>We have a specific configuration process </l...
Model Sources <ul><li>Goal: Maximum reuse of existing models </li></ul><ul><li>Following slides are not intended to be exh...
Model Sources (cont.) <ul><li>Software Engineering architecture models </li></ul><ul><ul><li>Target: component level archi...
Model Sources (cont.) <ul><li>Deployable Software Description (DSD) </li></ul><ul><ul><li>Target: deployment of artifacts ...
Model Sources (cont.) <ul><li>Common Information Model (CIM) </li></ul><ul><ul><li>Target: Host environment + (limited) so...
Model Sources (cont.) <ul><li>Autoconfig </li></ul><ul><ul><li>Target: Host environment </li></ul></ul><ul><ul><li>Source:...
Model Sources (cont.) <ul><li>Simple Network Management Protocol </li></ul><ul><li>Management Information Bases (MIBs) </l...
Architectural Model Classification <ul><li>System Model </li></ul><ul><ul><li>Represents the structure and properties of t...
Architecture Sub-Models <ul><li>System Model </li></ul><ul><ul><li>I  Family </li></ul></ul><ul><ul><li>II  Deployment </l...
System Model I: Family <ul><li>Model the range of legal configurations of a software system </li></ul><ul><ul><li>More or ...
System Model II: Deployment <ul><li>Model the chosen configuration </li></ul><ul><ul><li>with respect to some environment ...
System Model III: Activation <ul><li>Model the running system </li></ul><ul><ul><li>E.g., the actual number of clients and...
Environment Model I: Host <ul><li>Lowest level of granularity in environment model: OS, hardware </li></ul><ul><li>Basis: ...
Environment Model II: Network <ul><li>Interconnections of hosts plus properties of the whole network. </li></ul><ul><li>St...
Environment Model III: Administrative <ul><li>Security and administrative overlay on the hosts and network </li></ul><ul><...
Applying Models to Intrusion Life Cycle <ul><li>Examine the roles that the identified models can play in the steps of the ...
Intrusion Detection <ul><li>Most IDS operate at low level of detail: </li></ul><ul><ul><li>e.g. packets </li></ul></ul><ul...
Intrusion Repelling <ul><li>Firewall rule changes are common means for repelling attacks </li></ul><ul><li>Reconfigure to ...
Intrusion Warning <ul><li>Notify others of progress of this domain through the life cycle: </li></ul><ul><ul><li>when intr...
Intrusion Repair <ul><li>Determine state of the compromised system </li></ul><ul><li>Restart components </li></ul><ul><ul>...
Intrusion Analysis [Forensics] <ul><li>Current forensic tools are fairly low level </li></ul><ul><li>Architecture model pr...
Intrusion Prevention <ul><li>Analysis can identify the nature of the attack </li></ul><ul><li>This enables the development...
Issues <ul><li>Analysis of models </li></ul><ul><ul><li>For what? When (online vs offline)? </li></ul></ul><ul><li>Fidelit...
Next Steps <ul><li>Complete our models for Willow </li></ul><ul><li>Integrate models </li></ul><ul><li>Explore architectur...
CU - UC Davis Collaboration Opportunity <ul><li>I see strong synergy with Karl’s proposal of last week </li></ul><ul><li>W...
Willow - UC Davis Synergy
BACKGROUND SLIDES
Approach:  regional intrusion control actuation Example Actuator:  eResponder Primitives 1.  diagnose .  For diagnosing, a...
Technology transition:  structuring for adaptability <ul><li>Open source framework </li></ul><ul><ul><li>provisions for op...
Upcoming SlideShare
Loading in …5
×

Intrusion Management

315
-1

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
315
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

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

    1. 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. 2. Background: Willow Project <ul><li>Goal: Survive intrusions and other faults </li></ul><ul><ul><li>Continue “sufficient” level of service in the face of unintended and malicious disruptions </li></ul></ul><ul><ul><ul><li>analogy : load shedding in national power grid </li></ul></ul></ul><ul><li>System context </li></ul><ul><ul><li>Large-scale, heterogeneous, and distributed </li></ul></ul><ul><ul><li>Component-based and evolving </li></ul></ul><ul><ul><li>Interdependent </li></ul></ul><ul><ul><ul><li>E.g. Banking and </li></ul></ul></ul><ul><ul><ul><li>Telecomm </li></ul></ul></ul>
    3. 3. Primary Tool: Reconfiguration <ul><li>Any and all planned changes applied to the communication, interconnection, componentization, and functionality of a system </li></ul>
    4. 4. High-Level Research Hypotheses <ul><li>Reconfiguration in an assured , secure , and automated fashion is a powerful approach to surviving non-maskable service disruptions </li></ul><ul><li>Automated reconfiguration can react to disruptions with a speed , accuracy , and scale not achievable by manual procedures </li></ul><ul><li>Reconfiguration can proactively protect against threats and reactively recover from disruptions </li></ul>
    5. 5. Role of Models in Willow <ul><li>All phases of reconfiguration are driven by architectural models of the distributed system </li></ul><ul><li>Survivability Analysis </li></ul><ul><ul><li>Driven by a coarse architecture model in Zed </li></ul></ul><ul><li>(Re-)Configuration </li></ul><ul><ul><li>Driven by models of system families (variants) and executing systems </li></ul></ul>
    6. 6. Extending Willow Approach <ul><li>Hypothesis: configurable architecture models: </li></ul><ul><ul><li>Can provide a common framework for organizing and integrating all phases of defending against intrusions </li></ul></ul><ul><ul><li>Can provide a framework around which to organize existing data </li></ul></ul><ul><li>Goal: extend Willow’s capabilities to support more than just intrusion response </li></ul><ul><ul><li>Complement, not replace </li></ul></ul><ul><li>Willow focus is on software systems: not hosts or networks (but can’t ignore them) </li></ul>
    7. 7. Intrusion Management Life Cycle <ul><li>Define the steps for handling intrusions </li></ul><ul><ul><li>From initial attack to final prevention </li></ul></ul><ul><ul><li>From the defender’s point of view </li></ul></ul><ul><ul><li>Not an attack model (but related) </li></ul></ul><ul><li>Goal is to provide a theme for integrating existing intrusion management components </li></ul>
    8. 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. 9. What is Architecture? <ul><li>The architecture of a system represents the components of the system and the interconnections and dependencies between those components </li></ul><ul><li>Defined in terms of elements appropriate to the model’s level </li></ul><ul><ul><li>For e.g. deployment - it is the set of files (code and data) comprising the system </li></ul></ul><ul><ul><li>For e.g. runtime - it is the set of executable components plus various properties (e.g. ports) plus interconnections </li></ul></ul>
    10. 10. What is Configuration? <ul><li>A system family represents the possible versions and variants of the architecture of the system </li></ul><ul><ul><li>Version = revisions of the system architecture over time </li></ul></ul><ul><ul><li>Variant = range of alternative architectures for any version </li></ul></ul><ul><li>Configuration: </li></ul><ul><ul><li>Process of choosing a specific family instance </li></ul></ul><ul><ul><li>Properties that determine that instance </li></ul></ul><ul><li>Orthogonal to Architecture models </li></ul>
    11. 11. Configuration Process <ul><li>From Software Dock via Willow </li></ul><ul><li>We have a specific configuration process </li></ul>Environment Compute Consistent Property Assignment Verify Consistency Configured Architecture Consistent PropertyAssignment System Properties Property-Annotated Architecture Model
    12. 12. Model Sources <ul><li>Goal: Maximum reuse of existing models </li></ul><ul><li>Following slides are not intended to be exhaustive </li></ul>
    13. 13. Model Sources (cont.) <ul><li>Software Engineering architecture models </li></ul><ul><ul><li>Target: component level architecture </li></ul></ul><ul><ul><li>Sources: UCI (x)ADL, CMU (x)ARCH </li></ul></ul><ul><ul><li>Model elements: </li></ul></ul><ul><ul><ul><li>Components, Ports/Interfaces, Connectors, Constraints, Dependencies </li></ul></ul></ul>
    14. 14. Model Sources (cont.) <ul><li>Deployable Software Description (DSD) </li></ul><ul><ul><li>Target: deployment of artifacts </li></ul></ul><ul><ul><li>Source: Colorado Software Dock project </li></ul></ul><ul><ul><li>Model elements: </li></ul></ul><ul><ul><ul><li>properties (internal, external), assertions, dependencies, artifacts, processes </li></ul></ul></ul>
    15. 15. Model Sources (cont.) <ul><li>Common Information Model (CIM) </li></ul><ul><ul><li>Target: Host environment + (limited) software system architecture </li></ul></ul><ul><ul><li>Source: Desktop Management Task Force (DMTF) </li></ul></ul><ul><ul><li>Model elements: </li></ul></ul><ul><ul><ul><li>Complex class structure </li></ul></ul></ul>
    16. 16. Model Sources (cont.) <ul><li>Autoconfig </li></ul><ul><ul><li>Target: Host environment </li></ul></ul><ul><ul><li>Source: FSF </li></ul></ul><ul><ul><li>Model elements: </li></ul></ul><ul><ul><ul><li>No declarative model as such </li></ul></ul></ul><ul><ul><ul><li>Procedures for interrogating host environment </li></ul></ul></ul><ul><ul><ul><li>Source of raw data </li></ul></ul></ul>
    17. 17. Model Sources (cont.) <ul><li>Simple Network Management Protocol </li></ul><ul><li>Management Information Bases (MIBs) </li></ul><ul><ul><li>Target: Device and software system properties </li></ul></ul><ul><ul><li>Source: IETF </li></ul></ul><ul><ul><li>Model elements: </li></ul></ul><ul><ul><ul><li>Tree of properties with single or sequences of values </li></ul></ul></ul><ul><ul><li>Too primitive to be more than source of raw data </li></ul></ul>
    18. 18. Architectural Model Classification <ul><li>System Model </li></ul><ul><ul><li>Represents the structure and properties of the software system to be configured </li></ul></ul><ul><ul><li>May be multi-part to cover distributed systems </li></ul></ul><ul><li>Environment Model </li></ul><ul><ul><li>Represents the structure and properties of the site in which systems operate </li></ul></ul><ul><ul><li>E.g., OS, hardware, etc </li></ul></ul><ul><ul><li>Think autoconfig but more sophisticated </li></ul></ul>
    19. 19. Architecture Sub-Models <ul><li>System Model </li></ul><ul><ul><li>I Family </li></ul></ul><ul><ul><li>II Deployment </li></ul></ul><ul><ul><li>III Activation </li></ul></ul><ul><li>Environment Model </li></ul><ul><ul><li>I Host </li></ul></ul><ul><ul><li>II Network </li></ul></ul><ul><ul><li>III Administration </li></ul></ul>
    20. 20. System Model I: Family <ul><li>Model the range of legal configurations of a software system </li></ul><ul><ul><li>More or less a product-line description </li></ul></ul><ul><li>Basis: DSD+xADL+CIM </li></ul><ul><li>Technically includes all other system models </li></ul>
    21. 21. System Model II: Deployment <ul><li>Model the chosen configuration </li></ul><ul><ul><li>with respect to some environment </li></ul></ul><ul><li>Defines installed artifacts </li></ul><ul><li>Derived by choosing a specific family instance from family model </li></ul><ul><li>Basis: Software Dock internal model </li></ul>
    22. 22. System Model III: Activation <ul><li>Model the running system </li></ul><ul><ul><li>E.g., the actual number of clients and servers and their connections over time </li></ul></ul><ul><ul><li>with respect to some environment </li></ul></ul><ul><li>Define startup/shutdown dependencies </li></ul><ul><li>Derived from deployment model + architecture model for running system </li></ul><ul><li>Basis: xADL </li></ul>
    23. 23. Environment Model I: Host <ul><li>Lowest level of granularity in environment model: OS, hardware </li></ul><ul><li>Basis: SNMP + “autoconfig” + CIM </li></ul><ul><li>Not (currently) target for Willow reconfiguration </li></ul>
    24. 24. Environment Model II: Network <ul><li>Interconnections of hosts plus properties of the whole network. </li></ul><ul><li>Strong overlap with existing network manager (e.g. HP OpenView) </li></ul><ul><li>Basis: SNMP </li></ul><ul><ul><li>OpenView models proprietary? </li></ul></ul><ul><li>Not (currently) target for Willow reconfiguration </li></ul>
    25. 25. Environment Model III: Administrative <ul><li>Security and administrative overlay on the hosts and network </li></ul><ul><ul><li>Administrative domains </li></ul></ul><ul><ul><li>Firewall boundaries </li></ul></ul><ul><li>Overlays other environment models </li></ul><ul><li>Basis: unknown </li></ul><ul><li>Not (currently) target for Willow reconfiguration </li></ul>
    26. 26. Applying Models to Intrusion Life Cycle <ul><li>Examine the roles that the identified models can play in the steps of the Intrusion Management Life Cycle </li></ul>Detect Repel* Repair* Analyze Prevent* Warn*
    27. 27. Intrusion Detection <ul><li>Most IDS operate at low level of detail: </li></ul><ul><ul><li>e.g. packets </li></ul></ul><ul><ul><li>That is where the big payoff occurs </li></ul></ul><ul><li>Specification-based IDS is closer to our level </li></ul><ul><ul><li>Primarily watches behavior of software systems </li></ul></ul><ul><ul><ul><li>at the level of e.g. system calls </li></ul></ul></ul><ul><ul><ul><li>complementary to architecture models </li></ul></ul></ul><ul><li>Architecture is framework for behavior info </li></ul><ul><li>Reconfigure target system to include intrusion sensors </li></ul><ul><li>Manage IDS system itself (HiDRA project) </li></ul><ul><ul><li>E.g., sensor deployment </li></ul></ul>
    28. 28. Intrusion Repelling <ul><li>Firewall rule changes are common means for repelling attacks </li></ul><ul><li>Reconfigure to temporarily add/drop/modify functionality </li></ul><ul><ul><li>This is Willow approach </li></ul></ul><ul><li>No free lunch: repelling costs resources </li></ul>
    29. 29. Intrusion Warning <ul><li>Notify others of progress of this domain through the life cycle: </li></ul><ul><ul><li>when intrusion is detected </li></ul></ul><ul><ul><ul><li>the local administrator </li></ul></ul></ul><ul><ul><ul><li>other systems (networks, hosts, etc) </li></ul></ul></ul><ul><ul><li>when a repel or repair is successful </li></ul></ul><ul><li>Naively, there appears room for research here </li></ul><ul><ul><li>What happened to CDIF and its successors? </li></ul></ul>
    30. 30. Intrusion Repair <ul><li>Determine state of the compromised system </li></ul><ul><li>Restart components </li></ul><ul><ul><li>From trusted sources </li></ul></ul><ul><li>State repair is hard </li></ul><ul><ul><li>Requires careful checkpointing </li></ul></ul>
    31. 31. Intrusion Analysis [Forensics] <ul><li>Current forensic tools are fairly low level </li></ul><ul><li>Architecture model provides a high level framework for structuring the raw data produced by e.g. core dumps </li></ul><ul><ul><li>Allow an analyst to look for anomalies at the level of the architecture </li></ul></ul><ul><li>Automated Support </li></ul><ul><ul><li>Much of the initial mapping of the core-dump to the architecture can be automated </li></ul></ul><ul><li>Conversations with Rome Labs indicate movement in this direction </li></ul>
    32. 32. Intrusion Prevention <ul><li>Analysis can identify the nature of the attack </li></ul><ul><li>This enables the development of mechanisms for mitigating future attacks of this type </li></ul><ul><ul><li>Patches - require deployment to all affected systems (including running instances) </li></ul></ul><ul><ul><li>General reconfiguration </li></ul></ul>
    33. 33. Issues <ul><li>Analysis of models </li></ul><ul><ul><li>For what? When (online vs offline)? </li></ul></ul><ul><li>Fidelity between running system and the models </li></ul><ul><li>Ability of ADL or ARCH to model running systems </li></ul><ul><li>State management </li></ul><ul><li>Attacks on infrastructure </li></ul><ul><li>Need common representation for all models </li></ul><ul><ul><li>RDF, DAML/OIL, CIM </li></ul></ul>
    34. 34. Next Steps <ul><li>Complete our models for Willow </li></ul><ul><li>Integrate models </li></ul><ul><li>Explore architecture-based IDS </li></ul><ul><ul><li>UC Davis help would be invaluable here </li></ul></ul><ul><li>Explore architecture-based forensics system </li></ul><ul><ul><li>Again, need partner with forensics expertise </li></ul></ul><ul><li>Provide an integrated intrusion management infrastructure = IDS + Willow + Forensics </li></ul><ul><ul><li>Hard </li></ul></ul><ul><ul><li>Longer term </li></ul></ul>
    35. 35. CU - UC Davis Collaboration Opportunity <ul><li>I see strong synergy with Karl’s proposal of last week </li></ul><ul><li>Willow would provide strong candidate for: </li></ul><ul><ul><li>the intrusion control actuation system </li></ul></ul><ul><ul><li>Automated installation and maintenance system </li></ul></ul><ul><li>Willow provides one possible way to respond to intrusions </li></ul><ul><ul><li>Complementary to other approachs </li></ul></ul><ul><ul><li>We currently don’t do detection or forensics </li></ul></ul><ul><li>If there is interest, contact me </li></ul>
    36. 36. Willow - UC Davis Synergy
    37. 37. BACKGROUND SLIDES
    38. 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 <ul><li>Regional CoA Playbooks are predefined to respond to single or multi-domain threats </li></ul><ul><li>Playbooks consists of one or more response primitives </li></ul><ul><li>Automated CoA selection will employ regional CoA playbooks in response to multi-enterprise threats </li></ul><ul><li>Advance research will pursue automated playbook formulation </li></ul><ul><li>Synchronization of regional intrusion control systems will resolve CoA conflicts and overkill </li></ul>
    39. 39. Technology transition: structuring for adaptability <ul><li>Open source framework </li></ul><ul><ul><li>provisions for optional proprietary “plug-ins” </li></ul></ul><ul><li>Interfaces to standard management and security systems </li></ul><ul><ul><li>commercial network configuration and management systems </li></ul></ul><ul><ul><ul><li>OpenView, Tivoli, etc. </li></ul></ul></ul><ul><ul><li>commercial and open-source intrusion detectors and firewalls </li></ul></ul><ul><ul><ul><li>RealSecure, NetRanger, Dragon, snort, EMERALD, etc. </li></ul></ul></ul><ul><ul><ul><li>Gauntlet, PIX, Check Point, Raptor, ipchains, etc. </li></ul></ul></ul><ul><ul><li>internet security management standards </li></ul></ul><ul><ul><ul><li>SNMP, Intrusion Detection Message Format, and others </li></ul></ul></ul><ul><li>Automation for installation and maintenance </li></ul><ul><ul><li>network inventory and configuration </li></ul></ul><ul><ul><li>intrusion sensor deployment, configuration, and activation </li></ul></ul><ul><ul><li>security policy definition and dissemination </li></ul></ul><ul><ul><li>isolation and recovery mechanisms and agents </li></ul></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×