,

Undermining security and weakening Android

I have Amazon Prime, I quite like their shows, and whenever I have some time to kill I’ll watch an episode or 3.

A couple of weeks ago, I thought it would be a good idea to install the official Amazon video app on my android device, so that I could download episodes and watch them when travelling. I previously had it on my iPad, so knew it worked well.

However, I wasn’t able to find the Amazon video app in the Google Play store. Perplexed, I went hunting, and quickly found that Amazon does indeed have an app for Android, only it isn’t on the official store.

Amazon helpfully has instructions on how to install the app on your Android phone or tablet from its own Amazon Appstore.

 

 

Screen Shot 2017-09-13 at 09.36.33.jpg

For those of you playing along at home, you may have spotted the obvious flaw in this approach.

To install the app, Amazon is advising you to “Go to your device’s Settings, select Security or Applications (depending on device), and then check the Unknown Sources box.)”

But there are others

Unfortunately, this isn’t isolated to Amazon. Ken Munro pointed out on twitter that the National Lottery also asks you to download its app from a dark alley in the back.

 

nat lott.jpg

Although, to its credit, the National Lottery does mention to, “Remember to change your security settings back to your preferred choice.”

Quentyn Taylor pointed out that Samsung also does similar.

So what’s the big deal?

The official Google apps store isn’t a complete safe haven. Malicious apps have bypassed the security checks and ended up in the app store many times. Companies like Amazon, the National Lottery, or Samsung aren’t fly-by-night companies that will deliberately push out insecure apps; so what’s the harm in downloading the app and switching security back.

For most users that aren’t technically savvy, the ability for their Android device to block downloads from unknown sources is there to prevent them from accidentally downloading malicious software. – Strike one.

The security industry has spent a great deal of time and effort to educate users in the dangers of downloading unknown files from untrusted sources, and this approach undermines a lot of those efforts. – Strike two.

Normalising such actions enables attackers to try similar tactics. After all, if companies like Amazon have legitimised the approach of turning off security settings and downloading apps from their own environments, it is something that any company could emulate. – Strike three.

The reality is that convenience trumps security most of the time. Users will intentionally or accidentally bypass security controls to get the app of their choosing, often leaving themselves vulnerable in the process. Which is why it’s important that manufacturers, providers, app stores, and everyone in between work together to help deliver a secure experience to users, instead of elements working against each other.

,

When culture eats awareness for breakfast

European startup CLTRe founded by Kai Roer has spent the last couple of years examining the security awareness and user behaviour problem through the lens of security culture.

Based on findings over the course of 2016, CLTRe has produced its first annual Security Culture report, co-written by Roer and Gregor Petric, Ph.D., an Associate Professor of Social Informatics and Chair of the Center for Methodology and Informatics at the Faculty of Social Sciences, University of Ljubljana (Slovenia).

Many existing security awareness reports typically measure and report on a few basic metrics – pretty often based around number of phishing emails user click on.

It is here that the CLTRe report differentiates itself, by delving into statistics and metrics to provide a view that is probably the first of its kind. It takes into consideration not just behaviours, but adds insights to the behaviours based on gender, geographic location, age, duration of service, or acceptance of norms across seven dimensions.

The report has insightful nuggets of information scattered throughout, such as an  examination of the cultural difference across various industries in Norway and Sweden.

Screen Shot 2017-05-09 at 12.19.48.png

The report explains at length why security culture metrics matter and the value they provide. It states that similar to technical controls, security culture must be measured in order to understand and measure change.

For example, reporting the number of clicks on a phishing exercise is useful but has its limits. Those metrics do not provide the motivations or drivers for the users.

Screen Shot 2017-05-09 at 12.26.26.png

Thoughts

For its first report, CLTRe has produced a great report with very detailed insights. It’s not something to be considered light reading, and some segments feel quite academic in nature. It’s not a knock on the report, it’s needed to elevate the discussion to the higher level needed.

For next years report, I’d like to see the inclusion of case studies or quotes from companies that have been measuring their security culture and how they have used the information to improve the security culture.

Check out the full report here (registration needed).

Let Kai and the CLTRe team know what you think: Click to tweet:

Great job @getcltre @kairoer on the human factor report. (via @J4vv4D)

Why did you write this report? @kairoer @getcltre (via @j4vv4d) 

