Capítulo 6 - Ciberseguridad 1: Vectores de Ataque

Buenas tardes, en este sexto capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital daremos inicio de manera explícita al tema de la Ciberseguridad. Esto es necesario dado que sin el panorama global de lo que involucra la seguridad en una aplicación en la nube, es imposible evaluar adecuada y claramente la situación actual de nuestro sistema frente a sus principales amenazas.

En esta primera parte se dará cuenta de los principales Vectores de Ataque de los que una aplicación en la nube puede ser objetivo. Cualquiera de estos Vectores puede desencadenar la exposición de la información personal de pacientes.

¿Qué es un Vector de Ataque?

Un vector de ataque es un potencial camino a través del que un hacker puede obtener acceso a un sistema cualquiera objetivo, mientras que como se ha explicado en capítulos anteriores, su contraparte las Superficies de Ataque corresponden a los puntos de entrada de un sistema específico que hacen posible la implementación de Vectores de Ataque.

Las siguientes 5 son las principales categorías de Vectores de Ataque en el contexto de aplicaciones en la nube. En los siguientes capítulos los trataremos individualmente y aunque cada uno de los 5 Principios de Diseño Seguro (presentados en los capítulos anteriores) deben ser aplicados en cada una de las categorías de Vector de Ataque, en lo siguiente los relacionamos con el objetivo de entregar una recomendación para cada una de estas.

Categorías de Vectores de Ataque

1. Vector Organización

Probablemente los vectores de ataque con mayor potencial de daño sean los que provienen desde el interior de la organización en la que se desarrolla la aplicación, pues son los desarrolladores de esta quienes mayor control y acceso tienen a los datos y funcionamiento de ésta. Sin embargo, entre más claras sean las consecuencias y mejor la trazabilidad de acciones en el entorno de desarrollo, más probable es que un insider se abstenga de hacer un mal uso de sus privilegios.

En este contexto y siguiendo el Principio de Menor Privilegio, cada desarrollador debe emplear credenciales individuales claramente identificables. Esto permitirá por ejemplo que todas las acciones realizadas por un IAM User de Amazon Web Services quede automática, permanente e indestructiblemente registrada en el servicio Amazon Cloud Trail en el momento exacto de su realización.

Arquitectura que permite monitorear todas las operaciones realizadas al interior de una cuenta AWS (i.e acciones realizadas por desarrolladores de una aplicación) junto con todo el tráfico de IP sobre las interfaces de red en una VPC, y notificar en caso de algún evento previamente definido. Obtenida desde engineering.99x.io.

2. Vector Usuarios

En toda aplicación los usuarios son los responsables de cuidar que sus credenciales no caigan en manos ajenas. Sin embargo, a medida que la responsabilidad y los privilegios de un usuario en una aplicación aumentan, aumenta también la responsabilidad de sus creadores de proveer, e incluso imponer medidas de seguridad que dificulten la suplantación o robo de credenciales de acceso.

Por tanto y siguiendo el Principio de Defensa en Profundidad, todo superusuario o administrador de datos confidenciales de terceros debe emplear mecanismos de segundo factor asociados a sus credenciales al autenticarse en la aplicación. Esto no impedirá que otro tipo de mecanismos como por ejemplo ingeniería social no logren sus objetivos, pero reducirá en gran medida las probabilidades de filtración de datos.

3. Vector Aplicación

Tanto el hardware como el software empleado para levantar una aplicación responsable de proteger datos sensibles deben aplicar cada uno de los 5 Principios de Diseño Seguro, como por ejemplo el de Mínimo Privilegio en el diseño de roles y el de Defensa en Profundidad en la implementación de los mecanismos de acceso a la base de datos. Sin embargo, todos estos mecanismos pueden llegar a fallar.

Es por esto que siguiendo el Principio de Fallar de Manera Segura su aplicación debe poseer respaldos encriptados de la información y un Ciber Seguro en caso de que corresponda. Esto no impedirá el robo de su información, pero mitigará significativamente los daños en caso de Ransomware y conflictos legales.

Tanto AWS Aurora como RDS MySQL permiten a las bases de datos en Amazon implementar PITR (Point In Time Recovery), mecanismo que almacena en logs cada transacción realizada en la base de datos y que permite reducir la pérdida de datos a (un máximo de) los últimos 5 minutos de ingreso de datos Obtenida desde mydbops.wordpress.com

4. Vector Software de Terceros

Las librerías empleadas por una aplicación son una potencial fuente de vulnerabilidades, sobre todo aquellas que son menos usadas y estudiadas.

Siguiendo el Principio de Diseño Abierto, las librerías empleadas deben estar bien documentadas particularmente respecto de sus funcionalidades de seguridad, e idealmente ser las más usadas. Adicionalmente debe emplearse un administrador de paquetes que informe sobre las vulnerabilidades encontradas en las versiones de las librerías instaladas. Estos proveerán rápidamente de información acerca de la vulnerabilidad, lo que apuntará a la discusión sobre esta en el repositorio de la librería y sobre la solución recomendada.

5. Vector Red

La red es un ambiente plagado de individuos anónimos de todas las nacionalidades, buscando brechas de seguridad alrededor de cada punto de entrada a una aplicación.

En este contexto es que la Superficie de Ataque debe ser minimizada exponiendo a internet la menor cantidad de puertos y componentes de una aplicación, y monitoreando posibles intentos de ataque. También las peticiones aceptadas deben tener un formato lo más restringido posible, dejando fuera patrones de ataque conocidos. Amazon WAF es el firewall de AWS que identifica, registra y descarta mensajes de ataque dirigidos a las componentes desplegadas antes de que lleguen a ellas y puedan afectarlas.

Arquitectura que protege todas sus entradas con Amazon WAF, que filtra las peticiones recibidas en cada una de ellas con reglas de filtrado diferenciadas dependiendo del tipo de peticiones que puede recibir. Por ejemplo, la API podría recibir peticiones que intenten afectar la base de datos (SQL), mientras que el frontend podría recibir unas que intenten realizar un ataque XSS. Puede implementarse defensa en profundidad implementando chequeos diferenciados en las distintas etapas de procesamiento de una solicitud. Obtenida desde aws

Link al Capítulo anterior
Link al Capítulo siguiente

Referencias

  1. Principio del mínimo privilegio: Principio del menor privilegio: la estrategia de limitar el acceso a lo que es imprescindible | WeLiveSecurity

  2. ¿Qué es la defensa en profundidad? Defensa en profundidad y su relación con la seguridad por capas

  3. Principio de Fallar de Manera Segura: https://launchdarkly.com/blog/if-youre-going-to-fail-fail-safely/

  4. Principio de Diseño Abierto: https://www.coursera.org/lecture/secure-coding-principles/principle-of-open-design-FQFqL

  5. Principio de Menor Superficie de Ataque: What is an attack surface – Reducing it and what it is | Avast

  6. Amazon Web Services Cloud Trail: AWS CloudTrail – Amazon Web Services

  7. ¿Qué es un ciber seguro? Ciber seguro

  8. Amazon Web Services WAF: AWS WAF – Web Application Firewall – Amazon Web Services (AWS)

2 Me gusta