· CYBSER

How to prepare the Service Architecture Document (DAS) for CICLON

What the DAS for CICLON must include, what the laboratory will review, and what should be clear before the evaluation begins.

How to prepare the Service Architecture Document (DAS) for CICLON

In a CICLON evaluation, the Service Architecture Document (DAS) is one of the documents that most directly affects the start of the certification process. A high-level architecture overview is not enough. Detailed information must be provided on how the service is composed, which components fall within scope and which ones depend on third parties. If the goal is to move towards the CPSTIC Catalogue, this document should be in good shape from the outset.

What the DAS is within CICLON

The DAS describes the cloud service architecture that will be evaluated. It is a private document within the evaluation package, and its role is to make clear:

  • which components form part of the TOE
  • which elements belong to the operational environment
  • which integrations are required for normal service operation
  • which interfaces, protocols and flows exist between components
  • which constraints apply to data, encryption, access and the cloud provider

In short, the DAS is what allows the full solution to be understood.

This is not just a documentary requirement. The evaluation methodology includes a dedicated DAS analysis stage, and the laboratory must analyse the DAS to validate its content.

What the DAS must include under CCN-STIC 2010

The information to be provided is divided into two blocks:

  1. General process information
  2. Manufacturer declaration of conformity

Within that declaration, Annex B explicitly asks the DAS to cover:

  • TOE structure and operational environment
  • information flows between components
  • data jurisdiction
  • transparency requirements
  • direct access authorisation without WAF for evaluation purposes
  • ENS or EUCS certification of the provider
  • cryptographic requirements
  • whether the product is a cryptographic service

1. General process information

The template starts with the formal identity of the evaluation package:

  • manufacturer details
  • legal representative
  • TOE name
  • evaluation type, referenced as CICLON version 1.0

This section identifies what is going to be evaluated and how. It must be consistent with the Security Target (ST).

2. Service Architecture Diagram (DIAS)

The most important part of the document is the DIAS, the Service Architecture Diagram.

Annex B requires a representation of the cloud product architecture and its integration with proprietary or third-party components needed for normal service operation. It also requires that every component considered part of the TOE be clearly identified.

For each component or service, the template then asks for:

  • ownership
  • whether it is included in CPSTIC
  • purpose of the component
  • internal and external interfaces and protocols
  • interactions with other components or services

It is not just about listing components. It is about making clear what is being evaluated, what sits outside the TOE and how the service actually works.

3. Data jurisdiction

Annex B gives data jurisdiction its own section. What is being declared here is compliance with the geographic restrictions that apply to the service data, including primary data, backups and audit logs where relevant.

4. Transparency

Under transparency, it must be possible to provide customers of the service, if requested, with information about:

  • the list of security tools in use
  • the description of the virtualisation model and segregation mechanisms
  • secure deletion procedures
  • the geographic location of data, backups and logs
  • access to logs and records in the event of an incident

5. Direct access without WAF

For the evaluation, two access routes are contemplated: through the WAF or without it. In many products, keeping the WAF in place during testing can limit the scope of the evaluation and may not be a viable option. Whenever the product allows it, it is better to provide the laboratory with direct access without WAF so the tests can be carried out without blocking the process.

6. ENS or EUCS certification of the cloud provider

The DAS must also identify the ENS or EUCS certification of the system supplying the cloud product, including:

  • platform provider
  • ENS level
  • validity date
  • geographic data location

This information is provided by the cloud provider itself. It can be found for some of the main cloud providers here:

7. Cryptographic requirements

The DAS must document how assets declared as Critical Security Parameters (PSC) or Sensitive Security Parameters (PSS) are protected:

  • in transit, including protocols and cipher suites
  • at rest, including the protection mechanism used

It is not enough to state that encryption exists. The template expects it to be declared for each component, by protected asset and by actual mechanism.

8. If the product is a cryptographic service

If the cloud-deployed product is a cryptographic service, the DAS must also describe:

  • how encryption mechanisms operate without storing keys in the cloud
  • the architecture in use, including HSM brand, model and version
  • how the customer is guaranteed control over management and storage of those mechanisms

What usually blocks a DAS

The most common problems are usually:

  • a description of the TOE and operational environment that is too generic
  • lack of clarity when explaining integrations and components
  • lack of clarity around logs, backups and jurisdiction
  • cryptographic mechanisms described without enough detail
  • inconsistencies between the DAS and the real operating model

An incomplete DAS can delay the evaluation process. Preparing it properly helps the laboratory move faster and avoids interruptions once the methodology review is already underway.

How CYBSER helps

At CYBSER, we take the time to understand your product, its architecture and how it is delivered so we can prepare documentation that is coherent, precise and actually useful for the evaluation and the route into the CPSTIC Catalogue.

We prepare the ST, support the DAS, review the documentation and carry out the full evaluation. The goal is for your team to stay focused on the product while we handle the process.

If you need to assess whether your cloud service is ready for CICLON, you can start with our CCN-STIC 2010 guide or go straight to our CICLON certification service.

Back to Blog