HEADLINES

Who is responsible for cloud security?

The world is growing so weary of all those malware massacres in the Internet Wild West, that security is beginning to feel quite sexy.

Photo by Samuel Zeller from Unsplash.com

By Lionel Snell
Editor, NetEvents

It must be a sign of the times. The world is growing so weary of all those malware massacres in the Internet Wild West, that security is beginning to feel quite sexy.

The recent NetEvents EMEA Press Spotlight discussion – Enterprise Security Considerations for the Cloud – Containers, Perimeters, and Access Controls – added greater intelligence to the mix.

Ovum Principle Analyst, Rik Turner, discussed the challenges, and beginning with Cloud Security, he introduced the Shared Responsibility Model – chart below – and was surprised how few people in the audience had been aware of it.

His diagram showed three different delivery mechanisms, or ways of consuming cloud services: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). So, what is the security responsibility for the customer and what for the cloud service provider?

In IaaS for example: Amazon Web Services (AWS) take care of all the grey bits, from Virtualization down to Networking. But above that it’s the customers’ responsibility. “You are not going to get any money back from them if you are breached because you didn’t secure those layers above.” Similarly, for PaaS you are responsible for security in the top two layers. “If anything goes wrong with any of that, AWS would have to refund some money, or whatever”.

The shared security model is clearly very important for any enterprise migrating to the cloud: the enterprise will have to take care of security in all the red bits. So these are the very parts provided for by security vendors to the enterprise.

The joy, and the temptation, of SaaS is that it was so easy to sign up for – the IT department does not even need to know about it – hence the whole notion of shadow IT and the rise of Cloud Access Security Brokers (CASB) that sit between the users and their services – Fig 2. CASB was the first security response as it were to cloud adoption but: “A lot of the CASB guys have been acquired by somebody else and are now disappeared into the belly of much larger security companies with big broad portfolios”.

IaaS and PaaS are more complicated, because the enterprise customer has broader responsibility for security. What’s more, it is no longer just a question of spinning up Virtual Machines (VMs) because of increasing use of Containers, Microservices, or Serverless services – each with their own format. It’s a progression: VMs remove the dependence on physical servers; containers spare the spinning up of new VMs, and Serverless means you can forget these and just specify the functions to be supported – with a 70-80 percent saving in infrastructure costs.

So people are now talking more about Cloud Workload Protection Platforms – blocking and remediating attacks, and restarting the workload somewhere else – and Cloud Security Posture Management (CSPM), see the chart below.

CSPM is essentially a compliance function. It’s so easy now to spin up another instance either in the developer community or the actual production environment, that all of a sudden you’ve got another 50 VMs that security didn’t know about. So CSPM technology monitors and manages the spread of VMs to ensure compliance with company policies.

Rik Turner suggested: “I personally think that these two worlds will ultimately converge, because CSPM is itself starting to move in the direction of actually doing the remediation rather than just alerting. So, those two will become one… It gets a little bit more difficult with containers, in as much as you are starting to see smaller packages of code.” And with serverless: “things become more ephemeral… the life of a piece of code that’s running in a serverless environment may be a matter of milliseconds. How do I secure it?”

The theory is that we are moving towards a DevSecOps world, where the developers become responsible for embedding the security: “not a traditional developer concern, but we’re starting to see that”.

Moving to discuss perimeters and access control – Rik said: “the reason I want to make these separate is because this is the traditional world of virtual private networks… all very old-world stuff. Now, not only are your applications moving into all kinds of other environments, but fundamentally, your users have gone everywhere… So, I’m seeing a lot more complexity in terms of the actual access issue and the access control than there had been previously.”

After this very clear introduction, Rik opened up the discussion with his panel from Hotshot Technologies, nCipher Security, NetFoundry, Versa Networks and BA TestLabs.

Atchison Frazer, Worldwide Head of Marketing, Versa Networks, explained: “Versa is an innovator in the SD-WAN or WAN edge infrastructure space… one of the few vendors that from the beginning actually built a full-blown next-gen firewall UTM and web security into the same platform as the SD-WAN functionality. The issue for our clients isn’t so much the on-premise traffic; all SD-WAN vendors encrypt traffic on-premise at the highest standards.”

