Cuando el código fuente de tu aplicación no es seguro

Es de reconocida importancia la necesidad de mantener los sistemas de información actualizados para prevenir la mayoría de ataques cibernéticos. La actualización y la instalación de los últimos parches de software es un tema constante de este blog. Como en el caso de Apple que describí hace unos dias.

Si una organización tiene un ciclo de actualización corto, por ejemplo no tardar mas de 48 horas en instalar un parche de software crítico luego de su publicación, la práctica prevendrá muchos de los ataques que “mojan prensa”.

¿Pero que decisión debe tomar la dirección de informática si es sabido que el software que se utiliza es vulnerable pero la vulnerabilidad específica es desconocida? Esta es la situación que enfrentan los usuarios de ArcSight, el reconocido software de administración de eventos e información de seguridad (SIEM por sus siglas en inglés). De acuerdo a Reuters, Arcsight que hasta hace poco era parte de HP (o Hewlett-Packard) permitió al gobierno ruso la inspección del código fuente de este programa con el fin de lograr ventas en ese pais. Esa inspección puede permitir al gobierno ruso descubrir vulnerabilidades que serían de otra manera desconocidas.

Para entender la gravedad de esta situación primero hay que conocer la criticidad de un sistema SIEM. Estos sistemas permite correlacionar eventos –también conocidos como logs- en una red en un momento dado. El tipo de eventos puede incluir ingresos a la red (el común “logearse”), notificaciones del software antivirus, cambio de configuración de usuarios, etc. El número de eventos en una red empresarial mediana puede alcanzar miles de millones en un mes.

El éxito de un equipo de ciberseguridad de una organización depende de la rápida detección de eventos anomálos como intentos de acceso fallidos, y encontrar tales eventos en la miriada de eventos que se generan en una red es como encontrar una aguja en un pajar.  Una vez el sistema SIEM correlaciona un evento anomálo, el analista de seguridad puede identificar una actividad maliciosa y tomar medidas de defensa necesarias como generar alertas, bloquear usuarios o desconectar un computador contaminado. Por lo tanto, si el sistema SIEM tiene fallas de seguridad un hacker puede tomar ventaja de estas vulnerabilidades y pasar desapercibidio.

Dado que es ampliamente reconocido el apoyo del gobierno ruso a grupos cuyas operaciones en Internet son bien dudosas, no es sorprendente el nivel de alarma en los expertos de ciberseguridad especialmente cuando organizaciones de defensa y militares norteamericanas como el pentágono y el ejército de Estados Unidos son usuarios de Arcsight.

Alguien puede argumentar que esa no debe ser una preocupación para entes latinoaméricanos. Y en la mayoría de los casos el argumento es válido. Entidades bancarias, del mercado minorista y grandes superficies posiblemente no ven a grupos de hackers de origen ruso como un adversario de importancia.

Sin embargo, el riesgo para organizaciones de defensa latinoamericanas puede ser bien diferente. Aquellos países de la zona que tienen relaciones poco cordiales o tirantes con países donde el gobierno ruso tiene cierta influencia deberían tener presente este caso.

Cuando tu parche de software no soluciona una vulnerabilidad

A finales del mes de noviembre, un desarrollador de software turco llamado Lemi Orhan Ergin twitteó que había una falla de seguridad crítica en la última versión del sistema operativo MAC (llamado High Sierra o versión 10.13). 

La criticidad era bastante alta pues permitía a un usuario ganar acceso con derechos de administrador en un computador MAC sin entrar ninguna clave. En el sistema operativo MacOS, como en todos los sistemas basados en Unix, el usuario “root” tiene alto acceso al sistema y por supuesto la situación es considerada gravísima. Quien use esta cuenta puede crear nuevos usuarios, habilitar acceso remoto y evitar la necesidad de acceso físico en un futuro.

Una vez hecho público, otros investigadores confirmaron esta vulnerabilidad y agregaron que era posible explotarla de manera remota. Este hecho convierte esta vulnerabilidad en una de las más serias y de alto impacto de los últimos años y por esta razón Apple liberó muy rápidamente un parche que arreglaba el problema. O eso pensamos todos.

Desafortunadamente, el parche reintroducía la vulnerabilidad descubierta por el desarrollador turco. Y esta es una situación que vale la pena analizar.

