Roberto Velasco

DevSecOps, también conocida como SecDevOps, es una filosofía de desarrollo de software que promueve la adopción de la seguridad en todo el ciclo de vida del desarrollo de software (SDLC). DevSecOps va más allá de ser una herramienta o una práctica en concreto; favoreciendo la automatización de la seguridad, la comunicación y la escalabilidad. DevSecOps nace como evolución de la metodología DevOps. Su principal motivación es automatizar la seguridad para responder a la aceleración en los ciclos de lanzamiento de software promovida por la adopción de DevOps. DevSecOps no solo añade elementos de seguridad a ciclos DevOps, sino que aplicada correctamente, hace de la seguridad una parte integral dentro de todo el proceso, desde el inicio hasta el final. Como consecuencia, el equipo de seguridad se compromete mucho más con el resto de equipos que intervienen en el SDLC, incluyendo Desarrollo y Operaciones. Esto elimina fricción, ya que la tensión natural que existe entre velocidad y seguridad se comparte por todos los equipos. A pesar de, o tal vez debido, a su gran adopción, la metodología DevSecOps recibe críticas a su falta de concreción o guías específicas. En este post, queremos ofrecer siete consejos directamente aplicables que resuelven los problemas más habituales que observamos en los equipos que adoptan DevSecOps. 1. Utilizar herramientas IAST para evitar falsos positivos y la puesta a punto de los SAST Las herramientas Application Security Testing (AST), tipo SAST y DAST permiten a los desarrolladores encontrar vulnerabilidades, sin que sean expertos en seguridad. El problema es que, debido a enfoques anticuados y poco sofisticados, estas herramientas no ofrecen un nivel de precisión ideal. Para evitar esta falta de precisión, recomendamos la utilización de una herramienta de detección más precisa como es un IAST (Interactive Application Security Testing). Las herramientas IAST no requieren de una “puesta a punto” o revisiones manuales ya que no generan falsos positivos. 2. Integrar fallos de seguridad en las herramientas de colaboración para mejorar la coordinación Integra el sistema de seguimiento de errores (“bug tracker”) que tu equipo esté utilizando, por ejemplo Jira, con las herramientas de seguridad para que los desarrolladores puedan visualizar los errores de seguridad como tareas habituales. El objetivo detrás de esta recomendación es que los desarrolladores no se alejen del entorno que utilizan habitualmente. 3. Definir métricas y umbrales para asegurar la calidad si la cadencia de despliegues acelera De la misma forma que los errores de compilación paralizan el despliegue, los errores de seguridad también deberían hacerlo. Conocidos como “controles de seguridad” estos checkpoints aseguran que el código que llegue al CI/CD respete los estándares de seguridad. Crea checkpoints automáticos de seguridad para cumplir los objetivos de calidad, y paraliza el build si el número de vulnerabilidades sobrepasa un límite. 4. Automatizar la protección de errores de diseño para reducir la verificación manual (pentesting) Para mitigar el cuello de botella que supone verificar manualmente estos errores, recomendamos automatizar la validación utilizando soluciones y arquitecturas que sean seguras desde el inicio. Los equipos de pentesters son más productivos cuando tienen una imagen clara de las zonas donde atacar. 5. Adoptar reporting continuo para ganar visibilidad sobre el histórico de la seguridad El reporting continuo implica la generación de informes y métricas de seguridad que rastreen la evolución, el número y la severidad de las vulnerabilidades de cada lanzamiento. El objetivo es mitigar la falta de visibilidad sobre el histórico de la seguridad a medida que se van publicando nuevas versiones del software. Es recomendable utilizar herramientas como Jenkins Reports o Web Reports y mejorar los informes incluyendo la evolución de los fallos de seguridad. 6. Integrar la seguridad en las aplicaciones para mejorar el soporte a cloud Adoptar “seguridad como código”, frente a enfoques dependientes de hardware o de entorno de red, significa que las aplicaciones se mantienen seguras allá donde vayan, sin necesidad de cambios de configuración para adaptarse a un nuevo despliegue o a una nueva versión de la aplicación. 7. Asegurar la escalabilidad lineal y costes asequibles Asegúrate de que la infraestructura de seguridad de tu aplicación no es un cuello de botella en lo que a rendimiento se refiere. Busca soluciones de seguridad que puedan escalar de forma constante y lineal en el tiempo. Las siete recomendaciones que hemos expuesto en este artículo tienen como principal objetivo fortalecer a los desarrolladores para que puedan crear código de forma segura gracias a la automatización de la seguridad. Hdiv Security fue creada por y para desarrolladores desde sus inicios. Las claves descritas en este artículo, e incluso nuestro ADN como empresa, han perseguido siempre la filosofía DevSecOps incluso antes de que el término existiese. Para cualquier consulta relacionada con la automatización de la seguridad en aplicaciones, no dudes en contactar con nosotros.

El problema Uno de los mitos más arraigados que observamos en el mundo de la ciberseguridad, sobretodo en la cobertura que vemos en los medios de comunicación, pero también en nuestras conversaciones con clientes, es que para lanzar un ataque a un sistema informático es necesario “investigar” y encontrar un defecto nuevo y específico para ese sistema. Sin embargo, en la mayoría de los incidentes de seguridad que afectan a aplicaciones en internet, tan frecuentes en los últimos años, los atacantes no necesitan descubrir nuevos errores de software, ¡y les basta con explotar errores de programación ya conocidos! Por ejemplo, la escandalosa brecha de Equifax, uno de los incidentes que más repercusión ha tenido, se podía haber prevenido si se hubieran seguido normas de seguridad básicas, como parchear su aplicación contra vulnerabilidades conocidas. Y no lo decimos nosotros, ese fue el resultado de la investigación forense del gobierno federal estadounidense. Por tanto, una manera muy importante de reducir los riesgos de seguridad es asegurar que, desde la fase de desarrollo de software, se detecten y corrijan todos aquellos fallos de programación conocidos, antes de que las aplicaciones sean expuestas en entornos de producción. Además, por si fuera poco, fuentes sólidas como el NIST indican que corregir fallos de seguridad pronto resulta órdenes de magnitud más barato que hacerlo cuando el sistema está ya terminado. Pongamos un ejemplo para presentar la idea de forma más sencilla. Cuando escribimos un texto en Microsoft Word, el corrector ortográfico nos indica los errores de sintaxis que hemos cometido. Igualmente, existen soluciones de seguridad conocidas también como AST (Application Security Testing) capaces de detectar errores de sintaxis relacionados con la seguridad de la aplicación. Como resultado, los AST reportan el fichero y línea concreta donde reside la vulnerabilidad, al igual que Word reporta la página y la palabra donde reside el problema. En otras palabras, hacer uso de una herramienta de este tipo nos permite desarrollar software libre de “errores ortográficos” relacionados con la seguridad y por lo tanto mucho más seguro. ¿Os imagináis publicar un libro que contenga errores ortográficos? Impensable ¿no? Eso es exactamente lo que ocurre con gran parte del software publicado en Internet. Al no hacer uso de este tipo de herramientas de seguridad, las aplicaciones incluyen agujeros de seguridad muy básicos y por lo tanto fácilmente explotables por cualquier atacante. Veamos a continuación los diferentes tipos de “detectores de problemas de seguridad” o soluciones AST que podemos encontrar en el mercado y cuales son las ventajas de cada uno. El enfoque tradicional El mercado AST está dominado por dos tecnologías ya maduras: SAST o análisis estático de código, y DAST o análisis dinámico. Cada uno de ellos va dirigido a cubrir esta necesidad dirigido a un entorno o departamento en concreto. El análisis estático, SAST, también llamado de caja blanca debido a que la herramienta tiene acceso al código de la aplicación, recorre el código fuente buscando patrones que indican programación insegura, es decir, un potencial problema de seguridad. El análisis dinámico, DAST, por contra, sólo tiene visibilidad externa de la aplicación, es decir, tal y como un visitante o atacante vería el sistema. A partir de aquí, la herramienta lanza cientos de consultas y ataques con la intención de replicar la actividad de un atacante y encontrar las vulnerabilidades de la aplicación. La información reportada por ambas herramientas es diferente, dado que los SAST proporcionan el fichero y la línea de la aplicación donde se ubica la vulnerabilidad y los DAST proporcionan la vista dinámica de la vulnerabilidad (URL y parámetro). Por lo tanto, hasta hoy en día se han requerido de dos herramientas para poder disponer de una visión completa de la vulnerabilidad. El enfoque Interactive AST Las herramientas Interactive Application Security Testing (IAST) combinan el enfoque estático y el enfoque dinámico. Es decir, tienen acceso a la estructura interna de la aplicación, y también ven cómo la aplicación responde cuando hay tráfico. Este punto de vista privilegiado ofrece numerosas ventajas. Desde un punto de vista de arquitectura, las herramientas IAST se instalan como parte de la infraestructura que soporta las aplicaciones web, ya que se instalan como un complemento al servidor de aplicaciones. A este enfoque se llama “instrumentación”, y se realiza a través de un componente conocido como “agente.” Una vez el agente está instalado, incorpora sensores automáticos de seguridad en puntos críticos de la ejecución de la aplicación. Estos sensores monitorizan las peticiones y respuestas al servidor, las librerías externas que la aplicación usa, el acceso a recursos del servidor, y operaciones de datos como el acceso a bases de datos. Esta cobertura de “amplio espectro” supera con creces la visibilidad de herramientas SAST y DAST. Aterricemos estos conceptos en números específicos: la siguiente tabla compara dos métricas muy importantes: cuántas vulnerabilidades las diferentes tecnologías son capaces de encontrar, y cuántas resultan ser falsas (la herramienta indica una vulnerabilidad cuando ninguna existe). Pues bien, el mejor scanner dinámico (DAST) es capaz de encontrar sólo el 18% de las vulnerabilidades reales. Y peor aún, más de la mitad de las vulnerabilidades identificadas por el mejor analizador estático (SAST) resultan no ser tales! Fuente: Hdiv Security a partir de resultados públicos del test OWASP Benchmark El enfoque IAST ofrece numerosos beneficios tangibles: Cobertura completa, ya que permite analizar toda la aplicación: tanto el código propio como el código externo, también conocido como dependencias. Flexibilidad, ya que una única herramienta se adapta a todos los entornos: desarrollo, aseguramiento de calidad o testing, y producción Alta precisión, ya que la combinación de visibilidad estática y dinámica permite encontrar más vulnerabilidades, sin caer en la trampa de los falsos positivos. Información detallada de cada vulnerabilidad: estática (en lo referente al código fuente) y dinámica (en lo referente a cómo el código responde al tráfico). Reducción del plazo de verificación de la seguridad de las aplicaciones, por lo que acelera el desarrollo de aplicaciones seguras. Se adapta perfectamente a las nuevas metodologías de desarrollo, incluyendo metodologías ágiles y DevSecOps, ya que favorece la introducción de automatismos y reduce la dependencia en operaciones manuales. Debido a estas ventajas, una herramienta IAST puede complementar otras herramientas existentes en el portfolio de seguridad de las organizaciones. Conclusiones Al igual que hacemos uso de un corrector ortográfico cuando vamos a publicar un texto para detectar problemas con la sintaxis de nuestro texto, es necesario hacerlo con el software de cara a detectar problemas de seguridad. En cualquier caso, las herramientas de detección, conocidas como AST no representan una panacea, ya que solamente son capaces de detectar problemas en el software que siguen un patrón común. ¿Qué es Hdiv Security? Hdiv Security es un pionero en el mercado de protección de aplicaciones desde el año 2008, es el primer producto que ofrece protección durante el ciclo completo de desarrollo de software contra los bugs de seguridad o errores de sintaxis, a la vez que protege de los fallos en la lógica de negocio. La plataforma unificada de Hdiv simplifica la adopción de filosofías de desarrollo DevSecOps. Las soluciones de Hdiv (RASP y IAST) son utilizadas actualmente por instituciones gubernamentales, bancos, industria aeroespacial, y empresas del ranking Fortune 500. Es una empresa de capital privado y su sede está en San Sebastián (España).