Cómo preparar el Documento de Arquitectura del Servicio (DAS) para CICLON

En una evaluación CICLON, el Documento de Arquitectura del Servicio (DAS) es una de las piezas que más condicionan el comienzo de la certificación. No basta con presentar una arquitectura general del producto. Es necesario proporcionar información detallada sobre cómo está compuesto el servicio, qué componentes forman parte del alcance y qué depende de terceros. Si el objetivo es avanzar hacia el Catálogo CPSTIC, conviene tener este documento bien preparado desde el inicio.

Qué es el DAS dentro de CICLON

El DAS describe la arquitectura del servicio cloud que se va a evaluar. Es un documento de carácter privado dentro del expediente y su función es dejar claro:

qué componentes forman parte del TOE
qué elementos pertenecen al entorno operacional
qué integraciones intervienen en la operación normal del servicio
qué interfaces, protocolos y flujos existen entre componentes
qué restricciones afectan a datos, cifrado, acceso y proveedor cloud

En otras palabras: el DAS es el documento que permite entender la solución al completo.

Esto no se queda en una exigencia documental. La metodología de evaluación dedica una etapa específica al análisis del DAS y el laboratorio debe analizar el DAS para validar el contenido de este.

Qué debe incluir el DAS según CCN-STIC 2010

La información a proporcionar se divide en dos bloques:

Información general del proceso
Declaración responsable de conformidad del fabricante

Dentro de esa declaración responsable, el Anexo B pide cubrir expresamente:

estructura del TOE y su entorno operativo
flujos de información entre componentes
jurisdicción de los datos
requisitos de transparencia
autorización de acceso directo sin WAF para la evaluación
certificación ENS o EUCS del proveedor
requisitos criptográficos
condición de servicio de cifra, cuando aplique

1. Información general del proceso

La plantilla arranca con la identificación formal del expediente:

razón social del fabricante
datos del representante legal
nombre del TOE
tipo de evaluación, referido a CICLON versión 1.0

Es la parte que identifica qué se va a evaluar y cómo. Debe ser consistente con la Declaración de Seguridad (DS).

2. Diagrama de Arquitectura del Servicio (DIAS)

La parte más importante del documento es el DIAS, el diagrama de arquitectura del servicio.

El Anexo B pide representar el producto desplegado en la nube y su integración con componentes propios o de terceros necesarios para la operación normal del servicio. Además, exige que todo componente que forme parte del TOE quede identificado claramente.

Junto al diagrama, el documento debe detallar para cada componente:

propietario
si está incluido o no en CPSTIC
uso del componente
interfaces externas e internas y sus protocolos
interacciones con otros componentes o servicios

No se trata solo de incluir componentes. Se trata de dejar claro qué se evalúa, qué queda fuera y cómo se relacionan entre sí los elementos del servicio.

3. Jurisdicción de los datos

El Anexo B dedica un apartado específico a la jurisdicción de los datos. Aquí lo que se declara es el cumplimiento de las limitaciones geográficas aplicables al tratamiento y ubicación de los datos del servicio, incluidos los datos principales, las copias de respaldo y los registros de auditoría cuando corresponda.

4. Transparencia

En el apartado de transparencia se debe garantizar que, si los clientes del servicio lo requieren, se puede proporcionar información sobre:

el listado de herramientas de seguridad utilizadas
la descripción de la virtualización y de los mecanismos de segregación
los procedimientos de borrado seguro
la ubicación geográfica de datos, backups y logs
acceso y análisis de logs y registros en caso de incidente

5. Acceso directo sin WAF

Para la evaluación se contemplan dos vías de acceso: a través de WAF o sin WAF. En muchos productos, mantener el WAF durante las pruebas puede limitar el alcance de la evaluación y no ser una opción viable. Por eso, siempre que el producto lo permita, conviene facilitar al laboratorio un acceso sin WAF para poder ejecutar las pruebas sin bloquear el proceso.

6. Certificación ENS o EUCS del proveedor cloud

El DAS también debe identificar la certificación ENS o EUCS del sistema que suministra el producto cloud, incluyendo:

proveedor de la plataforma
nivel ENS
fecha de validez
ubicación geográfica de los datos

Esta información la proporciona el propio proveedor cloud. Aquí se puede encontrar para algunos de los principales proveedores cloud:

7. Requisitos criptográficos

Se debe documentar cómo se protegen los activos declarados como Parámetro de Seguridad Crítico (PSC) o Parámetro de Seguridad Sensible (PSS):

en tránsito, indicando protocolos y cipher suites
en reposo, indicando la forma de protección aplicada

No basta con afirmar que existe cifrado. La plantilla exige declararlo para cada componente, por activo protegido y por mecanismo real.

8. Si el producto es un servicio de cifra

Si el producto desplegado en nube es un servicio de cifra, el DAS debe describir además:

cómo funcionan los mecanismos de cifra sin almacenar las claves en la nube
la arquitectura utilizada, con marca, modelo y versión del HSM
cómo se garantiza que el cliente pueda gestionar y almacenar esos mecanismos

Qué suele bloquear un DAS

Los problemas más comunes suelen ser:

descripción del TOE y entorno demasiado genérica
falta de claridad al explicar las integraciones y componentes
falta de claridad sobre logs, backups y jurisdicción
mecanismos de cifrado descritos sin suficiente detalle
inconsistencias entre el DAS y la operativa real

Un DAS incompleto puede demorar el proceso de evaluación. Prepararlo correctamente ayuda a acelerar el trabajo del laboratorio y a evitar interrupciones cuando la revisión metodológica ya está en marcha.

Cómo ayuda CYBSER

En CYBSER nos encargamos de entender vuestro producto, su arquitectura y cómo se presta para preparar una documentación coherente, precisa y útil para la evaluación y la entrada en el Catálogo CPSTIC.

Preparamos la DS, damos soporte con el DAS, revisamos la documentación y ejecutamos la evaluación al completo. La idea es que vuestro equipo pueda seguir centrado en el producto mientras nosotros llevamos el proceso.

Si queréis revisar si vuestro servicio cloud está listo para CICLON, podéis partir de nuestra guía sobre CCN-STIC 2010 o ir directamente a nuestro servicio de certificación CICLON.