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.