Cuando el producto de software que una compañía provee presenta vulnerabilidades de alto impacto, los desarrolladores dedican personal y tiempo valioso en solucionarlas.

Usualmente arreglar una vulnerabilidad puede tomar varias semanas, o incluso meses. El equipo de trabajo debe verificar que el nuevo código arregla la vulnerabilidad, que no introduce nuevas vulnerabilidades y que la funcionalidad no cambia. Esto se logra con el llamado “regression testing”, que no es otra cosa que hacer pruebas al software y su funcionalidad. También debe probarse la seguridad del sistema con los llamados “penetration testing”. Solo después de pasar estos requerimientos, el código que soluciona un problema debe liberarse.

Sin embargo, cuando el problema es en un sistema operativo que es usado por millones quienes toman decisiones se enfrentan a un serio dilema. El equipo debe actuar lo más rápido posible y tener el código listo con el menor número de errores. Quienes desarrollan software saben que este es un delicado balance. En el caso de Apple, es claro que no hubo ciertas verificaciones y que se liberó el parche con la intención de solucionar un problema serio en el menor tiempo posible sin las verificaciones necesarias.

Para mala fortuna de Apple, no se logró el objetivo y la compañía es hoy blanco de burlas y críticas por su falta de cuidado. Los responsables de liberar el código deben estar trabajando afanosamente contra el reloj y bajo la presión de los ejecutivos y el público en general.

Esta es una lección importante de aprender. En ocasiones las presiones financieras o de tiempo obligan a saltarse buenas prácticas que existen precisamente para evitar la ocurrencia de estos problemas. Apple tiene ingentes recursos financieros y este será un traspié más en la larga historia de errores de software que poco daño causará en el mediano o largo plazo.

Sin embargo, la historia puede ser muy diferente para compañías de software con recursos limitados. Para una pequeña empresa las consecuencias no se limitan a costos financieros o la pérdida de un contrato vital, sino que pueden desestabilizar o amenazar la existencia de la empresa misma.

La evolución de la seguridad de la información. El nuevo siglo

A finalizar el siglo XX, el gusano “Melissa” afectó a miles de usuarios de Windows a nivel mundial. Aunque los daños fueron mínimos, la rapidez de reproducción solo era una muestra de los días por venir.

Ya en el 2000, el gusano “ILOVEYOU” fué mucho más dañino y su distribución mundial.  Además de los cuantiosos daños, este gusano informático claramente demostró que las defensas informáticas de los 90 no eran efectivas contra las amenazas del nuevo siglo.

Las defensas tradicionales de una organización tales como el “firewall”, el sistema operativo y el antivirus actualizado poco pueden hacer si el usuario es partícipe de la infección.   No solo el uso sugestivo de la frase “I love you” engañó a sus víctimas sino que “ILOVEYOU” tomó ventaja del marco de programación nativo del sistema operativo Windows (conocido como VBS o Visual Basic Script). 

La explotación de vulnerabilidades del sistema operativo y otros componentes de software despega en forma acelarada con gusanos como “Red Worm” y “Nimda”. Los directores de informática deben ahora empezar a identificar que sistemas de información y respectivos componentes de software puedes ser afectados por diferentes amenazas. 

Los primeros años del siglo XXI son también testigos de un impulso adicional que dificultó la labor del agobiado director de informática. La introducción de herramientas de fácil uso como “Metasploit” y el escáner de vulnerabilidades “Nessus” propició el ascenso de los llamados “Script Kiddies”. Aunque el término es usado despectivamente para describir a atacantes de poca habilidad técnica, ésto no quiere decir que no puedan causar daño.

El proceso, aún en boga hoy en dia, es sencillo. Cuando una vulnerabilidad en un sistema o componente de software es hecha pública, el código no tarda en estar disponible en “Metasploit”, “Nessus” y programas similares.

Una vez allí, cualquier persona puede usar un scanner de vulnerabilidades como “Nessus” para identificar sistemas vulnerables. Cuando la identificación es positiva, el atacante solo dirije un programa como “Metasploit” contra el sistema vulnerable usando unos pocos clics. Nada sofisticado en realidad, pero si altamente efectivo.

Las empresas y usuarios se enfrentan no solo al tradicional virus sino a un volumen inesperado de atacantes que pueden estar localizados en cualquier lugar del globo. Por lo tando, se necesita una nueva aproximación en la defensa de activos de información.

