Las aplicaciones Web son programas de software que los usuarios pueden utilizar accediendo a ellas a través de un navegador como Internet Explorer, Firefox, Safari y Chrome, entre otros. Muchas de estas aplicaciones son desarrolladas “a la medida” y frecuentemente los requerimientos de seguridad no son tomados en cuenta durante el proceso de desarrollo o adquisición de la aplicación, lo cual sí sucede por ejemplo con las características de funcionalidad, diseño visual, y uso.

El software inseguro está impactando de manera crítica en muchos sectores (financiero, de salud, defensa, energía, de servicios, etcétera) y a medida que la infraestructura digital es cada vez más compleja e interconectada, la dificultad para lograr que una aplicación Web sea segura se incrementa en gran medida.

Para muchas organizaciones implementar controles de seguridad en las aplicaciones Web parece ser una tarea imposible debido a que en muchas ocasiones se carece de experiencia en esta área, sin embargo en la industria del software existen modelos, marcos de trabajo y estándares internacionales tales como CMMi, COBIT ®, OWASP y el estándar ISO/IEC 27001:2005 que pueden ser utilizados como referencia para la puesta en marcha de mejores prácticas en el desarrollo de software seguro.

Lograr aplicaciones Web seguras solo es posible cuando se utiliza un ciclo de desarrollo de software seguro (SDLC, Software Development Life Cycle), para lo cual OWASP [1] recomienda que las organizaciones establezcan una base sólida de formación, estándares y herramientas que hagan posible la codificación segura. Por encima de esa base las organizaciones deben integrar la seguridad a su desarrollo, verificación y procesos de mantenimiento que a su vez permitan a la gerencia utilizar los datos generados para gestionar los costos y riesgos asociados a la seguridad en aplicaciones.

En esta ocasión hablaremos del modelo SAMM (Software Assurance Maturity Model), el cual es un marco de trabajo abierto que ayuda a definir y estructurar una estrategia de seguridad en el desarrollo de software basada en los riesgos específicos que enfrenta cada organización. En este artículo se toma como referencia el modelo SAMM y se proporciona una guía de los controles que se deben implementar en cada una de las prácticas de seguridad del modelo.

.

Entendiendo el modelo  SAMM

El modelo se fundamenta en desarrollar el software de acuerdo a las funciones críticas del negocio y cuenta con 3 niveles de madurez definidos a través de 12 prácticas de seguridad, como lo muestra la figura 1. Estas prácticas determinan una variedad de actividades que deben ser implementadas en la organización para reducir los riesgos de seguridad e incrementar el aseguramiento del software.

Figura 1. Modelo SAMM

.

El modelo SAMM fue diseñado para ser flexible, de tal manera que puede ser adoptado por cualquier tamaño de organización y fue construido bajo los siguientes principios:

  • Cambios paulatinos en la organización.- Un programa de seguridad exitoso deben ser implementado en pequeñas iteraciones, lo cual permitirá producir entregables tangibles y de valor para la organización en el corto plazo, los cuales se pueden ir  incrementando para el logro de metas a largo plazo.
  • No existe una receta única que funcione en todas las organizaciones.- Un marco de trabajo de seguridad de software debe ser flexible y permitir poner en marcha los controles necesarios basándose en el nivel de riesgo de la organización.
  • Establecimiento de una directriz de seguridad.- Las actividades de un programa de aseguramiento deben estar bien definidas, ser prácticas y medibles.

 .

Funciones de negocio

SAMM define cuatro funciones críticas de negocio de alto nivel. Cada función es una categoría de actividades que la organización debe cumplir en el proceso de desarrollo de software. Estas funciones son:

I. Gobernabilidad. Está centrada en la definición de la estrategia, en los procesos y políticas  relacionadas a cómo una organización debe gestionar el SDLC (Software Development Life Cycle).

II. Construcción. Se refiere a los procesos y actividades que la organización debe seguir para el desarrollo de la aplicación, lo cual incluye la administración del producto, recolección de requerimientos, especificaciones de la arquitectura a alto nivel, definición del diseño detallado e implementación de la aplicación.

III. Verificación. Se enfoca a los procesos relacionados a la revisión y pruebas de los artefactos producidos durante el desarrollo del software; incluye aseguramiento de calidad y diferentes tipos de pruebas.

IV. Implementación. Se refiere a las actividades relacionadas a la liberación de la aplicación.

SAMM precisa 3 prácticas de seguridad por cada función de negocio. Cada una de ellas es un grupo de actividades relacionadas con la seguridad. En total hay 12 prácticas de seguridad que soportan las funciones de negocio, las cuales son:

.

I. Prácticas de seguridad de la función de gobernabilidad

  • Estrategia y métricas de seguridad. Consiste en la definición de una estrategia del programa de aseguramiento de software y la definición de los procesos y actividades para la recolección de métricas de seguridad.
  • Políticas y cumplimiento. Involucra el establecimiento de lo que está permitido hacer por la aplicación y los usuarios de la aplicación. Identificar y trabajar dentro del ámbito de las políticas de seguridad mientras se diseña la aplicación, asegura un correcto despliegue y el cumplimiento de requerimientos regulatorios.
  • Capacitación y entrenamiento. Se refiere a incrementar el conocimiento de seguridad del personal involucrado en el SDLC a través de un plan de capacitación y concientización de acuerdo a las funciones de los diferentes actores. Algunos de los tópicos a incluir son: manejo de errores, administración de bitácoras, autenticación, autorización, entre otros.

