Evolución en arquitecturas de seguridad para el desarrollo de aplicaciones. Daniel Yankelevich – Guillermo Marro Pragma Consultores.

Presentación del tema: "Evolución en arquitecturas de seguridad para el desarrollo de aplicaciones. Daniel Yankelevich – Guillermo Marro Pragma Consultores."— Transcripción de la presentación:

1 Evolución en arquitecturas de seguridad para el desarrollo de aplicaciones. Daniel Yankelevich – Guillermo Marro Pragma Consultores

2 Outline Objetivos Tendencias en Seguridad Modelos de Seguridad: Evolución Caso de estudio: Web Services Web Services: Esfuerzos Vigentes en Seguridad Recomendaciones

3 Objetivos Garantizar la funcionalidad deseada Garantizar performance adecuada Lograr confiabilidad y robustez Asegurar interoperabilidad con otros sistemas Mantener el presupuesto de desarrollo dentro de lo estipulado Respetar los tiempos de desarrollo planeados Garantizar premisas básicas de seguridad (confidencialidad, integridad, disponibilidad, no-repudiación,etc)

4 Amenazas Tangibles

5 Qué cambió? Ud abriría un file ….exe?.ppt?.jpeg? GDIplus vulnerability Ataques al Graphic Device Interface dll, usando buffer overflow Hubo MUCHOS cambios, este es sólo un ejemplo de una tendencia.

6 Pasado vs Futuro La seguridad es un problema puramente técnico La seguridad es un gasto El objetivo es la seguridad Me voy a comprar el gadget que me garantiza la seguridad! La seguridad es un problema que compete a toda la organización La seguridad es una inversión El objetivo es la continuidad de negocio Seguridad es un proceso Antes Ahora

7 Evolución de los Ataques

8 Tendencias en ataques Automatización Evolución de frameworks de ataque Sofisticación semántica Descubrimiento vertiginoso de vulnerabilidades Permeabilidad en defensas perimetrales convencionales Amenazas asimétricas

9 Evolución en tecnología de detección

10 Evolución en Modelos de Seguridad FortalezaAeropuertoPeer-to-Peer

11 Modelo Fortaleza Protección perimetral Estático, no diferenciado Difícil de modificar y adaptar Descuida el insider problem

12 Modelo Aeropuerto Mayor flexibilidad Múltiples zonas de seguridad basadas en roles Protecciones multinivel interzonas Colección jerárquica de fortalezas interactuantes

13 Modelo Aeropuerto (cont.)

14 Modelo Peer-to-Peer Conceptos dinámicos de confianza, autenticación y autorización Requerimientos comerciales->Requerimientos tecnológicos Inferir en tiempo real qué quiero hacer y con quién quiero hacerlo Puede requerir servicios provistos por TTP (Trusted Third Parties)

15 Autorización Dinámica

16 Caso de estudio: Web Services Nuevo modelo de servicios y distribución de contenido basado en estándares XML Nueva generación de desarrollo sobre Internet Aprovecha la ubicuidad de protocolos HTTP/S y plataformas de consulta (web browsers) Firewalls con politicas permisibles en puertos 80 y 443 Enormes desafíos en seguridad en el caso de contenido distribuido

17 Web Services: desafíos SSL/TLS no alcanza!

18 WS: Que hay disponible? XML Signature (W3C/IETF): Valida integridad de mensaje y provee no repudiación para documentos XML XML Encryption (W3C): Permite cifrar partes de documentos XML XKMS (W3C): Especifica protocolos para la registración y distribución de claves públicas XACML (OASIS): Permite expresar semánticamente políticas de control de acceso SAML (OASIS): Permite a las aplicaciones emitir predicados de confianza

19 WS: Que hay disponible? (cont.) XCBF (OASIS): Facilita el intercambio de datos biométricos de autenticación XrML (OASIS): Permite especificar requerimientos de DRM WS-Security (IBM-Microsoft-Verisign): Extiende SOAP, con protección de integridad, confidencialidad y autenticación de mensajes Liberty Alliance Project (Conglomerado de Orgs): Se intenta imponer el concepto de identidad federada de red, para facilitar SSO a traves de múltiples redes, dominios y organizaciones.

20 Mejoras del proceso de desarrollo de aplicaciones Tenga en cuenta la seguridad Al comienzo del proceso Durante el desarrollo Durante la implementación En los hitos de revisión del software No deje de buscar errores de seguridad hasta el final del proceso de desarrollo

