Cómo desarrollar aplicaciones más seguras?
Presentada por: Julio César Ardita CTO CYBSEC Marcelo Stock Jefe de Seguridad Informática Banco Columbia
Aclaración: Todos los derechos reservados. No está permitida la reproducción parcial o total del material de esta sesión, ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito de los titulares de los derechos. Si bien este Congreso ha sido concebido para difusión y promoción en el ámbito de la profesión a nivel internacional, previamente deberá solicitarse una autorización por escrito y mediar la debida aprobación para su uso.
- Desarrollo de un Proyecto de Desarrollo - Problemáticas más comunes en el desarrollo de aplicaciones - Inclusión de la seguridad en SDLC - Seguridad en el Análisis - Seguridad en el Diseño - Seguridad en la Codificación - Testing de Seguridad - Implementación Segura
Desarrollo de un proyecto de Desarrollo Proyectos de desarrollo de software Qué problemáticas actuales tiene el desarrollo del software? Qué problemáticas actuales tiene el desarrollo del software en un entorno seguro? Desvíos en proyectos de IT
Desarrollo de un proyecto de Desarrollo Costo de solución de Problemas 40-1000 1000 900 Costo de un error por fase 800 Unidad de Costo 700 600 500 400 300 200 100 1 3-6 10 15-40 30-70 0 Requerimientos Diseño Desarrollo Test en desarrollo Test de Aceptación Operación Barry Bohem determinó el rango de costo por error generado por falsos supuestos en la fase de requerimientos y no detectados hasta fases posteriores ( Software Engineering Economics ). Poor management can increase software cost more rapidly than any other factor.
Desarrollo de un proyecto de Desarrollo 1. Planificación 2. Análisis 3. Diseño Etapas en el System Development Life Cycle 4. Codificación/Desarrollo 5. Testing 6. Implementación y Operación 7. Mantenimiento
Problemáticas más comunes en el desarrollo de aplicaciones Por qué fracasan los proyectos de sistemas? 1. Poca participación y compromiso de usuarios 2. Requerimientos incompletos 3. Cambio de requerimientos 4. Falta de soporte de la dirección 5. Incompetencia tecnológica 6. Falta de recursos 7. Expectativas ilusorias 8. Objetivos poco claros 9. Cronogramas irreales 10. Nuevas tecnologías 11. Otros Fuente: The Standish Group
Problemáticas más comunes en el desarrollo de aplicaciones Grandes mitos y excusas flacas La seguridad de la aplicación es responsabilidad del programador. Nadie sabe cómo funciona, por ende, no la van a atacar. Si no se encontraron vulnerabilidades hasta ahora A nadie le interesaría atacar nuestra aplicación. La aplicación es segura porque corre detrás de un firewall. La aplicación es segura porque usa encripción. Si, ese característica (que es insegura) viene habilitado por default, pero el administrador lo puede deshabilitar. Si no corre como Administrador no funciona. No hay tiempo para incluir seguridad
Problemáticas más comunes en el desarrollo de aplicaciones Interacción con Desarrollo: Ciencia o arte? Ciencia Métricas Métodos Standards Técnicas Training Templates Arte Comunicación Lenguaje Negociación Resol. Problemas Conflictos Expectativas Interpretaciones Juicios Percepciones Cap. Escucha Cultura Educación
Problemáticas más comunes en el desarrollo de aplicaciones Modelos mentales Las personas son diferentes y por lo tanto, también lo son sus representaciones de la realidad. Una aplicación bien segura, NO HAY PROBLEMA!!! Buenísim o. Em pecem os ya. La necesitam os en 2 meses.
Problemáticas más comunes en el desarrollo de aplicaciones La naturaleza del conflicto El conflicto es natural. Ni positivo ni negativo. Lo que importa no es el conflicto sino como lo gestionamos. Ganar o perder son objetivos de los juegos. No de los conflictos. Resolver un conflicto no tiene que ver con quién tiene razón sino con el entendimiento y la apreciación de las diferencias. Para cambiar nuestra perspectiva en un conflicto debemos movernos desde nuestro punto de vista a un punto de observación.
Inclusión de la seguridad en SDLC Participa Seguridad en el SDLC? Porqué? Debe participar en el SDLC? Porqué? Cómo y cuándo debe participar?
Inclusión de la seguridad en SDLC Grado de madurez del área de Seguridad Informática Grado de madurez de la Organización Cultura organizacional
Inclusión de la seguridad en SDLC Modelos actuales - ISO/IEC 21827 - Information technology Security techniques Systems Security Engineering Capability Maturity Model (SSE-CMM ) - Microsoft s Trustworthy Computing Security Development Lifecycle - Team Software Process for Secure Software Development (TSP) - Correctness by Construction - Software Assurance Maturity Model - Software Security Framework
Inclusión de la seguridad en SDLC Participación de Seguridad Informática El área de Seguridad debe: en el desarrollo de Aplicaciones - Evaluar el grado de madurez del área y la Compañía. - Seleccionar en que proyectos participar - Definir en que etapas del SDLC va a participar: - Participar desde el inicio - Definir como va a participar
Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo de Aplicaciones - Política de Seguridad - Estándares - Regulaciones - Aspectos legales - Validación de conceptos básicos - Determinación de amenazas y vulnerabilidades. - Requisitos de seguridad. - Análisis costo/beneficio - Nivel de protección deseada. - Desarrollo de planes de testing.
Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo de Aplicaciones - Incorporar especificaciones de seguridad. - Ajustar planes de test. - Determinar controles de acceso. - Diseñar documentación. - Evaluar opciones de encripción. - Diseñar controles de seguridad tomando en cuenta requerimientos regulatorios. - Diseñar controles de acceso. - Utilizar encripción. - Adaptar los planes de testing. - Diseño detallado de la documentación. - Considerar aspectos de la continuidad del negocio.
Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo de Aplicaciones - Desarrollar código de forma segura. - Implementar testing de código. - Dar soporte al plan de continuidad del negocio. - Desarrollar documentación. - Integrar componentes de seguridad. - Testing integrado de seguridad - Ajustar documentación. - Llevar a cabo verificación integral del producto.
Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo de Aplicaciones - Instalar software de forma segura. - Llevar a cabo test de aceptación. - Testing de seguridad (PT`s). - Completar la documentación. - Certificación y acreditación de ser necesaria. - Revalidar controles de seguridad. - Realizar Penetration tests y análisis de vulnerabilidades. - Gestionar requerimientos de cambios. - Implementar control de cambios. - Implementar cambios de forma segura. - Evaluar el nivel de servicio. - Actualizar y mantener la documentación.
Seguridad en el Análisis Durante el análisis de requerimientos, se pueden identificar diversas características que derivarán en los requerimientos de seguridad del software. Arquitectura de la aplicación. Plataforma donde correrá la aplicación. Requerimiento de compliance con normativas y marcos regulatorios. Tipo de conectividad Tipos de datos que se almacenarán o transmitirán Perfiles de usuario necesarios para la aplicación. Tipos de registro que el sistema debe generar.
Seguridad en el Análisis Seguridad en el análisis de requerimientos REQUISITOS DE SEGURIDAD INFORMÁTICA PARA ADQUISICIÓN Y DESARROLLO DE SOFTWARE - Arquitectura de la aplicación - Mecanismo de autenticación de usuarios - Administración de usuarios - Administración de contraseñas - Encripción - Transmisión - Registro de eventos
Seguridad en el Diseño Reducción de superficie de ataque Superficie de ataque: Puntos de entrada que tiene una aplicación desde el punto de vista de un atacante. Cuanto menor sea nuestra superficie de ataque, menos posibilidades tendrá un potencial atacante de explotar vulnerabilidades en nuestro sistema. Servicios/procesos activos Sockets TCP/UDP Características del sistema Usuarios de la aplicación sin privilegios administrativos ni demo. Repositorios de ejemplo Archivos temporales / Archivos de intercambio
Seguridad en el Diseño Principio del menor privilegio En Windows y Unix, las aplicaciones y procesos corren en el contexto de un usuario X. Privilegios de la aplicación = Privilegios del usuario X. Si un atacante explota una vulnerabilidad de la aplicación, podrá actuar con los privilegios del usuario X. Se debe utilizar un usuario X con los privilegios mínimos e indispensables para ejecutar la aplicación.
Seguridad en el Diseño Defensa en profundidad Implementar medidas de seguridad en TODAS las capas del sistema. Asumir siempre que la capa anterior pudo ser comprometida Nunca confiar en los datos recibidos
Seguridad en el Diseño Manejo seguro de mensajes de error Brindar únicamente la información necesaria para que el usuario tome las acciones correspondientes. Evitar mostrar los mensajes de error de otras capas y aplicaciones. Expresar los mensajes de manera clara y concisa. Diseñar los mensajes teniendo en mente el perfil de usuario que los leerá. Evitar mensajes con demasiada información.
Seguridad en el Diseño Manejo de información sensible Almacenamiento protegido Encripción Hashes ACL`s Restricciones en DB Transmisión segura Encripción de la comunicación Borrado de datos Depuración de datos Borrado seguro
Seguridad en el Diseño Encripción y manejo de claves de encripción Definir algoritmo de encripción Definir granularidad de la encripción NUNCA colocar la clave en el código (MUY INSEGURO!) Considerar encripción de claves de encripción La aplicación debe contemplar el cambio de claves de encripción
Seguridad en el Diseño - Interacción con Firewalls. Interacción de la aplicación - Interacción con dispositivos (Proxy / Reverse Proxy / Firewalls). - Interacción con Bases de Datos. - Interfases (que sean seguras!!!).
Seguridad en el Diseño Auditoría y logging Los registros de auditoría son una herramienta de vital importancia en cualquier aplicación. Una buena aplicación, debería proveer facilidades de logging para: Definir qué eventos a registrar Definir distintos niveles de logging. Definir cómo y dónde registrarlos Definir políticas de rotación de logs Definir acciones a tomar si no se pueden registrar logs Dónde loguear? Archivos propios de la aplicación Sistema de logging local (Event logger / Syslog). Sistema de logging remoto
Seguridad en el Diseño Auditoría y logging Qué loguear? Lo que se haya definido en la etapa de análisis. Accesos al sistema en general (exitosos y fallidos) Accesos a datos sensibles Cambios de permisos y privilegios Cambios de configuraciones Modificaciones a objetos de la aplicación Todos los errores de la aplicación Inicio y detención de la aplicación (servicios)
Seguridad en el Diseño Diseño de autenticación Qué hay que tener en cuenta en la etapa de diseño? Autenticación local vs. autenticación externa (integrada). Tipos de autenticación (integrada vs. propia). Factores de autenticación. Usuarios y contraseñas por defecto. Nivel de acceso de los usuarios por defecto. Bloqueo de cuentas / vs. Captcha.
Seguridad en el Diseño Diseño de autorización Una vez que el usuario fue autenticado, la aplicación deberá decidir si tiene o no permisos para realizar las acciones que solicita. Definición de niveles de acceso (ej: Roles) Funciones que puede ejecutar cada nivel Datos que puede leer / escribir / modificar cada nivel Asignación de niveles propia o integrada Roles / grupos definidos localmente Pertenencia a grupo en servicio de directorios Requerimiento de autorización en TODOS los componentes del sistema
Seguridad en el Diseño Documentación Utilizar lenguaje claro y conciso. Diferenciar complejidad para usuarios básicos y administradores. Incluir instructivos "paso a paso. Documentar TODOS los aspectos de seguridad de la aplicación. Explicar los riesgos concretos de cada caso Incluir configuraciones de seguridad recomendadas. Deben corresponderse con la instalación default Explicar cómo usar la aplicación de forma segura.
Seguridad en la Codificación Programadores
Seguridad en la Codificación Programadores Cómo es la relación de seguridad informática con los programadores? Cómo ven los programadores al área de seguridad informática? Áreas de desarrollo interno y la tercerización del desarrollo CLAVE: CAPACITACIÓN Y CONCIENTIZACIÓN
Seguridad en la Codificación Tipos de Vulnerabilidades Existen muchos tipos de vulnerabilidades. El impacto depende del tipo general de vulnerabilidad y las condiciones particulares del software y el sistema donde se ejecuta. Tipos más comunes: Stack buffer overflows Heap buffer overflows SQL Injections Cross Site Scripting (XSS) Directory Traversal void main(int argc, char **argv) { char nombre[10]; char apellido[10]; strcpy(nombre, argv[1]); // argumento 1 strcpy(apellido, argv[2]); // argumento 2 printf( Hola %s, %s, apellido, nombre); } Authentication Bypass Information Disclosure Escalamiento de privilegios Manejo inseguro de sesiones Denegación de servicio
Seguridad en la Codificación Revelación de información Es la publicación de información sensible acerca de la Aplicación, su arquitectura, configuración o implementación. Dicha información es utilizada como fuente para la diagramación de ataques más avanzados. Algunos ejemplos: Comentarios en código fuente. Información de rutas y nombres de archivos. Información de nombres de servidores, strings de conexión. Mensajes de error de capas inferiores (no capturados).
Seguridad en la Codificación Principio del menor privilegio. Recomendaciones de seguridad Evitar correr la aplicación /servicio con privilegios administrativos Validar SIEMPRE los valores de entrada. Proteger de archivos de configuración y registro. Restringir posibles archivos de salida. Basar los privilegios en la autenticación del usuario. Utilizar manejo de sesiones seguro.
Seguridad en la Codificación Programación segura Programación de forma segura (C++, Java,.NET, etc.) Training / explicación / monitoreo a los desarrolladores. Revisión de código (automatizada y manual). Secure Programming in Java http://www.secologic.org/downloads/java/051207_draft_eurosec_whitepaper_secure_java_programming.pdf Secure Coding Guidelines for the Java http://www.oracle.com/technetwork/java/seccodeguide-139067.html Secure Coding Guidelines.NET http://msdn.microsoft.com/es-ar/library/d55zzx87(v=vs.71).aspx CERT - Secure Coding http://www.cert.org/secure-coding/
Testing de Seguridad Testing funcional vs. Testing de seguridad Bugs que se encuentran mediante Testing de seguridad Funcionalidad diseñada Funcionalidad real Bugs que se encuentran mediante Testing funcional
Testing de Seguridad Testing Funcional Testing funcional vs. Testing de seguridad Consiste en verificar que las funcionalidades esperadas de la aplicación cumplan con los requerimientos. Se basa en un uso bien intencionado de la aplicación. Se levanta un error cuando la aplicación no hace lo que debería. Testing de seguridad Consiste en verificar que no se pueda forzar a la aplicación a efectuar acciones que excedan a la funcionalidad especificada. Se basa en un uso malintencionado de la aplicación. Se levanta un error cuando la aplicación hace lo que no debería.
Testing de Seguridad Testing de seguridad (Penetration Test) Contenidos de paquetes de red Variables de entorno Archivos de configuración Contenido de archivos temporales Registro de Windows Valores de peticiones y respuestas Todos los que sirvan como valores de entrada
Testing de Seguridad Testing de seguridad (Penetration Test) Testear al cliente con un server falso Desarrollar un prototipo de server Ad Hoc que pueda ser controlado Enviar respuestas incorrectas Enviar respuestas fuera de orden Insertar delays Idem para testear un server con un cliente falso Test de Stress Generar una carga alta de peticiones/transacciones a la aplicación Mantener esta carga durante tiempos prolongados Simular tráfico en ráfagas
Implementación Segura Implementación segura de aplicaciones Todo el esfuerzo de seguridad empleado en las etapas anteriores puede ser que haya sido en vano si la implementación / instalación de la aplicación no se hace de forma segura. Topología de la implementación Instalación y hardening de software de base Proceso de implementación Administración de implementación y mantenimiento
Implementación Segura Topología de la instalación La topología sobre la que se instala una aplicación, tiene implicancias directas sobre la seguridad. Segmentación de red DMZ s, VLANS Firewalls de borde Dirección de establecimiento de conexiones Entrantes / Salientes Funciones separadas en hosts separados Database server / Application server / Web Server Esquema Back-end / Front-end
Implementación Segura Aseguramiento del software de base El sector de tecnología / operaciones debe encargarse de asegurar correctamente el software de base antes del proceso de implementación de la solución. Recomendaciones: Eliminar servicios y funcionalidades innecesarias. Eliminar usuarios innecesarios. Eliminar objetos de ejemplo y documentación. Cambiar contraseñas e identificadores por default. Configurar correctamente el nivel de logueo y mensajes de error.
Implementación Segura Proceso de implementación segura Asumir que el usuario no tiene conocimientos sobre seguridad. Los valores seteados por default en la instalación, deben ser lo más seguros que la funcionalidad permita. Si una funcionalidad es peligrosa, debe instalarse deshabilitada o no instalarse por default. Si se emplean contraseñas por default, forzar al usuario a cambiarlas.
Conclusiones Debemos conocer nuestro nivel de madurez y el nivel de madurez de la Compañía para determinar como y de que forma podemos incluir la seguridad en el SDLC. Comenzar de a poco, mantener bajo perfil e ir ganando terreno mostrando resultados concretos. Ponerle más foco al arte que a la ciencia.
Gracias por asistir a esta sesión
Para mayor información: Julio César Ardita CTO CYBSEC jardita@cybsec.com Marcelo Stock Jefe de Seguridad Informática Banco Columbia stock.marcelo@bancocolumbia.com.ar Los invitamos a sumarse al grupo Segurinfo en