Gestión de incidentes y crisis, cuando el "MundoReal" impacta en primera persona.

Este blog técnico siempre ha orientado sus contenidos a compartir conocimientos en la materia o comentar situaciones cotidianas analizadas desde la perspectiva de la seguridad de la información.

Sin embargo he descubierto que con  el paso del tiempo, también ha puesto en valor su capacidad de dejar constancia en el tiempo de mi forma de ver las cosas e incluso de la evolución profesional desde que llevo recogiendo entradas hace más de 20 años ya. Es por tanto un blog-log de mi vida profesional y de mi evolución personal que describe mi historia y mis cicatrices. 

Hacía tiempo que tenía abandonada esta parcela de mi vida pero, estas últimas semanas, he tenido la oportunidad de disfrutar de suficiente tiempo y serenidad para poder ordenar el trastero de los pensamientos. Lo que voy a describir en esta entrada está relacionada con el proceso de gestión de incidentes /crisis pero contextualizado al ámbito personal, explicando mi propia experiencia sobre lo vivido en estas últimas cuatro semanas y cómo contar con herramientas de nuestra disciplina me han sido muy útiles. En la vida es importante tropezar y aprender de las cicatrices que el cuerpo va recogiendo para evolucionar. Quizás contarlo y comentar lo que para mí han sido factores clave que han permitido llevar mejor este tipo de situaciones, permita a otros recoger algunas ideas que puedan aplicar en su caso concreto. 

Esto además encaja con la última de las actividades del proceso de gestión de incidentes, en donde una vez finalizada la batalla, toca analizar, reflexionar y recapitular bajo la fase de "lecciones aprendidas".  He valorado durante varios días hasta dónde llegar a ser transparente respecto a mis emociones... y lo que a continuación describo lo hago con conocimiento de causa. Comenzamos...

Gestión de incidentes de ciberseguridad.

