Procrastinar en ciberseguridad: “Disculpen la demora”

¿Somos conscientes de cuántos de nuestros equipos informáticos emplean versiones antiguas de software para las que existen actualizaciones de seguridad? El silencio de muchos de los lectores ante la pregunta seguramente pondrá de manifiesto una práctica que se ha puesto de moda en muchas actividades de nuestra vida cotidiana: la procrastinación.

Actualizaciones de seguridad

Las actualizaciones de seguridad de aplicaciones software es una de las acciones más eficientes para reducir la superficie de ataque frente a los ciberdelincuentes. Sin embargo, en muchas ocasiones, posponemos esa decisión hasta que, por algún motivo, normalmente externo, nos sentimos obligados a realizarlas.

Existen centenares de vulnerabilidades en productos que permanecen sin ser resueltas pese a que los fabricantes proporcionan parches para corregirlas. Recientemente, el CISA norteamericano emitía una directiva dirigida a sus organismos públicos para que corrigieran más de 300 vulnerabilidades, conocidas y explotadas, que afectaban a las soluciones software comerciales desplegadas en sus equipos. Pero no se trataba de una recomendación, no. Se trataba de una orden.

La situación no es nueva y posiblemente no exclusiva de los americanos. De hecho, muchas de las vulnerabilidades explotadas en los últimos meses han estado relacionadas con mecanismos habilitadores del teletrabajo tales como las VPN o los servicios de escritorios remotos.

Compañías y organismos de todo el mundo se han visto afectadas por problemas en la ejecución remotas de programas (RCE), acceso a contenidos de los sistemas, escalado de privilegios o vulneración de los sistemas de autenticación, simplemente porque utilizaban versiones obsoletas de algunos productos.

Vulnerabilidades y exploits

No pretendemos escandalizar al lector, pero si en algún momento siente la curiosidad, podría consultar alguno de los múltiples repositorios que existen de vulnerabilidades de productos, comerciales y de software libre, junto con los parches que hay para corregirlas. Estudios del sector muestran que vulnerabilidades descubiertas hace más de 4 años aún aparecen en muchos equipos. Algo así como un tipo de obsolescencia software silenciosa.

Una vulnerabilidad es una debilidad del software que deja abierto un producto a un posible ataque. Por su parte, un “exploit” es un código o amenaza que se aprovecha de la vulnerabilidad para pervertir el comportamiento del producto. Pues bien, puede haber centenares de exploits para una única vulnerabilidad. Uno de los ejemplos más evidentes de exploits tiene su reflejo en los ransomware.

Numerosos estudios recogen vulnerabilidades cuyos exploits se prolongan más de una década. Quizás los más representativos estén relacionados con la apertura de documentos, Word o PDF, pero los hay para todo tipo de productos.

Justificaciones para procrastinar

Un experimento llevado en la Universidad de Carnegie Mellon mostró hace unos años cómo la mayoría de las personas retrasaban la decisión de actualización de su software, aun a riesgo de incurrir en problemas de seguridad, por razones tan dispares como que la actualización les interfería lo que consideraban una tarea primaria. Incluso se llegó a comprobar cómo, cuando no impactaban en tareas primarias, estas actualizaciones eran retrasadas simplemente por falta de atención o incluso por infravaloración del riesgo.

Las razones más habituales para la procrastinación en la instalación de actualizaciones de seguridad son múltiples. Simplemente enumeraremos algunas de ellas:

• Falta de hábito en las tareas de actualizaciones.
• Confianza en que la empresa no tiene riesgos importantes por falta de un análisis de riesgos adecuado.
• La experiencia pasada de la empresa sin incidentes, lo que reafirma la decisión de retrasar cualquier acción dirigida a mejorar su seguridad.
• Devaluación percibida del efecto de la medida. Las notificaciones de actualizaciones no explican las razones de seguridad para hacerlas y en muchos casos se consideran que no son necesarias. La seguridad solo se comprueba cuando falla.
• Prevalencia del uso del equipo o aplicación sobre su seguridad: solo se piensa en las actualizaciones cuando afectan a la funcionalidad.
• Alteración de la rutina de las personas que incluso generan miedo a cambios en las operativa que afecten a esa rutina.

Luego existe otro tipo de razones, no menos significativas, que aportanautojustificación, como:

• No se tiene seguridad de si las notificaciones son en sí mismas un tipo de malware.
• Existe pereza ante la posibilidad de tener que jugar un papel activo en la actualización.
• Los cambios que introducen las actualizaciones son percibidos como limitaciones de funcionalidades disponibles.
• Hay desconfianza sobre errores de las nuevas versiones. En el mejor de los casos se retrasa la actualización hasta comprobar que otros usuarios no han tenido problemas.
• Representan molestias como tener que reiniciar equipos o liberar espacio de disco o memoria.

Incluso podríamos identificar motivaciones reflexivas basadas en supuestos análisis de impacto y prioridades:

• Cuanto menor impacto tenga en el día a día más predisposición se mostrará a tomar la medida. El impacto se mide en comodidad, coste, etc.
• Tras recibir un ataque, las empresas reaccionan con la implantación de medidas de seguridad, pero en muchas ocasiones, y tras periodos de tranquilidad, vuelven al comportamiento original.
• Las comunicaciones sobre posibles vulnerabilidades y amenazas tienen una vida muy corta y tienden a olvidarse con rapidez.

Solo a modo de ejemplo doméstico podríamos mencionar que menos de un 20% de los usuarios de teléfonos móviles instalan las actualizaciones el mismo día que son publicadas y en torno al 50% lo retrasan más de 3 meses.

Algunos pensarán que ese es un comportamiento es más propio del ciudadano de a pie; que las empresas actúan de forma mucho más responsable. Pues bien, completemos los ejemplos con uno empresarial: en mayo de 2017 se produjo un ataque masivo a través de un malware conocido como WannaCry, ¿verdad? El ciberataque afectó a centenares de miles de equipos en el mundo. ¿Cuál fue la razón de su éxito? Los equipos afectados no habían actualizado su sistema operativo.

Procesos y Procedimientos

El comportamiento metodológico y procedimental a la hora de realizar actualizaciones de seguridad en las infraestructuras de sistemas de las compañías puede marcar los niveles de riesgos de una organización. Al fin y al cabo, los equipos de gestión de la seguridad pueden no detectar una vulnerabilidad, pero no pueden dejar de lado que una vulnerabilidad identificada y divulgada es como llamar a los ciberdelincuentes para que prueben si está corregida.

Las mejoras en el comportamiento de los ciudadanos y empresas a la hora de implantar actualizaciones de seguridad pueden venir a través la concienciación (utilizando técnicas de comunicación o incluso el premio) o la implantación de políticas de seguridad restrictivas, por poner un par de ejemplos.

Al fin y al cabo, existen razones más que suficientes para instalar estas actualizaciones: (a) se corrigen errores (susceptibles de originar vulnerabilidades), (b) se resuelven problemas de seguridad, (c) se aprovechan mejor las prestaciones del hardware o software de base, (d) se añaden nuevas funcionalidades y servicios, etc.

Bien es cierto que, en ocasiones, las actualizaciones del software no afectan a la seguridad. En ese caso, y solo en ese caso, se podría considerar la posibilidad de posponerlas: las nuevas utilidades de los productos no tienen por qué ser inmediatamente necesarias.