reunión. corto comedia the expert
Auditoría de código,  Desarrollo seguro

Realizando una auditoría de código: Tercera parte

En esta serie de tres artículos describo todas las tareas realizando una auditoría de código o análisis de código estático (SAST). El principal proceso llevado a cabo dentro de la gestión de desarrollo seguro de software. En esta tercera parte vemos cómo redactar el informe de auditoría, el producto entregable de nuestro trabajo y que aporta valor a este.

Si quieres leer acerca de lo que es una auditoría de código mejor empieza por este articulo en el que me centro en su descripción ¿Que es una auditoría de código?.

Si quieres ver cómo realizar una auditoría de código completa, este es el primer articulo. Primera parte

En la entrega anterior vimos la propia revisión del código. La búsqueda e interpretación de vulnerabilidades mediante tareas como la ejecución de herramientas automáticas, la lectura del código y la búsqueda por patrones. A continuación vamos a ver cómo redactar el informe de auditoría.

realizando una auditoría de código, informe

Introducción

En esta tercera parte de realizando una auditoría de código tratamos como redactar el informe de auditoría. Esta tarea es muy importante, especialmente si hemos realizado la auditoría de forma externa y no vamos a corregir la vulnerabilidades nosotros mismos como parte del equipo de desarrollo. Este es el único producto entregable de nuestro trabajo y por lo tanto el valor de este.

La división aquí sugerida para el contenido del informe cuenta con tres bloques principales: Apartados introductorios, extracto ejecutivo y resultados. Empezaremos con los apartados introductorios, estos ofrecerán al receptor del informe la ubicación y el contexto necesarios para el posterior diagnóstico de vulnerabilidades o triage.

Continuaremos con ideas sobre cómo describir en detalle las vulnerabilidades encontradas y su solución. Después veremos cómo realizar un extracto ejecutivo a modo de resumen, que ofrezca visibilidad de forma clara a cualquier persona independientemente de sus conocimientos técnicos previos.

Los apartados introductorios del informe

En la primera parte de este procedimiento veíamos las tareas a llevar a cabo para redactar estos apartados introductorios, que identifican el proyecto a auditar y predisponen la detección de vulnerabilidades. Lo más práctico es redactar este breve análisis sobre el propio informe de auditoría ya que de igual manera beneficiara al futuro lector en la comprensión de los resultados de este.

El objetivo de este primer bloque del informe será ubicar al lector sobre el componente software auditado, preparando la comprensión de este. Se conforma de un breve análisis de este y especifica la versión concreta del código y anexos sobre los que realizamos la revisión. También aclararemos las advertencias sobre elementos no auditados que quedan fuera del trabajo realizado y la metodología empleada a la que el informe se remite.

realizando una auditoría de código, icono informe

Alcance de la auditoría

En este apartado indicaremos brevemente el nombre o nombres de los componentes software que auditamos. También cualquier detalle extra que aporte información del alcance.

Descripción del componente auditado

En la primera parte de este procedimiento, veíamos cómo realizar un breve análisis del componente software objetivo de la auditoría. Esta tarea llevada a cabo al comienzo de la auditoría, nos predispone a encontrar vulnerabilidades al adquirir contexto sobre el componente, su entorno y su superficie de ataque.

Lo más práctico es redactar este breve análisis sobre el propio informe de auditoría ya que de igual manera beneficiara al futuro lector en la comprensión de los resultados de este. Este análisis debe abarcar de forma básica los principales aspectos funcionales y orgánicos.

  • Aspectos funcionales: Usuarios de la aplicación, roles de estos, requisitos y casos de uso básicos.
  • Aspectos orgánicos: Arquitectura del entorno tecnológico, plataforma usada y versiones de dependencias y patrones de diseño implementados. Diagrama de componentes lógico y físico.

Obtención de código y anexos

En la primera parte de este procedimiento se detalla como escogeremos para auditar la versión de mayor madurez y cercanía a salida a producción disponible del componente software. También registramos los detalles de esta adquisición, tanto del código como de anexos complementarios para la búsqueda de vulnerabilidades: Análisis funcional, manual de usuario, etc…

Es importante registrar con el mayor detalle posible el código que adquirimos, nada mejor que un ejemplo:

Nombre de aplicación «gnu_bash»
Fecha de obtención19/08/2019
Fecha de versión27/01/2017
Número de versiónv4.4
Id de repositorio«Bash-4.4 patch 12», commit bc007799f0e1362100375bb95d952d28de4c62fb
Nombre de archivo«gnu_bash-master.zip»
Hash SHA-256 archivocf8adc4f792c184397f3fc1ec88e5764c49bcc79e3e90cefce9067a1064ea7e9
Tamaño archivo9,53 MB (9.999.350 bytes)

