cybsec tendencias2007 seguridad sdlc

Seguridad en el ciclo de vida del desarrollo de software

Lic. Pablo MilanoLic. Pablo Milano

12 de Septiembre de 200712 de Septiembre de 2007Buenos Aires Buenos Aires -- ArgentinaArgentina

2007


2

Actualmente la mayora 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 ms tarde se detectan las mismas (igual que los bugs)

IntroducciIntroduccin a la seguridad en el SDLCn a la seguridad en el SDLC

A

n

a

l

i

s

i

s

A

n

a

l

i

s

i

s

D

i

s

e

D

i

s

e

o

o

C

o

d

i

f

i

c

a

c

i

C

o

d

i

f

i

c

a

c

i

n

n

T

e

s

t

i

n

g

T

e

s

t

i

n

g

D

e

p

l

o

y

m

e

n

t

D

e

p

l

o

y

m

e

n

t

C

o

s

t

o

C

o

s

t

o

TiempoTiempo

IntroducciIntroduccinn

2007


3

La seguridad de la aplicacin es responsabilidad del programador. Nadie sabe cmo funciona, por ende, no la van a atacar. Si no se encontraron vulnerabilidades hasta ahora A nadie le interesara atacar nuestra aplicacin. La aplicacin es segura porque corre detrs de un firewall. La aplicacin es segura porque usa encripcin. 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


2007


4

Participacin de Seguridad Informtica desde el comienzo de todos los proyectos de desarrollo.

Incorporar seguridad a lo largo de todas las etapas del ciclo devida del desarrollo de software (SDLC). Anlisis Diseo Codificacin Testing Deployment

Tendencia actualTendencia actual


2007


5

Seguridad en el anSeguridad en el anlisis de requerimientoslisis de requerimientos

Durante el anlisis de requerimientos, se pueden identificar diversas

caractersticas que derivarn en los requerimientos de seguridad del

software. Por ejemplo:

Arquitectura de la aplicacin Cliente/servidor o Desktop?

Plataforma donde correr la aplicacin PC / Palm / Telfono celular

Tipos de datos que se almacenan o transfieren Confidenciales / pblicos

Requerimiento de compliance con normativas y marcos regulatorios SOX, PCI-DSS, A 4609


2007


6


Tipos de registro que el sistema debe generar Acceso a recursos, uso de privilegios, etc.

Perfiles de usuario necesarios para la aplicacin Administrador, revisor, editor, usuario bsico, etc.

Tipos de acceso a los datos por parte de cada perfil Lectura, escritura, modificacin, agregado, borrado, etc.

Acciones sobre el sistema que puede hacer cada perfil Cambiar la configuracin del sistema Arrancar o detener servicios

Modos de autenticacin Passwords, Tokens, Biomtricos 1 factor, 2 factores, etc

2007


7

Muchas de las vulnerabilidades encontradas en aplicaciones tuvieron

su causa en errores de diseo. Ej:

Aplicacin Home banking (WEB)

Inclua el nmero de cuenta en el request de transferencias No validaba que la cuenta origen perteneciera al usuario logueado Vulnerabilidad: Transferencias desde cuentas ajenas

Aplicacin de Adm y Finanzas (Consola Unix)

Tomaba el usuario de una variable de entorno Permita que el usuario escapara a un shell Vulnerabilidad: Se puede establecer un usuario arbitrario

Seguridad en el diseSeguridad en el diseoo


2007


8

Reduccin de Superficie de ataque Criterio del menor privilegio Fallar de manera segura Criterio de defensa en profundidad Diseo seguro de mensajes de error Diseo seguro de autenticacin Separacin de privilegios Interaccin amigable con Firewalls e IDS's. Administracin segura informacin Sensible Diseo de Auditora y Logging Anlisis de riesgo

Buenas prBuenas prcticas para el disecticas para el diseo de una aplicacio de una aplicacin seguran segura


2007


9

Tcnica formal, estructurada y repetible que permite determinar y

ponderar los riesgos y amenazas a los que estar expuesta nuestra

aplicacin.

AnAnlisis de riesgo lisis de riesgo ThreatThreat ModelingModeling


Consta de las siguientes etapas:

1) Conformar un grupo de anlisis de riesgos

2) Descomponer la aplicacin e identificar componentes clave.

3) Determinar las amenazas a cada componente de la aplicacin.

4) Asignar un valor a cada amenaza.

5) Decidir cmo responder a las amenazas.

6) Identificar las tcnicas y tecnologas necesarias para mitigar los

riesgos identificados.

2007


10

MMtodo STRIDEtodo STRIDE


Ayuda a identificar amenazas en los componentes de un sistema Su nombre es un acrnimo 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 accin.

