Planning for Recovery
Security incident response is the resulting processes and actions an organization takes in responding to a security intrusion. Any company or organization that does business using the Internet, or private wide-area communications networks, should have a security incident response program setup before a security incident occurs.
Each and every security incident response program that is setup will contain unique elements that exist and make sense only for their organization. It is this uniqueness of the incident response program that is most important. If it were not for the unique elements of an incident response program, organizations could simply use a scripted scenario documented from a security textbook.
Certainly there are best-practice guidelines that are worth following, many of which can be found in leading Incident Response books such as Incident Response: A Strategic Guide to Handling System and Network Security Breaches by Schultz and Shumway, or O'Reilly's Incident Response by van Wyk and Forno. However, the unique elements of an organization's incident response process should contain the specifics and details of their intranet -- details that only someone inside your organization would have knowledge of.
An incident response program details the actions that you take when a security incident occurs. Actions imply that you do something, and in order to understand what you should do in any sort of risk mitigating situation, you need procedures. You also need to know who specifically will perform which procedures, what reports will be generated, and who will review the findings in these reports. Clearly defining roles and responsibilities are part of any worthwhile incident response program.
"Once a system has been ,
compromised you can't trust any
of the information contained on it"
To ensure that the appropriate actions are taken by the appropriate people, lines of accountability, guidelines for staff, and contact lists need to be established. An overall incident response manager needs to be appointed. Depending on the size of the organization, the incident response manager could be the director of information technology, the chief information officer, the director of information security, or a security project manager.
Putting the Plan into Motion
When an incident has been detected, it is the first responsibility of the incident response manager to make sure that the incident response team is assembled and notified in a timely fashion. Therefore, prior to the occurrence of any security incident, in the planning phase, detailed contact lists must be put together, and kept up to date. Security incidents are never convenient, and there is a good chance that key personnel will need to be notified off-hours. In the contact lists, you should retain home phone numbers, cell phone numbers, pagers, and all email addresses of everyone listed.
After the team has been notified of the incident, they need to be pointed to the pre-established guidelines, and instructed on which processes and procedures need to be applied to what systems, networks, and applications. Typically it is the organizations systems administrators that will do most of the hands-on work, and then report and log their work on incident tracking forms.
Before recovery from the incident begins, the organization should decide whether the goal of the recovery is to proceed and protect, or to pursue and prosecute. Often times these two objectives conflict, and if that is the case, one or the other needs to be given priority. If the goal is to pursue and prosecute, it is very important not to tamper with the evidence. Not tampering with the evidence means that log files will not be changed in any way, access and creation dates on files cannot be changed, data cannot be overwritten, or transferred over unencrypted intranet links to other systems.
If you have customer systems that need to be repaired within a certain timeframe, and have contractual obligations to do just that, you might not have time to contain the evidence in a way that would give a prosecuting attorney a case worth pursuing. Certainly taking actions like reformatting and reinstalling a disk will most assuredly destroy important evidence. Tough decisions might need to be made on whether catching the perpetrator is more important than restoring customer systems.
"Tough decisions might need
to be made on whether catching
the perpetrator is more important
than restoring systems"
The uniqueness of your organization's incident response plan will include information about your intranet accounts and data, including where master password lists are kept, and what procedures should be used to access them, purge them, or recreate them. The version of all your operating systems and patch level needs to be known for each and every system on your network - the same holds true for all your applications. In planning your incident response process, you need to have pre-recorded a minimal set of criteria regarding all your systems. Once a system has been compromised, you can't trust any of the information contained on it, because you don't know what the perpetrator has or has not changed. Version numbers might have been changed, patch levels, and of course various Trojan programs could have been installed. For any system that has been breached, the only option is to reinstall the entire system.
If the breached system is a development system, simply recompiling and re-linking the code is not good enough since you don't know whether the compiler or the libraries it uses have been sabotaged. You need to completely rebuild the system, reinstalling the operating system, compilers, and any supporting libraries and applications.
Dissecting a system to find Trojan Horses, and trying to understand what system files have been changed typically takes far longer than simply reinstalling the entire system from scratch. Therefore, a standard recommendation in the world of information security has evolved to reinstall, or build a new system, to replace any compromised systems. A compromised system should not be patched, since you will never know if you patched a recovered the entire system.
Go to page: 1 2
Images
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
