Creo que en el 2018 ya todos hemos escuchado como la seguridad es una responsabilidad compartida, y como las empresas y sus dirigentes deben estar informados y ser los responsables últimos de la seguridad cibernética de las organizaciones; pero que raramente se escucha son casos de éxito, donde se apliquen estos principios y donde los ejecutivos del nivel “C” aceptan esta responsabilidad de manera transparente, sin buscar como desvincularse del tema solo porque se trata de “algo técnico”.

Si la teoría aplicará, las organizaciones y sus ejecutivos entenderían el rol crucial que juegan en todos los aspectos técnicos de su organización; debemos recodar que la autorregulación de las organizaciones de tecnología (Vicepresidencias o gerencias) no ha tenido mucho éxito, en parte, porque existen muchas opciones y un ejemplo claro es el tema de la nube. La respuesta a preguntas difíciles como ¿que proveedor de nube debemos utilizar? ¿Amazon? ¿Google? ¿Microsoft?, rápidamente se convierten en cruzadas religiosas, donde ningún bando logra avanzar y todos creen tener la razón.

El impacto de la falta de liderazgo desde el nivel ejecutivo, en las organizaciones de tecnología es devastador, y usualmente pone a dichas organizaciones en el camino al fracaso.

Cuando el escenario es el ideal y existe una dirección clara de el nivel ejecutivo, entonces el ejercicio técnico se hace mucho más claro, usando criterios como:

  1. Opex vs. Capex
  2. Presencia local del proveedor de nube
  3. Niveles de soporte
  4. Velocidad de despliegue
  5. Seguridad

Tomando en consideración, los servicios de nube de Microsoft cuentan con una ventaja tangible, por lo menos en Panamá.

  1. Oficinas locales
  2. Soporte local y remoto
  3. Tiempos de respuesta bastante decentes
  4. Multiples opciones de licenciamiento (a veces esto es una desventaja)
  5. Disponibilidad de arquitectos de nube que pueden ayudar, entre otros temas, con el aseguramiento del despliegue de nube

Tomando en cuenta que mi experiencia es más que nada con Azure, este articulo se concentra en las capacidades de esta opción. Me queda pendiente explorar Amazon y Google.

Sin animo de redundar en el articulo anterior, es necesario indicar que una migración a nube, sin importar el proveedor seleccionado, básicamente se trata de trasladar los procesos y procedimientos existentes “on-prem” hacia la nube, haciendo los ajustes necesarios para adaptar los mismos a dicho ambiente. Esto requiere que dichos procesos y procedimientos existan, antes de intentar realizar una migración de servicios a la nube; de otra manera sera muy difícil gestionar los costos de dicho despliegue, y hace prácticamente imposible su aseguramiento.

¿Cuales son las amenazas reales?

Como dicen, no una imagen habla mil palabras, así que una bonita manera de entender el problema puede ser viéndolos en la gráfica: http://informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

En esta visualización, solo filtre por dos tipos de ataques: hacked (rojo) y ataques internos (morado).

Si a esto le sumamos la cantidad de vulnerabilidades nuevas, su severidad y el hecho de que ahora se pueden alquilar plataformas de completas de malware como servicio, para atacar organizaciones puntales, entonces podemos concluir que el panorama de amenazas es real, que no se trata de vender miedo a los ejecutivos, y que dichas amenazas deben ser plasmadas un lenguaje común, que permita a los técnicos obtener los recursos necesarios para asegurar las cargas de trabajo que se han migrado a la nube.

