Polı́tica de Seguridad y Contratos con proveedores

La Organización debiera contar con una Política donde se definan las directrices de seguridad a tener
en cuenta a la hora de implementar soluciones en la Nube.

Comprender el entorno de amenazas específico debe proporcionar a las empresas el contexto

necesario para adoptar las decisiones en torno al uso de la Nube en general. En algunos casos, migrar a la
Nube ofrece la oportunidad de mantener o incluso mejorar la postura de seguridad de una organización.
En otros casos, la migración a la Nube crea nuevos problemas. En cualquiera de los dos casos, un enfoque
posible sería el de establecer el tipo de Nube permitida en función del tipo de datos que albergue. Para ello,
los datos debieran clasificarse de acuerdo con la Política de clasificación de datos que la Organización haya
establecido. Así, dependiendo del nivel de confidencialidad asignado a los datos, se permite su uso sólo en
determinados tipos de soluciones de Nube. Además de los requisitos mínimos con respecto a la seguridad
de las distintas clasificaciones de los datos, pueden imponerse requisitos adicionales más restrictivos
basados en una evaluación de riesgos para cada implementación de la Nube.

Otro punto importante a tener en cuenta es que el proceso de aprovisionamiento de servicios en la

Nube debería establecer las reglas, de entre las cuales destacan, las legales, las regulatorias, las de
seguridad, las de privacidad y las de costes, que la empresa debe seguir para cualquier contratación de
dichos servicios. Durante esta fase del proceso se deberá detectar cualquier contratación fuera del proceso
habitual efectuada por cualquier departamento de la empresa, conocer el por qué y el impacto que esta
situación está teniendo en la organización y establecer los controles necesarios con el fin de evitar su
propagación, a fín de evitar problemas legales, regulatorios y de privacidad/seguridad que pudieran originar
por dicha práctica.

Se muestra a continuación una serie de requisitos a considerar en la formalización del contrato:

● Diagramas de flujos de datos, ubicación de los datos y controles de ciberseguridad a aplicar. Aquí se
incluyen las descripciones de los entornos de almacenamiento de datos y servidores compartidos con
otras empresas.
● Definición de una matriz de responsabilidades clara que permita estructurar un modelo de riesgo
apropiado.
● Los controles de ciberseguridad y riesgo de TI definidos (p. ej. Bastionado, parcheado, gestión de
vulnerabilidades, nivel de aislamiento, gestión de identidades y accesos, seguridad de red y protección
contra software malicioso).
● Restricciones geográficas en la ubicación de los datos.
● Controles que cumplan los requisitos legales y reglamentarios de la protección de datos y los derechos
de los usuarios.
● Determinar la finalidad de uso de forma que no sea distinto del que está autorizado.
● La capacidad de revisar la diligencia debida de los proveedores con los subcontratistas, así como la
supervisión del servicio vigente (acuerdos de nivel de servicio, estados financieros, cambio de
subcontratistas, titularidad de los datos incluidos los metadatos).
● Notificación en tiempo de todos los incidentes relacionados con la seguridad.
● Notificación de todos los cambios importantes que el proveedor vaya a llevar a cabo y que puedan
afectar a la infraestructura o al servicio contratado.
● Estrategia de salida y portabilidad de los datos de las instalaciones del proveedor.
● La cláusula de derecho de auditoría que proporciona la capacidad de auditar al proveedor de la Nube,
lo que respalda la trazabilidad y la transparencia en el entorno de programación en la Nube y de la
 regulación, ya que estos evolucionan con frecuencia. Es importante que esta cláusula indique sobre qué
elementos podrá el cliente realizar la auditoría, entre los que pueden incluirse: registros de control,
políticas y procedimientos, información de proveedores subcontratados, registros generados por
software utilizado en la prestación del servicio, etc. En ocasiones esta cláusula suele ser sustituida por
el derecho del cliente de acceder a certificaciones tipo ISO27001 o SOC/ISAE.
● Cláusula de transparencia con los derechos de acceso especificados.
● Protección de datos con especial atención a las medidas de seguridad y organizativas que dirijan el
procesamiento que tendrá lugar y la garantía del cumplimiento de dichas medidas.
● Propiedad Intelectual mediante la cual el cliente de servicios de Nube debe asegurarse de que el
contrato respeta sus derechos sobre cualquier propiedad intelectual, sin comprometer la calidad del
servicio ofrecido. Confidencialidad y no divulgación.
● Especificación del Acuerdo de Nivel de Servicio (ANS) o Service Level Agreement (SLA) así como de las
cláusulas de indemnización en caso de incumplimiento.

Modelos de control y modelos de gobernanza

Establecer e implementar herramientas y controles dentro de un programa de seguridad, privacidad y

cumplimiento de la información no es una actividad que debe ser realizada de forma aislada, sino que existe
una necesidad de seguridad constante y, por lo tanto, de supervisión continua. Esto toma especial
importancia a la hora de respaldar la supervisión continua de los servicios basados en la Nube.

La Guía de diseño ISACA® COBIT® 2019, proporciona las siguientes tareas que pueden incorporarse en
el programa de supervisión de garantía continua de servicios en la Nube:

● Identificar las prioridades del negocio y la estrategia del negocio dependiente de IT, incluyendo
cualquier proyecto significativo actual.
● Alinearse con políticas empresariales, estrategias, principios rectores y cualquier iniciativa de gobierno
en curso.
● Sensibilizar a los ejecutivos sobre la importancia de la TI para la empresa.
● Definir las políticas, objetivos y principios rectores y asegurarse de que la Alta Dirección las entiendan
y aprueben.

Otros modelos de control comúnmente utilizados tanto por clientes como por proveedores de servicios
en la Nube incluyen:

