Thursday, February 24, 2005
[Enterprise : Management]Create an incident response policy
By Mike Mullins, TechRepublic
Monday, February 21 2005 5:16 PM
Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down your organization's network, and your disaster recovery plan effectively details how to respond to a security incident--so you feel relatively secure.
But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has a policy in place that outlines steps to take during potentially disastrous times.
Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize security vulnerabilities and respond to security incidents in a well-organized and thorough manner should be a critical component of any company's BCP.
A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can include unauthorized access, malicious code (such as viruses), network probes, and denial-of-service attacks.
An effective IRP should address eight key areas. Let's take a closer look.
1. Demonstrate management support
First and foremost, your policy should clearly outline management's support of the policy. A member of senior management--or anyone with the same authority to address the included provisions--should sign the policy. These provisions might include any financial resources, personnel, equipment, and training dedicated to implementing the policy as well as internal consequences of violation.
2. Decide an organizational approach
There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The method your organization chooses should depend on whether the goal is to seek prosecution and/or compensation or to quickly restore services.
3. Determine outside notification procedures
Allowing your network to participate in a distributed attack and remaining silent is a legal landmine waiting to explode. In our collaborative world, it's important to determine procedures for notifying third parties if you're involved in a distributed event. Decide whom you'll inform as well as when and how.
4. Discuss remote connections
Your policy must address remote connections. This should encompass all remote employees or contractors, and it needs to outline your rights to disconnect and remove access during a security incident.
5. Define partner agreements
Describe downstream and upstream agreements with your service providers and customers that define your right to monitor and disconnect the network as required.
6. Develop an incident team
Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, responsibilities, and functions. The team should encompass a variety of skills and areas of expertise, including security, administrators, human resources, and legal.
7. Design an internal communications plan
Develop an internal communications plan that identifies who you will notify and how you will contact them. In addition, decide on the person who's responsible for initiating this contact.
8. Demand a follow-up report
Define a method for reporting and historically archiving the incident. Use that information to tune your operations to prevent a similar incident from reoccurring.
Every network is unique, and the type of business your organization conducts on the Internet will influence the level of your response to a security incident. As your network changes, make sure you adjust your IRP accordingly and address newly discovered vulnerabilities as they occur.
Final thoughts
If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a security incident. An IRP policy can't solve your problems, but it can offer a cool-headed method for dealing with a hot issue.
For more in-depth information on incident response, check out SANS' Information Security Reading Room , which offers a wealth of available information that can help you create a comprehensive incident response policy.
Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.
Monday, February 21 2005 5:16 PM
Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down your organization's network, and your disaster recovery plan effectively details how to respond to a security incident--so you feel relatively secure.
But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has a policy in place that outlines steps to take during potentially disastrous times.
Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize security vulnerabilities and respond to security incidents in a well-organized and thorough manner should be a critical component of any company's BCP.
A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can include unauthorized access, malicious code (such as viruses), network probes, and denial-of-service attacks.
An effective IRP should address eight key areas. Let's take a closer look.
1. Demonstrate management support
First and foremost, your policy should clearly outline management's support of the policy. A member of senior management--or anyone with the same authority to address the included provisions--should sign the policy. These provisions might include any financial resources, personnel, equipment, and training dedicated to implementing the policy as well as internal consequences of violation.
2. Decide an organizational approach
There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The method your organization chooses should depend on whether the goal is to seek prosecution and/or compensation or to quickly restore services.
3. Determine outside notification procedures
Allowing your network to participate in a distributed attack and remaining silent is a legal landmine waiting to explode. In our collaborative world, it's important to determine procedures for notifying third parties if you're involved in a distributed event. Decide whom you'll inform as well as when and how.
4. Discuss remote connections
Your policy must address remote connections. This should encompass all remote employees or contractors, and it needs to outline your rights to disconnect and remove access during a security incident.
5. Define partner agreements
Describe downstream and upstream agreements with your service providers and customers that define your right to monitor and disconnect the network as required.
6. Develop an incident team
Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, responsibilities, and functions. The team should encompass a variety of skills and areas of expertise, including security, administrators, human resources, and legal.
7. Design an internal communications plan
Develop an internal communications plan that identifies who you will notify and how you will contact them. In addition, decide on the person who's responsible for initiating this contact.
8. Demand a follow-up report
Define a method for reporting and historically archiving the incident. Use that information to tune your operations to prevent a similar incident from reoccurring.
Every network is unique, and the type of business your organization conducts on the Internet will influence the level of your response to a security incident. As your network changes, make sure you adjust your IRP accordingly and address newly discovered vulnerabilities as they occur.
Final thoughts
If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a security incident. An IRP policy can't solve your problems, but it can offer a cool-headed method for dealing with a hot issue.
For more in-depth information on incident response, check out SANS' Information Security Reading Room , which offers a wealth of available information that can help you create a comprehensive incident response policy.
Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.
# posted by MiDBA @ 2/24/2005 09:49:00 AM 