La inseguridad de Yahoo. Un ataque devastador

Finalmente Yahoo admite que todos sus usuarios fueron víctimas del ataque que hackers realizaron hace algunos años. Léase bien, todos los usuarios. Es un final triste para una empresa ícono del boom de Internet de los años noventa.

Algunos podrán pensar que poco importa que tu correo personal haya sido hackeado, pero si el usuario reconsidera y analiza bien la situación se dará cuenta que sus contactos, fotos personales y correos con información posiblemente íntima fue en algún momento accedida por quien sabe quién.

Este tipo de ataques necesitan ingentes recursos, usualmente de naciones estado, y en este caso las pistas forenses apuntan a Rusia. Sin embargo, los altos ejecutivos de Yahoo facilitaron tal devastador ataque.

Ya en esta columna he escrito sobre la responsabilidad compartida que muchas veces los directivos de las empresas afectadas tienen en estos casos. No es secreto que altos directivos de Yahoo hicieron caso omiso de las advertencias de su personal de seguridad informática.  De acuerdo al reconocido diario The New York Times, la seguridad informática nunca fue una prioridad para los directivos de Yahoo.

La razón por tal desacato y falta de atención es bien conocida. Los altos costos que la seguridad informática conlleva no son desconocidos, pero también influyó el hecho que inyectar seguridad en aplicaciones requiere cambios en el comportamiento del usuario. Los directivos de Yahoo nunca quisieron enfrentar ese arduo camino que es reentrenar al usuario en el uso de aplicaciones más seguras.

Pero las consecuencias están allí a la vista de todos. La empresa perdió valor, el nombre “Yahoo” es ahora sinónimo de mala administración y es ahora parte de un conglomerado de telecomunicaciones. Como empresa independiente Yahoo simplemente desapareció.

Ese escepticismo y la negación de que los ataques cibernéticos puedan afectar una empresa es un lugar común en el empresariado latinoamericano. Ese pensamiento no es muy diferente al dicho “ojos que no ven corazón que no siente”. Esos mismos empresarios estarían prontos a exclamar que esa actitud solo conlleva al desastre.

La evolución de la seguridad de la información. El atraso latinoamericano

Los repetidos ataques cibérneticos de hoy en dia son un recordatorio de la persistencia y creciente sofisticación de los atacantes o actores maliciosos.

No hasta hace mucho, los hackers o “villanos cibernéticos” como algunos le llaman se contentaban con reclamar la autoría de un ataque simple. Un repaso a los diferentes estadios en la evolución de los ataques es instructiva porque también ayuda al oficial de seguridad, o gerente de sistemas si no existe tal oficial, a identificar el estado de madurez en las defensas de la organización.

Aunque desde los años 80 la existencia de virus informáticos era bien conocida, solo hasta la profileración de Internet y la consecuente conectividad de equipos permitió a los actores maliciosos extender su alcance a todo el globo en los años 90.  En esa época el principal reto para los profesionales de sistemas era tener los antivirus actualizados, y aunque suene increible tener antivirus instalados en todos los computadores de la organización.

Aunque no tengo datos de estudios concretos sobre el tema, no es inusual encontrar empresas latinoamericanas en este primer estadio donde la organización aún presenta problemas en la configuración de sus firewalls, uso adecuado de antivirus, y mantenimiento de sistemas operativos actualizados. Una causa que pueda explicar este relativo atraso es el uso persistente de software pirata. Casos como los de Méjico y Colombia son bien dicientes: el empresariado latinoamericano simplemente no quiere pagar por software.

Expertos del área han identificado una relación directa entre el uso de software pirata y la exposición indebida de información financiera y privada de las empresas. Esta actitud basada en un mal concepto de ahorro financiero tiene consecuencias desastrosas. Todo software moderno se comunica con el sitio web de su fabricante para bajar actualizaciones y verificar la legalidad del mismo. Si el software no es legal no podrá obtener las debidas actualizaciones que mitigan las vulnerabilidades que los hackers aprovechan.

En este estadio la labor del director de informática o gerente de sistemas es bien ardua. Primero debe identificar el software instalado en su organización y asegurar la legitimidad del mismo. Es en ese momento que la organización puede empezar su gestión de vulnerabilidades, asegurar que sus sistemas de información siguen los lineamientos sugeridos por el fabricante y mantener la debida actualización del software adquirido.  

Los pasos descritos son necesarios y críticos para iniciar una adecuada protección de los activos de información. Pero ese es solo el comienzo.

Responsabilidad compartida

Ha sucedido otra vez y sin duda sucederá en el futuro de nuevo. A mediados del pasado mes (Junio) los titulares de primera página anunciaron un nuevo ataque de ransomware llamado “Petya”. Este es un gusano informático que aún sigue causando estragos en varios países.

De acuerdo a los detalles técnicos, el modo de ataque de Petya sigue un modelo estándar. Explota una vulnerabilidad conocida o usa credenciales almacenadas en el equipo contaminado. Este modo de ataque no tiene nada particular o diferente a ataques previos. De hecho, como es bien sabido, Petya explota la misma vulnerabilidad utilizada por Wannacry unas semanas antes.

Y este es el punto importante a considerar. El parche de software que mitiga la vulnerabilidad conocida como “Eternal Blue,” fue publicado por Microsoft el mes de marzo de este año.  Wannacry y Petya explotan una vulnerabilidad para la cual ya había una solución. La criticidad de esta vulnerabilidad es tan alta que la actualización incluyó sistemas operativos que Microsoft no soporta como Windows XP.

En otras palabras,  había suficientes indicios para los profesionales de sistemas acerca de la importancia de esta actualización de software. Sin embargo, tanto Petya como Wannacry causaron estragos a nivel global.

Aunque los creadores de malware ciertamente son los grandes responsables de los daños causados, los administradores de sistemas de las compañías afectadas también comparten algo de esa responsabilidad. Entre la publicación de la actualización de software por parte de Microsoft y el ataque Petya pasaron 3 meses. Tiempo mas que suficiente para instalar los parches de software necesarios.

Las buenas prácticas de administración de sistemas indican que los sistemas de información debe tener una actualización crítica de software horas o pocos días después de su publicación. Sin embargo, el alto impacto de Wannacry y Petya claramente indica que las empresas afectadas fallan en sus procesos de actualización de sistemas operativos y otros paquetes de software.

Es difícil saber la causa general de la demora en actualización de software en las empresas afectadas. Aunque el atribulado gerente/vicepresidente de sistemas tiene un ítem adicional en su larga lista de preocupaciones, la práctica de actualización trimestral simplemente no es apta en el mundo de hoy. Por lo tanto, la administración de riesgo debe considerar este aspecto porque los delincuentes cibernéticos sin duda continuarán explotando este tipo de vulnerabilidades.

La alta gerencia de las empresas modernas deben tener este factor presente y facilitar la tarea de sus equipos técnicos, pero a la vez estos últimos deben educar a sus altos ejecutivos. Como se ha visto, fallar en esta importante responsabilidad puede tener serias consecuencias económicas y financieras.

Como se mide una vulnerabilidad en un sistema de información

Cada vez que hay un nuevo gusano informático o un ataque de ransomware se habla de vulnerabilidades críticas. ¿Pero quien mide la criticidad de una vulnerabilidad?

Las vulnerabilidades en sistemas de información son bastante comunes. Tanto que semanalmente el equipo de respuesta a incidentes informáticos del gobierno de Estados Unidos (www.us-cert.gov) publica una lista con las vulnerabilidades más importantes. Léase bien, no con todas las vulnerabilidades. La lista completa de vulnerabilidades públicas, o mejor dicho conocidas, está en la base nacional de datos de vulnerabilidades  o NVD (National Vulnerability Database). Esta base de datos es mantenida por NIST - National Institute of Standards and Technologies por sus siglas en inglés.

Las vulnerabilidades están clasificadas por orden de criticidad. Osea según el impacto en la confidencialidad, integridad o disponibilidad de un sistema de información.  En algunos casos extremos una vulnerabilidad puede afectar gravemente los tres elementos de la triada.

La medición del impacto de una vulnerabilidad usa un estándar conocido como CVSS (Common Vulnerability Scoring System) que utiliza varios indicadores para asignar el valor final. Por ejemplo, uno de los parámetros indica la severidad del vector de ataque. Si este vector permite una explotación remota entonces el valor será más alto que si la vulnerabilidad es solo local. Otros parámetros incluyen la facilidad de acceso, el tipo de autenticación y el impacto a la triada C-I-A.

La nota o grado asignado a cada vulnerabilidad es una composición de todos estos parámetros y el valor final va de cero a 10. Siendo 10 el valor asignado a una vulnerabilidad de altísima criticidad. Las fórmulas y los parámetros para el cálculo de la criticidad de una vulnerabilidad es material público y puede ser consultado en cualquier momento. Este sitio ofrece la calculadora de medición de vulnerabilidades.

El valor numérico final permite tener una medición común de fácil comunicación al público y como todo estándar, la medición debe ser reproducible.  

La base de datos nacional de vulnerabilidades (NVD) sigue usando la versión CVSS 2.0 a pesar de que es compatible con la versión CVSS 3.0. La calificación de impacto en CVSS 2.0 es como sigue:

- Bajo si la calificación CVSS está entre 0 .0 y 3.9

- Medio si la calificación CVSS está entre 4.0 y 6.9

- Alto si la calificación CVSS está entre 7.0 y 10.0

Entendiendo el vocabulario de seguridad de información

En el campo de seguridad de la información o seguridad informática se habla continuamente de vulnerabilidades, riesgos y amenazas. Ya he mencionado esos términos en anteriores entregas cuando discutí análisis de riesgo.

Algunos intercambian estos términos y la confusión aumenta cuando se habla del valor de riesgo o la criticidad de una vulnerabilidad. Sin embargo, en nuestro campo estos términos están bien establecidos y es bueno tener clara las definiciones.

Una frase muy común es “vulnerabilidad en la seguridad”. En términos generales, una vulnerabilidad es una falencia o debilidad en un sistema o componente que permitiría a un atacante comprometer la confidencialidad, integridad o disponibilidad del componente o sistema. En alguna literatura es posible encontrar la palabra actor o amenaza en lugar de atacante. La razón es que en la literatura inglesa el término “threat” es empleado y significa la existencia de una circunstancia que tiene el potencial de hacer daño.

El agente que “explota” o toma ventaja de la vulnerabilidad es usualmente un agente “activo”. Es decir, se asume la existencia de un elemento criminal, pero es importante tener presente que en ocasiones la amenaza puede provenir de sucesos naturales que afectan negativamente a un sistema. Por ejemplo, un tornado o inundación. Los profesionales que tratan recuperación de desastre y continuidad de negocios incluyen estos factores no humanos.

En la definición de vulnerabilidad están éstos términos importantes:

- Confidencialidad. Este término se refiere a la restricción a personal autorizado al acceso de datos o información de un sistema. Un ejemplo clásico es la confidencialidad de la historia clínica de un paciente. Solo este último y su médico están autorizados a acceder a la información de la historia clínica.

- Integridad. Como su nombre lo indica la integridad de datos requiere que estos estén completos y no hayan sido alterados. Cualquier cambio debe ser realizado por personal con legítima autoridad. Siguiendo con nuestro ejemplo, solo el médico o enfermera autorizada pueden hacer cambios a la historia clínica del paciente. No sobra decir que los cambios deben dejar registros (o log trails) con hora y fecha del cambio y autor del mismo.

- Disponibilidad. Este término se refiere al acceso a un recurso, datos en este caso. Si un atacante logra negar acceso a un sistema entonces la disponibilidad del sistema ha fallado.

En la literatura inglesa los atributos son conocidos como la triada C-I-A por sus siglas en inglés (Confidentiality, Integrity, Availability). Estos tres atributos son los fundamentos de la seguridad de información y la gestión de riesgo de información se basa en su análisis.

Seguridad y las prueba PISA

Los resultados de las pruebas PISA del 2016 generaron mucha controversia en Latinoamérica. Incluso algunos sectores han rechazado de plano las pruebas y consideran que no evalúan bien la realidad educativa de la sociedad.

Lo cierto es que los países hispanos no salieron bien librados y una falencia común fue la mala comprensión de lectura. Sin entrar en detalles polémicos, los resultados son un motivo de alarma para la profesión de seguridad informática. 

También existen otras consideraciones que este campo profesional afecta como la seguridad nacional y la necesidad de proteger la privacidad de los ciudadanos. La seguridad informática es vital en estas áreas.

Desafortunadamente, un nivel de comprensión de lectura de un 60% o menor es un gran impedimento para futuros y actuales candidatos profesionales.  La demanda en el área de seguridad es creciente y los salarios competitivos a nivel internacional. Las proyecciones laborales siguen presentando salarios mayores al promedio.  Pero, si los candidatos carecen de buena comprensión de lectura, los jóvenes estarán perdiendo una gran oportunidad que permita mejorar sus niveles de vida.

En los últimos años la práctica ha madurado y hoy hay varias sub-practicas que van desde el análisis de riesgo hasta el desarrollo de exploits de software. En el primer caso, el practicante deberá entender los protocolos de una organización, evaluar procesos de negocios y dilucidar la postura del riesgo. Obviamente, es necesario leer y entender extensa documentación que describa flujos de información, unidades de negocio, etc.

En el segundo excitante caso, un exitoso profesional entenderá muy bien el funcionamiento interno de sistemas operativos o protocolos de comunicación. Solo así, podrá encontrar las debilidades que intenta explotar.  Existe un mercado legal y muy lucrativo para quienes toman esta ruta. Una profesional con pobre compresión del funcionamiento de un sistema de información tendrá pocas probabilidades de triunfar en esa área tan promisoria.

A la falta de comprensión de lectura se suma el hecho que el material actualizado se encuentra en el idioma inglés. Por lo tanto, no existen buenos augurios si la comprensión falla en el idioma natal.

Algunos dirán que las universidades de élite locales gradúan profesionales que llenen estos requisitos. Sin embargo, estas universidades no cubren la demanda y muy poco tiene Latinoamérica para mostrar en la creación de empresas en este campo (Existen algunas excepciones).

Aunque suene repetitivo otros países si han visto la oportunidad y han creado políticas de fomento a alto nivel. Las empresas norteamericanas siguen disfrutando el liderazgo pero la competencia comercial es brutal. No es sorpresa que Israel, India y otros países asiáticos apoyen el talento en el campo de seguridad informática. Las promesa de estas oportunidades es un mercado laboral de altos salarios y empresas con ventas crecientes.  Sin duda, el deprimido mercado laboral latinoamericano daría la bienvenida a esta promesa.

Latinoamérica parece fallar en proveer a su población los requerimientos de la sociedad moderna. Es posible que existan muchas causas, incluso culturales, que expliquen el fracaso relativo en un área fundamental como la educación. 

La comprensión de lectura es un requisito básico y sin él, el profesional no entenderá sistemas complejos ni obtendrá las conclusiones necesarias que le permitan cumplir los requerimientos de la práctica. Esto solo aumentará la dependencia tecnológica de Latinoamérica.

Análisis de riesgo y Ransomware VI. Errores comunes

La participación de personal de diversas áreas de la organización es fundamental para tener un análisis que se ajuste a la realidad de la organización. Sólo la participación con opiniones diversas y no necesariamente técnicas minimizan errores de juicio. 

Un error común que muchos ejecutivos de sistemas y seguridad cometen es asumir que el daño se limita al laptop o computador infectado. Sin embargo, nada es mas lejos de la realidad.

Si la victima del ataque es un administrador de un sistema informático el impacto del ataque puede ser gravísimo. Por ejemplo, si el sistema en cuestión es un sistema de almacenamiento conectado en red (NAS), entonces el daño causado por un administrador con un equipo contaminado puede extenderse a todos los datos almacenados de una empresa.

Como se puede dilucidar, un análisis con una errónea identificación de condiciones iniciales tendrá recomendaciones que pueden inducir a costosas consecuencias. Es en esta fase que la inclusión de diversas áreas del negocio provee su mayor valor. Solo la experiencia y el conocimiento colectivo de personal diverso permitirá identificar correctamente el impacto de Ransomware.

Además, el afinamiento del análisis solo ocurre cuando se realiza continuamente. Un análisis único simplemente será papel escrito muerto con recomendaciones que la organización nunca aplicará. En su etapa inicial, el análisis posiblemente requiera la participación de personal en intervalos semanales. En la medida que la práctica madure, el equipo de análisis puede incrementar el intervalo de reuniones.

Es infortunado que muchos departamentos de sistemas en Latinoamérica aun estén abrumados por el soporte técnico y dediquen poco tiempo a la identificación de escenarios negativos que pueden poner en peligro a la organización; y como consecuencia no tienen planes de defensa adecuados contra los diversos ataques que las organizaciones modernas sufren. Sin embargo, nunca es tarde para iniciar el primer análisis.

