en profundidad los ataques se llevan a cabo y los métodos más frecuentes de explo-tación («exploit») y técnicas usadas para comprometer el software. Los «árboles de ataque» son una técni-ca para modelar las diferentes for-mas que puede utilizar un atacante para alcanzar un objetivo. • Casos de abuso. Constituyen otra forma de representar la mentalidad del atacante en base a la descrip-ción del comportamiento del siste-ma bajo un ataque. El diseño de ca-sos de abuso requiere una cobertura explícita de lo que debería ser prote-gido, de quién y por cuánto tiempo. • Ingeniería requisitos de seguridad. La seguridad de un sistema y el software que lo soporta debe es-pecificarse en base a unos requi-sitos de obligada implementación y trazabilidad durante todas las fases del diseño. Estos requisitos pueden ser extraídos del análisis de riesgo realizado, los casos de uso y los casos de abuso. • Análisis de riesgo arquitectónico. Es una necesidad en la etapa de arquitectura y diseño, la realización de un análisis del riesgo arquitec-tónico que documente los posibles riesgos de la arquitectura y diseño e identifique las posibles amenazas. • Patrones de diseño. Son solucio-nes generales repetibles a un pro-blema de ingeniería de software recurrente, destinadas a obtener un software menos vulnerable y un diseño más resistente y toleran-te a los ataques, normalmente se limitan a funciones y controles de seguridad a nivel del sistema, co-municaciones e información. • Pruebas de seguridad basadas en riesgo. Consiste en el planeamien-to y realización de pruebas de ve-rificación y validación de los dife-rentes componentes y del sistema completo en base al conocimiento de la arquitectura del software, los resultados del análisis del riesgo, los casos de abuso y los patrones de ataque como forma de estu-diar la mentalidad del atacante, al objeto de comprobar el estado de seguridad y la no ocurrencia de funcionamientos incorrectos. • Revisión de código. La revisión de código es una de las actividades de seguridad más importantes a realizar durante el S-SDLC, pues puede descubrir alrededor del 55% de los problemas de la segu-ridad. Las herramientas estáticas de análisis de código fuente pue-den descubrir fallos de implemen-tación y vulnerabilidades comu-nes. Sin embargo, aunque es una práctica muy habitual e importante no es suficiente pues, por ejemplo, los problemas arquitectónicos son muy difíciles e incluso imposibles de encontrar revisando solamente el código, sobre todo los que tie-nen cientos de miles de líneas. Lo anterior implica que el combinar la revisión del código y análisis de riesgos arquitectónico aumenta en gran medida la seguridad del sof-tware. • Test penetración. Son pruebas cuyo principal objetivo es obtener una idea de cómo se comporta el software en su entorno de ejecu-ción final, siempre que se realicen en un entorno que simule perfec-tamente el entorno de producción donde la aplicación o sistema prestará sus servicios y en el que el software presente su arquitectu-ra definitiva. Son extremadamente útiles especialmente si se precede de un análisis de riesgo arquitectó-nico y de un plan de pruebas ba-sadas en riesgo. Un fallo en este tipo de pruebas, realizadas con herramientas de prueba dinámicas de seguridad en tiempo de ejecu-ción, significa que el sistema o el software es deficiente. • Operaciones de Seguridad. Un principio de diseño importante para la seguridad es la «defensa en profundidad», el sistema hay que protegerlo como un todo. Por un lado hay que minimizar al máximo sus vulnerabilidades y diseñarlo de forma resistente para que sea de confianza y por otro hay que secu-rizar su entorno de ejecución y de red al objeto de que la vía de ata-que al mismo se deba a su interac-ción con el software de base (sis-tema operativo, gestores de base de datos, etc.) y que las acciones maliciosas se puedan detectar en base al tráfico de red. En todo este proceso son fundamentales las ha-bilidades, experiencia adquirida de ataques producidos y conocimien-to del personal de administración de la red, sistemas y seguridad. • Revisión externa. Durante la revi-sión de la seguridad de los siste-mas es conveniente que, aparte de la realizada por el personal interno, se realice también otra diferente por parte de otro equipo externo, ajeno al equipo de diseño y desa-rrollo. Ello aporta otra visión de la Fig. 5. Coste relativo de corrección de vulnerabilidades en función de la etapa de desarrollo. (Fuente: http://www.microsoft.com/security/sdl/learn/costeffective.aspx). 26 Boletín de Observación Tecnológica en Defensa n.º 49. Primer trimestre 2016
Boletín de observación tecnológica en Defensa 49
To see the actual publication please follow the link above