Whose Responsibility is it Anyway?

Dana Windsor

Christchurch Hacker Conference 2025 · Main Stage

Overview

In an era of rapidly expanding cloud adoption and complex supply chains, the question of cybersecurity responsibility has become increasingly muddled. Dana Windsor, a Senior Security Consultant at Bastion Security, tackles this critical issue head-on in her CHCon talk, "Whose Responsibility is it Anyway?". The presentation dissects the pervasive problem of organizations deflecting security ownership, whether by assuming enterprise controls are sufficient, outsourcing to third parties, or relying on cloud providers, often with devastating consequences.

Watch on YouTube

Visual summary for Whose Responsibility is it Anyway? by Dana Windsor
Visual summary for Whose Responsibility is it Anyway? by Dana Windsor

Key moments

  1. 0:00 Common excuses for security responsibility
  2. 2:09 Defining 'Whose Responsibility Is It Anyway?'
  3. 4:54 Third-party risk: differing security standards
  4. 6:17 Quantas breach: real-world third-party consequences
  5. 10:50 Conflicting shared responsibility models
  6. 17:34 Mitigating gaps: due diligence and risk assessments
  7. 26:12 Conclusion: 'You are responsible' for security

Whose Responsibility is it Anyway?

Speakers: Dana Windsor, Senior Security Consultant, Bastion Security

Conference: CHCon

YouTube: https://www.youtube.com/watch?v=dCMeXrkOa60

Overview

In an era of rapidly expanding cloud adoption and complex supply chains, the question of cybersecurity responsibility has become increasingly muddled. Dana Windsor, a Senior Security Consultant at Bastion Security, tackles this critical issue head-on in her CHCon talk, "Whose Responsibility is it Anyway?". The presentation dissects the pervasive problem of organizations deflecting security ownership, whether by assuming enterprise controls are sufficient, outsourcing to third parties, or relying on cloud providers, often with devastating consequences.

Windsor highlights that while technological landscapes have transformed dramatically over the past two decades, the excuses for security lapses have remained eerily consistent. This talk serves as a stark reminder that regardless of who manages the infrastructure or platform, the ultimate accountability for information security — its confidentiality, integrity, and availability — rests with the organization that owns the data. She meticulously demonstrates how this confusion leads to critical security gaps, increased breach incidents, and severe reputational and financial damage.

The core message underscores that in today's interconnected digital environment, every organization must understand the full picture of its information's journey, who manages what, and where vulnerabilities might arise. Windsor emphasizes that these aren't merely theoretical concerns; real-world breaches, such as those affecting Quantas and Collins Aerospace, vividly illustrate the tangible and long-lasting impact of neglecting this fundamental question of responsibility. The article delves into the intricacies of shared responsibility models, internal organizational challenges, and actionable strategies for mitigation.

Background

▶ Watch: Common excuses for security responsibility (0:00)

The pervasive issue of unclear security responsibility is not new, yet its implications have grown exponentially with technological advancements. Windsor opens by lamenting that the excuses for security shortcomings—"It's an enterprise control," "We outsource that," "It's handled in the cloud," "It's compliant"—are precisely the same ones heard 16 years ago, as evidenced by a 2009 KiwiCom poster. The critical difference today is the widespread adoption of public cloud environments and the increasing reliance on third-party service providers, making these historical deflections far more perilous. Tech giants like Microsoft and AWS now have a global presence, further complicating the landscape of responsibility.

The fundamental premise Windsor establishes is that an organization is only as secure as its weakest link, which frequently turns out to be a third party. When an organization consumes a service, platform, or infrastructure from an external provider, it effectively becomes an extension of their own boundaries, inherently inheriting the associated risks. A stark example provided is the disparity in minimum cryptographic standards between New Zealand and Australia; while both require Advanced Encryption Standard (AES), Australia's minimum for non-classified data (112 bits) and top-secret data (192 bits) falls short of New Zealand's 256-bit minimum, and they plan to support these lower standards until 2030. Such differences underscore the need for organizations to ensure third-party security aligns with their own minimums or implement compensating controls.

The consequences of this abdication of responsibility are severe and far-reaching. Windsor cites the Quantas breach as a prime example, where a third-party supplier's compromise led to the exposure of Quantas customer data (phone numbers, email addresses, residential addresses, dates of birth, gender). Despite Quantas not managing the breached platform directly, their name and reputation were in the firing line. News reports often referred only to a "third-party supplier," shielding the actual culprit but vilifying Quantas. This initial breach subsequently enabled phishing campaigns, demonstrating how one incident can cascade into many more. Similarly, the Collins Aerospace Muse software attack, a cloud-based platform for electronic check-ins, caused widespread disruption at major airports like Heathrow, Brussels, and Berlin, highlighting the operational impact of third-party vulnerabilities.

Statistics from the Cordia cyber report further underscore the gravity of the situation: 19% of businesses experienced a cyber attack or incident through a third party, making it the fourth most common attack vector. Moreover, 35% of respondents perceive third-party attacks as the biggest threat to their cybersecurity posture. The report also reveals the long-term impact of such breaches, with 33% taking 2-4 months to resolve and an additional 12% taking 5 months or longer. The Quantas data, for instance, was still circulating on the black market four months after the initial incident. This widespread impact is not limited to a single organization; Windsor notes that the same third-party breach affecting Quantas also impacted around 40 other major global organizations, including Toyota, Disney, IKEA, and McDonald's, all at the mercy of one external provider. These events collectively demonstrate that responsibility and risk, whether internal or external, cannot be taken lightly.

Key Findings

▶ Watch: Third-party risk: differing security standards (4:54)

Dana Windsor’s talk unveils several critical findings regarding cybersecurity responsibility in modern organizations:

  • Pervasive Responsibility Confusion: There is widespread confusion, both internally and externally, about who is responsible for specific security controls and tasks. This ambiguity is exacerbated by outsourcing, cloud adoption, and organizational changes like redundancies.
  • Inconsistent Shared Responsibility Models: Major cloud providers like Microsoft, Google, and AWS offer fundamentally different interpretations of their shared responsibility models. These inconsistencies create significant gaps and uncertainties when organizations use multiple providers or integrate various services, leading to potential vulnerabilities.
  • The Client Bears Ultimate Consequence: Regardless of where a breach originates in the supply chain or which team is technically "responsible," the client organization (the data owner) ultimately suffers the reputational damage, financial losses, and legal repercussions. The public and media will always vilify the organization whose data was compromised, not necessarily the third party.
  • Enterprise Control Deflection: Project teams often attempt to descoping or ignore enterprise controls (e.g., documentation, security training, personnel screening) under the assumption that these are managed at a higher, organizational level. This practice elevates project-level risks and undermines overall security posture.
  • Supply Chain Depth is Critical: Organizations frequently overlook the security posture of their third parties' own third parties. A compromise "twice removed" in the supply chain can still directly impact the primary organization, creating extensive and non-obvious attack paths.
  • Smaller Third Parties as Easier Targets: Attackers often target smaller, less-resourced third-party providers as a "weakest link" to gain access to larger, more secure intended targets. This strategy offers a better "bang for their buck" for malicious actors.
  • Risk Management vs. Risk Ownership: While third parties can assist in managing risk, the ultimate ownership and acceptance of risk always resides within the client organization. This responsibility must be clearly assigned, often to product owners, project managers, or C-level executives, beyond just the CISO or CIO.
  • Resilience Over Prevention: Given the impossibility of 100% prevention (e.g., zero-day vulnerabilities like those recently seen in F5 and Cisco products), organizations must shift their focus towards building robust resiliency and effective response capabilities.
  • "You" Are Responsible (with a caveat): The core finding is that each individual and organization is responsible for security. However, this is tempered by a collective responsibility to each other within the ecosystem to ensure overall security and protect shared information.

Technical Deep Dive

▶ Watch: Quantas breach: real-world third-party consequences (6:17)

The technical core of Windsor's talk revolves around the inherent complexities and discrepancies within shared responsibility models, the systemic weaknesses introduced by enterprise control neglect, and the critical need to understand supply chain depth.

A significant portion of the deep dive focuses on the shared responsibility model, a framework designed to delineate security and compliance duties between cloud service providers (CSPs) and their customers. Windsor illustrates the models from three major players: Microsoft, Google, and AWS.

  • Microsoft's model often shows joint responsibilities in areas like network controls (e.g., firewalls) under the Platform as a Service (PaaS) model. While Microsoft may provide the base firewall service, the customer is responsible for configuring specific rules, alerting mechanisms, and responses, emphasizing that default settings are rarely sufficient.
  • Google's model presents subtle but crucial differences. For instance, in both PaaS and Infrastructure as a Service (IaaS), the network is often the sole responsibility of the CSP, but network security might be split depending on the service model. This distinction can cause confusion, as "network" and "network security" are often conflated.
  • AWS's model is described as "completely different again," further compounding the challenge.