21 SD 3 Seguro por diseño Seguro de forma predeterminada Seguro en implementación Arquitectura y código seguros Análisis de amenazas Reducción de los puntos vulnerables Menor área expuesta a ataques Las características que no se usan están desactivadas de forma predeterminada Privilegios mínimos Protección: detección, defensa, recuperación y administración Proceso: guías de procedimientos y de arquitectura Usuarios: aprendizaje Estructura de seguridad SD 3

22 Esquema temporal del desarrollo de productos seguros Planes de prueba completos DiseñoscompletosConceptoCódigocompleto Envío Después del envío Pruebas de puntos vulnerables de seguridad Evaluar los conocimientos de seguridad al contratar integrantes del grupo Determinar los criterios de firma de seguridad Someter a revisión externa Analizar las amenazas Aprender y afinar Realizar la revisión del grupo de seguridad Entrenar a los integrantes del grupo Probar la alteración de datos y los privilegios mínimos Resolver problemas de seguridad, comparar el código con las directrices de seguridad =continuado

23 Técnicas de análisis de riesgos Riesgo = Probabilidad * Daños potenciales Riesgo = Probabilidad * Daños potenciales Clasificar Amenazas: DREAD Clasificar Amenazas: DREAD Daños potenciales Daños potenciales Capacidad de R eproducción Capacidad de R eproducción AprovEchamiento AprovEchamiento Usuarios Afectados Usuarios Afectados Capacidad de Descubrimiento Capacidad de Descubrimiento MITIGAR MITIGAR

24 Consideraciones para Desarrollo La seguridad es parte de los requerimientos La seguridad es parte fundamental del diseño y de la arquitectura de la aplicación Siempre validar los inputs Manejo de claves y resguardo de información sensitiva (DPAPI) No almacenar información sensitiva en el cliente Reducir superficie de ataque (no incluya Funcs en una API si no hacen falta/no use servicios que no necesita) Mantenerse actualizado sobre las debilidades de la tecnología utilizada Ejecutar con privilegios mínimos necesarios Revisión de Código Incluir auditoría de transacciones, logs... Usar protocolos seguros para los datos críticos Documentar, no asumir que el no dar información es barrera!

25 Estrategia recomendada Comenzar con políticas de alto nivel que tengan en cuenta un BIA (Business Impact Analysis) de su organización Utilizar plantillas funcionales de arquitectura de seguridad, que implementen las best practices correspondientes Evangelizar a la comunidad desarrolladora de los beneficios de considerar a la seguridad como premisa inicial de diseño Migrar modelos del tipo fortaleza a modelos del tipo aeropuerto, que representen más fielmente los procesos de negocio En proyectos autocontenidos (Intranets), desarrollar IPv6-compatible, para aprovechar las provisiones de seguridad nativas del protocolo Pensar en un horizonte de 5 a 7 años para migrar a modelos de seguridad tipo Peer-to-Peer La seguridad es un proceso y no un proyecto

26 Evolución en Arquitectura del Software It's not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change Charles Darwin

27 Referencias The Evolution of Security Architecture Gartner's 2004 Strategic Planning Series. The Semantic Web: A guide to the future of XML, Web Services and Knowledge Management Michael C. Daconta et al. Wiley & Sons. CERT/CC Overview Incident and Vulnerability Trends CERT® Coordination Center - Carnegie Mellon University. Security in a Web Services World: A Proposed Architecture and RoadmapSecurity in a Web Services World: A Proposed Architecture and Roadmap Joint White Paper from Microsoft & IBM.

28 Referencias Sitio de seguridad de Microsoft (todos los usuarios) http://www.microsoft.com/security Sitio de seguridad de MSDN (desarrolladores) http://http://msdn.microsoft.com/security http:// Sitio de seguridad de TechNet (profesionales de IT) http://www.microsoft.com/http://www.microsoft.com/technet/security http://www.microsoft.com/

29

30 Para Mayor Información Argentina San Martín 575 4to (C1004AAK) Buenos Aires Tel (+54-11) 4327-1999 pragma@pragma.com.ar España Sta. Engracia, 169 (28003) Madrid Tel (+ 34-91) 295-1547 practia@practia.es Visite nuestros WEB SITES: www.pragmaconsultores.com - Información Detallada de Servicios - Nuestra Experiencia: Clientes y Proyectos - Nuestro Compromiso y Nuestra Metodología de Trabajo www.qafactory.com - Fábrica de Aseguramiento de la Calidad - Beneficios y Detalle del Servicio Contáctenos: Chile Luis T. Ojeda 0191 Of. 407, Providencia, Santiago Tel (+56-2) 3343361 practia@practia.cl