Cloud Security Standards: Frameworks and Identity Specs

Key takeaways

• Frameworks and audit reports tell you whether a provider runs controls; protocols decide whether your integration with it is secure.
• Ask every SaaS vendor for SSO via SAML or OIDC and provisioning via SCIM; they are the controls you operate yourself.
• The shared responsibility model means identity configuration is almost always your side of the line.

When a security team reviews a cloud service, two very different kinds of "standard" end up on the table. One kind describes how the provider runs security: policies, audits, certifications. The other kind describes how systems talk to each other securely: protocols such as SAML, OpenID Connect and SCIM. Both matter, and mixing them up leads to checklists that miss the point.

Which frameworks describe a cloud provider's security?

ISO/IEC 27001 with its cloud extensions 27017 and 27018, the CSA Cloud Controls Matrix, SOC 2 reports and, for US government work, FedRAMP.

Read the scope sections carefully. A certificate that covers the provider's data centers but not the product you are buying does not tell you much.

Which technical standards should a cloud service support?

Single sign-on with SAML 2.0 or OpenID Connect, provisioning with SCIM 2.0, API access with OAuth 2.0, and modern TLS.

These are the controls you operate yourself, so they deserve as much weight as the audit report:

• SSO (SAML or OIDC) puts authentication, MFA and conditional access under your identity provider instead of a separate password database.
• SCIM means accounts are created and, more importantly, removed when people leave. See our provisioning guide.
• OAuth 2.0 for integrations, with scoped tokens instead of shared admin passwords.
• Audit log export, ideally streamed to your SIEM, covering sign-ins and admin changes.
• TLS 1.2 or 1.3 only, with HSTS on web interfaces. The Security Header Builder shows what a good header set looks like.

How does the shared responsibility model apply to identity?

The provider secures the platform; you are responsible for who has access and how they authenticate.

Whether you use infrastructure, platform or software as a service, identity configuration is on your side of the line. Misconfigured access, missing MFA, stale accounts and over-privileged API keys cause a large share of cloud incidents, and no provider certification covers them. Our article on extending IAM to the cloud walks through the practical steps.

What should a vendor security questionnaire ask about identity?

Ask how users authenticate, how accounts are provisioned and removed, how admin access is controlled and what gets logged.

1. Do you support SAML 2.0 or OpenID Connect SSO on all plans we would buy?
2. Can SSO be enforced, disabling local passwords?
3. Do you support SCIM 2.0 for users and groups, including deprovisioning?
4. How are your own staff's access to customer data controlled and logged?
5. Can we export sign-in and admin audit logs, and for how long are they kept?
6. Which OAuth scopes do your API integrations use, and can tokens be revoked?

Short answers to these six questions often tell you more about day-to-day risk than a long framework mapping.

Questions

Is a SOC 2 report the same as a certification?

No. SOC 2 is an attestation report by an independent auditor under AICPA criteria, describing controls and, in a Type 2 report, how they operated over a period. ISO/IEC 27001 is a certification of an information security management system.

What does the CSA Cloud Controls Matrix cover?

It is a control framework from the Cloud Security Alliance with control domains for cloud computing, including identity and access management, and mappings to other standards. Providers can publish self-assessments in the CSA STAR registry.

Sources

• Cloud Security Alliance: Cloud Controls Matrix
• ISO/IEC 27017: Information security controls for cloud services
• NIST SP 800-145: The NIST Definition of Cloud Computing

Tagged: Cloud, Cloud computing, SAML, SCIM, OAuth, Audit, Security