Cumplimiento ¿palabra de moda?

En términos generales, el cumplimiento es el proceso de adherirse a un conjunto de reglas que un organismo de la industria o agencia de gobierno piensa que usted necesita cumplir. El negocio tiene que cumplir con X, Y y Z requisitos o de lo contrario[1]… [bueno, ya conocemos los eventos apocalípticos que se desatarían]. El proceso es doloroso opinan algunos incluso sin haberlo intentado –por el status quo y otros considerandos; que hay poca área gris o espacio para la flexibilidad opinan otros. Habría que actualizarnos continuamente con el fin de establecer si aún prevalece lo malo anteriormente expuesto.

Cumplimiento es algo más que un aspecto adicional relacionado con la seguridad[2]; y es que no se puede externalizar la responsabilidad de la seguridad –una alta prioridad sobre todo por la inherente complejidad, siempre creciente[3] -no olvidemos el gobierno en sus diferentes formas y alcances para gestionar apropiadamente los riesgos. Asegurar el cumplimiento y proporcionar seguridad a los datos en la nube son cosas complicadas, no es fácil, pero se puede lograr[4].

De hecho, definir una estrategia de seguridad en la nube debería ser la mayor preocupación, tanto para el negocio como para TI, desde el mismo inicio de cualquier despliegue en la nube[5]; así es, una estrategia de seguridad NO puede esperar –a nadie y por nada- y debe mantenerse viva.

Con respecto a la seguridad, entre otras inquietudes todos tenemos las siguientes[6]:

¿Qué informaciónse almacenaen un sistema? –lo sabe ¿verdad?
¿Dóndese almacenala información? –el asunto en cuestión, y todas las demás interrogantes relacionadas.
¿Quiénpuede acceder al sistema? –y ¿mantenemos vigente la lista como parte de un procedimiento documentado que involucra a todas las partes involucradas (proveedor, cliente, terceros)? –sin olvidar los niveles administrador/usuario, como mínimo.
¿Cuál es el riesgo para los datos? -¿Están los controles en el lugar adecuado para mitigar el riesgo? ¿Cómo se lidia con los criterios de confidencialidad, integridad y disponibilidad (CID)? Recordemos que para asegurar los datos debemos empezar por su identificación, clasificación y tratamiento. No olvidemos la seguridad de nuestros datos cuando son transportados y almacenados, pensando que nuestros datos son menos seguros en la nube [¿utilizamos cifrado de datos?[7] ¿Y validamos que se mantenga su efectividad?[8]] –claro, también cuando son procesados; el tema es nuevamente la responsabilidad compartida. Probar periódicamente la funcionalidad de exportación de datos le ayuda a entender el proceso de exportación en la práctica (no sólo en teoría). Esto da claridad sobre algunos diversos aspectos operativos de esta manera: cuánto tiempo va a tomar, quién tiene que estar involucrado en el lado del proveedor de servicios, los costos adicionales que pueden ser requeridos, en qué formato llegan los datos en última instancia, entre otros aspectos[9] –seguridad de la información/cumplimiento/SLA, o deseamos depender de solo un proveedor de servicios en nube.
¿A quépuedenacceder? –seguramente tenemos un procedimiento documentado para esto, además de las relaciones necesarias en el sistema y a qué partes de la plataforma (hipervisor, aplicación por ejemplo).
¿Es elacceso adecuado? –es decir, ¿sabemos el porqué es adecuado? El acceso debe basarse en roles de trabajo, y debe proporcionarse una descripción clara del nivel de acceso necesario.
¿Operaciones de seguridad? ¿Tenemos o existe disponibilidad para acceder a las trazas de seguridad, detección de anomalías, notificaciones de brechas de seguridad u otras notificaciones, APIs, procedimientos de respuesta a incidentes, derecho a realizar auditorías, otros? ¿Son las medidas de seguridad tradicionales aplicables en la nube? –de hecho hay un alto riesgo, y tampoco cometamos el error deconfiar demasiado enlas capas de seguridaddel proveedor deIaaS (o de ningún otro modelo) ¿Siguen siendo válidos “viejos” paradigmas como prevenir es mejor que curar, los seres humanos son el eslabón más débil, y el acceso debe limitarse a sólo a lo que un empleado necesita para hacer su trabajo[10]?
Obviamente no todas las aplicaciones son creadas iguales y la funcionalidad de la aplicación, el tipo de datos que se accede, la criticidad de negocios, los accesos/roles de los usuarios, la autenticación y así sucesivamente todos influyen en el perfil de seguridad de cualquier aplicación -¿ya mencioné que esto debe vigilarse en el tiempo?

