Eric Hibbard

ISO Wades in on Secure Multi-tenancy

Blog Post created by Eric Hibbard on Jul 3, 2013
The latest Committee Draft (CD) of ISO/IEC 27040, Information technology - Security techniques - Storage security has, for the first time within the standard world, taken a shot a defining and describing secure multi-tenancy. Before giving the details, a few definitions are in order:
  
data breach:  compromise of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to protected data transmitted, stored or otherwise processed
multi-tenancy:  allocation of physical and virtual resources such that multiple tenants and their computations and data are isolated from and inaccessible to one another  [SOURCE:  ISO/IEC 17788]
secure multi-tenancy:  type of multi-tenancy that employs security controls to explicitly guard against data breaches and provides validation of these controls for proper governance
  
As you can see from these definitions, secure multi-tenancy goes significantly beyond multi-tenancy. The focus on data breaches (a nasty definition in and of itself) and the calling out of explicit security mechanisms and capabilities (controls) to guard against breaches raises the bar; it is almost impossible for individual products to achieve it (think solutions). Further compounding the complexity is the requirement for validation and verification of the security controls, which means there's a way to check whether the security functionality is there, that it is enabled, and that it is functioning correctly.
To help people understand secure multi-tenancy, ISO/IEC 27040 states that one should approach it from the perspective of the tenants (including their system administrators). As such, a secure multi-tenant solution needs the capability to provide secure isolation while still delivering the management and flexibility benefits of shared resources that assures:
  • no tenant can determine the existence or identity of any other tenant
  • no tenant can access the data at rest (storage) of any other tenant
  • no tenant can perform an operation that affects an operation performed by another tenant
  • no tenant can perform an operation that might deny service to another tenant
  • each tenant can have a configuration that is independent of other tenant's existence and configuration (For example in naming or addressing.)
  • when a resource (compute, storage or network) is decommissioned from a tenant the resources should be sanitized of all data and configuration information
  • accountability and traceability measures are available at the tenant level

NOTE:   Secure multi-tenancy exists when the risk profile of an individual tenant is no greater than it would be in a dedicated, single-tenant environment.

Since 27040 is focused on storage security, it suggest that storage systems and infrastructure, used in part or in whole for secure multi-tenancy solutions, should use the following additional security measures:

  • Encrypted storage that is aligned with the tenants' usage of resources
  • Secure and rapid de-provisioning (media sanitization, including cryptographic erase)
  • Trusted third-party data storage management (e.g., SNMPv3, SMI-S with TLS, etc.)
  • Automated key management providing tenant-controlled key management (leverages KMIP v1.1 compliant servers)
  • Secure data replication(e.g., data in motion and at rest encryption)
  • Protect data from administrators (e.g., enforce a least privileges access model, administrators do not have access to the keying materials, etc.)
  • Highly available data fabrics (multi-path and diverse path)
  • Centralized and secure audit logging(e.g., syslog over TLS)
  • Validation and certification (e.g., Common Criteria) of cryptographic modules and other security measures (e.g., media sanitization, access control, etc.)
One of the quickest ways to determine whether a system or solution is potentially a secure multi-tenancy system or solution is to check to see how it integrates into the surrounding IT infrastructure. Specifically, each tenant should be able to use a completely different set of infrastructure. For example, syslog-based audit logging would use a different set of syslog servers for each tenant; likewise, each tenant could use a completely different Active Directory for authentication and authorization. If this is not the case, then the system or solutions is just multi-tenancy.
This characterization of secure multi-tenancy was designed to meet the expectations of security conscious organizations and the authors recognized that it would be extremely difficult to achieve. It does, however, improve the dialogue around multi-tenancy because vendors and solution providers can describe their efforts to achieve secure multi-tenancy.
What do you think about the characterization? Do you think anyone will be able to deliver such a solution?

Outcomes