Log inskip to content

Archive for the 'Business Continuity Management' Category

Latest Continuity News

Friday, June 20th, 2008

New standard will help with information security risk management
ISO/IEC 27005:2008 ‘Information technology – Security techniques – Information security risk management’.
http://www.continuitycentral.com/news04003.htm
•Date: 20th June 2008• Region: World

Can your call centre handle a disaster?
Creating business continuity plans for call centres. By Jeff Weil.
http://www.continuitycentral.com/feature0591.htm
•Date: 20th June 2008• Region: UK/World

Developing economies using ‘risk’ to increase competitive advantage
Developing economies have overtaken developed markets when it comes to capitalising on the benefits of risk management, according to a new study from BT Global Services.
http://www.continuitycentral.com/news04005.htm
•Date: 20th June 2008• Region: World

Security management in the supply chain
UKAS looking for feedback.
http://www.continuitycentral.com/news04001.htm
•Date: 19th June 2008• Region: UK/World

Learn from NIST: Best practices in security program management

Wednesday, June 18th, 2008

Mike Rothman, Contributor - 06.17.2008

Information security is a hard practice. When nothing happens, it’s a good day. Attackers only have to hit the jackpot once in order to be successful. Security professionals have to be right every time. No wonder most practitioners continue searching for the "silver bullet," which makes all of the angst and risk go away.

A large portion of effective security practice is reaching a common level of proficiency. Since patching systems in a timely fashion and configuring them in a secure manner increases the likelihood that an organization will remain secure, the U.S. government, after a rash of information security issues, decided the best way to make that happen would be for all agencies to adhere to a certain set of standards to protect their information.

This act of legislation, known as FISMA, or the Federal Information Security Management Act of 2002, put the job of defining what is right and what each agency needs to do into the hands of the national standards bearers — namely NIST (the National Institute of Standards and Technology). Thus, NIST has put forth standards and guidelines intended to provide a level of protection for information resources.

Two of NIST’s seminal documents are special publication 800-100, the Information Security Handbook: A Guide for Managers (pdf) and special publication 800-53, Recommended Security Controls for Federal Information Systems (pdf). As every security practitioner looks for a leg up on the bad guys, a great way to do that is to take a look at these two documents and figure out whether the guidelines conflict with what currently exists in your organization. What you discover will help define problems that demand critical attention.

The Information Security Handbook (800-100) attempts to define all of the considerations required to protect information. It treats terms such as governance, systems development life cycles, security assessments, risk management, incident response and many others in detail — in fact, one hundred seventy-six pages of detail. Think of 800-100 as a framework for information security, much like COBIT and/or ISO 27001/2 define the scope of an information security program.

Looking past the dry style and constant references to other NIST documents, the clear message in 800-100 is that security is a broad and complicated discipline that requires a lot of cooperation throughout the entire enterprise. Most already know that, but unfortunately too few organizations practice it.

Practitioners, however, should use some sort of framework to guide their efforts, whether it’s ISO 27001, or 800-100 because of a mandate (for U.S. agencies, for instance). When considering a framework, consider the overarching goals of the security organization. If its goals are more modest, such as simply becoming more relevant to the business, then guidelines like those in The Pragmatic CSO may be appropriate (shameless plug).

There are no wrong (or right) answers. There are no rewards for using one approach or framework over another. The only reward for missing something, which results in a breach or incident, is tossing hard work out the window.

The recommended security controls document, 800-53, takes 800-100 down to a practical level by defining the scope of potential security controls, as well as detailing a process to figure out which ones should be implemented. The document clearly states that controls in the absence of a structured program will not be effective, which is absolutely true.

The controls specified in the appendix of 800-53 are without context, so they aren’t particularly useful aside from providing a laundry list of the many controls that exist. What the appendix doesn’t (and shouldn’t) have is a directive concerning what should be implemented.

The process of defining the control set is simple. It starts by categorizing the data to be protected, then goes through selecting, documenting and implementing the controls. It also presents a closed-loop system of assessing and monitoring the control set to ensure it’s accurate.

Overall, even with all the constant churn and change inherent in protecting information, there is certainly some valuable information in NIST’s special publications. It wouldn’t hurt for most practitioners to go back occasionally and refresh their memories of the theory behind the activities they perform every day.

NIST has a lot of smart people and spends a lot of time trying to figure out what will work for the U.S. Government, so there is bound to be useful information there for enterprises as well. Not everything will be applicable, but a lot will be.

The skilled security professional understands the difference.

About the author:

Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com’s expert-in-residence on information security management. Get more information about The Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman@ securityincite.com.

