“seguridad en el ciclo de vida del desarrollo de...
TRANSCRIPT
“Seguridad en el ciclo de vida del desarrollo de software”
Lic. Pablo MilanoLic. Pablo Milano<[email protected]><[email protected]>
12 de Septiembre de 200712 de Septiembre de 2007Buenos Aires Buenos Aires -- ArgentinaArgentina
© 2007
Seguridad en el ciclo de vida del desarrollo de software
2
Actualmente la mayoría de los procesos de desarrollo no incluyen
seguridad, o bien la incluyen al final (etapa de testing)
El costo de solucionar las vulnerabilidades es mayor cuanto más
tarde se detectan las mismas (igual que los bugs)
IntroducciIntroduccióón a la seguridad en el SDLCn a la seguridad en el SDLC
Analis
isAnalis
is
Dis
eDis
e ññoo
Codific
aci
Codific
acióónn
Tes
ting
Tes
ting
Dep
loym
ent
Dep
loym
ent
Cost
oCost
o
TiempoTiempo
IntroducciIntroduccióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
3
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 no corre como Administrator / root, no funciona.
Si, ese feature (que es inseguro) viene habilitado por default, pero el
administrador lo puede deshabilitar.
No hay manera de explotarla.
No hay tiempo para incluir seguridad.
Grandes mitos y excusas flacasGrandes mitos y excusas flacas
IntroducciIntroduccióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
4
Participación de Seguridad Informática desde el comienzo de
todos los proyectos de desarrollo.
Incorporar seguridad a lo largo de todas las etapas del ciclo de
vida del desarrollo de software (SDLC).AnálisisDiseñoCodificaciónTestingDeployment
Tendencia actualTendencia actual
IntroducciIntroduccióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
5
Seguridad en el anSeguridad en el anáálisis de requerimientoslisis de requerimientos
Durante el análisis de requerimientos, se pueden identificar diversas
características que derivarán en los requerimientos de seguridad del
software. Por ejemplo:
Arquitectura de la aplicación¿Cliente/servidor o Desktop?
Plataforma donde correrá la aplicaciónPC / Palm / Teléfono celular
Tipos de datos que se almacenan o transfierenConfidenciales / públicos
Requerimiento de compliance con normativas y marcos regulatoriosSOX, PCI-DSS, “A” 4609
Seguridad en el anSeguridad en el anáálisis de requerimientoslisis de requerimientos
© 2007
Seguridad en el ciclo de vida del desarrollo de software
6
Seguridad en el anSeguridad en el anáálisis de requerimientoslisis de requerimientos
Tipos de registro que el sistema debe generarAcceso a recursos, uso de privilegios, etc.
Perfiles de usuario necesarios para la aplicación
Administrador, revisor, editor, usuario básico, etc.
Tipos de acceso a los datos por parte de cada perfilLectura, escritura, modificación, agregado, borrado, etc.
Acciones sobre el sistema que puede hacer cada perfilCambiar la configuración del sistemaArrancar o detener servicios
Modos de autenticaciónPasswords, Tokens, Biométricos1 factor, 2 factores, etc
© 2007
Seguridad en el ciclo de vida del desarrollo de software
7
Muchas de las vulnerabilidades encontradas en aplicaciones tuvieron
su causa en errores de diseño. Ej:
Aplicación Home banking (WEB)
Incluía el número de cuenta en el request de transferencias
No validaba que la cuenta origen perteneciera al usuario logueado
Vulnerabilidad: Transferencias desde cuentas ajenas
Aplicación de Adm y Finanzas (Consola Unix)
Tomaba el usuario de una variable de entorno
Permitía que el usuario “escapara” a un shell
Vulnerabilidad: Se puede establecer un usuario arbitrario
Seguridad en el diseSeguridad en el diseññoo
Seguridad en el diseSeguridad en el diseññoo
© 2007
Seguridad en el ciclo de vida del desarrollo de software
8
Reducción de Superficie de ataque
Criterio del menor privilegio
Fallar de manera segura
Criterio de defensa en profundidad
Diseño seguro de mensajes de error
Diseño seguro de autenticación
Separación de privilegios
Interacción “amigable” con Firewalls e IDS's.
Administración segura información Sensible
Diseño de Auditoría y Logging
Análisis de riesgo
Buenas prBuenas práácticas para el disecticas para el diseñño de una aplicacio de una aplicacióón seguran segura
Seguridad en el diseSeguridad en el diseññoo
© 2007
Seguridad en el ciclo de vida del desarrollo de software
9
Técnica formal, estructurada y repetible que permite determinar y
ponderar los riesgos y amenazas a los que estará expuesta nuestra
aplicación.
AnAnáálisis de riesgo lisis de riesgo –– ThreatThreat ModelingModeling
Seguridad en el diseSeguridad en el diseññoo
Consta de las siguientes etapas:
1) Conformar un grupo de análisis de riesgos
2) Descomponer la aplicación e identificar componentes clave.
3) Determinar las amenazas a cada componente de la aplicación.
4) Asignar un valor a cada amenaza.
5) Decidir cómo responder a las amenazas.
6) Identificar las técnicas y tecnologías necesarias para mitigar los
riesgos identificados.
© 2007
Seguridad en el ciclo de vida del desarrollo de software
10
MMéétodo STRIDEtodo STRIDE
Seguridad en el diseSeguridad en el diseññoo
Ayuda a identificar amenazas en los componentes de un sistema
Su nombre es un acrónimo de:
SSpoofing Identity: Suplantar la identidad de otro usuario o servicio.
TTampering with Data: Modificar maliciosamente datos almacenados.
RRepudiation: Imposibilidad de identificar el autor de una acción.
IInformation Disclosure: Divulgar información a usuarios no autorizados.
DDenial of Service: Provocar que un servicio deje de funcionar.
EElevation of privilege: Conseguir privilegios mayores a los asignados
© 2007
Seguridad en el ciclo de vida del desarrollo de software
11
ÁÁrboles de ataquerboles de ataque
Seguridad en el diseSeguridad en el diseññoo
1.1El usuario tenía una
contraseña débil
1.2El atacante capturó
datos de autenticación de la red
1.3El sistema permitió un ataque de diccionario /
fuerza bruta
1.4El sistema de validación /
autenticación es defectuoso
1.5El sistema permite
armar peticiones con IDs de otros usuarios
1.2.1La comunicación no estaba encriptada
1.2.2El mecanismo de autenticación es
vulnerable a “replay” de paquetes
1.4.1El sistema de
validación no falla de manera segura
1.4.2El sistema de validación es
vulnerable a ataques de “SQL Injection”
Amenaza #1Un usuario accede en
nombre de otro
© 2007
Seguridad en el ciclo de vida del desarrollo de software
12
MMéétodo DREADtodo DREAD
Seguridad en el diseSeguridad en el diseññoo
Ayuda a ponderar las amenazas identificadas.
Es un acrónimo de los siguientes 5 ítems:
DDamage Potencial: ¿Cuán importante es el daño de esta amenaza?
RReproducibility: ¿Cuán reproducible es la vulnerabilidad?
EExploitability: ¿Cuán fácil es de explotar?
AAffected Users: ¿Cuáles y cuántos usuarios se verían afectados?
DDiscoverability: ¿Cuán fácil de descubrir es la vulnerabilidad?
© 2007
Seguridad en el ciclo de vida del desarrollo de software
13
La falta de controles adecuados en la codificación, muchas veces
deriva en vulnerabilidades que pueden comprometer a la aplicación o
a los datos de la misma
Seguridad en la codificaciSeguridad en la codificacióónn
Stack buffer overflowsHeap buffer overflowsSQL InjectionsCross Site Scripting (XSS)Directory Traversal
Authentication BypassInformation DisclosureEscalamiento de privilegiosManejo inseguro de sesionesDenegación de servicio
Los tipos de vulnerabilidades más habituales son:
Seguridad en la codificaciSeguridad en la codificacióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
14
Validar siempre los datos de entrada antes de procesarlos
Nunca confiar en que los datos recibidos sean correctos.
Realizar validación de datos en todas las capas
Usar siempre criterio de “White List” en las validaciones
Controlar tamaño y tipo de datos
“Sanitizar” los valores de entrada y salida
Eliminar o “escapear” caracteres especiales
Transformar los datos de entrada a un “encoding” establecido
Reemplazar sentencias SQL dinámicas por Stored Procedures
Evitar generar código con valores ingresados por el usuario
No mezclar datos con código
Capturar errores de capas inferiores y no mostrarlos al usuario
Buenas prBuenas práácticas para una codificacicticas para una codificacióón seguran segura
Seguridad en la codificaciSeguridad en la codificacióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
15
Testing funcional Vs. Testing de seguridadTesting funcional Vs. Testing de seguridad
Funcionalidad diseFuncionalidad diseññadaada
Funcionalidad realFuncionalidad real
BugsBugs que se que se
encuentran mediante encuentran mediante
TestingTesting funcionalfuncional
BugsBugs que se que se
encuentran mediante encuentran mediante
TestingTesting de seguridadde seguridad
TestingTesting de seguridadde seguridad
© 2007
Seguridad en el ciclo de vida del desarrollo de software
16
Testing de seguridad funcional
Testing Funcional (clásico) aplicado a las funcionalidades de
seguridad de una aplicación. Ej:
TTéécnicas de testing de seguridadcnicas de testing de seguridad
TestingTesting de seguridadde seguridad
Testing de seguridad basado en Riesgo
Técnica que se desprende del Threat Modelling
Se identifican todas las interfaces de la aplicación
Se generan casos de test sobre cada interfaz basado en STRIDE
Req. de autenticaciónReq. de complejidad de contraseñasBloqueo automático de cuentas Funcionalidad de captchas
Restricciones de acceso según diseñoMecanismos de registro y loggingMensajes de error especificados
© 2007
Seguridad en el ciclo de vida del desarrollo de software
17
Testing con un cliente / server falso
Consiste en diseñar un cliente o server “Ad Hoc” que permita:Enviar peticiones /respuestas incorrectas o inválidas.Enviar peticiones/ respuestas fuera de orden.Insertar delays arbitrarios.Comportarse de manera diferente al cliente o servidor real.
Test de stress
Consiste en llevar la carga o funcionalidad de la aplicación al límiteGenerar una carga alta de peticiones/transacciones a la aplicación.Mantener esta carga durante tiempos prolongados.Simular tráfico en ráfagas.
TTéécnicas de cnicas de testingtesting de seguridadde seguridad
TestingTesting de seguridadde seguridad
© 2007
Seguridad en el ciclo de vida del desarrollo de software
18
Test de mutación de datos
Se testea la aplicación ingresando en sus interfaces datos “mutados”
TTéécnicas de cnicas de testingtesting de seguridadde seguridad
TestingTesting de seguridadde seguridad
Revisión de código
Permite encontrar vulnerabilidades que son muy difíciles de detectar
con otros métodos de testing de seguridad (ej: BackDoors)Enfoque tradicional: Grupo de revisiónEnfoque rápido: Revision por pares
Diferente signoDiferente tipoDiferente longitudFuera de rango
Caracteres especialesCódigo (ej: javascripts)Valores nulosValores aleatorios
© 2007
Seguridad en el ciclo de vida del desarrollo de software
19
Si no se implementa la aplicación de forma segura, se pueden echar
por tierra los esfuerzos de las etapas anteriores.
Hardening de software de baseServicios innecesariosUsuarios y contraseñas defaultConfiguración de intérpretes
Proceso de implementaciónSeparación de ambientes
Administración de implementación y mantenimientoReleases y PatchesFirma de código
Seguridad en la implementaciSeguridad en la implementacióón (deployment)n (deployment)
Seguridad en la ImplementaciSeguridad en la Implementacióónn
© 2007
Seguridad en el ciclo de vida del desarrollo de software
20
Integrando seguridad a lo largo de todas las etapas del SLDC se
ahorra tiempo y dinero.
La tendencia actual es que SI participe desde el principio de los
proyectos de desarrollo.
La mayoría de las vulnerabilidades no se deben a errores de
codificación, sino a defectos de diseño.
Existen buenas prácticas y técnicas específicas para insertar
seguridad en cada etapa del SDLC.
ConclusionesConclusiones
© 2007
Seguridad en el ciclo de vida del desarrollo de software
21
¿¿Preguntas?Preguntas?