Good advice can be hard to find. IT security is continuously a subject of blogs, articles, and white papers, many written by or for a vendor. The National Institute of Standards and Technology (NIST) has produced its own new publication, the "Computer Security Incident Handling Guide". This vendor-neutral guide sells no products, does not limit its discussion to just one issue but covers many, and is a reference for the future. It is not a guide to read overnight, but a 79-page book for those dealing with IT security. Most of the recommendations are just as valid for communications security.
This is very important because there appears to be no end of security attacks and data breaches. The enterprise must be ready to document, analyze and track down the attack to resolve it and prevent its reccurrence.
The guide has a series of recommendations valid for government, business and academic institutions:
* Create an incident plan and policy for the organization including on-premises and cloud-based services.
* Incident response and reporting procedures should be developed and followed; this should not just be a paper plan.
* Set guidelines for communicating with every possible organization, internal such as the legal department and external such as law enforcement agencies.
* Determine the incident response team structure and the qualifications necessary to be a member of the team staff
* The services that the incident response team should provide and to whom must be established.
* Don't forget that the incident response team needs training, not just once but ongoing.
One point that was made in the guide is that it is less costly to prevent a security incident than to resolve one. Security breaches not only cost the enterprise, they may damage their reputation and eventually their customer base. The goal of the incident response team is to reduce the number of incidents in the future.
Documentation of the incident and its resolution are very important. This information should be used to build better protection. This information should be shared with interested organizations such as law enforcement agencies, service providers, and vendors. The parties that should share in the documentation should be determined in advance, not after an incident occurs.
The guide offers a list of attack vectors--methods used in security breaches--for which procedures should be in place for prevention and remediation. Some examples of attack vectors:
* An attack can be executed by inserting removable media such external disk drives, flash drives, and CDs.
* An attack may use brute force methods to degrade, destroy or compromise a network or systems--this is called attrition.
* Web based attacks are all too common.
* An attack can be part of an e-mail message or attachment.
* Organizations have developed and published security policies and procedures. Attacks can occur when these are not followed or enforced.
* When equipment is lost or stolen, it can be used as an attack tool.
The guide also provides three other guidelines.
1. "Organizations should emphasize the importance of incident detection and analysis throughout the organization". This should come from the top of the organization, not from the bottom.
2. "Organizations should create written guidelines for prioritizing incidents." This is important since there will always be limited resources and time to respond to an incident.
3. "Organizations should use the lessons-learned process to gain value from incidents." If a similar attack has already been resolved, then it should be possible to resolve another attack of the same kind faster with less staff effort.
A final recommendation is that an attacked organization should reach out to other trusted organizations that may be able to provide valuable information and insight to the problem and its resolution.
The schematic below shows how the Incident Response Team may be composed.
