Friday, September 30, 2016

SANS 504 Notes - Process/Preparation

Well, my GCIH certification is up for renewal this year.  This time, since it has been a while since I've reviewed this material, I decided to redo the exam rather than the alternate renewal options.  As such, I'll be starting a series of notes for the SANS 504 course notes.  I remember taking this course way back when, it is a super exciting course and I highly recommend it.  It gives a good base on how to run an Incident and the steps involved.  Ultimately, the tools discussed in this course are real world, and give a ton of insight into how to defend networks/systems against them.

This post will be some points in the first section, around the incident handling process and the preparation phase.

  • What is incident handling
    • an action plan for dealing with the misuse of computer systems and networks
    • generally a set of written policies and procedures that outline what to do when an incident occurs
    • Pre-planning of response parameters/controls/scope
  • An incident refers to an adverse event in an information system or network
    • implies harm or the attempt to do harm
    • contrast to an event, which is any observable occurrence in a system or network
  • Ultimately, the definition of which events are classified as an incident is up to the handler and the company
  • Think of incident handling as first aid
    • incident handlers need a easy method to follow under pressure to resolve issues
    • Core Stages: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned
  • Preparation Phase
    • The WHY:  You need to enable the enterprise, both technically and from a people perspective, to respond to incidents.
    • People
      • Focus on training (sometimes reoccurring training)
      • Test user and the team often
        • fake incidents
        • social engineering attacks
      • Establish communication mechanisms (easy to use) for end users to report suspicious activities (TSA: See something, say something policy)
      • Coordinate with helpdesk staff (they are often the first line of defense against this)
        • establish training plans
    •  Policy
      • Policy should be established
        • in general
        • consequences of insider actions 
        • share information with authorities (or not)
        • peer notification
        • understand breach laws
      • Warning banners allow for lawful recording of actions (also serves to remind users, like airline safety training)
      • Get management buy-in and delegation of authority to the incident response teams
    • Notes
      • maintain excellent notes, preferably in written form on notebooks
      • understand the chain of custody requirements and follow procedures
    • Management Support
      • work to achieve management buy-in
      • show quarterly reports on incidents
    • Building A Team
      • aim for a multi-disciplinary team
        • technical domains (server, network, storage, forensics, etc)
        • Non-technical domains (marketing, law, public affairs, etc)
      • Establish roles if no specific members exist and assign the responsibility to someone
      • Conduct routing training and testing with the team
        • many online resources (counterhack challenges)
        • conduct sessions on log reading, etc
      • Establish appropriate compensation plans (work times, etc)
      • Establish response times, response locations
        • Might need a command post (secure location to sore files and hold meetings)
        • Remote people may be required to be the "techie on site" 
      • Establish a budget for the team ahead of time (no need to seek approvals to spend during an incident)
    • Checklists
      • Have a firm understanding on how to rebuild systems from known good backups or from scratch
    • Emergency communication Plan
      • Create a call list, test this call list
      • identify requirements for secured communication channels (ahead of time)
    • Granting access
      • have an access strategy in place for incident response team members to access critical systems and data
    • Jump Bag
      • thing about the things you will need in an incident
      • Tailor this to your environment
      • Technology: Gold images, rootkit checkers, debugging tools, forensic tools
      • People: clothing, medications, food, etc
      • Other things: cd/usb/media, jumpers, extra harddrives, taps, laptop with multiple OS, call list, cell phones with extra batteries

Sunday, September 4, 2016

A new definition for established traffic

For many years now, the firewall has been the mainstay of network security.  Firewalls make up the core of almost any security regulation, and if not regulated, is a general best practice among security practitioners for segmenting network traffic.  In recent years, Gartner has coined the term "Next Generation Firewall" which essentially stands for firewall capability at the layer 7 level, rather than the traditional layer 4.   

Firewalls generally come in two types, stateful and stateless.  Stateless firewalls are also known as "access control lists".  Keeping no memory, or state, these firewalls can only apply rules to the currently intercepted traffic.  Stateful firewalls, on the other hand, keep track of state and can use this in decision making going forward.  One key feature difference between these two types is the concept of established traffic.  Established traffic is the term applied to data sent that is a "response" to traffic that has already been allowed.  The core idea is that if the originating traffic is allowed, the response should also be allowed.  Let's dive into an example. 

Say a client would like to communicate with a web server.  A general best practice is to allow communication from the internet to the web server (or proxy).  This is required in order for the web server to serve content.  A webserver would be pretty useless if it could not talk back to the client with it's response to the client request.  In stateless firewalls, one would have to allow all traffic originating from that web server which is destined for the internet.  This can be a bad security practice as we, generally, want to control outbound communication.  A stateful firewall, on the other hand, can use the established traffic concept to allow that response through without the need for an allow rule. 

This definition and application of established traffic has worked well for use cases such as web servers.  But what about other traffic?  Specifically, traffic where outbound communication is required, but we still want it to be controlled.  This is where I propose that we need to extend the concept of established traffic. 

Many organizations struggle with implementing a comprehensive set of controls to protect client networks from attack.  Without getting too technical, controls are needed to prevent all stages of the attack lifecycle (recon, delivery&exploitation, installation, command&control). Generally speaking, the  following set is employed in some fashion: 
  • Antivirus on the desktop 
  • Web filtering as a proxy 
  • Blocking of traffic not through a proxy 
  • IDS/IPS on incoming traffic 
  • SSL/TLS Decryption as required 

There are several problems with the above control set.  Even if applied correctly, and ignoring the costs of doing so, this solution is still not complete.  Some of the ones that I can think of are: 
  • Antivirus is great for Windows, but incomplete on other platforms/devices 
  • Proxy cannot always be set up, especially in a BYOD environment. 
  • SSL/TLS decryption is an invasion of privacy and becoming more and more ineffective as sites use certificate pinning 
  • Controls are ineffective when devices leave the corporate network 

So, given the above, what is a company to do?  Outbound communication is required for the business to function, but, in allowing this, open up attack vectors that allow for the delivery, exploitation, installation, and command of client machines.  One solution to this problem that I really like is the idea of DNS firewalling.   

In DNS firewalling, hosts have their DNS pointed at a particular DNS firewall.  The DNS firewall can then intercept DNS requests, enforce policy at that point, and only service IP addresses back that are known good (or at least, thought to be known good).  Here are some pros: 
  • Solution does not require interception of raw traffic 
  • Solution allows for both whitelisting and blacklisting 
  • Standard approaches such as threat intelligence and behavioral monitoring can be employed 
  • Solution extends beyond the corporate network 

Further to the list above, the solution helps with some of the most current domain switching techniques that modern malware is employing.  At this point, you are probably asking, what does this have to do with established traffic? 

I think that the definition of established traffic needs to include communication with a specific IP, if and only if, that IP has been returned as a result of a DNS request made (to an approved DNS server) and if it conforms to an approved port. 

Let's look at a firewall setup for a client network that needs access to the internet.  This client network has been configured to use some type of DNS firewalling service. 
1) Allow DNS traffic to DNS firewall from client network 
2) Block DNS traffic to internet from client network 
3) Allow HTTP/HTTPS/Other to Internet from client network 
4) Deny all traffic 

The addition and requirement of firewall rule 3 is dangerous.  Any IP based communication, on an approved port, will be allowed to the internet, and I cannot guarantee that this request was first processed by my DNS firewall. I need a firewall provision that ensures that communication with an IP is first approved by my DNS firewall, then allowed.  Hence the addition to the idea of established traffic. 

In my research, most DNS firewall capabilities are focused on the DNS request/response.  While they do offer integration with other devices, no firm method has been devised as of yet to govern this type of traffic.  I'm curious what people in the community do to solve for this, and if there are any products that integrate the network and DNS firewalls seamlessly.  All comments are welcome!