The IT security industry loves its acronyms, why is anyone’s guess – maybe it’s a speed thing, perhaps it’s the whole idea of writing code or overcome language barriers, I’ve even heard “it’s to do with saving bandwidth”, whatever! What I do know is it’s confusing for those on the outside to keep up when the IT crowd are in full flow – a typical discussion would be ‘what’s the difference between SED and FDE and which is better?’ If you found you reworded the question to ‘what is’ then read on – I’m going to give you a sneak peak inside the mind of a geek.

Today, every business utilises technology in some form. However, this miracle of science has a split personality – a silent evil slashing an enterprises’ artery and haemorrhaging sensitive data, whilst the other is white knight reversing the tide and stemming the flow of bad blood generated with each data breach.

WIIDWID?

So let’s begin with why IT is doing what it’s doing. First is the realisation that it’s not alone in its penchant for acronyms, regulators have affection for them too, resulting in a common ground between the board room and the IT domain with compliance a significant driver to both :

DPA – The Data Protection Act 1998 is a UK Act of Parliament and the main piece of legislation that governs the control and protection of personal data.

PCI DSS – The Payment Card Industry Data Security Standard is a worldwide information security standard created to prevent credit card fraud through increased controls around data and its exposure to compromise.

HIPAA — The Health Insurance Portability and Accountability Act of 1996 is a set of US federal standards that requires healthcare organisations to implement security standards that protect (and keep up to date) patient data and to standardise on electronic data interchange.

SOX – The Sarbanes-Oxley Act of 2002 is a US federal law. The bill was enacted as a reaction to major corporate and accounting scandals. It covers issues such as auditor independence, corporate governance, internal control assessment and enhanced financial disclosure.

WATDIW?

Okay, that’s why, so the natural progression is what are they doing it with?

FIPS 140–2 — a U.S. government computer security standard used to accredit cryptographic modules. It defines four levels of security, simply named “Level 1″ to “Level 4″ however, it does not specify in detail what level of security is required by any particular application so it should not be considered as a guarantee that the product is secure.

Common Criteria – is a framework in which users can specify their security functional and assurance requirements, vendors then implement and/or make claims about the security attributes of their products, and testing laboratories evaluate the products to determine if they actually meet the claims. As with FIPS, just because a product is Common Criteria certified, does not necessarily mean it’s completely secure.

The Cloud – describes a new supplement, consumption and delivery model for IT services over the Internet.

Keylogging – tracking the keys pressed on the keyboard in a covert manner to steal passwords, banking details, etc. Previously a piece of malware, there are now hardware instances – for example a keyboard that looks legitimate so this is a diversifying threat.

DLP – data loss prevention refers to systems that identify, monitor, and protect data in use (e.g., endpoint actions), data in motion (e.g., network actions), and data at rest (e.g., data storage) through deep content inspection, contextual security analysis of transaction and with a centralised management framework.

Encryption – the conversion of data into a form that cannot be easily understood by unauthorised people. Decryption is the process of converting it back to its original form.

FDE – Full Disk Encryption, does what it says on the tin, using disk encryption software to encrypt every bit of data that goes on a disk or disk volume (excepting the Master Boot Record, which most FDE solutions leave unencrypted)

SED – a Self Encrypting Drive is a hard drive based on the Trusted Computing Group’s specifications, it can lock-down data automatically in less than a second and can be immediately and completely erased in milliseconds. SEDs are easily deployed and managed cost effectively and are interoperable across PC platform types. It is an emerging technology so watch this space to see if it delivers.

BitLocker Drive Encryption – a full disk encryption feature included with the Ultimate and Enterprise editions of Microsoft’s Windows Vista and Windows 7 desktop operating systems, as well as the Windows Server 2008 and Windows Server 2008 R2 server platforms. It’s designed to protect data by providing encryption for entire volumes.

U3 enabled – U3 Smart Drives are regular USB flash drives with a twist. Programs can be installed on them that launch independently of the machine it’s inserted into and the data from those programs travels on the device – leaving nothing behind. Whilst beneficial in the fight against data leakage, it has a malicious persona – for example, if it’s preloaded with malware and plugged into a logged on PC it could inject a virus into the system that is untraceable.

Black List – a list or register of items, for what ever reason, are being denied a particular privilege, service, mobility, access or recognition.

White List – similar to a black list but instead of denying, you stipulate which are accepted so it’s easier to build up from a security perspective than eliminating backwards.

SAM Database – the Security Accounts Manager database, used by Windows (and possibly other OS’s), manages user accounts. It’s implemented as a registry file that is locked for exclusive use while the OS is running. If its contents were discovered by subterfuge, the keys are encrypted with a one-way hash, making it difficult to break. Some versions have a secondary key, locking the encryption to that copy of the OS.

