realizando una auditoría de código, primera parte
Auditoría de código,  Desarrollo seguro

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

Realizando una auditoría de código, esta es la primera parte de una serie de tres, en las que describiré todas las tareas a realizar en un procedimiento de 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.

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 leer la segunda entrega aquí.

Introducción

Cuando pensamos en una auditoría de código es habitual pensar en ejecución de herramientas automáticas y revisión de código. Estas tareas son esenciales, pero una auditoría de código completa y de calidad tiene más tareas e implicaciones. En esta primera parte de realizando una auditoría de código, nos centramos en las primeras tareas.

Este procedimiento está redactado desde el rol de auditor de código externo al proyecto, sin necesidad de conocer nada de este previamente. Veremos de forma completa, todas las tareas que implica. Las evidentes y las no tan evidentes, pero todas importantes. Todo el procedimiento está organizado en orden cronológico habitual de realización, aunque algunas partes pueden cambiar su orden si interesa por alguna razón concreta, sobre todo en esta primera parte.

Empezamos en esta primera parte con: La identificación del proyecto y de lo que nos están pidiendo, una adquisición del código y documentación de este, calculo de métricas y por último un breve análisis del entorno tecnológico. Esto nos hará ubicarnos mucho mejor de cara a empezar a analizar el código y sus riesgos.

Por último decir que este procedimiento no está terminado y lo sigo mejorando cada dia. Si ves alguna corrección o mejora, por favor compartelo conmigo y así lo haremos crecer.

realizando auditoría de código, identificando componentes

Identificación

Realizando una auditoría de código empezamos identificando qué componente o componentes software serán objeto de la auditoría, de entre otros componentes del sistema con los que se interrelacionan. También nos interesa entender bien el alcance que debe tener la auditoría.

Identificar componentes software y su entorno tecnológico

Este primer paso es sencillamente hacer un simple diagrama de componentes que componen el sistema. Esta es una tarea habitual dentro del análisis orgánico en ingeniería de software. No tiene por que tratarse de hacer un análisis exhaustivo, sencillamente tener una imagen clara y cierta visibilidad sobre el entorno. Tener un dibujo a bolígrafo en un folio, es mucho más que no tener nada.

realizando una auditoría de código, diagrama de componentes a boli

Nos interesa conocer los componentes software objeto de auditoría y también los que no auditamos, pero intervienen en el entorno tecnológico objetivo. A veces llamamos «la aplicación» a un conjunto de aplicaciones y servicios que son independientes.

Esta identificación nos interesa entendiendo principalmente los siguientes aspectos del componente:

  • Los controles de seguridad que implementa (en la teoría)
  • Subcomponentes que lo conforman y dependencias internas
  • Activos lógicos y físicos con los que interactúa, idea sobre la criticidad de estos
  • Superficie y vectores de ataque de todo lo anterior

Diferentes componentes software

Normalmente vamos a encontrarnos con varios componentes software realizando una auditoría de código. Ilustrando el punto anterior con un ejemplo, hoy en día es muy habitual que un sistema disponga de los siguientes componentes software independientes:

  • Aplicaciones cliente:
    • Móvil:
      • Versión android en Google Play
      • App iOS en Apple Store
    • Web: basada en navegador, desarrollada con framework angular
  • Aplicación servidor .Net que ofrece servicios web REST con ASP.NET Web APIs.

Lo anterior sería simplemente enumerar los componentes software front-end expuestos al público por internet. Ni siquiera estamos preguntando por la arquitectura del backend, ni sabemos dónde está la base de datos todavía.

realizando una auditoría de código, componentes diagrama

Si la aplicación web en lugar de haberse implementado en angular, construye la capa de presentación desde el lado servidor con ASP.NET MVC, esto es un único componente software. Esta aplicación posiblemente forme parte un único proyecto «.Net» o al menos una misma solución. Pero también es muy posible que entonces exista un proyecto que ofrece una API concretamente para la parte móvil. Lo práctico será realizar auditorías de cada componente de forma independiente, aunque tenemos en cuenta siempre el entorno de este.

En resumen, es importante dividir correctamente. Puedes abarcar todo, pero lo inteligente es hacerlo con una planificación y unas prioridades. Cuando adquieres la responsabilidad de auditar el código de un componente software, debes tener certidumbre sobre qué vas a auditar y también sobre que no vas a auditar, aunque sea por ahora.

