Capítulo 7 - Ciberseguridad 2: Vector Organización y Zero Trust

Buenas tardes, en este séptimo capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital comenzaremos a tratar la lista de Vectores de Ataque presentada en el capítulo anterior, en particular el Vector Organización. Tal como se explicó este vector engloba a las amenazas provenientes de la misma organización, en la que se está desarrollando la aplicación en Salud Digital.

Las amenazas presentes en este vector pueden ser separadas en 2 tipos: Malas Prácticas de Seguridad e Insider. Procedemos a describirlas y posteriormente a especificar las principales estrategias para tratar con ellas.

Tipos de amenazas

1. Malas Prácticas de Seguridad

  • Una organización puede no tener el conocimiento de seguridad requerido por sus activos para que estos alcancen los estándares de seguridad que requieren, facilitándolos inconscientemente a entidades externas

  • Las prácticas de seguridad llevadas a cabo por cada uno de los empleados para administrar sus credenciales y medios de acceso pueden ser inseguras a pesar de su conocimiento

2. Insider

  • Un empleado puede aprovecharse de sus privilegios para causar daño a la organización

  • Un agente externo puede hacerse pasar por un miembro de la organización

Medidas de seguridad

  1. Los miembros de la organización deben ser educados en los principios y prácticas de seguridad que deben cumplirse tanto en la administración de sus credenciales y accesos como en la implementación de aplicaciones y manejo de los activos de la organización

  2. Mecanismos de autenticación seguros y eficientes deben implementarse e imponerse para impedir en la medida de lo posible, el acceso indebido tanto a los activos digitales como físicos de la organización.

    Mediante AWS Single Sign On los permisos que posee cada usuario pueden ser más eficientemente administrados debido a que éstos estarán asociados al mismo IAM User que lo identificará como el mismo individuo. Se respetará con mayor facilidad el Principio de Menor Privilegio al tener mayor claridad y control acerca de los permisos de cada usuario en las distintas cuentas que este usuario posee, pero también el Principio de Minimizar la Superficie de Ataque dado que este usuario podrá tener configurada de manera más eficiente mayores medidas de seguridad a su acceso Single Sign On.

    Esta regla del Vector Organización nos muestra que siempre y cuando un único acceso cumpla con el Principio de Defensa en Profunididad (uso de segundo factor y una contraseña fuerte en este caso) éste podrá reemplazar a todoslos demás accesos para acceder a todas nuestras cuentas, con lo que el Principio de Minimizar la Superficie de Ataque se antepondrá al Principio de Menor Privilegio.


    AWS Single Sign On permite poseer un único punto de acceso para todas las cuentas de AWS y a las aplicaciones que posean habilitada esta funcionalidad como aplicaciones de productividad de Office 365 y aplicaciones SAML desarrolladas por la misma organización. AWS Single Sign On puede ser integrado con Microsoft Active Directory para que en este esté configurada la funcionalidad de Single Sign On. Obtenida desde aws.

  3. Deben emplearse mecanismos para administrar eficientemente los permisos que posee cada empleado, de manera que cada uno sólo posea los mínimos necesarios, pero no menos. Al emplear plataformas como AWS para desplegar sus aplicaciones, se obtiene la posibilidad de que cada acción tenga un permiso asociado.

    Sin embargo, el especificar cada acción de grano fino permitida para cada usuario no permite revisar los permisos que tiene cada usuario y modificarlos en el tiempo de manera eficiente. Es por esto que el servicio IAM de AWS provee políticas con conjuntos de permisos predeterminados, asociados a roles típicamente asumidos para administrar los distintos servicios disponibles. De este modo es posible revisar fácil y eficientemente las políticas de seguridad asociadas a cada usuario.

  4. Debe poder verificarse de manera eficiente la información de acceso a todos los servicios de la organización, en idealmente un mismo lugar

    AWS Cloudtrail registra todo acceso y acción realizada al interior de toda cuenta AWS al interior de una organización, y puede ser integrado con AWS CloudWatch para disparar alarmas en caso de que se detecten eventos predefinidos


    Es posible definir un AWS IAM Access Analyser sobre recursos específicos para que cuando AWS CloudTrail genere eventos sobre su uso, estos sean despachados a un AWS IAM Access Analyser que se encargará de analizarlo, y en caso de que corresponda sean informados mediante email, sea registrado como un evento “Especial” en AWS Security Hub, y una AWS Lambda sea invocada para que tome medidas automatizadas. Obtenida desde aws.

  5. Deben configurarse alertas de seguridad para cada uno de los eventos de seguridad detectables al interior de los activos de la organización. Una organización que no está atenta a las amenazas específicas que atentan contra sus activos difícilmente podrá reaccionar a ellos, ni remediarlos, ni evitar que estos vuelvan a suceder.

    Adicionalmente una organización debe apuntar a automatizar en la medida de lo posible la respuesta a cada una de estas alertas. AWS Security Hub mantiene una lista priorizada de las alertas de seguridad y del cumplimiento de los estándares industriales de seguridad de todas las cuentas AWS que han sido configuradas bajo la cuenta raíz de una organización. De este modo las alertas de seguridad que hayan sido configuradas podrán ser estudiadas con todos sus pormenores en el panel de este servicio, y automatizar su respuesta mediante su integración con AWS Lambda y AWS Step Functions, además de en este mismo servicio dar seguimiento al progreso del cumplimiento de los estándares de seguridad de la organización en su totalidad.


    AWS Security Hub integra información desde los distintos servicios de seguridad de AWS y puede disparar alertas para que estas sean comunicadas mediante AWS SNS, y procedimientos de AWS Lambda y AWS Systems Manager entre otros sean iniciados para tomar medidas automatizadas. Obtenida desde youtube.com.

Zero Trust

Las medidas de seguridad aquí presentadas están alineadas con el paradigma actual de seguridad llamado Zero Trust, el que enuncia que las amenazas pueden venir de todos los frentes y que debe hacerse lo posible en términos de seguridad para que estas no cumplan su objetivo. Este paradigma se diferencia del paradigma “Castillo y foso” en el que todo aquel que se encuentra al interior de la VPN organizacional es confiado por defecto sin restricciones.

Muchas de las organizaciones actuales todavía poseen un modelo de seguridad “Castillo y Foso” en el que al interior de una VPN no existe autenticación diferenciada por usuario para los distintos recursos existentes, de manera que si un atacante logra ingresar a la VPN podrá acceder a un número ilimitado de recursos y su actividad no será monitorizada, registrada ni detectada. Por el contrario, el modelo Zero Trust promueve la autenticación diferenciada, analisis de comportamiento y registro de actividad de cada miembro de la organización. Obtenida desde mobile-mentor.com

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

Referencias

  1. AWS Single Sign On: AWS Single Sign-On | Servicio de identidades del personal | AWS

  2. AWS Cloudtrail: AWS CloudTrail – Amazon Web Services

  3. AWS IAM Access Analyser: Análisis de acceso de AWS Identity & Access Management - Amazon Web Services

  4. AWS Security Hub: AWS Security Hub | Amazon Web Services (AWS)

  5. AWS Lambda: AWS Lambda – Características del producto

  6. AWS SNS: AWS | Servicio de notificaciones Push (SNS)

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

3 Me gusta