Philip Griffiths, Head of EMEA Partnerships, NetFoundry: “We are changing how the world connects their applications.” Referring to Rik’s examples he added: “So a DevOps developer could create connectivity between their branches, devices, containers, virtual machine environment – anything anywhere – using the public internet only… in minutes using APIs in a fully cloud-native approach.” Delivering the security, performance and reliability of fibre, over the public Internet.

Peter Galvin, Chief Strategy and Marketing Officer, nCipher Security – a company offering a hardware security module for protecting business critical applications and data for “things like digital payments, lift and shift to the cloud, encrypting information and protecting the keys and hardware – allowing a very high level of assurance.”

Aaron Turner, CEO & Co-Founder, Hotshot Technologies: “a security company that provides the best security to protect the least sophisticated customers from the most sophisticated attackers. We take the power of very high entropy encryption, combine it with the location services that are available, and help people shift to a true zero trust model for messaging, collaboration and identity.”

 

Jan Guldentops, Director, BA Test Labs: “I have been playing around with security for 20 years, sometimes as a journalist, sometimes as a neutral consultant. What I would like to do today is take all these cool ideas, all the terminology and see what can be real and what are the problems”.

Rik noted that the panel had four non-competing vendors, all with different approaches. Of these, only nCipher would he classify as a “true security company” because “the reason it exists is in order to secure stuff.” The same analyst’s eye would describe Hotshot as “an application provider who happens to provide secure applications, but it is in the business of certainly selling applications with security wrapped into them.” Whereas “NetFoundry is an application networking company which can, if it needs to, sell alongside an SD-WAN, but it can also sell independently as an alternative to SD-WAN”. Then: “You could say that Versa are really wrapping security in from the outset into SD-WAN offerings. So, it’s a little bit of a different thing. But they’ve still got – each got their own take on what are the great issues around cloud security and equally, around network access and access control”.

Starting with Jan Guldentops, who pointed out how people who could not manage security used the cloud as an excuse: “We’re going to outsource to the cloud as it’s all secure and all the problems are gone. That’s the first misconception I see all the time. We are going to the cloud just to be able to secure”. He also reiterated Rik’s point about the need for designed-in, rather than bolted on, security.

Peter Galvin did not agree. For him the cloud driver was agility and reducing spending on data centers. But what was overlooked was the top layer in Rik’s Shared Responsibility: the need to protect one’s own data. Guldentops reminded us that this protection was also a legal requirement.

Phillip Griffiths pointed out that people were rushing to a fast-evolving cloud with legacy thinking: “what we now see as wrong used to be best practice.” He criticized over-use of the term zero trust: “you can’t be zero trust if you trust the network or the perimeter”. Aaron Turner agreed about dated ideas of a perimeter, then referred to the very recent Verizon Data Breach Investigation Report that reported a doubling of the number of nation-state level attacks against small business: “how’s the average small business going to defend themselves against a nation-state adversary?” Hence his company’s emphasis on: “a new solution that helps those least sophisticated people protect themselves from the most sophisticated adversaries”.

The conversation moved to false expectations of perimeter firewalls in a world where every single cloud connected device is now a potentially vulnerable endpoint. Again, a tendency to trust security to the cloud, the latest add-on, rather than seeing the need to design it in.

Griffiths shifted the emphasis from trust to verify with: “we work with a three-letter government agency… to access applications on the cloud, they have to show five points of trust. They have to have a client on their laptop, they enter a password onto that laptop, they are wearing a watch with unspoofable hardware, they put their thumb on that watch to give biometric proof of trust and that watch also measures their EKG, so it can’t all be done under duress.”

As the team recovered form this paranoid bombshell, Guldentops reminded us: “If the prize is big enough – I mean if the prize on the end of the hack is big enough – somebody will come up with something”. Griffiths hit back with: “If you’re harder and more expensive to hack, people find another victim. It’s about having better shoes to run faster than other people when the bear comes along.”

