Threat Level: green Handler on Duty: Adrien de Beaupre

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Critical Control 18: Incident Response Capabilities

Published: 2011-10-27
Last Updated: 2011-10-28 11:11:19 UTC
by Mark Baggett (Version: 2)
0 comment(s)

Some time ago I was brought in to help an organization create their Incident Response Team. Working together we defined an incident response procedure, assigned the various roles and responsibilities, worked with executive management to ensure the appropriate supporting policies and controls were in place and 'let her rip'. A few people in the management team had initially commented that they didn't see a need for all of the formality as the organization had never experienced even a minor breach in security. The first few months went by and everything seemed to be working fine. The head of the Incident response team wrote up a summary of all the incidents for the last thirty days and distributed it to all employees at the end of each month. Most of the incidents were pretty innocuous. A virus infection here or there, a targeted web attack that was thwarted by mod_proxy, or other malicious but minor deviations from the norm. Then, on the third month, someone reported a corporate laptop was lost by an employee. I'm told that after that report was distributed to all employees, the email account that was designated for reporting incidents got two separate emails asking if they should be reporting lost or stolen company assets. They were told yes. The following month 5 laptops were reported lost or stolen. The next month 6 laptops were reported lost of stolen. Over the first year of the incident response teams existence 2.5 laptops were reported lost or stolen every month. Prior to having an incident response team the organization had "never had a laptop lost or stolen". So was the creation of an IRT (Incident Response Team) responsible for the theft of all those laptops? Of course not! If you don't measure risk you can't manage it. If you don't have a formal process for capturing and responding to incidents you will not know they are occurring. No matter your size, you should have internal incident response capabilities. As they say, a failure to plan is a plan for failure. Here are some tips for ensuring the success of your organizations incident response capabilities.

  1. Write down your incident handling procedures. If it is written down then it is easier to explain to the business why your are doing what you are doing in the heat of battle. If you don't have a written procedure you can use the NIST guideline as a framework. http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf

  2. Document the roles and responsibilities of people on your incident response team. This will often include representatives from Legal, Human Resources, Public Relations, Compliance your Executive Sponsor and the usual suspect in the networking and information technology engineering groups along with your security team.

  3. Management support is critical to the success of most business initiatives. It is especially important when dealing with potentially politically explosive issues that are often associated with security incidents. Maintaining excellent and frequent communications with your executive management is critical to the success of your team.

  4. Establish requirements for all personnel to report suspicious incidents to the incident response team.

  5. Generate a regular report that summarizes the incidents that have occurred and how you handled them. Distribute the report to all employees in the organization.

  6. Require all incident responders to report in within a predefined amount of time once an incident has been declared. Periodically test the team to make sure everyone can be reached in a timely manner. Once you have your team together, conduct training exercises with various scenarios that test the teams ability to access and identify evidence on various systems throughout the networks they are responsible for protecting.

If you would like more information here are some helpful resources:

http://computer-forensics.sans.org/blog/2009/09/12/best-practices-in-digital-evidence-collection/

http://isc.sans.edu/diary.html?storyid=5354

http://www.sans.org/critical-security-controls/

 

Mark Baggett - Handler on Duty

Twitter @markbaggett

 

0 comment(s)

Software Update Potpourri

Published: 2011-10-27
Last Updated: 2011-10-27 23:27:18 UTC
by Mark Baggett (Version: 1)
1 comment(s)

A couple of updates were released recently that are worth calling to your attention. 

  • Quicktime - APPLE-SA-2011-10-26-1 QuickTime 7.7.1

This patch addresses critical several issues affecting Quicktime running on Windows.   

http://www.apple.com/quicktime/download/

More information is available at the Apple Security Updates
web site: http://support.apple.com/kb/HT1222

  • Chrome 15.0.874.102 to the Stable Channel for Windows, Mac, Linux, and Chrome Frame

This patch addresses a number of issues including XSS, Origin Policy violations, cookie theft and more. Chrome users should look at the details here:   http://googlechromereleases.blogspot.com/2011/10/chrome-stable-release.html

  • Java 5 Update 30 prelease

A preprelease version of Java 6 update 30 is now available to Java Developers.   This is a prerelease and not recommended for production systems.    Java developers can check it out here http://jdk6.java.net/6uNea.html

Thanks to Dave and Jim for bringing these to my attention.

Mark Baggett - @markbaggett

 

Keywords:
1 comment(s)
ISC StormCast for Thursday, October 27th 2011 http://isc.sans.edu/podcastdetail.html?id=2092
Diary Archives