Translation By:
- Alvaro Muñoz (HP Fortify)
- Daniel Medianero (Buguroo Offensive Security)
Introducción:
Análisis de código estático es el análisis del código fuente sin precisar su ejecución. Su objetivo es automatizar el análisis de código para encontrar tantas debilidades de seguridad de software como sea posible. En el mercado, las organizaciones tienen una gran variedad de herramientas y servicios de análisis estático de código, tanto con licencia OpenSource y como con licencia comercial.
El análisis de código estático se está convirtiendo rápidamente en una parte esencial de las competencias de seguridad de las compañías de software. Principalmente debido a su capacidad para analizar grandes cantidades de código fuente en un tiempo considerablemente menor que un ser humano, y a que permite descubrir las debilidades potenciales, además de añadir capacidad para automatizar el conocimiento de seguridad y flujos de trabajo de dichas organizaciones.
El objetivo del proyecto SATEC es crear un criterio independiente para ayudar a los profesionales de seguridad durante el proceso de adquisición de una tecnología de análisis de código estático que esté orientada a ser utilizada en los programas de seguridad de código fuente. Este documento proporciona una lista exhaustiva de criterios que deben tenerse en cuenta durante el proceso de evaluación. Diferentes usuarios establecerán diferentes niveles de importancia para cada característica, y el proyecto de SATEC proporciona al usuario la flexibilidad necesaria para aprovechar esta amplia lista de criterios posibles, reducirlo a una lista más corta que contenga el conjunto más importante o más relevante de criterios, asignar pesos a cada criterio, y llevar a cabo una evaluación formal para determinar qué solución cumple mejor en base a las necesidades del usuario.
La finalidad de este documento no es definir una lista de requisitos que todos los proveedores de análisis de código estático deban proveer a fin de ser considerado una solución "completa". Es más, la evaluación de productos específicos y proporcionar los resultados de dicha evaluación se encuentra fuera del alcance del proyecto SATEC. En lugar de ello, este proyecto proporciona criterios y la documentación para que cualquiera pueda evaluar las herramientas de análisis de código estático y servicios y elegir el producto que mejor se adapte a sus necesidades. La publicación del NIST 500 a 283 denominada "SourceCode Security Analysis Tools Functional Specification Version 1.1", contiene las especificaciones funcionales mínimas para las herramientas de análisis de código estático. Este documento se puede encontrar en http://samate.nist.gov/index.php/Source_Code_Security_Analysis.html .
Público objetivo:
El público objetivo de este documento es el personal técnico de las organizaciones que buscan automatizar partes de sus programas de auditoría de seguridad de las aplicaciones que utilizan una o más tecnologías de análisis de código estático, así como profesionales de la seguridad que se encargan de la realización de revisiones de seguridad de aplicaciones. En el documento se tendrá en cuenta a los que evalúan la tecnología y los que realizarán uso de la misma.
Alcance:
El propósito de este documento es desarrollar un conjunto de criterios que deben tenerse en cuenta al evaluar las herramientas de análisis de código estático o servicios para pruebas de seguridad. Los criterios son independientes de los proveedores y han sido seleccionados mediante un proceso de revisión basada en el consenso formado por expertos voluntarios. Cada organización es única y tiene un contexto único de desarrollo de software, este documento tiene como objetivo ayudar a las organizaciones a alcanzar sus objetivos de seguridad de aplicaciones a través de la adquisición de la herramienta más adecuada para su contexto particular. El documento se mantiene estrictamente alejado de la evaluación de los proveedores o de la calificación de sus herramientas. Sin embargo, se centrará en los aspectos más relevantes de las tecnologías de análisis de código estático, para ayudar a la audiencia objetivo identificar la mejor tecnología para su entorno y sus necesidades de desarrollo.
Colaboradores:
• Aaron Weaver (Pearson Education)
• Abraham Kang (HP Fortify)
• Alec Shcherbakov (AstechConsulting)
• Alen Zukich (Klocwork)
• Alvaro Muñoz (HP Fortify)
• Arthur Hicken (Parasoft)
• Amit Finegold (Checkmarx)
• Benoit Guerette (NorthSec)
• Chris Eng (Veracode)
• Chris Wysopal (Veracode)
• Dan Cornell (Grupo Denim)
• Daniel Medianero (buguroo buguroo Offensive Security)
• Dinis Cruz (SecurityInnovation)
• Gamze Yurttutan
• Herman Stevens
• Janos Drencsan
• James McGovern (HP)
• Jean-Marc Atchison (Centauri Technologies)
• Jim Manico (WhiteHat Security)
• Joe Hemler (Gotham Digital Science)
• Jojo Maalouf (Hydro Ottawa)
• Laurent Levi (Checkmarx)
• Mushtaq Ahmed (EmiratesAirlines)
• Ory Segal (Akamai)
• Philippe Arteau
• Sherif Koussa (Software Secured) [Jefe de Proyecto]
• Srikanth Ramu (University of British Columbia)
• Romain Gaucher (Coverity)
• Sneha Phadke (eBay)
• Wagner Elias (Conviso)
Póngase en contacto con:
La participación en el presente proyecto está abierta a todos. Si usted tiene alguna pregunta acerca de los criterios de evaluación, por favor póngase en contacto con Sherif Koussa (sherif dot Koussa at gmail dot com)
Criterios
1. Despliegue:
Las tecnologías de análisis de código estático a menudo representan una inversión significativa para las organizaciones de software que buscan automatizar sus procesos de análisis de seguridad de sus aplicaciones. Estas tecnologías representan no solo una inversión económica, sino que exigen tiempo y esfuerzo por parte de los miembros de la organización para la instalación, operación y mantenimiento. Adicionalmente, los miembros de la organización tienen la obligación de verificar y actuar sobre los resultados generados a través de la tecnología. Comprender el entorno de despliegue ideal será maximizar el valor derivado, ayudar a la organización a descubrir más posibles fallos de seguridad y puede evitar costes adicionales imprevistos derivados de la necesidad de compra de nuevo hardware. Los siguientes factores son esenciales para la comprensión de las capacidades de la tecnología y por lo tanto garantizar su correcta utilización.
1.1 Modelo de implantación:
Los fabricantes ofrecen las tecnologías de análisis de código estático a través de uno o ambos de los siguientes modelos:
• Tecnología de escritorio: el fabricante entrega el software como un paquete software a sus usuarios, el paquete está instalado localmente en la organización en una o más máquinas.
• Tecnologías Software-as-a-Service (SaaS): Los usuarios envían el código fuente de sus aplicaciones o archivos binarios al proveedor, donde son analizados y los resultados finales son entregados de nuevo a los usuarios.
En este documento se hará referencia a las tecnologías de análisis de código estático de escritorio como "herramientas" y se referirá a las tecnologías de análisis de código estático en SaaS como "servicios". El documento utilizará el término "tecnología" para hacer referencia a ambas tecnologías, basadas en escritorio y en servicio SaaS.
1.2 Soporte a la instalación de la herramienta:
Una herramienta de código estático debe proporcionar lo siguiente:
• Manual de instalación: instrucciones específicas sobre la instalación de la herramienta y sus subsistemas en su caso (por ejemplo, plugins para el IDE), incluyendo los requisitos de hardware y software.
• Manual de operaciones: instrucciones específicas y claras sobre cómo configurar y utilizar la herramienta y sus subsistemas.
• Servicios basados en SaaS: ya que no hay descarga o instalación, normalmente implica el uso de un servicio basado en SaaS, el proveedor debe ser capaz de proporcionar lo siguiente:
o Instrucciones claras sobre cómo empezar a utilizar el servicio.
o Tiempo estimado desde el momento en el que el código se presenta hasta que el momento en que se reciben los resultados.
o Medidas tomadas para que el código enviado o binarios, así como a los informes resultantes aseguren la confidencialidad.
1.3 Arquitectura de implantación:
Los fabricantes ofrecen diversas opciones de implementación. El proveedor debe proporcionar una descripción clara de las diferentes opciones de implantación, a fin de utilizar mejor la herramienta dentro de una organización. Adicionalmente, el fabricante deberá especificar las condiciones óptimas de operación. Como mínimo, el proveedor debe ser capaz de proporcionar :
• El tipo de implantación: server-side frente client-side, ya que esto puede requerir cambios de licencias o incurrir en compra de hardware adicional.
• Si hay posibilidad de realizar análisis simultáneos.
• Las capacidades de la herramienta de velocidad de análisis (por ejemplo, capacidad de máquinas multi-cadena, la capacidad de tomar ventaja de los entornos multi-threaded/multi-core, etc)
• Las capacidades de la herramienta de escalar, a fin de manejar más aplicaciones de escaneo si fuera necesario.
1.4 Configuración y dependencias en tiempo de ejecución:
El fabricante debe ser capaz de indicar si la herramienta o el servicio utiliza un análisis basado en código compilado o análisis basado en el código fuente.
• Análisis basado en compilación: donde la herramienta o el servicio compila primero el código junto con todas las dependencias, o si los binarios se analizan directamente. De cualquier manera, las herramientas
• el servicio requiere que todas las dependencias de la aplicación estén disponibles antes de realizar el análisis, por lo tanto, la aplicación se explora lo más cerca posible del entorno de producción posible.
• Análisis basado en código fuente: no requiere que las dependencias de software estén disponibles para que el análisis se ejecute. Esto podría permitir análisis más rápidos ya que las dependencias no son necesarias en tiempo de análisis. Esto permite realizar análisis previamente a que las aplicaciones estén desarrolladas.
• Análisis basado en ejecución dinámica: donde la herramienta o el servicio de análisis simulan la ejecución de código. Este apartado queda fuera del propósito de este documento, que se refiere al análisis estático.
2. Soporte tecnológico:
La mayoría de las organizaciones utilizan más de un lenguaje de programación en su parque de aplicaciones. Adicionalmente, los frameworks de trabajo son cada vez más maduros y los equipos de desarrollo los utilizan en multitud de ámbitos, así como una veintena de bibliotecas de terceros que se utilizan tanto en el servidor como en el cliente. Una vez que estas tecnologías, los marcos y las bibliotecas están integrados en una aplicación, se convierten en parte de la misma y la aplicación hereda cualquier vulnerabilidad en estos componentes.
2.1 Lenguajes soportados:
La mayoría de las tecnologías disponibles en la actualidad analizan más de un lenguaje de programación. Sin embargo, una organización que busque utilizar una herramienta de análisis de código estático o servicio debe hacer un inventario de todos sus lenguajes de programación, y sus versiones, así como las aplicaciones de terceros que se analizarán también. Después de la preselección de todos los lenguajes de programación y sus versiones, una organización debe comparar la lista con la lista proporcionada por el proveedor. Los fabricantes ofrecen varios niveles de soporte para el mismo lenguaje, la comprensión de cuál es el nivel de soporte del fabricante proporciona para cada lenguaje de programación, y sus versiones, además de los frameworks utilizados y sus versiones, es clave para comprender el alcance y la profundidad que proporciona una tecnología para cada lenguaje. Una forma de entender el nivel de soporte a un lenguaje particular es inspeccionar las firmas de la herramienta (también conocidas como “Reglas”) para dicho lenguaje.
2.2 Soporte a los entornos de programación:
Debido a que las aplicaciones están construidas utilizando frameworks, la aplicación hereda cualquier vulnerabilidad en dichos frameworks. Además, dependiendo de cómo la aplicación utilice un marco o una biblioteca, se puede añadir nuevos vectores de ataque. Comprender la relación entre la aplicación y los frameworks / bibliotecas es clave para detectar vulnerabilidades resultantes del uso de la aplicación, y en particular lo siguiente:
• La capacidad de la herramienta o servicio para entender cómo los framewroks (por ejemplo, Struts, Spring, Rails, etc) trabajan y analizan los datos basados en el flujo de datos actual, y seguir los flujos de datos entre la aplicación y el framework.
• La capacidad de la herramienta o servicio para seguir los flujos desde el lado del cliente (por ejemplo campos ocultos, etc) y el lado del servidor (por ejemplo, parámetros).
• Identificar si la aplicación utiliza un framework de una manera insegura.
• Identificar las vulnerabilidades conocidas como se define en las vulnerabilidades y exposiciones comunes (CVE)
2.3 Soporte a la configuración de laTecnología:
Varios ajustes proporcionados por la herramienta potencialmente podrían descubrir serias debilidades.
• Redefinición de archivos de configuración: Ampliar el conocimiento de la herramienta para el tratamiento de los archivos con extensiones de archivos de configuración no estándar (por ejemplo, * ini, * Propiedades *, xml, etc...) como ficheros de configuración.
• Extensión de Mapeo del Lenguaje: la capacidad de ampliar el alcance de la herramienta para incluir las extensiones de archivo de código fuente no estándar. Por ejemplo, jspf son archivos JSP que deben ser tratados igual que los archivos JSP. Además, los archivos de HTC son archivos de fragmentos de HTML que deben ser tratados igual que los archivos HTML. Los archivos PCK son archivos de paquetes de Oracle que incluyen procedimientos PL / SQL. Mientras que una herramienta no necesariamente tiene que entender todas las extensiones no estándar, debe incluir una función para ampliar su comprensión de estas extensiones mediante la asignación de la extensión no estándar a una normal.
3.Análisis, Soporte de gestión:
El análisis y la capacidad de gestión de las herramientas de análisis de código estático tiene una influencia significativa en la capacidad del usuario para configurar, personalizar e integrar la herramienta dentro de la organización del ciclo de vida de desarrollo de software (SDLC). Además, afecta tanto la velocidad y la eficacia de procesamiento de resultados como a la remediación de los mismos.
3.1 Soporte de línea de comandos:
El usuario debe ser capaz de realizar análisis utilizando la línea de comandos, que es una característica deseable por muchas razones. Para los servicios basados en SaaS, el proveedor debe ser capaz de indicar si hay un API para iniciar un análisis remoto, esto se convierte en una característica deseable para los escenarios que implican gran número de aplicaciones.
3.2 Soporte de integración con entornos de desarrollo (IDEs):
El fabricante debe ser capaz de enumerar que IDEs (y versiones) están siendo soportados por la tecnología que se evalúa, así como los análisis incorporados a través del IDE (por ejemplo, cómo se visualizarán los resultados). Por ejemplo, ¿puede un plugin de Eclipse analizar ficheros JavaScript y de configuración, o lo hace sólo escanear los archivos Java y JSP?
3.3 Soporte al proceso de compilación:
Las organizaciones suelen utilizar tecnologías de análisis estático de manera muy diversa. Algunas organizaciones analizan el código como parte de su sistema de compilación diaria. El fabricante debe ser capaz de enumerar los sistemas de integración compatibles y sus versiones (Ant, Make, Maven, etc). Además, el fabricante debe ser capaz de describir lo que se analiza exactamente en este contexto.
3.4 Personalización:
La herramienta por lo general viene con un conjunto de firmas o reglas. Este conjunto es generalmente utilizado por la herramienta para descubrir las diferentes debilidades en el código fuente. Las herramientas de análisis de código estático deben ofrecer una manera de extender estas firmas con el fin de personalizar las capacidades de detección de nuevas debilidades, alterar la forma en la que la herramienta actualmente detecta debilidades o eliminar la detección de un patrón específico. La herramienta debe permitir a los usuarios:
• Añadir / borrar / modificar firmas. Las firmas Core vienen equipadas con la herramienta por defecto. En general, los falsos positivos son uno de los problemas inherentes de las herramientas de análisis de código estático. Una forma de minimizar este problema es optimizar las firmas de la herramienta; por ejemplo, marcar una cierta fuente como entrada segura.
• Personalización de firmas: creación personalizada de firmas. Se utilizan para "educar" a la herramienta de la existencia de un módulo de limpieza de encargo, fuentes personalizadas de datos potencialmente vulnerables y funciones potencialmente peligrosas, así como una manera de hacer cumplir ciertos estilos de programación mediante el desarrollo de firmas personalizadas para dichos estilos.
• Paquetización de reglas: Capacidad para aglutinar reglas y ejecutar conjuntos selectivos de reglas.
• Análisis selectivo: Capacidad de ejecutar análisis buscando únicamente determinadas vulnerabilidades específicas.
• Pruebas unitarias: Posibilidad de crear pruebas unitarias para validar las reglas nuevas o modificadas.
• Formación: el fabricante debe declarar si crear nuevas firmas requiere una formación complementaria en la herramienta.
3.5 Capacidad de configuración del análisis:
Esta sección incluye las siguientes características:
• Capacidad para programar análisis: Los análisis son a menudo planificados para ejecutarse después de compilaciones, otras veces se programan cuando el uso de la CPU se encuentra en su mínimo. Por lo tanto, es importante que el usuario sea capaz de programar el análisis para ejecutarse en un momento determinado. Para los servicios basados en SaaS, el proveedor deberá indicar la ventana permitida de presentación de código o archivos binarios que deben analizarse.
• Capacidad para ver el estado en tiempo real de los análisis en curso: algunos análisis pueden durar horas, es beneficioso y conveniente que un usuario pueda ver el progreso del mismo. Para el servicio basado en SaaS, el proveedor debe ser capaz de proporcionar estimación de la entrega de resultados.
• Capacidad para guardar las configuraciones y volver a utilizarlas como plantillas de configuración: A menudo se invierte una cantidad significativa de tiempo y fuerzo en generar la configuración de una herramienta de análisis de código estático para una aplicación particular. La herramienta debe proporcionar al usuario la posibilidad de guardar dicha configuración de modo que pueda ser reutilizada para los análisis posteriores.
• Posibilidad de ejecutar simultáneamente varios análisis: Las organizaciones que tienen muchas aplicaciones para escanear, encontrarán la posibilidad de realizar análisis simultáneos una característica interesante.
• Capacidad para soportar múltiples usuarios: esto es importante para las organizaciones que están pensando en el despliegue de la herramienta para ser utilizada por los desarrolladores. Es también importante que diferentes usuarios puedan trabajar sobre un mismo análisis.
• Capacidad para realizar análisis incrementales: resulta útil cuando se analizan grandes aplicaciones en múltiples ocasiones, analizar sólo las partes modificadas del código lo que reducirá el tiempo necesario para evaluar los resultados.
• Capacidad para volver a configurar la ubicación del código fuente: La posibilidad de volver a configurar la ubicación del código fuente después de que el análisis se lleve a cabo. Algunas veces, los analisis se ejecutan en una máquina y los resultados se abren en una máquina diferente.
3.6 Características de detección:
El análisis de las debilidades es una funcionalidad importante de la herramienta o servicio. Es esencial que las herramientas y servicios sean capaces de entender, identificar con precisión y reportar los siguientes ataques y debilidades de seguridad.
• Abuso de APIs
• Configuración errónea de aplicación
• Función de “Auto-completar” no deshabilitada en parámetros de contraseña
• Desbordamiento de buffer
• Inyección de comandos
• Predicción de Credenciales
• Cross-site Scripting
• Denegación de servicio
• Escalada de privilegios
• Criptografía Insegura
• Cadenas de formato
• Credenciales en el código
• HTTP Response Splitting
• Incorrecta manipulación de los datos de entrada
• Incorrecta codificación de los datos de salida
• Fuga de información
• Almacenamiento en caché de datos inseguros
• Cargar archivos inseguros
• Bloqueo de cuentas insuficiente
• Autenticación insuficiente
• Autorización insuficiente
• Registro de logs insuficiente / Inseguro
• Insuficientes requerimientos de complejidad de contraseña
• Insuficientes requisitos Historial Contraseña
• Expiración de sesión insuficiente
• Desbordamientos de enteros
• Inyección LDAP
• Inyección de comandos de correo
• Inyección Null Byte
• Ataques Open Redirect
• Inyección de comandos al sistema operativo
• Rutas Transversales
• Condiciones de carrera
• Inclusión de ficheros remotos
• Inyecciones de segundo órden
• Fijación de sesión
• Inyección SQL
• URL redirección
• Inyección XPath
• XML Entidades Externas
• XML Expansión de Entidades
• Inyección XML
• Inyección XPath
3.7 Análisis basados en estándares de la Industria:
Proporcionar análisis basados en estándar de la industria se convierte en una característica deseable por muchas razones. Por ejemplo, OWASP Top 10 , CWE / SANS Top 25 , WASC Threat Clasificación , DISA / STIG etc proporcionan a las organizaciones puntos de partida para el análisis de las deficiencias de seguridad de software y en otros casos estas clasificaciones se han convertido en métricas de cumplimiento de las normas mínimas de seguridad. Proporcionar análisis basados en estándar de la industria se convierte en una característica deseable por muchas razones.
4. Actualización de firmas del producto:
Las firmas usadas por los analizadores (También conocidas como reglas o chequeos) son lo que las herramientas de análisis estático usan para identificar defectos de seguridad. Cuando se encuentre en el proceso de selección de una herramienta de análisis estático debería tener en cuenta las siguientes consideraciones:
4.1 Frecuencia de actualización
Ofrecer frecuentes actualizaciones del conjunto de reglas usadas por la herramienta de análisis estático asegura la relevancia de la herramienta con respecto al panorama de amenazas actuales. Por lo tanto es importante comprender los siguientes aspectos sobre el proceso de actualización de las reglas:
• Frecuencia desactualización de firmas: Si se trata de un proceso periódico, bajo demanda, requiere una subscripción especial, etc.
• Relevancia de las firmas sobre las amenazas en constante evolución: El proveedor debe proveer información sobre como se ajustan las firmas de sus productos al panorama de amenazas en constante evolución.
4.2 Envió de comentarios por parte del usuario
La herramienta debe ofrecer una forma de enviar comentarios sobre posibles fallos, firmas erróneas, mejoras de las reglas, etc.
5. Apoyo en el proceso de evaluación y remediación
Un factor crucial en un servicio o herramienta de análisis de código estático es el apoyo prestado en el proceso de evaluación de los resultados y la precisión y efectividad de las recomendaciones presentadas por la herramienta. Esto influirá de forma crucial en la rapidez de la evaluación los resultados y la remediación de los defectos por parte del equipo de desarrollo.
5.1 Metadatos de las ocurrencias:
Los metadatos de las ocurrencias en la información ofrecida por la herramienta o servicio acerca de la ocurrencia misma. Unos buenos metadatos ayudan al auditor o desarrollador a comprender el defecto y actuar sobre el mismo de una forma más veloz. La herramienta o servicio debería ofrecer al menos los siguientes metadatos para cada ocurrencia:
• Severidad de la ocurrencia: La severidad de la ocurrencia así como los medios para modificarla si fuese necesario.
• Resumen: Explicación de la ocurrencia y el riesgo que supone para la aplicación.
• Localización: La localización en el código fuente y el numero de línea de la ocurrencia
• Flujo de propagación: La habilidad para seguir los datos desde su origen al punto de consumo y viceversa.
5.2 Gestión de los metadatos:
• La herramienta o servicio debería ofrecer la posibilidad de marcar una ocurrencia como falso positivo.
• Capacidad para catalogar los falsos positivos: Esto asegura una consideración mas cuidadosa antes de marcar una ocurrencia como falso positivo a la vez que ofrece un medio para comprender mejor las fuentes comunes de falsos positivos lo cual, a su vez, puede ayudar a optimizar los resultados.
• Las ocurrencias marcadas como falsos positivos no deberán aparecer en análisis posteriores. Esto ayuda a evitar repetir los esfuerzos de remediación en análisis posteriores.
• La herramienta o servicio debería ser capaz de fusionar/diferenciar resultados de análisis. Esto es más relevante cuando se realizan varios análisis sobre la misma aplicación de tal forma que la herramienta o servicio debería poder añadir los resultados del segundo análisis a los del primero.
• El proveedor debería ser capaz de indicar si la herramienta o servicio tiene la posibilidad de definir políticas que incorporen tipos de fallos, niveles de seguridad, frecuencia de análisis y periodos de gracia para la remediación.
5.3 Apoyo al proceso de remediación:
• Le herramienta o servicio debería ofrecer consejos de remediación personalizables y precisos.
• Los consejos de remediación deberían estar acompañados con ejemplos escritos en el mismo lenguaje de desarrollo en el que se encontró la ocurrencia.
6. Generación de Informes
La herramienta o servicio de generación de informes es una de las funcionalidades más visibles para las partes interesadas del proyecto. La herramienta o servicio debe proporcionar diferentes formas de representarlos resultados en función del público objetivo. Por ejemplo, los desarrolladores necesitarántantos detalles comosea posiblecon el fin deser capaz deremediar el defecto de una forma satisfactoria y en un tiempo razonable. Sin embargo, la alta direccióndebería centrarse en un resumen ejecutivo de altonivel del riesgo representado por la aplicación analizada en vez de en los detalles detodas las vulnerabilidades concretas.
6.1 Soporte para Informes basados en Roles:
La herramienta o servicio debe ser capaz de ofrecer los siguientes tipos de informes así como la capacidad de generar informes mixtos:
• Resumen Ejecutivo: Ofrece un resumen de alto nivel de los resultados del análisis.
• Informes de detalles técnicos: Ofrece toda la información técnica requerida por los desarrolladores para comprender la ocurrencia y remediarla de forma efectiva. Debería incluir:
o Resumen de la ocurrencia incluyendo la categoría del defecto
o Localización de la ocurrencia incluyendo el nombre del fichero y numero de línea.
o Consejo de remediación personalizado para cada ocurrencia específica así como ejemplos de código en el mismo lenguaje en el que se halló la ocurrencia.
o Detalles del flujo de propagación como el origen y el destino del flujo de datos controlados por el usuario.
• Informes de cumplimiento: Los analizadores deben proveer formatos de informes que permitan a las organizaciones evaluar rápidamente si se cumplen los requisitos regulatorios u otros estándares. Esto debe ser especialmente considerado si ciertas regulaciones son importantes para la organización. La siguiente lista muestra algunos de los estándares potencialmente aplicables:
o OWASP Top 10
o WASC ThreatClassification
o CWE/SANS Top 25
o Sarbanes-Oxley (SOX)
o PaymentCardIndustry Data Security Standard (PCI DSS)
o HealthInsurancePortability and Accountability Act (HIPAA)
o Gramm-Leach-BlileyAct (GLBA)
o NIST 800-53
o Federal Information Security Management Act (FISMA)
o Personal Information Protection and Electronic Documents Act (PIPEDA)
o Basel II
6.2 Personalización de los Informes:
La herramientao servicio debeser capaz de soportar la personalización de informes. La herramientao servicio debeser capaz de proporcionarlo siguiente:
• Posibilidad de incluirlos comentarios de los auditoressobre las ocurrencias en el informe.
• Capacidad paramarcarlos resultadoscomofalsos positivos, yeliminarlos del informe.
• Posibilidad de cambiarla plantilla delinforme para incluirel logotipo de laorganización, la cabecera, pie de página, portada del informe, etc
6.3 Formato de los informes:
El proveedor debe ser capaz de enumerar los formatos de informes soportados (PDF, XML, HTML, etc)
7. Soporte de entornos empresariales
Cuando se evalúa una herramienta o servicio de análisis estático, se debe tener en consideración la capacidad de integración de la herramienta o servicio con los sistemas de la empresa tales como: sistemas de seguimiento de defectos, generación de informes, gestión de riesgo o minería de datos.
7.1 Integración con sistemas de seguimiento de defectos
Los proveedores deberán ser capaces de enumerar las aplicaciones de seguimiento de defecto soportadas. Los siguientes criterios deberían estar definidos por el proveedor:
• La forma en la que la herramienta o el servicio se integra con el sistema de seguimiento de defectos, por ejemplo: llamada directa al API, exportación de ficheros CSV, etc.
• Si la herramienta o servicio soporta la generación de defectos de forma manual y/o automática y el criterio usado para dar de alta un nuevo defecto
7.2 Integración con sistemas de gestión de riesgo:
Los equipos de Seguridad de la Información y las organizaciones necesitan presentar una vista precisa de la exposición al riesgo de sus aplicaciones y sistemas en cualquier momento. Por ello, la herramienta o servicio debe poder integrarse con sistemas de gestión de riesgo empresarial. El proveedor debe ser capaz de definir:
• La tecnología usada para realizar esta integración.
• Si es posible definir un criterio para gestionar la integración con los sistemas de gestión de riesgo empresarial.
7.3 Capacidad para agregar proyectos:
Esto hace referencia ala posibilidad de añadirmetadatosa un nuevoanálisis. Estos datos podríanser utilizadospara agregar yclasificar proyectos, que podrían ser utilizadospara aportar inteligencia a la dirección. Por ejemplo, esto puede ayudar a identificarlos lenguajes de programaciónque parecengenerar másresultadosy de esta forma utilizar mejor el presupuesto de formación, por ejemplo. Los proyectos seconstruyen conun determinadoconjunto de tecnologíasy/olibrerías. Estos pueden serde origen comercial, open-source o desarrollados por la propia organización.Ciertosproyectospueden tender a tener másproblemas de seguridaden comparación conotros dependiendo de la tecnologías o librerías utilizadaso delaforma en la que latecnología o librería se utilizadentro de uncontexto de negociodado. Las herramientas o servicios de análisis decódigo estáticopueden usarse para configurar proyectos similares con metadatos adicionales para detectar estos patrones.De esta forma se podrá generar
inteligencia sobre estos proyectos que podría ayudar adetectar que componentes de aplicación tienen másfallos de seguridady por qué.
7.4 Modelos de licenciamiento:
Las herramientas o servicios de análisis estático de código varían en sus modelos de licenciamiento. Normalmente los siguientes factores afectan a coste total (TCO) de esta tecnología.
• Factores del modelo de licenciamiento
o Licenciamiento basado en líneas de código: Las tarifas de las licencias dependen en el numero de líneas de código que serán analizadas.
o Licenciamiento basado en aplicaciones: Cuando una licencia es una licencia es generada para una aplicación especifica y no puede usarse para otras aplicaciones.
o Subscripciones por tiempo: Licencias basadas en el usuario que normalmente se combina con otros modelos de licenciamiento.
o Licenciamiento basado en uso: Licencias para escanear un numero ilimitado de aplicaciones por un numero ilimitado de usuarios.
o Licencias perpetuas: Licencias para escanear un numero ilimitado de
o Costes de servidor: Aplica a modelos cliente/servidor.
• Aplicación y verificación de los modelos de licenciamiento
o Servidor de licencias: Servidor dedicado donde se almacenan las licencias y que puede ser accedido por los usuarios de la red
o Local: Las licencias están vinculadas a un sistema operativo, sistema y usuario nominal.
o Flotante: Un numero de licencias se comparte entre un numero mayor de usuarios.
o Basado en confianza o contrato: El modelo de licenciamiento se asume que se respetara por parte del usuario sin necesidad de un sistema de gestión y verificación de las mismas.
Apéndice A
Preparación para la evaluación de herramientas o servicios de análisis estático de código Tomaruna decisiónacerca de la mejorherramienta o servicio de análisis estático decódigoaadquirirpuedeser una tareadesalentadora.Sin embargo, la preparación para esta tareapodríaser muy útil.Cadatecnología es únicaasícomo suentorno corporativo.A continuación listamos un conjunto dedetalles que debería obtener de antemano para facilitar la decisión a tomar:
• Una lista deloslenguajes de programación utilizadosen la organización.
• Una listade los marcosy bibliotecasutilizadas enla organización.
• ¿Quiénseencarga de realizarlos análisis de código?
• ¿Cómose integrarála herramientao servicioen elciclo de vida del desarrollo de software?
• ¿Cómo van a recibir los desarrolladoreslos resultados del análisis?
• Presupuesto destinadoa lacompra de tecnologíaincluyendo el hardwarepara ejecutarlos análisis (si la hay).
• La decisión sobre sise permite que elcódigo (olos binarios) puedanser analizadosfuera de la organización.
Comments (0)
You don't have permission to comment on this page.