● CSA CCM: Dedicado exclusivamente a los riesgos en los entornos de Nube y orientado desde la
perspectiva de proveedor de servicios en la Nube y desde la perspectiva de cliente de los mismos.
● ISO 27002: Este estándar da cobertura a los aspectos generales de seguridad de TI sin entrar en el
detalle de la seguridad en la Nube.
● ISO 27017: Adapta los aspectos generales de seguridad de la ISO 27002 e incluye controles específicos
para los servicios en la Nube.
● NIST SP 800-114: Directrices en seguridad y privacidad para servicios en Nubes públicas. Aunque no
incluye controles específicos si detalla los principales aspectos a considerar para una adecuada gestión
de servicios en la Nube.
● ENISA: La guía “Computación en la Nube” de ENISA detalla los riesgos técnicos y legales, así como los
principales retos organizacionales.
3.1.1. Métricas
La selección e implementación de una metodología de métricas adecuada al tipo de servicio en la Nube,
ayudará a las empresas a mantener una monitorización contínua de los servicios de los que depende la
empresa para llevar a cabo sus actividades. Las siguientes métricas debieran ser consideradas.

Métricas asociadas al riesgo de la cadena de suministro

Una gran parte de los incidentes de seguridad y de las violaciones de la privacidad son causados por
proveedores contratados y socios comerciales. Para poder gestionar de manera efectiva la cadena de
suministro completa de una organización, deben establecerse programas de gestión de riesgos de
proveedores, dentro de los cuales se incluyen los de servicios en la Nube. De esta forma, se podrá obtener
un conocimiento sobre los niveles de riesgo asociados a la actividad de cada proveedor. Hay muchas
métricas importantes que se pueden usar para proporcionar tales conocimientos. Estas métricas ayudarán
a monitorear el riesgo de cada proveedor de la cadena de suministro, a partir del que se abordará la
estrategia de riesgo necesaria.

Ejemplos de métricas clave son:

● Frecuencia (típicamente en número de semanas o meses) de revisión de la lista completa de

proveedores, contratistas y otros terceros. De forma específica respecto a los servicios en la Nube, las
preguntas que se pueden hacer son:
o ¿El número de servicios en la Nube utilizados por la organización es mayor o menor que la revisión
anterior?
o ¿Qué servicios en la Nube se agregaron o eliminaron? ¿Por qué razón?
o ¿Cuántos controles de acceso fueron apropiadamente modificados para aquellos servicios
agregados en la Nube y para aquellos eliminados, de acuerdo con los procedimientos establecidos?
o ¿Cuántos controles de acceso fueron modificados inapropiadamente?
● Cantidad de proveedores de servicio Nube clasificados como críticos.
● Número de interfaces de programación de aplicaciones (API) con los proveedores de servicios en la
Nube: ¿Cuál es el total de API para el total de los servicios en la Nube y cuáles son las API totales para
cada servicio en la Nube?
● Número de conexiones en cada interfaz con el proveedor en la Nube.
● Cambio en la cantidad de proveedores críticos de servicios en la Nube, proveedores, contratistas y otros
terceros respecto a la revisión anterior.
● Número de servicios en la Nube que utilizan cifrado robusto (según lo establecido y documentado
formalmente por la organización) de los datos en tránsito.
● Número de servicios en la Nube que comparten datos confidenciales y personales utilizando varios
métodos y canales.
● Número de servicios en la Nube con cualquier nivel de acceso a datos personales y datos sensibles.
● Número de servicios en la Nube con acceso a cualquier tipo de datos críticos (por ejemplo, propiedad
intelectual, etc.).
● Número de servicios en la Nube que informaron incidentes de seguridad, violaciones de privacidad y
problemas de incumplimiento desde la última revisión.
● Tiempo que llevó (en horas y / o días, según corresponda para cada servicio en la Nube) el que los
proveedores de servicios en la Nube respondieran a incidentes de seguridad.
● Tiempo que lleva a cada servicio en la Nube en aplicar parches de seguridad críticos.
 La Publicación Especial (SP) 800-171 del Instituto Nacional de Estándares y Tecnología (NIST), considera
incorporar las siguientes métricas clave:

● Número de ciberincidentes detectados a través de alertas.

● Número de elementos de información personal involucrados con cada cadena de suministro individual
involucrada en cada incidente específico.
● Número de entidades externas notificadas.
● Número de alertas de seguridad comunicadas en relación con cada servicio en la Nube y entidad
externa asociada.
● Número de servicios en la Nube y de socios de la cadena de suministro impactados por cada alerta.

Métricas clave relacionadas con incidentes y brechas de seguridad

Las empresas deben establecer y documentar las categorías clave de incidentes de seguridad e
infracciones de privacidad, y hacer un seguimiento del número de infracciones e incidentes por categoría.

Ejemplos de métricas clave incluyen:

● Número de alertas de ciberseguridad.
● Número de denuncias de incidentes de seguridad por parte del personal.
● Tiempo que tarda la actividad de incidentes de seguridad ser procesada a través del sistema.
● Tiempo que lleva el decidir qué acción tomar en respuesta a una alerta.
● Porcentaje de alertas determinadas como amenazas no válidas (falsos positivos).
● Tiempo que lleva identificar un incidente de seguridad.
● Tiempo que lleva identificar una violación de privacidad.
● Tiempo empleado por el personal que realiza operaciones especializadas de seguridad, privacidad y
cumplimiento para resolver un incidente de seguridad.

Métricas asociadas a las tecnologías emergentes

Los desafíos a los que se enfrentan los profesionales de la seguridad de la información continúan
creciendo. La nueva tecnología conlleva nuevos riesgos, mientras que se convive con la tecnología heredada
durante décadas. Los profesionales de seguridad de la información se enfrentan no solo a la gestión del
riesgo de la seguridad en el sistema, sino también a la mitigación del riesgo en la seguridad de los datos y
del cumplimiento, sin menoscabar los desafíos comunes que a menudo se pasan por alto y que se deben
tener asimismo en cuenta.

Las métricas clave para respaldar tales conocimientos, y para ayudar a mitigar los riesgos asociados con
los servicios en la Nube, incluyen:

