Azure
es la plataforma de computación en la nube pública de Microsoft.
Uno de los principales proveedores,
superó
a Amazon Web Services (AWS)
y Google Cloud en crecimiento de implantación durante el 2021.
Como tal,
Azure ofrece herramientas y funcionalidades,
así como infraestructura,
almacenamiento y capacidad de procesamiento.
Esto permite a empresas de todos
los tamaños desarrollar aplicaciones escalables
y ahorrar costos.
Puesto que estas aplicaciones deben ser seguras,
Azure cuenta con servicios que ayudan a los usuarios
a seguir las buenas prácticas de DevSecOps.

A pesar que algunas actividades de DevSecOps
consisten en automatizar las pruebas
y actualizaciones de seguridad,
la tecnología por sí sola no es suficiente.
El mismo Azure
aconseja en el Microsoft cloud security benchmark
(MCSB)
que técnicas manuales como el
red teaming
y pentesting
deben complementar el escaneo de vulnerabilidades para descubrir riesgos.
Debería prestarse más atención a esto,
ya que nuestros hackers éticos suelen encontrar configuraciones
inseguras en los servicios en la nube.
En este artículo del blog,
hablamos sobre cómo Fluid Attacks apoya tu implementación
de Azure DevSecOps con técnicas manuales en combinación
con pruebas de seguridad automatizadas.

El modelo de responsabilidad compartida de seguridad en la nube (SRM)

Antes de pasar al tema principal de este post,
abordemos primero un tema relevante:
el modelo de responsabilidad compartida
de seguridad en la nube (SRM, por sus siglas en inglés).
No te distraeremos durante mucho tiempo.
Todo lo que necesitas recordar es que Azure,
como proveedor de servicios en la nube,
será responsable de acciones como mantener
la disponibilidad de sus servicios,
la seguridad de la infraestructura física que los soporta
y la incorporación de características
de seguridad en sus soluciones.

Pero los usuarios también tenemos que ser conscientes
de nuestras responsabilidades.
Tenemos que proteger nuestro ambiente DevOps
y desplegar aplicaciones seguras en la nube.
Por lo tanto,
tendremos que responsabilizarnos si no protegemos
la cadena de suministro de software,
no realizamos pruebas de seguridad continuas,
no configuramos los servicios correctamente, etc.
Para cumplir con esta responsabilidad,
los usuarios debemos recurrir a DevSecOps en la nube.

DevSecOps en Azure con Fluid Attacks

La cultura DevSecOps
busca unir a los equipos de desarrollo,
seguridad y operaciones desde el inicio del desarrollo de software
para construir apps más seguras.
(Explicamos en otro lugar cómo implementar DevSecOps)
En la nube,
esta cultura requiere que los equipos presten
atención lo antes posible a la configuración adecuada
de los servicios en la nube
y realicen pruebas de seguridad continuas de los archivos
de infraestructura como código (IaC)
y las imágenes de contenedores, entre otras cosas.
Este enfoque de seguridad a la izquierda facilita
y hace menos costoso resolver los problemas.

Para ayudar a sus usuarios a conseguir DevSecOps,
Azure ha proporcionado recomendaciones
para automatizar la seguridad con sus productos.
Además,
está en el centro del MCSB
publicado en octubre de 2022,
que es un cambio de marca del Azure Security Benchmark (ASB).
Este recurso proporciona controles prescriptivos
que ayudan a los usuarios a mejorar su ambiente multi-nube
y la seguridad de las cargas de trabajo,
datos y servicios en Azure.

Los controles incluidos en el MCSB
comprenden actividadespara proteger los datos,
las redes y el acceso a los recursos,
obtener visibilidad de los activos y los riesgos para estos,
y garantizar estrategias, políticas
y procedimientos de seguridad organizacionales claros.

Existen herramientas Azure DevSecOps
para ayudar a implementar estos controles.
De modo que,
por ejemplo, los equipos pueden utilizar
el servicio Azure Pipelines para CI/CD.
Esta herramienta les permite compilar y agrupar código en contenedores,
asegurando así el ambiente del desarrollador,
y tener control de versiones.
Para abordar la cuestión de la protección de datos,
redes y accesos,
Azure ofrece el servicio Azure Key Vault para almacenar claves API,
certificados, tokens, contraseñas y otros secretos,
y Azure Active Directory (Azure AD)
para gestionar la identidad y el control de acceso.

A la hora de evaluar los riesgos,
dos aspectos del MCSB merecen atención especial:
la gestión de posturas y vulnerabilidades y la seguridad de DevOps.
Estos son algunos controles que,
en nuestra opinión,
resumen las actividades de evaluación en estos dominios:

• Infraestructura DevOps segura:
  acciones como identificar cualquier error de configuración
  en áreas centrales de Azure DevOps,
  mecanismos de autenticación débiles
  y secretos en el código fuente.

• Garantizar la seguridad de la cadena de suministro de software:
  acciones como garantizar que los componentes
  de código abierto están actualizados
  y libres de vulnerabilidades conocidas.

• Integrar las pruebas de seguridad de aplicaciones estáticas (SAST)
  en el proceso DevOps:
  acciones como evaluar el código fuente y evitar
  que el código vulnerable se despliegue en producción.

• Integrar las pruebas de seguridad de aplicaciones dinámicas (DAST)
  en el proceso DevOps:
  acciones como evaluar la aplicación en tiempo de ejecución.

• Reforzar la seguridad de la carga de trabajo
  a lo largo del ciclo de vida de DevOps:
  acciones como la gestión de vulnerabilidades en imágenes de contenedores y
  dependencias a lo largo de todo el ciclo de vida de desarrollo
  de software (SDLC).