TPM – Trusted Platform Module offers facilities for the secure generation of cryptographic keys, and limitation of their use, in addition to a hardware pseudo-random number generator. It includes capabilities such as remote attestation and sealed storage.

Acronyms may be confusing but are not designed to make the user sound superior, they’re just an industry idiosyncrasy, we all have them. However, the threat against data is serious and we musn’t let language cause a misunderstanding that thwarts our efforts – after all, it’s not a necessity it’s a requirement.

Sean Glynn – VP Marketing Credant Technologies

Additional Information:

Credant Technologies is exhibiting at Infosecurity Europe 2010, the Number One industry event in Europe held on April 27–29 in its new venue of Earls Court, London. The event provides an unrivalled free education programme, with exhibitors showcasing new and emerging technologies and offering practical and professional expertise. For further information, please visit: www.infosec.co.uk

It has long been recognised that this “divide” creates more problems that it solves, after all most businesses could not continue to operate successfully if their IT services were unavailable for a period of time, depending on the nature of your business this may well range from a few hours to several days.

The launch of BS 25999 has established a Business Continuity Management (BCM) standard which intrinsically links BCM, Incident Management, and IT DR. Essentially the key message is to have true business continuity you must also have strong capability.A disaster recovery plan should interface with the overall business continuity management plan, be clear and concise, focus on the key activities required to recover the critical IT services, be tested reviewed and updated on a regular basis, have an owner, and enable the recovery objectives to be met.

Recovery Objectives

The two key recovery objectives which many people are familiar with are: the recovery time objectives, how long can my business continue to function without the critical IT services (how quickly must I recover the service from the “decision to invoke”) the recovery point objective, from what time in my processing cycle am I going to recovery my data (how much data am I prepared to lose or have to re-enter from an alternate source).

There are several options, these are:

* Zero data loss, recovery to the point of failure
* Start of the current business day (SoD)
* End of the previous business day (EoD)
* Intraday

Intraday is a point between the last available backup either SoD or EoD and the failure, for arguments sake midday period end, the weekly or monthly backup

Additionally there is an additional measure, this is the Maximum Tolerable Outage (MTO), the MTO is the maximum time that my business will survive from the initial service interruption.

The recovery objectives must be based upon solid business requirements identified by the Business Impact Analysis (BIA) process.

This figure above clearly demonstrates the correlation between the incident starting, the reporting process, the investigation process, the decision making process, and the recovery process. If the MTO is 12 hours and the IT DR process takes 8 hours to perform from the invocation point then the decision to invoke has to be made within 4 hours of the initial incident.

Knowing this “lead time” is crucial to implementing an effective incident management and escalation process. The recovery time objective is where most misunderstanding occurs between the Business and IT Department.

The message from IT to the Business is “of course we can recover services within your required recovery time”.

The hidden message is assuming we start the recovery immediately the incident in detected. Generally speaking many organisations usually recover from minor incidents or service interruption well within their MTO.

The following diagram gives a high level incident management and DR invocation flow:

Disaster Recovery Plan Objectives

The key objective of a disaster recovery plan is to detail the key activities required to reinstate the critical IT services within the agreed recovery objectives. The most effective start point for any DR plan is the “Declaration of a Disaster” once an incident has been deemed serious enough that “forward fixing” at the primary location is impractical or is likely to result in an outage expending beyond the Maximum Tolerable Outage.

There are a number of common mistakes which organisation make when creating a DR plan, these relate to the level of detail they contain and the “standalone” nature of their construction.

So what level of detail should the plan contain?

The answer will depend on who you ask, the more people you ask the varied number of replies you will receive. It is advisable to keep the IT DR plan as concise as possible and focus only on the key information required at the time of a disaster.

So what information should the DR plan contain?

As a minimum the plan should contain the following information:

A statement detailing the scope and capability of the DR Plan, exactly when should this plan be used and what “consequences” are covered. It is advisable to focus on the consequences of an incident rather than the cause.

Why focus on consequences rather than the cause?

It is really important why the data centre is destroyed? As far as the DR Plan is concerned the answer is no. The same process and recovery stages will be followed regardless of the cause, fire, flood, terrorist incident, or the proverbial aircraft impact will all result in the partial or total destruction of the data centre.

The only relevant question is what is the impact and can I realistically continue to host servcies from my primary site or should I invoke and recover/resume the critical services at my secondary site.

