|
|
|
|
|
|
| |
In this article, Anna Johnson suggests a model for contingency planning and handling breaches of security. |
|
Introduction
Although prevention is always better than a cure, all organisations need a plan for adequately dealing with a breach of security. Despite your best efforts, no system or network is 100% secure 100% of the time. Therefore, you need an emergency response model that contains procedures for dealing with foreseeable and unforeseeable security breaches. |
|
Response Philosophy
No, a response philosophy is not some academic theory on how to respond to a security breach. It is merely how your organisation intends to approach various kinds security incidents. A common distinction is made between the "protect and proceed" approach and the "pursue and proceed" approach. Both have serious implications for your organisation, the hacker or hacker/s attempting or succeeding in penetrating your systems, and your organisation's stakeholders (employees, customers, shareholders, suppliers, others). |
|
Once an intrusion into your network has been discovered you basically have two options in dealing with the attack. You can either try to identify and close all the holes in your network in order to prevent further attacks, with secondary concern for identifying and prosecuting the attacker. Or you can leave your network vulnerable for the period of time it takes for you to identify the attacker and commence prosecution proceedings. |
|
|
Approach #1: Protect and Proceed
The aim here is to protect and preserve site facilities and return the internal network back to normal as soon as possible. Attempts are made to find and close the gaps through which the intruder gained access and subvert any of the attacker's processes. A damage assessment and recovery procedure is implemented as soon as possible. Facilities may need to be shut down, and access to the network denied, as the network is thoroughly examined and rectified. |
|
The major drawback with the "protect and proceed" approach is that the intruder is usually allowed to get away with his or her attack. No conscious attempts are made to identify or apprehend him or her. As a result, there is nothing to stop the intruder from attempting to infiltrate this or any other site again. |
|
Approach #2: Pursue and Prosecute
In this approach, the organisation - usually with the involvement of a relevant law enforcement body - intends to catch the intruder. Hence, the weaknesses in the network that allowed the intrusion are identified - but not rectified - until the intruder can be identified and apprehended. This approach is endorsed by the law enforcement authorities but has two major drawbacks for the organisation. |
|
Firstly, the network is left vulnerable to further attacks that may have devastating effects on normal organisation functions. Secondly, the attacks may also leave the organisation liable for damages in one or more civil actions brought against it by relevant stakeholders (customers, suppliers, shareholders, neighbours, others) due to the attacks. |
|
In certain jurisdictions an organisation may be liable for civil damages if a stakeholder can show the following: the attacks against the network caused the stakeholder damage; the organisation knew that the network was vulnerable; and it was unreasonable for the organisation to permit such attacks to continue. Moreover, law enforcement authorities cannot exempt an organisation from a civil action. It is therefore advisable to establish your legal rights before choosing the "pursue and prosecute" strategy. |
|
Which One Should You Choose?
You and your organisation may already be predisposed to either approach. If not, here are some guidelines as to which approach may be better in certain circumstances. Use Protect and Proceed if the following conditions exist:
· Your organisation's assets are not well protected.
· Continued penetration could result in organisational or financial damage.
· The possibility or willingness to prosecute does not exist.
· The potential for stakeholder loss is unknown.
· Users' work is vulnerable.
· The organisation is vulnerable to stakeholder lawsuits if the network is undermined. |
|
Use the Pursue and Prosecute approach if:
· Assets and systems are well protected.
· Good network and system back-ups are available.
· The risk of damage to your assets is outweighed by the risk of damage caused by possible future penetrations.
· The attack occurs with high frequency and intensity such that it might be relatively easy and quick to identify the intruder.
· The organisation is a popular or common target for intruders.
· The site is willing to incur the financial or other risk to assets by allowing the penetration to continue.
· Intruder access can be controlled.
· Management is willing to prosecute.
· You can acquire the evidence necessary to prosecute.
· There is established contact with knowledgeable law enforcement.
· There is a organisational representative versed in the relevant legal issues.
The organisation is prepared for possible legal action from stakeholders if they incur loss due to the compromise of the network.
|
|
The Importance of Planning
Your Security Policy should include a section containing emergency response or incident handling guidelines in order to deal with a security incident.
There are important reasons for having a response plan:
· It may save human life (eg, if human life depends on the stability of your network).
· Generally, a well-thought out plan will allow for incidents to be dealt with more efficiently and effectively than trying to deal with them on the spot.
· A planned approach is normally necessary to ensure that classified, sensitive or proprietary information is backed up and protected.
· Public relations can be thought out and therefore better handled to minimize negative exposure.
· Legal ramifications can be comprehensively thought out. |
|
Essential elements of your emergency response guidelines are:
· A statement as to which approach - Protect and Proceed or Pursue and Prosecute - is preferred under what conditions.
· Who is to handle a security incident - with the contact details of everyone (including external parties) who should be notified.
· The procedure for dealing with a security breach. |
|
Also, it is advisable to document each incident response in order to facilitate a post-event evaluation. An evaluation will allow you to identify any problems in the emergency response procedure and therefore make improvements to the guidelines. |
|
| |
| Developing a Security Policy, by Anna Johnson Categories : Other, Security, Site Planning | | | Emergency Response Part 2 of 2 Categories : Other, Site Planning, Security | | | Some more about "Doorway" pages... Categories : Search Engines, Search, Site Planning, Other | | | Honey, I Shrunk My Website Categories : PHP, PHP options/info, Site Planning, Other | | | Search engine strategies - part 5: More Keywords Categories : Site Planning, Other | | | Ecommerce security - The developer's side Categories : Ecommerce, Security, Site Planning | | | Search engine Strategies - part 6: Links Categories : Other, Search Engines, Site Planning | | | Search engine strategies - If you build it, will they come? - Part 1 Categories : Other, Site Planning, Search Engines | | | Search Engine Strategies - part 4: Choosing Keywords Categories : HTML, Other, Site Planning, Search Engines | | | Doorways to Traffic Categories : Search Engines, Search, HTML, Site Planning, Other | | | Copyright Law May Not Be Best Way to Protect Your GUI Categories : Other, Site Planning | | | The Search Portals are going through some growing pains Categories : Search Engines, Search, Site Planning | | | Entrepreneurs Need Caution When Disclosing Information Categories : Other, Law | | | MySQL Access Control System - Grant Tables Categories : Databases, MySQL, Security | | | Understanding Modern Denial of Service Categories : Security | |
| |
|
|