WeberDev.com PHP and MySQL Code

LOG IN
BEGINNER GUIDES  |  PHP CLASSES  |  CODE SEARCH  |  ARTICLES SEARCH  |  PHP FORUMS  |  PHP MANUAL  |  PHP FUNCTIONS LIST  |  WEB SITE TEMPLATES
Start typing to search for PHP and MySQL Code Snippets and Articles Search
Submit a code Example / Snippet Submit Your Code
Search Engine Optimization Monitor SEO Monitor
Web Site UpTime Monitor UpTime Monitor
WeberDev's Monthly code contest PHP Code Contest
Your Personal Examples List My Favorite Examples
Your Personal Articles List My Favorite Articles
Edit Account Info Update Your Profile
PHP Code Search
Web Development Forums
Learn MySQL Playing Trivia
PHPBB2 Templates
Web Development Index
PHP Web Logs (BLogs)
Web Development Resources
Web Development Content
PHPClasses
PHP Editor
PHP Jobs
Vision.To Design
Ajax Tutorials
PHP Programming Help
PHP/MySQL Programming
Webmaster Resources
Webmaster Forum
XML meta language
website builder
Submit Site
Forex Trading Online forex trading platform

Go Back Add a Comment Send this Article to a friend Add this Article to your personal favoritest for easy future access to your favorite Code Examples and Articles. Submit a code example Print this code example.
BACK ADD A COMMENT SEND TO A FRIEND ADD TO MY FAVORITES SUBMIT AN ARTICLE PRINT
Title : Emergency Response Part 1 of 2
Categories : Other, Security, Site Planning
Report SecuritySearch.Net Vulnerability
Report SecuritySearch.Net Vulnerability
Date : 2000-04-01
Grade : 0 of 5 (graded 0 times)
Viewed : 3806
Search : More Articles by Report SecuritySearch.Net Vulnerability
Action : Grade This Article
Tools : My Favotite Articles


  Submit your own code examples 
 


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