Security Event System (SES) Joint Techs July 2009

Size: px

Start display at page:

Download "Security Event System (SES) Joint Techs July 2009"

Ophelia Wiggins
6 years ago
Views:

1 Security Event System (SES) Joint Techs July 2009

2 Credits SES is a project in the REN ISAC community, with project funding from: the U.S. Department of JusKce, and the cooperakon and support of: Internet2, Internet2 CSI2 WG, Barely3am SoluKons, Indiana University, Carnegie Mellon University (relakon to the EDDY project), and Argonne NaKonal Laboratory (relakon to Federated Model project).

3 Idea Improve Kmely local proteckon against cyber security threat, by means of real Kme sharing of security event informakon within a trusted federakon, and among federakons. At its root, not a new idea. Security event informakon is being shared now, in private and semi private communikes, and some public sources. But there are issues

4 Issues with Current Methods Current methods are cumbersome Much reliance on e mail Not easily automated, oven requires the human interrupt signal Not structured for correlakon MulKple non standard data representakons Not easily consistently parsed or acted on Hard to determine confidence Long term intelligence is difficult to obtain Data is hostage to our inboxes Difficulty of correlakon Difficulty of coordinated or cooperakve analysis MulKple FederaKons Trust relakonships PoliKcal and organizakonal boundaries Yields disincenkves for sharing, and difficulty ackng on shared intel

5 SES In Its Simplest In a security informakon sharing federakon, such as REN ISAC, guided by policy and informakon sharing agreements, machine (aggregated) and human generated security event data, is normalized to standards based data descripkon, and through various supported secure interfaces, is submiaed to the SES repository. CorrelaKon is performed on the collected data, idenkfying bad actors and determining confidence. High confidence bad actor data is formed into a "detect these" feed, and analysts vet high confidence bad actors into a "block these" feed. ParKcipaKng sites pull down the "detect these" and "block these" feeds and apply local proteckons against the bad actors.

6 Discovery, CorrelaKon, and ProtecKon

7 Supported Data Types IP address, represenkng just about any type of compromised host or source of threat, e.g. botnet C&C or drone, DDoS source, scanner, etc. CIDR, either represenkng a miscreant heavy address range, e.g. RBN, or as addikonal qualifying informakon ASN, as addikonal qualifying informakon DNS name, represenkng for example, a botnet C&C URL represenkng for example, a malware download site E mail address, for example, a phishing Reply To: address

8 Inside the ParKcipaKng Site OpKonal uses of SES data, and submissions to SES

9 Query Interface: Tool for the Security Analyst

10 Inter FederaKon Sharing Across Policy Boundaries

11 Building a SoluKon Loosely based on concepts started with the ANL Federated Model Standards based IETF IDMEF standard for represenkng security event messages in XML IETF IODEF standard for represenkng incidents in XML Extensions Understanding "Sites" (via ASN, CIDR) Understanding URIs Understanding "FederaKons Request Tracker for Incident Response (RT+IR) Nicely solves the UI, ACL and workflow problem Allows us to build on exiskng, rich, open source technology. Database performance considerakons Open source InteroperaKon with CMU EDDY (End to End DiagnosKc Discovery) As opkon for local event aggregakon and transport

12 Phase I SoluKon Context of REN ISAC trust federakon Pilot deployment in REN ISAC, end of July Full scale produckon in REN ISAC, end of September(?)

13 A framework for Building a Framework Intra and inter federakon cooperakon IncorporaKon of addikonal correlakon and analysis tools Interface with systems that nokfy abuse contacts regarding infected systems, e.g. the REN ISAC nokficakon system Interface with systems that treat higher level colleckons of incident informakon in a federated context Extending the framework Long term intelligence storage Threat analysis plakorm

14 What meaning for the Typical JT Aaendee? How might nakonal, regional, or state networks, or exchange points be a data provider or consumer? Exchange points? How do you relate with your members w.r.t. security?

15 Contacts Doug Pearson isac.net Wes Young

MILE Implementation Report. Chris Inacio, Carnegie Mellon University Daisuke Miyamoto, The University of Tokyo

MILE Implementation Report. Chris Inacio, Carnegie Mellon University Daisuke Miyamoto, The University of Tokyo MILE Implementation Report Chris Inacio, Carnegie Mellon University Daisuke Miyamoto, The University of Tokyo daisu-mi@nc.u-tokyo.ac.jp Updates in Section 2 Information Sharing and Analysis Centers (ISAC)