IInformation Disclosure: Divulgar informacin a usuarios no autorizados.

DDenial of Service: Provocar que un servicio deje de funcionar.

EElevation of privilege: Conseguir privilegios mayores a los asignados

2007


11

rboles de ataquerboles de ataque


1.1El usuario tena una

contrasea dbil

1.2El atacante captur

datos de autenticacin de la red

1.3El sistema permiti un ataque de diccionario /

fuerza bruta

1.4El sistema de validacin /

autenticacin es defectuoso

1.5El sistema permite

armar peticiones con IDs de otros usuarios

1.2.1La comunicacin no estaba encriptada

1.2.2El mecanismo de autenticacin es

vulnerable a replay de paquetes

1.4.1El sistema de

validacin no falla de manera segura

1.4.2El sistema de validacin es

vulnerable a ataques de SQL Injection

Amenaza #1Un usuario accede en

nombre de otro

2007


12

MMtodo DREADtodo DREAD


Ayuda a ponderar las amenazas identificadas. Es un acrnimo de los siguientes 5 tems:

DDamage Potencial: Cun importante es el dao de esta amenaza?

RReproducibility: Cun reproducible es la vulnerabilidad?

EExploitability: Cun fcil es de explotar?

AAffected Users: Cules y cuntos usuarios se veran afectados?

DDiscoverability: Cun fcil de descubrir es la vulnerabilidad?

2007


13

La falta de controles adecuados en la codificacin, muchas veces

deriva en vulnerabilidades que pueden comprometer a la aplicacin o

a los datos de la misma

Seguridad en la codificaciSeguridad en la codificacinn

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 Denegacin de servicio

Los tipos de vulnerabilidades ms habituales son:


2007


14

Validar siempre los datos de entrada antes de procesarlos Nunca confiar en que los datos recibidos sean correctos. Realizar validacin de datos en todas las capas Usar siempre criterio de White List en las validaciones Controlar tamao 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 dinmicas por Stored Procedures Evitar generar cdigo con valores ingresados por el usuario No mezclar datos con cdigo Capturar errores de capas inferiores y no mostrarlos al usuario

Buenas prBuenas prcticas para una codificacicticas para una codificacin seguran segura


2007


15

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

Funcionalidad diseFuncionalidad diseadaada

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


2007


16

Testing de seguridad funcional

Testing Funcional (clsico) aplicado a las funcionalidades de

seguridad de una aplicacin. Ej:

TTcnicas de testing de seguridadcnicas de testing de seguridad


Testing de seguridad basado en Riesgo

Tcnica que se desprende del Threat Modelling Se identifican todas las interfaces de la aplicacin Se generan casos de test sobre cada interfaz basado en STRIDE

Req. de autenticacinReq. de complejidad de contraseasBloqueo automtico de cuentas Funcionalidad de captchas

Restricciones de acceso segn diseoMecanismos de registro y loggingMensajes de error especificados

2007


17

Testing con un cliente / server falso

Consiste en disear un cliente o server Ad Hoc que permita: Enviar peticiones /respuestas incorrectas o invlidas. 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 aplicacin al lmite Generar una carga alta de peticiones/transacciones a la aplicacin. Mantener esta carga durante tiempos prolongados. Simular trfico en rfagas.

TTcnicas de cnicas de testingtesting de seguridadde seguridad


2007


18

Test de mutacin de datos

Se testea la aplicacin ingresando en sus interfaces datos mutados

TTcnicas de cnicas de testingtesting de seguridadde seguridad


Revisin de cdigo

Permite encontrar vulnerabilidades que son muy difciles de detectar

con otros mtodos de testing de seguridad (ej: BackDoors) Enfoque tradicional: Grupo de revisin Enfoque rpido: Revision por pares

Diferente signo Diferente tipo Diferente longitud Fuera de rango

Caracteres especiales Cdigo (ej: javascripts) Valores nulos Valores aleatorios

2007


19

Si no se implementa la aplicacin de forma segura, se pueden echar

por tierra los esfuerzos de las etapas anteriores.

Hardening de software de base Servicios innecesarios Usuarios y contraseas default Configuracin de intrpretes

Proceso de implementacin Separacin de ambientes

Administracin de implementacin y mantenimiento Releases y Patches Firma de cdigo

Seguridad en la implementaciSeguridad en la implementacin (deployment)n (deployment)

Seguridad en la ImplementaciSeguridad en la Implementacinn

2007


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 mayora de las vulnerabilidades no se deben a errores de codificacin, sino a defectos de diseo.

Existen buenas prcticas y tcnicas especficas para insertar seguridad en cada etapa del SDLC.

ConclusionesConclusiones

2007


21

Preguntas?Preguntas?

cybsec tendencias2007 seguridad sdlc

Documents