Sabremos seguramente lo primero pero, ¿qué hay del resto de las incógnitas? -sobre todo cuando se trata de una nube pública y sobre todo por su naturaleza multi-cliente[11]. El reto es saber dónde están los datos [o dónde deberían estar] y cómo están protegidos -cuán privados permanecen [cuál es nuestro nivel de propiedad de los datos], porque pasar a la nube puede afectar la capacidad de una organización para cumplir con normas, regulaciones y estándares.

Si bien el proveedor podría técnicamente identificar dónde almacena sus [tus] datos, no está obligado a hacerlo. Bueno, parte del negocio es ese, el proveedor distribuye lo mejor que puede los recursos de la plataforma para entregar un servicio razonablemente “apropiado” para las cargas de trabajo que le serán exigidas. Aquí lo usual como clientes es preocuparnos de cuán persistentes son estos almacenamientos.

En buena cuenta, asegúrese de que su proveedor es capaz y está dispuesto a demostrar que utiliza separación de funciones para las funciones administrativas, y que tienen la capacidad de “probar” quién tuvo acceso a un sistema de información y cuándo tuvo este acceso. Tenga en cuenta que este último requisito requeriría desplegar una solución robusta y estado del arte para el registro relacionado con la seguridad. Es importante un cierto nivel de madurez[12] en el cumplimiento de estándares. Gran parte del cumplimiento se trata de garantizar los controles adecuados sobre quién tiene acceso a los bienes, qué nivel de acceso que tienen y cómo se mantienen esos niveles. La manera en que esas cosas suelen garantizarse es a través de la auditoría, en el que hay que decir lo que estamos haciendo y demostrar que lo estamos haciendo.

Mike Chapple de la Universidad de Notre Dame implica la posibilidad de un cambio en nuestro enfoque [de nuestros equipos de trabajo] en la seguridad y el cumplimiento. En los centros de datos convencionales [o legados] un equipo es el que lleva la responsabilidad final por el mantenimiento de un ambiente de TI seguro y conforme.

Este enfoque de extremo a extremo, simplemente no se aplica en un mundo de computación en nube donde las empresas suelen compartir las cargas de cumplimiento con uno o más proveedores de servicios que puedan estar proporcionando infraestructura, plataformas o servicios alojados. En este modelo de responsabilidad compartida, tanto los proveedores de servicios como sus clientes deben precisar lo que se requiere de cada lado, en términos de responsabilidades de cumplimiento.

Así, es crítico identificar quién es responsable de la ejecución de cada objetivo de control en cada etapa del modelo de nube. Entonces deberá trabajar con sus proveedores de servicios en forma regular para revisar y actualizar la división de responsabilidades. A medida que cambian las necesidades del negocio y las capacidades técnicas evolucionan, el peso del cumplimiento puede desplazarse en una dirección u otra. Mantenerse al tanto de estos desplazamientos de responsabilidades es un componente clave de la gestión del cumplimiento.

Muchas regulaciones de cumplimiento de TI contienen una redacción que especifica las ubicaciones geográficas donde entidades financieras o de salud, por ejemplo, pueden almacenar datos. Reglamentos de control de exportaciones de Estados Unidos prohíben el almacenamiento o la transmisión de algunos datos regulados fuera de los Estados Unidos. Del mismo modo, las regulaciones de privacidad de la Unión Europea prohíben la transferencia de información personal fuera de la UE sin la implementación de controles de privacidad adecuadas alrededor de esos datos; no hablemos de los canadienses.

Por esta razón, debemos considerar cuidadosamente los procesos de notificación de incidentes de seguridad antes de contratar los proveedores. Los contratos con los proveedores de servicios deben exigir que el proveedor nos notifique inmediatamente de los incidentes de seguridad conocidos o sospechosos que afectan a los datos en la nube. No olvidemos asegurar estas condiciones.

La adopción de servicios de cloud computing aumenta la complejidad de cuestiones relativas al cumplimiento y la importancia de documentar los controles. Cuanto más fácil nos sea demostrar claramente el cumplimiento de las leyes y reglamentos de TI, más tranquilas irán las cosas cuando los auditores nos visiten. No olvidemos que los contratos deben explicar los detalles del modelo de responsabilidad compartida negociado entre la organización y sus proveedores de servicios –y tampoco olvidemos los acuerdos de nivel de servicio.

También debemos conservar el derecho de auditar –periódicamente- el desempeño de los proveedores contra cualquier normativa de seguridad aplicable –un proveedor de la nube certificado [aunque parezca interesante y liberador que al utilizar sus servicios “heredemos” las certificaciones] no garantiza la protección [continua] así, siempre valide las demandas de cumplimiento que su proveedor le entregue –y asegúrese que se mantienen vigentes porque recordemos que la seguridad no es un acto único. Los vendedores son sin duda responsables de la gestión de sus servicios enfocados en el cumplimiento, pero este cumplimiento no se traduce automáticamente al cumplimiento completo del cliente[13]; alcanzar los estándares cumplimiento y regulatorios es predominantemente responsabilidad del cliente, no del proveedor de la nube[14].

