7 WAY SECURITY https://www.7waysecurity.co Tecnologías digitales innovadoras Sat, 10 Apr 2021 23:47:36 +0000 es-CO hourly 1 https://wordpress.org/?v=5.7.1 https://www.7waysecurity.co/wp-content/uploads/2020/08/cropped-Icon_C7-1-32x32.png 7 WAY SECURITY https://www.7waysecurity.co 32 32 Más allá de DevSecOps https://www.7waysecurity.co/mas-alla-de-devsecops-2/ https://www.7waysecurity.co/mas-alla-de-devsecops-2/#respond Sat, 10 Apr 2021 21:40:28 +0000 https://www.7waysecurity.co/?p=3997 Últimamente muchos de los requerimientos de nuestros clientes han estado muy enfocados en buscar soluciones para sus necesidades de pentesting en sus líneas de integración y desarrollo continuo, por lo que hemos generado propuestas desde nuestros servicios de Pentest as a Service, Pentest Serial y Pruebas de Intrusión Avanzadas continuas por demanda, dependiendo de las necesidades propias de cada uno de ellos. Hasta el momento el modelo se encuentra enfocado en la ejecución de pruebas de seguridad a aplicaciones de manera dinámica (DAST) y pruebas de seguridad a aplicaciones de manera estática (SAST), siempre en busqueda de realizar una intervención lo antes posible en el proceso de desarrollo, con el fin de poder identificar y remediar las vulnerabilidades de manera temprana, otra variable que hemos tenido que tener en cuenta es el nivel de madurez existente en el proceso de DevOps con el fin de proponer el servicio que más se acomode a las necesidades de integración de seguridad en todo el proceso.

Sin embargo es interesante ver que el proceso de DevSecOps como se ha presentado hasta el momento en nuestro mercado está muy enfocado en la ejecución de pruebas para realizar una revisión de los componentes de desarrollo o infraestructura lo antes posible dentro del proceso de programación, pero cabe la pena resaltar la importancia de la implementación de un modelo de DevSecOps que integre diferentes capas de protección como lo son:

  • Análisis de Código Estático – revisión de vulnerabilidades directamente en el código fuente, posibles errores relacionados a malas prácticas de programación
  • Administración de Cambios – Información detallada de la toma de decisiones frente a cualquier cambio en el proyecto
  • Monitoreo de Cumplimiento – Revisión de elementos regulatorios dentro del proceso de DevOps, con revisiones periódicas en puntos identificados dentro del pipeline
  • Investigación de Amenazas – Validación continua de las amenazas a las que se enfrentan los proyectos y su valoración con respecto al impacto al negocio
  • Identificación de Vulnerabilidades – Revisión de vulnerabilidades de manera dinámica en el código y revisión de configuraciones inseguras en la infraestructura
  • Entrenamiento en Seguridad – Generación de capacidades para todo el personal involucrado en el equipo de DevOps relacionada a seguridad

Dentro del proceso de análisis de código y como parte de nuestro servicio, realizamos una revisión de la calidad de código que es publicado de manera constante y en pequeños lotes, haciendo uso de herramientas automatizadas, con una revisión manual de los hallazgos, realizado por nuestro equipo técnico, lo cual minimiza los falsos positivos y permite una interacción con el equipo de desarrollo, para explicar las vulnerabilidades identificadas.

Desde nuestra plataforma de vigilancia digital Cattleya hemos encontrado en numerosas ocasiones llaves privadas o información de APIs expuesta directamente en Internet, lo cual muchas veces sucede por no realizar una revisión automatizada en las versiones de control de las aplicaciones dentro de las pruebas enfocadas en el análisis de código.

Dentro de la revisión que se debe llevar a cabo en la administración de cambios se deben tener en cuenta componentes como:

  • Generar responsabilidades dentro de los equipos de desarrollo para que que mejoren sus prácticas de seguridad y generen cambios dentro de los procesos continuos de desarrollo
  • Definir los procesos de revisión rápida y aprobación para los cambios realizados en el código
  • La generación y definición de elementos de control de cambios que permitan una trazabilidad dentro de todos los procesos
  • Por último, pero no menos importante, el cumplimiento de regulaciones establecidas para cada una de las industrias, dependiendo de la información manejada dentro de los desarrollos

En la etapa de monitoreo relacionado a cumplimiento es fundamental definir puntos de control que permitan comprobar que los elementos definidos como mejores prácticas y requerimientos de seguridad del proceso se estén cumpliendo, esta etapa debe incluir la definición de políticas estrictas de contraseñas, el monitoreo del sistema ante acciones maliciosas, la auditoría de las actualizaciones de código en repositorios, el cumplimiento de requerimientos de desarrollo seguro, y la higiene que se debe tener en cuenta en el código tanto a nivel de programación como a nivel de seguridad.

Un componente poco explorado en el concepto de DevSecOps es el relacionado a investigaciones de amenazas, comprensión de las mismas para el modelamiento correcto dentro de los proyectos de desarrollo, dentro de esta etapa se deben incluir tareas como las expuestas a continuación:

  • Monitoreo de la aplicación e infraestructura para la identificación de amenazas 
  • Controles y alertas en tiempo real construidas dentro del código para la identificación de posibles intrusiones
  • Construcción de playbooks en lenguajes como ansible con escenarios de respuesta para situaciones que se puedan presentar en infraestructura y seguridad
  • Elementos de telemetría que permitan la identificación de compromisos

En la etapa de identificación de vulnerabilidades aplicamos dentro de nuestros servicios tareas como; ejecución de escaneos de vulnerabilidades en infraestructura y código, revisiones continuas de los productos a medida que se adicionan nuevas funcionalidades o se generan nuevas versiones, pruebas de penetración, pero el componente más importante para esta etapa es la definición de tiempos para la mitigación de hallazgos y la comunicación continua con los equipos de desarrollo para lograr la comprensión de las vulnerabilidades y su mitigación efectiva.

Todo este modelo no es posible sin un componente transversal para los equipos de DevOps enfocado en el entrenamiento y adquisición de habilidades para mejorar el proceso donde se deben realizar tareas como:

  • Transformación del equipo de desarrollo tradicional en un equipo de desarrollo seguro
  • Participación de los equipos de desarrollo en conferencias de seguridad
  • Inversión en entrenamientos y certificaciones de seguridad
  • Educación y sensibilización de los equipos involucrados en DevOps en la comprensión de riesgos
  • Preparación de todos los equipos ante la respuesta a incidentes

El desarrollo de un plan de DevSecOps no se debe enfocar solo en la realización de pruebas de seguridad dinamica o estatica, debe contener diferentes elementos que le permitan fortalecerse a través del tiempo y entender los diferentes desafíos de seguridad a los que se deben enfrentar los desarrollos realizados por los equipos de DevOps.

]]>
https://www.7waysecurity.co/mas-alla-de-devsecops-2/feed/ 0
Ya hicimos el pentest, ahora… ¿Como documentamos? https://www.7waysecurity.co/ya-hicimos-el-pentest-ahora-como-documentamos/ https://www.7waysecurity.co/ya-hicimos-el-pentest-ahora-como-documentamos/#respond Sat, 10 Apr 2021 21:29:30 +0000 https://www.7waysecurity.co/?p=3990 A la mayoría de pentesters nos ha pasado que finalizamos la ejecución de un pentest y llegamos al punto menos placentero, la documentación,lo ideal y la manera que nos ha dado mejor resultado en CSIETE/7WS ha sido documentar en tiempo real lo que transcurre en el desarrollo de las pruebas, algo rápido para no perder el hilo y el contexto de los hallazgos, así una vez finalizadas las pruebas es mucho más fácil, rápido y efectivo retomar la construcción de los informes (Técnico/ejecutivo) para entregarle al cliente, la estructura de estos informes está definida por el framework o la metodología utilizada para desarrollar las pruebas, existen diferentes tipos, entre los que encontramos:

  • ISSAF (Information Systems Security Assessment Framework)
  • PCI DSS (Payment Card Industry Data Security Standard)
  • OSSTMM (Manual de la Metodología Abierta de Testeo de Seguridad)
  • PTES (Penetration Testing Execution Standard)