● Cantidad (en número de bytes, archivos, etc.) del tráfico saliente de la Nube privada de la organización
y que se envía a los servicios en la Nube contratados, además de a los sitios de Internet no autorizados.
● Cantidad de tráfico (en número de bytes, mensajes y/o archivos) desde y hacia los dispositivos de
usuario BYOD dentro de la red corporativa.
● Número de iniciativas corporativas y número asociado de servicios en la Nube, que involucran análisis
big data.
● Volumen de datos personales (en número de bytes, registros, etc.) utilizados en los procesos de IA
(inteligencia Artificial), y los servicios en la Nube asociados.
● Número de requisitos legales que cubren el uso, la protección, la compartición, y otras actividades
relacionadas con datos personales, y la cantidad de servicios en la Nube donde se almacenan, acceden
o procesan dichos datos personales.
● Volumen de tráfico hacia/desde dispositivos IoT dentro de la red corporativa.
Soluciones y herramientas

Como cada día aumenta el volumen de utilización de servicios en la Nube, los proveedores de servicios
en la Nube y fabricantes de herramientas de seguridad han desarrollado servicios y herramientas que hacen
frente a un creciente número de problemas que genera este nuevo paradigma en cuanto a seguridad. Estas
soluciones pueden ayudar desde el punto de vista técnico a mitigar los riesgos derivados de los servicios en
la Nube y por eso se ha considerado importante conocerlas.

Algunas de las herramientas/soluciones más comunes y novedosas utilizas con el fin de hacer frente a
estos nuevos desafíos y retos en cuanto a la seguridad son las siguientes:

*Cortafuegos Web o Web Application Firewall (WAF):

WAF es un dispositivo software o hardware que permite proteger los servidores de aplicaciones
expuestos en internet sobre determinados ataques específicos, tales como:

● Mitiga Ataques de Denegación de Servicios Distribuidos (DDoS).

● Previene Intentos de Explotación de Vulnerabilidades, como las inyecciones SQL, Cross-Site Scripting
(XSS), Inclusión Remota de Archivos (RFI), Inclusión Local de Archivos (LFI), etc.
● Protege Contra los principales riesgos identificados por la OWASP.
● Protege Contra Ataques de Control de Acceso.

*Agentes de Seguridad para el Acceso a la Nube o Cloud Access Security Broker (CASB):
Software que protege ataques orientados a la información y los usuarios, con la ventaja de que son
gestionados por la propia organización. Los CASB refuerzan las políticas de seguridad utilizadas en la Nube,
y se ubican entre los usuarios y los proveedores de servicios en la Nube.

Los CASB se basan en cuatro pilares básicos:

● Visibilidad. ¿Qué aplicaciones están siendo utilizadas por nuestros empleados? Importante aspecto
para la identificación y gestión de shadow IT.
● Gestión Normativa. Legal. Clasificación de los distintos tipos de datos, quién accede a cada tipo de datos
y desde dónde.
● Seguridad de los Datos. Refuerzan las políticas relativas a los datos, la gestión de acceso, el cifrado, etc.
● Protección de Amenazas. Detectan y responden a amenazas internas negligentes o maliciosas, así como
a amenazas de usuarios con ciertos privilegios.

*Protección de Carga de Trabajo en la Nube o Cloud Workload Protection Platform (CWPP):

CWPP es un término desarrollado por Gartner para describir una categoría emergente de soluciones
tecnológicas utilizadas principalmente para proteger las cargas de trabajo del servidor en entornos de
Infraestructura como servicio (IaaS) de Nube pública. Los CWPP proporcionan protecciones basadas en el
host para controlar su carga de trabajo, que es otra forma de referirse a sus aplicaciones, bases de datos y
/ o funciones que se ejecutan en instancias, nodos, máquinas virtuales o cualquier otra nomenclatura que
utilice el proveedor de la Nube.
 Principales beneficios en la implementación de dicha solución:

● Visibilidad y mayor control de cargas de trabajo en entornos de Nubes públicas.

● Seguridad elástica en cargas dinámicas.
● Mitigación de riesgos en cuanto a la adopción de servicios en Nubes públicas.

*Gestión de la Situación de Seguridad de la Nube o Cloud Security Posture Management (CSPM):

Nueva solución de seguridad que intenta ayudar a las organizaciones a descubrir, evaluar y resolver las
configuraciones incorrectas de los diferentes servicios implementados en la Nube. Debido a la gran
adopción de servicios IaaS, muchos de los ataques a dichos servicios se deben a su deficiente configuración
por parte de los clientes.

Depende de la solución implementada, algunos de los beneficios identificados son:

● Reduce malas configuraciones en entornos de Nube.

● Identifica si nuevos servicios han sigo generados sin las aprobaciones necesarias o con el debido análisis
de riesgo (evitar shadow IT).
● Da visibilidad a las políticas y garantiza su aplicación coherente en múltiples proveedores.
● Verifica que las actividades operativas se realicen como se esperaba de acuerdo con las políticas
establecidas por la organización.
● Soluciona automáticamente problemas de configuración, sin intervención humana.

Estas tres soluciones (CASB, CWPP y CSPM) tienen su ámbito de aplicación delimitado a los distintos
tipos de Nubes desde el punto de vista del modelo de servicio. Tal como se muestra en la Ilustración 4.

Ilustración . Ámbito de aplicación de soluciones de seguridad. Fuente Gartner.com

Auditorı́a de la Nube

El mundo de la Nube se puede clasificar atendiendo a dos aspectos principales, el modelo de

implantación y la categoría de servicio en la Nube que se ofrece.

En este nuevo mundo, se pueden identificar los siguientes grupos de riesgo:

● Organizacionales.
● Operativos.
● Financieros.
● Estratégicos.

Es importante que el auditor esté familiarizado con los diferentes modelos de servicios (IasS, PasS, SaaS)
que existen. Así como las diferentes modelos de implantación (Público, Privado, Hibrido).

