More organizations are moving to the cloud to host and deliver applications every year as the newness of Internet-based platforms wears off. But an expert says IT departments have to shed old ideas about security and adopt new designs and principles.
If they don’t, Mike Rothman, a consultant with Securosis and co-founder of a cloud management software startup, warned the SecTor security conference in Toronto on Wednesday, they’ll have a lot of trouble.
”If you can’t make this transition to start thinking about things from a cloud-first perspective, it doesn’t get easier,” he said.
Unlike the internal data centre model, in the cloud IT doesn’t control a data centre, he said. In fact, Rothman noted, all you have is code: The cloud is merely an interface you connect to.
Impatient organizations want to merely lift workloads directly to the cloud, including their architectures. Big mistake, he said, particularly if flat networks are used on-prem.
Flat networks in the cloud, he pointed out, makes it easy for an attacker to get at everything.
So dump flat architectures.
“Segmentation is your friend; account segregation is a best practice,” he said. And segregation minimizes the attack surface, he added.
Another example: In a data centre there is no management plane, where application code is stored. There is in the cloud. If an attacker gets to the management plane, they get access to all applications and can wipe out the company. So protecting this plane is vital.
”The idea is when we’re moving to the cloud is to start thinking about how we do this using cloud-speak, not old stuff because it’s comfortable,” he said.“We have to start separating out what it is we used to do, versus what we need to do moving forward.”
The cloud also means working faster, Rothman said. Traditional organizations might to two software revisions a year. Some cloud-based companies – like Amazon AWS — can update code several times a week. “We’ve got velocity we haven’t seen” before.
“Cloud-native does not mean not legacy, he added. “It means you’re either building it from scratch, or re-architecting it without compromise.”
Not all workloads can be re-architected, he admitted. An organization shutting its data centre but stuck with an indispensable legacy application will have to find some “cloudy” work-arounds, including building a moat around the app.
Otherwise, cloud-native rules. That means recognizing that going to the cloud means isolation by default, leveraging architecture for security, prepare for extensive use of automation because infrastructure can be expanded and contracted and APIs will be used extensively to connect machines.
“Those that understand and can think about security from the developer mindset is absolutely critical,” he said. “The whole start-up mentality of fail fast is absolutely critical in security, because that’s what our developers and operations people are going to be doing. We have to be okay with that, too.
“Which, by the way, means we have to manage expectations – which we’ve been crappy at for a long time. We can’t secure everything, it’s moving too fast. We’re going to try to reduce the attack surface, we’re going to try to automate as much as we can so we can move as fast as we can, but there will be some failure in there.”
He also said DevOps – the art of developing applications with security in mind at every step for thorough testing before the release of code – is essential. “Architecture plus DevOps is cloud security.
The cloud opens up many opportunities, he said, such as taking advantage of automation and orchestration. Imagine creating ‘guardrails,’ which are best practices – security or operational– that can be enforced using automation. For example, an application that checks all the entitlements on your organization’s Amazon S3 storage buckets and automatically shuts off those open to the Internet. Automation could also be used to quarantine an infected server, he said, or cut off access keys that haven’t been used in 90 days.
Better than on-prem
In an interview Rothman said security in the cloud can be better than an on-premise environment
“if you do it right. If you try to apply a lot of your traditional security controls that worked in a mediocre fashion in your data centre, it’s not going to end well. But if you use best practices from the standpoint of account segregation, network segregation, building in tests to your deployment pipeline, thinking about security as just another type of code, and having immutable infrastructure so you’re not just logging into servers — you’re getting when they drift or when they change — you can build design patterns that are significantly more secure that we had in traditional data-centre land.”
Which is not the say it will be perfect. “If we want to talk about things that are eminently avoidable and are the result of poor operational processes, cloud is no different than traditional infrastructure. If you’re crappy at security in your own house, you’re going to be crappy at security in the cloud … If anything you have less of a net and you’re on a much higher tightrope (in the cloud) just due to the fact that with just one configuration error you can open up a bunch of data to everybody. But that’s not an inherent (problem with cloud) – you actually have to do something in Amazon to open up an S3 bucket” to the Internet.
“By default they’re not open to the world … that’s why we don’t focus only on architecture as a key security control but also make sure you have the proper automation in terms of guardrails and automation to ensure that a lot of those best practices aren’t violated either by people who don’t know better or people who make mistakes.”