Privacy by design (PbD). Necesidades de desarrollo seguro. Daniel de los Reyes Director de desarrollo. S2 Grupo 12 de Mayo, 2011

Transcripción

1 Privacy by design (PbD). Necesidades de desarrollo seguro. Daniel de los Reyes Director de desarrollo. S2 Grupo 12 de Mayo, 2011

2 Antecedentes Nueva Directiva comunitaria sobre Protección de Datos. Referencias a PbD 2

3 3 Motivación

4 4 Motivación

5 Por qué hemos llegado a esto? Históricamente, la industria del software ha funcionado liberando al mercado productos con un escaso nivel de madurez y se ha ocupado sobre la marcha de corregir los defectos que fueran apareciendo. La presión por cumplir con el calendario y el presupuesto de proyecto y la exigencia de los usuarios por disponer de nuevas funcionalidades, provocan con frecuencia que la seguridad no sea algo prioritario para los equipos de desarrollo. Además, la eliminación de vulnerabilidades se suele entender como una tarea de la que alguien se encarga en la fase de testeo al final del ciclo de desarrollo, cuando la fase de programación ha concluido. 5

6 Sin embargo, el énfasis que desde distintas organizaciones y entidades se está haciendo por incorporar la seguridad al ciclo de desarrollo de software, parece indicar que las tendencias están cambiando. Muchos pensamos hoy que todas las fases del proceso de desarrollo deberían compartir un objetivo: garantizar la seguridad del software. 6

7 A pesar de todo, es bastante común que en organizaciones que producen software, no exista ninguna incorporación formal de medidas de seguridad al ciclo de desarrollo. Los motivos son diversos: falta de presupuesto, de concienciación, de conocimiento La realidad es que en la mayoría de los casos el software se valora fundamentalmente por la funcionalidad que implementa y la seguridad del código raramente se considera; hasta que ocurre lo que nadie tuvo en cuenta 7

8 Las auditorias de seguridad revelan un número elevado de problemas y vulnerabilidades que se repiten con frecuencia en los sistemas auditados. La resolución de algunos de estos problemas que aparecen en sistemas en producción, en ocasiones de una elevada complejidad ya que afectan al diseño de la totalidad del sistema, supone un elevado coste que en ocasiones ni siquiera es abordable. Resulta evidente la eficacia de la introducción de medidas en etapas tempranas del ciclo de desarrollo de software destinadas a evitar la aparición de estos problemas en origen. 8

9 Privacy by design Secure by design Build security in Security by default Privacy by default 9

10 Una iniciativa de desarrollo seguro debe contemplar todas las fases del ciclo de vida de la aplicación. Una aplicación es segura cuando: Ha sido diseñada considerando la seguridad como un aspecto irrenunciable. Se implementa siguiendo un conjunto de buenas prácticas para evitar la introducción de errores y vulnerabilidades. Se asume, desde el principio, la seguridad de su comportamiento por defecto. 10

11 La seguridad en el ciclo de desarrollo Fuente: 11

12 Análisis de requisitos La norma ISO 27002, en el dominio de control Adquisición, Desarrollo y Mantenimiento de Sistemas establece un objetivo de control dirigido a los Requisitos de seguridad de los sistemas. Este objetivo de control fija la necesidad de la elaboración de una sección específica en materia de seguridad en el documento de análisis de requisitos Garantizar que el análisis de requisitos contemple lo establecido por las dimensiones de seguridad definidas en la ISO Confidencialidad: Requisitos que garanticen que la información esté accesible únicamente para las personas autorizadas. Integridad: Requisitos que contemplen las salvaguardas necesarias para garantizar que los datos que maneja el sistema no son manipulados o alterados de forma anómala. Disponibilidad: Requisitos destinados a garantizar que el diseño y la arquitectura del sistema sean capaces de dotar al sistema de una disponibilidad acorde a su criticidad. Autenticación: Requisitos destinados a garantizar una adecuada gestión de identidades. Autorización: Requisitos destinados a garantizar un adecuado control de acceso a la información No repudio: Requisitos destinados a que el registro del sistema permita probar la participación de las partes en una operación. Trazabilidad: Requisitos orientados a que el sistema permita conocer quién ha hecho qué y en qué momento en relación a la información. El análisis de requisitos debe también contemplar el cumplimiento de lo establecido por el marco legal vigente (LOPD, RDLOPD,LSSI, LISI, etc.) según corresponda. 12

13 Conformidad legal La legislación vigente en materia de datos de carácter personal (LOPD) y en concreto el reglamento que la desarrolla, establece un conjunto de requisitos que deben respetarse durante el diseño e implementación de los sistemas que manejen datos de carácter personal. Desde el punto de vista de las aplicaciones, el reglamento de desarrollo de la LOPD, que es un reglamento de mínimos, establece entre otras cosas: Valoración de tipos de datos de carácter personal y su clasificación desde el punto de vista de la seguridad. Gestión de contraseñas, fortaleza y caducidad de las mismas. Adecuada gestión de los ficheros temporales que puedan contener datos de carácter personal. Gestión de usuarios / perfiles. Control de acceso lógico a los datos. Registro de acceso a los datos en función de su nivel de seguridad, que permita identificar quién, cuándo y a qué información acceden los usuarios. Cifrado de los datos. Formularios web de captación de datos personales (leyendas de cumplimiento de la legislación vigente). Por otro lado, el marco legal en materia de propiedad intelectual y una creciente variedad de licencias de código abierto que pueden afectar a componentes o librerías con frecuencia utilizados por los productos desarrollados, requieren un detenido análisis que garantice la viabilidad legal del resultado final. 13

14 Casos de abuso El caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico Los analistas tienden a especificar estos casos describiendo el comportamiento de un sistema cuando todo va bien (cuando los usuarios cooperan, en entornos amigables y el código está libre de defectos). Este enfoque suele llevar a una visión funcional del sistema basada en la asunción de que el sistema no va a ser objeto de abusos intencionados o a usos indebidos por negligencia o error, sin embargo, si el sistema va a ser usado, tarde o temprano se abusará de él. 14

15 Casos de abuso Para crear software que sea seguro y confiable, el análisis debe anticiparse a comportamientos anómalos. Los casos de abuso permiten a la organización ver el sistema resultante de forma similar a como lo vería un atacante, se trata de pensar como los malos e identificar las posibles situaciones en las que un atacante pueda abusar del sistema. Para una adecuada identificación de las situaciones que pueden llegar a comprometer un sistema, es necesario adoptar una Actitud Defensiva que debe hacerse extensiva a todas las fases del ciclo de desarrollo de software. Esta actitud aparece de forma natural mediante la implantación progresiva de una cultura de la seguridad en la organización. 15 Los casos de abuso son una buena entrada para la identificación de requisitos de seguridad y el modelado de amenazas.

16 Modelado de amenazas Técnica de análisis y evaluación de riesgos orientada a aplicaciones Es una vista del software que enfatiza las amenazas a las que se enfrenta, basada en sus componentes y las fronteras que mantiene. De esta forma, las posibles vulnerabilidades se presentan con mucha más claridad que cuando el foco está exclusivamente puesto en la funcionalidad y el rendimiento. A diferencia de técnicas puras de verificación, como el test de penetración, el modelado de amenazas se puede realizar antes de que un producto haya sido implementado. El modelado de amenazas permite garantizar que un producto es tan seguro por diseño como es posible, reduciendo la dependencia sobre procesos de verificación a posteriori o alternativas reactivas con el producto en producción. 16

17 Modelado de amenazas Diagram Diagrama de la arquitectura del sistema Añadir los limites de confianza y su detalle Id threats Address Threats Validate Identificar amenazas con un método como STRIDE Iterar sobre el diagrama Rediseñar utilizando salvaguardas estándares Usar salvaguardas a medida cuando sea inevitable Validar que los diagramas y el código coinciden Validar cada amenaza y su salvaguarda Spoofing Tampering Repudio Information Disclosure Denegación de servicio Elevación de privilegios 17

18 Modelado de amenazas 18

19 Diseño seguro El diseño de un sistema debe considerar una serie de principios que garanticen su seguridad: Menor Privilegio: un sujeto sólo debe dar a un objeto los privilegios que necesita para completar sus tareas asignadas. Economía y simplificación de mecanismos de seguridad: Los mecanismos de seguridad que se establezcan deben ser tan sencillos como sea posible. Configuraciones por defecto seguras: A menos que un sujeto haya otorgado acceso explícito a un objeto, éste no debería tenerlo. Es decir, todo lo que no está estrictamente permitido es prohibido. Mediación completa: Todos los accesos a un objeto(s) deben ser verificados para asegurarse de que cuentan con el permiso para hacerlo. Diseño Abierto: Evitar hacer uso de la seguridad por oscuridad. Privilegios Condicionados: Los privilegios no deben ser estáticos para los programas o rutinas en el tiempo y en ejecución. Aceptación psicológica: El mecanismo de seguridad que se establezca para un objeto no debe sugerir mayor dificultad que la que tendría si el mecanismo no estuviese presente. En otras palabras, el mecanismo de seguridad deber ser fácil de usar. Minimizar la interfaz atacable: La interfaz expuesta por la aplicación, y por tanto atacable, debe reducirse al mínimo imprescindible para la adecuada ejecución del sistema. 19

20 Análisis estático Análisis estático de código: Automático y sin ejecutar el código Ventajas: Consistencia. La herramienta ve lo que ve, sin ideas preconcebidas (que normalmente tienen los desarrolladores o revisores). Apuntan a la causa raíz, no a los síntomas. Una prueba de penetración puede establecer que hay un problema, pero no su causa final ni cómo corregirlo. Detección precoz. La aplicación no tiene que estar integrada ni necesita ejecutarse. Su ejecución es barata. Un sistema puede re-analizarse cuando se aplican cambios, o cuando se descubre una nueva vulnerabilidad de aplicación. Inconvenientes: Falsos positivos. Impacto (coste) crece al tener que evaluar cada positivo. Falsos negativos. Suelen ser incapaces de detectar vulnerabilidades de seguridad achacables al diseño, o específicas del contexto propio de la aplicación (se centran en vulnerabilidades genéricas, de codificación). Los resultados emitidos por herramientas de análisis estático necesitan de evaluación humana Fuente: 20