El auditor se encontrará con una serie de retos comunes a los que hasta la fecha se encontraban en la
auditoría tradicionales y otros específicos de los modelos de la Nube.
Entre los retos específicos de los modelos de la Nube destacan:

● Dispersión geográfica.
● No todas las regulaciones están adaptadas al mundo de la Nube.
● Monitorización del rendimiento y disponibilidad.
● Gestión de la información.
● Auditoría de entornos multi-cliente.
● Dificultad para encontrar evidencias.

Particularidades de la Nube

A la hora de planificar una auditoría del servicio en la Nube, será clave tener en consideración las
particularidades del entorno, que variarán en función del modelo de Nube implantado. Estas
particularidades tendrán un impacto directo en la capacidad de revisión de controles y en el diseño de los
procedimientos de validación.
En las siguientes subáreas se detallarán las particularidades de los distintos modelos de Nube y su
impacto en los procedimientos de auditoría.

*Particularidades de auditoría para Infrastructure as a Service (IaaS)

Como se ha visto con anterioridad, en el modelo IaaS la organización es responsable del mantenimiento
de las máquinas virtuales y sistemas operativos, bases de datos y aplicaciones que en ellas residan.
También, en la mayoría de los casos, la organización será responsable de la gestión operativa de la
capa de virtualización (hipervisor). Por otro lado, el proveedor de servicios Nube será el encargado del
mantenimiento de la infraestructura subyacente, así como del software y hardware que soportan la capa
de virtualización.
 *Áreas de revisión directa: Según el resumen anterior, las áreas de revisión directa estarán limitadas
a aquellas áreas de control que son gestionadas parcial o íntegramente por la organización. Algunas de las
áreas de control que pueden ser revisadas de manera directa se incluyen resumidas a continuación:

• Gobierno de la Nube: Definición de roles y responsabilidades, gestión del contrato y definición de

cláusulas clave.
• Gestión del servicio: Análisis y definición de acuerdos de nivel de servicio (ANS), gestión de
desviaciones de ANS, definición de penalizaciones por incumplimiento y otros.
• Gestión de riesgos: Identificación, análisis y tratamiento de riesgos.
• Incidentes de seguridad y disponibilidad: definición de canales de comunicación con el proveedor del
servicio, escalado de incidentes, remediación y análisis de causas raíz.
• Gestión de la capa de virtualización: configuración segura del hipervisor, gestión de accesos y permisos,
configuración de contraseñas y revisión de logs.
• Gestión de los servidores virtuales: inventario de servidores, gestión de la capacidad, configuración
segura y control de accesos, parcheado, gestión de vulnerabilidades, etc.

Cabe destacar que la capa de infraestructura subyacente (incluyendo software y hardware que
soportan la capa de virtualización) pudiera ser objeto de revisión directa en el caso de que una cláusula de
auditabilidad así lo establezca en el contrato con el proveedor del servicio Nube. En esta situación se
podrían revisar controles de seguridad física y lógica de dicha infraestructura.

*Áreas de revisión indirecta: En el caso de que no se haya definido una cláusula de auditabilidad en el
contrato, el entorno de control de la infraestructura subyacente que soporta el servicio deberá ser auditado
de manera indirecta. Ante esta casuística, el auditor validará las actividades de supervisión llevadas a cabo
la dirección para obtener un confort razonable sobre los controles implementados en dichas áreas clave.
Estas actividades de supervisión podrían consistir en la obtención y revisión de certificaciones y/o informes
de un tercero de tipo SOC 2 que validen, no solo el diseño, sino también la efectividad operativa de los
controles. En este punto, será de especial relevancia verificar los análisis realizados por la Dirección ante
las excepciones identificadas en el informe de tipo SOC para determinar el potencial impacto en los sistemas
de la organización y la definición de una respuesta alineada con el apetito de riesgo.
Particularidades de auditoría de Platform as a Service (PaaS)
En el modelo de PaaS la organización es la responsable de la gestión de las bases de datos y las
aplicaciones. A su vez, el proveedor será responsable de la infraestructura subyacente, el Sistema
Operativo, la capa de virtualización y la gestión de los servidores virtuales.

Áreas de revisión directa: En este modelo, las áreas de revisión directa podrían incluir la seguridad y
gestión de las bases de datos, así como de las aplicaciones y sistemas que se encuentren en el entorno de
Nube. También podrían considerarse los controles de mantenimiento de dichos sistemas, incluyendo el
ciclo de vida de desarrollo y la gestión de cambios. Como se detalla en el apartado anterior, en el caso de
existir una cláusula de auditabilidad en el contrato, que habilite a la organización a revisar de manera directa
los controles implementados por el proveedor de servicios en la Nube, las áreas de revisión directa podrán
incluir controles de seguridad física y lógica de la infraestructura subyacente, controles de gestión de la
capa de virtualización y gestión de los servidores virtuales.

Áreas de revisión indirecta: En el caso de que no se haya definido una cláusula de auditabilidad en el
contrato, el entorno de control de la infraestructura subyacente, la capa de virtualización del entorno Nube
y la gestión de los servidores virtuales deberán ser revisados de manera indirecta. Como en el modelo IaaS,
el auditor deberá verificar qué actividades de supervisión ha llevado a cabo la dirección para obtener un
confort razonable sobre dichas áreas clave.

4.1.1. Particularidades de auditoría de Software as a Service (SaaS)

En el modelo SaaS la organización es responsable únicamente de la gestión operativa de las
aplicaciones. Por otro lado, el proveedor de servicios es el encargado de la infraestructura subyacente, la
capa de virtualización, los servidores virtuales y la gestión y mantenimiento del software de aplicaciones.

Áreas de revisión directa: Bajo este modelo, las áreas de revisión directa podrían incluir control de
accesos a la aplicación, configuración y monitorización de alertas, segregación de funciones, monitorización
de transacciones críticas, etc. En el caso de existir una cláusula de auditabilidad definida en el contrato, el
auditor podrá revisar el resto de las áreas gestionadas íntegramente por el proveedor de servicios Nube.

