Caso práctico de Auditoría en el mundo del Cloud

Como ya adelanté en el anterior post, este cuarto post lo centraré en exclusiva en analizar un caso práctico de auditoría aplicado al mundo del Cloud Computing [1]. Si que me gustaría destacar, que a pesar de que la resolución del caso es correcta, ISACA ha realizado una serie de cambios importantes en las últimas versiones de COBIT, la quinta en particular. Por lo tanto, este post ha sido elaborado con la información que ISACA ha publicado con fin divulgativo pero es necesario acceder a los manuales más recientes si se desea elaborar una auditoría de sistemas alojados en la nube completa y elaborada mediante los estándares más recientes.

En el caso que analizamos en este post, la compañía A, ofrece una solución de software llamada Business Express mediante un modelo de distribución SaaS, no obstante la compañía no cuenta con la infraestructura propia necesaria para ofrecer esta solución. Por lo tanto, ha decidido hospedar su infraestructura en la nube (IaaS) mediante un acuerdo entre esta empresa y un CSP (Cloud Service Provider).

En resúmen, el CIO de la compañía ha decidido encomendar a un auditor de sistemas la tarea de auditar los dos aspectos que he mencionado anteriormente: la solución que ofrece la compañía en forma de SaaS y los sistemas alojados en la nube(IaaS) del CSP para soportar esa solución.

Una vez el CIO le ha comunicado al auditor cuales son las dos cuestiones a auditar, el auditor ha decidido elaborar un plan de auditoría con el fin de identificar los riesgos existentes en ambos sistemas. Para la realización de dicha auditoría, en la actualidad existen multitud de frameworks distintos de los que hacer uso.

Por una parte se puede hacer uso de frameworks genéricos como el elaborado por COSO (Enterprise Risk Management-Integrated Framework), y por otra parte, se pueden utilizar los frameworks referentes a la parte IT como son el ISO 27001 o el ITIL. Asimismo, diferentes organismos e instituciones como la CSA (Cloud Security Alliance), la ENISA, o el NIST [2] (US National Institute of Standards and Technology), ya han publicado diferentes guías referentes al tema que se trata  en cuestión, las auditorías del cloud computing. Finalmente, COBIT es un estándar que permite la realización de una auditoría holística que permita identificar los riesgos más relevantes de IT.

Por todo lo mencionado anteriormente, el auditor ha decidido hacer uso del framework Risk IT. Este framework se basa en los principios de COBIT pero complementandolo con todos aquellos riesgos no relacionados con IT que COBIT no contempla. Además, también hace uso de las distintas guías específicas sobre Cloud Computing que he mencionado antes para tener en cuenta también los riesgos propios de esta tecnología. Gracias a todo ello, el auditor consigue elaborar un listado de 36 escenarios distintos a analizar donde se relaciona cada riesgo IT con los objetivos de control propuestos por COBIT.

Dado que el documento cuenta con información abundante acerca de la realización de los controles, he decidido centrarme en las conclusiones del informe y destacar aquellas cuestiones más relevantes.

Por ejemplo, el riesgo número 34 hace referencia a la los riesgos relacionados con los acuerdos contractuales, los referentes de los distintos proveedores de servicios en particular. El auditor al analizar el acuerdo percibe la carencia de una auditoría externa al CSP, una cuestión trascendental antes de entablar cualquier tipo de relación con este tercero.

Este ejemplo, demuestra cómo COBIT no solo permite auditar riesgos tecnológicos sino que además, también analiza y estudia un amplio espectro de riesgos que van más lejos de la propia tecnología como es en este caso son los acuerdos contractuales.  Es decir, una análisis holística de los riesgos.

El informe elaborado por el auditor también destaca como la integridad de los datos se ve comprometida por la carencia de un sistema seguro de comunicación entre la empresa A y los sistemas alojados en el CSP (punto 28). Además, en lo referente a los Service Level Agreements (SLA), estos presentan un nivel de detalle escaso y la calidad del servicio (QoS) también se ha visto comprometida.

En resúmen y como demuestra esta infografía teniendo en cuenta los criterios de probabilidad e impacto, hay dos cuestiones a destacar: los aspectos asociados a los acuerdos contractuales y los aspectos referentes a la seguridad en la comunicación entre ambas entidades (Empresa A y los sistemas alojados en el CSP).

Para concluir, el objetivo final de este post ha sido el mostrar un framework metodológico para identificar, clasificar y priorizar los riesgos más relevantes en la implantación de esta tecnología. Al fin y al cabo, la clave del éxito radica en saber destinar los recursos en función de las prioridades de cada riesgo (prioridades alineadas con la estrategia del negocio). Por otra parte, los controles son importantes y resultan cruciales pero siempre se debe tener en cuenta una simple cuestión ¿Este nuevo control me va a suponer un coste superior al riesgo que intento evitar?, de ser así el implantar el control no es una opción viable.

En definitiva, cualquier control que se realice tiene un claro objetivo: identificar el impacto de los riesgos en el negocio. Por consiguiente, toda esta gestión de riesgos IT debe ir alineada con la estrategia de la empresa.

[1]  «SP 800-144, Guidelines on Security and Privacy in … – NIST CSRC.» https://csrc.nist.gov/publications/detail/sp/800-144/final. Se consultó el 29 noviembre 2018.

[2] «Cloud Computing Risk Assessment A Case Study – isaca.» https://m.isaca.org/Journal/archives/2011/Volume-4/Documents/jpdf11v4-Cloud-Computing.pdf. Se consultó el 29 noviembre 2018.