A description of the key roles and responsibilities so that anyone assigned to a particular role in the recovery team understand what is required of them. Should you name individuals in the plan? Ideally individuals who are to be expected to perform a particular role should already be aware that they are likely to be called upon and should have received the relevant training. It is advisable to record the names and contact details of individuals in the relevant section of the overall BCM plan rather than the DR Plan. There is no reason why the individual names at the time can’t be entered into the recovery log as the “designated recovery manager” or other predefined role.

A summary of the critical services, their recovery objectives and recovery priorities, this information may be lifted from the Business Impact Analysis (BIA) performed as part of the overall BCM process. Summarising them in the invocation plan will remove the inevitable discussions at the time of the incident and provide a reference point for the recovery teams. Third party contact details, particularly those that may be required to assist in the recovery effort or those that provide recovery servcies, for example:

The secondary (DR) data centre service provider, you will need contact details, address, maps, and of course the invocation process and codes. It is advisable to do this as soon as it becomes clear the incident is likely to become a disaster recovery situation. You can always “stand down” if the incident can be forward fixed (some service providers may levy a charge for this);

Your media handling company. Are your disaster recovery tapes removed from your data centre and vaulted off-site? If so you will want to arrange for them to be retrieved and sent to your recovery centre at the earliest opportunity; Mobilisation of the recovery teams.

What teams and individuals need to be contacted to recovery the services, at this stage of the recovery the incident management team will already know the extent of the incident and should (if not you need to make sure you do at the earliest opportunity) have placed the recovery teams on standby.

The plan should teams and skills required, not individuals. Individual contact details have to be recorded somewhere, it is normal practice, as part of the overall business continuity management program to have “contact lists”, rather than repeat the detailed contact information the DR Plan should reference the relevant sections in the BCM plan.

Detailed recovery activities and sequence of events, including pre-requisites, dependencies, and responsibilities.

What level of detail should you include in this section of the DR Plan?

This is very much down to personal choice, however, as a minimum you should include:

The recovery process and flow of activities;high level activities, for example, load operating systems, install application software, restore data, synchronise database, make configuration changes, post recovery checks, open service to users; pre-requisites and dependencies for each activity; responsibilities, who will perform each activity.

Should you include the detailed activities for installing an operating system or restoring a database? The detailed recovery activities should be held locally by the team responsible for performing these activities. There are several reasons for this, the “how do I install Windows” instructions will be used for business as usual activities, minor incidents, and disaster recovery. The DR Plan only needs to reference these documents, if you find it an absolute necessity to include these in your DR Plan then do so as an appendices and not in the main body of the document, don’t allow key purpose of the DR Plan to be lost in un-necessary or duplicated detail.

Testing the Disaster Recovery Plan

IT DR Testing should be performed on a regular basis, the exact frequency very much depends on your own organisational needs. However, it is usual for “full deployment” tests should be performed, as a minimum, on an annual basis. There are of course other “trigger points”, for example, a change in your infrastructure that affects your disaster recovery strategy, i.e. moving from active/contingency recovery model to an active/passive recovery model.

What do I test?

This question is probably the most common question asked, and the answer is simple, you test the plans, the process, the people, and the infrastructure, in fact every component required to recovery and resume your critical IT services.

What are the key objectives of a DR test? There are several key objectives of a test, the main ones are:

Exercise the recovery processes and procedures familiarise staff with the recovery process and documentation; verify the effectiveness of the recovery documentation; verify the effectiveness of the recovery site; establish if the recovery objectives are achievable; identify improvements require to the DR strategy, infrastructure, and recovery processes;

What is the scope of a DR test?

The scope will very much depend on the maturity of your DR strategy and capability, it is important to scope the test to stretch the objectives and success criteria of the previous test, for example, if this is your first test, you may not want to have the entire user community scheduled to come in and perform lots of testing, you may wish to limit the scope to just IT staff and maybe a couple of “friendly users” to test functionality. Depending on the complexity of your environment it may take several tests to build confidence and perform a “full deployment” test.

Common DR testing mistakes are:

Operating within your comfort zone, for example, recovering the servers you know you can recovery whilst avoiding the more difficult components

Not testing the recovery of a service but focusing on the hardware, systems, and applications. Remember, a particular service may require several servers to be recovered, it may also require data held on local drives and network attached devices, and network connectivity from the data centre to the user. trying to achieve too much too soon and overstating your DR capability and readiness

Not planning appropriately, testing and live invocation are very different. In a live invocation you do not have a live environment to protect. Consider the impact that testing may have on your live services.

Engage with the appropriate people at an early stage, a “full deployment” test may take several weeks to plan.

Siemens Enterprise Communications Limited