Los proveedores de nube deben ofrecer transparencia de su infraestructura a los clientes. Por ejemplo, aunque Microsoft realiza sus propias pruebas de Azure[15], los usuarios finales tienen la responsabilidad de asegurarse de que sus sistemas cumplen los requisitos de seguridad de la empresa[16]. El cumplimiento de los estándares de seguridad del centro de datos son una cosa, pero fallas de servidores y aplicaciones son otra muy distinta.

Así, es necesario tomar medidas para garantizar que los proveedores de servicios implementan sus servicios en la nube de manera tal que conservan el cumplimiento de todas las regulaciones aplicables a nuestros requerimientos –recordemos, entre otros, aspectos de exportación, requerimientos de privacidad. Nunca debemos depender exclusivamente de nuestro [menos de uno] proveedor de la nube[17] ‑recordemos, la responsabilidad debe ser compartida, y el monitoreo continuo.

No olvidemos los contratos de confidencialidad y seguros contra daños ocasionados por terceros –recordemos que el diablo está en los detalles[18]; la documentación referida a las responsabilidades compartidas; responsabilidades por la seguridad de los datos, como tampoco las categorías de servicio en nube que son ofrecidas o con las que desee trabajar –los requerimientos de cumplimiento en cada caso; los dispositivos móviles[19] que podamos utilizar para el control (según el Barómetro 2013 Riesgo/Recompensa de ISACA, 50% de las empresas ya permiten explícitamente BYOD[20]); los hipervisores y contenedores (dockers como alternativa a los hipervisores[21], que tienen tanto de proceso como de gobierno y tecnología y que los expertos instan a las organizaciones sólo utilizar contenedores de aplicaciones con permisos fuertemente custodiados, y para controlar el sistema operativo subyacente[22]), virtualización; control de los proveedores en nube que contratamos para la empresa –o que nuestros usuarios utilizan [incluso sin nuestro conocimiento o autorización]; entre otros puntos a considerar para un efectivo matrimonio cumplimiento-seguridad.

A estas alturas ya se habrán dado cuenta porqué hemos hablado poco de tecnología. De hecho, la seguridad en la nube no es sólo una pregunta [retórica] de TI[23].

[1] Fuente: http://searchcompliance.techtarget.com/tip/Cloud-compliance-legal-issues-take-center-stage-as-cloud-use-expands,febrero/2011

[2] Fuente: https://www.youtube.com/watch?v=1SruE7Tr7iw, enero/2015

[3] Fuente: http://searchcloudsecurity.techtarget.com/feature/The-ups-and-downs-of-cloud-compliance?utm_medium=EM&asrc=EM_NLN_48466586&utm_campaign=20151009_NEW%20IN%20INFORMATION%20SECURITY%20MAGAZINE:%20Regaining%20control%20of%20cloud%20compliance,%20CISO%27s%20role%20from%20IT%20security%20to%20policy%20wonk,%20Corporate%20investments%20in%20cybersecurity%20startups%20%20_oeckerson&utm_source=NLN&track=NL-1836&ad=903432&src=903432#, octubre/2015

[4] Fuente: http://searchcloudsecurity.techtarget.com/feature/Securing-data-and-ensuring-compliance-in-cloud-based-services, octubre/2015

[5] Fuente: http://searchcloudcomputing.techtarget.com/news/4500247879/Four-cloud-security-myths-debunked, junio/2015

[6] Fuente: http://viewer.media.bitpipe.com/1103740304_372/1280167431_218/CA_sCompliance_SO-O31222-E-Guide_7-22.pdf, octubre/2015

[7] Fuente: http://searchcompliance.techtarget.com/video/Cloud-compliance-data-protection-top-reasons-for-encryption, abril/2015

[8] Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246165/Seven-cloud-security-risks-that-will-ruin-your-day/2/Overlooking-cloud-data-encryption, octubre/2015

[9] Fuente: http://searchcloudsecurity.techtarget.com/tip/Three-practices-to-prevent-cloud-vendor-lock-in, junio/2013

[10] Fuente: http://www.cio.com/article/2989206/security/when-it-comes-to-security-trust-but-verify.html?phint=newt%3Dcio_security&phint=idg_eid%3D0f3e0907b81179ebb4f3b209b6424bae#tk.CIONLE_nlt_infosec_2015-10-09, octubre/2015

[11] Fuente: http://searchcloudcomputing.techtarget.com/photostory/4500246164/Seven-cloud-security-risks-that-will-ruin-your-day/1/The-risky-business-of-securing-data-in-the-cloud, octubre/2015

[12] Fuente: http://www.bitpipe.com/data/demandEngage.action?resId=1329422213_586, 2012