HCEL 2009

[Horst H. von Brand]

Daniel Alex Inostroza Gonzalez <dinostro en alumnos.inf.utfsm.cl> wrote:
> Horst H. von Brand wrote:
> > Como he dicho en multiples oportunidades, andarse colando en sistemas
> > ajenos, creando gusanos y troyanos, etc _nada_ tiene que ver con seguridad,
> > son habilidades y enfoques completamente diferentes. Saber mucho de una de
> > ellas pocazo aporta en la otra.

> En realidad, con lo poco y nada que me he metido en picar sistemas, he
> aprendido mucho sobre la seguridad minima que debiera tener un
> sistema, asi que no es tan pocazo el aporte.

Con lo /nada/ que me he metido en el tema hemos mantenido los sistemas del
DI seguros por una corrida de an~os... Claro, /cierto/ traslapo hay, pero
es mucho menos de lo que los legos creen. Manejar la tijera diestramente no
te hace buen jardinero...

> > Notese que organizar una cosa de estas tiene posibilidades serias de
> > problemas legales, y definitivamente de dejar a la comunidad Linux (de
> > nuevo, despues de un trabajo de an~os de crear una imagen seria!) como "una
> > tropa de nin~itos malcriados, aficionados al vandalismo". De ninguna forma
> > quiero verme asociado con esta clase de actividades.

> Aqui el profe tiene razon. Por mas que queramos intentar decir/mostrar
> una imagen, siempre hay pelagatos que ven otras cosas (y para peor,
> siempre buscan lo malo).

> > Si son buenas opciones: Juntar a la gente a desarrollar, reparar
> > pifias,
> > ver como reproducir problemas, cerrar/aportar a tickets en bugzilla, ...
> > (/eso/ es hacking!). Incluso organizar auditoria de codigo de alguna cosa,
> > buscando pifias de seguridad, con eso la gente aprende cosas utiles.
> > Requiere algun lider de un proyecto, y recopilar algunos problemas a
> > resolver, proyectos chicos a enfrentar, ...  /Esto/ es un aporte.

> Yo creo que el enfoque es mostrar los problemas de seguridad mas
> comunes y ya resueltos, como para que la comunidad los conozca y tenga
> en consideracion al momento de construir sistemas.

Lectura obligatoria: <http://www.dwheeler.com/secure-programs>,
<http://www.cl.cam.ac.uk/~rja14/book.html>, para gente interesada en
criptografia <http://www.cs.auckland.ac.nz/~pgut001> y
<http://www.cl.cam.ac.uk/~mgk25> (las ultimas dos son paginas de personas
que _saben_ del tema, y tienen mucho material interesante oculto por
alli). 

Si, el libro lo lei de punta a punta (es incluso divertido), luego lo
compre en papel (lo vale!). En ninguna parte esta biblia de seguridad de
sistemas discute como craquear nada... si discute (en bastante detalle)
algunos problemas de seguridad pasados, pero como ejemplo de que/como/por
que sale mal la cosa, y por tanto que hay que evitar. Los problemas de
seguridad "hot" de hoy dia los resuelve el parche/Service Pack/... de la
proxima semana, y el nuevo conjunto de aplicaciones de moda traen
vulnerabilidades nuevas (y hacen que las antiguas sean menos relevantes,
porque las aplicaciones ya no son tan importantes/criticas), los conceptos
de base de que hacer para que el sistema (red, computadores, y lejos mas
que nada gente) funcione en forma segura no son tan efimeros.

El tema es la diferencia entre saber planificar un jardin, con su riego,
abono, senderos para visitantes, orden entre las plantas y su
estacionalidad, aspecto visual, ... y conocer la (mejor?) manera de
arrancar un arbusto.

>                                                    Yo creo que es un
> gran aporte. Ahora, quizas si se replantea este concurso, combinado
> con (o inserto de) lo que dice el profe, podria no verse como la tropa
> de nin~itos malcriados.

Por eso digo: Tirenles un (micro)cursito de programacion segura (o diganles
que se preparen de antemano con el HOWTO de mas arriba), sueltenlos sobre
un trozo de codigo o un programa, y quien encuentre mas problemas de
seguridad (potenciales) en un periodo X, gana. Premio especial para quien
muestre el uso mas creativo (replicable!) de herramientas para encontrar
problemas. Para hacerlo mas equitativo, puede separarse por lenguaje, nivel
de experticia programando, ... Solo hacen falta jueces que revisen las
potenciales pifias para ver si son "reales" (no significa "explotables",
significa solo que potencialmente podrian abusarse).

Los resultados (pifias encontradas) dan lugar a reportes corriente arriba,
y son un aporte concreto. Aun mejor si van con parches. Queda gente
sensibilisada en el tema, y con habilidades minimas en el area, otro
aporte nada despreciable.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513