Definir y confirmar el alcance de la auditoría

Identificando correctamente los componentes software como describimos en el punto anterior, este punto se simplifica mucho. Lo más importante aquí es coordinarte muy claramente con la parte que solicita la auditoría, para dejar constancia sobre que entra dentro de la auditoría y que queda excluido. Realizando una auditoría de código como un servicio profesional.

logo de un disclaimer, aviso

Este punto es muy importante para cuidar la relación con el cliente y estar coordinados. Como hemos visto en el punto anterior la arquitectura de una aplicación puede ser confusa y fácilmente puede haber malentendidos en estimación de tiempos y cobertura de auditoría sobre el sistema completo. Por ejemplo pueden persistir vulnerabilidades sobre un componente del sistema, que han sido detectadas y corregidas sobre otro componente a raíz de una auditoría.

En este sentido es importante redactar y poner atención, sobre un apartado del informe de auditoría que entregaremos que se llama «Elementos excluidos de la auditoría». En este apartado detallaremos a modo de disclaimer y de forma completa la lista de componentes o subpartes del componente auditado que quedan excluidos de la auditoría y si procede su causa. A continuación 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.

Lo importante en este punto es hablar claro, estar coordinados con la parte solicitante de la auditoría y que no haya sorpresas o negligencias futuras.

realizando auditoría de código, introducción

Adquisición

En este punto vamos a tratar la adquisición del código objeto de la auditoría y demás elementos complementarios como la documentación. Veremos los detalles que debemos registrar durante esta adquisición y aspectos a tener en cuenta para realizarla de forma correcta.

Adquisición del código

Con el componente o componentes software que vamos a auditar identificados, nos disponemos a adquirir la versión objeto de la auditoría que vamos a realizar. Habitualmente interesa auditar la versión más reciente del código, del entorno de producción, salvo situaciones especiales.

Lo anterior significa hacernos con la versión del código exacta que está funcionando en producción y que utilizan los usuarios de esta. O en su defecto, si la aplicación no está ofreciendo servicio todavía, escoger la versión de mayor madurez y cercanía a su salida a producción. El repositorio de código dispondrá de ramas que hacen referencia al nivel de esta madurez, como por ejemplo: Desarrollo, preproducción y producción.

adquisición del código, imagen entrega de un paquete

Esto no significa que no sea productivo auditar código en fases tempranas del desarrollo, cuando la salida a producción todavía es lejana. Puesto que realizar auditorías de código tempranas es muy beneficioso para validar los requisitos de seguridad pronto, y detectar posibles desviaciones del propio diseño en cuanto a carencias de seguridad.

Es importante registrar que código adquirimos con el mayor detalle posible, 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)

Con un registro en detalle similar al anterior no habrá dudas sobre que versión del código se audito en el momento de la auditoría. Esto podrá solucionar muchas dudas o problemas posteriores. Es especialmente importante almacenar a ser posible, la versión de código auditada y su producto hash, a efectos de dudas futuras sobre que incluía el código o validez legal.

Adquisición de documentación

Realizando una auditoría de código, habitualmente enfocaremos la auditoría bajo en método de prueba caja blanca por propia definición. Además del propio código nos interesa cualquier anexo complementario a este que nos ayude a entender mejor el componente software y su contexto. Es interesante registrar en el informe de auditoría la documentación complementaria entregada, nombres de documentos, etc…

Es habitual poder tener acceso a algunos documentos como el análisis funcional, análisis orgánico, manual de administración, manual del usuario, etc… Independientemente del tiempo que tengamos para realizar la auditoría y por lo tanto para leer estos documentos, es importante hacernos con todo en la adquisición. Realizando la auditoría podemos querer enfocarnos en una posible vulnerabilidad concreta y usar la documentación a modo de consulta sobre este punto concreto.

Otras adquisiciones

Puede haber recursos complementarios al código y documentación, que quizás nos sirvan como elementos de consulta realizando la auditoría. Por ejemplo la base de datos, su script de creación (si no lo tenemos ya descargado por formar parte del repositorio) donde podemos ver la estructura, datos de ejemplo, etc…

Todo documento referente a la seguridad del sistema puede interesarnos, por ejemplo si la organización tiene realizado un análisis de riesgos esto nos vendrá genial. Este nos ofrecerá una visión de los riesgos de mayor criticidad a los que se enfrenta la organización y sus sistemas, los agentes de amenaza conocidos a tener en cuenta, incidentes de seguridad previos, etc…