The critical takeaway is that these three major organizations, whose services are frequently used in combination (e.g., an AWS platform integrated with Microsoft Intra ID), present disparate responsibility matrices. This lack of standardization leads to genuine confusion, blurred lines, and the introduction of vulnerabilities as assumptions are carried across different vendor environments. Smaller service providers further muddy the waters with their own interpretations.

Beyond external cloud providers, Windsor delves into internal responsibility gaps, particularly concerning enterprise controls. She highlights a common frustration: project teams often descoping or removing references to enterprise controls from their project audits. These controls, such as up-to-date documentation, finalized management approvals, regular enterprise security training, or personnel screening, are assumed to be handled at a higher organizational level. However, Windsor argues that while project teams may not directly remediate these, they must have the influence to escalate findings up the chain. Neglecting these enterprise-level deficiencies contributes significantly to an elevated overall security risk for individual projects and the organization as a whole.

The talk also explores the concept of supply chain depth. Organizations conducting due diligence typically assess their direct third-party providers. However, Windsor stresses the need to go "one step further": "What about the other third parties that your third party is using to run their business?" A breach affecting a provider "twice removed" from the primary organization can still have direct and severe consequences, creating a complex web of interconnected risks that often goes unaddressed.

A significant development highlighted is the New Zealand Information Sharing Standard, effective July 1, 2025. This standard mandates minimum guidelines for all New Zealand government agencies and non-government entities handling government-held personal information. Its three key principles directly align with Windsor's discussion:

  1. Agencies must have assurance that personal information is adequately protected.
  2. All parties must be aware of and understand their responsibilities.
  3. The agency is clearly accountable for the personal information it holds at all times, even when stored or hosted by another provider. This legal framework explicitly reinforces the idea that ultimate accountability never leaves the data owner.

Finally, Windsor touches upon the strategic targeting of the "weakest link." Malicious actors may not target a large, well-defended organization directly but instead compromise a smaller, less-resourced third party that provides services to many global organizations. This approach yields a "better bang for their buck" and can cause widespread disruption, as seen in the Quantas and Collins Aerospace breaches. She concludes by distinguishing between risk management (which third parties can help with) and risk ownership (which always resides with the client organization), emphasizing that while 100% prevention is impossible due to zero-day vulnerabilities (e.g., recent F5 and Cisco incidents), focusing on resiliency and response is paramount.

Demo / Proof of Concept

▶ Watch: Mitigating gaps: due diligence and risk assessments (17:34)

This talk did not include a live demonstration or a proof of concept. Instead, Dana Windsor focused on presenting real-world examples, statistical data, and conceptual frameworks to illustrate the critical issues surrounding cybersecurity responsibility and its implications in modern organizations. The emphasis was on analytical discussion rather than a technical demonstration.

Defensive Implications

▶ Watch: Conclusion: 'You are responsible' for security (26:12)

