Skip to main content

Resources

{Article} 50+ Incident Response Preparedness Checklist Items

{Article} 50+ Incident Response Preparedness Checklist Items

Download the Checklist

The #1 question organizations need to ask themselves is “if someone was in our network, would we be able to tell?” An organization’s ability to answer that single, extremely important question makes all the difference between being able to respond and recover from an incident quickly (and cost-effectively) vs. being notified by a user, or worse yet, by a federal agency, that something is amiss. Be honest with your answer; most organizations are unable to say “yes” to this question, and it rightfully keeps many networking admins or information security professions awake at night. If you are uncertain how to go about detecting an incident on your network, you are certainly not alone. Here’s a primer to get you started.

 

Where to Start

Preparing for an incident means that you have all your ducks in a row in advance so if an incident happens, you can work through the post-incident phases of Incident Response, including detection and analysis; containment, eradication, and recovery; and post-incident items, efficiently and quickly. You will need the following items prepared ahead of time:

  • Configurations
  • Logging
  • Vendor Information
  • Key Personnel

 


Configurations

GearsHave the following items configured and in place to be fully prepared for an incident:

  • Network Time Protocol (NTP) must be turned on and configured for all devices that will be sending logs.
  • Pre-incident policy and procedure must be established, documenting items such as the members and roles of an IR Team, identifying, protecting against, and detecting potential incidents, etc.
  • Establish a central logging capability (syslog, syslog-ng, snare, etc.)
  • Establish how change management needs to occur during an incident, or how you will handle changes to the network and IT assets in an organized manner. Cycling affected devices, emergency changes to systems affecting uptime of services, critical fix deployment, items that may hamper containment, etc.
  • Establish a “one user, one account” rule for accountability reasons; sharing of accounts should never be allowed!
  • Establish secondary accounts for privileged access and changes, for accountability reasons. Never use a domain admin or privileged account to answer email or browse the Internet.
  • Ensure service accounts are assigned only to the services they run.
  • Store an offline copy of your most recent Asset Inventory to be used for forensic investigations.
  • Create a jump bag with the following contents:
    • Sanitized drives for drive images
    • Incident forms – can be electronic on a laptop or mobile device in the bag
    • Printed copy of Incident Response Team (IRT) call tree
    • Common hand tools such as screwdrivers or a Leatherman
    • Linux live distributions such as Sift, Security Onion, and Kali on bootable DVDs and USB sticks
    • Mandiant Redline on a USB Drive
    • Wireshark on a USB Drive
    • Flash light and extra batteries
    • Checklists of all forensic software that might be needed for investigation. Applications like Mandiant Redline and Sleuth Kit should be on this list
  • Network tap and LAN cables, or the capability to create span ports on your switches.
  • A secure communication channel for the IRT that cannot be monitored by an attacker or inside; examples may include cell phones or secondary encrypted email system.
  • First responder training for help desk or customer-service employees, including knowing what to look for and how to “push the red button” for potential incidents. Frontline staff are your human sensors.
  • Define how incident forms or help-desk tickets are reported upstream – make sure these are encrypted so potential attackers and insiders can’t access or eavesdrop on your ticketing system.
  • Establish regular Incident Response testing – work through common IR scenarios and identify areas of improvement, especially communication and command structure. Budget to conduct continual training. Triage should be tested and trained. Service level agreements, vendor agreements, and incident command should be worked through and tested. Periodically conduct IR drills – use network testing (Penetration Testing) separate from the IRT if possible.
  • Establish a secure evidence room with locking cabinets to facilitate secure collection of evidence and ensure no modification by attackers or insiders.
  • Establish “Watch and Learn” or “Pull the Plug’ criteria. “Watch and Learn” means you will watch the attacker work through the attack for a bit before pulling the plug on them as a means of gathering evidence. “Pull the Plug” means you will eradicate the threat before gathering evidence.
  • Establish “contain and clean” criteria based on desired evidence preservation for each incident type
  • Establish and understand legal and regulatory requirements for responding to and reporting on breaches in your specific industries, states, and nations.
  • Establish a process for determining and handling criminal activity performed by employees. This item only applies to an incident where an employee is the attacker and it is not an outside threat.
  • Establish organization’s stakeholder expectations. For example, Board of Directors, shareholders, supporters, adversaries, participants, and partners in the value chain. Ensure the IRT understands these expectations.
  • Establish criteria for continual review of preparation items in this list.

 


Logging

FileAt a minimum, turn logging on in the following areas:

  • Firewall Logs - both ingress and egress logs are necessary for proper log correlation in an incident
  • Internet Service Provider (ISP) Traffic Logs
  • IDS / IPS Logs
  • AV Logs
  • Web Proxy Logs
  • Content Filtering Logs
  • Windows Event Logs
  • Active Directory (AD) Logs
  • Unix / Linux Logs
  • VPN / Remote Access Logs
  • DNS Logs
  • SIEM Logs
  • Data Loss Prevention (DLP) logs
  • Mail Server Logs
  • SQL and Database Logs
  • Switch ACL logs

 


Vendor Information