• Llevar a cabo operaciones regulares de red team:
  acciones como complementar el enfoque tradicional de escaneo
  de vulnerabilidades con pentesting y red teaming.

Azure ofrece orientación que puede abordar
algunos controles en estas áreas.
Así pues,
aconseja escanear las imágenes de los contenedores
en busca de vulnerabilidades
con Microsoft Defender for Cloud y también utilizar
las soluciones de pruebas de seguridad automatizadas
de GitHub para seguir buscando vulnerabilidades
en el código propietario
(p. ej., credenciales en el código fuente)
y en los componentes de terceros
(p. ej., bibliotecas de código abierto obsoletas).

Si se tiene en cuenta el último control de la lista anterior,
se puede ver que un enfoque centrado únicamente
en el uso de herramientas de seguridad Azure DevOps
y otro software DevSecOps se queda corto.
Una razón importante es que las herramientas automatizadas
arrojan resultados con tasas significativas de falsos positivos
y falsos negativos.
Se necesita trabajo manual para revisar los resultados
e identificar problemas que una herramienta,
por ejemplo, para SAST o DAST, no haría.

Sin ir más lejos:
en nuestro State of Attacks de 2022,
en el que mostramos los análisis de los resultados
de las pruebas de seguridad de nuestros clientes
a lo largo de un año,
descubrimos que fueron solo nuestros hackers éticos,
y no las herramientas,
quienes detectaron todas las vulnerabilidades de gravedad crítica
reportadas en los sistemas.

Como expertos en pentesting y red teaming,
ahora te mostramos cómo podemos apoyar tu implementación
de DevSecOps con estos enfoques.

Las pruebas de penetración
se realizan mediante simulaciones de ataques reales,
por ejemplo,
utilizando ataques personalizados para eludir las defensas.
Este es un excelente ejemplo de pruebas funcionales que exigen creatividad
y un conocimiento de las técnicas de los autores de amenazas actuales
que no puede lograrse mediante herramientas.
(De hecho,
sostenemos
que no existen las pruebas de penetración “automatizadas”).
Pero evaluar la aplicación desde el exterior
no es la única forma de realizar pentesting.
También existe la revisión manual del código seguro
para encontrar problemas recurrentes como credenciales
en el código fuente y errores de configuración de los servicios.
Por lo tanto,
te recomendamos que vayas más allá del consejo
de las pruebas de penetración “regulares”
y las conviertas en una actividad continua
a lo largo del SDLC.

Utilizando nuestra solución de Pentesting,
puedes disfrutar de los siguientes beneficios:

• Una comprensión más completa de las vulnerabilidades
  gracias al apoyo experto de nuestros equipo de hacking.

• Una combinación de pruebas de seguridad automatizadas
  y manuales que garantiza la detección
  de vulnerabilidades de gravedad crítica,
  arrojando tasas muy bajas de falsos positivos y falsos negativos.

• Conocimiento actualizado sobre el estado de seguridad de tu aplicación,
  solicitándonos que realicemos pentesting continuamente
  a medida que evoluciona el software nativo de la nube,
  lo que se conoce como
  pruebas de penetración como servicio (PTaaS).

• La opción de solicitar que rompamos el build
  para evitar que los builds vulnerables que violen
  las políticas de tu organización pasen a producción.

• Reataques ilimitados por parte de nuestros hackers
  sin costo adicional
  (esto es,
  para verificar si las vulnerabilidades han sido efectivamente remediadas).

Red Teaming también es una simulación de ataques reales,
pero se acerca aún más a la realidad.
Por ejemplo,
no se limita a las evaluaciones a nivel tecnológico,
sino que también incluye pruebas a nivel propiamente humano.
Esto forma parte de un enfoque holístico
para averiguar la eficacia de las estrategias de prevención,
detección y respuesta a los ataques de una organización.
Por consiguiente,
en red teaming,
los ataques se realizan con el consentimiento de la dirección ejecutiva,
pero la mayoría de las personas del equipo de respuesta a incidentes
y los empleados no son conscientes de ello.
Y otra característica que lo hace más realista
es que el red team
no se centra en encontrar todas las vulnerabilidades,
sino que se fija objetivos específicos.

Utilizando nuestra solución Red Teaming,
además de las de nuestra solución Pentesting,
puedes disfrutar de los siguientes beneficios:

• Simulaciones de ataques que son altamente realistas,
  ya que imitan las tácticas,
  técnicas y procedimientos de los atacantes.

• Una visión panorámica de la seguridad de tu organización
  a través de las evaluaciones de hackers éticos con
  certificaciones avanzadas (OSEE,
  CRTO, CRTE and CARTP).

Obtienes una visualización constantemente actualizada
de todos los hallazgos en nuestra plataforma.
En ella,
trazamos un mapa de todos los activos digitales
de tu organización y puedes realizar un seguimiento
de su exposición al riesgo a lo largo del tiempo.
También puedes ver las pruebas de explotación de vulnerabilidades técnicas,
asignar su remediación a miembros de tu equipo,
hablar con nuestros hackers para que te orienten,
y muchas otras cosas.

Ahora es el momento de comenzar Azure DevSecOps
con Fluid Attacks.
¡Contáctanos!

¿No estás seguro?
Disfruta de nuestras pruebas de seguridad automatizadas
gratuitamente durante 21 días.
Puedes cambiarte en cualquier momento
para añadir pruebas de seguridad manuales.