CyberCampES 2014 5-7 diciembre

Madrid

¿YO?

• Simón Roses Femerling

• Fundador & CEO, VULNEX www.vulnex.com

• Blog: www.simonroses.com

• @simonroses | @vulnexsl

• Ex: Microsoft, PwC, @Stake

• Beca del DARPA Cyber Fast Track (CFT) para investigar sobre seguridad en el ciclo de desarrollo de software http://www.simonroses.com/es/2014/06/mi-visita-al-pentagono/

• Ponente: Black Hat, RSA, HITB, OWASP, AppSec USA, SOURCE, DeepSec, TECHNET

OBJETIVOS DE LA CHARLA

• Cómo realizar una auditoría de código fuente de forma práctica

• Métodos, métricas y herramientas

AGENDA

1. Seguridad en el ciclo de desarrollo

2. ¡Una de métricas!

3. Auditoría de código fuente práctica

4. Inteligencia aplicada a la auditoría

5. Conclusiones

1. ¡EL CÓDIGO CADA VEZ MÁS COMPLEJO!

Software SLOC

Firefox 14 Millones

Windows Server 2003 50 Millones

Debian 7.0 419 Millones

Mac OS X 10.4 86 Millones

Linux Kernel 2.6.25 13.5 Millones

Linux Kernel 3.6 15.9 Millones

1. TAMAÑO DEL CÓDIGO FUENTE

http://www.informationisbeautiful.net/visualizations/million-lines-of-code/

1. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1. OPENSAMM

1. MICROSOFT SDL

1. ¡SE TRATA DE AHORRAR DINERO!

1. PRUEBAS DE SEGURIDAD VS AUDITORÍA DE CÓDIGO

PRUEBAS DE SEGURIDAD

AUDITORÍA DE CÓDIGO

PROS • Rápido • < Precio

• Amplia cobertura • Conocimiento

CONTRAS • Cobertura limitada • A ciegas

• Lento • > Precio

1. ¿DOCUMENTACIÓN, POR FAVOR?

1. ¿MOMENTO DE UNA AUDITORÍA?

1. ¿POR DÓNDE EMPEZAR?

• Ficheros • Redes • Procesos • Cifrado • Autenticación • ??

1. ¿CÓDIGO FUNCIONAL?

1. ¿HERRAMIENTAS?

2. CONOCIMIENTO DEL CÓDIGO

• ¿Qué API se esta utilizando?

• ¿Número de funciones?

• ¿Entrada / salida de las funciones?

• Relación entre funciones

• ¿Qué dicen los comentarios?

• Complejidad del código

2. MÉTRICAS DE CÓDIGO (COMIENZO AUDITORÍA)

• Tema controvertido ¡pero necesario!

• Tipos de métricas:

– LOC / KLOC / MLOC : línea de código, mil líneas de código, millón de líneas

código

– Complejidad de la función (Cyclomatic Complexity)

– Número de: • Líneas (LOC, KLOC, MLOC)

• Código

• Líneas vacías

• Comentarios

• Funciones

• Clases

• Instrucciones

• …

– Longitud de las líneas

– …

2. COMPLEJIDAD DEL CÓDIGO

• Se cuenta el número de caminos linealmente independientes que puede tomar el código – If....else

– switch

– case

– catch

– while

– do

– ….

• Se trata de obtener una idea de la complejidad de las funciones

• ¡Complejidad es el enemigo de la seguridad!

• Creado por Thomas McCabe (NSA – 1976)

http://www.literateprogramming.com/mccabe.pdf

2. UMBRAL DE COMPLEJIDAD DEL CÓDIGO

2. NOTACIÓN PARA ANÁLISIS DE CÓDIGO FUENTE

www.mccabe.com/ppt/SoftwareQualityMetricsToIdentifyRisk.ppt

2. ANÁLISIS VISUAL DE CÓDIGO FUENTE

BINARIO CÓDIGO FUENTE

2. SOURCE MONITOR

2. CODE ANALYZER I

2. CODE ANALYZER II

2. DEMO 1: SOURCE MONITOR

2. DEMO 2: CODE ANALYZER

2. DEMO 3: LINE COUNTER

2. MÉTRICAS DESPUÉS AUDITORÍA CÓDIGO I

• Defect Density (DD): numero de fallos confirmados durante un período de tiempo dividido por el tamaño del software

• Período: – Tiempo concreto (un mes, semanas, etc.)

