1 / 68

A New Detection Framework

This article discusses the need for a new detection framework for client attacks, which have become more common and harder to detect. The NRT Framework aims to fill the gaps in current systems and provide a scalable and extensible solution for detecting and responding to these attacks.

Download Presentation

A New Detection Framework

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. What would you do with a pointer and a size? A New Detection Framework

  2. Define the problem Why do we need a new detection framework?

  3. The Challenge is Different • Attacks have switched from server attacks to client attacks • Common attack vectors are easily obfuscated • JavaScript • Compression • File formats are made by insane people • Looking at you Flash and OLE guy… • Back-channel systems are increasingly difficult to detect

  4. Network Systems… • Inline systems must emulate the processing of 1000s of desktops • Detection of many backchannels is most successful with statistical evaluation of network traffic

  5. Coverage Gap • Broadly speaking, IDS systems deal with packet-by-packet inspection with some level of reassembly • Broadly speaking, AV systems typically target indicators of known bad files or system states

  6. Fill the Gap • A system is needed that can handle varied detection needs • A system is needed that extensible, open and scalable • A system is needed that facilitates incident response, not just triggers it • So……

  7. NRT Framework Near-Realtime Detection Framework or: “Anything is Possible”

  8. Framework Goals • Provide entry to the system for any arbitrary data type • Determine and manage detection based on a registered Deep Inspection Nugget • Provide alerting to any framework capable system • Provide verbose, detailed logging on the findings of the Nugget Farm • Make intelligent use of all data discovered during the evaluation process

  9. The Dispatcher • The heart of the NRT system • APIs to handle: • Deep Inspection Nugget registration • Data Handler registration • Detection requests • Alerting • Full analysis logging • Output to API compliant systems • Database driven

  10. The Dispatcher • Implements a database to provide a centralized set of data chunk information • Handles incoming queries for Data Handlers that have failed local cache hits • Handles detection requests from both Data Handlers and DINs • Handles incoming results from Deep Inspection Nuggets • Handles database updates based on DIN data • Writes out verbose logging based on DIN data • Provides alerting to Data Handlers

  11. Data Handler • Capture data and metadata • Contact dispatcher for handling • Has this data been evaluated before? • Where should I send it? • Pass that data set to a Deep Inspection Nugget • Accept feedback from the Dispatcher for detection request • Asynchronous alerting • Local cache of detection outcome

  12. The Data Handler • Data (in this case a file) is captured • Metadata is captured (in this case URL and filename) • A local cache of MD5 sums and URLs of files previously collected • A library to handle managing the initial file evaluation, cache checks and communication with the Dispatcher

  13. Deep Inspection Nugget (DIN) • Must handle data transfer from Data Handlers • Must communicate with Dispatcher • Register detection capability • Request for additional processing of subcomponents • Provide alerting feedback to Dispatcher

  14. The Deep Inspection Nugget • Registers with the Dispatcher • Processes data provided by the Data Handlers, as instructed by the Dispatcher • Handles incoming queries for Data Handlers that have failed local cache hits • Handles detection requests from both Data Handlers and DINs • Handles incoming results from Deep Inspection Nuggets • Handles database updates based on DIN data • Writes out verbose logging based on DIN data • Provides alerting to Data Handlers

  15. The Design An implementation of the NRT goals on a Snort platform Target: Malicious pdf files

  16. More info about the nuggets Let’s pretend that the PDF nugget already has the data…

  17. The Dispatcher Why are we passing back files?

  18. We Like Data • MD5 is stored for all inspected data – packets, files, and subcomponents, both bad and good • Primarily this is used to avoid reprocessing data we’ve already looked at • But after a update to any DIN, all known-good entries are “tainted”

  19. Why Taint known good? • After an update to detection, previously analyzed files may be found to be bad • We don’t rescan all files • But if we see a match for md5 to a previous file, we will alert retroactively

More Related