Después de la prehistoria, viene la edad media
Hace no mucho tiempo, digamos que unos 20 años, muchas empresas trabajaban con sistemas propietarios de las marcas que en aquella época estaban en auge. Podía encontrarse uno con los sistemas de Digital Equipment Corporation, Bull, etc., pero sin duda, toda aquella PYME de la época que tuviese cierto nivel de administración algo complejo optaba por los sistemas de IBM. Habían nacido los primeros mini ordenadores que eran asequibles, programables por el usuario, o por una empresa subcontratada.
El sistema operativo de aquellos “mini” ordenadores —el peso de la máquina podía llegar a unos 400 Kg.— era el SSP, que en sus diferentes versiones cubrió el abanico de los S/3X de IBM. El más utilizado en la época era el S/34, aunque ya existía el S/36, pero en cierto modo era bastante inalcanzable para aquellos que conservaban su S/34.
Mi trabajo en la época era de ingeniero de campo, por lo que me dedicaba a solucionar los problemas de dichas máquinas. Por lo general eran problemas de cableado de las pantallas, pero también ocurrían cosas como el bloqueo del sistema de frenado de los discos duros (que iba de 5 a 64 Mb). Hay que tener en cuenta que aquellos discos podían pesar unos 35 a 40 kilos, por lo que parar la inercia del giro era una ardua tarea, y para lo que se aplicaba la fuerza de un freno eléctrico con una zapata sobre el eje. Otros de los problemas podía ser que un módulo de memoria (de 8 Kb) fallase, y el peor desastre que podía ocurrir era que aterrizasen (literalmente, porque “volaban” controladas por un flujo de aire) las cabezas de lectura del disco duro.
Pues bien, en ese problema me vi metido en algunas ocasiones, pero la peor que recuerdo fue cuando en la empresa que me encontraba, filial de otra recientemente desaparecida, además de no tener las copias de seguridad al día, no sabían la contraseña del administrador del sistema. Restauré el contenido del disco a partir de la copia de seguridad más reciente, y tras ello arrancó el sistema operativo, pero para poder configurar lo básico y poder funcionar, se debía introducir la contraseña del administrador.
Hallé la solución por casualidad, en base a unas explicaciones ciertamente poco claras y no manuscritas: había que arrancar con el soporte de instalación del sistema operativo y utilizar la opción Debug. Esto proporcionaba una visión del contenido, byte a byte y en hexadecimal, del disco duro. En el primer segmento, aparecían varios caracteres diferentes de los 00 iniciales, por lo que deduje que la primera información que aparecía debía ser la que estaba buscando. Al no tener traducción a caracteres EBCDIC legibles, hice una sencilla operación: resté lo que estaba escrito del hexadecimal FF y me dio la clave: era el nombre del operador al revés.
Desde ese día, y con una pequeña orientación por mi parte en cuanto a seguridad básica, construyeron una verdadera fortaleza en cuanto al acceso al sistema. No hay nada cómo sufrir problemas de seguridad para que se despliegue la imaginación de los responsables.
Mi pregunta es: ¿Por qué no se conciencian desde el primer momento en que tienen a su cargo un sistema, que la seguridad es vital? Otra pregunta obvia que se me ocurre es: ¿Seguro que se le piden responsabilidades a aquellos que administran un sistema sin seguridad definida? Y la siguiente y última sería: ¿Es consciente el director general, al administrador, el gerente o el responsable de la empresa, de que su departamento de TI tiene una infraestructura de seguridad sólida y fiable?
Dejo la respuesta a esas preguntas como ejercicio para el lector.
Mi experiencia en diversas empresas es que nadie es consciente de la falta de seguridad, hasta que ocurre un desastre y si la seguridad funciona y no sucede nada, para qué gastarse el dinero?. Entonces vienen las reducciones de presupuesto en TI y las consecuencias son volver al otro lado del círculo.
Siendo positivo, recuerdo haber tenido frente a la puerta de mi despacho a un director internacional y al jefazo local, mirándome a ver que iba a hacer mientras mi sistema de baterias mantenía los AS/400, durante un fallo de potencia electrica, y las pantallas críticas (la mía lo era) seguían abiertas. Era como una diversión para ellos y un posible infierno para mi. Una caida de luz suponía una recuperación muy larga en aquel tiempo y mas si dos AS/400 iban sincronizando bases de datos con una cosa llamada MIMIX. Si os preguntais porqué no paraba los sistemas antes de que cayeran os diré que Murphy estaba allí y el proceso en marcha era el cierre de inventarios y pedidos del mes, interrumpirlo era como suicidarse. Al final, volvió la luz, pero esa noche no dormí pensando en otras posibles caidas.
Recientemente Bruce Schneier hace referencia a ciertas máximas de la seguridad. La más significativa queda expresada como Backwards Maxim: Most people will assume everything is secure until provided strong evidence to the contrary–exactly backwards from a reasonable approach. (la mayoría de la gente asumirá que todo es seguro hasta que se les muestren evidencias significativas de lo contrario, justo lo contrario de lo que sugiere una aproximación razonable)
Justo lo que viene a apuntar el comentario anterior. Triste pero no deja de ser una realidad y quizás se deba a la manera que tiene el ser humano de afrontar la gestión del riesgo.
El artículo entero puede leerse en Schneier on Security: Risk of Knowing Too Much About Risk y merece la pena destacar que las personas que más creen controlar o conocer los riesgos pueden cometer errores o tomar decisiones no adecuadas basadas en una confianza o conocimiento de la situación que puede no ser tal. El miedo es una fuerza poderosa y con temor la toma de decisiones puede producir resultados nefastos.Por lo que parece, nuestro cerebro procesa el riesgo de dos maneras diferentes y complementarias:
La primera es intuitiva, emocional y basada en la experiencia. Tratamos de mitigar aquello que tememos o que no podemos controlar, basados tanto en la experiencia como en la intuición de lo que puede pasar. Este parece ser un mecanismo de supervivencia evolutiva. En presencia de incertidumbre, el miedo es una valiosa defensa. Nuestro cerebro reacciona emocionalmente pero sin realizar un análisis objetivo del riesgo potencial.
La segunda forma en mediante el análisis de riesgos: la utilización de probabilidad y estadística para anular, o por lo menos priorizar nuestro temor. Es decir, nuestro cerebro juega de abogado del diablo con su primera reacción intuitiva, y trata de justificar las probabilidades reales de que pase algo para tomar una decisión final.
Lamentablemente para nosotros el análisis de riesgos no es la parte que gana. La intuición o el miedo pueden abrumar fácilmente a la parte analítica, especialmente cuando nuestro cerebro en situaciones de miedo recupera imágenes grabadas en la memoria sobre catástrofes, accidentes o experiencias desagradables que quedan más fácilmente almacenadas por la memoria emocional.
Totalmente de acuerdo Javier. En situaciones extremas nos dejamos llevar más por la intuición y el miedo irracional que por el raciocinio. Y eso sólo se puede corregir con “entrenamiento”. Lo que desde mi punto de vista nos lleva a la conclusión de que hay que hacer un esfuerzo importante en integrar la seguridad y la gestión del riesgo en la cultura de las organizaciones. Sólo así conseguiremos estar en condiciones de “esperar lo inesperado”.
Lo comentaba un compañero comiendo hoy: durante una estancia de estudios en USA, el colegio en el que estudiaba hacía simulacros mensuales de evacuación del colegio por incendio. El procedimiento se había automatizado e interiorizado de tal manera, que si un día el incendio fuese real, el comportamiento de las personas habría sido el mismo, aunque quizás lo habrían hecho un poco más rápido ;-)