21 Testeo (o auditoria) de seguridad Idealmente, el análisis estático sería capaz de identificar todas las vulnerabilidades existentes en el software, pero no es así. Por este motivo es necesaria la introducción de métodos dinámicos de testeo que interactúen con la aplicación como lo haría un atacante (Penetration Testing). El testeo de seguridad es similar al testeo funcional del software con la diferencia de que en este caso se busca que la aplicación funcione de formas para las que no ha sido diseñada: Aproximación priorizada basada en el modelado de amenazas. Existen herramientas que permiten su automatización aunque de nuevo, será necesario contar con las manos de un experto para testear aquellos aspectos que no es posible automatizar. 21

22 Code review Durante la fase de programación se realizan auditorias periódicas de código en busca de vulnerabilidades y en caso de que estás se detecten se ofrecen recomendaciones para proceder a su corrección y evitar su futura reaparición. Entre otras, se trabaja para evitar vulnerabilidades producidas por: Cross Site Scripting (XSS) Vulnerabilidades debidas a Inyecciones Malicious File Execution Insecure Direct Object Reference Cross Site Request Forgery (CSRF) Pérdidas de información Manejo inadecuado de errores Auntenticación y gestión de sesiones inadecuados Almacenamiento criptográfico inseguro Comunicaciones inseguras Acceso a URLs no restringido Validación de datos de entrada Buffer overflows, integer overflows Ataques de denegación de servicio Gestión de la configuración insegura Fallos en la separación de entornos Control de cambios inadecuado Fallos en el control de versiones Incompatibilidad en el uso de licencias Uso inseguro de ficheros temporales Política y gestión inadecuada de contraseñas Carencia o falta de adecuación de registros de acceso 22

23 23

24 OWASP (Open Web Application Security Project) OWASP es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro. Es un proyecto apoyado por una fundación sin ánimo de lucro y en el que intervienen numerosas grandes empresas del negocio del software. La comunidad OWASP está formada por empresas, organizaciones educativas y particulares de todo mundo. Juntos constituyen una comunidad de seguridad del software que trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquier organización. 24

25 OSSTMM (Open Source Security Testing Methodology Manual) OSSTMM es un estándar open source que define una metodología de testeo de seguridad y que se encuentra en proceso de convertirse en Norma ISO. Es un conjunto de reglas que definen CÓMO, CUÁNDO y QUÉ eventos son testeados. La metodología cubre el testeo de seguridad externo, es decir, el que se produce desde un entorno no privilegiado hacia un entorno privilegiado. Es un método estandarizado para realizar un exhaustivo test de seguridad de cada sección con presencia de seguridad (por ejemplo, seguridad física, seguridad inalámbrica, seguridad de comunicaciones, seguridad de la información, seguridad de las tecnologías de Internet, y seguridad de procesos) de una organización. Debido a la comunidad que lo desarrolla, es un método abierto y evaluado por expertos, para realizar exhaustivos testeos de seguridad, que se ha convertido en un estándar de facto internacional. La metodología es la base para la realización de un test práctico y eficiente de vulnerabilidades conocidas, filtraciones de información, infracciones de la ley, estándares de la industria y prácticas recomendadas. 25

26 ISO Dominio: Adquisición, desarrollo y mantenimiento de sistemas Requerimientos de seguridad de los sistemas de información. Procesamiento correcto en las aplicaciones. Controles criptográficos. Seguridad de los archivos del sistema. Seguridad de los procesos de desarrollo y soporte. Gestión de la vulnerabilidad técnica 26

27 Por dónde empezar? La incorporación de todas estas medidas, especialmente cuando se parte de una situación de poca cultura de seguridad, puede resultar algo abrumadora. Aunque el objetivo final debe ser adoptar el proceso completo, no es imprescindible que se adopten todas desde el principio para obtener mejoras significativas en la seguridad del software producido. La modificación del proceso se puede plantear como un proceso de mejora continua, empezando por aquellas medidas que requieren un esfuerzo y nivel de conocimiento y especialización moderado, para ir incorporando el resto según la experiencia y el know-how de la organización vaya creciendo. Algo es mejor que nada, algunas medidas pueden ser adoptadas inicialmente asumiendo un coste reducido y con un retorno importante: Análisis de requisitos de seguridad. Modelado de amenazas. Análisis estático. 27

28 Privacy by design (PbD). Necesidades de desarrollo seguro. Daniel de los Reyes Director de desarrollo. S2 Grupo 12 de Mayo,