Introducción: ......................................................................................................... 2
Desarrollo: ............................................................................................................. 4
Pronóstico…Parcialmente nublado… .................................................................. 4 Cloud Computing. ............................................................................................. 4 ¿Que podemos migrar a Cloud Computing?. ................................................... 4 ¿Cuán importante es el activo a migrar? .......................................................... 5 ¿Qué tipo de nube vamos usar para el activo? ............................................... 5 ¿Qué tipo de modelos de servicio de la nube podemos usar? ......................... 6 Los modelos y características de la arquitectura. ............................................. 7
La tormenta…Principales riesgos inherentes a los servicios en la nube.............. 9
El paraguas…nuestro plan de auditoria: ............................................................ 14 Gobierno y Gestión de Riesgos en la Empresa (GGRE) ................................ 16 Aspectos Legales y Contractuales (ALC) ....................................................... 16 Cumplimiento Legal y Auditoria (CLA) ............................................................ 16 Gestión de la Seguridad de la Información y de los Datos (GSID) ................. 17 Portabilidad e Interoperabilidad (PI)................................................................ 17 Seguridad Física, Continuidad de Negocio (SFCNRD)................................... 17 El Centro de Procesamiento de Datos (CPD) ................................................. 18 Tratamiento de Incidentes (TI) ........................................................................ 18 Seguridad de las Aplicaciones (SA) ................................................................ 18 Cifrado y Gestión de Claves (CGC) ................................................................ 18 Gestión de Identidades y de Acceso (GIA) ..................................................... 18 Seguridad de la Virtualización (SV) ................................................................ 18
La lluvia de controles…despliegue de controles por cada sub dominio. ............ 20
Conclusión ........................................................................................................... 34
Caso práctico ....................................................................................................... 36
Bibliografía ........................................................................................................... 58
Reseña del auditor interviniente ........................................................................ 59
Introducción:
El exponencial crecimiento del volumen de datos, así como el consumo de
servicios informáticos, avasallan hoy en día las capacidades de los recursos
tecnológicos, que consecuentemente implican actualizaciones y recambios por
obsolescencia, aumentando exponencialmente el presupuesto destinado a
tecnología de la información.
La posibilidad de aumentar recursos informáticos sin inversión en infraestructura,
la disminución de costos en licencias, instalación, mantenimiento, actualización, y
ahorro energético, así como la facilidad de implementación, la escalabilidad de
almacenamiento y la accesibilidad son algunos de las beneficios que se listan al
momento de pensar el porqué de la utilización de los servicios en la nube;
representan tentativas más que suficientes para que la dirección y las gerencias
involucradas (tecnología, costos, entre otras) estén interesadas en este nuevo
servicio.
¿Qué sucede entonces si la dirección resuelve, en tan solo un par de días, migrar
a la nube el aplicativo para el otorgamiento de créditos sugiriendo la visión y
opinión de auditoria al respecto? ¿Qué riesgos prioritarios deberíamos tener en
cuenta? ¿Qué controles deberíamos considerar?
La intervención del rol auditor/consultor debería formar parte no excluyente, del
proceso de adquisición o cambio, analizando la razonabilidad de riesgos y
controles, retroalimentando a cada gerencia interviniente y a la dirección con su
visión holística.
En el desarrollo del ensayo, desde la óptica del auditor de una entidad financiera,
se listarán los riesgos inherentes a la operatoria en la nube, se propondrán y
explicarán los mitigantes, entendiendo la arquitectura, analizando su entorno de
gobierno y de operaciones; para desenlazar en herramientas ágiles, que le
permitan dar un bosquejo de la situación que a gran escala consiste en la gestión
de software, hardware y personal, a gestionar servicios.
Desarrollo:
Pronóstico: Parcialmente nublado…
Como primera instancia y haciendo alusión al clima se “despejarán” dudas de
conceptos “nublados” necesarios para entender los componentes que integran los
servicios en una nube.
Esquema del entorno Cloud a describir y analizar:
Cloud Computing.
Es un conjunto de recursos de computación cuyo modelo permite acceder de
manera ubicua (a un mismo tiempo de todas partes), y, convenientemente,
contratando solo aquello que se consume.
¿Que podemos migrar a Cloud Computing?
Se pueden migrar o extender a Cloud dos tipos de activos:
� Datos
� Servicios (ejemplo: aplicaciones, funciones, procesos)
¿Cuán importante es el activo a migrar?
Toda Entidad Financiera, que de ahora en más llamaremos EF, debería tener
procedimientos formales para determinar la importancia de sus activos (ej. Matriz
de Calificación de Activos de la Información, Matriz de Análisis de Impacto del
Negocio, Matriz de Riesgo de TI), por tanto, utilizando algunos de los documentos
(que suponemos existentes) generados por estos procedimientos, obtenemos un
bosquejo de la importancia del proceso, operación, función, o dato, que se llevará
a la Cloud.
¿Qué tipo de nube vamos a usar para el activo?
Teniendo entonces conocimientos sobre la importancia del activo a migrar, el paso
siguiente es seleccionar la nube que mejor se adapte a las necesidades de la EF,
según las siguientes opciones:
• Pública: esta infraestructura está a disposición del público, y es propiedad del
Proveedor de Servicios Cloud que da ahora en más llamaremos PSC, en otras
palabras, múltiples organizaciones utilizan no sólo un único conjunto de redes y
máquinas, sino de almacenamiento, procesamiento y gestión de datos
ajustados a las necesidades de cada empresa.
• Privada: Los activos que están en esta nube son operados exclusivamente por
la EF, infiere más confianza y seguridad, es decir, la nube privada no es menos
segura que un centro de datos más grande. Lo que sí cambia son las políticas
y el manejo de la información.
• Comunitaria: La infraestructura de esta nube es compartida por varias
organizaciones y da soporte a una comunidad específica que ha compartido
preocupaciones (por ejemplo, misión, requisitos de seguridad, política o
consideraciones de cumplimiento legal).
• Híbrida: es una composición de dos o más Clouds (privada, comunitaria o
pública).
¿Qué tipo de modelos de servicio de la nube podemos usar?
Las EF pueden utilizar los tres tipos de servicios de la nube:
• Servicio de infraestructura (IaaS): son aquellos que nos facilitan una
infraestructura base, normalmente máquinas virtuales, sobre la que ejecutar
sistemas operativos, servicios y aplicaciones.
• Servicio de plataforma (PaaS): si IaaS nos ofrece equipos (Virtuales o Físicos)
para instalar los sistemas operativos y aplicaciones que quisiéramos, en PaaS
se ofrece directamente un entorno completo sobre el que desarrollar y
desplegar las aplicaciones, por ejemplo los desarrolladores pueden construir
aplicaciones web sin tener que instalar ninguna herramienta adicional en sus
computadoras.
• Servicio de software (SaaS): son las aplicaciones ofrecidas a través de internet
para el uso por varios clientes manteniendo la privacidad de sus datos.
Imaginemos el software de otorgamiento de créditos, en el caso que este
software fuese una aplicación de escritorio normal que instalamos en nuestro
ordenador no sería SaaS, pero imaginemos que este software funciona desde
una página web y estamos pagando una suscripción para acceder al mismo,
en ese caso sería SaaS.
A gran escala podríamos identificar los servicios de IaaS y de PaaS están
orientados a los desarrolladores que busquen una plataforma o infraestructura
sobre la que ejecutar su aplicación. En cambio SaaS está orientado a usuarios
finales.
Los modelos y características de la Arquitectura C loud representados
visualmente.
Habiendo desarrollado las características del servicio, los modelos de servicios y
de despliegue podemos entonces representar los conceptos en el siguiente
modelo visual según NIST (Instituto Nacional de Estándares y Tecnología).
A modo orientativo, de nuestro esquema logramos definir Arquitectura y Cloud:
La tormenta…Principales riesgos inherentes a los se rvicios en la nube.
Se utilizará el siguiente modelo en capas de abstracción, comenzando con la
descripción de riesgos, describiendo los controles mitigantes agrupados por
dominio y subdominio:
En función de la investigación sobre diversas fuentes bibliográficas, de
conocimientos empíricos y de entrevistas realizadas a referentes de tecnología, se
identificaron los siguientes riesgos:
Pérdida de control de gobierno y gestión de riesgos deficiente : Al
utilizar los servicios en la nube, la EF cede el control al PSC de una serie de
cuestiones generando disminuciones en las posibilidades de regular el
diseño, integración y funcionamiento de los órganos de gobierno de la EF,
pudiendo afectar las estrategias de negocio, la seguridad, e impidiendo
identificar y evaluar los riesgos relacionados, entre otros aspectos.
Pérdidas por vacíos contractuales y legales : Este riesgo involucra los
huecos contractuales y legales generados por errores u omisiones en la
descripción de cláusulas, generando la imposibilidad de resolución ante
disputas, pérdidas económicas por omisión de los niveles de servicios
pretendidos, probabilidad de incumplimiento de exigencias regulatorias, la
imposibilidad de auditar dichos mecanismos regularmente por medio de un
auditor independiente, incertidumbre para la cesión, e imposibilidad de
recambio de proveedor entre otros aspectos.
Incumplimiento legal y contractual : Si bien el riesgo anterior contempla
los vacíos contractuales y legales, el incumplimiento hace referencia a la
ausencia de mecanismos, tanto sea certificaciones, auditorías,
seguimientos, que muestren un adecuado encuadre reglamentario,
normativo y control interno, así como la imposibilidad para monitorear y
medir el cumplimiento de los niveles de servicios entre otros aspectos.
Carencia de especificación y nivel de detalle en ma teria de seguridad y
ausencia de participación de los responsables de se guridad en la
confección de los mismos : La falta de mecanismos de control,
organizativos y técnicos, basados en estándares internacionales, la no
utilización de buenas prácticas de mercado, la falta de alineamiento con
nuestras políticas, normas y procesos internos; así como la ausencia de
asignación y participación de los responsables de la Protección de Act. de
la EF dejan expuesta y en velo la integridad, confidencialidad y
disponibilidad.
Imposibilidad de migración a un nuevo PSC o la migr ación de vuelta a
un entorno de tecnologías de la información interno : La falta de
mecanismos y consideraciones para la portabilidad de los servicios en la
nube al momento de contratar un PSC, pueden generar dependencias, e
imposibilidad para la migración de los servicios a pesar de
disconformidades e incumplimientos.
Imposibilidad de incorporar nuevos servicios del mi smo PSC u otros :
La falta de infraestructura por parte del PSC, o tal vez nuevas ofertas, o por
el solo hecho de atomizar servicios, pueden generar limitaciones
funcionales a la EF.
Imposibilidad de restaurar funciones críticas y de sobreponerse a
desastres, así como posibilidad de robos, espionaje , infiltraciones
entre otros daños : El PSC no tiene o no cumple con planes y pruebas que
avalen la continuidad del negocio, así como la posibilidad de recuperación
de desastres generando la imposibilidad de responder a situaciones de
emergencia de manera oportuna. Este riesgo contempla también robos,
daños, etc. por la inexistencia total o parcial de mecanismos de seguridad
física en su centro de datos.
Pérdidas por un inadecuado Centro de Procesamiento de Datos (CPD)
contratado, e inexistencia de responsables claramen te definidos :
La falta de visibilidad de la EF impide el análisis de razonabilidad sobre
distintos aspectos del CPD que consecuentemente genera una deficiente
medición de los riesgos sobre los servicios contratados. El riesgo contempla
también la incertidumbre, demoras, o falta total de respuestas por no prever
los responsables para contactar en caso necesidad.
Pérdidas económicas y de reputación, por no cumplir el PSC con
mecanismos de detección, respuesta, notificación, y remediación de
incidentes: El riesgo hace referencia a las pérdidas económicas y el daño
reputacional por carencia o incumplimiento de políticas, procedimientos y
estrategias que permitan una inmediata resolución y comunicación bilateral
(entre los usuarios de los servicios en la nube, EF, y el PSC), así como la
inadecuada detección, e inefectiva administración de incidentes.
Posibilidad de fraude por incorrecta parametrizació n de seguridad e
inadecuados métodos de desarrollo de aplicaciones, así como
imposibilidad de autogestión por parte de la EF : El riesgo entre otros
aspectos involucra la posibilidad de fraude, intromisiones y vulnerabilidades
por utilización de parametrizaciones por defecto, fallas de seguridad de
aplicativos, malas prácticas de programación, así como el delay en
adecuaciones por dependencia del PSC y por carencia de interfaz de auto
gestión de la EF.
Fallas en la protección de los datos : Carencia o inadecuados
mecanismos de cifrado y fallas en la gestión de claves, entre otros factores,
que generan el inadecuado tratamiento de trasferencia o almacenamiento
de la información confidencial.
Pérdidas económicas y de reputación por acciones ma liciosas de
miembros internos : La operatoria en la nube necesita de ciertas funciones
cuyo perfil de riesgo es muy elevado, un ejemplo son los administradores,
cuyas funciones asignadas otorga la posibilidad de atentar contra los
activos.
Fallo de aislamiento y supresión de datos insegura o incompleta : Este
riesgo considera la multi-prestación o recursos compartidos mediante
virtualización, dejando expuesta la información ante incorrectos
tratamientos que separen el almacenamiento, la memoria, el enrutamiento,
así como la adecuada eliminación.
En nuestro modelo de capas, acabamos entonces de definir los riesgos:
El paraguas…nuestro plan de auditoria:
¿Cómo controlar lo que, por naturaleza, no controlas?
Probablemente no es la primera vez que oímos que simplemente “es una
cuestión de fe”.
En esta oportunidad, dejando la buena fe aparte, mantendremos un sano
escepticismo que nos permita caminar por la delgada línea de evaluador de
control interno y consultor.
Por tanto habiendo incorporado definiciones elementales de la arquitectura en
la nube, podemos entonces abordar los riesgos antes descriptos desde dos
grandes dominios :
Gobierno en el entorno Cloud: se abordan las cuestiones
estratégicas y de políticas.
Las operaciones en el entorno Cloud: se abordan cuestiones
tácticas, de seguridad, y de implementación.
Ya definidos los conceptos de Arquitectura y Cloud, habiendo incorporado las
definiciones de Gobierno y Operaciones, tenemos entonces completo nuestro
esquema:
Además, definimos de nuestro modelo de capas los dominios:
Cada dominio lo dividiremos en sub dominios (basado en el esquema ofrecido por
la CSA- Cloud Security Alliance), y a cada sub dominio le asociaremos controles, a
fin de atacar los riesgos descriptos.
Subdominios:
El gobierno en el entorno Cloud.
1. Gobierno y Gestión de Riesgos en la Empresa (GGRE): en este subdominio
se tratarán principios y normas que regulan el diseño, integración y
funcionamiento de la EF y el PSC, identificando además la capacidad que
se tiene para medir y comunicar el riesgo que introduce la utilización del
servicio.
Se analizarán aspectos como el tratamiento por incumplimientos de
acuerdos, capacidades de los usuarios de la entidad para evaluar el riesgo
de un PSC, y también de establecer las responsabilidades de protección
sobre datos sensibles.
2. Aspectos Legales y Contractuales (ALC): aquí se abordarán los requisitos
contractuales al momento de contratar el servicio, estos pueden ser entre
otros, cláusulas de confidencialidad de la información, mecanismos de
resolución de disputas, exigencias regulatorias de cada país, niveles de
servicios pretendido y mecanismos de seguridad requeridos.
La migración de servicios a Cloud es una forma de externalización, la regla
de oro es “entender por adelantado el contrato y planear como salir de él”,
por tanto la portabilidad (el concepto está definido a continuación en el
punto 5) es un criterio clave a considerar.
3. Cumplimiento Legal y Auditoria (CLA): Se describen pautas de cómo el
PSC podrá mostrar a los auditores de la EF que su organización cumple
con la ley y cláusulas contractuales, así como las capacidades confiables
para el logro de sus objetivos.
4. Gestión de la Seguridad de la Información y de los Datos (GSID): se
abordarán los procedimientos, políticas y mecanismos de comunicación
para entender cómo se usa la información, es decir, como se va a
almacenar, como se va a acceder, quien va a acceder, quien realizará la
custodia, el cifrado para la comunicación, entre otras particularidades.
5. Portabilidad e Interoperabilidad (PI): portabilidad abordara las cuestiones a
tener en cuenta para mover datos/servicios, de un proveedor a otro, o
incluso la vuelta a la EF, interoperabilidad tratará temas como por ejemplo
que tan flexible es el PSC para poder trabajar/operar con otros proveedores
o agregar servicios a los ya existentes,
Las operaciones en el entorno Cloud.
6. Seguridad Física, Continuidad de Negocio y Recuperación de Desastres
(SFCNRD): esta subcategoría tratará los mecanismos de seguridad que la
EF debería considerar al momento de la contratación de un PSC, a fin de
evitar el robo, espionaje, infiltraciones, entre otros daños; así como la
existencia de pruebas de recuperación de desastre y continuidad de
negocio. El cumplimiento de estándares internacionales (como por ejemplo
COSO, COBIT, ISO27001) es inestimable a la hora de evaluar el nivel de
seguridad.
7. El Centro de Procesamiento de Datos (CPD): si bien el acceso al centro de
cómputos de un PSC puede resultar físicamente imposible por parte de los
auditores de la EF para evaluar la arquitectura y las operaciones, en este
punto se considera la posibilidad de realización y la muestra de informes de
auditorías independientes.
8. Tratamiento de Incidentes (TI): en este punto se considerara desde la EF
estrategias del ciclo de vida de incidentes, como la detección, respuesta,
notificación y remediación.
9. Seguridad de las Aplicaciones (SA): son las consideraciones de seguridad
que deberían tener las aplicaciones ante su desarrollo y despliegue, tanto
de la EF como del PSC. Las consideraciones de estándares de seguridad,
guías y proyectos son contempladas en este control (como por ejemplo
OWAS- Open Web Application Security Project).
10. Cifrado y Gestión de Claves (CGC): detalla las buenas prácticas y
mecanismos a tener en cuenta por la EF para determinar qué y cómo la
información necesita ser cifrada, para que la misma sea almacenada y
transmitida de manera segura, así como también los mecanismos de
gestión de claves.
11. Gestión de Identidades y de Acceso (GIA): hace referencia a los
mecanismos de validación de usuarios de la nube (EF y clientes), así como
a la asignación de funciones, al momento de interactuar con la nube.
12. Seguridad de la Virtualización (SV): La virtualización en general simula
mediante programa, una plataforma de hardware autónoma, incluyendo el
sistema operativo completo que se ejecuta como si estuviera instalado en
una máquina física.
Al ser uno de los elementos claves de los servicios en la nube, se deberá
tener en cuenta al momento de la creación a través de software de una
versión de algún recurso tecnológico, de evaluar y perfeccionar entre otros
aspectos, los acuerdos de licencias con los principales proveedores de
entornos virtualizados, además de adaptar las políticas de seguridad a los
desafíos generados por la virtualización.
Ahora estamos aquí:
La lluvia de controles…despliegue de controles por cada sub dominio.
A continuación detallaremos los mitigantes de los riesgos detectados.
Las pruebas así como documental requerido de aplicar el control, pueden
consultarse en el caso práctico, en la columna “Prueba de Control – Comentario”,
del Check List de Controles Cloud Versión 1.0, donde el auditor, sin limitarse a lo
descripto, podría utilizarlo como ejemplo.
Controles:
El gobierno en el entorno Cloud.
1. Gobierno y Gestión de Riesgos en la Empresa (GGR E):
� GGRE1- La EF y el PSC tienen documentado, aprobado y aplicado un
Programa de Gestión de Seguridad de la Información (contemplando política
de seguridad, organización de la seguridad de la información, gestión de
activos, seguridad de los recursos humanos, seguridad física y ambiental,
gestión de comunicaciones y operaciones, control de acceso, adquisición de
sistemas de información , el desarrollo y el mantenimiento) que incluya
medidas de seguridad administrativas, técnicas y físicas para proteger los
activos y los datos de la pérdida, mal uso, acceso no autorizado, revelación,
alteración y destrucción.
� GGRE2- La EF y el PSC adoptan medidas formales para apoyar la seguridad
de la información, estableciendo compromisos documentados (ej.
procedimientos de comunicados internos con conocimiento de nuevas o
actualizaciones normativas, así como la detección de nuevas amenazas).
� GGRE3- La EF realiza revisiones y evaluaciones periódicas (al menos
anualmente) del cumplimiento de las cláusulas contractuales establecidas con
los proveedores Cloud, y el resultado se comunica de manera eficiente y
efectiva en toda la organización.
� GGRE4- El PSC tiene evaluaciones de riesgo formales y periódicas (al menos
anualmente) las mismas son comunicadas y consideradas por la EF.
� GGRE5- Existen, se utilizan y comunican tanto en la EF como el PSC,
políticas disciplinarias o sanción formal para los empleados que han violado
las políticas y procedimientos de seguridad.
� GGRE6- La EF tiene un plan de auditoria de los servicios en la nube, el mismo
se ejecuta periódicamente (mínimo anualmente).
� GGRE7- El PSC ofrece herramientas para medir el cumplimiento de los niveles
de servicios y la eficacia de las operaciones de seguridad a fin de realizar el
seguimiento a nivel corporativo de los servicios en la nube.
� GGRE8- La EF trata aspectos normativos, jurídicos y requisitos legales sobre
los servicios en la Cloud.
� GGRE9- La matriz de riesgo de la EF refleja los riesgos que puede generar la
incorporación de un servicio en la nube (como pueden ser la divulgación de
datos sensibles, el acceso indebido, la perdida de la información, entre otros).
� GGRE10- Los dueños de los activos de la EF definieron la tolerancia al riesgo
del proceso de implementación o migración a la nube habiendo aceptado los
riesgos residuales identificados.
� GGRE11- Desde la EF con los resultados de la evaluación de riesgos se
generan cambios a las políticas de seguridad, procedimientos, estándares y
controles para asegurar que siguen siendo pertinentes y eficaces.
� GGRE12- Desde la EF existen planes de capacitación a las gerencias
involucradas, en el proceso de implementación o migración a la nube, a fin de
mantener el conocimiento y el cumplimiento de las políticas de seguridad,
procedimientos y normas que son relevantes para su área.
2. Aspectos Legales y Contractuales (ALC):
� ALC1- Existe la posibilidad de negociar el contrato de adhesión al servicio en
la nube con el PSC, pudiendo generar adecuaciones o anexos necesarios en el
momento que considere la EF.
� ALC2- La gerencia de Legales interviene en el análisis de las cláusulas del
contrato de adhesión.
� ALC3- El contrato de adhesión considera, posesión, custodia y control de los
datos, así como la conservación, distinguiendo claramente los que están en
posesión de las EF y cuáles no.
� ALC4- En el contrato se consideran aspectos de interoperabilidad y
portabilidad de los servicios existentes en la nube.
� ALC5- El contrato explicita la posibilidad de realizar inspecciones por entes
reguladores a los entornos y aplicaciones cuando así se requiera, o tal vez por
dictamen judicial.
� ALC6- Existen cláusulas de costos del servicio y de almacenamiento, de
acuerdos de nivel de servicio, funcionalidades habilitadas, compromisos de
integridad, de no accesibilidad, y cláusulas típicas de contratos con terceros.
� ALC7- Existen cláusulas de cooperación mutua entre el PSC y la EF, así como
mecanismos de resolución de disputas. (ej: vías de comunicación, roles y
referentes para el tratamiento de incidentes, mecanismos notificación y de
soporte de incidentes, alcance de las actividades de análisis post mortem).
� ALC8- Existen clausulas exclusivas de transparencia y comunicación de
incidentes (por ejemplo un portal donde se comunique incidentes de seguridad
ocurridos, los canales disponibles comunicación, la posibilidad de un canal
rápido y bilateral).
� ALC9- El contrato contempla que el PSC llevará a cabo evaluaciones internas
y externas anuales para determinar la eficacia de sus políticas y
procedimientos.
� ALC10- La asignación de responsabilidades de cumplimiento legal entre el
PSC y la EF, incluye proveedores indirectos (por ejemplo, el proveedor del
proveedor de Cloud).
� ALC11- Al momento de la expiración del contrato, o cualquier otra razón, existe
cláusula que describa la responsabilidad y las herramientas para la
destrucción total de datos, así como claves (por ejemplo los mecanismos y
software utilizados para la eliminación, la posibilidad de destrucción física de
cintas y mecanismos de respaldo).
3. Cumplimiento Legal y Auditoria (CLA):
� CLA1- El PSC dispone periódicamente (anualmente o a demanda de la EF)
documentación que muestre su transparencia y encuadre en el cumplimiento
legal.
� CLA2- La EF en su plan de auditoria contempla los procedimientos para
asegurar la revisión constante de acuerdos de servicios, además de la eficacia
de la gestión de seguridad y el encuadre legal.
� CLA3- Los planes de auditoría ejecutados se tratan y comunican a los altos
estamentos involucrados de la EF y en caso de requerirlo al PSC para que
accione sobre las oportunidades de mejoras o deficiencia.
� CLA4- El PSC posee, entrega o dispone a la EF de planes de auditoria
definidos en el control ALC9.
� CLA5- El PSC posee certificaciones de terceros (ejemplo ISAE 3402, SOC2,
SSAE16, ISO27001).
� CLA6- El proveedor ofrece herramientas y la posibilidad de análisis de pistas
de auditoría.
4. Gestión de la Información y Seguridad de los Dat os (GISD):
� GISD1- La EF posee y utiliza políticas, procedimientos, medidas técnicas, y las
herramientas disponibles por el PSC, para realizar el monitoreo de quien
accede a los servicios, funciones habilitadas, localización de los datos,
prevención y detección de migraciones de grandes volúmenes de información.
� GISD2- La EF y el PSC tienen políticas y procedimientos para la manipulación,
la seguridad de los datos y objetos, que contienen datos existentes en la nube.
� GISD3- La EF tiene políticas y procedimientos para la eliminación segura y una
retirada completa de datos de todos los medios de almacenamiento,
asegurando que los datos no son recuperables por cualquier medio en
informática forense.
� GISD4- El PSC dispone de un modelo documentado, para entender políticas y
procedimientos de cómo se usa la información y como se gobierna su uso.
� GISD5- Se conoce la arquitectura y las técnicas de almacenamiento de los
datos ofrecida por el PSC.
� GISD6- El PSC utiliza mecanismos que avalen un adecuado ciclo de vida de
seguridad de los datos (creación, guardado, uso, compartir, archivar,
destrucción).
� GISD7- El proveedor ofrece mecanismos de cifrado de la información
reconocidos a nivel mundial.
5. Portabilidad e Interoperabilidad (PI):
� PI1- Existen políticas y procedimientos mutuamente acordados y disposiciones
establecidas para satisfacer los requerimientos de la EF.
� PI2- El PSC ofrece estándares y documentos a la EF con detalles para la
importación/exportación de datos y para la gestión del servicio.
� PI3- Existe la posibilidad de solicitar servicios adicionales (interoperabilidad) de
manera ágil al PSC (ejemplo: incorporar más hardware si se necesita más
procesamiento, solicitar más espacio de almacenamiento).
� PI4- Existe una estrategia para migrar (portabilidad) todos los servicios de
manera ágil por parte del PSC (ejemplo: reemplazados por nuevos o distintos
componentes, e incluso diferentes proveedores de forma transparente para la
EF).
Las operaciones en el entorno Cloud.
6. Seguridad Física, Continuidad de Negocio y Recup eración de Desastres
(SFCNRD):
� SFCNRD1- El PSC combina defensas activas (monitorización CCTV,
verificación de credenciales de empleados, control de visitantes en las
instalaciones, mantenimiento) y pasivas (capacitaciones, políticas y
procedimientos) para enfrentar amenazas físicas a la infraestructura, al
personal y a los distintos sistemas.
� SFCNRD2- El PSC realiza estudios de protección física por daños naturales y
desastres, para determinar los peligros sobre sus activos y el personal
(ejemplo incendios, inundaciones , descargas eléctricas atmosféricas , solar
inducida tormenta geomagnética , viento , terremotos , tsunamis , explosiones ,
accidentes nucleares , actividad volcánica, riesgo biológico , disturbios civiles ,
la actividad tectónica , y otros tipos de catástrofes naturales) aplicando las
contra medidas necesarias.
� SFCNRD3- Para reducir los riesgos de las amenazas ambientales, los peligros
y las oportunidades de acceso no autorizado, los equipos del PSC se
mantienen alejado de lugares expuestos a riesgos ambientales de alta
probabilidad y complementados con equipos redundantes situado a una
distancia razonable.
� SFCNRD4- Existe un marco unificado y coherente para la planificación de la
continuidad del negocio y recuperación de desastre, así como pruebas
periódicas (mínimo anual tanto para la EF como para el PSC).
� SFCNRD5- Tanto la EF como el PSC disponen de políticas y procedimientos
que describa el personal de apoyo para actuar en contingencia, con
descripción de funciones y roles.
� SFCNRD6- La EF dispone de método definido y documentado para determinar
el impacto de cualquier interrupción de los servicios en la nube que identifique
los productos y servicios críticos, periodo máximo tolerable, prioridades de
recuperación, tiempos, estimación de recursos para la reanudación.
� SFCNRD7- El PSC dispone de documentación del sistema de información (por
ejemplo, guías de administrador y usuario, y diagramas de arquitectura) que
pondrá a disposición del personal autorizado de la EF para que pueda realizar
el análisis que considere.
� SFCNRD8- El PSC realiza certificaciones y capacitaciones al personal acordes
a sus funciones, que avalen adecuado entrenamiento en la seguridad del
entorno.
� SFCNRD9- Existe la posibilidad de realizar inspección ocular a las
instalaciones del PSC por parte de la auditoria interna de la EF.
7. El Centro de Procesamiento de Datos (CPD):
� CPD1- Existe en la EF conceptos claros y documentos de quienes son los
responsables del CPD y las vías de comunicación del PSC.
� CPD2- Existen informes periódicos de auditorías y de seguridad sobre el CPD
del PSC con publicación de los resultados para que dispongan de ellos la EF.
� CPD3- El PSC tiene políticas y procedimientos para requerir autorización o
informar a la EF, antes de la reubicación o transferencia de hardware, software
o datos.
� CPD4- Existen por parte del PSC políticas y procedimientos para la eliminación
segura de los equipos.
8. Tratamiento de Incidentes (TI):
� TI1- Existen puntos de contacto claramente definidos tanto en la EF como en el
PSC para dar tratamiento inmediato.
� TI2- El PSC tiene capacidades de detección de incidentes de seguridad, de
análisis, de contención y de recuperación entre otras cuestiones clave.
� TI3- La EF tiene/elabora estrategias para la adecuada ejecución del ciclo de
vida de respuesta ante incidentes de los servicios en la nube.
� TI4- El PSC proporciona asistencias y herramientas para ejecutar las
estrategias del ciclo de vida de respuesta ante incidentes.
� TI5- La EF cuenta con representantes de su departamento legal en el equipo
de respuesta ante incidentes, para proporcionar orientación respecto de que
los datos de los clientes crucen fronteras geográficas y legales sin el
consentimiento de los mismos.
� TI6- La EF tiene herramientas y procedimientos para identificar las clases de
incidentes sucedidos en el PSC.
� TI7- El PSC brinda mecanismos que se ponen en marcha para monitorear y
cuantificar los tipos, volúmenes y costos de los incidentes de seguridad de la
información.
� TI8- El PSC brinda informes de Incidentes que incluyan la línea de tiempo del
incidente, el análisis de la causa raíz o vulnerabilidad, las medidas adoptadas
para mitigar los problemas y restaurar el servicio, además de recomendaciones
a largo plazo para una acción preventiva.
� TI9- La EF cuenta con logs a fin de cubrir sus necesidades en el tiempo, para
asegurar que cumple con sus requisitos de análisis de incidentes / forenses.
� TI10- Anualmente se realizan pruebas de revisión del plan de respuesta ante
incidentes con personal de la EF y del PSC.
� TI11- Existen tanto en la EF como en el PSC procedimientos forenses
adecuados, incluyendo la cadena de custodia, a fin de generar pruebas
legalmente permisibles.
9. Seguridad de las Aplicaciones (SA):
� SA1- La EF y el PSC tiene políticas y procedimientos para establecer y
mantener la seguridad de los aplicativos a través de múltiples desarrollos e
interfaces del sistema, para evitar la divulgación indebida, alteración o
destrucción.
� SA2- Tanto el PSC como la EF, desarrollan aplicaciones bajo marcos de
referencias de software seguro, se utilizan procedimientos y patrones (ej:
OWASP-Open Web Aplication Security Proyect) reduciendo la posibilidad
amenazas.
� SA3- El PSC realiza un análisis de riesgos de las aplicaciones en lo relativo a
la privacidad y la seguridad (confidencialidad, integridad y disponibilidad),
construyendo y manteniendo modelos de amenazas.
� SA4- El PSC tiene informes periódicos sobre las amenazas en el entorno
Cloud con análisis de impacto.
� SA5- Existe una traza e integridad por parte del PSC entre las amenazas y los
riesgos contra las soluciones y garantías.
� SA6- Se realizan test de intrusión de aplicaciones web con regularidad y
bilateralmente (PSC y la EF).
� SA7- Existe la posibilidad de auditar y verificar los procesos de gestión de la
configuración y del cambio al PSC.
� SA8- Las aplicaciones Cloud son ampliamente accesibles a través de varios
dispositivos, el PSC emplea la posibilidad de autenticaciones fuertes, además
de las simples utilizadas como lo son usuario y contraseña (Token RSA, OTP
sobre SMS o teléfono, Smartcard/PKI, biometría).
10. Cifrado y Gestión de Claves (CGC):
� CGC1- En la EF y en el PSC existen políticas y procedimientos para la gestión
de claves criptográficas.
� CGC2- La EF gestiona sus propias claves de cifrado.
� CGC3- Los propietarios de las claves de cifrado están claramente identificados.
� CGC4- El PSC utiliza las mejores prácticas de gestión de claves, para la
emisión, renovación y revocación de las mismas.
� CGC5- Los usuarios de la EF siguen un proceso de registros para disponer de
acceso a las operaciones de cifrado.
� CGC6- El PSC utiliza mecanismos de encripción no obsoletos (no utilizar los ya
obsoletos DES, 3DES).
� CGC7- El PSC utiliza mecanismos de cifrados conocidos (no inventados, ni
técnicas propias), que consiste en la codificación de los datos mediante claves
tanto para el almacenamiento (disco), uso (memoria) y transferencia
(mensajería electrónica).
� CGC8- El PSC utiliza a su vez tecnología de proveedores confiables.
11. Gestión de Identidades y de Acceso (GIA):
� GIA1- En la EF como el PSC existen políticas y procedimientos de acceso de
usuarios internos, corporativos y de clientes, donde se establezca por ejemplo
reglas de mínimo privilegio, factores múltiples de autenticación, cumplimiento
reglamentario y estatutario.
� GIA2- Tanto la EF como el PSC tienen políticas y procedimientos para
almacenar y gestionar la información de identidad sobre cada persona que
accede a la infraestructura de TI y para determinar su nivel de acceso.
� GIA3- Existen definidos servicio de identidad en la nube para cubrir la gestión
de la misma, así como la asignación de derechos y la gestión de
Autorización/Acceso a Cloud.
12. Infraestructura y Virtualización (VI):
� VI1- El PSC y la EF tienen políticas y procedimientos para evitar las
parametrizaciones por defecto. Cada sistema operativo se parametriza para
proporcionar sólo los puertos, protocolos y servicios que se van a utilizar para
satisfacer las necesidades del negocio.
� VI2- El PSC tiene diagramas de la arquitectura identificando con claridad los
entornos de alto riesgo y los flujos de datos que pueden tener impactos de
cumplimiento legal.
� VI3- El PSC garantiza contractualmente la integridad de todas las imágenes de
máquinas virtuales en todo momento.
� VI4- El PSC tiene políticas, procedimientos, y utiliza tecnología de seguridad de
Firewalls e IDS/IPS para asegurar el aislamiento y protección de las máquinas
virtuales.
� VI5- Todos los cambios realizados en las máquinas virtuales (reseteado,
apagado, movimientos lógicos) están registrado y generan alertas a los
referentes de la EF.
� VI6- La EF cuenta con soluciones de cifrado en todo momento sobre las
máquinas virtuales.
� VI7- El PSC tiene implementados mecanismos de reporte que ofrecen pruebas
del aislamiento y alertas en caso de violación del aislamiento.
� VI8- El PSC brinda garantía sobre la información en los servidores físicos o
máquina virtual no podrá ser recuperada.
A modo orientativo en nuestro modelo de capas, acabamos de describir la capa de
controles:
Como resultado de la investigación de riesgos y controles se plasmarán los
resultados en las siguientes matrices a fin de ser aplicadas de manera ágil por el
auditor: Check-List de Controles Cloud Versión 1.0; Matriz de Riesgos Cloud
Versión 1.0 y Mapa de Riesgos Cloud Versión 1.0.
La estructura de las herramientas y su utilización pueden verse en el caso práctico
adjunto a posteriori de la conclusión.
Conclusión:
En el desarrollo del ensayo se identificaron los riesgos de poseer un servicio en la
nube, y una batería de controles mitigantes consolidados en una lista aplicada a
un caso práctico, junto a una matriz que permitirá medir la probabilidad y el
impacto por la ausencia de ellos, para brindar apoyo a los sectores involucrados, e
incluso determinar la viabilidad del servicio en la nube.
Una pregunta que desafía al lector ¿Corresponde al auditor interno elaborar la
matriz y el mapa de riesgos?
Probablemente no, y convergeremos que la respuesta es la evaluación del control
interno, no obstante, cuando hablamos del “auditor interno” aún puede venirnos a
la mente la imagen de un señor serio, grismente trajeado, con poco interés por el
negocio, con una mirada acotada a buscar errores o ineficiencias, para resaltarlos.
Pero eso ya no refleja la realidad actual de los profesionales de Auditoría Interna.
En la actualidad, esta especialización resulta altamente atractiva para
profesionales que desean conocer la variedad de procesos que suceden en una
organización, analizando y aportando una mirada desde otro lugar sobre
situaciones cotidianas y sobre temas estratégicos. El auditor ha asumido el
desafiante rol de “Consultor”.
Haciendo una última alusión al clima, podríamos decir que partiendo de conceptos
nublados, transitando por una tormenta de riesgos que consecuentemente
desenlaza una lluvia de controles, utilizando como paraguas el plan de auditoria...
podemos concluir finalmente, que el proceso es solo una tormenta más a la cual
haciendo frente con profesionalismo redundará en el éxito del tratamiento de la
problemática.
Caso práctico :
Si bien el caso práctico resulta de un extracto sobre una situación real, en el
desarrollo del mismo plantearemos situaciones hipotéticas, a fin de preservar
confidencialidad y a su vez ser más gráficamente representativo.
Trataremos la situación según las bases teóricas aprendidas, en donde la EF, con
interés del sector de Tecnología Informática por la posibilidad de disponer de
manera casi inmediata de la información en las cintas de backup, sustentado por
el análisis de costos realizados por la gerencia de compras, planea utilizar los
servicios de la nube para gestionar el almacenamiento secundario.
La Dirección solicita la intervención de auditoria interna para el análisis de
razonabilidad del procedimiento, proveedor e información a migrar.
Por lo cual se realiza el siguiente despliegue de controles y análisis de riesgos:
Matriz de Riesgos Cloud Versión 1.0
Riesgo Evaluación Tratamiento del Riesgo
Riesgo Inherente Mitigantes Descripción del Riesgo Residual
P I
Tipo de Respuesta al Riesgo Residual
Plan de Acción Responsable Fecha Compromiso
Estado
1 Pérdida de gobierno y gestión de riesgos deficiente
GGRE1, GGRE2, GGRE3, GGRE4, GGRE5, GGRE6, GGRE7, GGRE8, GGRE9, GGRE10, GGRE11, GGRE12.
No se identifica riesgo residual.
2 5 Aceptar Sin acciones pendientes
2 Pérdidas por vacíos contractuales y legales
ALC1, ALC2, ALC3, ALC4, ALC5, ALC6, ALC7, ALC8, ALC9, ALC10, ALC11.
No se identifica riesgo residual.
2 5 Aceptar Sin acciones pendientes
3 Incumplimiento legal y contractual
CLA1, CLA2, CLA3, CLA4, CLA5, CLA6.
Falta de control sobre los acuerdos establecidos e incumplimientos contractuales. Falta de la razonabilidad para evaluar los sistemas y procedimientos de uso en una empresa, con el propósito de determinar si su diseño y aplicación son correctos; y comprobar el sistema de procesamiento de información como parte de la evaluación de control interno; así como para identificar aspectos
3 5 Tratar Si bien la EF no cuenta con un procedimiento que describa como realizar la medición de los niveles de servicios del PSC contra los establecidos en el contrato, se está analizando con los referentes de Tecnología Informática el armado del mismo.
Gerencia de Tecnología
Informática y Gerencia de
Auditoria Interna
1/6/2016 Pendiente
P es la probabilidad de ocurrencia, el rango posible es de 1 a 5, donde 1 indica la menor de las probabilidades.
I corresponde al impacto, el rango posible es de 1 a 5, donde 1 indica el menor impacto.
Matriz de Riesgos Cloud Versión 1.0
Riesgo Evaluación Tratamiento del Riesgo
Riesgo Inherente Mitigantes Descripción del Riesgo Residual
P I
Tipo de Respuesta al Riesgo Residual
Plan de Acción Responsable Fecha Compromiso
Estado
4 Carencia de especificación y nivel de detalle en materia de seguridad y ausencia de participación de los responsables de seguridad en la confección de los mismos
GISD1, GISD2, GISD3, GISD4, GISD5, GISD6, GISD7.
No se identifica riesgo residual.
4 5 Aceptar Sin acciones pendientes
5 Imposibilidad de migración a un nuevo proveedor o imposibilidad para volver a un entorno interno. Imposibilidad de incorporar servicios, del mismos u otro PSC
PI1, PI2, PI3, PI4. No se identifica riesgo residual.
2 4 Aceptar Sin acciones pendientes
6 Imposibilidad para restaurar funciones críticas, y de sobreponerse a desastres, así como robo, espionaje, infiltraciones
SFCNRD1, SFCNRD2, SFCNRD3, SFCNRD4, SFCNRD5, SFCNRD6, SFCNRD7, SFCNRD8, SFCNRD9.
No se identifica riesgo residual.
2 5 Aceptar Sin acciones pendientes
Matriz de Riesgos Cloud Versión 1.0
Riesgo Evaluación Tratamiento del Riesgo
Riesgo Inherente Mitigantes Descripción del Riesgo Residual
P I
Tipo de Respuesta al Riesgo Residual
Plan de Acción Responsable Fecha Compromiso
Estado
7 Pérdidas por un inadecuado Centro de Procesamiento de Datos contratado, no existen responsables claramente definidos
CPD1, CPD2, CPD3, CPD4.
No se identifica riesgo residual.
2 4 Aceptar Sin acciones pendientes
8 Pérdidas económicas y de reputación, por no cumplir el PSC con mecanismos de detección, respuesta, notificación, y remediación de incidentes
TI1, TI2, TI3, TI4, TI5, TI6, TI7, TI8, TI9, TI10, TI11.
Desconocimiento de los incidentes sucedidos, tanto en la EF como en el PSC, probabilidad de pérdidas económicas y reputacionales por detección tardía.
4 5 Tratar Se realizan reuniones junto a los referentes de la gerencia de tecnología y sistemas de la EF y del PSC a fin de determinar la periodicidad de revisión y evaluación del plan de respuesta de incidentes, así como los responsables involucrados. Se incluirán dentro de los responsables, referentes del sector de legales para el tratamiento de incidentes.
Gerencia de Tecnología Informática
17/4/2016 Pendiente
Matriz de Riesgos Cloud Versión 1.0
Riesgo Evaluación Tratamiento del Riesgo
Riesgo Inherente Mitigantes Descripción del Riesgo Residual
P I
Tipo de Respuesta al Riesgo Residual
Plan de Acción Responsable Fecha Compromiso
Estado
9 Posibilidad de fraude por incorrecta parametrización de seguridad e inadecuados métodos de desarrollo de aplicaciones, así como imposibilidad de autogestión por parte de la EF.
SA1, SA2, SA3, SA4, SA5, SA6, SA7, SA8.
No se identifica riesgo residual.
2 5 Aceptar Sin acciones pendientes
10 Fallas en la protección de los datos
CGC1, CGC2, CGC3, CGC4, CGC5, CGC6, CGC7, CGC8.
No se identifica riesgo residual.
2 5 Aceptar Sin acciones pendientes
11 Pérdidas económicas y de reputación por acciones maliciosas de miembros internos
GIA1, GIA2, GIA3. No se identifica riesgo residual.
1 5 Aceptar Sin acciones pendientes
12 Fallo de aislamiento y supresión de datos insegura o incompleta
VI1, VI2, VI3, VI4, VI5, VI6, VI7, VI8.
No se identifica riesgo residual.
2 4 Aceptar Sin acciones pendientes
Mapeo de riesgos Versión 1.0:
5 11 1; 2; 6; 9; 10 3 4 ; 8
4 5; 7; 12
3
2
1
1 2 3 4 5
Impa
cto
Probabilidad de Ocurrencia
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
Pérdida de gobierno y gestión de riesgos
deficiente
GGRE1 ����
Tanto la EF como el PSC cuentan con un programa de gestión de
seguridad, aprobados por directorio en las
correspondientes actas, con conocimiento y tratamiento por cada una de las gerencias
involucradas. Se dio vista a documentación con
las políticas, procedimientos y con registros de cambios al
momento del control.
GGRE2 ����
Las políticas, procedimientos son comunicados y tratados en
ambas organizaciones (EF y PSC),
mediante reuniones de comité, registrando en sus
correspondientes actas, las reuniones establecidas con
periodicidad mensual para le EF, y periodicidad bimestral para el
PSC, existen además mecanismos internos de
comunicación (intranet y correo electrónico interno).
Vistos actas, comunicados de adecuaciones normativas, comunicado de políticas y
procedimientos
GGRE3 ����
Existe la posibilidad de monitorización constante por
parte de referentes de TI mediante de los servicios en la nube, se verificaron además,
fuertes lazos de comunicación entre el PSC y la EF
(Teléfonos de referentes, correos electrónicos, asistencia presencial
y asistencia remota) que permiten realizar consultas
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
en caso de urgencias o desfasajes en mediciones y
revisiones.
GGRE4 ����
El PSC tiene evaluaciones de riesgos anuales,
las mismas quedan disponibles para ser descargada del sitio web
del proveedor, por los referentes de la EF que se
indican en el contrato.
GGRE5 ����
Existen procedimientos en ambas organizaciones para una
adecuada utilización de los recursos, y las medidas
disciplinarias a cursar por su incumplimiento.
Tanto la EF como el PSC los comunican a su personal
mediante cursos audiovisuales interactivos el debido uso de
recursos.
GGRE6 ����
Existen planes de auditoria definidos.
GGRE7 ����
Existen en la EF procedimientos y mecanismos de comunicación,
herramientas, y reuniones determinadas en una periodicidad mensual para medir los niveles de
servicios, recursos de procesamiento utilizados, almacenamiento disponible, ancho de banda
consumido, etc.
GGRE8 ����
Existen procedimientos y mecanismos para tratar aspectos
normativos, jurídicos y requisitos legales así como periodicidad definida de
revisión por parte de la EF.
Pérdida de gobierno y gestión de riesgos
deficiente
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
GGRE9 ����
Los resultados de los riesgos informados por el PSC, son
analizados, considerados y reflejados en la
matriz de riesgo de la EF.
GGRE10 ����
Existen definidos mecanismos de comunicación a nivel
organizacional del procedimiento que describe el
apetito de los riesgos. Existe procedimiento en la EF definidos
para tratar y comunicar los riesgos residuales que se
detecten.
GGRE11 ����
En función del análisis de riesgos provistos por el PSC,
de la adecuación de la matriz de riesgo de la EF,
se verificaron procedimientos y mecanismos de acción como
consecuencia de la actualización de los mismos.
GGRE12 ����
Existen planes de capacitación adecuados sobre la tecnología a
contratar para los distintos referentes
involucrados.
Pérdida por vacíos contractuales y legales
ALC1 ����
Existen referentes en la EF, encargados de analizar y
negociar las distintas cláusulas del contrato con el PSC.
ALC2 ����
Existen referentes de la EF del sector de Legales
involucrados en la contratación del servicio.
ALC3 ����
El contrato detalla en sus diferentes cláusulas quien va a
realizar la custodia, y control de los datos, la
integridad de las máquinas virtuales.
Pérdida de gobierno y gestión de riesgos
deficiente
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
ALC4 ����
El contrato considera cláusulas que permiten agregar servicios
adicionales, inter operar con otros
proveedores, así como la posibilidad de mudar los servicios de manera completa, y detalla que cualquier cambio en la infraestructura física que afecte
los servicios de la EF debe ser informado,
tanto sea en caso de reubicación, transferencias, agregados, etc.
ALC5 ����
Visto cláusulas donde se contempla la posibilidad
de realizar inspecciones por entes reguladores.
ALC6 ����
Existen clausulas sobre los niveles de servicio pretendido
y las funciones requeridas están claramente definidas.
ALC7 ����
En el contrato se detallan los mecanismos y responsabilidades para la cooperación entre la EF y
el PSC así como para la comunicación
entre los mismos.
ALC8 ����
El contrato contempla el tratamiento de los incidentes,
así como mecanismos de comunicación bilateral en caso de
ocurrencia.
ALC9 ����
Se describen en el contrato el compromiso
por parte del PSC a realizar anualmente revisiones,
ya sean a cargo de su auditoria interna
o por entidades reconocidas.
ALC10 ����
En el contrato el PSC asume responsabilidad
directa sobre los servicios que el subcontrata.
Pérdida por vacíos contractuales y legales E
l gob
iern
o
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
ALC11 ����
El PSC es el responsable de la eliminación
de la información que involucran los servicios contratados,
en caso de así requerirlo la EF.
Incumplimiento legal y contractual
CLA1 ����
Se verificó en el sitio web del PSC información actualizada de balances, referentes, misión y visión, entre otros aspectos.
Además la EF recibió la documentación que respalda y avala la transparencia del PSC
(trayectoria del PSC, referencias de clientes, referencias internas,
inexistencias de sanciones legales,
análisis de deudor sobre los referentes y el titular responsable del servicio, premios de calidad,
entre otros).
CLA2 ����
Si bien se cumplen los controles
GGRE6 y GGRE7, el plan no contempla un procedimiento que
permita medir los niveles de servicios requeridos.
La adecuación se contempla en la Matriz de Riesgo Cloud Versión
1.0 con su respectivo Plan de Acción.
CLA3 ����
Existen mecanismos (referentes explícitos en el contrato,
teléfonos, correos) con el PSC para comunicar las medidas
resueltas por las auditorías de la EF.
CLA4 ����
Se dio vista a los últimos informes disponibles de las auditorías
realizadas al PSC.
CLA5 ����
Se dio vista en el sitio web del PSC de las certificaciones de
calidad y de seguridad (ISO 9001, ISO
Pérdida por vacíos contractuales y legales
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
27001).
CLA6 ����
Se verificaron programas, y mecanismos por parte del PSC
para actuar en caso de requerimiento legal,
proceso de investigación o análisis de actividades (ej. log de
usuarios, fecha, acción realizada), así como procedimientos
disponibles en la EF.
Carencia de especificación y nivel de detalle en
materia de seguridad y ausencia de participación de los responsables de
seguridad en la confección de los mismos
GISD1 ����
El PSC dispone a la EF de herramientas y personal idóneo
para realizar el monitoreo de acceso a las interfaces del
sistema administrador, así como procedimientos de seguridad. Se
complementa con GGRE1.
GISD2 ����
Se dio vista a las políticas, procedimientos y técnicas
utilizadas para la manipulación de los datos.
GISD3 ����
Se dio vista a las políticas y procedimientos con las
consideraciones para el borrado de los datos.
GISD4 ����
El PSC presentó a la EF su organigrama,
sus funciones asociadas y referentes.
GISD5 ����
El PSC nos proveyó de documentación técnica
que avala los mecanismos y técnicas de almacenamiento.
GISD6 ����
El PSC mostró certificaciones en seguridad de la información,
certificación ISO 27001 para el último año.
GISD7 ����
Existe documentación que describen
los mecanismos de cifrado utilizados por el PSC.
Incumplimiento legal y contractual
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
Imposibilidad de migración a un nuevo PSC o de
migración de vuelta a un entorno de tecnología de la
información interno. Imposibilidad de incorporar nuevos servicios del mismo
PSC u otros.
PI1 ����
Se verificaron las cláusulas contractuales considerando la
portabilidad e interoperabilidad de los servicios contratados.
PI2 ����
Existen estándares en la EF provistos por el PSC
que detallan las características técnicas (Importación,
Exportación).
PI3 ����
Existen aplicativos e instructivos que permiten la autogestión de la
EF, activando o desactivando
recursos según se requiera.
PI4 ���� Aplica el control PI1.
Imposibilidad para restaurar funciones críticas,
y de sobreponerse a desastres, así como robo, espionaje, infiltraciones
Las
oper
acio
nes
SFCNRD1 ����
Se dio vista a las instalaciones del PSC,
verificándose monitorización, guardias de seguridad, cercos perimetrales, mecanismos de
credenciales, entre otros factores de seguridad.
SFCNRD2 ����
El PSC mostró certificaciones en seguridad de la información,
certificación ISO 27001 para el último año.
SFCNRD3 ����
Se verificó visualmente y mediante tecnologías
de GPS, la ubicación física de las instalaciones del PSC
analizando su razonabilidad, teniendo en cuenta reportes
climáticos y últimos desastres naturales
ocurridos en la zona. Se comprobó la existencia por parte del PSC de un centro alternativo
de procesamiento.
El g
obie
rno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
SFCNRD4 ����
Se verificó por parte del PSC la existencia de informes
de DRP y Plan de Continuidad de Negocio.
SFCNRD5 ����
Se verificó la existencia de responsables y funciones,
tanto en la EF como en el PSC que actúen en caso contingencia.
SFCNRD6 ����
Se verificaron los tiempos de recuperación
en la última DRP (Prueba de Recuperación de Desastres)
entregado a la EF.
SFCNRD7 ����
Se entregó documentación técnica
sobre la estructura contratada, por parte del PSC.
SFCNRD8 ����
La certificación ISO 27001, ya mencionada, aplica en este
punto.
SFCNRD9 ����
Se realizan las pruebas periódicamente
sobre los controles previamente descriptos.
Pérdidas por un inadecuado Centro de
Procesamiento de Datos contratado, no existen
responsables claramente definidos.
CPD1 ����
Se utilizó el contrato marco de adhesión de servicio
para describir los responsables del CPD
y las vías de comunicación del PSC.
CPD2 ����
Si bien existe la certificación ISO 27001,
existen informes anuales disponibles por parte del PSC de
su auditoria interna, para ser consultados por
referentes de la EF.
CPD3 ����
Existe definido contractualmente en el control antes citado ALC4.
Las
oper
acio
nes
Imposibilidad para restaurar funciones
críticas, y de sobreponerse a
desastres, así como robo, espionaje,
infiltraciones
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
CPD4 ����
Existe definido contractualmente en el control antes citado ALC11.
Pérdida económica y reputacional dado que el
PSC no cumple con mecanismos de detección,
respuesta, notificación y remediación de incidentes.
TI1 ����
Tanto en la EF como en el PSC existen puntos de contacto para tratar incidentes de seguridad, se dio vista en el sitio web del PSC teléfonos de atención las
24hs. Internamente se explicitó en el
contrato los contactos de referencia ALC8
TI2 ����
El PSC nos proveyó los últimos informes correspondientes a los
test de penetración (pen test) realizados,
informe y tratamiento realizados por los IDS/IPS.
TI3 ����
No se dio vista al procedimiento interno
de la EF para el tratamiento de incidentes Cloud.
Se contempla en la Matriz de Riesgo Cloud Versión 1.0
con su respectivo plan de acción.
TI4 ����
Si bien no existe procedimiento interno formalizado (según lo
visto en TI3), existe compromiso en el plan de acción para considerar la inclusión de
referentes de legales.
TI5 ����
Dentro del procedimiento interno antes descripto (TI3)
se dio vista al referente del sector de Legales.
TI6 ����
Se dio vista a las herramientas software provistas por el PSC
para detectar incidentes unilateralmente
y de manera pro activa (ej.: log de ejecuciones, inicio y finalización de tareas, datos corruptos, etc.). Visto manual de usuario en TI4.
Las
oper
acio
nes
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
TI7 ����
La detección descripta en el control TI6,
se complementa con un monitoreo continuo de detección
ante cambios de hardware, grandes movimientos de volúmenes de datos no autorizados, entre otros
monitoreos.
TI8 ����
Se dio vista a informes de incidentes generados desde el
PSC.
TI9 ����
Existen y se dio vista a herramientas informáticas
que permiten realizar el análisis forense en caso de requerirlo la
EF, con detalles de usuario que
intervino, hora, tipo de acceso, etc.
TI10 ����
Se consideró en el CLA2 la periodicidad al momento de
definir el plan de AI.
TI11 ����
La certificación ISO 27001, ya mencionada,
aplica en este punto, considerando un adecuado
tratamiento de la información. Para la gestión unilateral por parte de la EF, se verificaron
procedimientos internos actualizados.
SA1 ����
Existe documentación y patrones UML (Lenguaje Unificado de
Modelado) que avalan un adecuado
desarrollo de aplicaciones por parte del PSC.
Las
oper
acio
nes
Pérdida económica y reputacional dado que el PSC no cumple con
mecanismos de detección, respuesta,
notificación y remediación de
incidentes.
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
Posibilidad de fraude por incorrecta parametrización
de seguridad e inadecuados métodos de desarrollo de aplicaciones así como imposibilidad de autogestión por parte de la
EF.
SA2 ����
La metodología de desarrollo del PSC
está respaldada por el modelado de sistemas de software más
conocido y utilizado en la actualidad (UML).
Desde la EF solo vamos a consumir servicios de Backups
por ende no aplica la descripción de las pautas de diseño y desarrollo.
SA3 ����
El PSC dispone de información actualizada sobre las principales
amenazas y vulnerabilidades existentes,
el detalle es comunicado a la entidad mediante correos
a los principales referentes descriptos contractualmente.
SA4 ����
La comunicación informativa se realiza mensualmente
vía correo a los principales referentes, o cuando la EF lo
requiera, y en caso de urgencia vía
telefónica.
SA5 ����
Se verificó el informe de riesgo del PSC
contempla las principales amenazas detectadas, y
tratamiento sobre las mismas, según los servicios que provee a
la EF.
SA6 ����
Se dio vista a los informes de PEN TEST de la EF, y la
posibilidad de incluir el nuevo servicio en la nube para realizar las pruebas que se consideren,
también se dio vista a los informes de test periódicos
realizados por el PSC.
Las
oper
acio
nes
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
SA7 ����
El PSC brindó documentación con la parametrización
que involucran los servicios contratados al PSC. Por parte de
la EF existe la posibilidad de revisión de logs, y mecanismos de seguridad, existen fuertes canales (telefónicos y correos electrónicos) de comunicación
ente la EF y PSC, con inmediata respuesta.
SA8 ����
Se dio vista a documentación y mecanismos de autenticación provistos por el PSC, verificando el grado de actualización contra
estándares actuales.
Fallas en la protección de los datos
CGC1 ����
Tanto para la EF como para el PSC se dio vistas a políticas y
procedimientos para la gestión de claves
criptográficas.
CGC2 ����
Se dio vista a la guarda de claves de cifrado por parte de la EF, el
responsable es el sector de Protección de Act. de la Inf., los
referentes se encuentran descriptos contractualmente.
CGC3 ����
Se dio vista al procedimiento interno
de la EF que describe los responsables de las claves de
cifrado.
CGC4 ����
Se verificaron documentos, y parametrización en el sistema,
con los requisitos a cumplir para el alta
o renovación de claves, así como caducidad, etc.
CGC5 ����
El proceso de registro es realizado mediante formulario
firmado manuscrito por los referentes de
la EF cuya guarda es responsable el sector de Protección de Act. de
Las
oper
acio
nes
Posibilidad de fraude por incorrecta
parametrización de seguridad e
inadecuados métodos de desarrollo de
aplicaciones así como imposibilidad de
autogestión por parte de la EF.
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
la Información.
CGC6 ����
Se analizó la razonabilidad la fortaleza y grado de actualización
sobre la técnica actualmente utilizada para la protección de los
datos. La técnica utilizada se describe en el próximo control
CGC7.
CGC7 ����
Se verificó que utiliza mecanismos de seguridad
estandarizados, en nuestro caso AES.
Sin ningún desarrollo propio, tanto para la comunicación, como
para el uso, como para el guardado de claves.
CGC8 ����
Si bien no se logró identificar todos los proveedores que utiliza
el PSC, existen certificaciones que avalan la razonabilidad.
Pérdidas económicas y de reputación por acciones maliciosas de miembros
interno
GIA1 ����
Se dio vista a al procedimiento de alta de usuario,
asignación de permisos y funciones, así como las funciones
creadas y asignadas por defecto; visto certificación de seguridad del
PSC.
GIA2 ����
Se dio vista desde el panel administrador provisto por PSC
a la EF la posibilidad de ver todos los usuarios de la EF
que utilizaron los servicios en la nube (activa e inactiva),
todas las funciones asignadas actualmente y que tuvo
oportunamente. Así como log de todas las
actividades realizadas.
Las
oper
acio
nes
Fallas en la protección de los datos
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
GIA3 ����
El panel administrador de usuarios se puede acceder desde cualquier dispositivo
electrónico, en cualquier momento, y sólo tienen permisos
totales los referentes de la EF determinados contractualmente.
Fallo de aislamiento y supresión de datos
insegura o incompleta
VI1 ����
Existen contractualmente canales de comunicación para las
consultas técnicas con los principales referentes del
PSC, se dio vista además a las
parametrizaciones por defecto de los servicios
contratados mediante un informe provisto por el PSC.
VI2 ����
El PSC nos proveyó de documentación técnica con
diagramas de la arquitectura, se dio vista por
parte de la EF el diagrama y plan con el despliegue a
realizarse.
VI3 ����
Se contempla contractualmente en el control ALC3.
VI4 ����
En el control VI2 se visualiza el entorno,
las medidas de protección, modelos de IDS/IPS,
de los informes provistos por el PSC de detecciones y
tratamientos, así como el aval de la
certificación se considera mitigado el riesgo.
VI5 ����
El PSC provee de paneles administrativos
a la EF para que realice la parametrización de las alertas
que requiera y asigne a los referentes que considere. Visto
Las
oper
acio
nes
Pérdidas económicas y de reputación por acciones maliciosas de miembros interno
Check List de Controles Cloud Versión 1.0 Riesgo Inherente Dominio Controles Cumple Pruebas de control-Comentario
manual de usuario para la parametrización de alertas.
VI6 ����
El PSC ofrece la posibilidad de realizar cifrados, con técnicas conocidas y estandarizadas,
sobre las VM (Máquinas Virtuales), como herramienta
adicional de seguridad para evitar la copia de las
mismas. Visto documentación técnica provista por el PSC.
VI7 ����
El PSC mantiene los sistemas almacenamiento separados de
las máquinas virtuales, logrando un aislamiento entre
almacenamiento y procesamiento. Visto la
arquitectura provista por el PSC. Se dio vista a informes
disponibles por parte del PSC y la EF de la utilización de súper
usuarios o administradores, así como
la posibilidad de parametrizar alertas por parte de la EF.
VI8 ����
Se contemplaron las medidas en los controles ALC11, CPD4 y
GISD3.
Toda la documentación analizada en el relevamiento y nombrada en el Check List
(procedimientos, políticas, estándares), incluyen un adecuado versionado y
registros de cambios.
Las
oper
acio
nes
Fallo de aislamiento y supresión de datos
insegura o incompleta
Conclusión del práctico:
En el desarrollo del práctico pudimos entender la mecánica de los controles, sus
relaciones, interacciones, e intersecciones (por ejemplo VI8, VI3, CLA4).
En cuanto al relevamiento de las áreas involucradas el sector de Tecnología
Informática consideró aspectos contractuales, tecnológicos, de seguridad, y aristas
de encuadre legal propuestos, que no habían sido contemplados hasta la
intervención de AI.
El sector de Tecnología Informática consideró incluir en su matriz de riesgos, los
riesgos detectados por AI en los servicios Cloud.
Del relevamiento por cada riesgo detectado, los mitigantes asociados se
consideraron razonables.
Para los casos con riesgo residual, el plan de acción descripto se consideró
razonable.
Por tanto se concluyó que el proceso de migración a la nube del almacenamiento
de respaldo, con el proveedor propuesto, los riesgos detectados y controles
aplicados, se considera razonable.
Bibliografía:
� COSO, Control Interno y Marco Integrado.
� Guía de seguridad de áreas críticas en Cloud Computing V 3.0.
� Matriz de controles CSA_CCM_v.3.0.1.
� Manual de normas ISO/IEC 27001, e ISO/IEC 27018.
� http://www.auditool.org
� http://www.isaca.org
Reseña del auditor interviniente :
DATOS PERSONALES
Nombre y apellido: José Ignacio, Andres.
Dirección: Pasco/1333/2000/Rosario/Santa Fe/Argentina.
Teléfono: 54 – 02473 - 15407014.
Email: [email protected]
Fecha de nacimiento: 01 /06 /1981.
Nacionalidad: Argentino.
Estado civil: Soltero.
D.N.I. número: 28499672.
EDUCACIÓN Y FORMACIÓN
• Ingeniero en Sistema de Información (Universidad Tecnológica Nacional).
• Analista Universitario de Sistemas (Universidad Tecnológica Nacional).
• Auditor Interno en Banco de Santa Fe: Desde el año 2009 al 2016. Otras formaciones
Certificaciones de Auditor Interno ISO 9001, Auditor Interno ISO 27001, Diplomatura
en Seguridad de la Información, capacitaciones en herramientas de desarrollo, entre
otros.
Top Related