Esta última (PTES) es la empleada por CSIETE/7WS, la cual hemos ido adaptando a las necesidades específicas de los clientes presentando los informes técnicos y ejecutivos con una estructura predeterminada que está compuesta por una introducción, detalles del proyecto, insumos, accesos, resumen y detalles de los hallazgos, resultados generales de las pruebas, recomendaciones y conclusiones.

La construcción de estos informes debe tener un nivel de detalle para que pueda ser entendido por una persona técnica, pero también debe tener una simplicidad que permita que una persona que se encuentre en otra área entienda los hallazgos identificados, es por esto que lo ideal es entregar dos informes uno técnico, con la evidencia de los hallazgos, la explicación detallada de lo identificado y las recomendaciones pertinentes y un informe ejecutivo, este con más gráficas, números, resultados y conclusiones generales.

Consideramos que la mejor forma de redactar un informe, es escribirlo en tercera persona, en presente simple, la introducción debe presentar a grandes rasgos qué se verá en el informe, qué se estaba evaluando, en qué tiempo, bajo qué modalidades (caja negra, caja gris) y debe contener una gráfica de la aplicación o infraestructura evaluada, una pequeña descripción de su flujo y de lo que le permite realizar a sus usuarios, luego de tener lista la introducción, se procede con el resumen y el detalle de los hallazgos, para esto deben responderse las que en inglés conocemos como las 5WH:

  • ¿Qué?
  • ¿Por qué?
  • ¿Cuándo?
  • ¿Dónde?
  • ¿Cómo?

Aquí un ejemplo de cómo debería ser la documentación de un hallazgo identificado a un público con conocimientos técnico:

“Se identifica qué hace falta un control en el manejo de errores emitidos por el servidor, pues al momento de realizar una petición con parámetros mal formados de manera intencional, el servidor entrega información que permite identificar la ruta interna donde se encuentra alojada esta aplicación, además de esto en los headers de respuesta es posible identificar la tecnología web utilizada con su versión y sistema operativo”.

Aquí un ejemplo de cómo debería ser la documentación de un hallazgo identificado a un público sin conocimientos técnico:

“Se identifica qué hace falta un control en el manejo de errores emitidos por el servidor, pues al momento de realizar una consulta con datos erróneos o para los cuales se sabe que no se obtendrá una respuesta correcta, entrega información sensible de su configuración que permite identificar detalles internos”.

Impacto: Un atacante podría perfilar fácilmente las tecnologías usadas en la plataforma y buscar vectores de ataque sobre las versiones y rutas identificadas.

Es importante presentarle al cliente el impacto que este hallazgo representa para su compañía, qué podría realizar un atacante si hace uso de esta debilidad.

La evidencia debe tomarse lo más clara posible, los pantallazos deben ser legibles, claros y el título o descripción debe presentar el panorama evaluado.

Imagen 1. Se evidencia que se emplea el servidor nginx en su versión 1.14.0

Imagen 2. Se evidencia la versión 7.6.3.3 del servidor CompaqHTTPServer

Para finalizar el detalle de los hallazgos es importante entregarle al cliente, mínimo tres recomendaciones, las cuales son de suma importancia y fundamentales para mitigar de manera correcta las vulnerabilidades identificadas, con el fin de que el cliente tenga mayor claridad sobre el ¿qué? Y el ¿dónde? se deben Implementar los controles y/o tomar acciones.

Desde CSIETE/7WS se recomienda referenciar cada hallazgo si corresponde con el top 10 de OWASP, CVE, CWE, CVSSCORE o siguiendo las metodologías anteriormente mencionadas.

Para las conclusiones es importante hacer una lectura general de los hallazgos identificados, presentando la valoración del nivel de riesgo en que se encuentra el objetivo evaluado. Exponiendo todo lo que se pudo identificar, que se tiene implementado en cuanto a capacidades técnicas, controles, infraestructura y demás y finalmente decir si es aceptable o no el paso a un ambiente de producción o si, por el contrario, este ya se encuentra desplegado en producción se deban tomar medidas de seguridad lo antes posible, pues se encuentra en riesgo la disponibilidad, confidencialidad e integridad de la información.

]]>
https://www.7waysecurity.co/ya-hicimos-el-pentest-ahora-como-documentamos/feed/ 0