– Una fase del SDLC

– Todo el SDLC

• Tamaño: – Número funciones

– Número de LOC

Defect Density =

Número de fallos

Tamaño

2. MÉTRICAS DESPUÉS AUDITORÍA CÓDIGO II

• Risk Density (RD): Similar al Defect Density pero medido en función del riesgo (alto, medio, bajo)

• RD = X Riesgos / LOC o X Riesgos / Funciones

• Ejemplo: – 5 Riegos Altos por 5000 LOC

– 3 Riesgos Medios por 10 Funciones

2. MÉTRICAS, OWASP

3. ¿QUÉ HACE MEJOR UNA AUDITORIA DE CÓDIGO?

• Casi 100% cobertura del código

• Método sistemático para encontrar fallos

• Mejor para encontrar fallos de diseño

• Podemos encontrar todos los fallos de la misma categoría

• La única forma de encontrar según qué fallos

3. PROCESO DE AUDITORÍA CÓDIGO FUENTE – OWASP

https://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents

3. BUSCANDO VULNERABILIDADES

Manual

Estático

Leer código

Desensamblar

Binario

Dinámico Depurador

Symbols código

Públicos

symbols

Desensamblar Binario

Automatizado

Estático Análisis

Dinámico

Pruebas Negativas

Fuzzing

Tonto

Inteligente

Pruebas Positivas

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. EL PLAN

1. Definir ámbito

2. Definir equipo

3. Definir tiempo

4. Definir amenazas

5. Definer herramientas (software y hardware)

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. EL EQUIPO

1. 1..N

2. Roles 1. Auditor Líder

2. Desarrolladores

3. Arch, seguridad, jefes proyecto, dev y testers

4. Auditores junior y senior

3. Habilidades 1. Tecnología (Web != App Móvil != Aplicación)

2. Lenguaje (ASM != C/C++ != Java != .NET)

3. Seguridad (Cifrado, Validación datos, AuthN, AuthZ, etc.)

4. Vulnerabilidades (OWASP Top 10, Corrupciones memoria, etc.)

4. Recomendado tener diferentes perfiles

5. Formación

3. SESIONES

1. Grupos pequeños (2-4)

2. Cada uno con su propio equipo / herramientas

3. Un buen auditor entre 100 y 1000 líneas código (LOC) hora

4. Tiempo

5. 3-5 sesiones auditoría código a la semana

6. 2-4 reuniones a la semana (10 min – 1 hora máx.)

Recomendación Tiempo

Microsoft 1-3 horas seguidas / día

Microsoft 2 horas mañana / 2 horas tarde (4 horas total)

MITRE 3000 LOC día

Wikipedia 150 LOC / hora

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. FASES DE LA AUDITORÍA

• Conocimiento

1.

• Identificando vectores ataque

2. • Priorizar auditoría

3.

• Vulnerabilidades

4.

3. FASES DE LA AUDITORÍA

• Conocimiento

1.

• Identificando vectores ataque

2. • Priorizar auditoría

3.

• Vulnerabilidades

4.

3. CONOCIMIENTO CÓDIGO

• Métodos – Estático -> Leer código

– Dinámico -> Entorno pruebas, ejecución

• Documentación – Modelos de amenazas

– Diseño

– Funcionalidad

– Testing

– Auditoría anteriores ¿?

• Enumerar entorno y tecnologías – Sistemas

– Lenguajes, librerías

– Búsqueda de CVE

3. EL SOFTWARE YA NO SE ESCRIBE, SINO QUE SE COMPONE

3. FASES DE LA AUDITORÍA

• Conocimiento

1.

• Identificando vectores ataque

2. • Priorizar auditoría

3.

• Vulnerabilidades

4.

3. IDENTIFICANDO VECTORES DE ATAQUE

• Modelo de Amenazas

• Puntos de Entrada/Salida – Datos no confiables

– Nivel de acceso

• Análisis estático automatizado

• Léxico – Patrones

– Expresiones regulares

• Historia del código – Vulnerabilidades

– Auditorías

3. ¿QUÉ NOS OFRECE EL MODELO DE AMENAZAS?

• Incluye interfaces y niveles de privilegio

• Componentes

• Riesgos

• Ayuda a: – Entender el sistema

– Todo el mundo en el mismo punto

– Identificar riesgos potenciales

– Focalizar el trabajo