PeopleHave the following information readily available for vendors that pertain to the management of your network, data, IT assets, or applications:

  • Vendor Name
  • Contact Information
  • Log retention period in months
  • Response time during incident
  • Who can access the logs

 


Key Personnel

KeyHave the following information readily available for key organization personnel involved in Incident Response and functional areas of your organization

  • Name
  • Phone Number
  • Email Address
  • Role in the organization
  • Role during an incident

 

The items above are necessary for your organization to be fully ready to detect and respond to the current attacking threats that exist in the wild. Unfortunately, most organizations that experience an incident find these items out after the incident and are ill-prepared to defend their organization. Threats ranging from malware unidentified by the Anti-Virus community to Advanced Persistent Threats like organized crime syndicates and state-sponsored attackers affect organizations of all shapes and sizes each day. Don’t trick yourself into believing nothing will happen to your organization because you’re a small business in a small town; bad guys don’t care. Most of these attacks are automated and simply look for the “low-hanging fruit” – unpatched vulnerabilities, default credentials, or unmanaged networks. Utilizing the above information and having it ready for action can mean the difference between failing well and failing horribly.

 


Detection

HackerNow that your organization is prepared for an incident, how do you detect one? The answer isn’t simple to explain, but detection can be simple for IT folks that understand “what normal looks like” on their network. The detection capability comes from watching the logs specified above and looking for anomalies or separations from the baselines of your network.

At a minimum, watch logs in these key areas:

  • Total Network Logs per Second
  • Patch Management % / Known Vulnerabilities
  • Denied FTP Requests
  • Denied Telnet Requests
  • Failed Remote Logins
  • VPN Connections / Failed VPN Connections
  • Blacklisted IP Blocked
  • Branch Connectivity Lost
  • New Admin Credentials created
  • Threshold for successive account lockouts
  • VLAN ACL violations
  • Changes to Group Policy
  • Increase in network bandwidth
  • Increase in outbound email traffic
  • DNS Request anomalies

 

SBS recently helped a client with incident analysis, containment, and eradication; if the client had been monitoring their ISP traffic baseline, they would have seen it skyrocket to over 200% of normal in just a few days’ time. That is a red flashing light! During another incident, the client was able to detect a problem because domain accounts were seemingly randomly being locked out suddenly. That brute force dictionary attack indicator led us to discover a zero-day malware exploiting and worming through their network.


The moral of the story is this: be prepared and know how to not only identify and prepare for an incident, but also how to detect when something out of the ordinary is happening on your network.

 


How to Mature Your Incident Response Plan

Maturity in Incident Response comes from practicing the skills necessary for successful Incident Response. Assigning resources in your organization and setting up a sterile test network for those resources to practice is a must for organizations serious about network defense. The key skills that any Incident Response Team need include the ability to:

  • Detect anomalies or separations from the baselines established on your network
  • Contain network resources either by closing network segments or restricting access to network resources
  • Eradicate the threat by eliminating its access to your network resources
  • Recover and return to normal business operations.


More advanced skills include using tools such as Redline and Wireshark to investigate and analyze threat activities. These should be considered once resources have mastered the basics of detection, containment, and eradication.


As with all processes, maturing your Incident Response Plan will take time, practice, and experience. However, with the sheer number of attacks and breaches that make the news each day, not to mention all of those that don’t, organizations that rely on technology to perform day-to-day operations can’t afford not to ensure they have the capacity to perform good Incident Response when, not if, things do go wrong.
 

Download the Checklist


Written by: Buzz Hillestad - Senior Information Security Consultant - SBS CyberSecurity, LLC
and Blake Coe - Vice President, Network Security - SBS CyberSecurity, LLC


 

SBS Resources:

  • {Service} Incident Response Planning: An SBS consultant can assure your well-structured Incident Response Plan (IRP) will help mitigate the negative effects of a security breach, as well as demonstrate to examiners that your organization is properly prepared to handle such an event.
  • {Blog} Threat Intelligence - What Does it Look Like?:  To stay on top of emerging threats you can invest in threat intelligence; this not only helps you stay aware of any new and emerging threats making their way across the internet, but also monitor potential threats targeting your business network. Developing a Threat Intelligence Plan that outlines how you plan to monitor new cyber threats and attacks can provide great benefit to your business, and it doesn’t have to be a huge undertaking. 
  • {Hacker Hour} Incident Response Round Table: Join SBS for this free webinar in which we will discuss best practices to write and test your incident response plan.  We will also walk through some common scenarios that should be considered in your plan.


Related Certifications:

Join our growing community of financial service professionals showing their commitment to strong cybersecurity with a cyber-specific certification through the SBS Institute. Click here to view a full list of certifications.
Certified Banking Incident Handler   


Hacker Hour webinars are a series of free webinars hosted by SBS CyberSecurity. Unlike paid webinars, Hacker Hours are aimed to meet on a monthly basis to discuss cybersecurity issues and trends in an open format. Attendees are encouraged to join the conversation and get their questions answered. SBS will also offer products and services to help financial institutions with these specific issues.

Posted: Tuesday, April 17, 2018
Categories: Blog