¿Cómo desarrollar aplicaciones más seguras?...¿Cómo desarrollar aplicaciones más seguras? Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo

¿Cómo desarrollar aplicaciones más

seguras?

Julio César ArditaCTO CYBSEC

Presentada por:

Marcelo StockJefe 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 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 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

700

800

900

1000

Uni

dad

de C

osto

Costo de un error por fase

110 15-40

30-70

0

100

200

300

400

500

600

Requerimientos Diseño Desarrollo Test en desarrollo Test de Aceptación Operación

Uni

dad

de C

osto

3-6

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ño3. 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 usuarios2. Requerimientos incompletos3. Cambio de requerimientos3. Cambio de requerimientos4. Falta de soporte de la dirección5. Incompetencia tecnológica6. Falta de recursos7. Expectativas ilusorias8. Objetivos poco claros9. Cronogramas irreales10. Nuevas tecnologías11. Otros

Fuente: The Standish Group


� 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…

Grandes mitos y excusas flacas


� 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? Interacción con Desarrollo: ¿Ciencia o arte?

Métricas Métodos Métricas Métodos Standards Técnicas Standards Técnicas Training TemplatesTraining Templates

Ciencia


Comunicación Lenguaje NegociaciónComunicación Lenguaje NegociaciónResol. Problemas Conflictos ExpectativasResol. Problemas Conflictos ExpectativasInterpretaciones Juicios PercepcionesInterpretaciones Juicios PercepcionesCap. Escucha Cultura EducaciónCap. Escucha Cultura Educación

Training TemplatesTraining Templates

ArteArte


Modelos mentalesLas personas son diferentes y por lo tanto, también lo son sus representaciones de la realidad.


Buenísimo.Empecemos ya.La necesitamosen 2 meses.

Una aplicación“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.


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

¿Cómo desarrollar aplicaciones más seguras?Inclusión de la seguridad en SDLC

¿Participa Seguridad en el SDLC?¿Porqué?

¿Debe participar en el SDLC?¿Debe participar en el SDLC?¿Porqué?

¿Cómo y cuándo debe participar?


Grado de madurez del áreade Seguridad Informática

Grado de madurez de la Organización

Cultura organizacional


Modelos actuales

- ISO/IEC 21827 - Information technology — Security techniques — SystemsSecurity Engineering — Capability Maturity Model® (SSE-CMM®)

- Microsoft’s Trustworthy Computing Security Development Lifecycle- 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.- 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- 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.- 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.- 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).- 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.

¿Cómo desarrollar aplicaciones más seguras?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.� 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.

¿Cómo desarrollar aplicaciones más seguras?Seguridad en el Análisis

REQUISITOS DE SEGURIDAD INFORMÁTICA PARA ADQUISICIÓN

Y DESARROLLO DE SOFTWARE

Seguridad en el análisis de requerimientos

- 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

¿Cómo desarrollar aplicaciones más seguras?Seguridad en el Diseño

Reducción de superficie de ataqueReducció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 potencialsuperficie 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 privilegioPrincipio 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”.� 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 profundidadDefensa en profundidad

� Implementar medidas de seguridad en TODAS las capas del

sistema.

� Asumir siempre que la capa anterior pudo ser comprometida� Asumir siempre que la capa anterior pudo ser comprometida

� Nunca confiar en los datos recibidos


Manejo seguro de mensajes de errorManejo 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 � 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 sensibleManejo de información sensible

� Almacenamiento protegido

� Encripción� Hashes� 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!)� 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.- 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 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 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“.� 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.

¿Cómo desarrollar aplicaciones más seguras?Seguridad en la Codificación

ProgramadoresProgramadores


ProgramadoresProgramadores

¿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 VulnerabilidadesTipos 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

� Authentication Bypass

� Information Disclosure

� Escalamiento de privilegios

� Manejo inseguro de sesiones

� Denegación de servicio

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);

}


Revelación de informaciónRevelación de informaciónEs 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.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 seguridadRecomendaciones de seguridad

� Principio del menor privilegio.

� Evitar correr la aplicación /servicio con privilegios administrativos

� Validar SIEMPRE los valores de entrada.� 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 seguraProgramació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 Javahttp://www.secologic.org/downloads/java/051207_Draft_EUROSEC_Whitepaper_Secure_Java_Programming.pdf

Secure Coding Guidelines for the Javahttp://www.oracle.com/technetwork/java/seccodeguide-139067.html

Secure Coding Guidelines .NEThttp://msdn.microsoft.com/es-ar/library/d55zzx87(v=vs.71).aspx

CERT - Secure Codinghttp://www.cert.org/secure-coding/

¿Cómo desarrollar aplicaciones más seguras?Testing de Seguridad

Testing funcional vs. Testing de seguridadTesting funcional vs. Testing de seguridad

Bugs que se

encuentran mediante

Testing de seguridad

Funcionalidad Funcionalidad

diseñadadiseñadaFuncionalidad Funcionalidad

realreal

Bugs que se

encuentran mediante

Testing funcional


Testing funcional vs. Testing de seguridadTesting 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)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)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� 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

¿Cómo desarrollar aplicaciones más seguras?Implementación Segura

Implementación segura de aplicacionesImplementació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.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ónTopologí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 baseAseguramiento 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. 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 seguraProceso 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.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.

¿Cómo desarrollar aplicaciones más seguras?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 ArditaCTO CYBSEC

Marcelo StockJefe de Seguridad Informática

Los invitamos a sumarse al grupo “Segurinfo” en

CTO CYBSECJefe de Seguridad Informática

Banco [email protected]@bancocolumbia.com.ar

Documents

¿Cómo desarrollar aplicaciones más seguras?...¿Cómo desarrollar aplicaciones más seguras? Inclusión de la seguridad en SDLC Participación de Seguridad Informática en el desarrollo