Senin, 26 November 2012

Why Collect Full Content Data?

I recently received the following via email:

I am writing a SANS Gold paper on a custom full packet capture system using Linux and tcpdump. It is for the GSEC Certification, so my intent is to cover the reasons why to do full packet capture and the basic set up of a system (information that wasn't readily available when setting my system up)...

I am already referencing The Tao of Network Security Monitoring.

These are the questions that I came up with based on questions other peers have asked me...

Here are the questions, followed by my answers. Most of this is covered in my previous books and blog posts, but for the sake of brevity I'll try posting short, stand-alone responses.

  1. As an information security analyst in today's threat landscape why would I want to do full packet capture in my environment? What value does have?

    Full content data or capturing full packets provides the most flexibility and granularity when analyzing network-centric data. Unlike various forms of log data, full content data, if properly collected, is the actual data that was transferred -- not a summarization, or representation, or sample.

  2. Where should I place a full packet capture system on my network - are ingress/egress points sufficient?

    I prioritize collection locations as follows:

    • Collect where you can see the true Internet destination IP address for traffic of interest, and where you can see the true internal source IP address for traffic of interest. This may require deploying two traffic access methods with two sensors; so be it.
    • Collect where you can see traffic to and from your VPN segment. Remember the previous IP address requirements.
    • Collect where you can see traffic to and from business partners or through "third party gateways." You need to acquire the true source IP, but you may not be able to acquire the true destination IP if the business partner prevents collecting behind any NAT or security devices that obscure the true destination IP.
    • Collect where your business units exchange traffic. This is more of a concern for larger companies, but you want to see true source and destination IPs (if possible) of internal traffic as they cross business boundaries.
    • Consider cloud or hosted vendors who enable collection near Infrastructure-as-a-Service platforms used by your company.
  3. What advantages are there to creating a custom server with open source tools (such as a server running Linux and capturing with tcpdump) opposed to buying a commercial solution (like Solera or Niksun)?

    A custom or "open" platform enables analysts to deploy the sorts of tools they need to accomplish their security mission. Closed platforms require the analyst to rely on the information provided by the vendor.

  4. Now that I have full packet data, what kind of analysis goals should I have to address advanced threats and subtle attacks?

    The goal for any network security monitoring operation is to collect and analyze indicators and warnings to detect and respond to intrusions. Your ultimate role is to detect, respond to, and contain adversaries before they accomplish their mission, which may be to steal, alter, or destroy your data.

  5. Any other advice for an analyst just getting started with full packet capture systems and analyzing the data?

    Rarely start with full content data. Don't dump a ton of traffic into Wireshark and start scrolling around. I recommend working with session data (connection logs) and application-specific logs (HTTP, DNS, etc.) to identify sessions of interest, then examine the content if necessary to validate your suspicions.

I could write a lot more on this topic. Stay tuned.

0 komentar:

Posting Komentar