More and more organisations are moving their data to the cloud. I get the
opportunity to work with a lot of different companies, and one of the
things I've noticed very consistently is that organisations are more likely to be
breached after they go to the cloud than when there are still on-premises. That
leads me to the obvious question: is the cloud secure enough?
Welcome back to The Pro Tech Show - the place for tech, tips, and advice for IT
Pros and decision-makers. Now when we say "the cloud", it's important to realise that
there are lots of different clouds and they're not all created equal.
There's a common meme you've probably seen: "there is no cloud, it's just someone
else's computer". Now that's obviously a crass
simplification. If you take Amazon Web Services and compare it to your laptop,
I'm sure you'll notice one or two differences there. But it does have a
point. If your data lives in the cloud, then ultimately it does live on someone
else's computer. When we're talking about the security of your data then the way
that other person manages your computer really does matter. One of the
benefits of cloud is you don't need to know how it all works. Which means you can
spend your time worrying about something more important. One of the downsides of
cloud is you don't know how it all works. So if it was really bad behind the
scenes, you wouldn't necessarily know it. I've seen some seriously shoddy kit,
operated by people with very little idea what they're doing,
masquerading as a public cloud service. It varies from that, all the way to the
sophisticated heights of Microsoft and Amazon; and everything in between. Now just
because a cloud provider is very small compared to Amazon doesn't mean they're
not very good, and this is where it gets difficult. So how do you know that
they're taking the security of your data seriously? One of the things I recommend
is quite simple. Ask them. Ask them how they're protecting your data and ask for
evidence. Here's the thing: if a company's taking security seriously, they'll be very
happy to talk to you about it. You're literally giving them the opportunity to
tell you how wonderful they are. If, on the other hand, a company doesn't want to
talk about it. If they say that they're so secure that talking about the
security would somehow compromise it, then that is an immediate red flag. What
they probably mean is that if people knew how bad it was, they've be in serious
trouble. Avoid. By the way, if you enjoy this sort of content then don't forget to
subscribe for future videos. Now let's get back to that matter of security. If
you're using one of the really big providers like Microsoft or Amazon or
Google, then you can be fairly sure they're taking security seriously. They
kind of have to. They're too big a target not to. If their systems were breached,
that would make global headlines and cause massive reputational
damage. Their datacenters are physically secured using perimeter boundaries, manned
checkpoints, vehicle traps, motion sensors, video surveillance, infrared, biometrics...
You name it, they've got it. Let's take a look at Office 365 as an example.
Microsoft maintains strict separation between the people who manage the
software and the people who manage the hardware. That means the people who can
access the kit your data lives on have no idea where any of the data actually
lives, and the people who do know where the data lives have no way to access the
kit. That means if someone was trying to physically steal your data, they don't
have both pieces of the puzzle; and even if they did, the whole thing's encrypted
anyway. On top of that you've got sophisticated access control and
monitoring. An administrator can't just log on to your server - they have to make a
request, and they have to say exactly what they're going to do, when they're going to
do it, and what systems they need to do it on. If that request is approved, a temporary
account is provisioned that gives them just the access they need, at just
the time they said, on just the systems they said; an all of that access is fed into a
monitoring system that uses machine learning to look for anomalous behaviour.
The admins can only run a certain set of preapproved tools. Even if they somehow
managed to get something else onto the server, it won't actually run because it
has to be specifically whitelisted or it's blocked at the operating system
level. As a final precaution, every single server is rebuilt every two weeks on a
rolling basis. That's partly a precaution in case something nasty did
slip in, despite all of the safeguards; but it's also because patching is a pain
in the backside. When you're offering at hyperscale and
you've got all of that automation, it's just simply easier to rebuild the systems on
the latest version than it is to patch the software in-place. In order to keep
themselves ahead of the bad guys, Microsoft conduct red team versus blue
team wargames. They employ a team of hackers to try and break to their
systems, and a team of security professionals to try and stop them.
This helps them find weaknesses early, as well as helping them perfect their
defences. In theory you can do all of this yourself; and Microsoft being
Microsoft, will happily sell you a lot of the tools you need to do it. But, let's be
realistic. Doing this to the same degree of rigour as Microsoft or
Amazon is going to be cost-prohibitive for most organisations. Well that all
sounds really good! Yay for cloud, right? But hang on. If the
cloud is so secure, then how come people are more likely to be breached when they
use it? Well, so far I've only talked about half of the equation. The cloud
operates on a shared security model. That means the vendor is responsible for some
of it, and you're responsible for some of it. If you think of securing the cloud
like building a castle, where the vendor builds the walls and you build the gate;
there's no point to vendor making 30 foot thick walls if you're going hang a
curtain. I find this table helpful to visualise
it. I can't take credit for it - I've copied this off a Microsoft website. It's
not intended as a security diagram, rather it's intended to show where the
division of responsibilities lies for different types of cloud services.
Everything in red, you're responsible for; and everything in green, the vendor is
responsible for. This is useful to explain the broad differences between
the different types of cloud services, but it focuses on the differences, and
there are a whole bunch of responsibilities that aren't on there
because they don't really change. Let me add a few in. Now these are important,
because regardless of which type of cloud service you're using, these all
fall on you; and all of these are directly impacting the security of your
data. This area right here, the bit that wasn't
on the original table? This is where the vast majority of real-world breaches are
happening. This is the weak spot. You might be looking at that thinking "But
there's nothing new here. I still have to manage that on-premises.
Managing my devices my identities - that's not cloud specific?". No, it's not. In fact
there's nothing new here. Moving to cloud doesn't change those responsibilities,
but it does change the stakes. The simple and uncomfortable truth is that a lot of
organisations are doing a poor job in these areas. the recurring argument I
hear is "I've been operating this way for 15 years and I've not had a breach. Why
should I invest in security now?". With any risk, security or otherwise, there's an
element of luck involved. The less you choose to manage
risk, the more you're reliant on luck. For a lot of organisations, the reason they
haven't been breached yet is either because they've been lucky, or they
have been breached and they just haven't realised. Their defences haven't
stood the test of time because they're robust enough. Their defences have stood
because they've never been tested. When you move to the cloud your luck changes.
You no longer have the relative anonymity of the server at Bob and Jane's
Widget Factory. You're now Office 365 - one of the largest and most well-known
computer systems on the planet. That means you have a massive target painted
on you, and your defences are much more likely to be tested. Let's look at a
common example of how this works. A huge number of breaches originate in a
phishing email. This is an email that looks like a sort of email you'd expect
normally receive, and it usually links off to a website with a login; but
when you log into that website, it takes username and password and sends them off
the attacker. If you're going to target Bob and Jane's Widget Factory with a
phishing campaign, you need to figure out what their emails typically look like.
Who sends them? What sort of language do they use? What is the branding on those
emails? And once you've done that, you need to make your login page look like a
login page their users would expect to see. Again, with all the branding of one
of their systems. And once you've got their credentials, you need to figure out
how to use them. What systems do they have? How are they accessible? How can you
log in and extract the data? That's quite a bit of effort. Now if you were
specifically out to target Bob and Jane's Widget Factory, you'll be willing to put
that effort; in but most attackers are just looking for an easy score, and
individually attacking and researching lots of individual companies is not an
easy score. For an easy score you want to send an email to the maximum number of
people, with a minimum amount of effort, that means targeting the biggest
provider possible. One of the big global ones like Office 365 or G Suite. Now
while Bob and Jane are still on-premises an Office 365 branded email is going to look
a little bit out of place; and if it takes them to a login screen branded as
Office 365 that they've never seen before, then that's going to arouse suspicion.
Once they've moved to Office 365 on the other hand,
that email's going to look just like a lot of the
emails they receive every single day; and that login page is going to look like the
same login page they use every single day. At that point they're much more
likely to trust it and click the button. Once they click the button, it's Office
365, so the attacker knows exactly how to use his credentials to extract data.
This sort of thing is where we're seeing cloud services being breached all the
time. The weakness is the people using it. The vulnerability is the familiarity and
increased likelihood of being targeted. So are you better off staying on-
premises, then? Well, despite what the salesman may have told you, there's
nothing wrong with deployed on-premises services if that happens to be the best
solution for you; but it's not addressing the problem here. Think of it like a game
of dice. When you're in the cloud, you wake up
every morning and you roll a die. If you roll a six, your data gets stolen. Now I'm
not actually saying there's a one in six chance every day, it's just an analogy,
bear with me. But going by that analogy, if you're on-premises maybe it's like you
roll two dice, and you only lose your data if you roll double sixes. So that's
better, right? There's less chance of being breached? No. There's less chance of
being breached on your next roll, but over time both scenarios trend towards a
100% probability of you being breached. The answer isn't to add more dice. The
answer is to stop rolling, and that means taking your security responsibilities
seriously. The cloud offers plenty of opportunity to develop a strong security
posture. By taking advantage of hyperscale services by global industry
leaders, you can achieve a level of security that would be cost-prohibitive
to do yourself. But you have to actually do it. If you take advantage what the
cloud has to offer, you can be more secure than ever before; but if you just
bring bad practice to the cloud, it is more likely to punish you. One of the
best ways to defend against the sort of attack I've mentioned is to use
multi-factor authentication. Microsoft stats show it blocks 99.9 percent of
account compromise attacks. Fortunately for you, it was
also the topic of my very first video; which you can find right here. If you've got
that sorted, then maybe check out that other video down there instead. If you
found this one useful, then give it a like before you go, and don't forget to
subscribe for future videos. Thanks for watching, guys. See you next time!