This article was written by: Cryptomatrix.com

If you like our publications please visit our website:

http://www.cryptomatrix.com

(we have forums, tools, and other resources you may be interested in)

SECURITY RISK ANALYSIS AND DISASTER RECOVERY PLAN

This project paper is a reflection of a plan and policy for a hypothetical Internet based organization that sells children’s audio-video media. The objectives, herein, are to consider a plan that can be implemented to “secure our company against all types of failures and to promote uninterrupted business continuity". Today’s businesses rely heavily on their information systems in order to run effectively and efficiently. These businesses are bombarded by a plethora of threats, vulnerabilities and risk. We must consider these issues on an individual basis in order to be able to develop a comprehensive plan that will effectively protect the business.

First, we must consider the types and degrees of attacks that we could possibly be subjected to and be called upon to ward against damages effected. Second, we must consider a document developed by ISO (International Standards Organization) that provides directives for developing and implementing information security policy, ISO 17799. Third, we must design a comprehensive plan that can protect against misfortune as well as comply with ISO 17799. We must provide backups and alternatives for our business to keep running in the event that our plan fails. Finally, we need a system that is capable of measuring the effectiveness of our policy.

On an everyday basis, Information Security Systems are subjected to threats, vulnerabilities and risk. It is important to our goal that we understand and maintain the distinct differences between these concepts. A threat in terms of Information Systems is “a category of objects, persons, or other entities that pose a potential danger to an asset” (Whitman, 2005). In the terms of Information Systems Security, the assets we are referring to, includes a company’s hardware, software, intellectual knowledge, personnel, and anything that contributes value to the company. Mr. Whitman, points out that threats are always present. In designing an information security plan we must remember that threats will always be there, lurking around every corner. We cannot simply eliminate a threat; we need to protect against likely threats and in a cost effective and efficient manner. Some threats are accidental while other threats are purposeful. This simply summarizes that threats will fall into one of two categories; accidents and intentional attacks. Accidental damage can be the result of uncontrollable circumstances such as water, fire, storms, earthquakes, and other acts of god known as “force majure". Intentional attacks do not happen by chance. These types of attacks include hacker attempts, terrorism, disgruntled employee retaliation, and other attacks made for profit or retaliation.

Vulnerabilities can also pose a significant danger to corporations. A vulnerability with regards to Information Systems is, “a weakness of an asset or group of assets that can be exploited by a threat” (ISO 17799, 2005). The human factor is arguably the largest vulnerability that any company faces. This is because human error and weakness are particularly prone to exploitation. Social engineering attacks fall in this category. “Social engineering is the technique of circumventing technological security measures by manipulating people to disclose crucial authentication information” (Granger, 2001). Other vulnerabilities include poorly written programs that contain code that is exploitable, poorly controlled access control, and the lack of a maintained or regularly updated/patched information security system. Vulnerabilities differ from threats because they are not as uncontrollable as threats tend to be. The exploitation of vulnerabilities is similar to vehicle accidents. Within the realm of vulnerabilities there is a significant margin of “human error". For example, in a simple traffic accident, somebody is always at fault. If one vehicle collides with another vehicle by causing the front of their vehicle to make contact with the vehicle traveling in front of them, the vehicle in the rear is always considered “at fault". This is because there are several things that the driver of the vehicle in the rear can control, such as following distance and speed. Likewise with vulnerabilities, failing to patch or update a system is something that could have been done that would have prevented the breach to the system. Threats are uncontrollable, the vulnerabilities are considerably controllable.

The impact of risk on Information Systems is evaluated under a vast topic known as risk management. Risk management, “is the process of identifying vulnerabilities in an organization’s information systems and taking carefully or reasoned steps to ensure the confidentiality, integrity, and availability of all the components in the organization’s information system” (Whitman, 2005). Risk in itself includes the very threats and vulnerabilities that pose a danger to a company. In summary, risk management considers the threats and vulnerabilities that can be exploited against an organization and aims to effectively protect against these dangers in a cost effective manner. A very important point to be aware of when considering risk and the management thereof is that this is a danger that cannot be entirely eliminated. This is something we need to accept and evaluate carefully in order to implement a plan to protect against it. We must accept risk as a given. Risk is very similar to the chance or gamble each and every one of us takes when we get out of bed in the morning or attempt to cross the street in the afternoon.

Threats, vulnerabilities and risk direct themselves in harmful manners toward our Information Systems that are so critical to the mission of any business. There are various types of attacks that we need to be wary of and they bombard themselves upon us in varying degrees of strength. All of these attacks attempt to penetrate what is known as the CIA Triangle (confidentiality, integrity, and availability) of the data flowing between and stored on Information Systems. “Simple shoulder spying, dumpster diving all the way up the malicious chain to corporate espionage and social engineering fall into this realm” (Groom, 2008). These are all methods that affect the confidentiality of data. Integrity of data is usually affected by individuals intercepting or altering the information stored or transmitted. “Users are often involved in breaching integrity by speaking to unauthorized media sources, modifying databases on the fly and generally not adhering to the policies put in place” (Groom, 2008). Availability is what your business ultimately thrives on to turn a profit. If data is not accessible it is useless and revenue is lost. “Adherence to need for availability requires us to deal with power failures, hard drive failures and pretty much all system availability falls into this realm” (Groom 2008). This can also manifest itself in terms of a Denial-of-Service attack, an attack in which the attacker bombards the system with frivolous requests and thus overloads of the resources so the system cannot support it’s users with legitimate requests.

