3 Questions to Ask in Your Cloud Security Journey
In case you’ve been asleep for the past few years, you’ve undoubtedly begun moving a number of your IT functions to the cloud, along with their associated business processes. And why not? The many benefits of the cloud are now the equivalent of Supreme Court case law—long-settled and a fait accompli.
Most importantly for business leaders and technology stewards alike, I think we are now past the tipping point on cloud security. Whatever your cloud architecture—public, private or hybrid—physical security is handled by the cloud service providers, while you can focus on securing your data and applications. This shared-responsibility model for cloud security is a powerful and efficient approach.
Of course, that doesn’t mean our journeys to the cloud are always going to be smooth or without challenges. Nor does it mean that we should unthinkingly move everything to the cloud, or not worry about cloud security at all.
I experienced this firsthand several years ago, when I oversaw network and application security at my then-employer, a well-known and highly regarded global financial services firm. As our organization began its commitment to the cloud, I learned some valuable lessons about what to do and what not to do when it came to the cloud, and many of my most valuable lessons dealt with cloud security architecture and the then-unnamed concept of DevSecOps.
Many of my colleagues and peers around the world are making cloud a strategic, rather than tactical, part of their strategy. And, it’s not just about their IT strategy, either; cloud is now an integral part of overall business strategy. That makes it even more important to spot and avoid the potential mistakes many organizations make in their cloud projects.
Fortunately, we’re now far enough down the road with cloud adoption that we can share some tips on key, fundamental risks organizations face with the cloud. At very least, business and technical executives should ask themselves three questions:
- Why are we adopting cloud computing in the first place?
- What are we putting into the cloud?
- What will be our approach to cloud security?
Think Long Term
The first point—understanding why you are moving to the cloud—is, of course, where it all begins. (Or, at least where it should all begin.) Ever since I first became exposed to cloud computing back in 2009—yes, cloud does go back well over a decade—many organizations have failed to answer this most fundamental question.
In the era of Cloud 1.0, most organizations’ motivation in moving to the cloud was financial. Specifically, IT decision-makers liked the idea of using public cloud services as a way to counter tighter budgets, and CEOs and CFOs loved the idea of slicing up the Capex budget and adopting a more Opex-centric, subscription-based purchasing model for IT. But just like we learned 30 years ago from business consultant Michael Porter in his seminal works on sustainable competitive advantage, trimming costs is not a long-term strategy.
Business and IT leaders need to think longer and harder today about what they intend to accomplish in moving to the cloud, and to come up with the right strategies to achieve it and the right metrics to measure their progress. Whether it’s to improve organizational agility, roll out new IT services faster or make more strategic use of in-house personnel, organizations must develop a long-term game plan that clearly articulates and supports the various goals in moving to the cloud.
Do Some Experimentation
The second point, regarding what workloads, applications and business processes to move to the cloud, requires some experimentation, whether it’s around sandboxes, proofs of concepts or plain old trial and error. But again, since we have some really good cloud experience to draw upon, we can spot a few things that help us understand when something is better suited for the cloud—or when it makes more sense to leave it alone for now.
This is an area where a lot of mistakes are made, because it’s easy to fall into the trap of extrapolating benefits achieved from initial cloud projects to many more applications and workflows. “Hey, we saved $10 million in Capex last year and didn’t have to fill 10 open FTE slots when went to the cloud,” your CEO might say. “Imagine what we could do if we went all-in on cloud!”
Unfortunately, it doesn’t work like that. Some applications are tailor-made for migration to the cloud—in fact, others are literally built for the cloud from the ground up. These cloud-native applications are representative of this era of digital transformation, built around the notion of customer interactions over a simple web browser, or modeled on technologies such as virtualization or containers.
By contrast, microservices and application programming interface (API)-driven application stacks are great examples of technology built for the cloud. Because they are already lightweight and tend to have a smaller attack surface, integrating them into the cloud makes sense. Many cloud service provider security features are built around the concept of an API-based ecosystem or microservices-based workloads. End-user-based applications that rely on a browser or some sort of lightweight client also fit well into the cloud ecosystem.
Many organizations ideally would like to migrate enterprise workloads like SharePoint and Exchange to the cloud, but these applications typically require “heavy” endpoint systems with a lot of memory and dedicated disk storage, while others demand access to local, bandwidth-rich networks. For these and other enterprise applications, SaaS-based versions are available to take the infrastructure out of your hands and manage those workload environments.
And while some legacy applications can be massaged or reconfigured for the cloud, many times those applications are so enmeshed with rigid workflows or require hard-wired interaction with other applications that re-architecting them for the cloud may deliver more headaches than benefits.
Have a Security Strategy
Of course, the final area of potential risk—security—may be the single biggest issue for business and technologies to come to grips with, and to apply new ways of thinking.
As we adopt cloud-first applications and business processes, new risks emerge. Take the Internet of Things, for instance. This is a very exciting development in terms of business opportunity and the potential to create a better customer experience, and the cloud is a huge enabler of IoT for everything from the factory floor and the hospital bedside to the voting booth. But it also dramatically increases the attack surface, and you can’t just extend your on-premises network security protocols to a world of sensors, thin clients, containerized applications and software-defined data centers.
The cloud, however, has changed everything when it comes to security. The move to the cloud represents an important opportunity for all of us to dramatically rethink our security strategy. For instance, our long-standing approach to adding additional security tools to our IT operations has been built around the concept of “more.” We add more tools, from more vendors, applied to more processes and applications. And what has that left us with? A ton of technical debt to pay for, manage and update. That doesn’t begin to even cover the human cost.
As more applications, workflows and business processes become cloud-centric—or, increasingly, cloud-native—we can cast aside a lot of that technical debt. How? By starting with a more simplified view of security to match the “weight” of the application, process or endpoint.
We need to allow ourselves the freedom of not carrying forward all that legacy security baggage that complicated our on-premises deployments. We can re-imagine our applications so they don’t have overly complex dependencies that create data silos that much be managed with security point products, rather than with intelligent, automated and lightweight, agile platforms.
We also can take advantage of the fantastic array of native security tools cloud service providers offer, such as integrated vulnerability identification and management, secure connectivity and agentless management. This is consistent with trends such as mobility, where endpoints and operating systems carry much less overhead and can be crushed under the weight of traditional, on-premises-based security protocols. That leaves us with the opportunity to trim the list of third-party vendors and to be more selective about what we actually need and who we work with.
Of course, new risks and threats aimed at the public cloud mean that organizations need to take steps to bake in security from the onset. That means that new IT applications and services need to account for security before they go live; whether you call that SecDevOps, “shift left,” or avoiding the duct-taped security approaches, cloud security cannot be an afterthought.
Fortunately, most organizations are embracing the notion of security automation, such as artificial intelligence and machine learning, feeding into sophisticated analytics engines that give us real-time, hyper-accurate views of security events. Organizations need to cast aside their devotion to legacy firewalls, intrusion-detection tools, thick clients and dozens or more distinct security tools that we’ve long since paid for, and to embrace a new mindset when it comes to cloud security. Those tools and systems may still have value but moving to the cloud allows us to utilize them when and where it makes the most sense, such as when risks are not completely addressed by cloud service providers’ controls.
Bottom line: The days of complex security controls, multilayer security defenses and point products are on the decline. The cloud doesn’t just present some magical properties that build an impenetrable shield over your data, applications and services. It’s about reassessing your controls framework and implementing a new security protocol that emphasizes the data and access to it, not just the physical network boundaries.
Michael Morrato is Vice President of Security Services at Worldpay, a leading provider of secure payment processing.