Cloud Key Management

  • 1.  Kind reminder of tomorrow's working group call!

    Posted Jan 23, 2023 08:45:00 AM
      |   view attached
    Dear members,

    This is a kind reminder for our Cloud Key Mgmt working group call scheduled for tomorrow, Tuesday, at 10:00 a.m. EST / 15:00 GMT.

    Survey results (starting from voted as most important):
    1. KM lifecycle Best Practices
    2. Best Practices when uploading on prem data to the cloud
    3. Guide on which KMS pattern to use
    4. "X"YOK comparison
    5. Multi-cloudKMS

    • Decide on first deliverable: KM Lifecycle Best Practices OR HSM as a service OR both?
    • Brainstorming on the structure of the 2 documents (KM Lifecycle and HSM-as-a-service)
    • Produce Table of Content
      To connect on the  call:
      Meeting ID: 936 1788 0747

      Warm regards,

      Marina Bregkou,
      Senior Research Analyst,

    • 2.  RE: Kind reminder of tomorrow's working group call!

      Posted Jan 23, 2023 10:29:00 AM
      Edited by Thanos Vrachnos Jan 23, 2023 10:29:51 AM
      Dear all,

      It is obvious from the survey that the "KM Lifecycle Best Practices" topic was rated first and how couldn't it, since I believe the majority of this WG also has the same perception. Since productive polyphony is expected from now on, I would like to post here some thoughts/concerns on the topics @Marina Bregkou mentioned in the beginning of this thread:

      A. Regarding KM Lifecycle Best Practices, it may be useful to follow the standard key management lifecycle as seen in bibliography (e.g. handbook of applied cryptography or NIST SP800-21) and based on each lifecycle stage, mention the related best practices. 

      Key States and Stages:
      1. pre-operational:
        • user initialization
        • key generation
      2. operational
        • key installation
        • key update
        • key backup
        • key recovery
        • normal key usage
      3. post-operational
        • revocation
        • archival
      4. obsolete/destroyed
        • key de-registration & destruction
      B. As to whether HSMaaS will be included or not, I would like to add that although it is not an approach that is used an extended period of time, it seems to gain more and more attention and preference. More cloud-native apps are born which are benefited from an HSMaaS model (when required to use such a technology) and almost every provider has now a form of HSMaaS, from major public cloud providers to HSM vendors who now offer the cloud version of their traditional HSMs. So, despite the fact that it is a "baby" topic in terms of maturity, I think it would be beneficial to offer a good guidance material on choosing HSMaaS, both for our audience who could be enlightened and of course for CSA itself, to be one of the first (if not the first), vendor-neutral organization to provide guidance on this emerging topic.​​
      In case we decide to include the HSMaaS topic, please find below some points regarding document structure:
      • State the need of HSMaaS, as observed by professionals (payment industry/fintech, PKI/webPKI, regulated industries enforcing encryption, applications born in cloud) and maybe present a market trend/expenditure forecast on HSMaaS by a recognized source
      • Brief description of what HSMaaS model is and to which cloud delivery models it relates (probably SaaS)
      • Responsibility matrix of the offering (provider vs consumer)
      • From a vendor-agnostic scope: substantial HSMaaS characteristics/features, levels of assurance (FIPS 140-2 Levels), types of customer isolation provided, communication protocols
      • Should we describe in a non-marketing approach, the currently available HSMaaS offerings, at least those provided by A*S, Az***e, G*P? Some of them provide a set of HSMaaS variations with different characteristics while others have one HSMaaS offering.
      • HSMaaS Features of Concern/ensure the candidate HSMaaS satisfies your needs:
        • FIPS Level
        • whether it is backed by a commercial hardware HSM solution or hardware/software generic HSM solution
        • infrastructure protection level (network & perimeter, physical locations/buildings, DDoS)
        • geographic availability (hot vs cold/manual, upon request)
        • HR procedures, personnel operations that may affect the service
        • updates/patching, technical support
        • auditable logging
        • key attestation/public key verification 
        • in case the service is backed by commercial HSMs, does the cloud vendor provide the capability to access the HSM's native CLI/ways & protocols of consuming the service (programmatic, CLI, web-GUI)
        • service monitoring, alerting
        • service security validation (cybersecurity assessments)
        • compliance to other industry regulations
        • customer isolation (dedicated instance or same cryptographic engine/infrastructure and isolation only provided by user ACL)
      • Final decision algorithm (maybe?)
      Best Regards,

      Thanos Vrachnos OffensiveOps | PKI & eID Subject-matter Expert

    • 3.  RE: Kind reminder of tomorrow's working group call!

      Posted Jan 24, 2023 05:22:00 AM

      Please consider the following:

      NIST SP800-21 is superseded by NIST SP 800-175A. There is also a NIST SP 800-175B to go along with part A.

      Aspects of the Key Management lifecycle were addressed in Key Management in Cloud Services: Understanding Encryption's Desired Outcomes and Limitations.

      Any Key Management Lifecycle publications might reference CCM v4, the Implementation Guide, Shared Responsibilities, and Audit Guide. The CSA CBOK also includes the Cryptography Domain 11.

      NIST also has a crypto-publication-review-project page:

      Michael Roza CPA, CISA, CIA, CC, MBA, Exec MBA