Los codificadores conquistan la infraestructura de seguridad como serie de códigos: funciones de seguridad deshabilitadas

Las amenazas a la ciberseguridad en estos días son omnipresentes e incesantes. A medida que se digitalizan más facetas de nuestras vidas, más arriesgan los ciberdelincuentes: hay demasiado código que proteger y los datos privados son demasiado valiosos. Y, bueno, tratar de mantenerse al día y defender todos los aspectos de la superficie de ataque una vez desplegados los programas se ha vuelto casi imposible.

Existen 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 ocurre con cualquier desarrollo, existen algunos obstáculos de seguridad que sortear. Y dado que los desarrolladores están trabajando en el código que genera la infraestructura vital para alojar las aplicaciones, la concienciación sobre la seguridad es fundamental en cada etapa del proceso.

Entonces, ¿cómo haría exactamente un desarrollador nuevo en un entorno de servidor en la nube para mejorar sus habilidades, aprender los entresijos y abordar la construcción con una mayor conciencia de seguridad? Hemos creado la próxima serie Coders Conquer Security para abordar las vulnerabilidades más comunes de IaC, y los próximos blogs se centrarán en las medidas que usted, el desarrollador, puede tomar para empezar a implementar una infraestructura segura como código en su propia organización.

Vamos a empezar.

Hay una fábula del Viejo Oeste estadounidense sobre un hombre que estaba paranoico pensando que los bandidos atacarían y robarían su casa. Para compensarlo, invirtió en todo tipo de medidas de seguridad, como instalar una puerta de entrada muy fuerte, tapar todas sus ventanas y tener muchas armas al alcance de la mano. Todavía le robaron una noche mientras dormía porque se olvidó de cerrar la puerta lateral. Los bandidos simplemente encontraron la seguridad desactivada y rápidamente se aprovecharon de la situación.

Tener las funciones de seguridad deshabilitadas en su infraestructura es muy parecido a eso. Incluso si su red cuenta con una infraestructura de seguridad sólida, no sirve de mucho si se han desactivado algunos elementos.

Permítanme plantear un desafío antes de sumergirnos:

Visita el enlace de arriba y accederás a nuestra plataforma de formación gamificada, donde podrás intentar eliminar una vulnerabilidad de una función de seguridad desactivada ahora mismo. (Atención: Se abrirá en Kubernetes, pero usa el menú desplegable y podrás elegir entre Docker, CloudFormation, Terraform y Ansible).

¿Cómo te fue? Si aún tienes trabajo por hacer, sigue leyendo:

Las funciones de seguridad se pueden desactivar por diversos motivos. Algunas aplicaciones y marcos pueden estar deshabilitadas de forma predeterminada y primero deben activarse para que empiecen a funcionar. También es posible que los administradores hayan desactivado funciones de seguridad específicas para poder realizar determinadas tareas con mayor facilidad sin tener que enfrentarse a desafíos o bloqueos constantes (por ejemplo, hacer público un bucket de AWS S3). Una vez finalizado su trabajo, es posible que se olviden de reactivar las funciones deshabilitadas. También es posible que prefieran dejarlas apagadas para facilitar su trabajo en el futuro.

Por qué las funciones de seguridad deshabilitadas son tan peligrosas

Tener una o más funciones de seguridad deshabilitadas es malo por un par de razones. Por un lado, la función de seguridad se incluyó en los recursos de la infraestructura para protegerla contra un exploit, una amenaza o una vulnerabilidad conocidos. Si está deshabilitada, no podrá proteger sus recursos.

Los atacantes siempre intentarán encontrar primero las vulnerabilidades que puedan explotarse fácilmente e incluso pueden utilizar un script para analizar las debilidades más comunes. Es como 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 piratas informáticos se sorprenderán al descubrir que una defensa de seguridad común está inactiva. Pero cuando eso suceda, no tardarán mucho 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 contra las amenazas más comunes si no saben que alguien ha desactivado esas defensas.

Como ejemplo de cómo un atacante podría aprovechar una función de seguridad deshabilitada, considere la función 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 buzones pueden configurar fácilmente controles centralizados para limitar el acceso público a sus recursos de Amazon S3. Sin embargo, algunos administradores que tienen problemas para acceder al bucket de S3 deciden hacerlo público para completar la tarea lo antes posible. Si se olvida de habilitar esa función de seguridad, el atacante tendrá acceso total a la información almacenada en ese bucket de S3, lo que no solo provocará la divulgación de la información, sino que también incurrirá en costes adicionales debido a los gastos de transferencia de datos.

Comparemos algunos códigos del mundo real; consulte estos fragmentos de CloudFormation:

Vulnerable:

Cubo corporativo:
Tipo: AWS: :S3: :Bucket
Propiedades:
Configuración del bloque de acceso público:
blockPublicACLS: falso
BlockPublicPolicy: falso
ignorePublicacls: falso
restrictPublicBuckets: falso
Configuración de control de versiones:
Estado: Activado
Cifrado de cubos:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor por defecto:
Algoritmo SSE: «AES256"

Seguro:

Cubo corporativo:
Tipo: AWS: :S3: :Bucket
Propiedades:
Configuración del bloque de acceso público:
BlockPublicACLS: verdadero
BlockPublicPolicy: verdadero
ignorePublicacls: verdadero
RestrictPublicBuckets: verdadero
Configuración de control de versiones:
Estado: Activado
Cifrado de cubos:
Configuración de cifrado del lado del servidor:
- Cifrado del lado del servidor por defecto:
Algoritmo SSE: «AES256"

Prevenir las funciones de seguridad deshabilitadas

Impedir que las funciones de seguridad deshabilitadas perjudiquen negativamente 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 solo deben deshabilitarse en circunstancias muy específicas. Deben registrarse los incidentes en los que las funciones deban deshabilitarse temporalmente para solucionar un problema o actualizar las aplicaciones. Una vez completado el trabajo necesario, se deben comprobar las funciones para asegurarse de que se han reactivado por completo.

Si una función de seguridad debe deshabilitarse permanentemente para agilizar las operaciones, se deben proporcionar otras protecciones a los datos afectados para garantizar que los piratas informáticos no puedan acceder a ellos si no existe la protección predeterminada. Si se ha desactivado una función de protección necesaria, solo es cuestión de tiempo que un atacante encuentre la puerta abierta y aproveche la situación.

Obtenga más información, desafíese a sí mismo:

Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas y vulnerabilidades de seguridad.

¿Está listo para encontrar y corregir esta vulnerabilidad ahora que ha leído la publicación? ¡Es hora de hacerlo!Pruebe un desafío de seguridad gamificado para iMac en la plataforma Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Esta es una serie semanal que cubre nuestras ocho principales vulnerabilidades de infraestructura como código. ¡Vuelva la semana que viene para obtener más información!