1 / 28

Security Alert Systems

May 21st, 2003 cs239-1 Martin Lukac. Security Alert Systems. Overview. Revere CERT Dshield. Revere. Designed for rapid and widespread dissemination of information on a VERY LARGE SCALE Warning signals Firewall updates Intrusion detection system updates Certificate Revocation

hmargaret
Download Presentation

Security Alert Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. May 21st, 2003 cs239-1 Martin Lukac Security Alert Systems

  2. Overview • Revere • CERT • Dshield

  3. Revere • Designed for rapid and widespread dissemination of information on a VERY LARGE SCALE • Warning signals • Firewall updates • Intrusion detection system updates • Certificate Revocation • Virus updates • Software security updates

  4. Difficulties • Need for speed • Must be faster than attacks • Need for scalability • Not totally centralized • Must expect variability • Guarantee of coverage • Redundancy so there are no cut off points • Security • Duh! Very tempting target

  5. Revere • Overlay network • Large scale • Self organizing • Resilient & Redundant • Low volume of small messages • Simple lightweight dissemination • Relatively heavy overlay management

  6. RBONE First use various ways to locate node • Three way handshake protocol Next, send attach request Parent decides whether to adopt Child decides whether to accept potential parent

  7. Handshake cont. • There are timeouts • Each node wants multiple parents • Nodes continuously search for parents • Number of parents predefined • Nodes also have predefined limit for the number of children • Adjusting the limits affects the resiliency of the RBONE as well as the bandwidth and overhead of each node

  8. Parent Selection • Want to select parent to achieve possible efficiency and resiliency • Multiple parents so node only misses update if all its paths back to center are broken • One parent is along the fastest path back to dissemination center • Other parents have paths as disjoint at possible back to distribution center How find these paths?

  9. Parent Selection cont. • Path vector: potential path for delivering security updates from a dissemination center to a node • Parent path vector: ppv(n,p) = fastest path from center to n with p as the last hop before n • Node path vector: npv(n) = fastest parent path vector among all of n's parents How compare resiliency?

  10. Resiliency comparison • Start with fastest parent • Compare every other PPV to fastest parent by number of overlapping nodes along path • Greater overlap means weaker resiliency • Will end up with parents with same resiliency • Choose highest resilient parent, and repeat first step with this parent as the 'fastest parent'

  11. Selection • Potential parents sends their NPVs along with their AttachACK • The node uses the potential parents NPV and the RTT to derive its PPV • RTT obtained from AttachReq • The node then compares all the resiliency of all the PPVs

  12. Adaptive • What is done when node goes down? • Explicit notification • Tear down messages • Not reliable • Implicit notification • Heartbeats • Carry other useful information • Timestamps (for RTTs), changed NPVs (for dynamic adjustment of child NPVs)

  13. Dissemination • Push • Store and forward from dissemination center • Clearly nodes get multiple copies, so updates carry sequence numbers • Pull • All nodes do not keep updates • After being temporarily disconnected or turned off, nodes can query for updates • Queries go to repository nodes

  14. Repositories • Dynamic • Nodes nominate themselves to be a repository • Add themselves to repository candidate list • List propagates through heartbeats back to center • Center selects repositories from list • Propagates choices back through heartbeats • Handles failures and demotions all through heartbeats

  15. Security Threats • Security update interception • Dropping, misdirecting, delaying, damaging, forging, or replaying security updates • Repository corruption • Tampered or incomplete updates • Key theft at dissemination center • Center impersonation • RBone attack • False RBone information, replay control messages, impersonation

  16. Dissemination Security • Public key crypto approach • Center signs all updates • Multiple resilient delivery paths • Helps make sure updates get everywhere • Helps against subverted repositories • Nodes can contact more than one repository • All nodes do duplicate checking

  17. Key corruption • Impersonation detection • Out of band • Reverse traversal back to center • Key Invalidation • One simple message: Revocation, signed by revoked key • Switch to new pre installed key • Redeliver missed or corrupted updates

  18. Rbone Security • Each node sets up its own rules for trust judgment • No centralized control • Different trust levels: complete trust, selective trust, and no trust • Direct trust • Node trust configured • Indirect trust • Deduce trust based on third parties, or use trust authority (like CA, but for trust, not identity authentication

  19. Authentication • Still need to authenticate identity and verify messages of other nodes • Each node may have a different set of authentication schemes

  20. Revere Conclusion • Can have multiple Rbones • Good results has potential to be fast and scale well

  21. CERT • Computer Emergency Response Team • At Software Engineering Institute at CMU • DARPA funded • Started after Morris worm in November 1988 • They do lots of stuff

  22. What CERT does... • Vulnerability analysis and incident handling • Monitor public sources of info • Receive vulnerability reports • Work with vendors • Since 1988, they've received more than 642,365 email messages and more than 21,895 calls reporting computer security incidents or requesting information, and they've handled more than 182,460 computer security incidents

  23. More stuff... • Education and training • Survivable network technology • Analysis of how susceptible systems are • Finding ways to improve the design of systems • Developing techniques to assess and predict current and potential threats to the Internet. Involves examining large sets of network data to identify unauthorized and potentially malicious activity.

  24. Ever more stuff... • Information dissemination • Web, email, phone, usenet • Alerts • Advisories • Incident notes and vulnerability notes • CERT summaries • Security practices and tech tips

  25. AirCERT • Place Internet-based security event sensors on the networks of various organizations • The sensors will log locally selected information on detected security events and anomalies to both a local database and a central database located at CERT • Developing prototype system using open source and low-cost components • They hope to get to get all sorts of sensors from different vendors to work together

  26. Dshield • Distributed Intrusion Detection System

  27. Dshield • Take inputs from a lot of different firewalls and routers • Automatic submission built into clients, email submission, web submission • Show web pages

  28. Questions • Revere • What do we do with the updates? Trust? Sometimes easy to decide, sometimes not • What if a router goes down? Even though paths are separate on the application level, still might be going through the same routers • Should vendors be responsible for creating the dissemination centers? CERT? Govt? • Does Dshield really help? • Will there ever be a point when a system like Revere might prevent a new attack?

More Related