Now that we have a concrete base that we are defending against we can develop an effective policy that can ward against the evils we that could place us in the unemployment line. The first step we need to take in developing this plan and policy is to gather an inventory of the company’s assets. “An organization should identify all assets and document the importance of these assets” (ISO 17799, 2005). This must be a very comprehensive, well detailed and organized inventory that accurately reflects all the company’s assets, especially those assets needed to recover from a crisis. “The asset inventory should include all information necessary in order to recover from a disaster, including type of asset, format, location, backup information, license information, and a business value (ISO 17799, 2005). Inventorying is an extremely critical step in the process and cannot be taken lightly or casually. This step is the pinnacle upon which all disaster a recovery efforts rely on. In other words, this is mandatory, not recommended or optional.

The next step is to agree on a “backups” policy and strategy that can be used to restore systems in a timely manner. “Routine procedures should be established to implement the agreed back-up policy and strategy for taking back-up copies of data and rehearsing their timely restoration” (ISO 17799, 2005). Backups must contain all information and data that will be needed. Systems need to be backed up according to the needs of the business. However, the frequency and in which backups occur also must be weighed against the length of time the company intends on keeping the backups readily available. In our hypothetical organization that sells children’s audio-video media we will require that the backups are kept for 30 days. This will provide adequate time for transactions to be completed, payments to be processed, and potential returns to be administered. Therefore, we will require backups to occur four times a day, at the rate of every six hours. “According to ADR Data Recovery, U.S. businesses lose more than $12 billion per year because of data loss due to hardware or system failure, software corruption, natural disasters, or human error” (Saltzman, 2008). Backups will be required, they are not optional.

Now that we have a method of keeping track of what we are attempting to protect and a copy of the data we are protecting for purposes of restoration we must dwell on management’s role and involvement in our mission. Management’s firm commitment to uphold and implement the requirements of our policy is the key to the success of any disaster recovery plan. If the rules and regulations are not implemented uniformly from the highest ranking employees all the way down the line these requirements become useless, because they are occurring on a reliable basis. We must clearly dictate our expectations of the management team. They will be the individuals presenting our plan to the rest of the employees. Therefore it is imperative and so important that they have a clear and succinct perspective of our goals and objectives. “Management should actively support security within the organization through clear direction, demonstrated commitment, explicit assignment, and acknowledgment of information security responsibilities” (ISO 17799, 2005). Lack of well informed, knowledgeable and disciplined management teams can greatly hinder our attempts to maintain company operation without incident.

We have already provided for inventorying assets, backups, and management’s firm commitment to our goal. The next step in our comprehensive plan is to decide how we will respond in the event of a crisis. In the event of a disaster every second will count. Every second wasted is revenue lost and aids the attacker or perpetrator that is working against us be it a real-life character or mother nature. Therefore, we need to ensure that we are well organized and have a hierarchy for making decisions during our response. This will account for our “incident reaction” part of the recovery plan. An “incident reaction consists of actions outlined in the Incident Recovery Plan that guide the organization in attempting to stop the incident, mitigate the impact of the incident, and provide information for recovery from the incident” (Whitman, 2005).

In the event of an incident we must have a system for notifying the management personnel that will take control and direct recovery efforts. We will be using the “hierarchal roster” due to it’s advantage in terms of speed with is critical during an incident. “A hierarchal roster is activate as the first person on the ‘notification list’ is contact and that person contacts the next on the list who in turn continues to pass the torch” (Whitman, 2005). Once we have notified the proper individuals we can instigate recovery.

After notification management will step in to assist. The first line of defense our recovery effort will consist of assessing the overall picture and determining a priority list for the recovery team. “Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response to information security incidents” (ISO 17799, 2005). Management will commence to recover our systems as follows. Our plan will require that the safety of our recovery team be the first priority. “A key objective of the contingency plan should be to provide for the safety and well-being of people on the premises at the time of a disaster” (CSA, 2005). Next, we will recover our systems utilizing our inventory list and the backups we have provide for. “Throughout the recovery effort the plan must aim to minimize immediate damage and losses, minimize the duration of a serious disruption to operations and resources, and continue critical business operations” (CSA, 2005).

