Seguridad de Software: Una Introducción

● Enero 2011: Sony demanda a modders por hacer jailbreaking e ingeniería reversa de la PS3.

● Abril 2011: PSN recibe ataques DDOS y SQL Injection los cuales roban información de tarjetas de crédito de sus usuarios. Sony cierra PSN por 24 días.

● Mayo 2011: Aparece un sitio de phishing en un servidor Sony

● Junio 2011: Se filtran bases de datos y cupones de Sony Rusia, Sony Portugal, Sony Francia y Sony Europa.

USD 24x10⁹Costo de los ataques para Sony:

Costo de prevención:

< USD 10000Fuente: Veracode, "Sony PSN Breach Infographic"

Seguridad de Software: Una IntroducciónCristián RojasConsultor en Seguridad de Software – Investigador Asistente CLCERT Universidad de Chile

Ciclo deCharlasInformáticas[cc ]i

Seguridad de Software: Una Introducción

Primera parte:

¿Es importante la seguridad?


● 6 mitos sobre seguridad● ¿Por qué los buenos desarrolladores

escribimos mal código? 3 factores cruciales

● La trinidad de los problemas● ¿No? Importancia de la seguridad


Mito 1: Seguridad 100%


Mito 2: Seguridad "Next"No, si mi framework trae seguridad integrada. No

tengo de qué preocuparme.


Mito 3: "Nunca nos han atacado"

● Igual que los avisos de inversiones:"Rentabilidad pasada no asegura rentabilidad futura"

● ¿Y para qué construir un paso de cebra frente al colegio si nunca han atropellado a nadie ahí? (¿O es muy tonto lo que estoy diciendo?)

● La verdad es que no nos han atacado... aún.


Mito 3: "Nunca nos han atacado"

● "Pero cómo podría alguien atacarnos si somos una empresa chica/PYME/startup"– Generalmente no tienen medidas de seguridad

implementadas

– Faltan especialistas que desarrollen políticas de seguridad

– 83% de los ataques son oportunistas, más que orientadosBiztech: "Hackers Have Their Eye On Small Business"


Mito 4: "Tenemos un firewall"


Mito 5: Los ataques sólo vienen de afuera

● La incidencia de ataques desde dentro de la organización bordea el 20%

● Y pueden no necesariamente ser ataques

● Los usuarios son el peor enemigo de una aplicación


Mito 5: Los ataques sólo vienen de afuera

● Los usuarios son más peligrosos que los mismos crackers:– Curiosos

– Torpes

– Crédulos

– Malévolos

– Petulantes


Mito 6: Sólo para "juáquers"

Me han contado que los mejores crackers del mundo hacen esta pega

en 60 minutos...Lamentablemente yo necesito a

alguien que la haga en 60 segundos.

"Swordfish", Warner Bros, 2001.


¿Por qué los buenos desarrolladores escribimos mal código?


Factores técnicos

● “El todo es más que la suma de sus partes” (NOT!)

● Hay fallas de seguridad que surgen espontáneamente ¿Por qué?


Factores psicológicos

● Programar es una actividad difícil y frustrante● Nosotros descansamos en la abstracción... los

chicos malos se fijan en los detalles● Nunca debemos confiar ciegamente en el código

de otro (ahora... anda a que alguien llegue a desconfiar del de uno)


Desarrolladores escriben códigowhile(true) { Especialista en seguridad dice "UR DOIN IT WRONG!" Desarrolladores hacen cambios}


Factores del mundo real

● La fuente de nuestro código fuente● El desarrollo de software es un proceso

democrático● La presión de producir, producir, producir

– ¡¡¡Margen, margen, margen!!! Y calidad, ¿cuándo?


Factores del mundo real

● “¿Cuán seguro?” “Lo suficiente”– “¿Cuándo dejarán de vendernos esta porquería?”

“Cuando Ustedes dejen de comprarla”

– Si se emplea tiempo en chequear posibles fallas de seguridad, habrá menos ingenieros dedicados a añadir nuevas características

– Muchas compañías restan importancia a incidentes

● Se nos enseña a desarrollar, pero no en forma segura


InterconectividadExtensibilidadComplejidad

(La Trinidad de los problemas)


¿No? importancia de la seguridad● ROI (margen)● Ejercicio: ¿Cotizarías

voluntariamente en una Isapre?

● ¿Es bacán la seguridad?


Segunda parte:

¿Cómo asegurar nuestro software?


Educación

● ¿Sabemos qué vulnerabilidades hay y cómo mitigarlas?– Tutoriales en línea

(OWASP Top 10, CWE/Sans Top 25...)

– Libros


Educación

● Aplicaciones débiles a propósito– NOWASP (Mutillidae)

– Google Gruyére

– OWASP WebGoat


Análisis de seguridad

● Minimizar la superficie de ataque:

1) ¿Esa característica es realmente importante?

2) ¿Quien necesita esa funcionalidad y desde dónde?

3) Reducir privilegios

Acceso remoto

Acceso local

Acceso restringido

Acceso anónimo

Acceso sólo para

admin

Acceso para usuarios

Mayor s

uperficie de ataque


Análisis de seguridad

● Threat Modeling: Herramienta que busca obtener una visión general del sistema en términos de seguridad:

1) Determinar dependencias y supuestos

2) Modelar el sistema

3) Determinar las amenazas

4) Calcular riesgos

5) Mitigar


Utilizar herramientas automatizadas

● Análisis Interno– Analizadores estáticos

● Análisis externo (pentesting)– Fuzzers



● Limitaciones– Las herramientas automatizadas tienen las mismas

limitaciones que los antivirus

– Por lo mismo, utilizarlas como parte de un programa de desarrollo de software seguro

● Precaución con el análisis externo– Utilizar sandboxing

– NUNCA hacer las pruebas sobre un sitio en producción.



● Analizadores estáticos:– Findbugs, PMD, CodePro Analytix (Java)

– RATS, Flawfinder (C/C++/PHP/Python)

– FXCop (.NET)

– Brakeman (Rails)



● Fuzzers:– Websecurify

– W3AF

– Skipfish

● Sandboxes– Chroot

– Virtualizadores: Virtualbox (vagrant), VMWare...


Aplicar buenas prácticas

● Diseño simple● Prepared Statements y permisos para bases de

datos● Validar entradas (contra XSS, inyecciones varias,

usar lista blanca)● Poner atención a las configuraciones por defecto.

Suelen ser inseguras.


Aplicar buenas prácticas

● Completa mediación: Revisar privilegios siempre antes de hacer una operación crítica

● Atentos a los privilegios (privilegio mínimo, separación de privilegios)

● Compartimentalizar la aplicación● Aceptabilidad psicológica: No hacer el sistema tan

seguro que termine siendo inusable



Soportar todo el software

● Mucho de nuestro software depende de otro software:– Bibliotecas externas

– Frameworks

– Etc.

● Atentos a avisos de seguridad de software externo● Si las vulnerabilidades para ese software no se corrigen:

– Corregirlo nosotros mismos

– Buscar alternativas


Desarrollar un "Security Response"

● El software nunca quedará perfecto, por lo tanto es bueno armar un plan de respuesta a incidentes

● Fomentar la divulgación: ¿Abierta o responsable?● Adelantarse: Encontrar las vulnerabilidades antes

que un investigador/cracker/ocioso lo haga● Al lanzar un parche, no preocuparnos sólo de

corregir, sino también de evitar regresiones


Demo(Un intento por hacer bacán la seguridad)

Fuente: https://github.com/injcristianrojas/swsec-intro


Links interesantes

● Veracode, "Sony PSN Breach Infographic"http://www.veracode.com/resources/sony-psn-infographic

● "Hackers Have Their Eye On Small Business"http://www.biztechmagazine.com/article/2012/05/hackers-have-their-eye-small-business-infographic

● Veracode: "Stay Cool, Nobody is Calling Your Baby Ugly"http://www.veracode.com/blog/2011/10/stay-cool-nobody-is-calling-your-baby-ugly/

● Aplicación de demostración JEE/Mavenhttps://github.com/injcristianrojas/swsec-intro


Links revelantes

● OWASP Top 10https://www.owasp.org/index.php/Top_10

● CWE/SANS Top 25 Most Dangerous Software Errorshttp://www.sans.org/top25-software-errors/

● OWASP: "Threat Risk Modeling"https://www.owasp.org/index.php/Threat_Risk_Modeling

● 42+ best practices for secure mobile development in iOS and Androidhttps://viaforensics.com/resources/reports/best-practices-ios-android-secure-mobile-development/

● Microsoft: "SDL Process: Design"http://www.microsoft.com/security/sdl/discover/design.aspx


Blbliografía

● McGraw: "Software Security: Building Security In"● Viega, McGraw: "Building Secure Software"● Howard, LeBlanc, Viega: "24 Sins of Software

Security"● Howard, Lipner: "The Security Development

Lifecycle"● Graff, Van Wyk: "Secure Coding: Principles &

Practices"


Muchas gracias por su atención.

¿Preguntas? ¿Comentarios?

Contacto:[email protected]

Technology

Seguridad de Software: Una Introducción