,

The Growing Impact of Security Researchers

I’ve followed Scott Helme’s work for a while now and have been impressed with his approach. So was interested to find out that he had teamed up with BBC Click and Prof Alan Woodward to comprehensively dismantle a vendors claim to total security. Scott has published the whole story on his blog and The BBC Click episode is live.

This was a well-researched and executed piece, but let’s take a step back and look at the wider picture and what this means for vendor-research relations.

So, I felt it was a good time to grab some time with Scott to seek his opinions on some of the questions that came to mind.

One of the first things that strike me about Scott is his measured and calm demeanour. He has the look of a chess master that is quietly confident knowing that he’s always 7 moves ahead. The second thing I note is that I really can’t gauge how old he is. I think it’s one of the things that happens as you grow older, I find it increasingly difficult to differentiate between someone that is 20 or 35. They all just look “young” to me. So I look for clues such as ages of children, year of graduation, or years experience to try and make an educated guess.

What is secure?

Not wanting to waste time with warm up questions, I wanted to get to the heart of the matter. There is no benchmark or agreed standard upon when it’s appropriate to use the word secure, or claim a product is secure. The fact of the matter is that as far as technology goes, nothing is truly ever secure. So does that mean no-one should ever use the phrase secure at all?

On one hand one wants to avoid going down the route of legislation, or having stringent criteria in an industry that is constantly in a state of flux. On the other hand, Scott said, “We don’t see many car manufacturers rocking up with the safest car in the world that has no airbags or brakes.”

Which is a fair comment, but it is a lot easier for a lay person to see and understand security in physical products than in software.

The manufacturers dilemma
So what is a security startup to do? Nearly every security product has had vulnerabilities they’ve needed to patch – not even the largest of vendors are free of bugs.

Open source products, where the code is available for all to audit is no exception with products such as OpenSSL having had long-standing vulnerabilities. Given the landscape, what’s the best way to approach this?

Scott gives a half smile, indicating that it’s something he may have been asked many times. He told me that he believes that the more scrutiny a device or product has then the more likely you are to become aware of issues. “Researchers and bug bounties are your friend. They can’t replace traditional penetration testing and other standards or compliance requirements, but they sure add a lot of extra coverage, often for not a lot of cash.”

It’s somewhat a balancing act. After all, security costs time and money in order to implement properly. Far too many startups are caught up in trying to prove that their product serves a viable market and that there is demand before pouring resources into security.

Scalability
But is relying on researchers to find vulnerabilities a scalable model? There are only so many Scott’s in the world, and researchers will be drawn to particular products out of personal curiosity, or where their expertise lie. So many products simply slip beneath the radar.  The number of secure products being released outpaces the time and effort needed to properly validate their capabilities.

Scott agrees with the sentiment, and states that it ties into the issue of lack of standards. “Right now there is no regulation or standards, so researchers are all we have. Even basic standards would start to raise that minimum bar and begin the process of filtering out the crud. I do it because I feel I can make a difference, I enjoy it and it helps me keep my skills sharp.”

With great power
With time running out, I wanted to go straight for the jugular with my last question.

While one can commend the good work Scott and others do. With the recent release, we’ve effectively seen a company torn down. Surely that kind of approach can have a negative impact into scaring other startups from releasing any product at all?

If I were considering starting up a secure product, I’d be scared that you, or other researchers could shut my business down. Which would leave me with the choice of either not producing anything at all, or try to bribe you up front. While you may be above bribery, can’t say that for every researcher out there.

Despite my Jeremy-Paxman style attempt at getting a rise out of Scott, he remained patient with me.

