When your lines of business pick their own public cloud platform for the task at hand, it’s not always clear who’s responsible for security.
FireMon’s 2019 State of Hybrid Cloud Security survey found nearly 30 percent of respondents use the cloud for Software-as-a-Service (SaaS), while use of Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) are both a close second with just over 26 percent. Overall, 39 percent of respondents said they’re using all three “as-a-Service” models.
These adoption rates show respondents are comfortable putting more workloads in the public cloud and sharing responsibility for security. This is particularly true for the 23 percent of respondents who indicated they’re using IaaS and PaaS, where more responsibility for certain items such as applications and data falls on them rather than their public cloud provider.
But even as organizations get used to sharing security responsibility for the cloud, comprehensive visibility into what needs to be secured is essential. In addition, different cloud providers delivering the same type of application or service may have a different model for sharing security responsibility.
Digital transformation drives shared security responsibility
The adoption of multi-cloud is driven by digital transformation efforts. It’s what I like to call “cloud for strategies,” as companies let business objectives guide their cloud choices. But it does muddy the waters because you must be clear on who’s responsible for security.
Shared security responsibility models differ for each cloud platform even if the application or service is similar. You might pick Microsoft Azure as your preferred PaaS, while I might go with Amazon Web Service (AWS). You must understand what part of security you’re responsible for and what Microsoft provides within that infrastructure, while my responsibilities may be different because I chose AWS.
The types of applications and services you deploy can influence how security responsibility is defined internally—elastic storage versus a CRM suite. Right now, it’s still a little like the Wild West. Traditional IT security teams take care of physical firewalls and must work with infrastructure and networking teams, but adding just one public cloud provider, let alone multiple providers, adds a new group of people to the mix. For example, the marketing department may spin up a cloud service workload instance without fully understanding the organization’s responsibility for securing that workload. They may fail to enlist IT because they assume security is up to the public cloud provider. There may not even be a precedent set at the company for who should take ownership for the security controls around the applications that are being deployed in the cloud.
This shared responsibility is also present within the organization. Many large organizations I talk to said they’ve had to rework their DevOps processes so they can honor the speed of business demands. Shared security responsibility is the outcome of this accelerated pace. As a security professional, you can’t simply say “no” to a line of business; they’ll just go around you. These users view security as a barrier, not an enabler, spinning up cloud instances and configuring security (or not) themselves. These “as-a-service” deployments can add up quickly along with ad-hoc security policies and temporary firewall rules that outstay their welcome.
Meanwhile, new cloud security teams are forming separate from traditional on-premise IT security staff. Best case scenario, these siloed groups all assume everyone is taking responsibility for their share of security because they’ve deployed it.
And that’s the problem. Different parts of the organization are sharing responsibility for security along with multiple cloud platform providers, but it’s in a haphazard way. There’s no unity, and that means when something goes wrong, there’s going to be a lot of finger pointing.
One policy to rule them all?
Because we have different parts of the business engaging with different public clouds that confuse who’s responsible for security, we’ve moved away from having a central security policy everyone supports.
It used to be clearly laid out for the entire organization. It might have been called the “security policy,” “standard operating procedures,” or “application port guidelines,” but it always boiled down to someone, or a core group, articulating all the acceptable scenarios for the business with a process in place to make changes.
Obviously, this took time. But because a cloud instance can be enabled so quickly, the speed of business has people circumventing these security policies—they’re rolling their own, so to speak, without any guiding principle or a security rule book to govern these ad-hoc configurations.
Shared security responsibility needs complete visibility
Some organizations are handling shared security responsibility better than others by trying to align some of their best practices and policies as various groups spin up their own cloud instances from different providers. The formation of cloud security teams is an excellent example, while DevOps teams are weaving security into application development.
While there are nuances between different public cloud providers and their respective shared security models, what matters most is there’s a unified rallying point of cloud deployments in general. Ultimately, shared security responsibility isn’t good or bad, but it must be governed by a global security policy. We must clearly define what we can and can’t do. Governance must also be supported with a collaborative platform where all stakeholders can orchestrate policy that aligns with business, compliance, and security intent.
Most of all, this consensual security policy must be technically enforceable. That requires complete visibility because it’s hard—even impossible—to secure what you can’t see or manage what you don’t know. Returning to a global policy means having complete visibility so you know it’s being honored, even if security responsibility is shared.
Special thanks to Director of Product Marketing, Elisa Lippincott, for contributing to this post.