AOS BsAs 2015

General

He sobrevivido a un nuevo AOS, cada vez mejor. Mejores resultados, menos stress. Sólo quince minutos de pánico media hora antes mientras caminaba rumbo al lugar.

Aunque al comienzo con el juego de las tribus me dió la impresión de que la demografía no era buena, resultó que sí lo era, había gente que aunque newbie en Seguridad/Agile/Desarrollo no lo era en Desarrollo, así que el evento cumplía con sus expectativas.

El evento fué exitoso desde todo punto de vista, asistió la masa crítica necesaria, todo quedó limpio y ordenado, parece que todos se fueron contentos, gracias a UP[1] tuvimos el lugar, gracias a infobyte[2] se disputaron dos entradas a la Ekoparty 2015[3] y finalmente lo más importante, gracias a SCV[4] y Securetia[5] hubo comida.

Aunque se logró una mayor madurez en términos de respetar el formato, aun no se pudo lidiar con la sensación de "no me quiero perder nada", lo que provocó que se juntaran muchas sesiones, generando una supersesión con casi todos los asistentes y una o dos sesiones muy pequeñas a la par, pese a tener espacio de sobra, como seis aulas. Esto se vió agravado por la tendencia de una persona que tiene a hablar mucho pese a haberse comprometido a no acaparar y no voy a decir quien es, jaja.

Me parece que igual influyó un pequeñisimo pero fundamental error mío, que consistió en no poner en la pizarra explícitamente todos los espacios.

Como resultado, durante la convocatoria y tras la realización se han sumado más de diez nuevos miembros a seguridad-agile. No sé cuantos a agiles-argentina y foro-agiles.

A lo largo de todos estos años ha habido una muy alta rotación de asistentes. Si lograramos que la mitad de los de esta vez vuelvan, sería un eventazo, la pasaríamos bomba, conociendo la mecánica y pudiendo aprovecharla mejor.

Las sesiones

Lamentablemente no tomé nota así que todo fue a parar al humus de mi mente, lo cual no es muy bueno sumado a que han relacionado la degeneración cognitiva con el consumo de azucar. Acá van recuerdos inconexos:

Andrés Riancho de w3af[6] presentó la nueva interfaz REST API que se suma a la web y GUI ya existentes. Además, a pedido dio el core de la explicación de deep web.

Gente de una petrolera nos comentó de sus dificultades para lidiar con BYOD a situaciones extremas como golpes, robo de información y cumplimiento de normativas de hardware muy estrictas. Pensá que al operar el dispositivo no puede generar ningún tipo de chispas, estás rodeado de gases de petroleo. No sé si se llevaron algo, espero nos volvamos a ver.

Se conversó acerca de que habría que mejorar en las carreras universitarias en relación a seguridad. Se mencionó que los recibidos aparte de no tener los conocimientos técnicos tampoco tienen la "picardía" aunque puedan ser bastante turras, como que no lo aplican a los sistemas y si a las personas.

Espero que alguien aporte sus experiencias en algún otro blog para lograr mejor cobertura y otro ángulo.

Personal

Javier me invitó a mostrar la demo de mobile que tengo armada y aunque había llevado el equipamiento, estaba cansado y quería más aprender que mostrar. Cuando quieran nos juntamos a hacerla en alguno de los lugares que tenemos disponibles. O cualquier otra actividad.

Organización

Esto es bastante íntimo, podría estar en una entrada aparte. Pese a que voy a recalcar sobre las críticas, mi balance de la organización es bueno, no veo defectos si no más bien oportunidades de mejorar (salvo lo del meetup, ya verás).

Nos convocamos por las listas [7] y [8] y somos los que están en "organizadores" en [9].

Dos no asistieron, aclarándolo desde el comienzo. A mi no me gusta para nada que los organizadores no asistan, pero no hice problema. Quizás la solución sea tener "organizadores" y "colaboradores" pero, ¿vale la pena? No creo.

Nos faltó algo elemental, el crear un chat de Telegram (somos de seguridad, ¿no?) dos o tres días antes del evento para la coordinación final. No digo mucho antes pues considero que salvo momentos especiales, los chat son más una obstrucción al resto de la vida que una utilidad.

Hay una persona que por usar dos cuentas, una para el hogar y otra para el trabajo que además son de yahoo, entorpeció un poco algunas comunicaciones. Prometo que no usaré más yahoo...

Tuvimos un apoyo institucional record, pero parece que no ha hecho diferencia, la cantidad de asistentes, aunque la más alta, fue apenas superior a los eventos anteriores.

Quizás no es buena época, el año que viene insistiré en que se haga antes.