We can not assume that the disaster will be limited to the information systems in our control. Especially since network systems are not isolated we must provide the expectation that our recovery efforts may require assistance or us to provide assistance outside of our domains. “Information security incidents might transcend organizational and national boundaries” (ISO 17799, 2005). Management will need to be acutely aware of this factor in directing the recovery team. “To respond to such incidents there is an increasing need to coordinate response and share information about these incidents with external organizations as appropriate” (ISO 17999, 2005).

No Disaster Recovery Plan is complete without provide a method to measure and test the effectiveness of our contingency plan. “Don’t make the mistake of creating a paper-only security response plan just to satisfy regulatory requirements. You might as well figure out a strategy to stop localized problems before they shut down your corporate network” (Mullins, 2007). In order to pass our testing phase our plan must meet the objective of allowing our business to run without delay as well as be cost-effective. “However, it is expected that reasonable measures will be taken to regularly test aspects of the plan to achieve acceptable levels of confidence that the plan is viable” (Rust, 2005). In order to be able to measure the usefulness of our plan we must gather data while our systems are running under non-emergency conditions. We must have a reference that we can use as a “benchmark”. A benchmark is a measurement of our system at peak operation. Our plan will require benchmark testing. We will use the benchmark to compare how our systems reacts under stress compared to under routine, normal conditions.

To measure the effectiveness of our Disaster Recovery Plan we will instigate a simulated incident. We will select a potentially great threat to our network and notify the system administrators that the network has just been brought down by a dangerous viral infection and instruct them to commence recovery according to plan. “Using a virus example, elect a viral threat that poses the greatest risk and inform the security administrator that the virus is loose on that machine” (Mullins, 2007). After notifying the administrators we will monitor and record the results of the simulated incident.

Using the results thereof we will evaluate and measure our plan. In order to draw a proper conclusion we must subject our test results to the following question. “Can your business process staff operate efficiently after an adverse event or under adverse conditions after the IT staff has done its recovery tasks?” (Brewer, 2006). If our plan can withstand this requirement we have passed the testing phase. This plan will require a re-evaluation on an the industry standard, a minimum of an annual basis. “The remainder of the processes required by this Plan should be reassessed by the Plan Coordinator at least annually” (Stanford, 2003). Testing is required and not optional. “Test everything often. Your tolerance of what is acceptable as a “recent” test should be low” (Brewer, 2006).

This Disaster Recovery Plan takes into consideration the risks, threats, and vulnerabilities that our business will potentially face. We have developed a plan that involves inventorying our assets, providing for system backups, and a never failing commitment from management. We have also addressed issues pertaining to the recovery from disastrous events or dastardly acts of malice. Our plan even takes into consideration assessing general security risks and making accommodations for such. Finally, we have made provisions to ensure that the plan is routinely tested to ensure potency.

Works Cited

Brewer, D. (2006). Disaster Recovery Success Begins and Ends With The Basics. Retrieved from:http://searchfinancialsecurity.techtarget.com /tip/0,289483,sid185_gci1294568,00.html on May 16, 2008

CSA - Computer Security Administration, University of Toronto. (2004) Disaster Recovery Plan. Retrieved from: http://www.utoronto.ca/ security/documentation/business_continuity/dis_rec_plan.htm on May 14, 2008.

Granger, S (2001). Social Engineering Fundamentals, Part I: Hacker Tactics. Retrieved from: http://www.securityfocus.com/infocus/1527 on May 16, 2008

Groom, R. (2008). Security Versus Business. Retrieved from: http://bizsecurity.about.com/od/holisticviewofsecurity/a/secbiz.htm on May 2, 2008.

ISO 17799. (2005). Information Technology – Security Techniques. Retrieved from: https://online.apus.edu/educator/temp/da1446/ is306b001spr08/CopiedResources/ISO-IEC_17799_2005.pdf on May 2, 2008.

Mullin, M. (2007). Test Your Security Incident Response Plan. Retrieved from: http://articles.techrepublic.com.com/5100-10878_ 11-6173748.html on May 11, 2008.

Panko, R. (2004). Corporate Computer and Network Security. Upper Saddle River, NJ: Prentice Hall.

Pipkin, D. (2003). Halting the Hacker. Upper Saddle River, NJ: Prentice Hall.

Rust, B. (2005). MUSC Information Security Standards: Contingency Plan. Retrieved from: http://www.musc.edu/security/standards/MUSC-Contingency-Plan.html#is-testing-of-contingency-plans-required on May 16, 2008.

Saltzman, M. (2008) How Often Should You Backup Files. Retrieved from: http://technology.inc.com/security/articles/200609/basicbackup .html on May 6, 2008.

Stanford University Legal Department. (2003). Standford University Confidential Financial Information Security Policy. Retrieved from: http://www.stanford.edu/dept/legal/Worddocs/financialSecurityPlan0903.pdf on May 14, 2008.

Tomas, T. (2004). Network Security – First Step. Cisco Press.

Whitman, M and Mattford, H. (2005). Principles of Information Security, 2nd Edition. Boston, MA: Thompson Course Technology.