The benefits of the internet and cloud computing have been tempered by the increase in security issues. We hear of security breaches on an almost daily basis, and attacks come in ever-increasing scale and sophistication.
While traditional IT systems and legacy applications were developed for a different security climate, shouldn’t the new breed of apps, developed with the cloud in mind, be better protected?
Are micro-service architectures inherently safer, or do they create more problems than they solve? Are traditional information security vendors able to help solve cloud-native problems, or is a completely new approach required? CRN spoke to companies building cloud-native services, security vendors and channel partners about what security looks like in a cloud-native world.
Cloud-first security
Australian cloud integration platform Maestrano tackled the cloud-native security problem head-on from the start. “We embedded security into the core of the platform from the very beginning,” says Stephane Ibos, co‑founder and chief executive.
“We feel quite strongly about it. Most security tools you find on the market only deal with the periphery.”
Instead, Maestrano takes an ‘assume breach’ position, where every system and service on the network is suspect until proven otherwise.
“We take a holistic view of the security of the platform,” adds Ibos.
Maestrano extensively uses micro-services and containers, and security is built in at the container level. “Each container has a security layer,” says Ibos.
The approach seems to work, as Ibos says Maestrano was able to observe an attacker breach the perimeter only to get nowhere.
“We had an attack, and our CTO was brave enough to simply observe them carefully,” says Ibos. “They tried to get further, but gave up when it was clearly too difficult.”
“'Build it then secure it’ is the old way,” he says. “Now, security should be built into the core.”
Complex composition
The basic ideas underpinning information security in the cloud era aren’t new: who needs access to what, when, where, and how? Where applications once tended to run on systems located in a single place in the mainframe and client-server eras, cloud-native applications are not tied to any one physical location.
The applications are accessed over a network, and while this is superficially similar to timeshare mainframe systems or thin-clients, one major difference is that the applications themselves are accessing other applications over networks.
“It’s now rare for an application to be entirely within one VM,” says Richard Cookes, country manager for ANZ at One Identity. "Cloud-native applications are made up of multiple, usually distributed parts, all communicating with each other over networks in a fluid and dynamic way.
"People are also more mobile now than in the past, and expect to be able to use their devices to access applications from anywhere. This isn’t limited to smartphone apps, and applies equally to laptop and desktop applications.
"Your corporate applications may need to be accessed by customers, business partners and suppliers, as well as your own internal staff. Most of them won’t be physically on-site, and will be coming in over external and untrusted networks."
Cookes notes that a monolithic, on-site application has one factor of authentication built in: you have to be authorised to be on that site. When all applications are accessed over a network, “we have to add the second factor back in, but using other methods,” he says.
For many applications, components are provided by separate companies that specialise in one area – performance monitoring, log collection, application tracing – and their physical location may not even be known.
There is no clearly defined perimeter. There is no ‘inside’ that can be assumed to be secure. Every request for data could be an attacker trying to break in.
Security is not a bolt-on
For cloud-native services, instead of building a castle with high walls to defend against external attackers, each micro‑service becomes a kind of mini-castle of its own. Every request for service is checked to see if it is authorised.
“I am a big fan of the Google BeyondCorp concept,” says Rohan Blake, cyber security product manager at Sydney-based systems integrator VMtech. Published in 2014, the Google research paper BeyondCorp: A New Approach to Enterprise Security talks about how Google was moving its corporate applications onto the internet, rather than having them hidden behind firewalls in an isolated network.
To do this, Google had to embrace the idea that any request for service could be malicious, and to design security into the way its applications worked from the very beginning. When everything starts life as a service to be accessed by external users, and not a back-end, hidden ‘air-gapped’ solution, it’s not possible to rely purely on old firewall-dependent techniques to keep them safe.
Cloud-native approaches are also vastly more dynamic and changeable. With dozens of releases each week – or every day – submitting a helpdesk ticket to have a new firewall ruleset burned simply doesn’t work. Tracking the hundreds, sometimes thousands, of access rules isn’t something humans can keep up with unassisted, and so cloud-native firms make extensive use of automation.
“Pre-DevOps, security barriers were kind of built in,” says Roy Adar, senior vice president of product management at CyberArk. “You’d have separation between production and development, and it was harder to move between them. The walls were higher.”
In cloud environments, things tend to be more highly integrated and automated, so gaining access to privileged systems can provide enormous control over large parts of the software supply chain. Once again, traditional approaches to security simply aren’t enough.
Taking security seriously
Changing an application from an old-style monolith to a cloud service and doing it securely is hard. “A lot of people treat going to cloud as a lift-and-shift,” says VMtech’s Blake. He suggests that this is the wrong way to think about using cloud services, and a more fundamental rethink is required.
One Identity’s Cookes agrees. “To do BeyondCorp requires a fundamentally different approach to security,” he says. “Cultural change is required for cloud security. Organisations need to ask themselves, ‘Do we really understand this?’ and be honest about the answer.”
There is plenty of evidence to suggest progress. Multi‑factor authentication is becoming more widespread, and standardisation, such as the Universal 2nd Factor (U2F) standard, has helped to make robust authentication methods more accessible to developers.
“In the past 12 months, security budgets have generally increased,” says John Negron, chief revenue officer at Tenable Network Security. “Ransomware attacks like Wannacry got a lot of attention.” Negron says that while CIOs were always able to get money for more hardware, budget processes are now including more items, such as security software and services.
“It is getting better,” says Roy Adar, senior vice president of product management at CyberArk. “People are becoming better educated about the issues.”
While there has been good progress, there’s still a long way to go for most organisations as they move to cloud.
“Here in Australia, I still get lots of blank stares if I mention a book like The Phoenix Project,” says VMtech’s Blake.
Security isn’t a new issue, but the new ways of creating applications in a cloud-native world require a new way of thinking about security. The rigid segmentation and control of the IT of old is no longer sufficient in a highly networked, mobile-centric world where people expect to be able to work from anywhere.
Moving to this new world requires a fundamental re‑think of how companies do security. Many of the existing vendor solutions aren’t suitable, or only solve a small part of the problem, and you’ll need new tools to solve the new problems created by the dynamic, changeable world of cloud-native.
The good news is that there are people out there who have done this successfully. The hard part is finding them, but when you do, pay close attention to what they have to say, and you could well save yourself a lot of pain.
-1.jpg&w=100&c=1&s=0)
.png&w=100&c=1&s=0)