Quizás debimos haber enviado un mail recordatorio en las listas, pero no sé, me parece que meetup envió uno.

Durante la organización hubo bastante mirarme a mí (en términos metafóricos ya que era por mail) como figura de autoridad. Si el grupo se consolida podremos mejorar ese aspecto. Igual no sé bien que autoridad: la fecha no fué la que quería, se aprobó buscar sponsors y a nadie le importó la atribución de méritos, jaja.

Los sponsors

Durante la organización se trató el tema de los sponsors, con una mayoría a favor y una minoría muy minoritaria en contra, que argumentaba la tendencia de los sponsors a apropiarse del evento y/o molestar con detalles menores para no decir pelotudos. La discusión quedó zanjada con la oportuna intervención de Carlos Peix: "vamos a los sponsors que conocen esto y listo" rematada con la mía "el que quiera sponsors, que se encargue".


De los cuatro sponsors , que fueron muy correctos, tanto en el espacio (UP), como en la comida (SCV y Securetia), como en las entradas a la Ekoparty (infobyte), tres fueron "automáticos". Uno por el espacio y dos por que fueron organizadores. El único al que convocamos fué a infobyte, pese a la vergüenza que tenía por el fracaso de una experiencia anterior, en la cual nadie se interesó por las entradas [10]. No era de seguridad el evento, aclaro.

Hubo un intento más que no prosperó. Igual no sé que le hubiésemos pedido. Uno de los organizadores hubiese necesitado viajar para asistir, pero por su logística familiar no podía.

 Quedamos un poquito en falta con los sponsors pues la lista de asistentes que forma parte del "trato" no tiene la calidad apropiada.

Meetup

Se usó meetup "porque es el camino para los eventos en Buenos Aires".

No estoy de acuerdo en volver a usar el meetup[11] por los siguientes motivos con sus tags:

*) Fue completamente engañoso (misleading es la palabra que mejor representa, pero no hallo nada apropiado en español). NUNCA he participado de la organización o accedido a información de evento alguno al que haya asistido en que hubiera una tasa de asistencia/inscripción tan baja. Si nos manejáramos por esa medida, el evento fué el peor de los AOS, pese a que tuvo la máxima asistencia [logística].

*) En la exportación de inscriptos no figura el mail, lo cual dificulta darle a los sponsors un valor asumido implicitamente en estos eventos (igual no ha habido problema por eso).

*) En la página ahora dice que asistieron 95 personas, lo cual no es real y no creo que nadie de los que no asistieron entre a decir "no fuí". [humo]

*) De las personas que figuran como organizadoras en el meetup, sólo una colaboró con la organización y no pudo asistir. No recuerdo en los seis años que lleva haciéndose, que hayan asistido o manifestado ningún interés, que es su completo derecho. Sin embargo, casi diez personas participaron de la organización, que son las que figuran en la página oficial. [humo,mérito]

"Give credit where credit is due"

Opiniones muy personales

Lo que sigue puede ser un poco confuso, es la serialización textual de un grafo.

No cuestiono en absoluto la falta de interés, asistencia o colaboración de Ágiles Argentina de conjunto. Es una actividad voluntaria.

A mi no me gusta el humo, los resultados inflados ni la apropiación del mérito ajeno, ya sea a propósito, por error, efecto colateral o por limitaciones de una herramienta.

La relación que tenemos en las comunidades Agile y Seguridad Agile no es proveedor/cliente ni empleador/empleado, ni B2B, es de pares profesionales. No veo problemas en que alguien ofrezca sus servicios o productos ni que se reclute u ofrezca fuerza laboral, pero nuestra moneda de cambio es el mérito de haber organizado, de haber asistido, de haber colaborado, tanto a los eventos como a la actividad en los foros. Y no es sólo en el pasado, si no aquí y ahora. Y no sólo en los eventos internacionales, donde la mayor parte de la comunidad queda excluida pues no puede viajar ya sea por tiempo y/o dinero.

Reconozco plenamente el trabajo previo que condujo a la existencia de Agiles Argentina, pero la utilización de meetup "porque es el camino para los eventos en Buenos Aires" con el defecto de atribución de mérito a los fundadores y no a los que actuan aqui y ahora, es desalentador para los nuevos involucrados. Lo digo tanto como "nuevo" en el sentido que no formé parte del nucleo fundador como "viejo" en el sentido de que Agile Open Seguridad es el evento con mayor continuidad [12] a la par de *BsAs si se considera una misma iniciativa, que no lo es.

	2009	2010	2011	2012	2013	2014	2015
BsAs	x	x2
Calidad y Arquitectura BsAs			x
Organizaciones flexibles			x
Software Libre BsAs				x
Educación BsAs				x	x	x
BsAs sin AOS	x	x2	x2	x2	x	x
Seguridad BsAs		x	x	x2	x	x	x
Córdoba	x	x
Tandil	x		x
La Plata	x	x	x
Bahía Blanca	x	x	x
Mar del Plata	x	x	x			x
Rosario		x
Tucumán			x			x
Paraná				x3
Salta						x	x
Miramar						x

La gente con la que se tiene contacto ya sea directo y presencial o via foros sabe cuales son tus méritos (o tu falta de). La gente que te "ve" por tu rastro en Internet no. No pretendo corregir esa situación, pero tampoco quiero colaborar con ella.

Está claro que ante la próxima actividad plantearé esto al grupo organizador y aceptaré lo que se decida, tanto usar el meetup como tomar un camino distinto.

En este marco de la apropiación del mérito planteé al final del evento que deberíamos cambiarle el nombre al grupo, ya que tiene el mismo nombre que este blog, que es mío. Pero me trataron medio de pelotudo, jaja.

Igual seguiré insistiendo.


[1] http://www.palermo.edu/
[2] http://www.infobyte.com.ar/
[3] http://ekoparty.org/
[4] http://www.securetia.com/
[5] http://www.scvsoft.com/
[6] http://w3af.org

[7] https://groups.yahoo.com/neo/groups/agiles-argentina/
[8] https://groups.google.com/forum/#!forum/seguridad-agile
[9] http://www.agiles.org/agile-open-tour/agile-open-bs-as-seguridad-2015
[10] http://seguridad-agile.blogspot.com/2014/09/agiles-argentina-2014.html
[11] http://www.meetup.com/agiles-bsas/events/222685446/

[12] http://www.agiles.org/agile-open-tour

ErlangBA 2015

Un lugar muy agradable el del encuentro, buena tasa de asistencia.

Sólo pude asistir a una y media de las tres charlas. La segunda fué bien técnica de Riak a cargo de Iñaki Garay y la mitad de la tercera, de Federico Repond, comenzó más bien con redes sociales, por pero como no llegué a ver la conclusión, me quedaron algunos conceptos inconexos.

Lo que sí me quedó claro es que hicieron su propia DB llamada Leapsight Semantic Dataspace, apoyándose en los mecanismos de distribución y HA de Riak Core y Erlang/OTP, muy grosos.

Me parece que Federico tiene una concepción parecida a la mía, en mi caso más teórica y en el suyo bien práctica, de que somos dealers, no adictos en el sentido de que no consumimos lo que creamos, o al menos el equivalente que crea otro.

Digo en mi caso teórica, pues este evento es el de un mundo de la alta disponibilidad, centenares de miles de conexiones concurrentes, centenares de nodos. Millones de subscriptos, datos que flotan sin terminar de actualizarse. ¿Conocés el triangulito del PM: Barato, Pronto, Bueno, elegí dos? Acá es CAP:

(eventual) Consistency: en algún momento los datos serán consistentes
Availability: siempre vas a poder acceder
Partition Tolerance: si hay fallas, no te vas a enterar

y sólo podés elegir dos, en teoría. Parece que en la práctica podés elegir un poco más que dos.

Se explicaron conceptos de nosql y distintos tipos, como

KV

KAV

Graph

Document

y otros, te dejo a tí a que hagas las búsquedas apropiadas y voy a comentar sobre los aspectos en los cuales puedo aportar algo.

Sin embargo, si se me permite, dejaré asentado que neo4j.com que implementa Graph  en sus uses cases (menu -> use cases) menciona cosas que me interesan como "Fraud Detection" y las otras, que de mezclarlas sabiamente me llevan a mi principal problema:

Cómo hacer un mapa de los conceptos, personas, tecnologías, herramientas y etc. que uso a diario, por ejemplo imaginario:

            windows              José(interno, mail)

               |                     |

          control usuarios  ---- José autoriza cambios usuarios
          90 días inactivos

               |     +-------- Ana borra usuarios

               |                     |

          script detecta         Ana(interno, mail)-----Area
                                      |
                                notas acerca de Ana
                                 (colaborativa)          

Por que si tengo que leer procedimientos, me muero de aburrimiento, si los encuentro.

Fiel al principio agile de dar algo con valor lo antes posible, dejaré la investigación para despues de esta nota y cuando y sí logro algo, lo compartiré en su entrada correspondiente.

Iñaki comentó que en lugar de modelar a partir de los datos, se debe modelar alrededor de las consultas, lo tendré muy en cuenta.

Así que en lugar del gráfico anterior, debería pensar a partir de:

¿Cuál es mi inventario de scripts?
¿Quienes son las personas colaborativas de un área?

Esto es una mezcla infernal entre jerarquías, red social, flujos de trabajo y TODO.

Logs

Creí escucharle a Iñaki "en el log no hay FK". Justo confluye con el tema mencionado en inforiesgo, que uno de los puntos menos maduros en las organizaciones con respecto a la seguridad es la falta de correlación de logs.

En un sistema complejo, puede ocurrir que la autenticación la haga un componente con su propio log y la operativa posterior otro. Luego, puede ocurrir que exista un token de sesión entre el navegador y el front end, que es lo habitual y lo llamaré "web", pero tambien que entre el front end y los backends hayan otros identificadores de otras sesiones.

Tambien puede ocurrir que en el log no se registre el id de sesión web pues permitiría a un operador o developer ROBAR TODAS LAS SESIONES ACTIVAS. Esto no tiene que ver con lo de FK, pero es suficientemente interesante como para mencionarlo. Ya que estamos, aunque no es el propósito original, suele existir un segundo factor de autenticación como un pin numérico o una tarjeta de coordenadas, que cumple con el efecto secundario de mitigar esto.

Si hay operaciones diferidas agendadas, pueden haber nuevos ids temporarios. Para complicar más hay operaciones que pueden depender del accionar y la autorización de varias personas.

Para detectar ataques y fraudes es vital correlacionar toda esta actividad, tanto como para descubrir alguna falla del proceso como para mediante análisis de comportamiento detectar un robo de credenciales  o autofraude.

Estuve varias veces a punto de preguntar por el tiempo de propagación, siempre pensando en los logs pero no hizo falta por dos comentarios.

*) Cambio de nombre de usuario de un blog: si un usuario cambia su nombre, si hay desnormalización que parece que es muy común en nosql, hay que actualizar en cada entrada su nombre y eso puede llevar... ¡días!

Este escenario en el log no ocurre, es WORM, pero en el insert ocurre esto:

*) Token de sesión y la consistencia eventual: un problema que hallaron es que el usuario se autentica y obtiene su token de sesión, pero como no es instantáneo, inmediatamente se encuentra con que no tiene acceso pues su token aún no es válido. Esto se arregla, como todos los problemas de concurrencia con un sleep(), es este caso dentro de un spin lock.

O sea, que para una investigación durante un ataque puede no ser lo más apropiado y para un IPS sin duda fallaría.

De boca en boca

Federico en su charla mencionó el recurso más efectivo actualmente en las redes sociales.

Es bien sabido que es muy efectiva una recomendación de un producto proveniente de alguien conocido. Un referente mediático viene a ser alguien "conocido" de algún modo y por ello tanto dinerillo amasan los famosos con publicidad (que me corrija alguien que sepa de publicidad, psicología, neurología y todo lo que yo no sé).

Es un conocido asimétrico, ¿no? Hace mucho, cuando trabajaba de otra cosa pasé por una casa donde había un muchacho con alguna disminución mental. Hablaba todo bien, parecía todo ok, pero le hablaba a las personas de la tele como si las conociera. Él si las conocía, no así al revés. No quiero con esta anécdota sugerir que las personas sin disminución de sus facultades mentales tengan algún tipo de tara por "conocer" a personas que no conocen, claro.

Volviendo al gran valor de la recomendación, el problema es que no importa cual es la realidad. Por suerte por lo general la realidad si importa y está mejor expresada por las estadísticas que por una recomendación.

Las recomendaciones sin duda afectarán a las elecciones de las personas y las estadísticas nos diran cuales fueron las buenas elecciones.


Por supuesto que sé que a las estadísticas se las pueden manipular e interpretar siguiendo alguna conveniencia, aún dejando de lado todos los errores metodológicos. Si no, buscá las estadísticas de cualquier herramienta como antivirus, firewall, i[dp]s y vas a encontrar que varios son "el mejor", algo evidentemente imposible.

También supongo, que si nadie "interviene", las recomendaciones deberían converger con las estadísticas.

Comprender esto nos puede llevar a evitar errores (respetando las estadísticas) y sacar provecho de los errores ajenos (de quienes siguen las recomendaciones que no corresponden con las estadísticas).

Comunidad Erlang Argentina

Para qué reinventar malamente la rueda si puedo citar a El Brujo Benavídez:

"Durante el ErlangBA 2015 surgió un comentario que para algunos de los que estamos en esta comunidad Erlanguera hace tiempo resulta medio evidente, pero para quienes recién comienzan no lo es y me parece una buena idea compartirlo:

La comunidad de Erlang en el mundo no es tan grande como otras y más o menos conocernos a todos no es tan difícil. Por eso, formar parte de la comunidad es algo que, tanto para los programadores por sí mismos, como para las empresas que invierten en el desarrollo de sistemas en Erlang es más que recomendado. Si me presionan yo diría que es trascendental.

Y en nuestro caso, formar parte de la comunidad no es nada difícil. Hay varios canales de comunicación:

• el más popular es sin dudas la lista de erlang-questions. Sí, es una lista de emails. Sí, es super-siglo-pasado, ya lo sé. Pero no se asusten, en los días pico de actividad te llegan 20 mails. En los días habituales, te llegan 5. Pero les aseguro que en 1 de esos 5 hay algo interesante y/o útil para aprender o trabajar mejor.
• en Argentina también tenemos nuestra listita, creada por Mariano Guerra.
• En IRC pueden entrar al canal #erlang de freenode
• y claro está... buscar erlang o elixirlang en twitter también sirve :) - no busquen 'elixir' solo porque sólo se van a encontrar a Shakira :P"

Diccionario

WORM (Write Once Read Many): el log debería ser inmutable, se escribe una vez y de ahí en más sólo se lee.

spinlock: es quedarse en un loop preguntando por algo hasta que ocurra. La mejor explicación es la escena de "and then?" de Dude, where is my car?

IPS (Intrusion Prevention System): es un IDS (Intrusion Detection System) que cuando detecta alguna irregularidad toma una acción defensiva como bloquear una cuenta o levantar una regla de firewall.

Inforiesgo 2015

Comparto mis impresiones acerca del evento del 2015-06-10 [1].

La señora de la puerta se dió cuenta que estaba leyendo la lista de asistentes buscando conocidos y tomó las precauciones apropiadas pero no suficientes y llegué a ver que la tasa de asistencia fue de 2/3, muy buena.

La primera presentación, a cargo del polifacético profesional y docente de seguridad informática de la UdeMM[2] y alguna otra institución Pablo Romanos[3] trató sobre SGSI, en particular con iso27k. Por un lado dió la explicación teórica de rigor regada de muy buenos ejemplos y por otro presentó una interesante herramienta, que en sus palabras consiste en hacer lo mismo que venían haciendo en una hoja de cálculo. Pese a la modestia, la herramienta se veía bastante interesante.

Luego, Santiago Cavanna hizo algo muy interesante, que fue adaptar su presentación a ciertas ideas que había tirado Pablo.

Según los datos que mostró, la regulación sirve. O sea, si se pena que hagas las cosas mal, no las hacés tan mal, ¡qué primitivo! Tambien que hay terribles falencias de correlación de eventos, gestión de cuentas de administradores y de servicio, se comparten cuentas privilegiadas. Se calcula que hay un 5% de personal "desleal" que de tener oportunidad ataca a su organización.

Tuvo un par de reflexiones muy interesantes como que en cuatro mil años no ha cambiado el core de la seguridad de la información, con lo que no puedo menos que estar de acuerdo. La otra es algo que he expuesto en algunas capacitaciones internas y paso a explicar en mis palabras, me parece que su concepto es el mismo:

Cuando hablamos de probabilidad de ataque no es lo mismo que probabilidad de un accidente, pues en el primer caso hay una voluntad de por medio. Ponete en el lugar de atacante, que hace un relevamiento y encuentra que cerraste todas las que tienen más de 7 puntos de cvss[4]. Si estaba decidido o motivado, te va a atacar por las de menos puntos que estén abiertas, asi que si tenías una de 1 punto, para vos en realidad se hizo de 10 puntos.

Esto hace que decir: por mis vulnerabilidades tengo un XX% de probabilidades de ser atacado y cuanto más la cierre menos probable es, no tenga tanto sentido como que digas que hay un YY% de que TENGA ÉXITO. Entonces decir "esta vulnerabilidad no la cierro pues es muy difícil de explotar y nadie lo está haciendo" es perfecto para el atacante, que va a ver cuales vulnerabilidades tenés, se va a especializar y te las va a explotar.

Pero que quede claro que estos dos últimos párrafo son míos, no le estoy atribuyendo a Santiago mis palabras, no lo conversé con él, ni siquiera lo conozco. Es algo que venía pensando y que debería agregar a [5].

Otro concepto, que me preocupó es que como que estamos tomando demasiado estrictamente lo de "los datos de argentinos deben estar en Argentina" cuando en realidad parece que es "los datos de argentinos deben estar duplicados en Argentina y se pueden procesar afuera". Cuando alguien le dijo con los bancos no es asi, él dijo, hablen con la señora plin plin plin y verán...

Tras la pausa, hubieron dos presentaciones a las que lamentablemente no les pude sacar mucho más provecho que usar como abono para lo que sigue:

Hace como quince años había una docente en la facultad que leía las presentaciones, algo absolutamente insoportable e inútil. Me dije "no se pueden dar tan mal las clases" y me ofrecí como ayudante ad honorem y esa experiencia y los contactos resultantes han hecho que yo sea quien soy hoy, asi que quizás no está tan mal OTRA PERSONA lea las slides, está bueno el error pero no ser recordado sólo por ello.

Como le dijo Mathis a Bond, "estar muerto no significa que no puedas ser útil" [5].

Como en alguna otra entrada he manifestado [6], pero no recuerdo cual, tiendo a estar más del lado de RTFM que de STFW y del papel que de la pantalla, aunque no dudo en servirme de stackoverflow[7] cuando no necesito comprender o no comprendo pese a RTFM.

Si yo te leo un texo, podés prescindir de mi. De todos modos no podés prescindir de mi, por que lo que te estoy leyendo no te aporta nada que no hubieras tomado por vos mismo. Otra cosa es que haya un texto y alguien que lo desmenuce.

Esto vale tanto cuando aprendo como cuando enseño. Por ejemplo, andaba con ganas de dar capacitación mas formal y por fuera del trabajo y alguien me sugirió que para mejorar "la venta", era conveniente que subiera algún minicurso filmado.

Lo que no me gusta es que yo no aprendo nada cuando alguien ve mi video. No hay pair-programming en solitario.

Si yo leyera una presentación, lo único que aprendería sería a no volverla a leer y vos a no volver, punto.

Pero me fuí por las ramas, todo esto debió haber sido una entrada aparte

En la cuarta presentación se dijo que en términos militares el ciberespacio ha pasado a tomar el lugar protagónico que tenía lo naval. Mmh, si en la misma charla se dijo que se estaban considerando tomar "represalias físicas" en casos de ciberataques, ya me empieza a hacer ruido.

Hubieron datos del tamaño actual y proyectado de los "ciberejércitos", de pocos miles, minúsculos si comparamos con los convencionales. Tienen la ventaja de que no los matan, por ahora.

Se mencionó que hubo una importante denegación de servicio en Georgia antes de la invasión, que hubo sabotaje contra las centrifugadoras iraníe. Es verdad, pero Georgia luego fué invadida FÍSICAMENTE. Irán se atrasó un par de años y siguió en marcha su programa nuclear. Tirar un virus es tan sólo otro recurso como haber tirado unas bombas en un reactor experimental[8].

El problema es que se está confundiendo C³ con Internet. Leé un un poco de C³[9] antes de seguir.

¿Listo? Aburrido, ¿no?

C³ usa Internet, por que en parte Internet es resultado de C³ y por otro Internet es más barato. Fijate, que paradójico que Internet existe para tener comunicaciones reduntantes descentralizadas pero cada que el ancla de un barco arranca una fibra óptica del lecho marino, alguien se queda sin comunicaciones, jeje.

Mencioné esto de C³ no porque la tenga reclara, si no por que me parece algo muy importante para que profundices y reflexiones, prestá atención a C³I, no sé para qué le dicen C⁴I.

Volviendo a los ejemplos, en Siria se ve como la guerra civil tambien transcurre en Internet, pero no en los sitios atacados, si no en la manipulación de las noticias.

Se dice que EEUU perdió la guerra en Vietnam cuando la opinión pública se puso en contra, cuando comenzaron a volver los muertos. Pero alguien tuvo que matar a esos muertos primero.

Soy un completo convencido de que en última instancia, el ciberespacio no es más que una ilusión como el dinero y la ley, que nos rigen en el día a día y que cuando no lo pueden hacer, se respaldan en la violencia. En términos menos poéticos, en última instancia si no te colás para entrar a la cancha es por que la policia te apalea.

Otra vez por las ramas. Volviendo...

Hay algunas otras ideas que no recuerdo quien las expuso o siquiera si fueron expuesta o me surgieron como reflexiones del momento, como que dado que sigue habiendo muchísimo win9x en sistemas de control, los fabricantes que se benefician por hacer los upgrades bien pueden tener una actitud un tanto negligente en relación a su seguridad.

En síntesis, el evento estuvo ok. Pese a la "baja calidad" de dos presentaciones que igual aportaron algo de conocimiento. Ah, y la puntualidad falló, pero he visto peores...

[1] http://www.cpci.org.ar/index.php/pago-de-la-cuota-social/34-novedades/novedades/264-jornadas-info-riesgo-2015-en-udemm-8-edicion
[2] http://www.udemm.edu.ar/

[3] pabloromanos@green40.com
[4] https://nvd.nist.gov/cvss.cfm?calculator&version=2
[5] http://seguridad-agile.blogspot.com/2013/09/dos-dimensiones-extra-en-la-evaluacion.html

