1 Ventajas de tecnologías libres en seguridad informática ● Por Lisandro Lezaeta. ● Duración: 45 min (aprox). ● Dificultad: Novato/Intermedio. ● Temática: Desarrollo libre. orientado a la Seguridad.

2 Índice ● Introducción general a la Seguridad Informática. ● Open source y Closed source. ● Métodos de detección. ● Atacando el error. ● Detección de ataques. ● Reparación de errores. ● Consecuencias... ● Había una vez un villano... ● Conclusiones y preguntas. ● Despedida!

3 Introducción a la Seguridad Informática ● Definición: disciplina orientada a la detección y corrección de fallos que comprometan la seguridad de un sistema o aplicación informática. ● Metodología: análisis, detección, corrección, publicación. ● Villanos y profesionales... ● Full disclosure & Sec. through obscurity.

4 Open y closed source... ● OPEN SOURCE = CODIGO FUENTE ABIERTO Y LIBRE – Libertad para leer, editar, guardar y distribuir el código. ● CLOSED SOURCE = CODIGO CERRADO Y PRIVATIDO – Restricciónes que imposibilitan el conocimiento de ”que sucede”.

5 Métodos de detección de errores ● 0 days (el lado del mal) – O.S = El villano cuenta con el código fuente, lo que facilita el trabajo. – C.S = El villano no cuenta con el código fuente, fuerza bruta, desensamblado, debugging. ● 1 days (”fixeados oficialmente”) – O.S = El villano procede a leer el ”paper” y a descargar el exploit (en full disc) o a realizar un diffeo de código y detectar las modificaciones en segundos. – C.S = Diffeo de binarios para detectar los cambios (en sec t. Obscurity), mayor complejidad para encontrar.

6 Atacando el error ● 0 days – O.S = El villano ataca uno, dos, tres servidores hasta que lo pescan y en días el bug (debería) queda obsoleto. – C.S = El villano ataca uno, diez, cincuenta, cien... y sigue... ● 1 days – O.S = Cualquier usuario puede (y debe) actualizar, solucionando los errores y dejando obsoleto el bug. – C.S = El que puede, actualiza, el que no ”es botnet”.

7 Detección de ataques ● O.S = Es posible llegar hasta el fondo del ataque, detectar exactamente en que variable de qué programa. Esto posibilita arreglar el error y reportarlo con detalles, simplificando la tarea de los desarrolladores del ”soft” vulnerable. ● C.S = Solo es posible saber que determinado programa es vulnerable, sin poder saber con presición (o en algunos casos, dificultandose mucho saber) cual es el fallo.

8 Reparación de errores. ● O.S = El usuario perjudicado, la comunidad, el desarrollador, cualquiera puede realizar la reparación y publicarla. ● C.S = Nadie puede hacer nada. Hay que esperar a un ”FIX” oficial. (A veces meses...)

9 Consecuencias... ● Con todo esto... – Un error crítico en una aplicación de código abierto puede causar mucho daño a determinada cantidad de sistemas. Por suerte, al contar con el código y una comunidad (supuestamente) comprometida, el error debería solucionarse con brevedad. – Un error en una aplicación de código cerrado puede durar años, puede comprometer cientos de sistemas y aún así no ser reparado núnca (por ejemplo, proyecto abandonado) pues depende exclusivamente del desarrollador.

10 Había una vez un villano... ● Ejemplos prácticos.

11 Conclusiones y preguntas... ● Mis conclusiones: – El O.S es más seguro, más confiable y es la única opción para quien se preocupa por la seguridad. – En el C.S nunca sabemos realmente que sucede ni porqué sucede. – En el C.S no podemos responsabilizarnos por nuestra propia seguridad, depende de la seriedad de los desarrolladores de las utilidades que necesitemos. – En el O.S si algo ocurre, es mi culpa (o la de mis empleados), en el C.S puede ser la culpa de cualquiera.

12 ¿¿¿Preguntas??? ● Por favor....

13 Despedida ● Mail: [email protected][email protected] ● Blog: http://murder.diosdelared.com ● Visiten www.diosdelared.com