Con esto en mente, a continuación propongo una lista de pasos para una nube segura, según mi corta experiencia (3 años) con estas tecnologías:

  1. Mantenerse informado

    Esto puede sonar a disco rallado, pero la verdad es que no hay alternativa; ahora no solo es estar informados sobre las amenazas, sino también sobre las técnicas de defensa, mejores prácticas y demás.

    Como siempre, NIST nos proporciona mucha información, y el tema de nube no es la excepción, en este enlace https://www.nist.gov/publications/nist-cloud-computing-reference-architecture, se puede encontrar el modelo de referencia de computación de nube de NIST (publicación 500-292). Dicho modelo sirve para poner las cosas en contexto y homologar los términos a utilizar, cuando se hable de nube.

    En el tema especifico de seguridad, NIST también tiene otra publicación “Cybersecurity Framework” (https://www.nist.gov/programs-projects/cybersecurity-framework).

    Y ya entrando en el tema de seguridad en Azure, Microsoft cuenta con bastante información, sin embargo, la lectura obligada para iniciar la conversación sobre el tema es el documento de responsabilidad compartida en la nube, publicado en el siguiente enlace https://gallery.technet.microsoft.com/Shared-Responsibilities-81d0ff91.

  2. Azure Cloud Networking, cifrado y almacenamiento de datos

    Creo que el concepto de nube no podría existir sin el cifrado de datos, mismos que nos brinda la posibilidad de utilizar VPNs, HTTPS en todos lados y el cifrado de datos en descanso.

    Pero esto no es suficiente, el cifrado de datos en descanso (at-rest) y en movimiento (in-transit) debe ser parte de su solución de nube (https://docs.microsoft.com/en-us/azure/security/azure-security-data-encryption-best-practices).

    En el caso de Azure, esto es realidad out-of-the-box, sin embargo, hay que recalcar que este nivel de cifrado puede ser insuficiente, ya que se Microsoft controla las llaves privadas. Para garantizar que los empleados de Microsoft no tengan acceso a los datos de los clientes, se debe implementar el esquema de BYOK (Bring Your Own Key) mediante la implementación de Azure Key Vault (https://blogs.technet.microsoft.com/kv/2015/01/08/azure-key-vault-making-the-cloud-safer/).

    En el tema de cifrado, siempre va a existir el debate sobre el acceso que el proveedor de nube tenga a los datos cifrados de los clientes; en el ámbito civil, el esquema de Azure Key Vault es suficiente para garantizar que cualquier demanda que reciba Microsoft se redirigirla al cliente dueño de la información, ya que el proveedor no tendría acceso a la información cifrada con la llave privada del cliente; sin embargo, en el ámbito penal existe todo un abanico de opciones legales, que pueden ser o no contrarias a los mejores intereses de los usuarios de servicios de nube.

    En este ultimo escenario, es preocupante ver como el gobierno de Estados Unidos ha hecho más fácil el acceso trans fronterizo de información, dejando de lado el canal usual de los MLATs (Mutual Legal Agreements). Esta ley conocida como CLOUD ACT (https://en.wikipedia.org/wiki/CLOUD_Act) fue aprobada sin amplias consultas, dentro del presupuesto del gobierno federal. Este tema es bastante reciente, por lo cual creo que su divulgación aún no ha sido muy amplia.

    Sin importar las limitantes legales, el consejo número uno cuando se consumen servicios de nube es cifrar todo: datos en descanso, en movimiento, máquinas virtuales, utilizar VPNs y/o servicios web cifrados (HTTPS). Esto aplica para todo lo que se haga en nube, ya sea desarrollo interno, despliegue de máquinas virtuales (IaaS), consumo de servicios (PaaS), y demás. Este tema es especialmente delicado cuando se trata de desarrollos, ya que los programadores pueden no tener experiencias con tecnologías de cifrado y seguridad, ya que están acostumbrados a que las aplicaciones existan dentro de un perímetro bajo el control de la organización. En la nube, el perímetro no existe y la identidad de los usuarios y su información son la prioridad.

  3. Getsión de identidad y Multiple factor de autenticación

    En todo lo que se relaciona con la identidad del usuario, tendemos a pensar en lo mínimo necesario; usualmente una contraseña es suficiente y ni siquiera se toma en cuenta las reglas mínimas de complejidad de contraseñas. ¿Cuantas veces no escuchamos a los usuarios quejándose cuando se implementan reglas de complejidad de contraseñas mínimas? Esto es especialmente cierto cuando hablamos de los usuarios de los departamentos de tecnología.

    Ahora, hay que imaginar el proceso de implementación de cosas como:

    • Single Sign-On
    • Multiple Factor de Autenticación (MFA)
    • Registro de dispositivos
    • Gestión de credenciales administrativas (Privileged identity management)
    • Control de acceso condicional
    • Sistemas de identidad híbrida
    • Control de acceso basado en roles (RBAC)

    Creo que se entiende la idea; la selección e implementación de controles de acceso es compleja, sin embargo, su resultado debe ser una solución integrada de gestión de identidades, que sea fácil de utilizar, tanto para los administradores, como para los usuarios finales.

    Esto requiere robustez en los procesos de TI que soportan esta función (seguridad y mesa de ayuda).

    Lo bueno de hacer despliegues en la nube, es que nos da muchas herramientas de donde elegir. Puntualmente en Azure podemos encontrar que RBAC y MFA vienen incluidos, sin necesidad de hacer mucho. El resto de las opciones podrían tener un costo, pero la otra ventaja, es que si el modelo funciona para la nube, debe funcionar para los recursos en tierra, en otras palabras el modelo es extensible.

    Este es un buen lugar para iniciar la lectura con respecto al manejo de identidad en Azure: https://docs.microsoft.com/en-us/azure/security/azure-security-identity-management-best-practices.

    Aqui hay otro enlace interesante: https://docs.microsoft.com/en-us/azure/active-directory/identity-fundamentals

  4. Azure Security Center

    Usualmente los equipos de seguridad siempre están en contra de los despliegues hacia la nube, me imagino que por la sensación de perdida de control sobre el perímetro (como si aún importara), la perdida de visibilidad de las bitácoras, y demás mitos y leyendas que hemos aprendido a través de los años; usualmente relacionados con las practicas de seguridad por oscuridad o de el famoso FUD (Fear Uncertainty and Doubt), que tradicionalmente nos ha servido para obtener nuestros presupuestos.

    El tener que admitir que estas prácticas oscuras del pasado, en realidad no son efectivas, ocasiona resistencia a la adopción del modelo de nube, mismo que no puede acomodar estos conceptos, ya que al momento de que un proveedor ofrece el servicio de nube, el mismo debe estar basado en procesos y procedimientos ampliamente probados y conocidos (ITIL, Cobit, ISO, NIST, etc.); lo que siempre provoca la pregunta en los niveles ejecutivos ¿y porque no lo hacíamos así antes? Y la típica respuesta de los departamentos de tecnología: “Porque siempre lo hemos hecho así”.

    Este es el principal obstáculo para la adopción de nube, sin embargo, los departamentos de seguridad no se pueden dar ese lujo, sencillamente no hemos existido por suficiente tiempo, ni hemos operado de una sola manera por suficiente tiempo, como para poder decir que siempre lo hemos hecho de una manera u otra. La razón de esto es que el panorama de amenazas cambia constantemente, los actores cambian, las motivaciones cambian, y su su oficina de seguridad no esta cambiando constantemente, sencillamente no están haciendo su trabajo.

    Ahora, regresando al tema de Azure, la mejor manera de afrontar todos estos cambios, de la manera más rápida, sencilla y económica posible, es implementando Azure Security Center (https://docs.microsoft.com/en-us/azure/security-center/security-center-intro).

    Sencillamente es el lugar donde encontraremos todo tipo de información relacionada con nuestra planta tecnológica, y antes de que pregunten, los agentes de monitoreo también se pueden instalar en sus servidores on-prem, de manera que se tiene una sola consola de control y monitoreo del estado de seguridad de todo lo que esta en la nube y si su presupuesto le da, de todo lo que esta on-prem.

    Desde mi punto de vista, no es posible realizar un despliegue hacia la nube, sin una herramienta como esta, todo lo demás es sencillamente irresponsable, ya que no se puede realizar una migración a nube y sencillamente esperar que no suceda nada malo.

    Hay que recordar que en nube, la responsabilidad de los datos, siempre es del cliente y nunca trabajo del proveedor.

Estoy seguro que se me quedaron muchos más temas por fuera, pero lo bueno es que eso puede provocar una conversación interesante.