Exclusiones

Como vimos en la primera parte de este procedimiento, redactar lo que queda fuera de la auditoría como advertencia o disclaimer es muy importante. En este punto vamos a indicar claramente los elementos excluidos y las pruebas no realizadas en la auditoría, para estar coordinados con la parte solicitante de la auditoría y que no haya sorpresas o negligencias futuras. Lo siguiente es un ejemplo.

Se excluye del alcance de esta auditoría:

  • La autenticación, ya que esta funcionalidad se realiza desde otro componente software del sistema y este no ha sido auditado.
  • La pasarela de pagos y los casos de uso de compras, por propia decisión del cliente a causa de no encontrarse con la suficiente madurez de estado de desarrollo esta funcionalidad y no formar parte a día de hoy del repositorio de preproducción.
  • Aplicaciones móviles.
owasp, metodología

Metodología empleada

Este apartado consiste en dar visibilidad sobre cómo hemos realizado la auditoría y referenciar al estándar que sigamos. El estándar líder para revisiones de seguridad en el código es sin duda Open Web Application Security Project (OWASP). Un ejemplo sería sencillamente lo siguiente:

En esta auditoría se propone respuesta y recomendación sobre las vulnerabilidades y debilidades detectadas siguiendo la metodología de revisión de OWASP. Referenciar particularmente la guía principal de revisión de código “OWASP Code Review Guide”, en su última versión estable 1.1.

Si estás siguiendo este procedimiento, es importante notar que sencillamente intento simplificar con él, la realización de una auditoría de código. Enumerando una lista de tareas a realizar. Lo que realmente te ayudará a adquirir conocimientos y profundizar posteriormente sobre la materia son grandes proyectos y comunidades como la de OWASP.

Redactando nuestros resultados, el análisis

Llegamos a la parte interesante, redactar nuestros resultados del informe. Es decir, describir las vulnerabilidades y debilidades que encontramos. En primer lugar vamos a ver que debemos escribir sobre una vulnerabilidad, para informar sobre esta de forma completa.

Identificación de la vulnerabilidad

Una vulnerabilidad tiene siempre ciertos campos que nos sirven en su gestión, los redactamos a modo de cabecera. A continuación un ejemplo:

  • Criticidad: ALTA
  • Nombre: Insuficiente validación de datos de entrada a la aplicación
  • Tipo: CWE-20: Improper Input Validation
  • Atributo afectado: Confidencialidad, integridad y disponibilidad
  • Recursos afectados: /src/main/java/web/FormularioSolicitud1.java
  • Código referencia: OWASP A1:2017 – Inyección
realizando una auditoría de código

Descripción de la vulnerabilidad

En este apartado describimos la vulnerabilidad. Una forma de hacerlo es escribir una cierta descripción, no hace falta que sea muy extensa, atendiendo a cada uno de los cinco puntos citados a continuación. En el informe no diferenciaremos estos puntos o ideas a desarrollar, simplemente será el apartado descripción. Lo siguiente simplemente son ideas para facilitar su redacción.

Descripción general de este tipo de vulnerabilidad

Es fácil empezar dando una descripción genérica de la vulnerabilidad. Atendiendo más a recursos generales como por ejemplo el mitre, su CVE si es que lo tiene, breve referencia a la descripción de su CWE relacionado. Describimos el tipo de vulnerabilidad a partir de recursos que ya hayamos encontrado sobre esta. Si es muy concreta de ese desarrollo, buscamos referencias a vulnerabilidades conocidas similares o hacemos referencia a la debilidad común relacionada o CWE.

Descripción concreta para el componente software o sistema objetivo del análisis

En este punto pasamos a centrarnos en el contexto concreto que hemos auditado, describiendo la vulnerabilidad presente en los sistemas del cliente. La idea es especificar lo que conozcamos sobre esta exposición concreta de la vulnerabilidad:

  • Donde está expuesta?
  • Podemos saber desde cuándo?
  • Al alcance de quién? (se requiere autenticación, y autorización?)
  • El por que, o causa de esta: Implícita de una versión de dependencia usada, por una mala práctica en la implementación…
  • Complejidad de detección

Al igual que en el siguiente punto, lo ideal es estimar y expresar la dificultad que tiene esta vulnerabilidad. En este caso la dificultad de detección. Este factor es importante calculando la criticidad. Una vulnerabilidad muy fácil de encontrar facilita su explotación.

dibujo explosión, bart simpsons

Descripción de su potencial explotación

Aquí detallamos lo encontrado sobre la potencial explotación de la vulnerabilidad, lo más concreto posible sobre el contexto auditado. Si hemos podido confirmar su explotación por que teníamos acceso a la aplicación en ejecución, lo especificamos. Hacemos mención al método de explotación empleado, a ser posible ofreciendo visibilidad sobre la dificultad que conlleva.

  • Complejidad de ataque: Como de difícil es explotarla? Si hay un exploit lo especificamos junto con su madurez y facilidad de uso.
  • Requerimiento de privilegios: Requerimos estar autenticados? requerimos que el usuario autenticado tenga un perfil de privilegios concreto?
  • Vector de ataque: Método empleado para explotar la vulnerabilidad, si requiere varios pasos detallarlos cronológicamente.
  • Interacción de usuario: Describimos cualquier participación necesaria de otro usuario diferente del atacante. Por ejemplo, si necesitamos engañar a un usuario para que haga click en un enlace.

Descripción de potencial impacto

En este punto describimos las consecuencias de una potencial explotación de la vulnerabilidad. Detallamos su alcance especificando si afecta, y cómo afecta, a tres aspectos del sistema: Confidencialidad, integridad y disponibilidad.

Si se conocen, podemos hablar de incidentes de seguridad causados a raíz de esta vulnerabilidad. En este punto podrían ser interesante casos conocidos para entender cuál es el contexto habitual y por otro lado siempre hay que tener en cuenta el peor escenario posible.

Detalles concretos sobre la amenaza

Si se conociera, y si aporta, puede especificarse un agente de amenaza concreto relacionado con esta vulnerabilidad. Si por ejemplo la organización donde estamos realizando la auditoría suele tener incidentes de seguridad relacionados con denegaciones de servicio por parte de ciertos grupos hacktivistas y la vulnerabilidad descubierta facilita una denegación de servicio sobre los sistemas, este aspecto es a tener en cuenta.

tomar evidencia

Evidencia

Este apartado es importante, no solo como demostración del trabajo realizado, si no para el propio autor del informe si tiene que retomarlo en el futuro. Consiste en una o varias capturas de pantalla, una copia de texto devuelto por el sistema, la grabación de un video de escritorio que añadir como anexo al informe, etc… A modo de demostración.

Por un lado, cuanto más detalle técnico se pueda ver mejor, URLs, valores de variables, devolución que confirma la explotación, etc… Por otro lado, si en las capturas de pantalla quedan expuestas contraseñas en texto plano, datos personales o información confidencial, podemos anonimizar estos datos sensibles. Para esto podemos usar una herramienta de edición de imágenes y pixelar o difuminar esas partes. En el caso de texto simplemente modificando estas partes.

Respuesta a la vulnerabilidad

Una vez descrita y documentada la vulnerabilidad, nos centramos en la respuesta que dar. Cómo podemos corregir o mitigar esta vulnerabilidad. En el informe no diferenciaremos estos puntos o ideas a desarrollar, simplemente será el apartado respuesta. Lo siguiente simplemente son ideas para facilitar su redacción.

Cuales son los próximos pasos para responder ante este riesgo? Como se llevan a cabo?

La primera parte describiendo una respuesta, es especificar los cambios a realizar para mitigar, o preferiblemente corregir por completo esta vulnerabilidad. Si los pasos a realizar para dar respuesta son simples, sencillamente los describimos. Si la respuesta es compleja, según el contexto puede ser positivo describir una mitigación temporal o workaround y además describir por otro lado los pasos a llevar a cabo para una respuesta completa.

realizando una auditoría de código, respuesta

Este punto, como en el resto del informe. Lo que profundizaremos depende del tiempo que tengamos para realizarlo. Aunque lo ideal es investigar y ofrecer de forma proactiva una respuesta completa y en detalle, para el personal que vaya a llevar a cabo esta.

En una auditoría de código, las respuestas habitualmente pasan por informarnos de las mejores prácticas de código, configuraciones y uso de librerías especializadas en seguridad. Estas cambiarán según el entorno tecnológico y arquitectura en la que estemos trabajando y por lo tanto habrá que buscarlas específicamente para ese componente software.

Que nos aporta esta respuesta? Por que esta es la mejor opción?

Es positivo explicar que produce y que aporta cada paso de los indicados en la respuesta, para que el personal que la va a llevar a cabo comprenda qué cambios está realizando sobre el sistema. El detalle técnico aportara certidumbre en estas tareas. Si los cambios no solo corrigen la vulnerabilidad encontrada, si no que además ofrecen más beneficios, los describimos también.

Si puede responderse a la vulnerabilidad con varias opciones y hemos elegido una concreta, por que la consideramos mejor. Describimos esta elección ya que aportará más información al receptor del informe.

Cual es el objetivo final? describir el mejor escenario

A veces describimos una respuesta que es adecuada para la vulnerabilidad concreta. Sin embargo esta podría mejorarse, complementarse o ni siquiera hubiera ocurrido de disponer el sistema de cambios de mayor alcance. En este caso describimos esta mayor protección.

referencias, CWE
Vendor specific. Identified, validated vulnerabilities. Specifics. Common Weakness Enumeration. Vendor agnostic. Categories of exploitable errors based on historical vulnerabilities. Common Attack Pattern Enumeration and Classification. Implementation agnostic. Threat modeling. Vulnerability and exploit identification approach.

Referencias

Este apartado especifica simplemente una lista de fuentes que has consultado, para que de esta manera el receptor del informe pueda profundizar sobre lo indicado si lo requiere y ofrecer contexto.

CWE relacionado, siempre hay uno

Puedes encontrar cada posible debilidad en el desarrollo de software, y por lo tanto la causa de una vulnerabilidad en el Common Weakness Enumeration (CWE) del mitre. Esta enumeración ofrece códigos que organizan estas debilidades, es una buena forma de organizar todos tus resultados y referenciar un estándar que ofrezca contexto.

Más detalle

Como se indica anteriormente, añadir las fuentes consultadas a modo de lista de enlaces. Ofrece la posibilidad de profundizar en detalle si se requiere. Interesan recursos que documenten sobre un contexto tecnológico lo más parecido posible al auditado.

Los enlaces pueden ser a un recurso compartido por un CERT gubernamental o estándar como OWASP, documentación oficial del proveedor tecnológico, blog de un especialista, etc…

Otras debilidades del software

No todos los resultados que encuentres serán vulnerabilidades. Encontrarás malas prácticas, deficiencias de calidad y en general aspectos mejorables. Estos representan cierto riesgo actual o futuro. Puedes separar estos resultados a otro apartado llamado «otras debilidades del software», para diferenciarlo de las vulnerabilidades.

Lo anterior se debe a que su criticidad en términos de ciberseguridad será menor. A pesar de que su criticidad para la seguridad del sistema sea menor, estos resultados pueden aportar mucho y tener criticidad en cuanto a aspectos como la calidad, mantenibilidad del código y continuidad del proyecto. Por lo demás la forma de redactarlos sigue la misma estructura descrita anteriormente: Identificación, descripción, evidencia y respuesta.

marionetas, bart simpsons

Redactando la síntesis o extracto ejecutivo

Una vez redactados los resultados de la auditoría, aporta mucho resumir estos en un extracto ejecutivo. Esto ofrece al receptor del informe, la posibilidad de informarse con una síntesis de todos los resultados de la auditoría en un breve tiempo de lectura y sin necesidad de disponer de conocimientos técnicos. Esta síntesis está pensada para ofrecer visibilidad rápida sobre el trabajo realizado, una reunión, toma de decisiones, etc…

En este apartado puede especificarse brevemente la criticidad general del informe con su necesidad de respuesta y tiempo de esta. Incluir una tabla con el número de resultados encontrados organizados por criticidad y describir con unas líneas cada una de las vulnerabilidades de mayor criticidad.

Los objetivos principales de este resumen es que sea claro, breve y entendible por cualquier persona. Los detalles técnicos que son esenciales en el detalle de cada resultado, en este resumen complican la lectura a una persona que no posea conocimientos específicos y por lo tanto pueden entorpecer la difusión del informe y la respuesta a las vulnerabilidades.

diagrama de tarta netflix

Anexos entregables

Por último no olvidar anexar al informe cualquier documento o archivo que pueda aportar y complementar los resultados de este. Referenciando estos desde el propio informe.

Ejemplos de esto serían: Desarrollo de una pequeña aplicación de prueba de concepto, a partir de un código extraído del componente auditado (para confirmar una vulnerabilidad), una propuesta de modificación del código del proyecto actual que corrija una vulnerabilidad, etc… Estos anexos pueden aportar evidencia o facilitar la corrección de vulnerabilidades.

Referencias y recursos para profundizar en el tema:

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

error

Enjoy this blog? Please spread the word :)

error: