domingo, 28 de junio de 2015

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


viernes, 19 de junio de 2015

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]x y vas a encontrar que varios son "el mejor", algo evidentemente imposible.

También supongo, que si nadie "interviene", las recomendaciones deberían convergir 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.