Áreas de revisión indirecta: En el modelo SaaS, las áreas de control gestionadas íntegramente por el
proveedor son la mayoría. Por tanto, las áreas de revisión indirecta podrían incluir gestión de la
infraestructura subyacente, capa de virtualización, servidores virtuales, gestión de bases de datos y
mantenimiento del software de aplicación.

Preparació n de la auditorı́a

El paradigma de esta tecnología, y su complejidad, conlleva, que antes de realizar cualquier auditoría,
tanto interna como externa, existan una serie de factores a tener en cuenta.

A continuación, se establecen dichos puntos de preparación de forma generalista. Los puntos de

preparación pueden sufrir modificaciones en función del entorno o entornos que forman parte del alcance
de la auditoría. Por entorno, se hace referencia a los modelos de servicio (IaaS, PaaS o SaaS) o bien entornos
mixtos, es decir, cualquier mezcla de los diferentes servicios indicados anteriormente con servicios de la
propia empresa en sus instalaciones (on-premise). También cobra cierta relevancia el tipo de modelo de
implantación de la Nube (Publica, Privada, Hibrida).

-Arranque de la auditoría:
Toda auditoría comienza con un arranque en donde se establece el equipo auditor, la metodología que
se llevará a cabo en la auditoría, las horas de trabajo previstas, las visitas que se pueden realizar, el tipo de
evidencias a obtener y como éstas deben ser entregadas al equipo auditor. Será imprescindible contar con
acuerdos de confidencialidad (NDA, non-disclosure agreement) dada la naturaleza de la documentación
tan sensible a recoger. También es importante establecer qué documentos se pueden imprimir y cuáles no,
incluso las medidas físicas necesarias para visualizar cierta documentación.

Otro punto importante a tener en cuenta es la visita, o visitas, al centro de datos desde donde se presta
el servicio en la Nube. Este es un aspecto que hay que planificar lo antes posible, debido a que gestionar
los accesos al mismo suele ser complejo por cuestiones de política de seguridad y de auditoría. Se debe
resaltar que, en la mayoría de los casos, el proveedor de los servicios en la Nube no es el propietario del
centro de datos. Este hecho implica que algunas áreas de la auditoría cambian, es decir, ciertas áreas deban
ser cubiertas por la empresa prestadora de los servicios, y otras por la propietaria del centro. Este es un
aspecto importante que se debe revisar por parte del equipo auditor, sobre todo la parte contractual de las
partes involucradas en el servicio para identificar responsabilidades de cada uno.

Alcance de la auditoría:
Con lo indicado anteriormente, y centrándose en las partes principales de la auditoría, se debe conocer
y acordar con el cliente qué es lo que se va a auditar, es decir, conocer el alcance de la auditoría. Es
recomendable empezar definiendo el objetivo de la auditoría, es decir, qué es lo que realmente va a ser
auditado e identificar las distintas áreas de auditoría. Como ejemplo, se listan a continuación las más
significativas, de las cuales se auditarán una o varias o todas:

● Física (physical)
● Almacenamiento (storage)
● Comunicaciones (network)
● Aplicaciones (applications)
● Datos (data)
● Personal (staff/personnel)

Las áreas identificadas anteriormente y el motivo de auditoría estarán relacionadas con el modelo de
servicio, o servicios en la Nube sujetos de autoría. Adicionalmente, se ha de considerar que, aunque se trate
de una auditoría de servicios en la Nube, es muy probable que conlleve una parte on-premise a auditar.
 Por otro lado, hay que tener en cuenta que la complejidad podría incrementarse si el alcance de la
auditoría contemplase soluciones en la Nube de diferentes proveedores de servicio (escenario “multi-
nube”), algo que actualmente se está convirtiendo en la norma de muchas empresas. Este hecho se traduce
en una dificultad de cara al equipo auditor, ya que las reglas o controles de seguridad de un vendedor
pueden ser totalmente diferentes a las de otro para servicios iguales o muy parecidos.

A modo de ejemplo, se podría establecer una matriz parecida a la de abajo, con diferentes líneas de
auditoría:

Áreas de Auditoría IaaS PaaS SaaS On-premise Multi-Proveedor

de servicios
Física X X
Almacenamiento X X
Comunicaciones X X
Aplicaciones X X X
Datos X X X
Personal X X X X X
Tabla . Matriz de líneas de auditoría

Se debe de seguir con la elaboración de un documento conocido como declaración de aplicabilidad

(SoA – Statement of Applicability), que indicará qué áreas son aplicables a la auditoría y cuáles no,
facilitando para estas última una justificación del porqué de su exclusión.

Por ejemplo, el resultado podría ser un documento con información similar a la indicada en la siguiente
tabla:

Marco Requisito Referencia Aplica No Justificación en caso

Referencia Aplica no aplicar
p. ej. ISO Requisito #1 Rq.to#1
27001/ENS/PCI X
DSS/ …
p. ej. ISO Requisito #2 Rq.to#2 Indicar el motivo.
27001/ENS/PCI X Enumerar las razones, de
DSS/ … forma clara y concisa.
Tabla . Ejemplo de declaración de aplicabilidad

Una vez que este documento ha sido acordado y firmado si procede, se pasará a la siguiente fase.

Recogida de evidencias:
Parte crítica y principal de toda auditoría. Para la recogida de evidencias es recomendable que el cliente
haya identificado a uno o más responsables por cada requisito aplicable. Este es un ejercicio importante y
requiere mucho esfuerzo y tiempo. Dichos responsables pueden ser conocidos como expertos en la materia
(Subject Matter Experts - SME), a los cuales se les ha debido de informar del motivo de la auditoría y de lo
que se espera de ellos (disponibilidad y documentación a facilitar).
 Por cada control que está siendo auditado se deberán obtener evidencias claras y creíbles de que la