Business continuity - are we still missing the point?

Monday, June 16th, 2008

By Dominic Hill, consultant, Siemens Enterprise Communications Limited

There have been a number of papers and presentations recently looking at the nature of business continuity and tools used to deliver it – from the future of the BIA to the importance of building evacuations. With the arrival of Part 2 of the British Standard for Business Continuity Management (BS 25999-2), there is now a defined management system – the business continuity management system (BCMS) - and a means of measuring performance of business continuity capabilities, should organisations choose to do so. But are we missing something? Have we created our own definition of continuity?

The Oxford English Dictionary (1999 edition) defines continuity as ‘the unbroken and consistent existence or operation of something over a period of time’.

In BS 25999-1:2006, business continuity is defined as ‘strategic and tactical capability of the organisation to plan for and respond to incidents and business disruptions in order to continue business operations at an acceptable pre-defined level’.

In this definition, the ‘unbroken and consistent existence’ has been replaced with ‘plan for and respond to’ and ‘continue’, words which imply reaction and recovery. If we look at the services offered within the business continuity/disaster recovery arena today, it is easy to see the focus on responding to incidents and recovering capabilities in:

* The provision of disaster recovery services;
* The provision of work area recovery services;
* The variety of software to generate, maintain and disseminate plans;
* A plethora of communications tools allowing call cascades and other abilities.

Many of these services, and the business continuity capabilities of the organisations that use them, are reaching levels of maturity never before seen, and are thus giving those organisations a degree of confidence in their ability to recover.

This is laudable, nay essential; as the BC manager’s maxim should be ‘Expect the unexpected’! But do these services really provide continuity for the business? It could be argued that this is really business recovery, although for some that term has its own distinct meaning. Are we missing something? Would it not be even better to avoid the incident or business interruption in the first place, leaving the recovery for when there is no other option?

Why have a disaster if you can avoid it?
Many organisations spend a significant amount of money and effort on recovery capabilities and the associated plans, but neglect to address the issues that would make the operation more resilient and less in need of recovery in the first place. Could that money be better spent on disaster avoidance in the first place? To a degree the answer is going to be dependent upon the state of the organisation, its ability to change and the willingness, of those in charge, to accept risk.

A key tenet of BS 25999 is ‘embedding the BCM culture within the organisation’ and this is probably the single most important thing when it comes to being pro-active about disasters. When a system, regardless of whether it is business or IT, is designed and operated with continuity in mind, the subsequent need to mitigate risks with recovery capabilities can be reduced.

Resilience: the unbroken operation
In order for a system to have unbroken operation, the threats to that operation must be reduced or removed. When BCM is a recognised part of the daily processes, and not something that gets retrofitted in the later stages of the system lifecycle, it is easy to consider these potential threats at the start of that lifecycle. Typically the causes of threats include:

* Location of the system – This has a wide scope and should consider location at all levels – both physically (geographically and within the campus and building) and logically (within the organisation). Taking as an example a new IT system, are there opportunities to implement it in a location discrete from main user population as well as from physical risks arising from location and environmental factors.

From the business viewpoint, the who and how should be considered. Does the system require input from certain members of staff whose roles make them unlikely to be available at the same time? Is specialist knowledge vested in a single individual, thus creating a potential single point of failure?

* Access to the system – Again this works at both physical and logical levels. Again considering an IT example, there is little point in implementing a new system and a corresponding recovery capability if the system is situated in a location that does not afford it appropriate protection – environmentally or from a physical security point of view. A classic technology example is siting critical equipment in an IT suite that is used by members of IT staff as a shortcut to other parts of the building. A large number of incidents arise from human error in some shape or form, accidents do happen.

Similarly from a business viewpoint – especially in these days of increased concerns over the safety of data – who has access to what, by what means and for what purpose must be considered. For example, are personnel records only available as paper copies – if so where are they held, is it secure?

* Design of the system – A single IT system can look cheaper than a design that addresses potential single points of failure with some sort of redundancy of functionality. On paper that is. When the cost of the corresponding recovery capability is included the picture may be very different. Similar arguments exist for non-IT tasks, where the ability for multiple teams (possibly on different sites) to carry out the same activity can address not only loss of site scenarios but also loss of staff – whether through pandemic or other cause.

* Systems documentation - or the lack of it - In today’s fast moving world it is not uncommon for less than ideal documentation to be produced during the development phases, as the pressure to deploy the system increases. Limited documentation leads to a potential lack of understanding of how things work, which increases the threat of mistakes. Furthermore it is very hard to maintain and protect the system if it is not clearly understood where the interdependencies lie and the possible impacts when changes occur around it.

