Consider a finance employee who receives a convincing email requesting a supplier’s new bank details. The message arrives through a reputable cloud email service. The platform is available, its infrastructure is protected, and the employee’s account requires multifactor authentication. Yet the payment can still go to a criminal if nobody independently verifies the change.
That scenario illustrates the central challenge of shared security: a secure service does not automatically create a secure business process. Providers, customers, managed service partners, and business teams each control different pieces. Effective protection depends on making those boundaries explicit—and testing what happens between them.
What Does “Fraud19” Mean?
The “Fraud19” identifier appears to be event-related, associated with AGA’s 2019 Internal Control & Fraud Prevention Training, rather than the name of a security framework. Bart McDonough’s speaking page separately lists “Shared Security Model” and “Fraud19 Keynote.” Those listings do not establish the content of the unavailable article or presentation.
This newly written guide addresses the shared-security topic associated with that identifier. Its cloud-security focus is an editorial interpretation of the title and cybersecurity context—not a reconstruction of the original presentation.
Understand Where the Provider’s Responsibility Ends
The cloud industry generally calls this division the shared responsibility model. Providers secure the infrastructure and service layers they operate; customers secure the identities, data, configurations, and workloads they control. The boundary changes with the service.
Microsoft’s responsibility guidance explains the distinctions:
- Infrastructure as a service: The provider operates physical infrastructure and virtualization. Customers generally manage guest operating systems, applications, data, identities, and configurable network controls.
- Platform as a service: The provider also operates managed platform layers. Customers retain responsibility for their code, application configuration, data, identities, and applicable access settings.
- Software as a service: The provider operates the supplied application. Customers still manage users, permissions, tenant settings, data governance, and their endpoints.
These categories are starting points, not substitutes for service documentation. Under AWS’s model, customers patch the guest operating system on an EC2 instance. With S3, AWS operates the underlying platform, while customers manage their data and permissions. Saying “AWS handles security” obscures that difference.
Turn Shared Responsibilities into Named Owners
A responsibility diagram explains the arrangement. A responsibility register makes it operational.
For each critical service, document the control, internal accountable owner, operator, required evidence, and escalation route. The accountable owner and operator may be different people or organizations.
- Access: A business owner approves permissions; an identity team implements them; access reviews demonstrate oversight.
- Patching: An application owner sets priorities; IT or a contracted provider performs updates; reports show unresolved exceptions.
- Monitoring: A security owner defines coverage; a monitoring team investigates; tested alerts demonstrate response.
- Payment changes: Finance owns the process; accounts payable executes it; verification records document approval.
Adapt these assignments to your organization. NIST’s Cybersecurity Framework guidance emphasizes governance, defined responsibilities, and supply-chain risk management.
If a managed service provider participates, establish whether its contract covers configuration, monitoring, investigation, or containment. Confirm after-hours coverage and who may authorize disruptive action. “Managed security” is not a precise scope of work.
For every critical control, identify who owns it, how its operation is verified, and who acts when it fails.
Verify the Controls That Commonly Fall Between Teams
Identity and Access
Start with people who can administer services, export sensitive information, change payment details, or grant access. Remove unnecessary privileges and promptly revoke access when roles change or employment ends. Review service accounts and integrations as well as human users.
Require MFA, prioritizing privileged access and sensitive workflows. CISA recommends phishing-resistant MFA, including FIDO/WebAuthn-based methods. Number matching can improve push-based authentication while stronger methods are deployed.
Tradeoff: Stronger authentication requires enrollment, support, and secure recovery procedures. A weak help-desk reset process can undermine a strong login control. Plan both together.
Configuration and Data Exposure
Security defaults help, but they do not prove that an existing environment is safe. Review effective permissions, external sharing, public access, and administrator settings.
For example, AWS blocks public access for new S3 buckets by default and recommends enabling all four Block Public Access settings at the account level. Its S3 guidance explains how organization, account, bucket, and access-point restrictions interact.
Tradeoff: Tightening access can break legitimate applications, including some static-website configurations. Identify genuine public-access requirements, test changes, and document exceptions rather than applying restrictions blindly.
Logging and Investigation
A logging feature is not the same as an investigation-ready record. Ask the operator to demonstrate which events are collected, where they are retained, who can alter logging, and who investigates alerts.
AWS CloudTrail Event history provides the preceding 90 days of management events in an AWS Region. It does not display data events. Longer-term records require a trail or event data store, and data-event collection must be configured explicitly.
For a sensitive document repository, test whether investigators can establish who accessed or downloaded a file—not merely who changed its configuration.
Tradeoff: Additional collection and retention can increase costs. Prioritize evidence that supports your likely investigations, protect that evidence, and account for privacy obligations.
Backup and Recovery
Service availability and data recovery are different questions. Determine what is backed up, who controls recovery credentials, and whether a compromised administrator could damage both production data and its recovery copies.
CISA’s ransomware guidance recommends offline, encrypted backups of critical data and regular testing of their availability and integrity.
Restore a representative critical workload and record the outcome. Include dependencies, configuration, and credentials—not just files.
Tradeoff: Isolation and restore testing require storage, time, and coordination. Prioritize services whose loss would most seriously disrupt operations. A successful backup job is not proof of successful recovery.
Connect Cloud Security to Fraud Prevention
Return to the supplier-payment example. Email filtering may catch the message. MFA may prevent an account takeover. Logging may support an investigation. None of those controls establishes whether new bank instructions are legitimate.
The FBI’s business email compromise guidance recommends independently verifying payment requests and changes to account numbers or payment procedures. Use a trusted contact method, not contact details supplied in the suspicious message.
A practical finance workflow should:
- Verify changed instructions with a known contact using previously established details.
- Separate requesting or entering a change from approving it.
- Record the verification and approval before releasing payment.
- Define how urgent exceptions are reviewed rather than letting urgency bypass controls.
A familiar sender, realistic voice, or plausible document is not independent verification. The business owner must define legitimate authorization; the technology team must protect the systems supporting it.
If a fraudulent transfer occurs, contact the financial institution immediately and report it to the FBI’s Internet Crime Complaint Center. Do not wait for the technical investigation to finish.
Test the Handoffs Before an Incident
Run a tabletop exercise involving IT, security, finance, leadership, and relevant providers. Use a hypothetical compromised mailbox followed by a payment-instruction change.
Test who disables access, preserves evidence, contacts the bank, assesses notification obligations, and coordinates with providers. Confirm that emergency contacts and decision-makers are reachable outside business hours.
The UK National Cyber Security Centre describes cloud security as a shared responsibility within an outsourcing relationship. An exercise exposes whether that relationship works operationally—not just contractually.
A Practical Shared-Security Checklist
Use this checklist during onboarding, renewals, and periodic reviews:
- Identify critical services and their service-specific responsibility boundaries.
- Name an accountable internal owner and operator for each important control.
- Confirm provider and managed-service obligations in writing.
- Review privileged users, service accounts, offboarding, and MFA coverage.
- Verify effective permissions, external sharing, and public-access settings.
- Demonstrate logging coverage, retention, and alert handling.
- Complete a restore test and document recovery dependencies.
- Independently verify payment-instruction changes and record approvals.
- Test incident escalation, emergency contacts, and provider coordination.
- Assign owners and target dates to unresolved gaps.
Make Shared Security Measurable
Moving a system to the cloud changes who operates it. It does not eliminate the need to govern access, protect information, verify payments, or prepare for disruption.
Start with one critical service and one high-risk business workflow. Map responsibilities, request evidence, and test the handoffs. Then expand the process. Shared security succeeds when every important control has a named owner—and nobody has to discover during an incident that each party thought someone else was responsible.