+ All Categories
Home > Documents > Security Alert Systems May 21st, 2003 cs239-1 Martin Lukac.

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

Date post: 21-Dec-2015
Category:
View: 214 times
Download: 1 times
Share this document with a friend
Popular Tags:
28
Security Alert Systems May 21st, 2003 cs239-1 Martin Lukac
Transcript
Page 1: Security Alert Systems May 21st, 2003 cs239-1 Martin Lukac.

Security Alert Systems

May 21st, 2003cs239-1

Martin Lukac

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

Overview●Revere●CERT●Dshield

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

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

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

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

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

Revere● Overlay network

– Large scale– Self organizing– Resilient & Redundant

● Low volume of small messages– Simple lightweight dissemination

● Relatively heavy overlay management

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

RBONE● Three way handshake protocol

First use various waysto locate node

Next, send attach request

Parent decides whetherto adopt

Child decides whether to acceptpotential parent

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

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

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

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?

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

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?

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

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'

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

Authentication● Still need to

authenticate identity and verify messages of other nodes

● Each node may have a different set of authentication schemes

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

Revere Conclusion● Can have multiple Rbones● Good results has potential to be fast

and scale well

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

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

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

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

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

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.

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

Ever more stuff...● Information dissemination

– Web, email, phone, usenet● Alerts

– Advisories– Incident notes and vulnerability notes– CERT summaries

● Security practices and tech tips

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

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

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

Dshield● Distributed Intrusion Detection System

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

Dshield● Take inputs from a lot of different

firewalls and routers● Automatic submission built into clients,

email submission, web submission● Show web pages

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

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?


Recommended