Do You Communicate Consistently?
by Julie Fuggett
Clear, concise, well-written e-mails can be the key to getting what you want, but have you ever considered that they can also save you time, headaches, and even keep you out of hot water?
During the incident handling process, we all know that communication is key. Everyone on the incident handling team must know what the expectations are for their behavior. What is needed of them and when? What should they do? What should they not do? This is especially important if you have technical support staff members who are not full-time IT security staff assisting with incidents. Clear, concise messages that set expectations in black and white can be the one thing that stands between much-needed evidence and spoliation brought on by a network admin who thought he or she was doing the right thing.
Are you re-inventing the wheel every time you handle an incident? You may know the process backwards and forwards in your own head, but what if you have to pass the incident off to another staff member or bring in someone from outside the security office for help? Do you have faith in your own ability to explain all the ins and outs of handling an incident to someone who rarely (or never) gets involved? Having to document all the do’s and don’ts of incident handling during the incident could lead to very costly mistakes. Clear, consistent communications are key to getting your point across as well as documenting what has been done and what needs to be done.
Well-designed message templates can save precious time and mistakes when an incident has occurred. These messages should be formatted to be easy to read, concise, and written to suit the technical acumen of their potential audience. They should say what is okay to do to the system in question as well as which actions should absolutely not be performed. If a message regarding notification of a compromise is to be sent to an IT staff member outside the security office, you may wish to give them a list of actions to perform (assess the physical state of the system, fill out an initial survey with the user of what data is present, etc) and remind them not to attempt to clean an infection on a compromised system.
Depending on the structure of IT in your organization, they may also need to lay out consequences for lack of compliance with the instructions in the message. These could be technological (loss of network access) or administrative (report to HR) in nature.
Consistent communication isn’t just for incident handling, however! Use it to your advantage when dealing with customers and clients as well. Find efficiencies in the way you communicate with outsiders that set clear expectations on what you can do for them or share with them. You can also use this as a way to gauge the efficiency of other services. If you find that you are repeating the same set of instructions to your users over and over and over again, perhaps it is a sign that your service is making its users work for it instead of the other way ‘round.
Finally, make sure any message templates you choose to use are vetted. (For the sake of professionalism, you should also have them proofread!) Incident response templates should likely be vetted by management and counsel. Customer communication message templates should be vetted by representatives of your user community and not just by “the guys around the office.”
Incident Handling – the dead horse that won’t die
By Ron Simmons
Do you have a documented and tested incident handling program? To my surprise, some a majority of companies lack this basic necessity. Putting something in place may take some time, but here are some tips and suggestions to help get started.
Define: incident
For those familiar with ITIL (Information Technology Infrastructure Library), it is important to note a security incident is not the same as an ITIL incident. ITIL describes and incident as and event that is not a part of the standard operation in these terms an incident is the start of a service delivery or problem management process.
While in security events are the starting point for us, they are issues in the enterprise that could lead up and incident. The best definition of incident that I have read out there is “An incident is any situation that exceeds normal risk management processes.”
Instead of focusing on a specific type of incident, an “Incident handling” process must be designed to be broad enough to support any type of threat or exposure to organizations systems, data, and/or physical infrastructure, etc…. Breaches happen in many forms now days, improper disposal of documentation, lose of equipment, system compromises, all the way to the janitor attempting to sell DOE restricted data. However when you think about it, an incident may not end up in a breach, but a breach will always be an incident. Breaches encompass many forms of data, personal information, financial account information, health care information, trade or governmental secrets, and the list goes on.
Simple is always effective, and it is no different when it comes to incident handling. Good incident handling does not require a novel. To get started, keep terms general, include process flow charts and check lists. When responding to an incident, these will keep everyone on track and ensure all actions are documented.
The process can be broken down in 5 simple steps:
1. Prepare (for incidents)
2. Identify
3. Incident handling
4. Recover (from incident)
5. Lessons learned
Preparation – Proactive
Preparation is the most critical element. Document the guidelines to handle incidents. Preparation ensures you will be better equipped to handle most situations as they come up.
First start by identifying what your organization has that it considers critical assets. This could be technology, customer data, physical assets, even services that are offered. Then you need to identify what types of threats does your company face. Keep it simple here, no need to go into specifics, IS threats, physical threats, insider threats, etc…. Then document your policy, guidelines, and checklists on how to identify, resolve, and recover from them.
Remember to keep it general, there is no way you can identify all possible threats down to exacts.
Identification
This is the most difficult step of this process. The ability to gather “events” is crucial – without it, the incident could be missed. An organization has to know the sources of the events and what their meanings are in order to validate and event and move into the incident handling process. The best piece of advice anyone could get here is “log… and log everything.” Without logs you can and most likely will miss the event that leads to your incident. The last thing anyone wants is for an outside company to discover the incident before you do as a company.
To help you could come up with cheat sheet to assist your employees in identification of incidents.
Incident Handling
Here is where we stop the bleeding. Once the incident has been identified assemble your strike team, move in, and eradicate the incident. Here is where preparation comes in: if the documentation is in order, including the procedures on how to handle different types of incidents, then dealing with them in a rapid and efficient way will be a snap.
Recovery
“Simply” put things back to normal. Make sure that back to normal does not include the risk that was abused in the first place to create this incident. In a cyber incident this normally means rebuild from scratch. Be careful if you decide to restored from backup, if can not or have not identified exactly when the breach or incident happened, you could restore back to the bad state and have to start all over. It is best to restore your configurations from your configuration management system.
Lessons Learned
Take what you have learned from this and return to the preparation phase and make modifications as necessary. These modifications could also mean changes to the production systems, the physical environment and even the training you give your employees. Sometimes these changes could seem silly, but you still need to heed the warnings and make the change.
http://en.wikipedia.org/wiki/ITIL
http://www.knowledgetransfer.net/dictionary/ITIL/en/Incident.htm
http://securosis.com/2008/08/20/the-best-incident-response-training-you-can-buy-for-free/
http://darkreading.com/security/attacks/showArticle.jhtml?articleID=212902962
Engage with Michael
-
Journey Into the Breach