Time for questions from the floor, beginning with Steve Broadhead – another long esteemed NetEvents gadfly. He could have been speaking for a world population of frustrated IT users – or should we say “sufferers” – when he began: “the fundamental problem there is IT is supposed to make life more simple and you’re just painting this amazingly complex picture. I’m just imagining my mother attempting to do what you’ve just described!”

Griffiths was quick to reassure us: “But at the other end of the scale, you can literally go on to our website, download a couple of endpoints, deploy into your cloud and, in five minutes, create a network. One of our customers connected seven AWS data centres in two hours the other day, while doing another job that implements multiple layers of security by design. So that you take away many of these threat vectors such as DDos, man-in-the-middle et cetera”.

Hotshot makes a point of securing the least sophisticated customers, so it was no surprise that Turner came next with: “We try to make it so that a family or a small business can deploy nation-state level protections in 30 seconds or less… so easy to use and so intuitive that you get that protection built in”.

Before NetFoundry and Versa could get their word in, Broadhead acknowledged their offerings, adding: “What you’re doing is fine; the problem is when it gets to the customer, they often make a mockery of what you’re trying to do by adding bells and whistles. Like having a beautiful car designed for minimum wind resistance, and people put a roof rack on it, right?”

Frazer for Versa saw this as a key challenge, and distilled from it a definitive case for automation: “Capital One has a thousand sites. They use digital labour delivered by Versa. It’s all automated. We have the NSS labs, we’re the only SD-WAN vendor that scored in the top vector of NSS labs rating. At some point, you have to automate as many of these functions as you can, be able to reprogram as needed and set those policies and have complete visibility on-premise through the cloud and back.”

Griffiths had an interesting example of a new cloud-native bank working towards an automated blockchain trust mechanism: “so that this electronic transaction with almost no humans involved in has legal bearing.”

For the final question: Antony Savvas, “IT Europa and Data Economy, among others”, lead to the room a very large elephant, namely “The US Cloud Act.” He suggested: “We might as well all give up because, at the end of the day, if a US agency wants your data in Europe controlled by an American company, it can have it. What are the security companies saying about this? I’ve heard that companies should simply encrypt their data and control the encryption keys. So, if a US vendor has to comply with the US Cloud Act, all it can do is potentially hand over encrypted data. What does the panel feel about this?”

This generated quite a buzz of “over-speaking” from which Galvin from nCipher stood out with: “Most of our customers are concerned about it. One of the reasons they are encrypting data and managing the keys themselves is to protect themselves from any subpoena activity. Not only the US government, but other governments have the right to ask for information and never even tell the person that data is being taken. The only way you can really protect yourself from that is if you are encrypting the data and maintaining ownership of the keys. They’ll get encrypted data, but they won’t be able to read it.”

Turner added: “The first question we ask to the General Counsel is, which laws do you want to comply with… because you can’t comply with them all. You can’t comply with US Cloud Act and GDPR and the Chinese data encryption law and UK encryption law. You have to do the risk analysis to trickle-down: so I’m willing to run the risk of not complying with the Chinese encryption law and I’ll run the risk of not complying with UK, and so on”.

Just in case there was anyone left still feeling secure, Guldentops cut in with: “There is one thing worse than not using encryption – using bad encryption – I’ve seen that quite a lot. There’s another problem: what is unbreakable encryption today will not be unbreakable in five years. In a cloud perspective that’s potentially the worst: because your data stays there potentially and could be decrypted within two, three, four years.”

The audience came to discover security. They went away with the wisdom of experience as distilled by Guldentops: “People will stay stupid. I mean it’s the same thing with DevOps; am I the only guy who’s scared giving software engineers control over infrastructure? I used to coin the phrase ‘it’s not DevOps, it’s DevFlops’. It’s scary. It’s a brave new world and we’ll have to learn to live with it.”

The full transcript of this session is available now.

To Top