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 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 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 imagen. Estas prácticas determinan una variedad de actividades que deben ser implementadas en la organización para reducir los riesgos de seguridad e incrementar la fortaleza del software.
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 seguridad 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.
Cambios clave en OWASP SAMM v2
La nueva versión 2 de SAMM consta de los siguientes componentes:
- la descripción e introducción del modelo SAMM , que explica el modelo de madurez en detalle
- una guía de inicio rápido con diferentes pasos para mejorar su práctica de software seguro
- una caja de herramientas SAMM actualizada para realizar evaluaciones SAMM y crear hojas de ruta SAMM
- una nueva iniciativa SAMM Benchmark para comparar su madurez y progreso con otras organizaciones y equipos similares
El modelo original OpenSAMM 1.0 fue escrito por Pravir Chandra y se remonta a 2009. Durante los últimos 10 años, ha demostrado ser un modelo eficaz y ampliamente distribuido para mejorar las prácticas de software seguro en diferentes tipos de organizaciones. Con SAMM v2, se han realizado más mejoras para hacer frente a algunas de sus limitaciones percibidas.
El nuevo modelo SAMM es independiente del paradigma de desarrollo. Es compatible con el desarrollo en cascada, iterativo, ágil y DevOps. El modelo es lo suficientemente flexible como para permitir que las organizaciones tomen un camino basado en su tolerancia al riesgo y la forma en que construyen y usan el software. El modelo se basa en las funciones comerciales centrales del desarrollo de software con prácticas de garantía de seguridad.
Los 3 niveles de madurez permanecen como estaban. El nivel 1 es la implementación inicial; nivel 2, realización estructurada; y nivel 3, funcionamiento optimizado.
El modelo de la versión 2.0 ahora admite actualizaciones frecuentes a través de pequeños cambios incrementales en partes específicas del modelo con actualizaciones periódicas de explicaciones, herramientas y orientación de la comunidad.
Modelo SAMM versión 2 actualizado:
Lista de cambios importantes:
- El equipo introdujo una quinta función empresarial , Implementación, para representar una serie de actividades centrales en la creación y despliegue de dominios de una organización. También incluye una nueva práctica de seguridad que se ocupa de la gestión de defectos .
- Las 5 funciones comerciales principales del modelo son: gobernanza, diseño (que solía ser construcción), implementación, una función de verificación rediseñada y operaciones.
- Las actividades ahora se presentan en flujos lógicos a lo largo de cada una de las ahora 15 prácticas de seguridad, divididas en dos flujos, que alinea y vincula las actividades en la práctica en los diferentes niveles de madurez.
- Cada corriente tiene un objetivo que se puede alcanzar en niveles crecientes de madurez. De esta manera, no hay actividades «huérfanas» que parecen relevantes solo en un solo nivel de madurez (por ejemplo, firma de código en el modelo anterior).
- El modelo ahora admite mediciones de madurez tanto desde una perspectiva de cobertura como de calidad . Hay nuevos criterios de calidad para todas las actividades de SAMM y un modelo de puntuación actualizado para ayudar a los evaluadores y organizaciones de SAMM con la garantía de su software.
- Una única fuente que utiliza GitHub nos permite generar automáticamente documentos PDF, el sitio web, la caja de herramientas y las aplicaciones.
- Todo el contenido del modelo se ha convertido a archivos YAML , lo que permite que las herramientas u otros consumidores de SAMM utilicen el modelo automáticamente.
- El principal canal de publicación es ahora el sitio web de OWASP SAMM , no un documento monolítico. Esto permite mejoras iterativas, publicación más rápida e interacciones en línea con el modelo.
- Creamos una descripción general del mapeo de la versión 1.5 a la 2.0 para visualizar cómo ha evolucionado el marco.
Recursos:
OWASP SAMM v2 pdf:
https://github.com/OWASP/samm/raw/master/Supporting%20Resources/v2.0/OWASP-SAMM-v2.0.pdf
Software Assurance Maturity Model: