Descargar Presentación

Seguridad del Software
Las 10 fallas de diseño más
frecuentes y como evitarlas
Presentada por:
Iván Arce
Programa de Seguridad en TIC
Fundación Dr. Manuel Sadosky
Aclaración:
©
Todos los derechos reservados. No está permitida la
reproducción parcial o total del material de esta sesión, ni
su tratamiento informático, ni la transmisión de ninguna
forma o por cualquier medio, ya sea electrónico, mecánico,
por fotocopia, por registro u otros métodos, sin el permiso
previo y por escrito de los titulares de los derechos. Si bien
este Congreso ha sido concebido para difusión y promoción
en el ámbito de la profesión a nivel internacional,
previamente deberá solicitarse una autorización por escrito
y mediar la debida aprobación para su uso.
Qué es seguridad del software?
La seguridad es un atributo de calidad del software
Seguridad del software es una propiedad emergente de un sistema
de software, resultante de la interacción de personas, procesos y
tecnología a lo largo de todo su ciclo de vida.
El costo de arreglar un bug crece exponencialmente en el tiempo:
{Requerimientos, diseño, implementación, testing, despliegue, mantenimiento}
Qué NO es seguridad del software?
Seguridad del software no es:
• Un conjunto de características (features) del software
Usar SSL, autenticar con usuario y clave, permisos de acceso
• Usar un dispositivo de red o un sofware de seguridad
Firewall, firewall de aplicación web, antivirus, etc.
• Una reglamentación de cumplimiento legal o una regulación
PCI DSS, SOX, BCRA “A” 5374, BCRA “A” 4609, etc.
• Una certificación de calidad o nivel de madurez de procesos
ISO 9001, CMM/CMMI, SMMM, ISO 27001, ITIL, CoBIT, etc.
El estado de la seguridad del software
Fuente: National Vulnerability Database, NIST, EEUU (2015). https://nvd.nist.gov/
Cuál es el alcance del problema?
o Las estadísticas mostradas son:
• Incompletas, sesgadas, desfasadas en el tiempo.
• Sobre problemas de implementación (bugs)
• Publicados por fabricantes o terceros (investigadores,
industria, etc.)
• Catalogados con un ID único (CVE) por Mitre.org
• Solo aplicables a software comercial ya desplegado
o Se estima que los bugs solo representan el 50% de los problemas
de seguridad del software. El otro 50% corresponde a fallas de
diseño (flaws)
o La cantidad de bugs es al menos 1 o 2 órdenes de magnitud (10x
– 100x) mayor si consideramos software a medida o desarrollado
para uso interno.
Cómo atacamos el problema?
Proyecto “METODOLOGÍAS PARA EVALUAR LA
MADUREZ DE LA SEGURIDAD EN EL PROCESO DE
DESARROLLO DE SOFTWARE”
Realizado en forma conjunta por:
UTN Facultad Regional Santa Fe
Grupo I+D GISTIC
Fundación Dr. Manuel Sadosky
Programa STIC
2014-2015: Fase II del proyecto
Hay dos tipos de Defecto de Software
Errores de implementación (bugs)
•
•
•
•
•
•
Problemas a nivel codificación
Identificables vía testing
Puede permanecer latentes y manifestarse en tiempo de ejecución
Testing unitario, regresión, cobertura
Automatización de pruebas de seguridad, fuzzing
Se arreglan con “parches”
Fallas De Diseño
•
•
•
•
•
Problemas mucho mas profundo en la etapa de concepción
Equivocación u omisión en etapas de diseño, definición de arquitectura
No se puede “testear” lo que no existe
Su manifestación tiene consecuencia catastróficas
Se arreglan con “re-diseño”
Error de implementación (bug)
“Understanding the Apple goto fail vulnerability”, Amit Sethi, Cigital, Feb 25. 2014
http://www.cigital.com/justice-league-blog/2014/02/25/understanding-apple-goto-fail-vulnerability-2/
Falla de diseño (flaw)
Centro para el Diseño Seguro de IEEE
• IEEE Computer Society Cybersecurity
Initiative
• Lanzado en 2014
• 13 miembros fundadores
• Lista de las 10 fallas de diseño mas
frecuentes
• … y como evitarlas
http://cybersecurity.ieee.org/center-for-secure-design/
GANAR U OTORGAR CONFIANZA,
PERO NUNCA DARLA POR SENTADA
UTILIZAR UN MECANISMO DE AUTENTICACION
QUE NO PUEDA SER ELUDIDO NI ALTERADO
AUTORIZAR DESPUES DE AUTENTICAR
“Behind the Scenes at a Nuclear Alert Facility”, Joe Papallardo, Popular Mechanics, 2010
http://www.popularmechanics.com/military/weapons/a6169/behind-the-scenes-at-a-nuclear-alert-facility/
SEPARAR ESTRICTAMENTE DATOS
E INSTRUCCIONES DE CONTROL
“SQL Injection in the wild”, Gunter Ollman, IOActive, 2013
http://blog.ioactive.com/2013/03/sql-injection-in-wild.html
VALIDAR TODOS LOS DATOS
EXPLICITAMENTE
“Encuentran un ’puto el que lee’ en el contrato de Lamela a Roma”, Clarin, Deportes, 2011
http://www.clarin.com/deportes/Encuentran-puto-contrato-Lamela-Roma_0_514748732.html
UTILIZAR CRIPTOGRAFIA
CORRECTAMENTE
“The ECB Penguin”, Filippo Valsorda, Nov. 2013
https://filippo.io/the-ecb-penguin/
IDENTIFICAR DATOS SENSIBLES,
Y COMO SE LOS DEBERIA GESTIONAR
CONSIDERAR SIEMPRE A LOS USUARIOS
LA INTEGRACION DE COMPONENTES
CAMBIA LA SUPERFICIE DE ATAQUE
CONSIDERAR CAMBIOS FUTUROS EN
OBJETOS Y ACTORES
Gracias por asistir a esta sesión…
Para mayor información:
Iván Arce
Programa STIC, Fundación Sadosky
[email protected]
Para descargar esta presentación visite
www.segurinfo.org
Los invitamos a sumarse al grupo “Segurinfo” en