Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones

3,280 views

Published on

Presentación de Alfredo Aranguren en SG09 Conferencia y Expo

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,280
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • El objetivo de la plática es exponer las principales tendencias en cuanto a Seguridad de Información y la importancia de la seguridad en el desarrollo de aplicaciones.Se revisará cuales son las principales vulnerabilidades en el desarrollo de aplicaciones Web y la importancia de involucrar aspectos de Seguridad de Información en todas las etapas del ciclo de vida del desarrollo del software (SDLC). Se analizará el impacto de involucrar de manera tardía la seguridad en el ciclo de vida y la importancia de la ejecución de un análisis de riesgo.Se analizarán las principales amenazas en aplicaciones web tales como Cross Site Scripting, Injection Flaws, Malicious Files Execution, entre muchas otras.Por último se revisarán las buenas practicas para el desarrollo de aplicaciones seguras.
  • Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones

    1. 1. Click to edit Master subtitle style Incorporando la Seguridad de la Información en el Desarrollo de Aplicaciones Alfredo Aranguren T., CISSP Especialista en Seguridad de Información
    2. 2. Objetivo 22 Exponer las principales tendencias en cuanto a Seguridad de Información y la importancia de la seguridad en el desarrollo de aplicaciones.
    3. 3. Gente / Procesos / Tecnología 33 Concientización Capacitación Guías Desarrollo Seguro Configuraciones Seguras Pruebas de Seguridad Revisión de Código Seguro Pruebas Automatizadas Firewalls de Aplicación
    4. 4. Datos Relevantes • Revisiones de código (peer reviews) – IBM redujo un 82% de los defectos antes de comenzar las pruebas. – 80% de los defectos es probable que no sean detectados en las pruebas – Es 100 veces más costoso solucionar un problema de seguridad en producción que en el diseño (IBM Systems Sciences Institute) 44 Ref: http://ganssle.com/Inspections.pdf
    5. 5. Concientización y Entrenamiento del Personal 55
    6. 6. Concientización y Entrenamiento del Personal • El soporte de la alta dirección es crucial. • Se debe de hablar en términos de Negocio – Creación de Valor – Administración de los riesgos del negocio 66
    7. 7. Concientización y Entrenamiento del Personal • Entre el 70% y el 90% de las aplicaciones web tiene vulnerabilidades serias porque – El desarrollador promedio no está lo suficientemente capacitado y entrenado. • Introducir controles de seguridad en el desarrollo e implementación permitirá – Mayor disponibilidad, menor TCO – Controlar y mitigar riesgos 77
    8. 8. Requerimientos de Seguridad 88
    9. 9. Requerimientos de Seguridad • Los aspectos de seguridad deben ser parte de los requerimientos • El negocio debe de estar informado de los riesgos • Base sólida para controles de seguridad posteriores • Definir estándares para requerimientos de seguridad – Cuales controles son necesarios – Cuando son necesarios – Por qué son necesarios 99
    10. 10. Requerimientos de Seguridad • Generar un conjunto genérico de requerimientos de seguridad – Debe incluir todos los mecanismos de seguridad. – Debe considerar todas las vulnerabilidades comunes. – Debe considerar casos de mal uso. – Considerar aspectos tales como regulaciones, buenas prácticas, estándares, etc. 1010
    11. 11. Identificación de Amenazas 1111
    12. 12. Para qué? • Para entender el ambiente operativo en donde se encuentra la aplicación. • Para identificar, analizar, documentar y mitigar riesgos. 1212
    13. 13. Administración de Riesgos • Seleccionar estrategias de mitigación basadas en las amenazas identificadas. • Beneficios: – Prevenir defectos en el diseño de la seguridad – Identificar y manejar los principales riesgos – Mejorar el entendimiento y concientización de los riesgos – Permitir el concenso en el equipo de trabajo – Lograr la justificación de costos para los controles necesarios 1313
    14. 14. Evaluación y Mitigación de Riesgos • Administrar los riesgos ocasionados por fallas de seguridad que generan impactos: – Financieros – Operativos – Legales – Imagen 1414
    15. 15. Cumplimiento Legal y Regulatorio • Cumplir con requerimientos legales y regulatorios • La administración de riesgos es obligatoria para la mayoría de las regulaciones: – Ejemplo de marcos de referencia de control interno: CobiT, ISO 17799 – Ejemplo de regulaciones: Basilea II, Sarbanes-Oxley, FDA, HIPAA 1515
    16. 16. Guías para el Diseño Seguro 1616
    17. 17. Diseño Seguro • Principios – Asegure el eslabón más débil – Implemente la seguridad por capas – Fallas de manera segura – Seguir el principio del menor privilegio – Compartimentalización (compartmentalize) – Mantenga las cosas simples – Promueva la privacidad – Recuerde que guardar secretos es dificil – Sea reacio a confiar – Segregación de funciones 1717
    18. 18. Pruebas de Seguridad for 1818
    19. 19. Pruebas de Seguridad • Identificar errores de seguridad durante las pruebas • Desarrollar casos para pruebas de seguridad –Basados en los requerimientos –Probando todos los mecanismos de seguridad y vulnerabilidades comunes 1919
    20. 20. OWASP Top 10 • Se refiere a las diez vulnerabilidades de seguridad más críticas de las aplicaciones web • Son un buen principio, pero no un estándar 2020
    21. 21. OWASP Top 10 2007 1. Cross Site Scripting (XSS) 2. Injection Flaws 3. Inclusión insegura de archivos remotos 4. Insecure Direct Object Reference 5. Falsificación de petición en sitios cruzados (Cross Site Request Forgery -CSRF) 6. Fuga de información y manejo inadecuado de errores 7. Débil protección de elementos de sesión y autenticación 8. Almacenamiento inseguro de funciones criptográficas 9. Comunicaciones inseguras 10. Fallas para restringir el acceso mediante URL´s http://www.owasp.org/index.php/Top_10 2121
    22. 22. 1. Cross Site Scripting (XSS) 2222
    23. 23. 1. Cross Site Scripting • Descripción – El HTML generado por el cliente es ejecutado por el navegador web • reflejado: enlaces en correos, páginas web... • almacenado: correo web, foros, blogs... • inyección a través de DOM: manipulando document.URL, document.location...) • Recomendaciones – Validar y/o codificar todos los parámetros antes de incluirlos en páginas HTML – Validar usando principalmente “listas blancas”
    24. 24. 2. Injection Flaws 2424
    25. 25. 2. Injection Flaws • Descripción – Los datos proporcionados por el usuario son enviados a un interpretador como parte de un comando o de un query – El más comun es SQL injection – Todas las aplicaciones web que usan interpretadores son vulnerables a este tipo de ataques. 2525
    26. 26. 2. Injection Flaws • Recomendaciones – Verificar que el usuario no puede modificar comandos o queries enviados a cualquier interpretador usado por la aplicación. – Es útil hacer revisiones de código para detectar este tipo de vulnerabilidades – No confiar en la validación realizada por el cliente – Normalizar los valores de entrada – Aplicar validación en el servidor – Restringir los tipos de datos aceptados 2626
    27. 27. 3. Inclusión insegura de archivos remotos 2727
    28. 28. 3. Inclusión Insegura de Archivos Remotos • Descripción – Permite al atacante ejecutar código remoto, comprometiendo archivos de entrada; causado comúnmente por confiar indebidamente de archivos de entrada – Todas las aplicaciones que permiten que se ejecuten archivos cargados, son vulnerables 2828
    29. 29. 3. Inclusión Insegura de Archivos Remotos • Recomendaciones – Usar referencias indirectas – Diferenciar datos validados de los del usuario – Validar la entrada usando “listas blancas” – Filtrar los intentos de acceso remoto desde el servidor web – Usar mecanismos de aislamiento: chroot, jail, máquinas virtuales... – Usar mecanismos del lenguaje: tainting, allow_url_fopen... 2929
    30. 30. 4. Insecure Direct Object Reference 3030
    31. 31. 4. Insecure Direct Object Reference • Descripción – La aplicación expone una referencia a un objeto interno • directorio • registro de una base de datos – Las referencias a objetos internos están expuestas. – Los atacantes usan manipulación de parámetros para cambiar referencias y violar políticas de control acceso débiles. – Las referencias a las llaves de bases de datos están expuestas. 3131
    32. 32. 4. Insecure Direct Object Reference • Recomendaciones – Evitar exponer las referencias – Validar todas las referencias a objetos – Verificar la autorización en todos los accesos – Usar índices o mapas de referencias ( http://www.example.com/application?file=1) – Verificar la autorización 3232
    33. 33. 5. Falsificación de petición en sitios cruzados (CSRF)) 3333
    34. 34. 5. Falsificación de Petición en Sitios Cruzados (CSRF) • Descripción – Provocar que el navegador genere peticiones HTTP ocultas a recursos restringidos – Se aprovecha la autentificación implícita • Autentificación HTTP (ej: usuario y contraseña) • Cookies • Autentificación SSL del cliente • Autentificación basada en IP’s 3434
    35. 35. 5. Falsificación de Petición en Sitios Cruzados (CSRF) • Recomendaciones – Usar un token de autorización que no sea enviado automáticamente por el navegador. – Eliminar cualquier vulnerabilidad de XSS en la aplicación. – Añadir una petición a una variable de un sólo uso al URL y formas adicional a la sesión estándar. – Requerir pantallas de login adicionales para datos sensibles. – No use GET para requerir datos sensibles 3535
    36. 36. 6. Fuga de Información y Manejo inadecuado de Errores 3636
    37. 37. 6. Fuga de Información y Manejo Inadecuado de Errores • Descripción – Las aplicaciones filtran información sensible • sobre su configuración, diseño interno... • datos privados a los que tienen acceso – La información puede ser usada para otros ataques 3737
    38. 38. 6. Fuga de Información y Manejo Inadecuado de Errores • Vulnerabilidades – comentarios en el código fuente – mensajes de error 3838
    39. 39. 6. Fuga de Información y Manejo Inadecuado de Errores • Recomendaciones – El objetivo es que la aplicación no divulge mensajes de error detallados. – Comprobar la aplicación con todo tipo de datos de entrada inválidos y analizar los mensajes generados – Deshabilitar o limitar los detalles mostrados sobre errores (especialmente de capas internas: BD, SO...) – No usar los gestores de error por defecto – Garantizar que los caminos de ejecución sensibles devuelven mensajes de error3939
    40. 40. 7. Debil protección de elementos de sesion y autenticación 4040
    41. 41. 7. Débil Protección de Elementos de Sesión y Autenticación • Descripción – Fallo al proteger credenciales y tokens de sesión • Causas – Fallas en los principales mecanismos de autenticación. – Debilidades en la administración de contraseñas. – Fallas en los tiempos de desconexión de las sesiones. 4141
    42. 42. 7. Débil Protección de Elementos de Sesión y Autenticación • Recomendaciones – Usar SSL exclusivamente para todo acceso autenticado – Encriptar todas las credenciales y tokens para almacenarlos (A8) – Planificación cuidadosa • No exponer datos sensibles en URLs o registros • Utilizar un único mecanismo de autentificación • No usar direcciones IP, consultas al DNS o “referrer headers” para autenticación • Ser cuidadoso con el envío de contraseñas a direcciones de correo 4242
    43. 43. 7. Débil Protección de Elementos de Sesión y Autenticación • Limitar o eliminar el uso de cookies para la autenticación o gestión de sesiones (ej: recordar al usuario en el sitio web) • No aceptar id. de sesión nuevos, preestablecidos o inválidos en URLs o peticiones (evitar “session fixation attacks”) • Crear una nueva sesión tras la autentificación o cambio de nivel de privilegio • Proporcionar enlaces para desconectarse • Utilizar mecanismos de autodesconexión • Asegurar que la liga de logout destruye todos los datos pertinentes. 4343
    44. 44. 8. Almacenamiento inseguro de funciones criptográficas 4444
    45. 45. 8. Almacenamiento Inseguro de Funciones Criptográficas • Descripción – Fallas al encriptar datos sensibles • No encriptarlos • Utilizar algoritmos criptográficos propios • Usar incorrectamente algoritmos fuertes • Continuar usando algoritmos débiles (MD5, SHA- 1, RC3, RC4...) • Usar claves preprogramadas o almacenarlas desprotegidas. 4545
    46. 46. 8. Almacenamiento Inseguro de Funciones Criptográficas • Recomendaciones – Sólo almacenar lo imprescindible – Usar algoritmos probados (no crear nuevos) • AES, RSA para criptografía asimétrica • SHA-256 o mejores para “hashing” • http://www.owasp.org/index.php/Guide_to_Cryptograph – No usar algoritmos débiles (ej: MD5, SHA-1) – Gestión cuidadosa de claves • Generarlas fuera de línea • Almacenar las claves privadas con extremo cuidado • Nunca transmitirlas por canales inseguros4646
    47. 47. 9. Comunicaciones Inseguras 4747
    48. 48. 9. Comunicaciones Inseguras • Descripción – Las aplicaciones frecuentemente fallan en encriptar el tráfico de la red cuando es necesario proteger comunicaciones sensibles – Se recomienda usar SSL para todas las conexiones autenticadas. 4848
    49. 49. 9. Comunicaciones Inseguras • Recomendaciones – Usar SSL para conexiones autenticadas o que transmiten información sensible (credenciales, números de tarjeta de crédito, datos de salud...) – Encriptar la comunicación en la infraestructura (con servidores de aplicaciones, bases de datos, LDAP...) – No permitir que se pueda pasar a un modo inseguro (ej: cuando ocurre algún fallo en las comunicaciones o falla algún componente) 4949
    50. 50. 10. Falla para restringir el acceso mediante URL’s 5050
    51. 51. 10. Falla para Restringir el Acceso Mediante URL’s • Descripción – No permitir acceso a funciones basándose en el URL • Es un ejemplo de seguridad mediante oscuridad • URLs secretas, difíciles de adivinar... • Evaluar el control de acceso en el cliente • Permitir acceso sólo a ciertos tipos de carpetas(ej: HTML, PDF...) • Mantener actualizados los componentes que manejan datos proporcionados por usuarios (imágenes, XML, textos...) 5151
    52. 52. 10. Falla para Restringir el Acceso Mediante URL’s • Recomendaciones – Usar una matriz de control de acceso – Restringir el acceso a URLs y funciones en cada paso – Realizar pruebas de penetración – No asumir que los usuarios desconocen ciertas URLs o APIs 5252
    53. 53. Fuentes • www.owasp.org • Programación Segura – Carlos Pérez Conde – Departament d'Informàtica – Escola Técnica Superior d'Enginyeria – Universitat de València
    54. 54. Click to edit Master subtitle style Preguntas y Respuestas Alfredo Aranguren T., CISSP alfredo@aranguren.com.mx

    ×