Es interesante preguntar para no dejarnos nada que pueda ayudar a conocer la aplicación mejor.

Métricas del código

En este punto nos haremos una idea del volumen de código a auditar, previo a la propia realización de la auditoría. Estas métricas son interesantes para estimar tiempos.

Podemos empezar contando el número total de archivos que tiene el empaquetamiento del proyecto entregado, dividir estos archivo por tipo. Separar tipos de archivos que son estrictamente código de otros recursos, con esta división realizada contar las líneas de código total del proyecto, etc… A mi me gusta hacerlo en bash, en el blog tengo subidos algunos comandos a modo de chuleta.

realizando una auditoría de código, métricas

Una métrica muy interesante es la complejidad ciclomática del código, que nos indica un sumatorio de la complejidad que posee la lógica implementada en el proyecto. El sumatorio total de complejidad ciclomática del proyecto es una cifra interesante para hacernos una idea del volumen del componente software, al igual que el total de líneas de código. La complejidad ciclomática también será interesante para hacernos una idea de la calidad del software y localizar puntos problemáticos más adelante.

Estimando el volumen de un componente software también es interesante la revisión del análisis funcional del proyecto y los casos de uso si se dispone de ellos. Esto nos ofrecerá una visión de la cantidad de tareas que lleva a cabo la aplicación. Podríamos incluso tener esta métrica calculada mediante puntos función, aunque no es en absoluto habitual.

Breve análisis del componente y su entorno

Llegamos al último punto de esta primera fase de auditoría, antes de ponernos manos a la obra con las herramientas SAST y la revisión de código. Este punto se trata de conocer la aplicación y su entorno mejor y hacer un breve análisis de esta. Depende mucho lo que hayamos profundizado en el punto anterior de identificación de componentes software y la lectura de la documentación obtenida. Puede que ya tengamos este análisis hecho o la idea clara y lista para redactar.

Este breve análisis que redactamos para el informe en la propia introducción de este, nos servirá tanto a nosotros como a cualquier persona que consulte el informe de auditoría. El objetivo de este breve análisis será ubicarnos en el contexto de la aplicación, conociendola mejor a nivel funcional y orgánico. Esto nos posiciona mejor para todo el posterior análisis del código y búsqueda de vulnerabilidades.

Este análisis debería darnos una idea clara de:

  • Entorno tecnológico del componente. Tecnologías usadas, versiones, etc…
  • Funcionalidad que desempeña el componente objeto de la auditoría. Requisitos y casos de uso básicos
  • Relación con otros componentes del sistema. Visión sobre las entradas y salidas.
  • Superficie y vectores de ataque del componente objetivo de auditoría.
  • Información que maneja, cuál es la información más sensible?
  • Usuarios de la aplicación, roles de estos. Autenticación y autorización de estos.

Entrevista con el arquitecto

Durante este análisis al que hacemos referencia en este último apartado, cuando ya tengamos cierta idea del componente, tener la posibilidad de reunirnos con el responsable técnico o arquitecto del proyecto nos ayudará mucho. Es la persona que mejor conoce el componente software desde el punto de vista técnico y podremos revisar y consultarle el análisis.

realizando auditoría de código, imagen de interrogatorio true detective

Contrastaremos con él si hemos comprendido bien el componente objeto de la auditoría y su entorno. También es especialmente interesante preguntarle por alguna posible vulnerabilidad de la aplicación que ya conozca o cualquier aspecto relativo a seguridad que le preocupe y no haya tenido tiempo para revisar bien.

Es importante transmitir tanto al arquitecto como a cualquier miembro del equipo de desarrollo, que no estamos allí para que las cosas ya estén hechas y señalar errores. Estamos allí para responsabilizarnos de la gestión de la seguridad de forma proactiva y sumar al proyecto formando parte de él. Es completamente normal que el equipo de desarrollo este centrado en desarrollar el componente software sin profundizar en aspectos de seguridad, para eso está allí el auditor.

Conclusiones

Espero que te haya gustado este primer articulo sobre la realización de una auditoría de código. Mi idea es ofrecerte una visión completa sobre todas las tareas que puede llegar a implicar esta actividad como servicio profesional, mas allá de la evidente ejecución de herramientas automáticas y revisión de código que veremos en la próxima entrega.

Referencias y recursos para profundizar más 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: