Resumen de lo que pasó
En un Viernes Ñoño[1], al iniciar el hangout ví que estaba en pantalla la parte de las crecenciales del machete de cómo iniciar el hangout y el streaming. Como no estaba seguro de no haberlas difundido, las cambié, afectando a un curso remoto que tuvo una interrupción hasta haber obtenido las nuevas credenciales.
No tengo ninguna, ninguna duda de que soy un salame, pero haré un análisis y pueden haber frases, ideas o interpretaciones que pueden parecer justificaciones pero no lo son, son descripciones que intentan ser objetivas.
El objetivo es comprender lo que pasó, las causas y ver que no ocurra otra vez.
Detalles de lo que pasó
Era la primera vez que hacía un hangout de este tipo, agendado y con streaming. Las otras veces se encargó otra persona y no ví nada del proceso.
Recibí un instructivo muy claro, que seguí al pié de la letra horas antes. En una parte decía que se abriría un hangout, pero parece que eso vale para los que son "ahora", no los agendados.
Llegué más o menos en hora, no tan justo como otras veces.
Inicié el hangout cerca de la hora prevista.
Comencé a revisar que las ventanas que quería estuvieran en los lugares apropiados.
Ví que la del instructivo estaba a la vista con las credenciales a la vista (falla 1), la cerré inmediatamente e intenté sopesar las implicancias.
No estaba seguro de haber compartido aún nada, tenía el juicio un poco nublado (falla 2).
Inicié el escritorio compartido.
Al terminar la charla (falla 3), quise revisar el video, pero aparentemente le lleva un tiempo el render, no lo podía ver.
Ante la duda, decidí tomar un solución drástica por si había mostrado de algún modo algo, cambié las credenciales (falla 4) y avisé (fallas 5 y 6).
Intenté modificarlas en el documento pero tenía acceso de sólo lectura.
En un curso se cortó el hangup por el cambio, se regeneró una clave y se retomó el curso.
Veamos el detalle de las fallas que he podido identificar:
Falla 1: lo que nos trae acá, la posibilidad de haber divulgado las credenciales.
Falla 2: En este momento estaba haciendo tres cosas simultáneas: configurar el entorno remoto, iniciar la charla y lidiar con el error. Esta es la base de los ataques de Ingeniería Social, crear una distracción para obtener algo de nosotros. En este caso fue un ataque autoinflinjido.
Falla 3: Todo lo que hice, debí hacerlo en el momento mismo de la falla 1, aunque retrospectivamente la exposición hubiera sido similar debido a la demora del render.
Falla 4: Al cuidar la confidencialidad de la clave para resguardar la integridad del canal, afecté la disponibilidad.
Falla 5: No avisé con insistencia, esperando un acuse de recibo, lo que hubiera alertado de la situación mucho más rápido. Usé la misma conversación en lugar de modificar el asunto y marcarlo como "[urgente]".
Falla 6: Cambié la clave en lugar de consultar. Eso no está del todo mal, pero no es consistente con que cambié la clave al finalizar, como que tanto apuro no había.
Valores
Todos nos preguntamos para qué querría alguien las claves de esto.
Vandalismo personal y gratuito
Si alguno de los organizadores o el proyecto mismo le cae mal a alguien, esta persona puede utilizar tanto el incidente como las credenciales mismas para intentar desacreditar.
Despues hay gente que lo hace por que sí.
Intereses contrapuestos
Si alguien se ve económicamente afectado por el proyecto CIAA, tanto el daño como la mala prensa ayudan a desacreditarlo.
Plataforma de ataque
Teniendo acceso se puede generar una campaña de desinformación o spam tanto hacia la comunidad como hacia afuera.
Imaginate como se me pusieron los pelos cuando ví la cadena pocas horas despues preguntando a dónde había ido a parar un repositorio. Por suerte vi la respuesta a la vez, aunque habría que terminar de investigar que realmente no haya relación. (Me han confirmado que no hubo relación)
Ordenamiento
De darle un orden de importancia a las fallas, sería este, pero no está escrito en piedra:
Falla 3: demora en reacción.
Falla 4: denegación de servicio.
Falla 1: divulgación de información sensible.
Fallas 0 y 2: son las de proceso, no tener previsto esto y exponerse a situaciones innecesariamente complejas, colaboran con la 1.
Fallas 5 y 6: comunicación defectuosa,colaboraron con la 4.
Mejorías
Estas son algunas medidas que se me ocurren:Agregar al manual un ámbito de difusión
En general pero más cuando hay información sensible, es mejor explicitar cual es el público. Al menos para que quien recibe el documento piense "uh, como en las películas" y ya tenga aun sin pensarlo una actitud distinta.
Advertencia con respecto a la publicación accidental de cualquier tipo y como proceder en caso de falla
Esto es por dos motivos: en parte para prevenir, si me estás explicando como proceder si algo sale mal le estás dando protagonismo a la falla y puedo estar más atento. Pero fundamentalmente es que al estar en el momento de la falla, es mejor ya contar con información pues es difícil pensar bajo presión.
Separar los canales
Si todos los documentos que requieren la inclusión de credenciales tienen una parte común de credenciales, se vuelve rutina y se pierde. Además empieza el problema de la sincronización cuando distintos documentos refieren a procesos con la misma cuenta.La idea es entonces tener en un documento o canal aparte las credenciales, con permisos más estrictos y el foco puesto en que son credenciales.
Pero todo esto tiene un costo, que debe ser menor a lo que estamos protegiendo.
Pero, no ha pasado antes ni hay perspectivas de que vuelva a ocurrir
Aunque no hay un adversario de por medio como en [2], está presente el mismo ingrediente: alguien que tiene que hacer varias cosas a la vez. Si no se puede evitar, hay que tener "defensas" proactivas, no reactivas que fue lo que se activó en este caso.
Reflexiones
Con respecto a mi subjetividad, es evidente la falla por estar en una situación para mi compleja y nueva. Estos mismos motivos son los que causan otras fallas de seguridad en vivo y accidentes.Diferencio "en vivo" como las que se producen durante un incidente como puede ser una intrusión o ataque de denegación de servicio en contraste con las de diseño e implementación, pese a que aunque no sea en el instante, durante dias, semanas o meses la presión de sacar un producto puede producir resultados adversos para la seguridad.
Pude haber aprovechado que habían presentes dos compañeros de trabajo que me pudieron haber supervisado, quizás detectado y seguramente ayudado a evaluar, pero tuve la presión auto impuesta "de negocio" de que el hangout ya estaba en marcha y me resultaba muy interfiriente cerrarlo y crear uno nuevo, cosa que pensé, pero a la vez tambien pensaba que por más que lo borrara ya se había difundido, todo me llevaba a la solución standard ante la sospecha de compromiso de credenciales:
Regenerarlas
¿Hubo una falla 0?
La pregunta es si el incidente se inició en el momento con la falla 1 o antes, al no haber tomado recuados para que esto no ocurriera. Si en el documento hubiera habido una advertencia clara para que esto no ocurriera, las probabilidades hubieran bajado.
Es verdad que fué una situación medio inesperada el tener que armar el entorno, de haberlo podido ver o practicar antes, seguramente me hubiera dado cuenta de "uh, fijate que hay que cerrar esta ventana antes de iniciar", lo sé por que me paso todo el día haciendo eso.
De ahora en más, si se aplican las mejorías propuestas y se difunde entre el ámbito de difusión, cualquier evento futuro sin duda se iniciará con la falla 1.
Escenario ideal
En mi opinión, sería este:Supongamos que se genera la divulgación (Falla 1) pese a estar prevista (Falla 0). Inmediatamente se cambia la clave (Falla 3) y se comunica correctamente a la espera de respuesta (Falla 5), disminuye drásticamente el margen de denegación de servicio (Falla 4).
¿Por qué tenemos de todos modos la Falla 1, la divulgación accidental? Por que shit happens, es muy difícil evitar la Falla 2 (hacer varias cosas a la vez) de modo económico, tendría que estar una persona que expone acompañada de una que opera y otra que esté atenta a resolver los errores que puedan surgir. Ah, y además que estas personas no hayan estado trabajando todo el día antes de iniciar estas tareas.
Otros casos
Equivalentes a este:
En los segundos 11 a 13 se vé como el muchacho pega del portapapeles a un campo de texto unas credenciales.
- https://www.youtube.com/watch?v=b3cf6oxqpr0
Más...
- https://www.digit.in/networking/2014-fifa-world-cups-wi-fi-password-revealed-accidentally-23101.html
- http://www.dailymail.co.uk/news/article-5279525/Photo-Hawaii-emergency-agency-shows-password-Post-it.html
- https://www.gq.com/story/sean-spicer-password-tweet
- https://nakedsecurity.sophos.com/2012/11/21/prince-william-photos-password/
- https://www.wsj.com/articles/uniteds-cockpit-door-security-codes-inadvertently-revealed-1494794444?mod=mktw
Ademas existe otro tipos de casos equivalentes pero con una mecánica distinta, como es enviar información sensible sin ofuscar:
- https://www.theguardian.com/technology/2015/jul/15/confidential-personal-data-release-accident-councils-nhs-police-government
- https://thehackernews.com/2017/07/sweden-data-breach.html
- https://productforums.google.com/forum/#!topic/gmail/PuzbZdyifdU
Un poco más profesional, este es un buen resumen
- https://securityintelligence.com/the-role-of-human-error-in-successful-security-attacks/
- https://www.verizonenterprise.com/verizon-insights-lab/dbir/
Opiniones muy personales
Muy personal, salteable.
Volviendo al párrafo inicial de justificaciones vs descripciones, al analizar un problema de este tipo, siempre intendo ponerme en el lugar de cada uno de los actores involucrados y ser lo más estricto posible, pues mi objetivo no es hallar responsabilidades civiles o penales para culpar y castigar, si no para corregir y evitar. Puede parecer entonces que la responsabilidad va recayendo de modo desproporcionado; si se hiciera una lista con los actores y sus porcentajes de responsabilidad, la suma daría muy por encima de 100%, pues al ir rotando la lupa distorsiona el protagonismo.
Lo hago así pues para cada actor su parte es sobre la que tiene posibilidad de actuar y modificar.
Ejemplo: el servicio meteorológico le erra, da un porcentaje de probabilidades de lluvia relativamente bajo y pese a mi impresión, no llevo paraguas y luego llueve. No me sirve de nada culpar al servicio meteorológico, a lo sumo mi confianza en su pronóstico.
Otro ejemplo, real, otro ángulo. El otro día estaba seleccionando ropa y disfraces viejos para descartar de una de las personas a cargo que tengo que estaban tirados por el suelo de la habitación. Levanté el bulto, seleccionamos un par de cosas que se quedaban y el resto se fué, junto a una pantufla muy adorada.
Desde mí, el error fue no revisar bien. Desde la persona afectada, el andar tirando todo por ahi.
Desde afuera, fue mi responsabilidad por no revisar bien. Y así le digo y si no hubiera sido tan adorada la pantufla tambien le hubiera dicho su parte para que lo aproveche, pero a veces hay que medir bien lo que uno hace para no producir más daño que beneficio.
Conclusiones
Los costos de este incidente fueron:
- Sufrimiento para el docente del curso afectado.
- Pérdida de su tiempo y sus alumnos.
- Disminución de la confianza operativa de la organización en mi.
- Las muchas horas que me ha llevado pensar y escribir esto.
Las ganancias pueden ser:
- Mejora en el proceso para evitar futuras ocurrencias.
- Que quienes lean esto que no les ocurra algo parecido en otros ámbitos.
[1] https://groups.google.com/forum/?hl=en#!topic/embebidos32/j5M2RzadM3I
[2] http://seguridad-agile.blogspot.com/2012/06/offtopic-robo-stallman.htm
No hay comentarios:
Publicar un comentario