Understanding whose responsibility it is, and actively managing that responsibility, is paramount for any organization. Windsor outlines several critical defensive implications and strategies:

  1. Rigorous Due Diligence: The procurement stage is a critical juncture. Organizations must conduct thorough due diligence to ensure that a third party's security requirements align with their own business objectives and compliance requirements (e.g., NZISM, PSR in New Zealand). Treating a third party as an extension of one's own organization necessitates the same level of scrutiny applied to internal personnel screening or skill assessments.
  2. Establish Clear Functional and Non-Functional Requirements: To eliminate confusion, organizations must define and share explicit functional and non-functional requirements with all service providers and relevant internal teams. This provides a baseline for all parties, ensuring operational and security adequacy aligns with the organization's risk appetite and expectations.
  3. Comprehensive Third-Party Risk Assessments: Beyond initial due diligence, ongoing third-party risk assessments are essential. These assessments should evaluate the full extent of potential risks and existing mitigations. Crucially, this must extend to the entire supply chain, asking "what about the other third parties that your third party is using?" Organizations need to understand their exposure to incidents affecting providers "twice removed." Based on these assessments, decisions can be made to accept risk, implement compensating controls, or seek alternative providers.
  4. Proactive Engagement with Shared Responsibility Models: Do not make assumptions about cloud provider responsibilities. Organizations must actively understand and clarify the specific delineations in each shared responsibility model they encounter (Microsoft, Google, AWS, etc.), especially when using a multi-cloud or hybrid environment. This proactive clarification helps identify and close potential gaps that arise from differing interpretations.
  5. Empower Project Teams to Drive Enterprise Compliance: Project teams should not fear or descoping findings related to enterprise controls. Instead, they should be empowered to use these findings to advocate for improved compliance at the enterprise level. Their insights provide crucial pressure from the "bottom-up" to strengthen organizational security for the benefit of all projects.
  6. Maintain Continuous Vigilance and "Guard Up": Given that attackers may target the weakest link in the supply chain, organizations must maintain their "guard up at all times at their boundaries." This means constant monitoring, threat intelligence, and preparedness for incidents that may not originate directly within their managed infrastructure.
  7. Embrace "Trust But Verify": While trust is necessary in partnerships, it must be accompanied by verification. Organizations should not blindly rely on a third party's assurances but actively verify their security posture through audits, assessments, and contractual agreements. Engaging security consultants can provide an independent verification layer, helping to highlight deficiencies and improve overall security.
  8. Prioritize Resiliency and Response Over Prevention: Acknowledging the inevitability of breaches (especially from zero-day vulnerabilities), organizations must shift focus from an unattainable 100% prevention to building robust resiliency and incident response capabilities. This includes defining business continuity plans, recovery strategies, and clear communication protocols for when incidents occur.
  9. Assign Clear Risk Ownership: Explicitly define who within the organization owns and accepts risk. This responsibility extends beyond security teams to product owners, project managers, and C-level executives, ensuring that someone with authority is aware of the full security picture and accountable for strategic risk decisions.

Key Takeaways

  • Ultimate Accountability Rests with the Data Owner: Even when services, platforms, or infrastructure are outsourced, the organization that owns the data remains ultimately responsible and accountable for its security, confidentiality, integrity, and availability.
  • Shared Responsibility Models Are Inconsistent: Major cloud providers' shared responsibility models differ significantly, leading to confusion and potential security gaps when organizations operate in multi-cloud or hybrid environments. Thorough clarification is essential.
  • Third Parties are a Primary Attack Vector: Third-party suppliers often represent the "weakest link" in an organization's security posture, making them attractive targets for attackers seeking to compromise larger, well-defended entities. Breaches through third parties can have long-lasting and severe reputational and financial consequences.
  • Proactive Due Diligence and Risk Management are Crucial: Implementing rigorous due diligence during procurement, establishing clear functional and non-functional requirements, and conducting comprehensive third-party risk assessments (including the deep supply chain) are fundamental to mitigating external risks.
  • Internal Responsibility Gaps are Equally Critical: Neglecting enterprise-level security controls or allowing project teams to descoping them creates systemic vulnerabilities. Project teams must be empowered to identify and escalate these issues to drive organizational-wide security improvements.
  • Focus on Resiliency and Verification: Given that 100% prevention is impossible (due to zero-day exploits), organizations must prioritize building robust resiliency and incident response capabilities. Furthermore, trust in third parties must always be accompanied by verification of their security posture.

About the Speaker(s)

Dana Windsor is a Senior Security Consultant at Bastion Security. With extensive experience in the field, she specializes in helping organizations understand and navigate the complexities of cybersecurity, particularly concerning responsibility, risk management, and compliance. Her work involves conducting audits and providing guidance to clients, emphasizing the importance of understanding the full security picture, identifying gaps, and implementing effective mitigation strategies. Windsor's insights are informed by a deep awareness of both historical security challenges and the rapidly evolving technological landscape, advocating for a proactive and holistic approach to security across internal teams and external partnerships. She also previously delivered a talk on online scams, demonstrating her broad expertise in cybersecurity threats.

Reviews

Dr. Zero (Offensive Security Researcher) — SOLID

A well-structured awareness talk on third-party risk and shared responsibility models that competently covers ground most security practitioners should already know. Good regional context with NZ/AU policy specifics, but nothing here that experienced attendees haven't heard at every GRC-flavored conference since 2015.

Heather Calloway (CISO) — SOLID

Competent treatment of third-party risk and shared responsibility confusion, but the material is table stakes for anyone who's run a vendor risk program. Useful for practitioners earlier in their careers; unlikely to move the needle for seasoned leaders.

→ Top-rated talks at Christchurch Hacker Conference 2025

All talks from Christchurch Hacker Conference 2025