1001010010111011001 0101010101010111100 0100001010010100010 1000110100100010100 0101001010000101110

1001010010111011001 0101010101010111100 0100001010010100010 1000110100100010100 0101001010000101110

Código solo accesible por usuarios autenticados

Código accesible por todo el mundo

3. MICROSOFT SDL TM

http://blogs.microsoft.com/cybertrust/2014/04/15/introducing-microsoft-threat-modeling-tool-2014/

3. GREP KUNG-FU

Add2Ptr\(.*,.*->.*\) alloc.*(.*\*.*sizeof(WCHAR)) \+.*wcslen\(.*\) \*.*wcslen \(.*\) wcslen\(.*\).*\* ISSUE NOTICE FUTURE TODO REVIEW BUGBUG FIXFIX FIX GUBGUB HACKHACK

user

admin

pwd

http

ftp

key

secret

port

root

anon

pass

3. DEMO 4: BAREGREP

3. DEMO 5: VISUAL GREP

3. FASES DE LA AUDITORÍA

• Conocimiento

1.

• Identificando vectores ataque

2. • Priorizar auditoría

3.

• Vulnerabilidades

4.

3. PRIORIZAR AUDITORÍA

• Más revisión – Código viejo

– Por defecto

– Elevado privilegios

– Acceso anónimo

– Escucha en red

– UDP

– C/C++ / ASM

– Historial de fallos

– Complejo

– Interfaz sin documentar

– Contiene información sensible

– Código difícil de mantener

• Menos revisión – Código nuevo

– Cerrado por defecto

– Mínimos privilegios

– Acceso autenticado

– No escucha en red

– TCP

– Código gestionado

– Historial limpio

– Código simple

– Interfaces documentados

– No contiene información sensible

– Código fácil de mantener

3. PASES DE LA AUDITORÍA

• Multi-pase

– Pase #1

• Uso de herramientas análisis estático/dinámico

– Pase #2

• Buscar patrones de vulnerabilidades

– Pase #3

• Análisis en profundidad de código potencialmente con riesgo

3. FASES DE LA AUDITORÍA

• Conocimiento

1.

• Identificando vectores ataque

2. • Priorizar auditoría

3.

• Vulnerabilidades

4.

3. VULNERABILIDADES I

• OWASP Top 10 – Web: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

– App Móviles: https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

• .NET Code Review – http://msdn.microsoft.com/en-us/library/ff648637.aspx

• OWASP Top 10 for .NET developers – http://www.troyhunt.com/2011/12/free-ebook-owasp-top-10-for-net.html

• Secure Coding Guidelines for Java – http://www.oracle.com/technetwork/java/seccodeguide-139067.html

• Common Weaknesses Enumeration (CWE) (+700 bugs) http://cwe.mitre.org/index.html

3. VULNERABILIDADES II

• Corrupciones de memoria

• Específico del lenguaje

• Construcciones lógicas (bucles, saltos)

• Sincronización

• Validación

• Escalada de privilegios

• Abuso de protocolos

• Específico de la plataforma

• …

3. VULNERABILIDADES III

• Inyección SQL

• Cross-Site Scripting (XSS)

• Acceso a datos

• Validación datos

• Autentificación

• Autorización

• Datos sensibles

• Código inseguro

• Código Nativo vs Código Interpretado

• Secretos en código • Gestión inadecuada

de errores • Ficheros de

configuración • Code Access

Security (CAS) • Cifrado • Interfaces no

documentados • Puertas traseras • Problemas en Hilos

3. FUNCIONES INSEGURAS

• http://msdn.microsoft.com/en-us/library/bb288454.aspx

3. USO DE CIFRADO

Microsoft SDL Algoritmos de cifrado aprobados

3. BUG: CAN-2004-0204, DIRECTORY TRAVERSAL

public class CrystalImageHandler : WebControl {

private string tmpdir = null;

protected override void Render(HtmlTextWriter writer) {

string filepath;

string dynamicImage = (string)Context.Request.QueryString.Get("dynamicimage");

if (tmpdir == null) {

tmpdir = ViewerGlobal.GetImageDirectory();

}

filePath = tmpdir + dynamicImage; FileStream imagestream = new FileStream (filePath, FileMode.Open, FileAccess.Read); ... File.Delete (filePath);

}

}

http://foo.bar/crystalreportviewers/crystalimagehandler.aspx?dynamicimage=..\..\..\..\..\mydocuments\private\passwords.txt