La mejor propuesta de procesos y referencia principal la estableció "NIST 800-61 Computer Security Incident Handling Guide" allá por 2012. Las actividades del proceso quedaban establecidas en 4 fases principales, donde la primera de ellas era propia de diseño y el resto ya operativas cuando el incidente se produce. El siguiente gráfico muestra de forma sencilla estas actividades y simplifica de forma bella la propia naturaleza de estas actividades. Como puede verse, el feedback es constante, tanto entre las fases operativas (detección/analisis y contención/erradicación/recuperación) como entre las fases iniciales y finales (ajustes desde las lecciones aprendidas hacia el propio diseño del proceso para asegurar la mejora continua.

Todo esto cobra sentido cuando se identifica claramente que la toma de decisiones en un entorno dinámico sometido a incertidumbre debe basarse en un ciclo de gestión retroalimentado basado en el OODA LOOP.

Esta dinámica de trabajo permite en todo momento estar estudiando la información de entrada, obtener conciencia situacional para identificar riesgos, situación, respuesta de ajuste para minimizar consecuencias y respuesta para lograr variar o revertir los riesgos identificados.

Una vez realizada esta pequeña exposición teórica, ahora vamos a iniciar la reflexión más intima de cómo es posible emplear conocimientos de unas disciplinas en otras para obtener nuevos enfoques a la hora de resolver problemas. Es lo que denominamos Hibridación de disciplinas como base para la innovación que aplico constantemente que detecto algún patrón.

Contexto de situación.

Como pequeña descripción de contexto debo decir que estas dos últimas semanas (desde primeros de mayo de 2022 para contextualizar puntualmente el momento en el blog) estoy de baja por enfermedad. Aunque continuo en proceso de diagnóstico y valoración de daños, un virus no informático hackeó mi oído interno causando daños en el sistema del equilibrio y el sistema auditivo del hardware afectado (lado izquierdo) con degradación casi completa de la audición. Ello, acompañado de unos síntomas severos de vértigo que inutilizaban el sistema locomotor, la capacidad de mantener la verticalidad y andar de forma normal y generaban colateralmente una denegación de servicio del sistema digestivo que expulsaba cualquier solido o liquido que quisiera procesar. En resumen, una degradación completa que sólo me permitía estar en cama tumbado sin casi poder probar alimento durante 3 días. Vista la situación y su severidad, tuve que acudir a urgencias para una valoración del estado. En una primera visita, los síntomas eran severos y se empezó a administrar medicación inicial de contingencia para arrancar primeras fases del tratamiento y posteriormente al día siguiente, con una valoración también ya completa de la degradación del sistema auditivo izquierdo, se procedió al ingreso hospitalario inmediato. 

El tratamiento requería dosis fuertes de medicación una vez al día y la realización de una prueba relevante de diagnóstico por imagen con el objetivo de analizar el estado de situación de la zona del oído interno (donde residen los huesos más pequeños del cuerpo humano) mediante resonancia magnética.

Como dato relevante, con 48 años en este momento, no había pasado todavía en mi vida hasta esta fecha una sola noche ingresado en un hospital. Mantenía una ficha en blanco como usuario de la sanidad española en atención hospitalaria. Por tanto, todo lo que iba a vivir desde ese momento en adelante era nuevo para mi, visto desde dentro y no desde la posición de acompañante que había sido siempre mi rol en estos temas.

El proceso de gestión de incidentes llevado al ámbito de la salud.

A continuación pretendo ir reflejando algunas reflexiones que estuvieron en mi cabeza en cada momento y que ayudaron a una mejor canalización de todo lo que estaba pasando. Esta es la experiencia que comparto por si puede ser de ayuda a cualquier que haya llegado a leer hasta aquí. No ha sido fácil valorar el coste/beneficio de mostrar esta parte tan intima … pero si en algo puede ayudar, merecerá la pena.

Fase de detección.

Todo comenzó con un pequeño pitido en el oído, no muy molesto y una sensación de atenuación del sonido. Inicialmente creí que podría ser suciedad en el oído y acudí al médico para que lo mirara. En el contexto temporal, esto fue el evento 0 situado en el tiempo el día 1 de mayo de 2022. Tras comprobación y revisión no se detecta nada pero si parece que hay una pequeña inflamación y me administran antibióticos para 5 días. 

Esa misma noche, de madrugada, me despierto con gran sensación de mareo y angustia que provoca directamente tener que ir al baño a vomitar. El video que muestro a continuación simula perfectamente cómo veía todo al levantarme de la cama.

Tras llamar al médico de urgencias y administrarme medicación para el cese del vómito, al día siguiente de nuevo viene otro médico para valorar los nuevos síntomas y me proporciona medicación para el vértigo. Solo estaba tranquilo totalmente tumbado pero no podía ingerir alimento y casi nada de líquido porque enseguida lo volvía a vomitar. Según lo comentado por el doctor, en un par de días debía mejorar o habría que ver qué pasaba. Llega el miércoles, la cosa no mejora y la sensación de vértigo me impide andar con normalidad porque todo me da vueltas. Es en ese momento cuando noto ya de forma relevante una pérdida auditiva severa en el oído izquierdo y el acúfeno interno mucho más intenso. Consulto con mi hermano que es médico ( urólogo) y me comenta que ya hay que acudir a urgencias. La cosa no ha evolucionado y los síntomas ya no son algo llevadero. En este caso, contar con un asesoramiento especializado que valore los síntomas y establezca el nivel de urgencia fue esencial para atajar a tiempo los eventos detectados.

Como reflexiones respecto a la gestión de incidentes en esta fase de detección, es importante tener en consideración las siguientes cuestiones:

• Inventariar cualquier situación o evento significativo que adquiera carácter de anómalo o de indicio o sospecha vinculable al incidente. En la fase de detección hay que tratar de reunir la máxima información que permita en la siguiente fase un mejor diagnóstico.
• Tener o identificar criterios de severidad para decidir cuándo el incidente está evolucionando negativamente y va a requerir un escalado o una nueva valoración de la severidad. La toma de decisiones debe ser proporcional a los umbrales que se van identificando y debe estar clara cuál es la línea roja que activa la "contingencia" o "crisis". En mi caso, había síntomas que ya hacían necesario acudir a urgencias para escalar el diagnóstico de forma urgente y recibir una atención más especializada.

Fase de análisis o triaje.

El miércoles cuando me ven en urgencias me indican ya un posible diagnóstico rápido y comienzo con una medicación inicial de corticoides que es la forma de mitigar la inflamación que puede estar causando todo esto. Me citan a consulta al día siguiente para una valoración completa y la realización de una audiometría. Tenía dos dolencias simultáneas y no es habitual que se hubiera producido una pérdida de audición tan severa. 

Al día siguiente la audiometría constata la merma auditiva tan acuciante del oído izquierdo y tras valorar la prueba me informan que tienen que ingresarme. Como el motivo principal es la administración de altas dosis de corticoides, me dejan ir a casa e ingresar por la tarde para ya pasar noche en el hospital. Como he comentado antes, hasta la fecha no había estado ingresado y empezará ahí un descubrimiento del funcionamiento del entorno hospitalario desde el punto de vista del paciente.

He de decir que el persona sanitario es de admirar. La vocación y entrega al trabajo, el trato al paciente, la humanidad para empatizar con las situaciones de cada uno forman parte de su día a día. En mi caso el trato ha sido en todo momento exquisito y sólo puedo estar agradecido a todos los que he conocido. Tenemos una sanidad que es un tesoro y que habría que mimar más.

 

El jueves por la mañana, tras unas primeras extracciones de sangre para la realización de analíticas completas, me indican que voy a estar con altas dosis de corticoides y que tienen programada por protocolo para la semana siguiente (miércoles 11, el día D), una resonancia magnética. 

Con esta descripción de situación ya me hago una composición de lugar. Hay "evidencias" que me permiten saber cuál será el contexto de los próximos días aun sin todavía tener claro el diagnóstico. Hago inventario de "certezas" y valoro contexto y decisiones a tomar:

• Voy a pasar al menos una semana ingresado. Hay que planificar la logística con la familia para que las rutinas habituales y el día a día de mis hijos sea impactado lo menos posible.
• Las analíticas no tienen valores raros, salvo cuestiones relacionadas con la medicación. He de destacar aquí el papel que también ha tenido el acceso a los datos clínicos que permiten los sistemas de información del Servicio Murciano de Salud. Desde hace tiempo, tenemos vía aplicación movil o página Web acceso al portal del paciente. En este entorno, a través del servicio Ágora, el ciudadano tiene acceso a todos los informes y documentos clínicos que se van generando. Esto me permitía descargarme tanto las analíticas como los informes de valoración que me iban entregando en consulta. En cierta forma, iba pudiendo conocer resultados que luego los médicos me valoraban al pasar consulta. Esta accesibilidad ha sido un punto positivo a destacar.
• La resonancia es una prueba clave para el diagnóstico. Hasta ese día no se podrá conocer la gravedad del asunto y por tanto, toca esperar. Este quizás fue el punto crítico, porque la "severidad del incidente" según resultado podría dispararse a niveles muy altos. Es aquí cuando aparece en escena la palabra "tumor, normalmente benigno" como posible origen de un brote tan severo e inmediato. Hasta ese día no se podrá saber si el origen está vinculado con ese diagnóstico. 

Como reflexiones respecto a la gestión de incidentes en esta fase de triaje, es importante tener en consideración las siguientes cuestiones:

• Es esencial valorar la situación en base a los "hechos confirmados" y las "evidencias reales". En mi caso había potenciales hipótesis que podrían llevarme a escenarios más complicados... pero adelantar acontecimientos y situaciones futuras no iba a sumar. Por tanto, cabeza fría y ajuste de la valoración de la situación a lo que es "cierto en el momento en el que se decide todo". Es en ese momento cuando recurro a uno de las imagen-fuerza que me acompañarán estos días. Importa el hoy y el mañana. El pasado sirve para retroalimentar conductas y aprender de errores.

• Hay que asimilar rápido los cambios. El futuro no es como uno quiere sino como se presenta. Por tanto, es posible que tenga que convivir en el futuro con una merma auditiva. Tengo que empezar a valorar en qué va a afectar e iniciar los cambios que sean necesarios para poder convivir con esta nueva situación. Como acción inmediata ya he adquirido un nuevo monitor con altavoces y micro incorporado que ya no requiere utilizar cascos. Además al ser panorámico, minimiza el movimiento de cabeza y hace mucho más cómodo todo. Mi nuevo setup asegura una mayor ergonomía y comodidad en esta nueva situación.

• En relación a la gestión de incidentes, implica que hay que valorar qué se tiene y qué se debe conseguir tener para tener mejores herramientas en las fases siguientes del incidente, donde habrá que poner la carne en el asador: "contención, erradicación y recuperación". Qué bien me había venido también leer recientemente el libro de Maite Moreno "Gestión de incidentes de ciberseguridad" porque había repasado recientemente todas estas actividades. Yo conozco perfectamente la norma de referencia ISO 27035 porque en Govertis soy formador en esta materia. Doy clases de gestión de brechas de seguridad en los cursos a DPD de la certificación DPD de AEC y también he ido profundizando en la materia para dar soporte en consultoría tanto al diseño de procedimientos de gestión de incidentes/crisis como a ejercicios de escritorio Table Top Exercise (TTX) de los que ya he diseñado y ejecutado varios simulacros para organizaciones muy relevantes del ámbito nacional de sectores tan críticos como el energético o el financiero. Este "expertis" me estaba dando herramientas intelectuales de gestión de la situación de un valor incalculable. A esta mochila profesional tengo que añadir que en mi época universitaria también fui educador de los scout y tuve que enfrentarme a un par de accidentes severos con evacuaciones de emergencia que me hicieron ver cómo en situaciones de crisis, en vez de caer en pánico, surgía de mi una serenidad y una tranquilidad para tomar decisiones que no imaginaba poseer. Estas "soft skills" que no se enseñan, son capacidades que en ciertos momentos hacen muy diferente a las personas y sus reacciones.

• Comunicar la situación a partes interesadas directamente afectadas. Esta es una actividad de gestión del incidente que discurre en paralelo a las acciones técnicas de valoración y toma de decisiones pero "ESENCIAL" durante todo el proceso.  Tal como se determina en la norma de gestión de incidentes, es necesario realizar un inventario de "partes interesadas" y tener claro para cada una de ellas los siguientes puntos:
• Expectativas de comunicación y frecuencia de contacto.
• Canales de comunicación a emplear. 
• Mensajes

• En este caso, tuve de nuevo un golpe de suerte. El hospital es universitario y tenía desplegada la red Eduroam, por lo que tenía internet sin límite mientras estuviera ingresado. No me iba a faltar ancho de banda. Por ese motivo, me llevo la Tablet de mi hija al hospital que me permite tener aplicaciones de ocio y televisión pero la suite O365 para tener acceso a Teams y correo y poder seguir participando de algunas cosas que estaban en curso o apoyando a compañeros al menos en reuniones. Todo ello con la prudencia adecuada de evitar que estos comportamientos pudieran agravar la situación, pero no me habían contraindicado nada al respecto. Además estar activo me mantenía distraído e hizo que los días jueves, viernes, lunes y martes pasaran más rápido. Tenía la cabeza ordenando cosas del trabajo y la vida aprovechando la pausa forzada.
• Respecto al inventario de partes interesadas, era fácil:
• Familia: mis hijos fundamentalmente tenían que ver la situación como algo temporal, incomodo pero poco relevante. Debían verme como siempre pero sin poder tener contacto presencial. Por suerte hoy en día con la videollamada y la mensajería, el contacto es continuo y la "sensación de proximidad" puede ser tan intensa como se quiera.
• Jefes y compañeros: trasmitir la potencial duración de la situación para que se tomaran medidas de ajuste y mucho optimismo porque estaba todo controlado. En este caso además, recibía el apoyo tanto de ellos como de los compañeros con los que tenía interacción.

• En relación al uso de la tecnología, hay que maximizar los beneficios que nos proporcionan nuestros nuevos medios y las posibilidades que permiten de jugar con ellos. Para quitar hierro al asunto cuando hablaba con mis hijos (11 años) siempre usaba las capacidades de Facetime para gastarles bromas durante la conversación. Las situaciones no son realmente como ocurren sino como se perciben y el humor es una varita mágica que hace maravillas en este aspecto. El canal puede complementar al mensaje y condicionan mucho la percepción de lo que está ocurriendo.

 

Fase de contención, erradicación y recuperación.

Actualmente puedo decir que estoy en esta fase. Todavía tengo pendientes, en esta semana que entra, el paso por consulta para la realización de nuevas pruebas de valoración de la audición que proporcionará nueva información. En concreto, se identificará si hay una situación de estancamiento o de mejora y los siguientes pasos. En cualquier caso, en estos momentos lo importante es, de forma proactiva, hacer todo aquello que pueda suponer una mejora o permita avances en la recuperación. La actitud a mantener, dosificando fuerzas es siempre de ir subiendo escalones... porque con el tiempo, la distancia recorrida será mucha.

 

Como reflexiones respecto a la gestión de incidentes en esta fase de contención, erradicación y recuperación, es importante tener en consideración las siguientes cuestiones:

• Identificar los roles a involucrar en donde cada miembro sume su máximo potencial. No todos tenemos capacidades para todo tipo de actividades pero repartiendo bien los roles, se cubren muchos frentes y cada miembro del equipo de respuesta frente a incidentes (ERI) o gestión de crisis (Comité de crisis) puede aportar. Las capacidades requeridas en  estos equipos son muy variadas:
• Capacidades técnicas vinculadas al tipo de incidente y los conocimientos necesarios para tomar decisiones sobre las actuaciones de contención, erradicación y recuperación.
• Capacidades de gestión y tomas de decisiones.
• Capacidades de comunicación.
• Capacidades de realizar el seguimiento y registrar a modo de bitácora lo que va aconteciendo para posteriormente tener claro el time line del incidente.
• Capacidades de motivación y coordinación para gestionar al equipo, su cansancio y su descanso.
• Tener claro los criterios que deben priorizar la toma de decisiones en cada momento:
• Contención: cortar la hemorragia, resolver el problema o lograr minimizar tanto el tiempo de daño como sus consecuencias. El foco en esta fase se sitúa en parar cuanto antes la causa de daño. Cuando el incidente tiene naturaleza de "one shot", es decir, el impacto inicial es inmitigable, la contención en estos casos debe velar por poder contrarrestar los efectos negativos del incidente. En seguridad de la información, cuando hablamos por ejemplo de "fugas de datos" donde el daño se vincula a la confidencialidad, no existirá reparación posible. Lo que habrá en estos casos que valorar es la viabilidad, si fuera posible, de revertir o hacer caducar la información filtrada para que su impacto sea menor. Esto por ejemplo aplica en fugas de contraseñas o hashes donde el valor de la información lo proporciona la propia información pero ésta puede ser renovada o hacerla caducar.
• Erradiación: el foco aquí se centra en observar qué respuesta van teniendo las acciones que vamos tomando y si vamos logrando que la situación esté controlada y empecemos a revertir los daños. Según la naturaleza del incidente, en erradicación lo que buscamos es tratar de eliminar el origen y limpiar los entornos afectados haciéndolos llegar a un "estado de confianza" anterior al incidente que permita pasar a la fase de recuperación con garantías de no volver un paso atrás o con la tranquilidad de que el agente agresor ya no tiene control o posibilidad de acceso al entorno afectado. 
• Recuperación: con las fases anteriores ya finalizadas, en este momento se inicia la normalización al momento anterior al incidente para dejar las cosas como al principio. De nuevo, según la naturaleza del incidente, las acciones técnicas a realizar permitirán mas o menos lograrlo. Estará también esta fase condicionada por los resultados de las medidas preventivas y de recuperación que hayamos desplegado de forma previa y la fiabilidad de sus resultados. En esta fase es esencial la adecuada estrategia de backup que la organización hubiera establecido y sobre todo, las garantías de que este proceso fuera fiable y contara con garantías que eviten llegado a este momento, que lo que era una salvaguarda se convierta en un fracaso que aumente el impacto inicial del incidente. En muchos casos de ransomware el drama no llega cuando se detecta la afectación sino cuando se descubre que el backup está afectado y no podrá ser utilizado como salvaguarda.

Fase de lecciones aprendidas.

Finalmente, una vez acaba la batalla, pero sin dejar excesivo tiempo para el olvido, es importantísimo hacer el ejercicio de revisión y valoración de todo lo ocurrido. Es en parte el objetivo de todo esto que he escrito hasta aquí, y la forma de pasar página saliendo más fuerte. Cuando imparto formación en gestión de incidentes y la transición a crisis, me gusta siempre comenzar con esta imagen que describe bien lo que debe significar "lecciones aprendidas". En japonés crisis tiene dos símbolos con palabras que parecen antónimas: peligro/oportunidad. No había identificado hasta ahora lo cierto y relevante que es la palabra "oportunidad" vinculada a crisis. Como se suele decir, todo tropezón supondrá heridas... pero lo peor de todo sería no aprender.

La fase de “lecciones aprendidas” es de feedback completo sobre todo lo establecido y de identificación de desviaciones o ausencias relevantes que hayan podido condicionar la correcta ejecución. Es por eso que la flecha de feedback va desde "lecciones aprendidas" a "preparación", porque es en esa fase donde se realiza el diseño de todo el proceso y se describen todas las actividades del resto de fases.

 ¿Qué cuestiones se deben revisar en lecciones aprendidas?

El objetivo es garantizar que una siguiente ejecución tiene como punto de salida una mejor capacidad de respuesta a partir de lo ya ocurrido e identificado.  ¿Qué puntos se deben tratar?

Cuestiones vinculadas al proceso, la coordinación y la comunicación:

• Definición de roles, asignación clara de responsabilidades, localización de las personas, protocolos de coordinación.
• Revisión de actividades: En este caso, si se puede segmentar el análisis en las fases de gestión. Valorar qué hay que cambiar o mejorar respecto a:
• Detección.
• Análisis y valoración.
• Contención
• Erradicación
• Recuperación

Cuestiones técnicas:

• Valoración de herramientas: necesidades detectadas que no están cubiertas, entornos o herramientas que habrían supuesto una ayuda de haber podido contar con ellas.

Como vemos, esta fase debe generar un informe final de ajuste que permita la retroalimentación hacia todas las fases existentes realizando ajustes frente a desviaciones o ausencias de criterios o de oportunidades de mejora para limar fallos. A lo largo de este post me he ido ayudando de Liz Fosslien, una dibujante que tiene la capacidad de mostrar desde la sencillez los pensamientos clave que hacen robusto el proceso de mejora y superación. Tengo pendiente adquirir su libro porque como habréis podido comprobar, sus ilustraciones tienen una "energía de comunicación brutal". Para que la podáis tener localizada, esta es su web.

Toca terminar con esta imagen que también resumen bien todo lo anterior. En situaciones difíciles solo tenemos dos caminos: el bloqueo o pánico o la reacción serena para coger al toro por los cuernos y tratar de evolucionar para salir del agujero. No vas a poder cambiar los hechos pero si puedes controlar el cómo los vayas a afrontar. 

Tener unos pilares fuertes, una "familia" que actúa como red de cobertura y apoyo que hace fácil lo difícil y tratar en cada momento de sumar al máximo son las claves del éxito. En mi caso, todo ha sido viento a favor que ha hecho todo más llevadero... y ha generado una dinámica positiva que ha contribuido a acelerar para bien todo. 

 

Espero que esto sirva para dar herramientas a quien en algún momento se vea en situaciones parecidas o extrapolables a la experiencia contada. Nos gusta pensar que andamos por la vida atravesando grandes avenidas pero en realidad, cada paso que damos siempre lo hacemos en una cuerda floja. De repente la vida nos pone en contexto y nos hace ver "lo anómalo que es la tranquila normalidad que vivimos cada día". 

La vida nos fuerza en muchas ocasiones a parar. Con cierta sabiduría, creo que las cosas no pasan por azar sino que llegan en momentos que es necesario detenerse a reflexionar. En mi caso, estas tres semanas han sido de auditoría interna del camino recorrido y ha sido gratificante ver que solo hay “oportunidades de mejora” pero ninguna desviación ni no conformidad. Estoy donde quiero estar, con todo en su sitio y equilibrado. Hace días Bernardo Quintero escribía una frase que suscribo, “la vida me ha enseñado que se puede perder ganando y ganar perdiendo”. A lo largo de mi carrera profesional he tomado decisiones donde lo familiar o personal ha primado sobre lo profesional. Decidí salir de Madrid cuando no compartía ese ritmo acelerado de vida con mi carácter, salir de Almería trabajando para una  entidad financiera y aterrizar en una pyme para montar el area de seguridad de la información. Ahora, disfruto de mi ciudad, un entorno tranquilo donde mis hijos tienen sus rutinas, van a mi mismo colegio y tienen un ambiente adecuado. Estas cosas no tienen precio… pero sigo trabajando en lo que me gusta, con cada día más vocación y pasión y ahora, en Govertis/ Telefónica Tech con proyectos increíbles de altísima complejidad que jamás habría podido soñar tener y sin salir de casa. Hay que valorar lo que se tiene y disfrutarlo. Como dice el proverbio popular "No hay paraíso hasta que se ha perdido".

Digitalizar o informatizar, esa es la cuestión.

Una de las cosas más bonitas que tiene el trabajo del consultor de seguridad es que te permite visitar todo tipo de organizaciones y analizar modelos de negocio muy variados. A lo largo de los diferentes proyectos que me ha tocado ejecutar he podido ver sectores tan dispares como el hotelero o el militar, empresas de fabricación de productos alimenticios o de desarrollo software. 

La presente entrada tiene que ver con reflexiones sobre la vital importancia que tiene hoy en día la gestión de información. Es obvio que todas las empresas se han planteado ya la incorporación de nuevas tecnologías a sus procesos de negocio. Sin embargo, desde la visión de un consultor externo se puede observar cómo en algunos casos el proceso de adaptación se ha quedado en la superficie en muchos casos y en otros cómo ha llegado a cambiar el modelo de negocio por completo.

En todo proyecto tanto de construcción de un sistema de gestión de la seguridad de la información como de protección de datos de carácter personal como de continuidad de negocio siempre el trabajo que toca hacer es el "modelado de la organización". Para ello, el habitual punto de partida suele ser emplear el modelo de la cadena de valor de Porter y tratar de identificar cuales son las actividades primarias y de soporte de esa organización. Cuando tienes suerte y la empresa ya está certificada bajo el esquema ISO 9001 gran parte del trabajo suele estar muy avanzado dado que ya se puede partir de un mapa de procesos que debe definir qué hace esa empresa y cómo logra satisfacer las necesidades de sus clientes. Sin embargo muchas veces ocurre que lo pintado por el manual de calidad dista bastante de la realidad operativa de la empresa. Por desgracia hay sistemas de gestión de la calidad que sólo sirven para ostentar una certificación pero para nada implantan la cultura de la mejora continua dentro de la organización.

En la fase de análisis de riesgos, de análisis de impacto en el negocio o de identificación de los tratamientos de datos de carácter personal el consultor debe analizar para cada empresa cuales son los flujos de entrada de información, los procesos de transformación y las salidas que se producen. En Ingeniería del software durante la carrera nos enseñaban que había que identificar en abstracto todos estos intercambios de información para poder definir el modelo de datos. Para ello empleábamos los diagramas de flujos de datos que son una manera normalizada de definir y diagramar todas estas relaciones entre elementos importantes del sistema de información.

En teoría, la incorporación de las tecnologías de la información en todas las organizaciones debería haber supuesto la elaboración de estos planos de identificación de los procesos de negocio y de las necesidades de información de cada uno de ellos para establecer la mejor manera de incorporar los nuevos canales y las nuevas capacidades operativas que optimizaran los procesos y lograran una mayor eficiencia. Eso hubiera sido "informatizar" la organización. Sin embargo, en muchos casos la incorporación de las tecnologías simplemente ha supuesto la incorporación del correo electrónico como mecanismo de intercambio de información, la creación de una Web para publicitar y anunciar los productos o servicios y la sustitución de máquinas de escribir por ordenadores que generan documentos ofimáticos que se almacenan en servidores de ficheros.  Eso es lo que podemos denominar "digitalizar" la organización. Esta es la infraestructura más común que ves en empresas que dicen haberse adaptado al siglo XXI. No se puede negar que estos cambios suponen avances pero ello no implica en el día a día una mejora significativa del rendimiento y la productividad de la organización. En muchos casos, al aumentar el caudal de la información procesada, se ha incrementado la carga de trabajo y al no estar rediseñados los procesos de negocio, los canales telemáticos suponen un cuello de botella. Eso ocurre tradicionalmente con el correo electrónico. Otro de los grandes errores es la ausencia de criterio en la gestión electrónica de documentos, lo que hace del servidor de ficheros un gran repositorio de datos no indexados ni adecuadamente organizados que impide la gestión eficiente de la información en soporte electrónico. La búsqueda de documentos se convierte en una pesadilla porque hemos trasladado los criterios de gestión del papel basados en archivadores y carpetas a la gestión electrónica de documentos, no aprovechando la potencia que implica el uso de metadatos y la categorización de contenidos según cuadros de clasificación documental. Supongo que llegado este punto se puede entender cómo en muchos casos la incorporación de las tecnologías simplemente ha supuesto un cambio de formato respecto al contenido, un proceso de transformar en digital lo que se hacía en soporte papel de forma tradicional.

¿Qué habría sido informatizar la organización?

En primer lugar y tal como empezaba esta entrada, un ingeniero en informática lo que sabe hacer bien es identificar los flujos de información y los procesos de transformación de datos. Debe ser capaz de representar de forma visual el modelo de negocio e identificar los diferentes tipos de documentos, el tipo de datos que se manejan, los repositorios donde se almacenan, etc. Debe construir un modelo de gestión de la información que debe describir qué hace esa empresa y cómo se generan los productos o servicios que forman la cadena de valor de esa organización. Con esos planos, la segunda fase es el rediseño de procesos para adaptar la incorporación de los nuevos medios electrónicos y tratar de automatizar cuando sea posible la recogida y almacenamiento de información para su posterior procesado. Algo que forma parte de la columna vertebral del proceso de administración electrónica que debería estar cambiando el modelo de gestión de las Administraciones Públicas para mejorar en eficiencia y operatividad proporcionando un mejor servicio al ciudadano.

Muchas organizaciones grandes si han tenido que pasar por esta fase de revisar y adecuar sus actividades al uso de las tecnologías cuando han incorporado a su corazón de gestión las aplicaciones de ERP (Enterprise Resource Planning) como Navision, SAP, etc... En muchos casos estos productos ya vienen con un mapa estandar de procesos según el sector y la empresa realmente lo que hace es adecuarse al software en vez lo contrario pero ello en muchos casos se fundamenta en que el modelo de gestión propuesto por el software ya se encuentra muy consolidado y optimizado para ser la forma más eficiente de gestionar.

De identica forma, la informatización también debe identificar cómo gestionar la información en soporte electrónico siendo la gestión documental una pieza clave que permita la iteracción entre las aplicaciones de negocio y la gestión de documentos electrónicos, aprovechando las capacidades de este tipo de herramientas y utilizando su verdadero potencial cuando existe una gestión adecuada de los metadatos vinculados.

En este sentido y dentro de las tendencias de Gobierno TI, parece que empieza a cuajar lo que denominan "Enterprise Architecture" o Arquitectura empresarial que sería esos "planos de la organización" desde la visión de procesos de negocio, aplicaciones y artefactos o recursos informáticos que dan soporte a los sistemas de información. Esta forma de modelar organizaciones está pensada para que todas las capas de la misma puedan utilizar este tipo de planos para adecuar los sistemas de información a las necesidades de negocio.

Estos planos se establecen en capas y permiten desde cada una de ellas subir o bajar en detalle para conocer con exactitud a qué se da soporte o qué recursos necesita.

Formalmente se puede definir la "arquitectura empresarial como que es la lógica de la organización de los procesos de negocio y la infraestructura de TI que refleja los requisitos de integración y normalización del modelo de funcionamiento de la empresa. El modelo operativo es el estado deseado de la integración de procesos de negocio y la estandarización de procesos de negocio para la entrega de bienes y servicios a los clientes."

Esto que suena tan bonito se puede llegar a tangibilizar en esquemas como el siguiente y que permiten a todos los actores de una gran organización conocer exactamente que se hace y qué dependencias y recursos requiere la empresa para funcionar.

El resultado de una adecuada consultoría en seguridad o protección de datos a veces tiene como efecto positivo y colateral el suministrar este tipo de resultados y permitir a la organización identificar deficiencias operativas u oportunidades de mejora que pueden lograr una mejor eficiencia operativa o una mayor robustez de sus sistemas de información frente a los potenciales riesgos que pudieran plantearse. Como conclusión final quería comentar que efectivamente en muchos proyectos uno entra para diagnósticar situaciones y acaba proporcionando una visión completa de qué hace la organización que permite que la comunicación entre Dirección y el área de sistemas de información pueda ser mas fluida. Permite que tanto desde arriba (Top management) se puede visualizar la cantidad de recursos técnicos que son necesarios para soportar a los procesos de negocio como justificar o evidenciar la importancia de determinados recursos técnicos por su vital papel dentro de la posible cadena de fallo y de los impactos potenciales que pudieran ocasionarse en caso de incidentes sobre los procesos de negocio. Aunque los proyectos tienen como objetivo la seguridad, en muchas ocasiones se tienen como resultados colaterales una mejora de la eficiencia operativa o el diagnóstico de puntos de fallo que pueden comprometer la cadena de valor de Porter.

Clasificación de información e ISO 30301, en busca del santo grial.

Llevo un tiempo sin prodigarme en el blog pero hay momentos en los que toca estudiar para seguir ampliando conocimientos. Además, ultimamente ando curioseando otras ramas de las ciencias ajenas a la seguridad pero con las que hay sinergias que pueden contribuir a trasladar modelos que permitan la solución a muchos de nuestros problemas.

Desde el año pasado existe la norma ISO 30300 sobre la gestión documental que proporciona viento fresco a los que nos dedicamos a su protección. Cada día soy más consciente de que el término "información" engloba un conjunto de definiciones que aun siendo similares, representan conceptos diferentes y de relevancia distinta. Los que nos dedicamos a la "seguridad de la información" según el caso y el tipo de documento podemos ser los garantes del conocimiento y la sabiduría de una empresa. El nivel de comprensión y el contexto en el que son analizados los datos, van elevando su altura y relevancia.

Uno de los grandes retos de la seguridad de la información es que por desgracia, carecemos de cultura de gestión de la información y por tanto, algunas de las medidas a implantar como controles ISO 27002 son duros de llevar a la práctica porque implican un cambio organizativo y cultural importante. Como es un tema que sufro de forma continua he tratado de buscar referencias que pudieran ayudarme y el haber tenido una compañera documentalista ha sido un gran lujo porque me ha tenido siempre bien informado y me ha hecho ver el tremendo papel que juegan los documentalistas en toda organización. Hace meses me habló de la norma ISO 30301 que pretende ser para la gestión documental lo mismo que ISO 27001 es para la seguridad de la información. Además, tenemos la suerte de que esta norma se ha cocinado bastante en España y tenemos a grandes expertos de la materia haciendo difusión de esta norma. Me han dado la oportunidad de contribuir como redactor en el blog www.iso30300.es  y eso esta permitiendo intercambiar enfoques e impresiones respecto a cómo abordar aspectos comunes entre las normas ISO 27001 e ISO 30301. Al fin y al cabo no puede haber "gestión de la documentación" sin seguridad, pero tampoco puede haber "seguridad de la información" sin gestión de la documentación. Mi primer articulo está enfocado a plantear cómo puede definirse un criterio de clasificación que contemple los requisitos legales establecidos y a la par sea algo manejable, aplicable y real para una implementación en cualquier tipo de organización. El post por largo ha sido dividido en estos dos trozos:

• El control A.7.2. "Clasificación de la información" de la norma ISO 27001 y la norma ISO 30301. (Parte 1)
• El control A.7.2. "Clasificación de la información" de la norma ISO 27001 y la norma ISO 30301. (Parte 2)

Todavía no hay respuesta en la búsqueda de este santo grial, pero seguro que una solución mixta entre el mundo de la gestión documental y la seguridad de la información será mas completa y acertada que desde una visión parcial donde la protección prima por encima de cuestiones operativas. Ambas normas, ISO 27001 e ISO 30301 deben resolver la cuestión y nos toca ahora plantear un cuadro de clasificación de documentación que pueda servir para resolver el tema. En lo que respecta al marco jurídico, la legislación tanto de protección de datos de carácter personal como de Administración electrónica ya ha puesto nombre y apellidos a los criterios de clasificación, puesto que define 3 niveles: Alto, Medio y Básico. Ahora toca establecer los requisitos para definir todo el ciclo de vida de la información: recogida, clasificación, tratamiento, almacenamiento, transporte, desclasificación y destrucción.

El Tsunami tecnológico que no pudimos evitar (Actualización)

Este post quiero dedicarlo a mi fuente de inspiración, la mesa redonda "Encuentro de blogueros de seguridad 2012" del evento ENISE de Inteco donde no he podido estar y donde estos cinco compañeros blogeros y "monstruos de la seguridad" a los que admiro han sabido transmitir con precisión cual es la sensación que tenemos los profesionales de la seguridad y sobre todo, nuestras inquietudes respecto a lo que habría que hacer y no estamos afrontando. Los figuras han sido Alonso Hurtado @ahurtadobueno, Samuel Linares @Infosecmanblog, Román Ramírez @patowc, Antonio Ramos García @antonio_ramosga y Pablo Teijeira @JpabloTG han expuesto desde diferentes puntos de vista (economista, abogado, informático, consultor, fabricante medidas de seguridad) qué cosas deberían empezar a preocuparnos.
[Actualización]
Inteco hoy ya permite el acceso a las diferentes charlas y mesas redondas en la dirección http://6enise.webcastlive.es/ . En concreto, la Mesa de bloggeros a la que estaba invitado pero no pude asistir, puede verse en este enlace. [/Actualización]

Voy a tratar de resumir las constantes reflexiones que durante la charla bullían en mi cabeza mediante el siguiente relato.

"Diario de un consultor de seguridad de la información. Hoy es 23 de octubre de 2020 y ya puedo contar lo que hemos tenido que padecer durante estos dos últimos años.

23 de octubre de 2018. Este fue el día 0, el comienzo de una nueva era en la evolución de la humanidad. Tras unos pocos años de respiro tras una crisis económica global que vino como un tsunami, la tecnología fue una segunda ola con impactos devastadores. Para poder explicar qué paso trataré de hablaos un poco de la situación anterior al día 0, el Pearl Harbour cibernético. La sociedad del año 2012 iba muy acelerada. Los cambios eran continuos y muy rápidos lo que daba poco tiempo a reflexionar sobre la evolución del contexto y entorno que se estaba produciendo. Las redes sociales lo habían inundado todo, las empresas veían en las nuevas tendencias tecnológicas basadas en la cloud y la virtualización las oportunidades para lograr una reconversión tecnológica y poderse adaptar a los cambios. De repente habíamos descubierto que la información en si mismo es una materia prima que llevabamos años recolectando pero que no habíamos sabido explotar. Las tecnologías incipientes relacionadas con el big data ahora nos permitian tranformar datos en información y con ésta lograr conocimiento que mejoraba los rendimientos y resultados de los negocios. Parecía que estabamos por fin sabiendo surfear la ola de las tecnologías de la información y dirigirnos con rumbo acertado hacia la optimización de los procesos de negocio para lograr la máxima eficiencia que jamás habíamos conocido. Sin embargo, y pese a las advertencias de algunos profesionales de la seguridad de la información  de aquella época, la gran ola llegó para arrasar con todo. Durante los años anteriores, principios de 2010, se empezaba a advertir como una nueva realidad lo que ya se venía anunciando en los años 90. Cuando el mundo del crimen organizado aterrizara en el ciberespacio las cosas se iban a poner muy feas.

Y tuvo que pasar para que nos creyeran al verlo con sus propios ojos. No habíamos hecho las cosas a tiempo y no habíamos querido frenar aquella vorágine evolutiva que nos llevaba a un ritmo trepidante, modificando nuestras organizaciones continuamente sin preguntarnos si quiera si todo aquello tenía unos cimientos adecuados para aguantar tanto peso.  Lo cierto es que algunas cosas se habían intentado. Teníamos una legislación muy básica en materia de protección de datos que obligaba a establecer al menos los mecanismos más elementales de protección. Posteriormente llegaron casi al mismo tiempo las regulaciones en materia de Administración electrónica para el sector público y la legislación en materia de infraestructuras críticas. Pero no íbamos a cambiar, venimos de una cultura latina donde siempre las cosas de seguridad están en un segundo plano, donde el "nunca pasa nada" era la frase consuelo que hacía de venda en los ojos para mirar a otro lado. La informática nunca quiso ser vista como una  ingeniería. Aunque en las facultades se formaba a profesionales para que aplicaran metodologías de desarrollo, se validaran los programas, se formalizaran las pruebas, en definitiva, se creara un producto robusto y estable, aquello penalizaba la rentabilidad de las empresas del software y no era la práctica habitual. Solo las grandes ya habían descubierto que esa manera de generar código era la única viable para dar soporte al ciclo de vida del software. La crisis también tuvo bastante que ver porque fue la cazuela perfecta en donde cocinar todos estos ingredientes: excusas por falta de recursos, saltos al vacío para ahorrar costes y mirar a la nube como la panacea de las TI, carencias de normas de regulación tecnológica que al menos forzaran a unos procesos de desarrollo y fabricación de tecnologías más robustos y sobre todo, la extensión general de que las responsabilidades no son aplicables a las tecnologías de la información y que el "error informático" es un ente sin nombres y apellidos que siempre está en todas las consecuencias pero que no tiene un padre que determine cual es la causa y sobre todo el culpable. En todos los productos tecnológicos era una práctica habitual que aparecieran las cláusulas de "irresponsabilidad" que son todas aquellas cláusulas de responsabilidad que empezaban diciendo "este producto se entrega como está y el fabricante no se responsabiliza de nada". 

Contado ahora en el 2020 suena a locura pero en aquellos años era habitual. No habíamos aprendido que de igual forma que para la fabricación de vehículos, electrodomésticos y edificios debían primar en los criterios de diseño la seguridad, en la tecnología se hacía la vista gorda y nadie preguntaba nada si aquello se ponía a funcionar y no daba muchos problemas. Y esa invisibilidad de la amenaza, esa falta de criterio del cerebro humano para predecir amenazas invisibles y sobre todo, no naturales, que no generan miedo porque es complejo predecir los peligros físicos, visibles y tangibles que nos pueden ocasionar tuvo como efecto un engaño, una ilusión de la seguridad, una falta de percepción del riesgo indirecto que sin saberlo estábamos asumiendo. La ola del tsunami se había empezado a levantar pero nadie fue capaz de adivinar hasta que altura llegaría. Es una ley de la naturaleza, la selección natural. Lo cruel es que esta vez se aplicaba sobre nuestra especie y además por fenómenos provocados por nosotros mismos. Nuestra incapacidad para detectar los peligros que generaba el incremento de complejidad en los sistemas que estábamos construyendo y sobre todo, la interdependencia de muchos de ellos entre si, no nos permitieron ver que todo nuestro ciberespacio era un conjunto de fichas de dominó puesto en fila una tras otra y que en cuanto alguien con intenciones concretas y dañinas tirara la primera piedra, el resto caerían sin control y freno. No habíamos ni siquiera previsto cortafuegos entre piezas para que al menos los sistemas críticos no cayeran todos de golpe.

A estas alturas os preguntaréis qué fue lo que ocurrió. Pues vino a pasar que una de esas piezas de la fila del dominó cayo y debido a la alta dependencia que habíamos alcanzado de la tecnología, llegó una situación de caos total que tuvo consecuencias físicas muy graves. La causa podría  haber sido otra cualquiera, seguramente los daños habrían sido diferentes pero las consecuencias para la humanidad, similares. En los años 2011 y 2012 ya se habían producido los primeros incidentes serios de amenazas APT en sistemas industriales. El malware había evolucionado y su sofisticación ya era importante. Las estrategias antimalware seguían evolucionando pero existía ya una industria del Zero-Day que alimentaba bases de datos de vulnerabilidades que ni siquiera ya gestionaban los fabricantes. El día D para producir el Pearl Harbour cibernético se estuvo cocinando durante meses. En una primera fase, se estuvo propagando por la red un malware complejo, sin actividad aparente y sin patrones de tráfico predecibles. Se enmascaraba bien entre el ruido del tráfico habitual de cualquier organización y por tanto, no había sido detectado. Tampoco tenía actividad visible por lo que en esta fase su objetivo era simplemente la dispersión. Cual plaga en esta primera fase solo pretendía crecer y extenderse. En una segunda fase y ya como un elemento común en la red de usuarios de PC y tablets, este malware se transformó y mutó su código para rediseñarse y poderse propagar en lo que sería su objetivo final, los sistemas SCADA. Para ello, hubo un intenso trabajo de inteligencia que se dedicó a recorrer las redes sociales más conocidas y profesionales con el objetivo de localizar aquellos profesionales vinculados a sectores industriales donde pudieran existir estos sistemas SCADA vulnerables. La infección de equipos de usuarios era selectiva y vinculada al perfil profesional del infectado. El malware se instalaba, rastreaba cualquier tipo de dato de carácter personal que permitiera identificar al dueño del ordenador y consultaba su perfil en las redes sociales para decidir si se quedaba o saltaba a otro equipo. Siempre como regla general se instalaba en cualquier dispositivo USB conectado a ese hardware porque era la forma más facil de seguir contaminando el mundo. En una tercera fase, pocos minutos antes de la hora D, las 00:00 del  23 de octubre del 2018, el malware modificó la configuración de los sistemas de referencia horaria y en aquellos sistemas informáticos que empleaban la sincronización basada en GPS alteró los parámetros para apuntar al sistema bajo el control de atacante. A las 00:00 del día D, el malware modificó la referencia horaria de todos los sistemas infectados haciendo viajar en el tiempo a todos los equipos hasta el año 2038, el conocido como Y2K38 que era conocido pero del que todavía no se había empezado a remediar nada dado que quedaban 18 años por delante. Este problema afectaba a los programas que usaban la representación del tiempo basda en POSIX que se basa en contar el número de segundos transcurridos desde enero del 1970 a las 00:00:00.  Era una lacra de diseño de sistemas antiguos que nunca había sido modificada porque nadie había podido pensar que fuera a generar consecuencias tan desastrosas. Ese día, a las 00:00:00 los sistemas de control de infraestructuras críticas como la energía eléctrica, el sistema de posicionamiento global GPS, el control de la cadena de suministro de gas y petróleo dejaron de funcionar produciendo como efecto en cascada la caída del suministro eléctrico en ciudades. Ya disfrutábamos del Internet de las cosas y en el ámbito doméstico la mayoría de aparatos dejaron de estar operativos. Además, los sistemas alternativos y redundantes también padecían dicho fallo y no pudieron ponerse en servicio. Se había tratado siempre de proteger la primera linea de defensa, la cadena de suministro operativa pero en el problema del Y2K38 nadie había mirado tampoco si los sistemas alternativos podrían superar este error. 

Después de aquello y tras algunos meses para poder volver a la normalidad todo cambió. Los políticos, responsables de grandes corporaciones y los grandes accionistas de las importantes multinacionales entendieron que el mundo había sido construido sobre la tecnología e Internet, pero que sus cimientos eran simples palillos apoyados en tierras movedizas que no daban garantía de nada. Todo cambió. Entendieron entonces que la inseguridad no era un tema de costes sino de impactos. No estaba en cuestión el acierto en los criterios de tolerancia al riesgo sino de supervivencia de la humanidad. Ese fue el día en el que por fin se entendió que la tecnologia necesitaba la misma seguridad industrial que el resto de elementos que hasta esa fecha habían sido empleados para la construcción del mundo. Ya no era importante el poner en servicio sino garantizar que todo producto era diseñado para resistir y que además superaba determinadas pruebas de estrés y resiliencia. Y los cambios que hubieron que hacer no fueron tan complejos. Simplemente se prohibieron las cláusula de irresponsabilidad del software. Todo fabricante de cualquier producto tecnológico, software o servicio TI debía superar procesos de homologación y validación industrial previo a su comercialización, asumiendo el fabricante el coste de la inseguridad generada si era demostrado que el sistema tenía fallos que no habían sido gestionados. Además, se obligaba a todo fabricante a suministrar planes de mantenimiento y actualización de sus productos frente a posibles vulnerabilidades descubiertas y a no superar una ventana de tiempo de un mes para la resolución y cierre de estas vulnerabilidades. Obviamente el sector TI sufrió bastante con estos cambios, pero como cuenta la "teoría de la evolución" solo los fuertes sobrevivieron. Justo o injusto, no podíamos permitirnos la existencia de débiles en la cadena de suministro TI que volvieran a hacernos pasar por otro día D. Se tuvo que sacrificar la velocidad y la vorágine de nuevos avances por una mayor estabilidad, sosiego y sobre todo, valoración de los riesgos que estos nuevos entornos estaban contemplando. Ese día dió la razón a todos aquellos que ya habían venido anunciando que lo que se veía en los escenarios de la seguridad informática eran solo la punta del iceberg de los problemas reales que podría suceder. Y tuvo la humanidad de nuevo que vivir un nuevo Titanic TI para darse cuenta de que esos icebergs, pese a querer borrarlos o ignorarlos, estaban ahí y podían tumbar toda nuestra tecnología. Ese día el ser humano volvió a aprender que prevenir el riesgo siempre es más barato que recuperarse de impactos por no haberlo evitado, que la seguridad es un elemento intrínseco en el proceso de diseño y que las cosas deben pensarse con criterios de seguridad, es decir, no pensar cual sería el uso adecuado y funcional del producto sino cuestionarse dado un entorno, cual sería el eslabón más débil  por donde nos querían atacar. Emplear la psicología de la seguridad en todo momento donde lo que siempre está en cuestión no es si el sistema trabaja correctamente sino valorar por donde podría fallar o en dónde podría ser vulnerable. Una mentalidad defensiva basada en la evidencia de que si tiene una IP, podrá ser accesible en algún momento para personas con no buenas intenciones.

De nuevo la naturaleza nos daba muestras claras de que nos aplicaban las mismas leyes que en la selección natural."La cebra tiene que ser más rápida que el más rápido de los leones pero el león tiene que ser más rápido sólo que la más lenta de las cebras". Esta vez, los leones de la inseguridad nos habían ganado la partida porque no quisimos parar las máquinas a tiempo, frenar un poco para mejorar la resiliencia de nuestros avances tecnológicos porque habríamos desacelerado o frenado la vorágine de la innovación. Y como el ser humano no fue capaz por si mismo de autoprotegerse, tuvieron las matemáticas del caos que entrar en acción y demostrar que en sistemas complejos, un pequeño aleteo de una mariposa en Nueva York puede producir un tsunami en la costa de Japón.

Llegado este momento, perfectamente podrían encenderse las luces del cine, levantarnos e irnos a casa. Sin embargo y seguramente con otras hipótesis, muchas de las cuestiones aquí planteadas podrían ser reales en estos años o años futuros. A los profesionales de la seguridad de la información, que somos como los mecánicos de la Formula1 respecto al funcionamiento de la organización que sería el propio coche, se nos pide a diario que detectemos anomalías y problemas estructurales pero no parando el coche en boxers sino cuando está circulando en plena carrera. En esos escenarios, siempre somos una molestia porque no estamos para aportar valor sino para garantizar que el coche llegue a meta. Sin embargo, de no hacer bien nuestro trabajo, lo que corre peligro es la vida del piloto. Es nuestro contexto, es nuestro entorno y es nuestra misión seguir detectando y alertando de las consecuencias que podrían producirse. No nos gusta ser los aguafiestas en las empresas... pero, y valga como reflexión la actual crisis económica, ahora nos preguntamos todos por qué nadie nos avisó. Quizás si lo hicieran pero nadie quiso parar la música en plena fiesta de bonanza económica. Además, el ser humano no puede cambiar tan rápido. Nuestro cerebro lleva siglos evolucionando y no es capaz de plantearse amenazas virtuales, invisibles, intangibles. No es capaz de calibrar las consecuencias de fenómenos en cascada hasta que no hay signos visibles de peligro. Se siguen invirtiendo ingentes cantidades de dinero en seguridad para el mundo físico pensando en proteger un perímetro de un territorio cuando en el subsuelo, por el inframundo, los países eliminaron hace años sus fronteras para interconectarse entre sí a Internet. En un mundo global y conectado, los atacantes no vendrán por la superficie montados en tanques... lo harán desde los sillones de su casa o de los edificios gubernamentales donde trabajen usando su PC. Y además por varios motivos: son más dificiles de detectar, es más barato el desarrollo de operaciones y sobre todo, asumen menos riesgos físicos. Si el ataque no prospera las víctimas son cero porque simplemente no se logra la intrusión. No hay un desgaste o deterioro para el atacante que de nuevo puede volverlo a intentar por otro lugar o en otro momento. Sólo tiene que esperar a buscar el sistema-cebra más lento, en este caso, el menos parcheado, vigilado y protegido.
Ojalá que este texto quede solo en relato, que ese dia D siga siendo algo fictício y que la IN-seguridad de la información jamás cueste una vida humana. Sin embargo, los datos y las diferentes noticias del día a día a los que estamos vigilando y siguiendo la evolución de esta nueva realidad no nos llevan a ser muy optimistas. El malware se extiende y cada vez a sectores más críticos. Hace unos días se publicó la noticia de la  preocupación que hay ya por el salto del malware a los dispositivos médicos, software normalmente cerrado, sin actualizaciones y con sistemas operativos antiguos y sin parchear que podéis consultar en  Computer Viruses Are "Rampant" on Medical Devices in Hospitals. Esto empiezan ya a ser palabras mayores al igual que todo aquello que afecta a infraestructuras críticas. Esperemos que en estos temas no sigamos usando la cultura del "escaparate" donde sólo nos preocupamos por aparentar y no realmente solucionar las cosas. Esperemos no aplicar la misma filosofía que se emplea con la legislación tecnológica basada en el "CUMPLI-MIENTO", entendido como decir que se cumple aunque sea mentira. El mundo del cibercrimen es una realidad, sólo hay que mirar un par de post atrás para ver el documental de En portada.

  Y para finalizar este extenso post,  lo más curioso es que una historia similar  ya había sido escrita para explicar otro fenómeno descontrolado del poder del hombre basado en la ficción de poder volver a crear dinosaurios en base a su ADN. En este caso, el papel de agorero que anunciaba los riesgos lo había asumido, bajo las teorías de las matemáticas del caos y el no control de la naturaleza, el papel de Malcom. Quiero extractar a continuación el párrafo en cuestión donde el matemático del Caos, Malcolm comenta con el dueño del Parque, Hammond por qué la naturaleza no puede ser controlada y cómo había sobredimensionado el poder de la ciencia:

 “—¿Sabe qué es lo que tiene de malo el poder de la ciencia? —prosiguió—. Que es una forma de riqueza heredada. Y ya sabe usted cuan imbécil es la gente congénitamente rica. Nunca falla. —¿De qué está hablando? —preguntó Hammond. Harding hizo un gesto, indicando delirio. Malcolm le lanzó una mirada. —Le diré de qué estoy hablando —contestó—: La mayor parte de las distintas clases de poder exigen un gran sacrificio por parte de quien quiera tener ese poder. Hay un aprendizaje, una disciplina que dura años. Cualquiera que sea la clase de poder que se busque. Presidente de la compañía. Cinturón negro de karate. Gurú espiritual. Atleta profesional. Sea lo que sea lo que se persiga, hay que ponerlo en el tiempo, en la práctica, en el esfuerzo, hay que sacrificar muchas cosas para lograrlo. Tiene que ser muy importante para uno. Y, una vez que se alcanza, es el poder de uno mismo; no se puede delegar: reside en uno. Es, literalmente, resultado de nuestra disciplina. Ahora bien: lo interesante de este proceso es que, en el momento en que alguien adquirió la capacidad de matar con sus manos, también maduró hasta el punto en que sabía cómo utilizar ese poder. No lo utilizaría de manera imprudente. Así que esa clase de poder lleva una especie de control incorporado: la disciplina de conseguir el poder cambia a la persona, de manera que esa persona no hace mal uso de su poder. Pero el poder científico es como la riqueza heredada: se obtiene sin disciplina. Una persona lee lo que otras hicieron, y da el paso siguiente. Puede darlo siendo muy joven. Se puede progresar muy de prisa. No hay una disciplina que dure muchas décadas. No hay enseñanza impartida por unos maestros: se pasa por alto a los viejos científicos. No hay humildad ante la Naturaleza. Sólo existe la filosofía de hacerse-rico-pronto, hacerse-un-hombre-rápido. Engañar, mentir, falsificar, no importa. Ni para uno ni para sus colegas. Nadie nos critica: nadie tiene pautas. Todos intentan hacer lo mismo: hacer algo grande, y hacerlo rápido. Y, como uno se puede levantar sobre los hombros de los gigantes, se puede lograr algo con rapidez. Uno ni siquiera sabe con exactitud qué ha hecho, pero ya informó sobre ello, lo patentó y lo vendió. Y el comprador tendrá aún menos disciplina que el científico: el comprador simplemente adquiere el poder, como si fuera cualquier bien de consumo. El comprador ni siquiera concibe que pueda ser necesaria disciplina alguna. Un maestro de karate no mata gente con las manos desnudas; no pierde los estribos y mata a su esposa. La persona que mata es la que no tiene disciplina, no tiene restricciones, y que salió y adquirió su poder como una dosis de droga. Y ésa es la clase de poder que la ciencia fomenta y permite.”

Seguridad en la nube

La cloud computing es el tema de moda de este año y empiezan ya a publicarse estudios y documentos interesantes que tratan de enfocar el tema en materia de seguridad. Desde luego que la Cloud no sería posible sin una tecnología previa de gran importancia como es la virtualización pero además y como se comenta en casi todos los foros, no es algo nuevo. La "cloud computing" es un nuevo apellido a una serie de servicios tecnológicos que en los primeros tiempos del despliegue de Internet en España, cuando el principal negocio era el acceso y los proveedores de servicios ISP (Internet Service Provider), algunos ya planteaban nuevos modelos de uso de software basado en el alquiler ASP (Aplication Service Provider). En aquel primitivo escenario, el cliente se planteaba poder disfrutar del uso de una aplicación muy cara bajo regimen de alquiler y teniendo a su disposición un servidor (propio o compartido) alojado en un proveedor de acceso a Internet. Es evidencia de aquel momento y aquellos planteamientos un artículo que publicó mi jefe en Innosec, Gustavo San Felipe (Actual CISO en Acens) donde hablaba de la problemática de la seguridad en entornos donde los clientes compartían recursos y de las necesidades de garantizar servicios por parte del proveedor. Aquello era el año 2000 y se publicó en la Revista Nº40 de SIC.

Aunque el escenario ha cambiado, sobre todo incrementándose en complejidad, en el fondo se plantean las mismas inquietudes de aquel momento, la responsabilidad y confianza que se puede depositar en un servicio tecnológico remoto relevante.

A estas alturas ya han ido apareciendo diferentes documentos que merece la pena recopilar en este artículo y que sirven para tener una visión completa de cómo se plantea la problemática de la seguridad en la cloud computing.

1.- Estudio de riesgos en la Cloud de Enisa (En castellano). Son 140 folios con un estudio pormenorizado de los diferentes tipos de riesgos que la nube plantea en sus diferentes modalidades (IaaS, PaaS y SaaS). Es uno de los estudios más completos para tener una visión clara de los problemas que la nube plantea y cómo gestionar en ese contexto la seguridad.

2.- Estudio de la seguridad en la Cloud del BSI alemán (En ingles).  Son 70 folios del organismo aleman que establece los requisitos mínimos de seguridad que todo prestador debe satisfacer. Además, en este estudio, el análisis contempla criterios según las necesidades de disponibilidad o confidencialidad y las versiones de cloud públicas o privadas. Este documento es recomendado para los que se inician en el tema dado que en la introducción tiene una explicación detallada de los principales conceptos manejados bajo el término cloud así como las diferentes modalidades de servicios.

3.- Documento Enisa sobre como monitorizar los acuerdos de nivel de servicios en la nube prestados por terceros (En Ingles).  Son 64 folios con una definición marco de qué debe contemplar un SLA para servicios en la nube y cómo valorar por parte de un cliente la calidad del servicio prestado atendiendo a diferentes criterios (porque no solo la disponibilidad es suficiente en muchos casos). Esta guía de ENISA incluye  una descripción detallada de cada parámetro de seguridad a medir y cómo hacerlo. Los parámetros de seguridad a cubrir son: la disponibilidad del servicio; la respuesta a incidentes; la flexibilidad del servicio y la tolerancia de la carga; la gestión del ciclo de vida de los datos; el cumplimiento técnico y la gestión de la seguridad; la gestión de los cambios; el aislamiento de datos y la administración de los registros así como el análisis forense de seguridad de la información. 

4.- Documento de la AEPD y el Consejo General de la Abogacía donde habla del uso de la Cloud en despachos de abogados. (En castellano). Son 20 folios centrados en la problemática del uso de la cloud en el sector de la abogacía pero que es interesante e ilustrativo porque ha sido elaborando en colaboración con la Agencia Española de Protección de Datos (AEPD) y aporta su visión respecto a los requisitos legales de cumplimiento de la Cloud en el marco de la LOPD. Por tanto, de este informe se pueden deducir con carácter general qué cosas hay que exigir dentro del marco de cumplimiento en materia de protección de datos.

Del informe del BSI alemán me gusta este esquema gráfico de las cosas que están bajo el término "Cloud" y establece por un lado la arquitectura física y lógica de los sistemas de información y por otro las capas de gestión que el proveedor de servicio debe implementar. Bajo este contexto es obvio que los diferentes prestadores de servicio van a competir por el mercado intentando diferenciarse del resto y acreditando confianza. Para ello se están apoyando en la certificación de sus sistemas de información o servicios bajo las normas ISO 27001 (Seguridad de la información) e ISO 20000 (Gestión de servicios TI). Obviamente estas certificaciones sólo acreditan el cumplimiento de unos requisitos y la implantación de unas buenas prácticas de gestión TI aunque ello no tiene por qué suponer el logro de unos óptimos resultados (de la aplicación de esos marcos de gestión). En este contexto, la aparición de la reciente ISO 22300 también va a ser muy relevante dado que una de las cosas que más preocupan a los clientes en la cloud es que pasaría con sus datos en caso de una contingencia grave. Certificar un servicio en Cloud bajo la norma ISO 22300 al menos es un indicativo de que existen planes de continuidad de negocio y que se han probado. 

Mi reflexión/resumen de todo lo que voy leyendo al respecto es que las decisiones de saltar a la nube deben contemplar los siguientes factores:

1. Modalidad de cloud a emplear. Decidir el salto a la nube que se quiere dar. Los saltos a las modalidades IaaS y PaaS son más reversibles que los saltos a la modalidad SaaS. Por tanto, garantizan más autonomía en caso de problemas con el prestador o permiten montar rápidamente un servicio alternativo si ocurriese algo. Para ello es importante también decidir cual es la política de backup y qué parte se debe sincronizar desde la Nube con la organización que contrata. Tener al menos los datos te salva en caso de problemas gordos para poder garantizar "continuidad de servicio".
    
2. Definición de los términos y condiciones del servicio. El aspecto crucial de todo este asunto es también el proceso de contratación porque es cuando el prestador de servicios TI es flexible y se intenta amoldar al cliente. En este sentido, los contratos deben ser muy claros, concisos y concretos. El problema es cuando el proveedor TI es tan grande que es inflexible a las necesidades de clientes individuales. Además, es necesario hablar de penalizaciones porque un corte de X días tiene impactos no solo cuantificables por el coste del servicio sino también por las consecuencias de la ausencia del mismo aunque en la luz y el agua no se ven de esa forma.
   
3. Legislación y cumplimiento: Esto debe ser contemplado desde dos perspectivas. Por un lado, el marco jurídico donde se resuelven los conflictos porque si los problemas se resuelven en EE.UU. y sus tribunales las cosas tienen un coste en caso de conflicto y legislación aplicable. La temida Patriot Act permite a los americanos meterle mano a todo tipo de cosas. Por otro, garantizando el cumplimiento del marco legal de aplicación al que externaliza el servicio. La LOPD habla de diligencia del responsable del fichero frente a la externalización y que impera por tanto tener garantías de cumplimiento con carácter previo a la contratación. Además, no solo habría que mirar el presente de la materia (Actual ENS en Administraciones Públicas y LOPD) sino también el futuro (Nueva directiva de privacidad de la Unión Europea). 

De todo ello se evidencia en el contrato de servicios de cloud deberá  tener varios ejes y que obviamente debe ser redactado por perfiles jurídicos muy bien asesorados por los perfiles técnicos que tienen claro lo que quieren regular. Un buen acuerdo de nivel de servicio debe concretar y determinar los siguientes puntos:

• Introducción
• Descripción técnica del servicio.
•  Alcance
• Roles y responsabilidades
• Por parte del suministrador.
• Por parte del cliente.
• Operación del servicio
• Solicitud.
• Horas de operación
• Tiempos de respuesta.
• Mantenimiento y cambios
• Contingencias e incidencias cubiertas por el acuerdo.
• Procedimiento de escalado.
• Medición del servicio y su calidad.
• Notificación de incidentes en el prestador.
• Políticas o Normas complementarias a garantizar (Donde encaja este anexo técnico).
• Entrada en vigor y revisión del SLA.
• Aprobador del SLA.
• Revisor del SLA.
• Penalizaciones por incumplimiento.

De cualquier forma es justo y necesario pensar que todas estas cuestiones surgen ahora por la novedad de este tipo de servicios y la ausencia de experiencias de uso por parte de los clientes. En estos momentos aparecerán cientos de servicios y proveedores bajo las siglas cloud y será el tiempo quien realice una selección natural y vaya manteniendo y haciendo sobrevivir a aquellos que gocen del prestigio y la confianza de sus clientes en base a su fiabilidad, robustez y seguridad. Cuando todo el mundo piensa que el salto a la nube es peligroso en base a los riesgos ya identificados y por la alta dependencia de este nuevo tipo de terceros, debería al mismo tiempo plantearse que la misma dependencia existe de los proveedores de suministros básicos como la luz o el agua y sin embargo a ellos no se le plantean tantas exigencias respecto a garantizar continuidad de servicio y justificar el cumplimiento de SLA. Un corte de suministro tiene un impacto similar en una empresa que la caída de los servicios de cloud o del proveedor de telecomunicaciones que nos permite alcanzar la cloud. Por tanto, por coherencia, a todos los eslabones de la cadena hay que pedirles idénticas garantías y robustez. En el tema de suministros básicos, la Ley de Protección de Infraestructuras Críticas ya está forzando a que la continuidad sea un tema resuelto.