[5] http://www.imdb.com/title/tt0381061/quotes?item=qt0433391
[6] http://seguridad-agile.blogspot.com/2012/07/layer-8-csrf-protection.html
[7] http://stackoverflow.com/
[8] http://www.spiegel.de/international/world/the-story-of-operation-orchard-how-israel-destroyed-syria-s-al-kibar-nuclear-reactor-a-658663.html
[9] http://www.globalsecurity.org/military/systems/ground/c3.htm

Las reglas y el ego

Esta entrada es lo que quizás alguien considere "un ensayo". Para mi más bien es una reflexión probablemente intrascendente. Si no la hubiera escrito yo, la consideraría puro humo. Dejo a tu criterio sacarle algún provecho.

Las reglas

Caso uno

El otro día estaba haciendo compras y ocurrió algo muy divertido, edificante y potencialmente peligroso. Para facilitar el seguimiento, voy a abandonar la prosa y pasaré a pseudoalgo.

• Nos pusimos en la cola, con dos o tres personas adelante.
• Se puso un Muchacho atras.
• Se puso una Señora atras.
• Ambos se alejaron un poco para buscar cosas, dejando sus changuitos.
• Las personas delante nuestro avanzaron.
• Le dije a mi acompañante que empujara las cosas del muchacho
• Pero como estaba haciendo otra cosa no lo hizo.
• Ni insistí, pues estaba aprendiendo a hacer esa otra cosa.
• Apareció un Señor que vió que habían changuitos
• y vió aunque no oyó mi diálogo con mi compañia.
• Se puso entre nosotros y el Muchacho
• con mirada de "...si se fueron...".
• El Muchacho volvió.
• El Señor se fue a buscar más cosas.
• Le pregunté al Muchacho si no estaba detrás nuestro.
• Me dijo que si y la Señora tambien
• pero no tenían ganas de pelear por tan poca cosa.
• Las personas delante nuestro avanzaron.
• Les manifesté mi apoyo por si volvía el Señor.
• Avanzaron por delante del changuito del Señor.
• No les presté más atención.
• Llegó mi turno en la caja.
• Apareció el Señor y le dijo al Muchacho que era su lugar.
• Se puso delante del Muchacho.
• Yo le dije que no solo no era así si no que iba detrás de la Señora.
• Se enfureció
• pero dejó pasar al Muchacho
• y se enojó conmigo.
• Intenté explicarle (*)
• pero no entendió así que desistí.

Esta es la animación:

T(0): Charly
T(1): Muchacho - Charly
T(2): Señora - Muchacho - Charly
T(3): changuito - changuito - Charly
T(4): changuito - changuito - Señor - Charly
T(5): Señora - Muchacho - Señor - Charly
T(6): Señora - Muchacho - changuito - Charly
T(7): changuito - Señora - Muchacho -  Charly 
T(8): changuito - N - Señora - Muchacho -  Charly 
T(9): N - Señora - Muchacho - Señor
T(A): N - Señora - Señor - Muchacho

Si llegaste hasta aca, mas vale que la explicación (*) sea buena, ¿no?

Lo que intenté explicarle (*) fue que él asumió la regla de que si nadie empuja el changuito de alguien que está en la cola, el de atras puede saltearlo y que como a él nadie le había empujado el changuito, le habíamos aplicado la regla que él mismo había asumido.

¿Te dás cuenta de como esa persona aplica las reglas que le convienen? En otras palabras, la regla es ganar.

Caso dos

Cayó en mis manos una aplicación interna para hacerle Ethical Hacking y habiendo terminado con las manos ensangrentadas y el corazón palpitante de la aplicación en mis puño apretado, una de las personas que la habían desarrollado me dijo que le parecía raro que tuviera una cierta vulnerabilidad, ya que había puesto las restricciones apropiadas en el código html provisto al navegador. Vi todo rojo pero en lugar de perder la chaveta le dije "venite para acá en persona y traete a alguien más a quien le interese el tema" y les machaqué una horita acerca de por que no se puede confiar en los datos que llegan desde otro lado, que el navegador se considera comprometido y todo lo de client-side y server-side validation.

¿Te dás cuenta de que el programador puso unas reglas y pensó que el atacante las iba a respetar?

Caso tres

En los últimos meses he recibido bastante capacitación forense informática y una de las cosas no informáticas que más me llamó la atención se resume en esta frase:

A las evidencias que respalden a la parte 'A', la parte 'B' intentará por todos los medios invalidar y las que la parte 'B' pueda hallar en favor de 'A', se ignorarán cuidadosamente.

