Shared fate vs shared responsibility: What’s the difference and how can your business benefit?
When a cybersecurity incident implicates both a vendor and a customer, it’s not always clear where responsibility lies. While customers lack oversight on a tool’s underlying security, the provider lacks oversight on how securely the tool is being used.
Under the ‘shared responsibility model’, the division of roles seems fairly straightforward. Crowdstrike’s definition, for example, states that the cloud provider is responsible for monitoring threats to the cloud and its infrastructure, while customers are responsible for the protection of data and assets within the cloud environment.
Speaking to ITPro, Nick Godfrey, director of the office of the CISO at Google Cloud, says the answer is a new approach to responsibility in the public cloud landscape, the shared fate model.
Godfrey outlines how the shared responsibility model was developed to deal with the new territory cloud represented.
“As we shifted into the cloud, we needed to be able to draw a line to say, ‘What’s the customer responsible for?’ For example, the cloud provider would, in that model, be responsible for the physical environment, the data centers, and some of the physical networking and computing that underpin the cloud,” he explains.
“Conversely, the customer would be responsible for the identity and access management of who in their organization has access to their applications on top of the cloud. The complexity comes because the point of delineation varies depending on what type of cloud you’re using.”
The cloud ecosystem comprises a number of different technologies and depending on what the businesses have implemented, the responsibility of the cloud provider could reach deeper into the organization.
For example, Godfrey notes, software as a service (SaaS) solutions such as an HR portal used by employees are virtually always limited to managing identity and access data within that portal. In contrast, infrastructure as a service (IaaS) tools often burden the customer with far greater responsibility for securing that storage and maintaining the virtual network it runs on.
Godfrey argues new complications like these have exposed the limitations of the shared responsibility model, and that the framework assigning needs to evolve to reflect this growing complexity. Although helpful, the boundaries delineated under the shared responsibility model are too rigid, Godfrey claims, which can lead to security gaps.
Making the step from shared responsibility to shared fate
The distinction between shared fate and shared responsibility models centers around the extent to which the cloud provider works alongside the customer to understand how to configure and design their cloud. Godfrey tells ITPro that early definitions of shared responsibility saw documentation given to customers outlining best practices but that they were largely left to defend their cloud alone.
Shared fate, by contrast, is defined by an increased focus on working with the customer, alongside tailoring one’s cloud products so that they are easier for businesses to use out-of-the box.
Godfrey breaks down where he thinks shared fate can really help organizations into three core areas:
Collaboration on the entire environment
The first areas in which shared fate goes beyond shared responsibility in helping businesses hit the ground running with their cloud deployment. Shared fate can help businesses hit the ground running with their cloud deployment, as vendors develop partnerships with customers, says Godfrey.
At Google Cloud, Godfrey says he’s implemented a dedicated team of cloud professionals to work with their customers on the cloud transition. In any set of circumstances, it’s vital for service providers to reach out to the cyber leaders within their customer organizations to update legacy attitudes to fit modern cloud security.
Giving customers resources
Another aspect of a shared fate model is providing customers with frameworks, best practices, and resources.
This includes guidance on how they should think about identity, and how to secure specific types of workload in their cloud environment, Godfrey adds.
Changing default behaviors
Finally, Godfrey thinks cloud providers need to put in the work behind the scenes and change how they think about the default configurations of their products.
“If the fundamental job of a customer in securing the cloud is figuring out which configurations and architectures they need to have in order to be secure, then we can do a better job as an industry by making the default configurations for the products and services that they instantiate in their environment secure by default,” he says.
“This means ensuring that if there’s a security-critical feature or function, it should be on by default.”
Most of this work needs to be done before the customer even receives the product. This is another reason for cloud providers to work actively with each customer, to understand which default settings and configurations would be most useful for them based on their processes and workflows.
Debunking the myth that CISO and CTO are naturally opposed
Godfrey, a former CISO, thinks one aspect of a mature cloud strategy that goes overlooked is its ability to unify the aims of security executives and technology leaders, where there can often be friction. He adds that one of the megatrends Google Cloud has identified driving cloud adoption is its ability to transform security assurance in development pipelines .
“I think cloud is an interesting opportunity for totally debunking that myth, by having both those parties sit down and agree on a set of shared outcomes they’re looking for, a shared north star,” says Godfrey.
“Because if you think about it, every CIO would like agility, the ability to provide new technologies that will feed the business needs and so on, and in order to do that, they’re incentivized with cloud to build high-quality CI/CD pipelines, lots of automation, the ability to deploy very quickly, the ability to pull it back if it didn’t work. That’s exactly the environment the CTO wants,” Godfrey notes.
Through the right shared fate model and approach to the cloud, Godfrey adds, leaders can bake security into development pipelines from the outset.
“So we actually work quite closely with CIOs as well to say that, ‘you know, actually you want the same things’, and so I genuinely think you can massively enable innovation, agility, and improve security at the same time with the same approaches.”
Shared responsibility is creating confusion in cybersecurity
George Fitzmaurice
George Fitzmaurice is a staff writer at ITPro, ChannelPro, and CloudPro, with a particular interest in AI regulation, data legislation, and market development.
The shared responsibility model can be applied broadly across cybersecurity. Difficulties are created, however, when a cybersecurity incident affects both parties. If the use of a product leads to a breach or attack, then the product vendor will likely have to in some way address the issue.
Speaking at a media briefing for Proofpoint Protect London 2024, Proofpoint’s EVP of cybersecurity strategy Ryan Kalember outlined some of the complexity shared responsibility can create.
“So when everybody moved to cloud the first time and SaaS services became a thing it was ‘we’re responsible for the application layer and kind of the infrastructure underlying that,’… but there are all these things that you, as an end user of that, can configure, and you’re responsible for those,” Kalember says.
Within reason, any security product be poorly configured, Kalmeber adds, noting that’s created difficulties for Proofpoint in how it balances security and customer decision making.
“This is a complicated problem for us because, in this shared responsibility model, we’re not going to force our customers to change configurations around their trust of Microsoft,” Kalember explains, referring to a spam campaign involving Proofpoint and Microsoft in August.
In the spam campaign, a user configuration of Proofpoint’s platform was abused to relay emails via Microsoft 365 tenants.
“We don’t want this to happen, but we also can’t totally overhaul our customer’s configurations without consulting them and working with them,” Kalember said.
“We have to nudge them progressively more aggressively over time to just say, ‘Hey, we would really love you to not be doing this, because this is being bounced off of you from Microsoft and going to other people,’” he added.
How responsibility is divided then becomes a tricky problem to solve, as vendors are forced to question what role they play in managing the implementation of their tool, rather than just the security of the tool itself.
“If you let people set up what is effectively a giant data lake of very sensitive information, in most cases, behind a password and nothing more, what is your responsibility for that?” Kalember asks.
“That’s exactly the sort of question that we’re trying to struggle with,” he added. “We can even put it in the contract that ‘We don’t want you to do this,’ but we’re not going to go to the admin with a cattle prod and say, ‘You can’t do this’”
There are still options. Kalember said Proofpoint was having an internal discussion on how aggressive it should be in telling users they’ve made an unwise decision with their product and has considered making certain configurations “very hard to do”.
The latter option could come into play for Amazon S3 buckets, for example, which have have been notoriously left open to enable cyber attacks. Amazon now makes it very difficult for users to configure buckets in that way.
“We’re trying to adopt more of those principles when it comes to ways that our own products can be configured in a risky way,” he adds.
Source link
/cdn.vox-cdn.com/uploads/chorus_asset/file/25290333/STK255_Google_Gemini_C.jpg)
