Several times lately, CIOs and CISOs have asked me why the security toolset they get for “free” from their cloud service providers isn’t enough. Sure, it might not be the best … but isn’t it good enough for the program’s success?
It’s true that we don’t often need the Cadillac. But cloud programs are failing at high rates, and the number-one listed reason is security challenges. Teams are trying to use that SaaS or IaaS/PaaS cloud service provider-native security and finding after initial designs that it’s full of holes, or that it’s very difficult to operate across the enterprise. And trying to bolt on additional security to highly automated cloud deployments is not nearly as easy as it was in steadier-state traditional data center configurations. We as solution engineers are failing our development, business and security teams by not addressing the number-one factor in cloud transformation failure with tools that will better support their success in delivering secure cloud implementations.
The CSPs and enterprise software providers just aren’t considering full architectural requirements for security, at a time when architecture overall—and security architecture in particular—is more important than ever. And they don’t have that perspective: Operating a complete end-to-end security architecture and program isn’t the perspective of these software companies’ product teams. Enterprise security is still needed, but new perspectives, more flexibility and support for automated architectures are also needed. Cloud deployments move so fast that we get to the point of “hard to add budget and redesign for efficiency” faster than ever before. We’re asking our development teams to walk a high wire, creating new technologies that enable business using new cloud technologies … but we’re assuming that those new cloud technologies are coming with their own security safety nets. And the market experience is that they don’t.
A better approach is to ENSURE a practical, agile security architecture starting with Cloud Access Security Broker (CASB) basics in place as a foundation of any major cloud transformation program. This gives us detective—and quickly available preventative—controls to ensure that while valuable risks are taken by our development and business teams who build fast in SaaS or IaaS/PaaS cloud, we are protecting them and the enterprise from egregious configuration errors and other easy mistakes up on that high wire.
When I’m developing services, I want to work with market-proven tools—they create an environment for my success.
What do you think? Are SaaS or IaaS/PaaS “built-in” security controls sufficient, or is a considered enterprise security architecture still necessary? Should we design that security architecture as base to programs or after giving CSPs’ own controls a chance to fail? Always interested in your feedback.
Next month, we’ll look at the highest-priority components of a complete cloud security architecture.
The post Is Cloud Service Provider-Native Security ‘Good Enough’ For Your Cloud Transformation Program’s Goals? appeared first on McAfee Blogs.