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.