Assurance Plans Guideline

All business continuity analysis should be risk based, and risk prioritised to deal with the important business risks first. This means that any risks to your business need to be identified, examined and dealt with.
There are 4 options for dealing with each risk:

1. Reduce the risk. Reducing the risk falls into 2 categories - reducing the likelihood of the problem occurring and reducing the impact of the problem if it does happen. A simple example is that by having a fire alarm you are reducing the likelihood of a fire spreading unseen and by installing a sprinkler system you are reducing the impact of fire.

Reducing the risk is often referred to as mitigation. For example, data backups are a form of mitigation. They reduce the impact if a problem occurs which affects the primary data source. Any mitigating actions require testing to provide assurance they work when required.

2. Transfer the risk. This is an interesting option which may be seen as a get-out, but which is a perfectly valid thing to do. By transferring a risk it becomes someone else’s problem and you therefore have the risk covered. We are not talking about blaming someone else, or even transferring the risk to someone else in the company.

For example, there could be a risk that office space will not be available in the case of a disaster in the main location. Therefore the risk can be transferred to a third party company which organises office space for disaster recovery and keeps offices available for companies who need such a recovery service.

3. Accept the risk. By accepting the risk of a potential problem you are at least aware of its existence and can plan for it happening. If it is a risk that would have no impact for an acceptable period of time it should still be noted but you may decide to take no action until it occurs.

Almost by definition, accepting a risk is also reducing the impact of the risk as you are aware of the potential problem and can write it into your business continuity plan.

4. Ignore the risk. This option should never be selected. There is never a reason for ignoring a risk once it has been identified. A risk can be accepted (acknowledged) but must never be ignored.

Once the actions for each risk have been identified, then anything put in place to help cope with a risk needs testing. However, many companies either test nothing at all or try testing every facet of a business continuity plan. Both methods are doomed to failure. The answer is to adopt a risk based testing approach from two perspectives: the business continuity plan is fit for purpose and it will work when invoked.

A health check (testing the plan is fit for purpose) needs to be performed by someone other than the authors of the business continuity plan. Ideally it’s performed by an independent third party that specialises in testing business continuity plans, but it could be a disinterested party from another part of the company. Independence is essential here for an objective assessment.

Testing the plan will work when invoked, must be viewed in a business context and the elements of the plan prioritised so that the risks with the most business impact and likelihood are tested first. This approach and the techniques to perform business continuity testing in a cost effective manner are the subject of other articles.

Copyright Acutest UK 2005

A Streeb is an experienced practitioner of business continuity testing at Acutest, an independent consultancy specialising in business continuity assurance and software testing services. For more information on this topic visit http://www.acutest.co.uk or send an email to enquires@acutest.co.uk

Share This

You just finished building your company’s website. You have tested it yourself and had other company employees test it. The website now goes live. A few weeks later you start getting emails from irate customers who complain that they are unable to place their orders because certain steps in the “Buy Now” process give errors. You quickly fix the problem. A few days later you get complaints about some other issue and you again react quickly to fix the website. This continues for a few months till the complaints finally halt and things stabilize.

At this point you make some enhancements to your website. A few days later a customer email alerts you to the fact that in the process of making this enhancement you “broke” something else on the website. Again you spend time to find and fix the problem but by now you are perplexed and not a little frustrated. These issues have cost you many customers in the last few months and potentially spread ill will across the broader customer community. It seems to you that the only way to have detected these issues before they went “live” was to have employed a large army of software testers, something your company is unable to afford.

Enter automated software testing. While nothing can replace good human testers, broad test coverage requires some degree of software automation for it to be economically feasible. Automated testing tools can provide a huge workforce multiplier and do a very good job complimenting human testers. Every change to your website no matter how small requires thorough testing to ensure that nothing else was affected. This becomes very time consuming very quickly due to the large number of possible cases to test. A strategy whereby tests are automated using software becomes an economic necessity.

There are two classes of automated testing tools. The first kind, functional and regression testing tools, helps to make sure that the website behaves as it should: for example if a customer clicks on button X, page Y is displayed without errors. Functional and regression testing tools are able to automate a large number of scenarios to ensure that your website works as intended. The second type, load testing tools gauge how well your website performs when subjected to a large stress, such as a large number of simultaneous users. I will be discussing load testing in a separate article.

I will now give you an overview of the basic characteristics of functional testing. Before you can begin any kind of functional test automation you will need to identify the test scenarios you wish to automate. Once this is done, you will need to generate test scripts that cover these scenarios.

A functional testing tool will typically record user interactions with a website. As you perform various operations on your website or application, the tool records every step. When you finish recording, it generates an automated script from your interactions with your website. Alternatively you could use the tool to construct the script by hand. Typically testers tend to do a combination of the two. They will use the recorder to generate the basic framework of their scripts and then tweak the scripts by hand to incorporate special cases.

Scripts can be graphical and/or text based in nature. A good functional testing tool does not require users to have a programming background. Users not proficient in programming will work predominantly with graphical scripts. In most tools graphical scripts will typically show all interactions in a tree structure and users can edit any node of the tree to modify the script. Some users however, who have programming backgrounds may wish to program their scripts. These users will typically work with a text script written in a standard language such as JavaScript or VBScript.

Once you have generated your script you will need to insert checks in your scripts to test if your website is functioning correctly. Such checks are usually called checkpoints. A checkpoint verifies that values of a property obtained when testing the website match expected values. Checkpoints enable you to set the criteria for comparing expected values with obtained values. The expected value of a property is derived from recording interactions with the web site. It is viewed and modified from checkpoints. The current value is retrieved during replay (i.e. during the execution of the test case).

There are many different kinds of checkpoints. A page checkpoint verifies the source of a page or frame as well as its statistical properties. You can check for broken links, verify link URLs, image sources, the hierarchy of HTML tags or even the entire HTML source of the Web page or frame. You can also set thresholds for the loading time of a page. A text checkpoint verifies that a given text is displayed or is not displayed in a specified area on a web page. A web object checkpoint verifies the properties of a web object e.g. the value of an HTML INPUT field. A database checkpoint verifies the contents of a database used by your website.

When you replay a test script, the testing tool will open the recorded application and perform the recorded steps in the same sequence they were specified in the script. As it replays the script it will also run through all the checkpoints you have inserted into the script. In addition, you can test your application’s behavior with varying data inputs. For example you can try to submit a page after entering different values in the edit box of a web page. At the end of the replay a detailed report is typically be generated.

Functional test automation allows you to automate the repetitive testing of a large number of scenarios across your website. Functional testing tools are an important weapon in your development arsenal whose use provides a huge productivity gain and allows for small testing groups to accomplish significantly more work. There is a very strong economic case for the use of Functional Testing Tools as part of the development and deployment cycle of a website.

About the Author:
Umair Khan is Founder and Chairman of
Verisium, Inc., a provider of products for automated functional and regression testing, load testing, bug tracking and test and requirement management.

Verisium is the maker of vTest, an automated functional and regression testing tool for web applications.

Share This

I’ve finally stopped procrastinating and joined my local Information System Security Association, Colorado Springs Chapter (ISSA-COS). A few of my co-workers have been encouraging me to join since last year.

Over the past year many of the benefits that they’ve enjoyed as member of the ISSA have spilled over on to me. I encourage all serious Information security professional to join because the ISSA has their fingers on the pulse on all information security events, jobs and seminars at discount prices.

ISSA members are always up on the latest security events and seminars in town. Just two months ago, an ISSA member invited me to attend an Certified Ethical Hacking course. I actually had no idea that there was a “hacking certification” prior to her email. I attended a free seminar with mile2 and loved it so much I decided to attend the whole course. I was able to attend an Ethical Hacking Course which my company paid for. I’ll be going for that cert. soon.

As an ISSA member you will have access to many information security jobs in the area and around the world. Recently, one of my former co-workers (ISSA member) sent me information on an information security job in Baghdad. For fear of being apart of a hostage reality show on Al Jazeera TV, I declined. Would you decline a 300K/year job? I must admit I think about it every now and then. My co-worker actually took the job and is much braver than I am.

Discounts on events, seminars and training is another benefit of an ISSA member. For example, we are having a local Security+ training that will be held this Saturday at Colorado Technical University and in May there will is the SANS Rocky Mountain 2005 - Immersion Training which gives a price cut to all members.

In my opinion, the best thing about the ISSA is the ability to network with like minded Information Security professionals. In the local ISSA Chapter there is a meeting once a month with seminars and meetings that include speakers like Phil Zimmerman, creator of PGP and representatives from companies like 3Com’s, TippingPoint.

If you are an information security professional, you should definitely sign up. Membership is free for 90 days to give you feel for the association (attend a meeting with your 90-day membership). It is $99.00 a year for ISSA membership and an additional $25.00 for the Colorado Springs ISSA division (each local chapter has its own annual fee). Don’t be like me and wait a year to join. The networking is worth your weight in gold or at least 300K/year in an exotic location.

Join at www.ISSA.org

Rob Elam has a computer security blog at http://elamb.org. He has been doing security for the Department of Defense for ten years. He is currently a System Security Engineer in Colorado.

Share This