Las amenazas a la ciberseguridad hoy en día son omnipresentes e implacables. A medida que se digitalizan más facetas de nuestras vidas, mayor es el riesgo para los ciberdelincuentes: hay demasiado código que mantener seguro y los datos privados son demasiado valiosos. Y, bueno, tratar de mantenerse al día y defender cada aspecto de la superficie de ataque después de que los programas se desplieguen se ha vuelto casi imposible.

Hay enfoques que pueden aliviar algunos de estos síntomas, y uno de ellos es evidente cuando las organizaciones astutas adoptan el concepto de Infraestructura como Código (IaC). Por supuesto, como en cualquier desarrollo, hay que sortear algunos escollos de seguridad. Y puesto que los desarrolladores están trabajando en el código que genera la infraestructura vital para albergar las aplicaciones, la concienciación sobre la seguridad es fundamental en cada etapa del proceso.

Así que, ¿cómo podría un desarrollador nuevo en un entorno de servidor en la nube ir a la actualización, aprender las cuerdas, y acercarse a la construcción con una mayor conciencia de seguridad? Hemos creado la siguiente serie Coders Conquer Security para abordar las vulnerabilidades comunes de IaC, y estos próximos blogs se centrarán en los pasos que usted, el desarrollador, puede tomar para comenzar a desplegar una infraestructura segura como código en su propia organización.

Empecemos.

Hay una fábula del viejo oeste americano sobre un hombre que tenía la paranoia de que los bandidos atacarían y robarían su granja. Para compensar, invirtió en todo tipo de medidas de seguridad, como la instalación de una puerta delantera extrafuerte, la colocación de tablas en todas las ventanas y el mantenimiento de muchas armas al alcance de la mano. Aun así, una noche le robaron mientras dormía porque se olvidó de cerrar la puerta lateral. Los bandidos simplemente encontraron la seguridad desactivada y se aprovecharon rápidamente de la situación.

Tener elementos de seguridad deshabilitados en tu infraestructura es muy parecido. Aunque tu red cuente con una sólida infraestructura de seguridad, de poco sirve si hay elementos desactivados.

Permítanme plantear un reto antes de entrar en materia:

Visite el enlace anterior, y será transportado a nuestra plataforma de formación gamificada, donde puede intentar vencer una vulnerabilidad de la función de seguridad desactivada ahora mismo. (Atención: Se abrirá en Kubernetes, pero utiliza el menú desplegable y podrás elegir entre Docker, CloudFormation, Terraform y Ansible).

¿Qué tal te ha ido? Si aún te queda trabajo por hacer, sigue leyendo:

Las funciones de seguridad pueden desactivarse por diversas razones. Con algunas aplicaciones y frameworks, pueden estar deshabilitadas por defecto y deben ser activadas primero para empezar a funcionar. También es posible que los administradores hayan deshabilitado funciones de seguridad específicas para poder realizar más fácilmente ciertas tareas sin ser cuestionados o bloqueados constantemente, (por ejemplo, hacer público un cubo de AWS S3). Una vez finalizado su trabajo, es posible que se olviden de reactivar esas funciones deshabilitadas. También es posible que prefieran dejarlas desactivadas para facilitar su trabajo en el futuro.

Por qué los elementos de seguridad desactivados son tan peligrosos

Tener una o más funciones de seguridad desactivadas es malo por un par de razones. Por un lado, la característica de seguridad se puso en los recursos de la infraestructura para proteger contra un exploit, una amenaza o una vulnerabilidad conocida. Si está desactivada, no podrá proteger tus recursos.

Los atacantes siempre intentarán encontrar primero las vulnerabilidades fácilmente explotables y pueden incluso utilizar un script para recorrer las debilidades más comunes. No es diferente a un ladrón que comprueba todos los coches de una calle para ver si alguna puerta está abierta, lo que es mucho más fácil que romper una ventana. Los hackers podrían sorprenderse al descubrir que una defensa de seguridad común está inactiva. Pero cuando eso ocurra, no tardarán en explotarla.

En segundo lugar, tener una buena seguridad y luego desactivarla crea una falsa sensación de seguridad. Los administradores pueden pensar que están protegidos de las amenazas comunes si no saben que alguien desactivó esas defensas.

Como ejemplo de cómo un atacante podría aprovecharse de una característica de seguridad desactivada, considere la característica de seguridad de AWS S3 de bloquear el acceso público. Con el bloqueo del acceso público de Amazon S3, los administradores de cuentas y los propietarios de cubos pueden establecer fácilmente controles centralizados para limitar el acceso público a sus recursos de Amazon S3. Sin embargo, algunos administradores que se encuentran con problemas al acceder al bucket de S3 deciden hacerlo público para completar la tarea lo antes posible. Si se olvidan de habilitar esa función de seguridad, un atacante tendrá acceso completo a la información almacenada en ese bucket de S3, lo que provocará no solo la divulgación de información, sino también costes adicionales debido a los gastos de transferencia de datos.

Comparemos un poco de código del mundo real; echa un vistazo a estos fragmentos de CloudFormation:

Vulnerable:

CorporateBucket:
Tipo: AWS::S3::Bucket
Propiedades:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Seguro:

CorporateBucket:
Tipo: AWS::S3::Bucket
Propiedades:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Evitar los elementos de seguridad desactivados

Evitar que las funciones de seguridad deshabilitadas perjudiquen a su organización es tanto una cuestión de política como de práctica. Debe existir una política firme que establezca que las funciones de seguridad sólo deben desactivarse en circunstancias muy específicas. Los incidentes en los que las funciones deban ser desactivadas temporalmente para trabajar en un problema o actualizar las aplicaciones deben ser registrados. Una vez finalizado el trabajo necesario, se debe comprobar que las funciones se han reactivado por completo.

Si hay que desactivar permanentemente una función de seguridad para agilizar las operaciones, hay que proporcionar otras protecciones a los datos afectados para garantizar que los hackers no puedan acceder a ellos en ausencia de la protección por defecto. Si se ha desactivado una función de protección necesaria, es sólo cuestión de tiempo que un atacante encuentre esa puerta desbloqueada y aproveche la situación.

Aprende más, desafíate a ti mismo:

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad.

¿Preparado para encontrar y solucionar esta vulnerabilidad ahora que has leído el post? Es hora deprobar un reto de seguridad gamificado en la plataforma Secure Code Warrior para mantener todas tus habilidades de ciberseguridad afinadas y actualizadas.

Esta es una serie semanal que cubre nuestras ocho principales vulnerabilidades de la Infraestructura como Código; ¡regrese la próxima semana para ver más!