cybercampes 2014 5-7 diciembre madrid · manual estático leer código desensamblar ... • ......
Post on 12-Oct-2018
214 Views
Preview:
TRANSCRIPT
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
top related