PDF de programación - Seguridad en el ciclo de vida del desarrollo de software

“Seguridad en el ciclo de vida del

desarrollo de software”

Lic. Pablo Milano
Lic. Pablo Milano
<[email protected]>
<[email protected]>

12 de Septiembre de 2007
12 de Septiembre de 2007
Buenos Aires -- Argentina
Argentina
Buenos Aires

Seguridad en el ciclo de vida del desarrollo de software
Introduccióónn
Introducci

© 2007

Introduccióón a la seguridad en el SDLC
n a la seguridad en el SDLC
Introducci



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)

o
o
t
t
s
s
o
o
C
C

s
s
s
s

i
i

i
i
l
l

a
a
n
n
A
A

g
g
n
n
i
i
t
t
s
s
e
e
T
T

t
t
n
n
e
e
m
m
y
y
o
o
p
p
e
e
D
D

l
l

oo
ññ
e
e
s
s
D
D

i
i

nn
óó
i
i
c
c
a
a
c
c
i
i
f
f
i
i
d
d
o
o
C
C

Tiempo
Tiempo

2

Seguridad en el ciclo de vida del desarrollo de software
Introduccióónn
Introducci

© 2007

Grandes mitos y excusas flacas
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 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.

3

Seguridad en el ciclo de vida del desarrollo de software
Introduccióónn
Introducci

© 2007

Tendencia actual
Tendencia actual



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álisis
Diseño
Codificación
Testing
Deployment

4

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el anáálisis de requerimientos
lisis de requerimientos
Seguridad en el an

© 2007

Seguridad en el anáálisis de requerimientos
lisis de requerimientos
Seguridad en el an

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ón

PC / Palm / Teléfono celular

Tipos de datos que se almacenan o transfieren

Confidenciales / públicos

Requerimiento de compliance con normativas y marcos regulatorios

SOX, PCI-DSS, “A”4609

5

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el anáálisis de requerimientos
lisis de requerimientos
Seguridad en el an

© 2007

Tipos de registro que el sistema debe generar

Acceso 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 perfil
Lectura, escritura, modificación, agregado, borrado, etc.

Acciones sobre el sistema que puede hacer cada perfil

Cambiar la configuración del sistema
Arrancar o detener servicios

Modos de autenticación

Passwords, Tokens, Biométricos
1 factor, 2 factores, etc

6

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

Seguridad en el diseññoo
Seguridad en el dise

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

7

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

Buenas práácticas para el dise
Buenas pr

cticas para el diseñño de una aplicaci

o de una aplicacióón segura
n segura



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

8

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

AnAnáálisis de riesgo

lisis de riesgo –– Threat

Threat Modeling
Modeling

Técnica formal, estructurada y repetible que permite determinar y
ponderar los riesgos y amenazas a los que estará expuesta nuestra
aplicación.

Consta de las siguientes etapas:

Conformar un grupo de análisis de riesgos

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

9

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

MMéétodo STRIDE
todo STRIDE

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

10

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

ÁÁrboles de ataque
rboles de ataque

Amenaza #1

Un usuario accede en

nombre de otro

1.1

El usuario tenía una

contraseña débil

1.2

1.3

El atacante capturó

datos de autenticación

El sistema permitió un
ataque de diccionario /

de la red

fuerza bruta

1.4

El sistema de
validación /

autenticación es

defectuoso

1.5

El sistema permite
armar peticiones con
IDs de otros usuarios

1.2.1

La comunicación no
estaba encriptada

1.2.2

El mecanismo de
autenticación es

vulnerable a “replay”

de paquetes

1.4.1

El sistema de

validación no falla de

manera segura

1.4.2

El sistema de
validación es

vulnerable a ataques
de “SQL Injection”

11

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en el diseññoo
Seguridad en el dise

© 2007

MMéétodo DREAD
todo DREAD



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?

12

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en la codificacióónn
Seguridad en la codificaci

© 2007

Seguridad en la codificacióónn
Seguridad en la codificaci

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

Los tipos de vulnerabilidades más habituales son:

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

13

Seguridad en el ciclo de vida del desarrollo de software
Seguridad en la codificacióónn
Seguridad en la codificaci

© 2007

Buenas práácticas para una codificaci
Buenas pr

cticas para una codificacióón segura
n segura

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

14

Seguridad en el ciclo de vida del desarrollo de software
Testing de seguridad
de seguridad
Testing

© 2007

Testing funcional Vs. Testing de seguridad
Testing funcional Vs. Testing de seguridad

BugsBugs que se
que se

encuentran mediante
encuentran mediante
Testing de seguridad
de seguridad
Testing

Funcionalidad diseñña