“I certainly hope it wouldn’t scare them from releasing a product, but perhaps consider engaging a reputable security firm to analyse the product prior to release. I feel that’s the minimum any responsible company should be doing anyway. They can also engage the community with a bounty program to get private feedback prior to release too. If someone plans to bribe you, I guess you can’t do much about that, except beat them to the punch and fix the issues first. The internet is full of bad people :(”

The internet is indeed full of bad people, you cannot argue with that.

Make your vote count

The prestigious European Security Blogger awards are upon us. For those unfamiliar with the European Security blogger awards, it’s an award ceremony for bloggers who specialise in security and reside in Europe – at least that what I hope it means.

I am fortunate enough to have made it into the finals in five of the nine categories – which in itself feels like a great achievement considering how many super-awesome and cool security bloggers there are scattered around Europe. The categories I’m in are:

Best Security Video Blog
Most entertaining blog
Most educational blog
Best EU Security Tweeter
Grand prix prize for best overall security blog

Anyway, it would be a shame to let your vote go to waste so head over to  and make your vote count.

,

How to Fake Monitoring

You’re the new guy in the security ops team, they’re giving you training and put you on a very crucial and important job… Monitoring. You’ll be told how important the job is and how it is essential to be done correctly to ensure the ongoing safety of the company. But you notice that nobody really shows any interest in doing it. There’s are two reasons for this. Firstly, it’s usually a job that they don’t really understand how to do, but secondly, and more crucially, even if they do understand how it works, it makes watching grass grow an extreme sport in comparison.
Having been subjected to monitoring of all kinds early in my career, I developed a set of techniques which can be used to give the impression you’re a monitoring guru:
1. The Blink and Chin Rub:
Blink frequently and rub your chin. This tried and tested technique gives the impression that you’re deep in thought and analyzing each packet individually. Having a couple of crushed cans of red bull or coke will give the impression you’re a man on the edge and very few people will interrupt or ignore you. Every now and then let off a low level grunt.
2. Look for Key Values and Strings
A quick find for key strings and values will save you trawling through gigs worth of logs. Identify the key ones first and type them up separately. That way if anyone looks at what you’re doing, they will be impressed by your apparent ability to detect patterns. At the end of the day simply delete it and sound frustrated whilst muttering “false positive”, bang the table for dramatic effect before grabbing your coat and heading off home.
3. Be Vague When Questioned
When your boss asks for your thoughts on some anomalous network traffic you need to tread carefully. Deliver a vague opinion, add that you’ve been analyzing a list of key values and strings to get to the root cause (see 2). For good measure ask a question which direct the conversation away from your view. Something like, “what made you think of that?” would be perfect. It gives the boss an opportunity to wax lyrical about how they arrived at a conclusion.
4. Blame A.P.T.
Should the unthinkable happen on your watch, blame it on being an A.P.T, or it being a state-sponsored and highly sophisticated attack that has evaded all your detection controls. Turn it around on your boss and ask him how you’re supposed to keep track of everything with such outdated hardware and software where the enemy have access to unlimited funds. If you’re lucky, you could end up with your own personal SOC being commissioned.
5. Harass an ISP
During a quiet patch people will begin to get suspicious. So to shake things up, send a passive-aggressive email to a random ISP every few weeks threatening them with legal action unless they block the state-sponsored APTers from constantly bombarding your network. When a complaint is filed with your CEO, simply point to the previous breach and say you suspect the ISP to be compromised. Careful how you balance this because you don’t want to end up looking like a crazed conspiracy theorist. Tell them you’ll withdraw the legal threat, but will be “keeping a close eye on them.” No-one will ever suspect you’ve got no idea how the IDS logs work.
,

Infosec Friends

For all the talk about it being an echo chamber and the like, I’ve met a ton of people in security whom I otherwise wouldn’t have. As I was pondering over this over breakfast one morning, I came to the conclusion that I end up grouping my infosec friends into different categories. They probably look a bit like this:

Level 0 – These are your closest security friends. They are the guys who you look out for and they look out for you. If you see a bug in their code, you’ll sort it out for them. When they call you up at 3am because they need help with a security strategy presentation, you’ll stay up with them all night working on it. Whenever you are stuck for something, you’ll turn to them for help. They’re your best teacher and most annoying student rolled into one. You know how many kids each other have, their ages and names. You can never get rid of them and they can’t get rid of you. The amazing thing is that you may never have met some of these people in real life.

Level 1 – These are best friends. You hang out with them, connect with them on every social media channel. Bond with them on a personal level and hear out their problems. When you need a LinkedIn reference or someone to endorse your CISSP you’ll go to them. If there’s a job going in their team, they’ll do what they can to get you on their team. They are there for you when you are stuck pen testing a website, but won’t do much beyond getting pizza and running Nmap.

Level 2 – These are more friends of friends. You’ll meet them at conferences and local chapter meet-ups. Sometimes they may move up the ranks and get promoted to a level 1 friend or maybe not. They’ll retweet something witty you say and will like your blog posts. They’ll meet you for lunch but never offer to go any more than halves with you on the bill.

Level 3 – These are those security people you have to be friends with. Normally these are work colleagues. You learn nothing from them and often put up with their moaning and spreading of office gossip. Every morning whilst going into work you pray they will be sick and you don’t have to see them.

Level 4 – Anyone who follows you on social media like twitter or facebook that doesn’t fall into any of the other catergories. They are the trolls who follow you and make smartass comments whenever they can. They contribute nothing positive to security, yet linger around like a bad smell. Secretly everyone hopes they fall down an open elevator shaft onto some bullets.

CISSP Reloaded–Domain 8: BCP and DR

This is the 8th part on my CISSP Reloaded where I am revisiting the 10 CISSP domains I studied for many years ago to see what has changed and how much of it I have retained as well as adding in my own personal thoughts, experiences and rambles into the mix. Read the other domains here: (Domain 1) (Domain 2) (Domain 3) (Domain 4) (Domain 5) (Domain 6) (domain 7)

Do you ever watch those life insurance adverts where they show a family playing happily and then in comes the deep grim voiceover that somberly asks, “Who will look after them should the worst happen?” It doesn’t say the word death by heart attack, or falling from balcony to your doom or even death by PowerPoint. But we all know that’s what they mean.

Which is the exact same voice that goes through my head any time I’ve had to sit in on a Business Continuity or Disaster recovery planning session. I possibly I even end up speaking like that guys. “So tell me, how will you run your website…. Should the worst happen?”

“Who will answer your customers phone calls…. Should the worst happen?”

“how will we operate the projector… should the worst happen?”

Now you’re also going to have that stuck in your head and it will come out at the most inappropriate time causing you to chuckle to yourself while everyone around you thinks you’ve gone a bit loopy. I like how it’s worded in a non-offensive and open way, to bring about unlimited possibilities. It’s like a game of inception. You don’t want to say the exact words because you’ll look like a doomsday hater, but you want to plant the seed of doubt in their minds. Get them thinking.

If there’s nothing else you take away from this domain, take this lesson. Forget the technology, forget your load balancers and your availability criteria, when you talk to the business about continuity and disaster recovery, your job is to leave them feeling as paranoid as an A-List celebrity out shopping without wearing a pair of sunglasses 3 sizes too big to conceal their identities. I find that parents of children aged between 3-8 already have the necessary skills needed to be effective at this. They are used to giving out these subliminal messages to their kids. “you better clean your room right now young man, or you’re going to be in trouble.” Of course, the term ‘trouble’ is never really quantified. The kid usually conjures up some wild imaginative thing such as their parent will turn into a werewolf and eat them while they sleep. Whereas the parent is desperately hoping the child does what they’re told or they’ll be forced to make up some laughable punishment, like the naughty step.

Another of my favourite parenting techniques has to be the counting to 3 method. It’s where the parent tells the child to do something and the child stubbornly refuses. So the parent slowly, but very firmly starts to count. It becomes a battle of nerves at that point like a spaghetti Western standoff, the tension mounts in the room. The gauntlet has been thrown down by the parent, they’ve sent out a clear message that insubordination will not be tolerated. For a while the child resists…. Then the parent says “2”. At this stage time slows down, an eerie silence takes over, the child can hear the clock ticking, becomes aware of their own breathing and heightened pulse rate. The parent raises an eyebrow as if to indicate that if they reach “3”, the floodgates of hell will be opened up and demons will emerge from every corner and rip the child limb from limb.

So the child gives in, stomps their feet and does what they were asked to do. The parent sighs a giant sigh of relief knowing that if they ever reached 3, their whole game would be up. The bluff is saved to be repeated another day.

I have no idea how I’ve ended up talking about parenting techniques – this is the very reason I’ve been told I desperately need an editor, so they can take out all my crap. But that would probably turn a 4000 word chapter into 50 words.

Business Continuity Planning and Disaster recovery are usually uttered under the same breath and used somewhat interchangeably, but do they mean the same thing? Well they’re a bit like sisters who are born a year apart. They’re not quite twins, but the similarities are undeniable. They have the same mannerisms, probably share that same awkward snorty laugh and are the same build. But when you look closer you’ll note the differences, like how one has a mole on her left cheek or has 3 piercings in her ear whereas the other only has 1. This leads to it almost becoming an obsession with you wanting to check the mole out before speaking to either because you want to know exactly who you’re talking to. Which is how you should approach Business Continuity and Disaster Recovery. They’re the two sisters who everyone else mixes up, but you know who’s who because of their moles and piercings.

Sisters who aren’t twins and parenting tips? I swear this is the most messed up domain I’m writing about. Probably because I’ve got little experience in doing a lot of Business Continuity or Disaster recovery planning. I usually end up asking a project if they’ve considered it, and they grunt and mutter something about having bought two servers and installed one in each of the data centres which are 50 miles apart and I usually nod and tick it off on my checklist and make a mental note to go verify the data centres are actually ones the company owns and manages and to validate it on the plan. It would work a whole lot better if I actually made an actual note of these things on the piece of paper in front of me because I kind of forget mental notes. That’s the problem with mental notes. Depending on your mental capacity, you can end up forgetting them, or overwriting them with other notes, or even worse you start doodling on them in your mind. Which is why you should always document your business continuity and disaster recovery plans. The last thing you want is a tragedy hits and you have 8 different senior managers in a meeting trying to remember what they agreed would be the best course of action to take in the event of this incident.

Business continuity planning is rather pro-active. It’s like taking a first aid kit with you on holiday because you know that the kids will inevitably trip over and cut their knee. The first aid kit will allow you to take a bit of pleasure in disinfecting the wound while the child wails and apply a plaster. After a while your kid can carry on playing as normal. Or it’s like having a spare wheel in the back of your car. You have a plan that if your car journey was interrupted by a flat tyre, you could change it, or if you’re like my wife, you phone me up to come and change the wheel. This allows you to continue the car journey albeit with a slight interruption.

Disaster recover, as it names suggests is how you would recover from a real disaster. Like if your kid got taken hostage by flying monkeys who wanted to raise the man-cub as their own and name him Mowgli… or if your car’s engine blew up. These are disasters and the recovery is usually a reactive process. So having car breakdown cover so that a man who kills people on the weekends can drive up in his pickup truck, look around your car, confirm that the engine has blown up and offer to tow your car to a garage. I’m not sure what kind of plan you’d invoke to get your child back from the flying monkeys though.

Business Continuity Planning

BCP is all about continuing business activities whilst something has happened. My CISSP notes break it down into four phases:

1. Scope and Plan Initiation

2. Business impact Assessment

3. Business Continuity Plan Development

4. Plan Approval and Implementation

1. Scope Plan Initiation

As they say, a journey of a hundred miles begins with a single step. The scope plan initiation phase is the first step you need to take to create a BCP. In order to properly scope the plan, it’s important to understand what the company does, what activities are important or not and which systems are crucial to support the important activities. Now, if a company has done a good job of risk assessing and classifying all their assets, then this should be an easy process of simply going through your assets and ticking off the ones that are needed.

Unfortunately, it’s never that easy, so what happens is you end up setting up a working group of well-trained monkeys to go around with checklists trying to understand what all the assets are and trying to make sense of how the organization works. This highlights a fundamental disconnect between most security departments and the business. If you ever find yourself doing this activity in a business, stop and ask, if you don’t already know what the business does or what are the critical assets, then how do you know what you’re supposed to be protecting and where your security controls are most needed?

During this phase a lot of large organisations will setup a committee or two, a steering group and an advisory board of some sort. Just do what’s right for the organization and plough on.

2. Business Impact Assessment

The BIA is what we should be doing on each asset when it’s deployed. But again, we would have either misplaced the record or it would be so out of date that the BCP creation process will drive us down conducting another set of BIA’s on each system.

In simple terms, the BIA seeks to answer what the impact to the business will be if a particular system was rendered unavailable. Or if you want to jazz up the words a bit, what would be the impact to the business if a rogue state, sponsored some hacktivists to totally cyber-pwn your box.

There are different templates and complexities of BIA’s that different companies adopt. Generally though you’ll be working with someone in the business to answer the questions. Well crafted questions will allow you to prioritise the system you’re looking at, understand how it operates, and therefore reach some sort of scientific conclusion on what the impact to the business will be should the system be unavailable through any means.

You can then put it into a bucket for how much downtime is acceptable. For example, it could be 1-3 hours, or 1 day, 1 week or even 1 month or more than a system can be down before having significant impact. For example a monthly payroll system may only be used once a month, so if the system is down at the beginning of the month for a few days, there isn’t a major impact. Perhaps there are manual workarounds that could be deployed in the interim. On the other hand, there could be an online store that generates over 80% of the company’s revenue, so you can afford much downtime at all.

The important thing to bear in mind whilst completing a BIA and arriving at a conclusion is that people will answer questions based on their own understanding and view of the world. Once I was speaking to a person about the criticality of a system, to which he responded that it was very very critical and couldn’t be down for any length of time. Probing a bit further, I enquired as to why it was so important, to which he responded that without the system, he wouldn’t be able to do his job. I agreed that him not being able to do his job was most definitely an impact on him as an individual, but what would the impact to the company be? Would other processes fall down, would customers be unable to proceed with decisions, would the CEO be asking for data out of this system? He rather sheepishly replied “no, I don’t suppose anyone else would really notice.”

I tried to assure him that this wasn’t about his job security, I was just trying to figure out which systems need to be recovered first if we invoke Business Continuity procedures. He nodded, but I don’t think he believed me. The next time I walked past his desk he was on a jobsite.

The main point being that simply getting people to fill out a set of BIA questions alone isn’t sufficient. You need to be involved to a degree to ensure the quality of responses are sufficient.

3. Business Continuity Plan Development

By now you would have collated some information and saved some money by identifying redundant jobs so you have enough information to start developing the plan. The strategy should encompass everything that may need continuity, so that would not just be computing, but consider your facilities, people, supplies and other equipment. Things like planning for a transport strike and people couldn’t get into the office. Or if there was a blocked drain in the building and people couldn’t work just because of the smell.

Many years ago, when I first started work, there was a young graduate who had started at the same time as me. A few months into the job, he had an unfortunate accident and passed away. Naturally everyone in the office was upset by this incident, particularly his team members who directly worked with him daily. On his funeral all of his team and most of the rest of the office was out to be at the funeral. Sure it had a big impact on the company that day when nearly all of the IT support function was out, but no manager is going to prevent people from going to a funeral, and even if you could force a few people to stay behind, would they really be in the state of mind to operate efficiently?

When planning, keep in mind that people won’t always be in the best state of mind to make the most rational decisions. Factor this into your plans.

4. Plan Approval and Implementation

The emotional state of people during a disaster is a good reason why it’s so important to have your plan fully documented. Because it’s a lot easier to agree and document a plan of action in advance. What you do need to ensure though is that the documented plan is approved at right level. Nothing is more fun than having a documented plan that is ignored by some big chief who wants to play hero during an incident.

Also make sure that people are aware of the plan. Because if you’ve left the organization or are on holiday somewhere on the other side of the world when someone needs to use the plan, it’s no good if they can’t find it. But don’t make it publically available for anyone to pick up and read. After all, it could contain sensitive information about your company, it’s assets and other proprietary information.

Finally, keep the plan up to date. Why do you have a plan that talks about using the win95 recovery disk? Yes, I actually read that in a plan… in 2008!

Disaster Recovery Planning

DR plans are for when things really go bad. I’m not talking about a blocked sewage pipe, I’m talking about every single pipe getting blocked and spontaneously bursting thus flooding your entire building. It’s Armageddon, it’s a realization of those scenario’s you see in Hollywood movies but thought could never happen to you.

I find myself talking in the voice of the movie trailer guy as I write this.

Where DR plans differ from BCP is that with DR planning, you’re looking to setup a framework or a method of how the company can effectively make decisions in a logical way should the worst happen.

In essence, a DR plan will seek to minimize any decision making required by staff during a disaster. During an event, people may be emotional, worried, complacent, or just curious as to what’s going on and hence being distracted by what they need to do. It’s not the best time to expect them to be making strategic decisions. Having people know what they are supposed to be doing will hopefully protect the organization from major failure by minimizing the risk from delays in recovering from an incident.

The planning process is similar to the BCP process. So assuming you’ve already undertaken BC planning, you’ll have the BIA’s to hand, so you’ll start from defining what you need to do to for the business to recover. A lot of material you will read will go into the merits of having mutual aid agreements with other companies whose facilities you could share and vice versa if the need arises. Or having your own hot, cold or warm backup sites. Of course being so many years old, my notes don’t make any reference to the cloud. Which is also another place where businesses are hosting their critical applications.

It is interesting, because some companies a lot of companies are not factoring in cloud-based (or general 3rd party hosted) applications into their DR plans because contractually, the cloud provider is responsible for it all. Although, I’d argue that what would you do if your cloud-provider got hit by a disaster they couldn’t recover from. Then what would you do in order to continue your business operation? The answer will vary on the type of business and the criticality of the applications that are run in the cloud. The point is that you can’t blindly rely on a 3rd party provider just because they have claimed something in the contract. Which is why it’s important to conduct adequate due diligence on your 3rd parties to make sure they really do have the capabilities to backup their claims. It’s like would you seriously go into a dangerous situation armed with a gun that only fires plastic pellets and jams after 3 rounds? Or would you take in a fully tested and functioning AK47? It depends on the situation, but there are few times where having an AK47 doesn’t strongly increase your negotiating power.

Which brings us nicely onto testing. There’s no point in having a lovely and wonderfully orchestrated DR plan if it all starts to fall apart when you need it because somebody forgot to get toilet roll for the building or change the static IP addresses. There are different types of tests you can undertake such as:

Checklist

This may seem like the lazy persons test, but it is very cost effective. It’s where you send the plan to everyone and they all review it in their own time. It’s not really a test per say but more of a guide to agree the principles. Think of it as sending instructions to someone on how to swim, but without the cost or hassle of actually getting into the pool.

Structured walk-through

A step up from the checklist, it’s where everyone gathers in a room and walk through the plan collectively. Again, people don’t get wet, but it’s a good way to laugh at others responsibilities and duties in the plan.

Simulation

A simulation is where you do a dry run involving all the staff who will be involved in providing support in the event of a disaster. They’ll usually all be asked to reconvene at an alternative site and pretend there is a disaster going on around them. Most staff end up treating it as half a day out of the office and try to figure out what they’ll be doing once they finish.

Parallel

A parallel test is a full test of the recovery plan, using all staff and resources. The key point though is that the actual production environment isn’t touched and left running as usual. In effect you end up running a second ‘hot’ site for the duration of this test.

Full interruption

This is the real deal. Other than the burning building and screaming ladies, this is where the production system is shut down and the disaster recovery plan is tested to its limits. Although this is the only way to be absolutely sure you’ve got a proper recovery plan in place, it’s one that requires extreme bravery to execute. Most people stop and wonder, what if they can’t recover, what if something breaks, what if the main system is unrecoverable. So they usually declare that their parallel test was good enough and leave it at that.

Communicating externally

A disaster is similar in many ways to any other incident, except at a much larger scale and just like an incident, it’s important to have well-established communication channels setup via which you can get in touch with key contacts such as the police, fire services, medical facilities, utility providers, press, customers, shareholders, partners, the list goes on.

It’s a good strategy to utilize social media to communicate with your wider customer base as it’s usually quicker and more direct. So you see, social media isn’t all bad is it.

Another important communication strategy that needs to be put in place is dealing with staff and their families. If, as a result of a disaster there is a loss of life or serious injury, how would you communicate with the family? If, as a result of the disaster, the business is impacted so badly, they have to lay off staff. How is that communicated?

Communicating with the media is also something that needs to be handled carefully in the best of times, but even more so during a disaster. You want the company to be accessible, but also ensure a media trained spokesperson is nominated. The last thing you want is Bill from mainframe support on the 9 o clock news flapping his gums about the disaster that he knows absolutely nothing about because he was in the basement when it all happened.

They think it’s all over

Be sure the plan is very clear as to when the disaster is over. Usually this is when all operations are returned to the normal state in the original locations etc. This is important because it’s at that point you can take a snapshot of your data and compare it with pre-disaster as well as your assets and personnel to effectively gauge the impact.

Disasters are a good opportunity for thieves and fraudsters to attack. Setting off fire alarms in order to walk out of buildings with a couple of laptops is a common technique. You can also find the business is subject to vandalism and looting so try to ensure as many different considerations are agreed upon before you’re faced with a calamity.