1. Ing.Pablo Andrés Garzón Vera Magister Dirección Estratégica en Ingeniería de Software dilema de la seguridad actualdesarrollando softwareEscribiendo código seguro
2. Agenda Necesidad de Sistemas Seguros. Principios de Seguridad(SD3+C) Proceso Proactivo de Desarrollo Seguro Modelo de Amenzas(Threat Modeling)
3. Prerrequisitos de la Sesión Experiencia en desarrollo de software 0, Experiencia en seguridad informática. Microsoft Security Development Lifecycle(SDLC).
4. Agenda Necesidad de Sistemas Seguros. Principios de Seguridad(SD3+C) Proceso Proactivo de Desarrollo Seguro. Modelo de Amenazas(Threat Modeling)
5. ¿Por que es importante? Mas del 70% de los ataques ocurren en la aplicación – Garther. Iniciativas de la legislación en UK Y EEUU que responsabilizan a desarrolladores si el código causa una falla de seguridad. Posee la empresa, algún seguro contra incidentes de seguridad? ¿Es esto posible en Panamá?
6. Por que debe cambiar el Desarrollo de Software Producir aplicación de calidad es un requisito mandatorio.. El costo de arreglar defectos luego de la implementación es casi 15 veces mas grande que detectar y eliminar durante el desarrollo.
8. ¿Por qué ocurren Vulnerabilidades de Seguridad? Profesionales de Seguridad No Conocen sobre las Aplicaciones Como profesionales de seguridad informática, no se como las aplicaciones de mi compañía deben funcionar de forma que implemente una solución adecuada… solution…no se si estoy protegiendo lo necesario. Desarrolladores y Profesionales de QA No Conocen sobre Seguridad Como desarrolladores de aplicaciones ,pueden añadir grandes funciones mientras cumplo con fechas de entrega, pero no se como incluir la seguridad en mis aplicaciones.
9. From: Bill Gates Sent: Tuesday, January 15, 2002 5:22 PM To: Microsoft and Subsidiaries: All FTE Subject: Trustworthycomputing Today, in the developed world, we do not worry about electricity and water services being available. Computing falls well short of this, ranging from the individual user who isn't willing to add a new application because it might destabilize their system, to a corporation that moves slowly to embrace ebusiness because today's platforms don't make the grade. Great features won't matter unless customers trust our software. So now, when we face a choice between adding features and resolving security issues, we need to choose security. This priority touches on all the software work we do. By delivering on Trustworthy Computing, customers will get dramatically more value out of our advances than they have in the past. The challenge here is one that Microsoft is uniquely suited to solve.
11. Agenda Necesidad de Sistemas Seguros. Principios de Seguridad(SD3+C) Proceso Proactivo de Desarrollo Seguro. Modelo de Amenazas(Threat Modeling)
12.
13. Marco de Seguridad SD3+C “Threat modeling”. Inspección de Código. Mejoras en Procesos. Funciones apagadas por defecto. Reducir área de ataque. Menor Privilegio. Guías “Howto” y de Arquitectura. Herramientas de Seguridad. Entrenamiento y Educación. Compromiso con Comunidad. Documentación. Políticas Claras.
14. Construye ProductosAnticipado Fallas en el Código Atacantes atacan todo el código No enfocarse en «hacerlo bien la próxima vez» Remover código viejo. Eliminar funciones antiguas. Reemplazar protocolos viejos. Reconocer que el código fallara y reducir la superficie de ataque.
15. Educación y Entrenamiento Educación en seguridad es requerida anualmente. Registro de asistencia por cada VP Créditos en profundidad. Threat Modeling en profundidad. Diseño Seguro. Patrones de Seguridad. Defectos de Seguridad en Detalle. Pruebas Fuzz. SDL para Managers Writing Secure Code 2 en lectura obligatoria es Microsoft.
16. SD3+C Windows Server 2003 Inspección de Código. “Threat modeling”. 3 meses de entrenamiento. (grupo del producto). Scripting deshabilitado en IE. 20 servicios apagados por defecto. Local Service / Network Service. No hay juegos. Windows Update. Documentación (cantidad y detalle)
17. Agenda Necesidad de Sistemas Seguros. Principios de Seguridad(SD3+C) Proceso Proactivo de Desarrollo Seguro. Modelo de Amenazas(Threat Modeling)
18. Mejorando el Proceso de Desarrollo de la Aplicación Considerando la seguridad. Al inicio del proceso, Durante el desarrollo, Durante la implementación. En todas las metas de revisión de software. No dejes de buscar «bugs» de seguridad hasta el final del proceso de desarrollo»
19. Security Development Lifecycle(SDL-IT) Evolucionando y con nuevos factores, como la privacidad que están siendo añadidos. Efectivo en responder a las necesidades de seguridad; diseñado para producir RESULTADOS DEMOSTRABLES (no todas las metodologías cumplen con esto) Ha demostrado ser altamente efectivo en reducir vulnerabilidades en software comercial. Basado en experiencias reales. Cuenta con 100% de apoyo ejecutivo.
21. Secure By Design Aumentar conciencia de seguridad del equipo de diseño. Utilizar entrenamiento en curso Cambiar actitudes - “Lo que no conozco no me puede lastimar” no aplica!. Utilizar la seguridad correctamente durante la fase de diseño. Definir las metas de seguridad para el producto Implementar seguridad como una característica clave del producto. Utilizar “threat modeling” durante la fase de diseño.
22. Agenda Necesidad de Sistemas Seguros. Principios de Seguridad(SD3+C) Proceso Proactivo de Desarrollo Seguro. Modelo de Amenazas(Threat Modeling)
23. Necesidad de Threat Modeling Si conoces a tu enemigo y a tu persona, no necesitar temer por el resultado de cien batallas. Si conoces a tu persona pero no al enemigo, por cada victoria ganada también sufrirás una derrota. Si no conoces al enemigo ni a tu persona, sucumbirás en cada batalla. – SunTzu, El Arte de la Guerra
24. Necesidad de Threat ModelingSeguridad de Aplicación Prueba de Penetración. Intenta simular al adversario mientras realiza una intrusión. Revisión de Código de Seguridad. Detecta fallas de seguridad en código base. Revisión del Diseño de Seguridad. Detecta fallas de seguridad en arquitectura de software.
25. Necesidad de Threat Modeling Amenaza Realizada a través… Ataques Realizados por medio de… Vulnerabilidades Mitigadas con… Medidas de Protección Posibilidad de que algo malo ocurra Como ocurre (el “exploit”) Porque ocurre (la causa) Como prevenirlo (la cura)
26. Necesidad de Threat Modeling Si un impacto negativo al negocio no puede ser ilustrado, no es una Amenaza!
27. Necesidad de Threat ModelingPerspectiva del Adversario Estado actual de la seguridad de aplicación es fundamentalmente sobre la perspectiva del adversario. Prueba de Penetración. Revisión de Código de Seguridad. Revisión del Diseño de Seguridad. Buscando vulnerabilidades que pueden ser utilizadas para realizar un ataque. Vulnerabilidades y ataques son simplemente los medios a un fin.
28. Necesidad de Threat ModelingPerspectiva del Defensor Amenazas no pueden comprenderse desde una perspectiva del adversario Antes de iniciar con la ingeniería, necesitamos comprender como pueden ocurrir estas amenazas. Construir una estrategia de seguridad. Implementada y probada durante SDLC(SDL-IT).
29. Necesidad de Threat Modeling Principio detrás de “ACE Threat modeling”. No se puede construir un sistema seguro sin antes comprender sus amenazas. Por qué un modelo de amenazas?. Para identificar amenazas. Crear una estrategia de seguridad. “Threat Modeling” provee administración de riesgo en la aplicación a través de SDLC.
30. ¿Qué es “Threat Modeling”? La metodología de “Threat Modeling” se enfoca en aplicaciones de línea de negocio (LOB) para empresas. Objetivos Provee una metodología consistente para identificar y evaluar objetivamente amenazas en aplicaciones. Traduce el riesgo técnico a impacto del negocio. Permite que el negocio administre riesgo. Crea conciencia entre equipos de dependencias y suposiciones en seguridad. Todo sin requerir maestría en seguridad (SME).
31. ¿Qué es “Threat Modeling”?Beneficios Beneficios para Equipos de Aplicación Traduce el riesgo técnico en impacto del negocio. Provee una estrategia de seguridad. Prioritizafunciones de seguridad. Comprende valor de medidas de protección. Beneficios para Equipo de Seguridad. Más enfocado en Evaluaciones de Seguridad. Traduce vulnerabilidades a impacto del negocio. Mejora ‘Concienciación de Seguridad’. Cierra la brecha entre equipos de seguridad y aplicaciones.
33. Programación de la Seguridad WCF Seleccione uno de los enlaces predefinidos adecuado a sus requisitos de aplicación. Seleccione uno de los modos de seguridad para el enlace. Tenga en cuenta que el enlace que seleccione determinará las opciones de modo disponibles. Por ejemplo, WSDualHttpBinding no permite la seguridad de transporte (no es una opción). De igual forma, ni MsmqIntegrationBinding ni NetNamedPipeBinding permiten el modo de seguridad. La seguridad de transporte depende del mecanismo que utilice el enlace que ha seleccionado. Por ejemplo, si utiliza WSHttpBinding, el mecanismo de seguridad es Secure Sockets Layer (SSL) (también es el mecanismo para el protocolo HTTPS). MessageEl modo de seguridad significa que cada mensaje incluye los encabezados y datos necesarios para mantener el mensaje protegido. TransportWithMessageCredentialEsta opción utiliza el nivel de transporte para proteger la transferencia del mensaje, mientras que cada mensaje incluye las credenciales enriquecidas que otros servicios necesitan.
35. Mas Información Microsoft Application Threat Modeling Blog • http://blogs.msdn.com/threatmodeling/ MSDN: Threat Modeling • http://msdn.microsoft.com/security/securecode/ threatmodeling/default.aspx MSDN: Application Threat Modeling • http://msdn.microsoft.com/security/securecode/thr eatmodeling/acetm/ Michael Howard’s Web Blog • http://blogs.msdn.com/michael_howard/