El que me haya parecido tan interesante le indicará a cualquier persona que sabe de derecho o de negocios una muestra de mi ingenuidad, que me llame la atención algo tan obvio.

El ego

Caso uno

Tras una instanciación del juego de piolines, me observaron que probablemente estaba atacando el ego de los participantes por mencionar en repetidas ocasiones que era un juego pensado para escolares de primaria, siendo que esa ocasión no eran escolares. Agradecí el comentario y al reflexionar llegué a la conclusión de que no hubiese cambiado nada, ya que en seguridad informática, igual que en cualquier otra actividad donde haya intereses encontrados, se utiliza al ego del contrincante para obtener ventaja.

En este caso en particular, el ego de los asistentes se podía ver ultrajado, pero eso les podría llegar a impedir aprender de la actividad.

Lo que ocurre, es que la realidad es que no importa que tan clara la tengas, un script kiddie determinado te puede hacer caer. Hasta al mejor entrenado comando o ninja lo puede derrotar cualquier persona común con un arma de fuego.

Caso dos

Conozco a una persona de bastante éxito que además es muy discreta y en alguna ocasión siendo yo su pasajero pude observar un comportamiento muy interesante. Al manejar no se pelea ni enoja con ninguna persona. Si lo encierran, frena, no toca la bocina, no intenta devolver la encerrada, nada, ni un insulto entre dientes, como que está "apagado". Sin embargo, al fallar en tomar una salida de la autopista, que se convierte en pérdida de tiempo, sobre todo tras la segunda falla y peor aún la tercera, sí se enoja y profiere maldiciones. Lo que me llamó la atención es que lo segundo señala que no es una persona completamente calmada y que acepta perder. Viendo ambas actitudes, se ve como mide cuando enojarse y tomar acciones y cuando no. No sé si lo hace concientemente y es imposible preguntarle, pues forma parte de su discreto éxito, va a poner cara de que no entiende y nunca sabré si es verdad o mentira.

Perder unos segundos por una encerrona no hace diferencia, más con las derivaciones inesperadas que pueden traer una pelea con otro conductor. Sin embargo, perder una salida, pueden ser cinco, diez, quince minutos y el costo preventivo es sólo estar un poquito más atento.

Con respecto a no preocuparse por intrascendencias, hay frase muy ilustrativa que es "penny wise and pound foolish" y acá http://thebillfold.com/2012/05/penny-wise-and-pound-foolish/ hay un ejemplo, el primero que encontré.

Parece que la frase está mas relacionada con disonancias cognitivas que con el ego, pero, como este caso parece indicar, tener al ego bajo control ayuda. Tengo entendido sin embargo que algunas de esas disonancias ayudan a tomar decisiones acertadas a corto plazo, pero no soy psicólogo ni neurólogo.

En la ingeniería social se usa mucho la "distracción", que suele estar muy relacionada al ego. Tambien se aprovechan esos mecanismos automáticos de corto plazo para influenciar decisiones que pueden afectar el mediano y largo plazo.

Caso tres

Estaba recibiendo capacitación forense práctica y en uno de esos momentos en que hay que instalar algo y se produce una pausa, uno de los asistentes tomó su celular y llamó a reclamar la reposición de un vidrio de su auto. Le anticipé al docente "fijate que no nos va a entender". Lo pinchamos por estar llamando y dijo "igual no estabamos haciendo nada y necesito el auto", mientras el docente le decía que podría irse afuera a hablar y nada, no entendía y seguía hablando. El docente no lo dijo, pero me miró como diciendo "¿es tarado?".

Lo mejor es que era una capacitación bastante cara, era sólo un día y entiendo que le resultaba interesante.

Agregué este caso pues complementa al ego con una visión absolutamente selfie.

Reflexión tangencial

Hace unos años solía preocuparme por que en el futuro me podría encontrar sin trabajo, pues las nuevas generaciones iban a saber más, que el constante avance me iba a dejar rezagado. La verdad, es que hace poco ni sabía como atender un llamdo en un smartphone y en pocos días aprendí a usar/configurar/programar/romper android. Pienso que los que hemos abrazado la informática desde chicos y hace tiempo, no corremos ningún peligro por ese lado. Con sólo dedicarle un ratito a no salirse de la cresta de la ola, ahí vamos.

Lo que no hay dudas es que quien se ha criado desde la cuna con acceso a las computadoras tiene una inmensa facilidad para usarlas. Lo que no estoy tan seguro es que esa facilidad se extienda a entenderlas.

Hay una frase que le decía a un amigo mio su ex cuando aún no era ex: "Tenés plata para comprarte las cosas y despues no te da la cabeza para usarlas"