empresa tiene la documentación correspondiente, actualizada y que el procedimiento se cumple en función
de lo establecido y lo marcado por el requisito o estándar.

Cabe resaltar, que durante esta fase pueden surgir problemas entre las partes por la interpretación de
matices que pudieran originarse. Es aconsejable tener reuniones preliminares con los principales
interlocutores con el fin de resolver cualquier duda al respecto, esto hará que el trabajo de campo y
recogida de evidencias sea lo más ágil, eficaz, eficiente y posible.

Una medida importante es la de establecer un calendario de recogida de auditorías bien planificado,

con el fin de dar tiempo suficiente a cada experto en la recogida y presentación de la documentación. Podría
darse el caso de que ciertos expertos se encuentren en una zona/franja horaria diferente, por lo que la
flexibilidad a la hora de elaborar un plan de trabajo que involucre a dicho grupo de expertos es también
una parte fundamental en estas situaciones.

Durante esta fase, los auditores pueden beneficiarse de diferente documentación en forma de
estándares de certificación que la empresa puede tener; ISO 27001 (gestión de la seguridad de la
información), ISO 31000 (gestión del riesgo), ISO 20000 (servicios gestionados), SOC (Sistema de
organización de servicios), PCI DSS, etcétera. Dicha documentación puede ayudar a los auditores a centrarse
en requerimientos particulares en más detalle, en vez de hacer foco en requerimientos que dichos
estándares ya cubren en profundidad.

Por último, se debe de establecer un plan de mejora continua. Es decir, corregir aquellas desviaciones
encontradas durante la toda la fase de auditoría. Aunque no sea sencillo cuantificar este apartado, es
importante tener en cuenta dicha fase en el proceso de auditoría desde el principio.

Guı́a para el auditor

En este punto se pretenden cubrir las áreas principales a tener en cuenta por todo auditor, que audite
entornos en la Nube. En el Checklist se pretenden abordar los aspectos más importantes de una auditoría
y que sirva de guía para los auditores que se enfrenten por primera vez a una auditoría de servicios en la
Nube, así como de apoyo para los auditores más experimentados que encuentren preguntas de interés que
puedan importar a sus auditorías.

Las preguntas (check-list) no son únicas, dependiendo del entorno a ser auditado, el marco regulatorio
de la empresa, su nivel de riego, detalle, etc. dichas preguntas pueden derivar en nuevas, con el fin de
profundizar en ciertas áreas.

5.1. Proceso-Fases de auditorı́a:

Como en todo proceso de auditoría, se identifican las siguientes fases:

Inicio. Preauditoría
Informes. Mejora
Auditoría
Evaluación Resultados Continua
 Inicio. Identificar la relación contractual existente con el proveedor de servicio
Evaluación (SP por sus siglas en inglés Service Provider)

Descripción inicial de los servicios y controles que son sujetos de auditoría.

Es decir, ¿Qué se está auditando? ISO 27001, ENS, HIPPA, PCI etc.

Obtener las aprobaciones necesarias para acceder a un centro de datos.

Preauditoría Cubrir todos los trabajos necesarios antes de acometer una auditoría.
● Alcance (Scope)
● Planificación
● Identificar a las personas que van a participar. Cuando y
qué limitaciones existen
● Acceso a la documentación. Desde dónde y bajo qué
circunstancias.
Auditoría Trabajo de campo (fieldwork). Identificación de evidencias, entrevistas
con personas y personal responsable de controles, revisar
documentación, etc.
Informes. Análisis de evidencias encontradas y Elaboración de informes.
Resultado Plan de remediación.
Mejora Continua. Establecer áreas de mejora continua dentro de la auditoría para su
Lecciones aprendidas posterior implementación.
Fases de auditoría

Para cada una de las fases, se establecen una serie de preguntas que son de utilidad para auditar
servicios en la Nube. Como ya se ha indicado anteriormente, se debe realizar/modificar en función del
objetivo de la auditoría.

Inicio. Evaluación

Pregunta Limitaciones Respuesta Notas

Describir el mandato de auditoría o carta de encargo
y los principales objetivos a cubrir durante la ejecución
de la auditoría
Análisis inicial de Aspectos regulatorios como el RGPD
o la regulación específica sobre el negocio con un
listado completo de las regulaciones que se consideran
aplicables a nuestra auditoría e incluso que el auditor
mantenga estas regulaciones como evidencias
relevantes durante el proceso de ejecución de la
auditoría.
Análisis contractual de proveedores Nube
(IaaS/PaaS/SaaS o combinados). Obtener un listado del
número de contratos con proveedores y sus contratos
de nivel de servicio. Se recomienda mantener siempre
este listado y monitorizarlo durante la ejecución de la
auditoría e incluir información básica contractual:
periodos críticos del contrato y presupuestos
asociados.
Análisis de Políticas, estrategias y Directivas
organizacionales. El estatuto de auditoría interna o la
carta de encargo, las políticas de seguridad de la
información y de auditoría interna y de sistemas, las
estrategias corporativas, especialmente sobre
tecnologías de la información y comunicaciones (TIC) y
aspectos relevantes de recursos humanos que puedan
afectar al mantenimiento o desarrollo de las
infraestructuras Nube. Se recomienda realizar un
listado de estas políticas, estrategias y directivas
organizaciones que se consideran aplicables a nuestra
auditoría e incluso que el auditor mantenga estas
regulaciones como evidencias relevantes durante el
proceso de ejecución de la auditoría.
Análisis de Infraestructuras de tecnologías de la
información bajo responsabilidad de la organización y
de aquellas que están bajo contratos con proveedores
de servicios Nube. Deberían, al menos, identificarse los
Centros de Procesamiento de la Información
principales y las instalaciones con terminales de
usuario. Se recomienda realizar un listado de estas
instalaciones que se consideran aplicables a nuestra
auditoría e incluso que el auditor mantenga este
listado durante el proceso de ejecución de la auditoría.
No se requiere mantener complejas bases de datos de
activos de la información como una CMDB o un
inventario de, pues es un proceso complejo que
requiere de considerables recursos, pero si al menos
una identificación de las instalaciones principales.
Análisis de Interfaces externos con otras
organizaciones con las que se intercambie
información, incluyendo los diferentes proveedores.
Deberían, al menos, identificarse qué tipos de
entidades son y los principales puntos de contacto.
También se aboga por identificar todos los acuerdos de
alto nivel que se tengan con este tipo de entidades. Se
recomienda realizar un listado de estas entidades y
acuerdos, e incluso que el auditor mantenga este
listado durante el proceso de ejecución de la auditoría.
Evaluación de Riesgos preliminar al objeto de
determinar las diferentes prioridades para la
asignación efectiva de recursos de auditoría.