II. Prácticas de seguridad de la función de construcción

  • Análisis de amenazas. Esta práctica se centra en la identificación y entendimiento de los riesgos de la aplicación.  De acuerdo al OWASP los 10 riesgos más importantes de seguridad en aplicaciones son:
    • Inyección de código.
    • Cross site scripting (XSS).
    • Pérdida de autenticación y gestión de sesiones.
    • Referencia directa insegura a objetos.
    • Falsificación de peticiones en sitios cruzados (CSRF).
    • Configuración de seguridad defectuosa.
    • Almacenamiento criptográfico inseguro.
    • Falla de restricción de acceso a URL.
    • Protección insuficiente en la capa de transporte.
    • Redirecciones y reenvíos no validados.
  • Requerimientos de seguridad. Se refiere a las expectativas de la aplicación respecto a la seguridad; los requerimientos de seguridad deben estar basados en las necesidades del negocio. Algunos de los requerimientos de seguridad que se deben considerar en aplicaciones Web son:
    • Autenticación de usuarios.
    • Autorización de usuarios.
    • Prevención de manipulación de parámetros.
    • Protección de datos sensibles.
    • Prevención de hacking de sesión.
    • Validación de datos de entrada.
    • Auditoría y registro de actividades y transacciones.
    • Cifrado y hashing de datos confidenciales.
  • Arquitectura de seguridad. Se refiere a  introducir la seguridad en las aplicaciones web desde el diseño

III. Prácticas de seguridad de la función de verificación

  • Revisión de diseño. Se enfoca a la evaluación del diseño del software y problemas relacionados a la arquitectura, lo cual permite detectar problemas de manera temprana en el proceso de desarrollo de la aplicación, antes de que sea liberada.
  • Revisión de código. Se refiere al proceso de revisar manualmente el código fuente de la aplicación para detectar huecos de seguridad. Existen numerosos problemas de seguridad de aplicación Web, como los errores de inyección, que son mucho más fáciles de encontrar a través de revisión de código, que mediante pruebas externas. La revisión de código se debe realizar contra una lista de verificación que incluya:
    • Requerimientos del negocio acerca de la disponibilidad, integridad y confidencialidad.
    • Revisión del “Top 10 de OWASP”.
    • Requerimientos específicos de la industria tales como Sarbanes-Oxley, ISO 17799, HIPAA, PCI, entre otros.
    • Algunas herramientas para la revisión de código como  CodeCrawler, Orion y O2.
  • Pruebas de seguridad. Involucra pruebas de seguridad para descubrir vulnerabilidades y establecer un estándar mínimo para la liberación del software. Así como la revisión de código tiene sus puntos fuertes, también los tienen las pruebas de seguridad. Es muy convincente cuando se puede demostrar que una aplicación es insegura demostrando su explotabilidad. También hay muchos problemas de seguridad, en particular la seguridad proporcionada por la infraestructura de las aplicaciones, que simplemente no pueden ser detectados por una revisión del código, ya que no es la aplicación la que está proporcionando la seguridad. Una herramienta para llevar a cabo pruebas de seguridad a aplicaciones Web es WebScarab, la cual ayuda a la identificación de vulnerabilidades XXS, de autenticación y de control de acceso.

IV. Prácticas de seguridad de la función de implementación

  • Administración de vulnerabilidades. Involucra el establecimiento de procesos para manejo de vulnerabilidades e incidentes de seguridad, así como la recolección de métricas e información detallada que permita un análisis de la causa raíz del incidente para tomar acciones de mitigación.
  • Endurecimiento de los ambientes. La práctica se centra en el aseguramiento de la infraestructura que soporta a la aplicación Web, tales como: sistemas operativos, firewalls y manejadores de bases de datos.
  • Habilitación operativa. La práctica se centra en la recopilación de información crítica por parte del equipo de desarrollo de la aplicación y la distribución de la misma a los usuarios y operadores. Abarca la documentación operativa y funcional de la aplicación.

Conclusiones

Las aplicaciones Web pueden ser complejas cuando interactúan con múltiples sistemas, y para la mayoría de las organizaciones la tarea de producir una aplicación segura o corregir una ya existente puede ser difícil, pero la seguridad en las aplicaciones no es opcional ya sea por el incremento de ataques o por cumplimiento regulatorio, por lo cual se deben establecer prácticas para el aseguramiento de sus aplicaciones Web. Se recomienda instituir un programa holístico que incluya a diferentes actores en la organización tales como los departamentos de seguridad y auditoría, desarrollo de software y la alta dirección del negocio. Es importante centrarse en las actividades que realmente ayuden a reducir el riesgo en las aplicaciones y en la organización de la manera más rentable.

.

[email protected]

.

Referencias:

  • Software Assurance Maturity Model v1.0, 2009, www.opensamm.org
  • The Open Web Application Security Project, OWASP Top 10 -2010, www.owasp.org
  • Open Web application Security Project, OWASP Testing Guide 3.0

[1] OWASP (Open Web Application Security Project). Es una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener aplicaciones web confiables.