Segurinfo2013 Seg Desarrollo Software Ardita Stock

¿Cómo desarrollar
aplicaciones más
seguras?
Presentada por:
Julio César Ardita Marcelo Stock

CTO CYBSEC 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.
¿Cómo desarrollar aplicaciones más seguras?
- 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
Costo de solución de Problemas 40-1000
1000
900
Costo de un error por fase
800
700
Unidad de Costo
600
500
400
300
200
30-70
10 15-40
1 3-6
100
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”.
Etapas en el System Development Life Cycle
1. Planificación
2. Análisis
3. Diseño
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
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
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
Modelos mentales
Las personas son diferentes y por lo tanto, también lo son sus
representaciones de la realidad.
Buenísim o.
Em pecem os ya.
La necesitam os
Una aplicación
en 2 m eses.
“bien” segura,
NO HAY
PROBLEMA!!!
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?

Grado de madurez del área

de Seguridad Informática
Grado de madurez de la Organización
Cultura organizacional
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

Participación de Seguridad Informática

en el desarrollo de Aplicaciones
El área de Seguridad debe:

- 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

- 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.

- 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.

- 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.

- 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
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.
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
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.
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
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
Interacción de la aplicación
- Interacción con Firewalls.
- Interacción con dispositivos (Proxy / Reverse Proxy / Firewalls).
- Interacción con Bases de Datos.
- Interfases (que sean seguras!!!).
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
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)
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.
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
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
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
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. void main(int argc, char **argv) {
char nombre[10];
char apellido[10];
Tipos más comunes: strcpy(nombre, argv[1]); // argumento 1
strcpy(apellido, argv[2]); // argumento 2
Stack buffer overflows }

printf(“Hola %s, %s”, apellido, nombre);
Heap buffer overflows

Authentication Bypass
SQL Injections
Information Disclosure
Cross Site Scripting (XSS)
Escalamiento de privilegios
Directory Traversal
Manejo inseguro de sesiones
Denegación de servicio
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).
Recomendaciones de seguridad
Principio del menor privilegio.
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.
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 funcional vs. Testing de seguridad

Testing Funcional
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 (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 (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
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
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.
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:
Marcelo Stock
Julio César Ardita
Jefe de Seguridad Informática
CTO CYBSEC
jardita@cybsec.com Banco Columbia
stock.marcelo@bancocolumbia.com.ar
Los invitamos a sumarse al grupo “Segurinfo” en

Segurinfo2013 Seg Desarrollo Software Ardita Stock

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Segurinfo2013 Seg Desarrollo Software Ardita Stock

Hochgeladen von

Copyright:

Verfügbare Formate

¿Cómo desarrollar

Julio César Ardita Marcelo Stock

© Todos los derechos reservados. No está permitida la

- Desarrollo de un Proyecto de Desarrollo

- Problemáticas más comunes en el desarrollo de aplicaciones

- Inclusión de la seguridad en SDLC

Proyectos de desarrollo de software

¿Qué problemáticas actuales tiene el desarrollo del software?

¿Qué problemáticas actuales tiene

Costo de solución de Problemas 40-1000

Etapas en el System Development Life Cycle

¿Por qué fracasan los proyectos de sistemas?

1. Poca participación y compromiso de usuarios

Grandes mitos y excusas flacas

Interacción con Desarrollo: ¿Ciencia o arte?

Comunicación Lenguaje Negociación

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.

Para cambiar nuestra perspectiva en un conflicto debemos

¿Participa Seguridad en el SDLC?

¿Debe participar en el SDLC?

¿Cómo y cuándo debe participar?

Grado de madurez del área

Grado de madurez de la Organización

- Microsoft’s Trustworthy Computing Security Development Lifecycle

- Team Software Process for Secure Software Development (TSP)

- Software Assurance Maturity Model

- Software Security Framework

Participación de Seguridad Informática

El área de Seguridad debe:

Participación de Seguridad Informática

- Determinación de amenazas y vulnerabilidades.

Participación de Seguridad Informática

- Diseñar controles de seguridad tomando en cuenta

Participación de Seguridad Informática

- Integrar componentes de seguridad.

Participación de Seguridad Informática

- Revalidar controles de seguridad.

Durante el análisis de requerimientos, se pueden identificar diversas

Seguridad en el análisis de requerimientos

REQUISITOS DE SEGURIDAD INFORMÁTICA PARA ADQUISICIÓN

Reducción de superficie de ataque

Principio del menor privilegio

En Windows y Unix, las aplicaciones y procesos corren en el

Implementar medidas de seguridad en TODAS las capas del

Manejo seguro de mensajes de error

Brindar únicamente la información necesaria para que el

Manejo de información sensible

Encripción y manejo de claves de encripción

Definir algoritmo de encripción

Lo que se haya definido en la etapa de análisis.

Autenticación local vs. autenticación externa (integrada).

Definición de niveles de acceso (ej: Roles)

Utilizar lenguaje claro y conciso.

¿Cómo ven los programadores al área de seguridad informática?

Áreas de desarrollo interno y la tercerización del desarrollo

Stack buffer overflows }

Heap buffer overflows

Secure Programming in Java

Secure Coding Guidelines for the Java

Secure Coding Guidelines .NET

CERT - Secure Coding