Understanding the business is one of the four stages in B2 25999 and is as essential to the resilience aspects of business continuity as to the recovery aspects. Good systems documentation has a major part to play in this.

* Control of changes to the system – most systems will, after an initial period, operate in a steady state, until something changes! This is especially true in IT, which due to the ever developing nature of the technology is probably subject to more change than most business processes – the changes occurring in the form of software patches, upgrades, hardware enhancements for capacity improvements etc. The same can also be seen in the non-IT space, where changes to business process manifest as the results of mergers and acquisitions or the outsourcing of parts of the operation. By controlling the way change occurs – especially considering the impacts from all aspects – the threat from change can be minimised.

When these areas are considered throughout the whole lifecycle of a system and appropriate decisions made, the result will be a more resilient system that is fit for the purpose for which it was intended. As with anything in the business continuity space, this is not rocket science, just common sense, but it appears to be something that is often ignored in favour of cheaper or short-term solutions or because the challenges are too great.

Challenges associated with implementing resilience
Implementing resilience can have significant challenges associated with it, including:

* Cost;
* Outsourcing/supply chain management;
* How to get there from here.

However, each of these challenges provides a means to its own solution as they can be used to improve resilience.

Total cost of continuity
This is a variant of the well known ‘total cost of ownership’ concept and is proposed here as a means to understand exactly what costs are incurred in providing true continuity for an organisation.

Typically organisations look at their recovery contracts, sum the costs and label the result as the cost of business continuity. This is misleading as it takes no account of the cost involved in setting up and maintaining business continuity within the organisation. In particular it ignores the cost of resources required for the exercising (testing) of recovery plans, both IT and non-IT. These costs can be quite considerable when the effort required for preparation and carrying out exercises across the different departments is considered, but they are often lost within the operational costs of the departments involved. Also, the more specialist the recovery processes the more resource is required, in addition to a potential for greater frequency of exercising (to ensure that all appropriate staff gain the necessary experience).

If a more realistic approach is taken and the resource and exercising costs (in particular) are included, the total cost of continuity may well look very different. This may provide sufficient justification for implementing a more robust design that negates the need for much recovery.

Outsourcing
More and more the outsourcing of discrete parts of operation is seen as a cost saving exercise. While this may be true, there may also be benefits in the form of decoupling those parts of the operation physically as well as logically. Resilience may be improved, but out of sight is out of mind as the saying goes – so the emphasis shifts to one of supplier management, which must be supported by carefully prepared and suitably detailed legal contracts. This is an area of business continuity that is experiencing rapid growth as organisations mature in their own continuity capabilities and start to look more closely at those suppliers (outsourcers included) on which they depend.

Change as a mechanism for delivering resilience (and hence continuity)
Applying changes to an existing system in order to improve resilience is rarely easy – especially if it involves withdrawing previous access. It is easy to argue that things ‘have always been done that way’ and that disasters had not occurred so change is unnecessary. The point can be illustrated with statistics, but not conclusively, for either side! The governing factor must be what is best for the unbroken operation of the business in a fit for purpose solution.

Fortunately, change can work in favour of these attempts to achieve resilience. In the area of technology (not exclusive to IT) the need to refresh equipment every three or four years provides an opportunity to implement measures to improve resilience. Similarly in the business space, changes in process, whether brought about by technology or changes in business practice, can be used to improve resilience here too.

Summary
While the typical focus of business continuity today is arguably on recovery activities, there is much to be gained from the pro-active side of continuity – providing the unbroken operation in a way that is fit for purpose. Maybe the time has now come for attention to be paid to this much neglected area of business continuity; maybe it will be the next to mature? After all, why have a disaster if you don’t need to?

Siemens Enterprise Communications Limited will be exhibiting at the Business Continuity Expo and Conference held at EXCEL Docklands from 2- 3rd April 2008 - the UK’s definitive event for managing risk, resilience and recovery. This event will explore the solutions and best practice to ensure operational continuity and protect a company’s interests before during and after an incident. For further information visit www.businesscontinuityexpo.co.uk

July 2008
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
28293031EC

Upcoming Events

  • No events.

Just as with the Y2K crisis of seven years ago, IT workers are being called upon to don superhero suits and save the enterprise from impending technology trouble. But this time, IT will be sifting through the complexities of the federal Sarbanes-Oxley Act of 2002

Public Companies over 75 million already need to comply by 12/15/2007...

Will your SMB be Ready?


Google
Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Sign up for our Email Newsletter