3. BUG: FUNCIONES PROHIBIDAS

• Uso de función prohibida!!

• Pero que impacto?

3. BUG: INYECCIÓN COMANDOS

• c:\> myapp.exe nominas.db

3. BUG: HOLA INYECCIÓN SQL

• Un clásico ¡¡pero sigue muy activo!!

• http://foo.bar/loguser.aspx?usuario=pepe&pwd=12345 • ´ OR 1=1—

3. QUÉ BUSCAR: INYECCIÓN SQL

Lenguaje Buscar

C# Sql, SqlCient, OracleClient, SqlDataAdapter

PHP Mysql, connect

Ruby ActiveRecord

Python MySQLDB

Java java.sql, sql

SQL exec, execute, sp_executesql

3. BUG: HOLA XSS

• Otro clásico ¡¡y también muy activo!!

• http://foo.bar/welcome.aspx?Username=pepe • <script>alert(“HOLA”)</script>

3. BUG: CVE-2014-9031, WORDPRESS 3, XSS

• Fichero: wp-includes/formatting.php

• Fallo: Inyección XSS

• PoC: [<blockquote cite="]">["

onmouseover="alert('hello');" ] • Aviso de seguridad:

http://klikki.fi/adv/wordpress.html

• 20 noviembre: 86% wordpress vulnerables en Internet

3. QUÉ BUSCAR: XSS

Lenguaje Buscar

ASP.NET PathInfo, Request.*, Response.*, <%=, *.text y *.value

PHP $_REQUEST, $_GET, $_POST y $_SERVER

Ruby on Rails <%=, cookies, redirect_to

Python form.getvalue, cookies

JavaServer Pages (JSP) addCookie, getRequest, request.getParameter

3. BUG: CÓDIGO MALICIOSO OCULTO

• Muy difícil de encontrar mediante

pruebas de seguridad

3. BUG: GESTIÓN INADECUADA DE ERRORES I

• ¿¿Seguro que quieres capturar todos los errores??

3. BUG: GESTIÓN INADECUADA DE ERRORES II

• Información sensible en fichero claro

3. BUG: SECRETROS EN CÓDIGO

• ¡Contraseña metida en código!

3. BUG: USO INSEGURO DE GENERADOR DE NÚMEROS PSEUDOALEATORIOS

Lenguaje Buscar

C / C++ Rand(), random(), seed(), etc.

C# Clase Random

Java Java.util.Random

Python Random

Ruby rand()

• Usos: • Cifrado • Generación de sesiones

3. DEMO 6: RATS

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. SEGUIMIENTO DEL PROCESO

• Simple y fácil

• Llegar hasta lo más abajo posible – Sistema

– Componente

– Módulo

– Función

– Bloque

• Utilizar sistema de seguimiento de errores – Excel

– Mantis Bug Tracker

– Bugzilla

– Visual Studio Team Foundation Server (TFS)

– …

3. PROCESO DE AUDITORÍA DE CÓDIGO FUENTE

Plan

Equipo

Auditoría Seguimiento

Solución

3. SOLUCIONAR VULNERABILIDADES

• Proporcionar soluciones viables y razonables

• Limitar el tiempo “PoC”

• Trabajar con los programadores

• Re-evaluar mitigación

3. COMPILADORES

• Pueden aplicar cambios en el binario generado

• Incluyen defensas: – Visual Studio:

• Stack Cookies (GS), funciones prohibidas, /SDL, /NXCOMPAT, /DYNAMICBASE

– GCC: • CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2"

• LDFLAGS="-Wl,-z,now -Wl,-z,relro"

• Analizar binarios con un verificador de binarios

3. VERIFICAR LA SEGURIDAD DE BINARIOS

• Microsoft BinScope Binary Analyzer http://www.microsoft.com/en-us/download/details.aspx?id=11910

• RECX Binary Assurance for Windows https://www.recx.co.uk/products/exeaudit.php

• VULNEX BinSecSweeper http://www.vulnex.com/es/binsecsweeper.html

3. BINSCOPE 2014

http://blogs.microsoft.com/cybertrust/2014/11/20/new-binscope-released/

3. BINSECSWEEPER EN ACCIÓN

4. INTELIGENCIA APLICADA A LA AUDITORÍA DE CÓDIGO

• Generalmente no tendremos suficiente tiempo

• Priorizar la auditoría

• Entender el código lo antes posible

• Podemos obtener inteligencia del código fuente

4. HERRAMIENTAS

• ¡Por supuesto que debemos usar!

• ¡Debemos entender qué hace y cómo utilizarla correctamente!

• ¡Combinar herramientas! – Métricas

– Grep

– Análisis estático / dinámico

• No son mágicas, debemos combinar con revisión manual

4. HERRAMIENTAS, NADA ES PERFECTO

PROS CONTRAS

Escalan Falsos Positivos

Bugs fáciles rápidamente No detecta fallos de diseño, etc.

Podemos añadir nuevos fallos Tecnología avanza rápido

4. COMPILAR O NO COMPILAR, ESA ES LA CUESTIÓN!

GREP

Análisis Estático, sin compilar

Manual

NO GREP

Análisis Estático, compilando

Manual

SI

4. SOURCE CODE NAVIGATORS I

• Nos ayudan a entender el código

– Cross-referencing

– Búsqueda de texto

– Entienden diferentes lenguajes (C/C++, Java, etc.)

– Resaltado de sintaxis o coloreado de sintaxis

– Visualización de código

– Scripting

4. SOURCE CODE NAVIGATORS II

• Gratis – Source Navigator NG

http://sourcenav.sourceforge.net/

– LXR Cross Referencer http://sourceforge.net/projects/lxr/

– Cscope http://cscope.sourceforge.net/

• Comerciales – Code Surfer

http://www.grammatech.com/research/technologies/codesurfer

– Understand https://scitools.com/

– Source Insight http://www.sourceinsight.com/

3. DEMO 7: SOURCE CODE NAVIGATOR NG

3. DEMO 8: UNDERSTANDING

4. JOERN

• Herramienta para análisis de código C/C++

• No necesita compilar el código

• El código se guarda en una base de datos y luego se puede realizar llamadas (queries) para buscar fallos – Sintaxis: el aspecto del código

– Control de flujo: el orden de ejecución

– Flujo de datos: cómo fluyen los datos en el programa

• http://www.mlsec.org/joern/

• http://mlsec.org/joern/docs/2014-inbot.pdf

4. 18 0DAY EN EL KERNEL DE LINUX (¡SOLUCIONADOS!)

4. ARQUITECTURA DE JOERN

4. VULNEX - TINTORERA

• “Put source code into context”

• Objetivo: obtener una sensación del código mientras compila

• Inteligencia del código fuente: – Visualizaciones

– Análisis de comentarios

– Identificación del API

– Métricas

– Generación informes

• Código C/C++ es transformado a ficheros JSON, ahora se puede realizar búsquedas y análisis con los datos

4. TINTORERA POR DENTRO

• Dos ficheros

– analyzer.py: Plugin GCC mientras se compila el código, genera los ficheros de

datos JSON

– do_report_tintorera.py: genera el informe utilizando los ficheros de datos JSON

• Compuesto de:

– Código Python

– Ficheros JSON

– HTML / CSS / JavaScript

4. TINTORERA: INSTALACIÓN Y USO

1. Versión GCC 4.7 o superior

2. Instalar gcc-python-plugin (ver doc online)

3. Añadir path: 1. Export LD_LIBRARY_PATH=/gcc-python-plugin/gcc-c-api

4. Añadir línea al Makefile (etiqueta CC=) 1. gcc –fplugin=/gcc-python-plugin/python.so –fplugin-arg-python-

script=/tintorera/analyzer.py

5. Ejecutar make

6. Una vez compilado el proyecto a auditar, ejecutar: 1. Python do_report_tintorera.py –c tinan.cfg

4. TINTORERA: FICHEROS DE CONFIGURACIÓN

• Editar tinan.cfg y cambiar valores según necesidad

• Establecer valores para: – Directorio para guardar análisis

– Activar / desactivar del análisis: • Bloques básicos

• Callgraphs

• Comentarios

• Gimples

• Etc.

– Umbral de Complejidad Código (Cyclomatic Complexity)

4. TINTORERA: FICHEROS DE DATOS

• Directorio: /data

• Fichero: tinto_api.json

• Este fichero en formato JSON define las APIs

4. TRANSFORMACIÓN DEL CÓDIGO

CÓDIGO FUENTE

INFORME HTML

FICHEROS JSON

4. FICHEROS DATOS JSON

• 3 ficheros:

– tintorera_bb_file.json: Bloques básicos

– tintorera_meta_info.json: información general, tamaño ficheros y código y comentarios fuera de funciones

– tintorera_temp_file.json: información de funciones

4. TINTORERA_BB_FILE.JSON

4. TINTORERA_META_FILE.JSON

4. TINTORERA_TEMP_FILE.JSON

4. TINTORERA: MÉTRICAS CÓDIGO FUENTE

• Métricas:

1. Número de:

1. Líneas

2. Código

3. Líneas en blanco

4. Comentarios

5. Dos puntos y Punto y coma

2. Media longitud líneas

3. Línea mínima

4. Línea máxima

5. Total de bloques básicos

6. Total de Complejidad de Código

7. Media de Complejidad de Código

4. ANÁLISIS DE COMENTARIOS EN CÓDIGO FUENTE

3. DEMO 9: TINTORERA

4. ANÁLISIS ESTÁTICO DE CÓDIGO

• VisualCodeGrepper (C/C++, C#, VB, PHP, Java y PL/SQL) http://sourceforge.net/projects/visualcodegrepp/

• YASCA (agregador: Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL, .NET) http://www.scovetta.com/yasca.html

• OWASP LAPSE+ (Java) https://code.google.com/p/lapse-plus/

• RIPS (PHP) http://rips-scanner.sourceforge.net/

• CAT.NET (ahora integrado en FxCop, .NET) http://www.microsoft.com/en-us/download/details.aspx?id=19968

• Visual Studio /analyze (C / C++) http://msdn.microsoft.com/en-us/library/ms173498.aspx

• Brakeman (Ruby on Rails)

http://brakemanscanner.org/

• DjangoSCA (Django / Python) https://bitbucket.org/jsthyer/djangosca

5. SER EFICAZ

• Equipo multidisciplinar

• Combinar técnicas de auditoría

• Buscar vulnerabilidades desde diferentes ángulos

• Concentrarse intensamente durante tiempos limitados

• Objetivo: encontrar vulnerabilidades

5. CONSEJOS PARA EL AUDITOR

• ¿¿Saber programar??

• Escribe algún software, y no hablamos de un script Python de 50 líneas…

• Aprende: – Web: AJAX, HTML5, librerías populares (Bootstrap, jQuery etc.), AngularJS,

etc.

– Móviles: Android (Java), iOS (Objective-C / Swift), Windows Phone (.NET)

– Herramientas de desarrollo: IDE, repositorios, bug tracking, etc.

• ¡Audita código con el que estés familiarizado!

5. CONSEJOS PARA EL CLIENTE

• No esperes al final para auditar el código, recomendado a partir del 80% completado en fase de desarrollo (SDLC)

• ¡Si el código compila, mejor!

• Por favor, un entorno de pruebas (¡¡hola, virtualización!!)

• Las personas de contacto tienen que estar disponible

• Recuerda: el auditor está para ayudar

5. LIBROS RECOMENDADOS

• The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software http://www.amazon.es/Security-Development-Lifecycle-Developing-Demonstrably/dp/B00M0QV1AK/ref=sr_1_24?ie=UTF8&qid=1417599769&sr=8-24&keywords=microsoft+secure

• Threat Modeling http://www.amazon.es/Threat-Modeling-Adam-Shostack/dp/1118809998/ref=sr_1_1?ie=UTF8&qid=1417599822&sr=8-1&keywords=threat+modeling

• 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them http://www.amazon.es/Deadly-Sins-Software-Security-Programming/dp/0071626751/ref=sr_1_sc_1?ie=UTF8&qid=1417599936&sr=8-1-spell&keywords=24+dealy+sins

• The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities http://www.amazon.es/Art-Software-Security-Assessment-Vulnerabilities-ebook/dp/B004XVIWU2/ref=sr_1_1?ie=UTF8&qid=1417600025&sr=8-1&keywords=art+of+software+security

• Secure Programming with Static Analysis: Getting Software Security Right with Static Analysis http://www.amazon.es/Secure-Programming-Static-Analysis-Software-ebook/dp/B004YJ35E6/ref=sr_1_11?ie=UTF8&qid=1417609119&sr=8-11&keywords=static+analysis

5. Q&A

• ¡Gracias!

• ¡Cervezas y copas son bienvenidas!

• @simonroses • @vulnexsl | @BinSecSweeper

• www.vulnex.com • www.simonroses.com