Lecciones aprendidas de InfoSec de un …


Todos hacemos suposiciones. Raramente resultan bien. Un problema de fecha nuevo / antiguo ofrece una lección de por qué es así.

(imagen de kwarkot, a través de Adobe Stock)

(imagen de kwarkot, a través de Adobe Inventory)

Hace veinte años, el mundo de TI pensó colectivamente que había esquivado una bala del tamaño de un milenio cuando los años de preparación vieron el amanecer del 1 de enero de 2000, sin una catástrofe informática mundial. Sin embargo, para algunos, la bala Y2K ha resultado ser un boomerang. Y es un boomerang que ofrece lecciones para los profesionales de la seguridad.

El problema de cambio de fecha que se esquivó en 2000 ha levantado su fea cabeza en 2020. ¿Por qué? Debido a que los desarrolladores de application en 1999 intentaron desesperadamente descubrir cómo evitar que los sistemas informáticos que utilizan un campo anual de dos dígitos se confundan sobre el siglo, hicieron algunas suposiciones.

Su solución se llamaba «ventanas» o dependía de un «año pivote»: una very simple bandera significaba que se suponía que las fechas de dos dígitos en un cierto rango (típicamente 20 a 99) estaban en el siglo XX, mientras que las del rango 00 a 19 se suponía que estaban en el 21.

Se supuso además, en esos días embriagadores cuando los programadores estaban de fiesta como en 1999, que cualquier sistema en uso en el cambio de milenio habría sido reemplazado (por un sistema con un nuevo software program con más fechas incluidas) dentro de 20 años.

Y ahora puedes ver dónde entra el problema.

Sistemas de larga duración
Las suposiciones como «seguramente no utilizarán este sistema dentro de 20 años» casi siempre se vuelven para morder a los profesionales de TI porque estas suposiciones olvidan que las empresas indudablemente elegirán la opción más barata, lo que muy bien podría significar obligar al departamento de TI a mantener el whisky. – Unir el mismo sistema antiguo año tras año tras año.

En este caso specific, no solo muchos de esos sistemas milenarios siguen en servicio, sino que los programadores con tiempo limitado han tomado esas rutinas de fecha de dos dígitos y las han usado, sin alteraciones, en sistemas más nuevos. Todo esto significó que el 1 de enero de 2020, más de unas pocas piezas de software crítico para el negocio dejaron de funcionar o dejaron de funcionar correctamente.

En algunos casos, el problema fue descubierto y parcheado antes de finales de 2019. En otros, los parches de emergencia se pusieron en servicio de inmediato en el nuevo año.

Y en otros, las empresas pasaron días (o más) esperando imprimir recibos, aceptar dinero de los clientes o llevar a cabo otros procesos comerciales críticos mientras los desarrolladores de software package trabajaban para solucionar todos los problemas relacionados con la fecha.

Esto está lejos de ser el primer caso de suposiciones que se vuelven para morder a los profesionales de la industria. Algunos de nosotros podemos recordar que «nadie necesitará más de 64k de memoria» como un conjunto specific de dientes, y no tengo ningún interés en volver a combatir la batalla del espacio de direcciones IPv4.

Para los profesionales de la seguridad, la verdadera lección de todo esto es que los arquitectos, ingenieros de sistemas y desarrolladores de software package van a hacer suposiciones en el trabajo que realizan. La mayoría de ellos parecerán razonables en el momento en que se hacen. Algunos continuarán pareciéndolo, pero muchos terminarán siendo la causa de un dolor de cabeza, o algo peor. Entonces, ¿qué puede hacer un profesional de seguridad para reducir el riesgo basado en suposiciones?

Pregunta siempre
El primero es sentarse a la mesa con esos arquitectos y desarrolladores para que pueda comprender algunos de esos supuestos molestos. Otra razón para el asiento es asegurarse de que se documenten tantas suposiciones como sea posible. Tus sucesores te lo agradecerán.

Luego, debería pasar por los sistemas existentes (especialmente aquellos que han estado en el trabajo más tiempo que usted) y obtener una visibilidad seria de lo que están hechos y cómo funcionan, con un énfasis individual en identificar los supuestos que antes Los desarrolladores podrían haber hecho. Es fácil dejarse llevar por la creencia de que un proceso regular de parcheo y actualización habrá eliminado la maleza irracional, pero se necesita una actualización seria para resolver un límite arquitectónico diseñado en el sistema.

Finalmente, no tenga miedo de mirar sus sistemas con los ojos de los principiantes. Cuando tenemos prisa, bajo presión, tratando de mostrarles a nuestros colegas cuán informados somos, o los tres, tendemos a hacer nuestras propias suposiciones sobre cómo funcionan las cosas. («No veo un cable todo el acceso a la pink DEBE ser a través de Wi-Fi»). No tenga miedo de hacer las preguntas más básicas y tontas para verificar con precisión cómo funcionan las cosas. Y cuando haga esas preguntas, no permita que los sistemas o las personas den respuestas apresuradas y no examinadas. Asegúrese de que hayan verificado los hechos obvios que le están entregando.

Las suposiciones que hace su organización pueden no tener el impacto digno de los titulares de los problemas milenarios, pero aún pueden generar serias vulnerabilidades y problemas importantes de resiliencia del sistema. Todos hemos escuchado la vieja sierra, «Cuando asumes que eres un asno de ti y de mí». El hecho de que sea canoso y cliché no significa que no sea cierto.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Dim Looking at. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y online video para Dim Looking at y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Más concepts





Enlace a la noticia authentic