Coders Conquer Security Infrastructure as Code Series: Funciones de seguridad deshabilitadas
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!
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.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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!
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!
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
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!
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
