NIST Incident Response Plan: An Overview
January 13, 2016
The National Institute of Standards and Technology (NIST) provides guidelines on what they beleive to be the best way to respond to cyber security incidents. Read on for an overview of the NIST Incident Response plan, and how it can help your organization.
NIST Computer Incident Security Handling Guide
The NIST Computer Incident Security Handling Guide is meant for large organizations, but if you wanted to adjust it to apply to your small business, it is very possible to do so. NIST only provides the guidelines, they aren’t going to hold your hand through the process. This leaves you free to mold these guidelines to suit your needs.
There are three main sections:
- Incident Handling
Section 1: Organization and Communication
First up in the guide is organization. If you have three people notifying the boss, but nobody called in the security specialist, or took appropriate measures to isolate the computer(s) from the network and quarantine the area. Well, you have a few real problems to fix. Staff need to have designated roles and be properly trained to effectively react in these situations. Make sure that everyone knows who to contact in case of a security breach.
NIST calls for very specific actions regarding media contact. Giving out too much information (or incorrect information) can damage the investigation and the company reputation. This is especially important for highly visible companies. The media probably isn’t coming to a small business for interviews, there’s usually not enough public interest. Large corporationsm, such as Sony and Microsoft are watched closely by media outlets when they are attacked because everyone knows who they are, and often times the stakes of data loss are higher. If the media comes knocking, you need to be sure that only one representative communicates with them.
NIST also calls for a single point of contact with law enforcement agencies. Only one person should notify the authorities. and should contact a single agency where possible. If multiple law enforcement organizations get involved, there could be jurisdictional issues that slow down response time. Of course if your attacker is in another state, there are going to be multiple agencies involved.
It’s also important to establish a full documentation of the incident, including the chain of custody for all evidence. Should you find the attacker(s), evidence needs to be organized for prosecution. Don’t let your attacker off the hook just because you had poor documentation of the incident or evidence mishandling!
Section 2: Incident Response
I love that this section begins with preparation. There’s an old saying that the best defense is a good offense. How does that apply to cyber security though? Simple! Attack your own network. Hire ethical hackers to find flaws in your network and take the necessary steps to minimize them. Don’t just sit around until something happens, be proactive!
NIST offers an awesome list of tools and resources for incident recovery. Tools such as:
- A Contact list for key incident response personnel
- Encryption software for communication both internally and outside the organization
- Laptops for analyzing network traffic (this is were those ethical hackers come in)
- Evidence gathering tools and a secure area to store evidence and sensitive materials
- Forensic Software for disk analysis
- Documentation of all software used (operating systems, anti virus, applications)
- Access to clean operating system images
This is just a small sampling of NIST’s recommended incident response tools. There are plenty of other great tools in the list so be sure to check it out.
How do I know there was a security incident in the first place?
There are many ways to identify a security breach. Network logs, file integrity checkers, anti-virus, monitoring tools, and more are all available to let you know something unusual occurs.
Beyond the standard tools, user training is essential. Malware is not always evident. While the more obnoxious threats will pop up a screen saying something like “The FBI has locked your PC, pay ___ to unlock it”, the real threats are the silent ones such as key loggers, root kits, and backdoors. These are not always apparent, but a keen eye might notice something wrong.
Security professionals are not the only people who require this type of awareness. For example, I recently had a computer start acting a bit sluggish. A quick check of the resource monitor hinted that something was off. Far too much of the hardware resources were being consumed for the programs open, and closing them changed nothing. I did a reboot, found the problem persisted, and noticed odd network activity. I immediately unplugged my Ethernet cable, disabled my network interface and contacted the IT department to check it out for me. Was there actually malicious software on there? I don’t know yet. But my quick action may have prevented the spread of malware across the network. Properly training users to identify potential threats could be the difference between one infected PC and an entire office of infected computers.
Section 3: Information Sharing and Coordination
Communication and coordination are what make the tools discussed earlier effective. It’s important to relay information to external groups like Internet Service Providers (ISPs), partner organizations, and law enforcement. Communicating what happened could help others avoid a similar issue. ISPs can help track down the attacker and law enforcement can take down their own documentation of what happened (this may be of use if you end up taking the attacker to court).
One thing I love about the NIST guidelines for communication is that they encourage companies to reach out to others before an incident, and establish an incident coordination plan. This is especially important for contacts outside your company. You don’t want to be trying to figure out who you need to talk to at your ISP or law enforcement agency in the middle of an incident. Call ahead of time, figure out who can help you when an incident occurs, and work with them to establish a solid plan of action in the event of a security breach.
Communicate Information on an Need to Know Basis
One of the most important points of this section is to ensure that you are only communicating the necessary information. You have to be careful that you aren’t sending sensitive information to people that don’t need to see it. There is an entire subsection in this topic in the NIST incident response guidelines, and it does a great job of outlining how you can determine what information needs to be shared.
NIST Incident Response Is Not All Inclusive
Remember the NIST guidelines do not recover incidents relating to power failure, natural disasters, or any non computer related events. However, you should keep in mind that these events can certainly affect the security of sensitive data and you should prepare for them.
If your power goes out and there is no backup plan, not only could you lose critical data, but your electronic security measures are no longer operational. Solid State Drives (SSD) are particularly vulnerable to power issues. Losing power during a write process on a SSD could lead to drive failure. Check out this article on the effects of power outages on computers for more information on this. Further more, if your security cameras are offline and an employee walks out with sensitive data on a hard drive, you have no proof. An incident response plan needs to be built closely along side an incident prevention plan, to stop that employee from stealing sensitive documents in the first place.
Overall the NIST guidelines are a fantastic tool for developing an incident response plan. Whether you follow NIST, or develop your own system, just be sure that you have a solid incident response plan at your organization. For more information on NIST guidelines visit the NIST website. We also provide Incident Response training for individuals tasked with those important responsibilities in their organizations.