DESARROLLO DE
SOFTWARE SEGURO
YURY DANIEL ZAVALETA DE LA CRUZ
WHOAMI
DESAROLLADOR DE SOFTWARE SEGURO: INTELIGENCIA DIRANDRO PNP
CONSULTOR EN CIBERSEGURIDAD.
ETHICAL HACKING.
SECURITY RESEARCH.
IING. DE SISTEMAS – MÁSTER SEGURIDAD INFORMÁTICA
2
MITOS
La seguridad del software es responsabilidad del programador.
Nadie sabe cómo funciona, por lo tanto, no atacarán.
No se encontraron vulnerabilidades, hasta ahora...
A nadie le interesaría atacar nuestra aplicación.
El software es seguro porque corre detrás de un firewall.
El software es seguro porque usa cifrado de datos.
Si no corre como Administrator/root, no funciona.
No hay manera de explotar el software.
No hay tiempo para incluir seguridad en el desarrollo de software.
3
DESARROLLO DE SOFTWARE SEGURO
Que es la seguridad ?
El desafío de la seguridad en el desarrollo de software.
Por que necesitamos aprender a desarrollar software seguro?
Seguridad desde el diseño.
Buenas prácticas de desarrollo.
4
SEGURIDAD DESDE EL DISEÑO
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.
5
Análisis de riesgo.
CICLO DE VIDA DE SOFTWARE SEGURO.
Tareas básicas que permiten desarrollar software de calidad desde el primer
instante del propio proyecto.
Las propiedades que debe cumplir un proceso de estos sería al menos
contemplar los servicios de seguridad como confidencialidad, integridad y
disponibilidad.
Es un ciclo continuo y deberá disponer de iteraciones, que deben ser ejecutadas
durante la vida del propio software.
6
SEVEN TOUCHPOINTS FOR SOFTWARE SECURITY
Code review
Architectural risk analysis
Penetration testing
Risk-based security tests
Abuse cases
Security requirements
Security operations
7
Code review
DEMO XSS.
DEMO BRUTEFORCE.
DEMO XPATH TRAVERSAL.
DEMO UPLOAD WEBSHELL.
DEMO CSRF
DEMO ENCODE VS ENCRYPT
DEMO CHALLENGE
DEMO SQLI. 8
Architectural risk analysis
Si no conocemos el riesgo, no sabemos que debemos proteger.
Gestión del riesgo.
Todas las decisiones de gerencia se deben tomar con el conocimiento de los riesgos que implican.
Tratamiento del Riesgo.
1. Mitigar el riesgo.
2. Transferir el riesgo.
3. Evitar el riesgo.
4. Aceptar el riesgo.
Resultados.
9
DEMO MATRIZ DE RIESGOS
Penetration testing
Fases:
1. Fase de reconocimiento
2. Fase de escaneo
3. Fase de enumeración
4. Fase de acceso
5. Fase de mantenimiento de acceso
Herramientas que podemos usar:
1. ZAP PROXY
2. SQLMAP
3. BEEF
Resultados esperados.
10
Reporte gerencial
Risk-based security tests
Desarrollado desde una perspectiva de gerencia de proyecto.
Todas las actividades desarrolladas en el test de seguridad se
realizan principalmente para alinearse a los requerimientos de
seguridad.
Un Test basado en riesgos proviene de los riesgos de software.
El objetivo principal del testing de seguridad es reducir las
vulnerabilidades dentro del software.
Pruebas en caliente vs Pruebas en frio.
11
Abuse cases
Actores de Abuso
1. Descripción.
2. Recursos.
3. Habilidades.
4. Objetivos.
Interacción de Abuso.
1. Daño.
2. Rango de Privilegios.
3. Descripción de la interacción.
DEMO CASOS DE ABUSO
12
Security requirements
Optar por una perspectiva de un atacante.
Se debe ser lo mas explicito posible.
Los requerimientos deben ser testeados.
Estos requerimientos no deben estar alejados de los SQUARE
requerimientos funcionales.
Los requerimientos deben actualizarse con cierta frecuencia
DEMO REQUERIMIENTOS DE SEGURIDAD
13
Security operations
Identificar los activos que se necesitan proteger.
Determinar con precisión los activos que son vulnerables a ataques.
Entender las técnicas que usan los atacantes contra los sistemas.
Reconocer cuando una infiltración ha ocurrido.
Determinar que acciones se deben ejecutar para no afectar la postura de seguridad.
14
INTEGRACIÓN DE TOUCHPOINTS EN EL CICLO DE
DESAROLLO DE SOFTWARE
FASE DE REQUERIMIENTOS: FASE DE DISEÑO:
Architectural risk analysis Architectural risk analysis
Abuse cases
Security requirements
PLAN DE PRUEBAS: CODIFICACIÓN:
Risk-based security tests Code review 15
INTEGRACIÓN DE TOUCHPOINTS EN EL CICLO DE
DESAROLLO DE SOFTWARE
TESTING: FEEDBACK:
Architectural risk analysis Penetration testing
Penetration testing Security operations
16
BUENAS PRÁCTICAS
Separación de entornos: Desarrollo vs producción.
Defensa en profundidad.
No reutilizar contraseñas.
Principio del mínimo privilegio.
Encodificar no es cifrar.
Seguridad por oscuridad no existe.
Nunca confiar en lo que envia el usuario.
Validar todos los datos devueltos desde nuestro servidor.
17
Conclusiones
La Integración de seguridad a lo largo de todas las etapas del SLDC ahorra
tiempo y dinero.
La tendencia actual es la seguridad este involucrada en todo el ciclo de
vida de desarrollo de software.
En su mayor caso, 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.
18
GRACIAS
19