Pre auditoría

Pregunta Limitaciones Respuesta Notas

Listado de contratos bajo el paraguas de la auditoría.
Incluir un listado de los contratos que están dentro del
alcance de la auditoría.
Contextualizar la auditoría, con una breve descripción
del objeto auditable, incluyendo información sobre
empresa, entidad, departamento, organización, etc.
Detallar el alcance de la auditoría. Dentro de los
contratos bajo el paraguas de la auditoría identificar los
siguientes elementos para especificar con mayor grado
de detalle el alcance final de la auditoría:
✔ Los aspectos regulatorios que cubre.
✔ Los estándares que van a ser utilizados
como referencia durante la auditoría.
✔ Las ubicaciones físicas de las
infraestructuras TIC.
✔ Dentro de cada ubicación física,
identificar los activos de alto nivel (centro
de procesos de datos, sistemas de
información y redes)
✔ Los elementos organizacionales y sus
procesos asociados que cubre dentro de
cada proveedor de servicio.
✔ La cadena de suministro de los
proveedores de servicios Nube, con los
principales contratistas de herramientas,
procesos y servicios asociados con los
contratos identificados dentro del
alcance.
Describir el enfoque y el método de la auditoría. Si se
trata de una auditoría de cumplimiento o de
diagnóstico, las técnicas de auditoría asistidas por
computador (CAATS, Computer Audit Assisted
Techniques) y los sistemas asociados a las mismas que
vayan a ser utilizadas, las herramientas y métodos para
el análisis de riesgos, los procesos para la realización de
pentests y análisis de vulnerabilidades, las
herramientas de soporte a la gestión de evidencias y
las herramientas para la generación de informes y de
soporte a la presentación de los resultados de la
auditoría.
Planificación y equipo de trabajo. Describir el equipo
de trabajo de soporte a la auditoría, con los roles y
perfiles requeridos. Incluir, además, los roles que
interactuaran durante la ejecución de la auditoría, bien
a ser entrevistados o a dar soporte.
Cronograma de la auditoría. Identificar los hitos
principales de la auditoría y su cronograma asociado.
Plan de comunicación de la auditoría. Realizar un plan
de comunicación de la auditoría, con la lista de
distribución del informe y las líneas de reporte durante
la planificación y ejecución de la misma.
Identificar las pre-auditorías llevadas a cabo. Hacer un
estudio de todas las auditorías previas que se han
llevado a cabo, tanto en la organización interna como
con los proveedores asociados dentro del alcance de la
auditoría.

Auditoría

Pregunta Limitaciones Respuesta Notas