Análisis de riesgo y Ransomware V. Condiciones iniciales

Antes de iniciar el análisis como tal, un ejercicio “table top” ayudará a identificar las condiciones iniciales. Las condiciones iniciales son importantes y su inclusión o no puede conllevar a resultados completamente diferentes. Y en este caso el análisis puede ofrecer recomendaciones no adecuadas.

Errores de juicio en las reales condiciones de acceso a datos pueden dar como resultado análisis erróneos o complacientes. Desafortunadamente, en mi experiencia la complacencia es una situación común.

Un análisis de riesgo de este tipo puede ser complicado especialmente si la organización no ha identificado previamente que usuarios tienen acceso a que tipo de información. Esto puede parecer ilógico, pero la identificación de flujo de información toma tiempo, meses en algunos casos.

A pesar de la aparente complejidad, el practicante de seguridad informática no debe asustarse ante la inmensidad del trabajo a realizar. La delimitación de condiciones iniciales tales como el tipo de acceso de diferentes usuarios e identificación de datos importantes permitirán llevar a cabo un buen análisis de riesgo. La ventaja de un análisis de alcance limitado es que es más rápido y no consume mucho tiempo del personal involucrado. La desventaja es asumir que es las recomendaciones son válidas para todos las situaciones. Pero, si las limitaciones del análisis son conocidas de antemano, es posible extrapolar las recomendaciones y aplicarlas a escenarios más complejos.  

Aunque este articulo solo provee un vistazo de los factores que un análisis de riesgo debe considerar, si enfatiza la necesidad de identificar correctamente las condiciones de la organización. En la próxima entrega describiré un error común en los análisis de riesgo.

Análisis de riesgo y Ransomware. Como medir el impacto II

Para minimizar el impacto en la operación diaria, la organización tratará a todo costo recuperar la información que necesita. Decisiones tomadas previamente empiezan a tener un impacto en este momento.  Como expliqué anteriormente, una decisión de pago por rescate de datos será solo el inicio de pagos posteriores.

Independiente de la decisión de alta gerencia, los ingenieros y técnicos tratarán de identificar, limpiar y recuperar cualquier sistema contaminado. El análisis de riesgo debe incluir los costos en horas hombre relacionados en la recuperación de un sistema, incluyendo un simple portátil. En algunos casos, será necesario contratar personal especializado. Estos son costos adicionales también deben ser parte del análisis.

En ambientes altamente competitivos como el mercado de grandes superficies, una demora o congelamiento de la operación puede ser mortal. Si cientos de clientes no pueden comprar o acceder a un servicio es claro que la reputación de la organización tendrá un impacto negativo. Desafortunadamente, medir el impacto en reputación no es fácil y pocas organizaciones tienen una medida del valor de su reputación.

En conclusión aunque no es posible tener una medida fiel de los posibles costos de un ataque de Ransomware, la práctica permite tener una buena idea del impacto a la operación y los datos de la organización. Una aproximación cualitativa con algunos datos financieros ciertamente crearan conciencia en la alta gerencia y facilitarán la implementación de medidas defensivas.

Análisis de riesgo y Ransomware. Como medir el impacto I.

La anterior entrega de esta serie termina con una lista de consecuencias de alto impacto que cualquier organización sufrirá en un ataque de Ransomware. Desafortunadamente,  la víctima probablemente sufra todas al mismo tiempo.

Cuando una organización es presa de una ataque ransomware, la primera consecuencia es la falta de acceso a la información que el ransomware ha contaminado. Algunas veces los datos contaminados serán inaccesibles de manera permanente.

Dependiendo de la criticidad de los datos afectados, la organización podría o no operar de manera regular; o peor aun la operación se puede detener completamente. Si el caso es este ultimo es fácil medir el impacto financiero.

Este último dato es importante porque permite al analista de riesgo tener un análisis cuantitativo con valores aproximados. Nada abre mas los ojos de los ejecutivos que una presentación con datos concretos y el impacto financiero de un ataque de este tipo.

Por fortuna, muchas organizaciones conocen las pérdidas financieras incurridas en caso de que la operación se detenga. En algunos casos existe datos detallados de pérdidas por hora. Incluir datos financieros concretos en el análisis facilitará al oficial de seguridad informática proveer información de fácil digestión para ejecutivos de mercadeo o finanzas.

Dada la forma de operar de ransomware, la organización víctima verá su operación afectada de una manera u otra. Entonces, el análisis puede indicar el impacto máximo en un marco determinado de tiempo. Es decir, el reporte del análisis señalaría un valor de pérdidas dado en dólares (o la moneda local) por hora, día o cualquier otro referente temporal.

El impacto a la organización es función del equipo y personal afectado por ransomware. Las perdidas financieras diferirán notablemente si el afectado es una recepcionista o un analista financiero con acceso a documentos en servidores de archivo. Por lo tanto, el análisis deberá incluir los diferentes tipos de personal que accede a datos dentro de la organización

Análisis de riesgo y Ransomware II. Impacto

En mi anterior entrega decía que el análisis de riesgo es una importante herramienta para hacer frente al ransomware. El análisis es importante porque permite dilucidar las falencias en defensa, y por fortuna, como enfrentarlas.

El análisis debe identificar las vulnerabilidades presentes que la amenaza de ransomware puede explotar y el impacto en las actividades de la organización. En muchos casos es posible tener una análisis cuantitativo que mida el máximo impacto financiero de un ataque de ransomware. Para un análisis adecuado es entonces necesario identificar las consecuencias de mayor impacto.

Las posibles consecuencias negativas de una ataque de este tipo son variadas e incluyen como mínimo  las siguientes:

• Pérdida temporal o permanente de información propietaria o crítica

• Interrupción de la operación de la organización

• Pérdidas financieras incurridas en la recuperación de archivos y sistemas de información

• Daño potencial a la reputación de la organización

 

 

Análisis de riesgo y Ransomware

Ante el auge del Ransomware, algunos se preguntaran como puede enfrentarse esta plaga. Hay algunas buenas prácticas que mencioné anteriormente, pero la mejor defensa es identificar el posible daño y como afectaría a la organización.

Un proceso de gran utilidad en la identificación de impactos y vulnerabilidades de un ataque digital es el  análisis de riesgo. En su definición mas general, riesgo es producto de la explotación de una vulnerabilidad por un agente externo o interno. El impacto de un riesgo en particular dependerá de la criticidad del sistema afectado.

A pesar de que solo organizaciones con prácticas de seguridad informática maduras practican análisis de riesgo de manera continua, cualquier tipo de organización puede obtener beneficios de este análisis.

Una ventaja del análisis es permitir a la organización proceder de manera sistemática en la identificación de vulnerabilidades y riesgos que impacten de manera negativa a la organización. Adicionalmente, la práctica formal minimiza los errores de juicio que son comunes cuando no existe un análisis ponderado de una situación dada.

La identificación de diferentes factores de un riesgo determinado puede conllevar algún tiempo. Identificar el primer factor, el agente externo o interno en el análisis de riesgo de ransomware es posiblemente el menos complicado. En algunos pocos casos, digamos entidades militares, será importante diferenciar entre un agente extranjero o nacional. Pero en la mayoría de casos basta saber que existen organizaciones delictivas dedicadas a la extorsión digital. Estos serán los agentes, o amenazas, que explotarían una vulnerabilidad existente.

Identificar vulnerabilidades puede ser bastante mas complicado. En el caso de ransomware los tradicionales escáneres de vulnerabilidades son de poca utilidad. Antivirus y otros agentes de defensa en los equipos tampoco sirven mucho. Equipos proxies  y software de seguridad ATP (Advanced Threat Protection) tienen mayor éxito contra sitios web contaminados, pero aun así existen muchos sitios contaminados sin reportar.

Ransomware no explota una vulnerabilidad especifica de un sistema operativo o programa sino que toma ventaja de los datos a los que tenga acceso un usuario.

Desafortunadamente un error común es asumir que solo los datos locales son afectados. Ransomware puede bloquear datos que residan tanto en un equipo local o en la red empresarial.

Solo el adecuado conocimiento del tipo de acceso de datos que diferentes usuarios poseen permite un adecuado análisis. Por esa razón, en el análisis deberá participar personal de diferentes departamentos o áreas. Análisis realizados al interior de un departamento de sistemas sin la participación de otras áreas será insuficiente, y peor genera el común sentido de complacencia de muchos jefes de sistemas e incluso de auditoría.