Descripción del Servicio
Proporcione una descripción del servicio técnico del
servicio en la Nube que ha sido contratado, sin entrar en
mucho más detalle.
Arquitectura del Servicio
¿En qué regiones o países se ha contratado los servicios?
Este apartado es importante con el fin de identificar
problemas regulatorios (no mover datos fuera de la Unión
Europea, por ejemplo).
Proporcionar un diagrama de flujo de datos que ilustre
cómo se procesan los datos a través del servicio.
¿Hay una relación de puertos usados para la entrada y
salida de datos (port matrix)?
¿Existe una lista de riesgos, actualizada recientemente, del
servicio contratado?
¿La contratación del servicio ha pasado por algún proceso
interno de aprobación?
Facilitar ubicación del procedimiento operativo para la
utilización de servicio(s) en la Nube.
Cumplimiento Regulatorio
¿El servicio contratado está bajo alguna actividad
regulatoria (ENS, HIPPA IRAP, C5, etc.)?
Gestión de Activos
Facilitar lista de los diferentes componentes (activos) de
los sistemas en el alcance del servicio contratado
¿Cuál es la frecuencia de las auditorías de configuración?
¿Quién tiene la tarea de realizar estas auditorías de
configuración?
¿Se han registrado todos los activos en un inventario de
activos? Si es así, por favor identifíquelo. ¿Se puede asignar
fácilmente el inventario de activos a los diagramas de
arquitectura de servicio / red?
Facilitar la lista de software dentro del alcance
Gestión de Accesos
¿Existe una lista de accesos?
¿Cómo se gestiona el aprovisionamiento?
¿Qué sistemas se utilizan para la gestión de identidad y
control de acceso? (por ejemplo, LDAP, etc.)
El acceso está centralizado para solicitar acceso a dicho
servicio. ¿Hay algún proceso de aprobación?
Integradores
¿Hay un único proveedor de servicio? En caso de existir
varios, establecer un listado detallado de todas las
empresas involucradas en su conjunto de los servicios
contratados.
También hay que conocer quién está detrás de los centros
de datos en caso de que no pertenezcan al Proveedor de
servicio en cuestión (como suele ser habitual)
¿Existe una arquitectura que contempla todos los servicios
integrados?
¿Tienen acceso a los datos?
Arquitectura del servicio
¿La arquitectura del servicio está documentada en
diagramas de arquitectura de red físicos y / o lógicos que
ilustran los componentes compartidos y dedicados (DNS,
bases de datos y servidores de aplicaciones), proveedores
de conectividad de red / Internet, herramientas de
monitorización, componentes de seguridad principales
(firewalls, IDS, dispositivos de control de acceso)?
Diagrama de red que ilustre cómo se implementa el
servicio en la Nube, incl. Límites de zona / seguridad y
herramientas de administración y vigilancia que se
implementan para ese servicio.
Arquitectura: ¿de un solo inquilino (dedicated) o
multiusuario (multitenant)?
Proporcione detalles sobre qué componentes (incluidas las
herramientas) se comparten entre los clientes en
comparación con los dedicados a un cliente.
Las métricas/limitadores se indican en la descripción del
servicio
¿Las métricas del servicio en la Nube son públicas a través
de algún portal corporativo del SP(s)?
¿Hay algún SLA (Service Level Agreement) acordado con el
SP?
¿Se hace revisión continua de dicho nivel de servicio?
Proceso a seguir en caso de que no se alcance
Resistencia
Describa cómo se implementa la alta disponibilidad (HA,
high availability) en la nueva infraestructura implementada
en la Nube
Integración con otros servicios
En caso de tener un único SP, ¿se pueden contratar los
servicios actuales con otros servicios de otros SPs?
¿Se ha probado el proceso de integración entre varios SPs?
Riesgos identificados de tener varios SPs
Protección de datos
Los datos en movimiento/transito (in transit) se
encuentran cifrados. ¿Qué tipo de cifrado se usa?
¿Los datos en reposo están cifrados?
Si es así, ¿quién controla las claves? ¿Dónde se guardan las
claves?
Seguridad y Operativa
¿Se han escaneado todos los sistemas en busca de
vulnerabilidades y hallazgos remediados?
¿Qué herramienta se utiliza para dicho procedimiento?
¿Se realizan prueba de pen-testing regularmente?
Lecciones aprendidas de dicho proceso.
¿Existe separación de roles en diferentes materias de
operativa del servicio contratado?
Detalle de dicha separación
¿Se han implementado todas las herramientas de
administración y monitorización necesarias para respaldar
las operaciones y la monitorización?
Backup. Copia de Seguridad
Describa la copia de seguridad que se implementa, incl.
qué datos se respaldan, la frecuencia, el almacenamiento
in situ o externo y el período de retención.
¿Las copias de seguridad del servicio están segregadas por
servicio contratado?
¿Hay algún dato del cliente almacenado en algún otro lugar
aparte de la base de datos? Si es así, ¿cómo se respaldan
esos datos?
¿Se realizan restauraciones para probar la integridad de las
copias de seguridad realizadas?
¿Existe algún requisito temporal (cada año, mes) de
cuando llevar a cabo dicha restauración, a modo de
prueba?
¿Quién es la persona, o equipo, responsable de dicho
proceso de restauración?
Gestión del Cambio
Describa cualquier cambio en las prácticas de gestión de
cambios.
 Existe un acuerdo -contractualmente- sobre ventanas de
trabajo (change management scheduling)
Como se gestiona el proceso de gestión del cambio cuando
hay varios SPs
¿Cuál es el proceso de aprobación antes de hacer cambios?
¿Cuál es el proceso de roll-back?
DR. Plan de recuperación en caso de desastres
¿Cuál es la política de DR?
¿Está disponible o es una hoja de ruta establecida por la
empresa?
¿Qué tipo de capacidades de DR están disponibles:
Automatizado, Manual, Hot-standby?
¿El equipo está en escena y pre-aprovisionado en el
emplazamiento de DR, o este tendrá que ser construido
durante la ejecución de un DR?
¿Cuál es la ubicación de las instalaciones del centro de
datos primario y secundario?
¿Qué herramientas de DR se utilizan para replicar datos?
¿Con qué frecuencia se actualizan los procedimientos de
recuperación y plan de DR?
¿Se realiza algún tipo de prueba o ejercicio al respecto,
1
ejemplo, table top exercise ?
¿Se valida integridad de las copias de seguridad durante la
ejecución del plan DR?
RTO -Tiempo Objetivo Recuperación. RTO. Tiempo Recuperación Objetivo
¿Cuál es el RTO establecido?
¿Hay un SLA con el SP al respecto?
¿Cuál es el RPO establecido?
¿Hay un SLA con el SP al respecto?
SLA
¿Existen SLA con el SP?
¿Hay una división de los SLA en función del tipo de servicio
contratado? En este caso por tipo de servicio se hace
referencia a si es un servicio SaaS o IaaS o PaaS
¿Como se mide la disponibilidad? ¿Hay alguna fórmula
para ello?
¿Se supervisan los niveles de disponibilidad de la
infraestructura de servicio como CPU, memoria,

1
Discusiones en las que los miembros del equipo se reúnen de forma informal para analizar sus funciones durante una
emergencia y sus respuestas a una situación de emergencia en particular.
almacenamiento, base de datos, componentes de red y
transacciones? Por favor proporcione detalles.
Terminación del Servicio
¿Existe una política de terminación de servicio?
¿Quién es la persona, o equipo, responsable de dicho
proceso?
¿Se han establecido métricas de terminación de proceso
(tiempo)?
¿Se sabe qué tipo de dados estarán disponibles para la
recuperación?
¿En qué formato estarán disponibles los datos para el
cliente después de la terminación? (Excel, csv ...)
¿Existe alguna herramienta para recuperar los datos o es
un proceso que ejecuta el SP?
¿Hay alguna evidencia de que los datos se eliminan
(incluidos los medios de copia de seguridad) ¿
¿Se utilizan protocolos seguros para transferir datos?
Facilitar detalle de esta.
¿Se conoce de antemano donde van a ir esos datos
originados una vez que el servicio se haya terminado?

Informes. Resultados

Pregunta Limitaciones Respuesta Notas

¿Cuál es el plan de remediación para abordar los
problemas/ debilidades /mejoras / no conformidades
encontradas durante la auditoría?
¿Cuál es el tiempo establecido para implementación
de plan de remediación?
¿El plan de remediación conlleva alguna verificación
posterior?