Empresas y gripe A

Lo siento, no me he podido resistir. Hay temas sobre los que, si no escribes, parece que no estás al día... Aunque claro, si lo que escribes va contra corriente, quizás estés cometiendo un suicidio social... Bueno, me voy a arriesgar.

A estas alturas seguro que todos hemos oído hablar de la Gripe A, así que no me voy a entretener mucho con ella. No obstante, sí que me gustaría analizar sus efectos desde el punto de vista de la seguridad (de la información), porque tengo la sensación de que estamos perdiendo un poco el norte con este tema.

Vayamos por partes. En primer lugar, ¿qué efectos puede tener la gripe A sobre las empresas? Sencillamente, que el personal afectado no vaya a trabajar por estar sufriendo la enfermedad. Es decir, que desde el punto de vista de la seguridad la gripe A es una amenaza que puede provocar efectos sobre la disponibilidad y continuidad de las personas, y por tanto sobre los servicios que estas personas desarrollen.

El hecho de que sean los "servicios profesionales" los que se vean directamente afectados es un factor a tener en cuenta. Servicios TI puros o empresas productivas cuya cadena de producción esté completamente automatizada no se van a ver afectados de forma directa, sino sólo indirecta (por los servicios de mantenimiento que presten las personas sobre las máquinas correspondientes).

Ahora pasemos a analizar el factor de riesgo de esta amenaza. Por una parte, tendremos que analizar la probabilidad de ocurrencia de esta amenaza. En este caso estamos frente a una pandemia (sencillamente, una enfermedad infecciosa de alcance mundial, o mejor dicho, extendida por varias regiones geográficas extensas de varios continentes) de nivel 6 (la enfermedad se propaga geográficamente de persona a persona de manera exitosa, ya que aparecen brotes comunitarios en al menos 3 países de 2 regiones distintas). Por tanto, podemos decir que la probabilidad de ocurrencia aparentemente es alta. Pero... cómo de alta? Hay noticias que hablan de una tasa actual de ocurrencia de casi 54 casos por 100000 habitantes, y si vemos los datos de otros países europeos ninguno alcanza los 100. ¿Podemos considerar un 0,054% una tasa alta de ocurrencia? Si lo comparamos con el histórico de incidencia de la gripe estacional en España, vemos que el año pasado tuvimos una incidencia máxima de 200 casos semanales, y el máximo histórico alcanzado en 2005 fue de 542. Si extrapolamos este dato a uno mensual, podemos hablar de un umbral máximo histórico de ocurrencia del 2,17%. Si hacemos unas pequeñas suposiciones, como que la incidencia geográfica y temporal es homogénea, podríamos decir que la probabilidad mensual de contagio que tiene cada persona es, redondeando al alza, de un 2,2%. En realidad deberíamos considerar la probabilidad anual para poder mantener los cálculos que figuran a continuación, y aunque jamás van a llegar ni con creces a una tasa mantenida a lo largo del año, vamos a suponer que es así y que la probabilidad anual, acumulativa, es del 26,4% (como veis, estoy dejando muuuucho margen de error, y siempre estimando el caso peor).

El segundo factor para analizar el impacto de la amenaza es valorar sus efectos. En este caso, por separado para la disponibilidad y para la continuidad. Para el segundo, el fatídico, hay que considerar la tasa de mortalidad de la enfermedad, que sería lo que provocaría efectos sobre la continuidad. Para esta enfermedad a día de hoy tenemos una tasa de mortalidad del 0,018% en España, aunque algunas noticias que podemos encontrar en la red han llegado a dar una tasa mundial de 0,78%. Aparentemente no es una probabilidad alta, y tampoco parece serlo comparada con la de la gripe común, que según algunas fuentes sería hasta del triple que la primera.

Para el caso de la disponibilidad es necesario analizar el tiempo medio que una persona está de baja debido a la infección por gripe A. Según algunas fuentes, el dato de referencia varía entre los 2-4 y los 10 días, así que para nuestro cálculo tomaremos el límite superior, por si acaso. Esto supone una indisponibilidad del personal del 2,8% del tiempo anual, aproximadamente, si no consideramos periodos especiales. En términos coloquiales, una baja de semana y media.

En principio, con estos datos ya podríamos hacer una estimación del factor de riesgo. Para la disponibilidad, tendríamos que estimar que la gripe A va a provocar una baja de semana y media de duración en el 2,2% del personal cada mes. ¿Es correcta esta afirmación? Pues me temo que no. En este caso hay un factor que debemos tener muy en cuenta: la tasa de propagación del virus. La probabilidad de infección de una persona concreta sí que sería del 2,2%, pero la probabilidad de que esta persona infecte a compañeros de trabajo durante la semana y media de duración de la enfermedad depende de este dato. Y la verdad es que no he sido capaz de encontrar un dato específico al respecto, salvo que todas las fuentes hablan de una tasa mayor que la correspondiente a la gripe común y algunas afirman que llega a ser del triple. Como no he podido obtener ningún dato numérico, no me ha quedado más opción que recurrir a noticias menos argumentadas, que hablan de un 50% de afección en las empresas. Personalmente me parece un dato inflado, pero ya que es el único que he podido encontrar es el que voy a utilizar.

En definitiva, la afección por gripe A podría llegar a ocasionar como máximo en una empresa la baja del 50% de las personas durante el 2,8% del año con una probabilidad de ocurrencia del 26,4%, es decir, un impacto del 1,4% sobre la disponibilidad con una probabilidad de ocurrencia del 26,4%, de modo que el lucro cesante que debería asociar una empresa a la gripe A serían del 0,37% del valor que generen los servicios profesionales desarrollados por las personas afectadas, que en una empresa de servicios podríamos asimilar a su facturación. Sin olvidar que este es un valor asintótico con mucho margen...

Para estimar el impacto real de la gripe A en cualquier organización me gustaría comparar este dato con uno de referencia muy habitual: las vacaciones. Desde el punto de vista de la disponibilidad tienen un efecto idéntico al de una baja, salvo que son planificadas. En este caso, las vacaciones habitualmente las coge el 100% del personal (pongamos el 90%, por si acaso) con una probabilidad de al menos el 90% de certeza de que lo hagan y una duración de referencia de 3 semanas, así que en este caso hablaríamos de un impacto del 5,18% con una probabilidad de ocurrencia del 90%, es decir, un lucro cesante del 4,7%. ¿No os parece llamativa la comparación?

En definitiva, mi conclusión es que, aun en el peor de los casos, la gripe A no debe ser especial motivo de preocupación para las empresas. Todas asumen que sus empleados se van de vacaciones, y aunque se planifique para que coincida con periodos de menor actividad, la afección por la gripe A también coincidiría, si atendemos a los factores de propagación del virus, con periodos de menor actividad de los clientes, ya que se verían sujetos a las mismas olas. Y de todos modos hay que considerar el elevado diferencial de impacto entre ambos casos... Vamos, que en la práctica muchas empresas seguro que tienen mejores motivos por los que preocuparse que por los efectos de la gripe A. No vaya a ser que en medidas de prevención acaben gastándose más dinero que el lucro cesante que puede llegar a provocar la enfermedad...

Modelos para la gestion de incidentes de seguridad

A raíz de unos comentarios en relación al último post sobre incidentes de seguridad se me ha ocurrido extender un poco más mi respuesta en forma de post. La idea es, sencillamente, presentar un par de modelos que pueden ser utilizados para la gestión de incidentes de seguridad.

El primero de ellos, como sugieren en los citados comentarios, es seguir el modelo de gestión de problemas de ITIL para llevar a cabo la gestión de incidentes de seguridad. En dicho modelo se habla de monitorizar y ejecutar revisiones preventivas en busca de problemas, que en el ámbito de los incidentes de seguridad se podrían asimilar a las auditorías (técnicas de seguridad y la monitorización de los sistemas de seguridad, pudiendo llegar a considerar incluso las consolas SIM. Por otra parte, ya dentro de la gestión reactiva, la gestión de problemas en sí misma habla de registrar los problemas, diagnosticarlos, identificar las causas del mismo (convirtiendo el problema en un error conocido), definir la solución más apropiada y generar la RFC (petición de cambio) correspondiente. Si sustituimos el término problema por el de incidente de seguridad, el modelo de gestión es perfectamente válido.

El segundo de los modelos que se suele utilizar para la gestión de incidentes de seguridad es el correspondiente a la gestión de no conformidades y acciones correctivas asociadas. Podemos sustituir el incumplimiento de las normas y/o procedimientos establecidos (la no conformidad) por la ruptura de las condiciones de seguridad establecidas (el incidente de seguridad), y a partir de ahí seguir la sistemática de registro y análisis estándar para las no conformidades aplicada al mismo. A partir de la no conformidad se definirán alas cciones correctivas necesarias para resolver la no conformidad, que en nuestro caso supondría identificar las acciones a acometer para solucionar la causa del incidente de seguridad.

Como se puede ver, ambos modelos son equivalentes, y perfectamente válidos para la gestión de incidentes de seguridad. No obstante, tienen algunos matices que no está de más tener en cuenta, por si las moscas.

En primer lugar, la gestión de problemas según ITIL tiene un carácter técnico. Esto supone que los incidentes de seguridad asociados a las personas (y muchos del ámbito de la confidencialidad lo son) van a tener dificultades para ajustarse al modelo. Por otra parte, también es necesario tener en cuenta que la gestión de problemas requiere de la gestión de incidentes y la gestión de cambios y versiones para completar el ciclo de gestión, ya que los incidentes de seguridad requieren tanto de la corrección instantánea de la situación que provoca el incidente (gestión de incidentes) como de la aplicación efectiva de la corrección (gestión de cambios y versiones) para poder considerar que el incidente de seguridad está cerrado. Y por último es necesario considerar, dentro de la gestión de cambios, que el carácter eminentemente operativo que subyace en este proceso puede ser insuficiente para tratar determinados incidentes de seguridad cuyas causas y/o consecuencias puedan llegar a ser de carácter estratégico.

El segundo modelo es complementario al anterior. Es un modelo de caracter más estratégico, de modo que tienen mayor cabida situaciones de carácter menos técnico u operativo, pero al mismo tiempo es un modelo mucho más vago y menos detallado. Tiene la ventaja de que, al exigir la participación activa de la dirección, las decisiones que se adopten van a contar con su "bendición", lo que desde el punto de vista de recursos y prioridades puede ser importante. No obstante, si restringimos el modelo a la gestión de no conformidades y acciones correctivas también sería un modelo incompleto, y para terminar de completarlo deberíamos considerar también ltanto a gestión de acciones preventivas (en relación a las debilidades de seguridad) como la realización de auditorías y el seguimiento de indicadores y cuadros de mando que exige cualquier sistema de gestión normalizado, de modo que también queden contemplado en el modelo el apartado preventivo de la gestión de incidentes de seguridad.

En definitiva, lo importante es que cada organización desarrolle su propia sistemática de gestión de incidentes de seguridad y que, independientemente del modelo que elija (alguno de estos dos o cualquier otro) sea un modelo completo, que contemple todos los apartados necesarios para una gestión efectiva de los incidentes de seguirdad.

Incidentes y responsabilidades

Habitualmente, los que nos dedicamos a esto de la seguridad solemos hablar de riesgos, de controles, de prevención... Sí, también hablamos de incidentes de seguridad, pero habitualmente desde un punto de vista positivista: procedimientos de gestión, minimización de los efectos de los incidentes, etc. Pero muchas veces se nos olvida hablar de la cruda realidad: los incidentes ocurren. Y cuando ocurren, duelen.

Efectivamente, por mucha seguridad que tenga una organización, por mucho SGSI que tenga implantado y por muy bien que venda su certificado, nadie se libra de sufrir incidentes de seguridad. Tarde o temprano, a todo el mundo le toca. Y qué supone sufrir un incidente de seguridad? Veamos:

• En principio, el incidente ha podido ser contra la disponibilidad (algo ha dejado de funcionar), la integridad (algo se ha corrompido) o la confidencialidad (se ha filtrado alguna información). La traducción respectiva de estas casuísticas es que algo se ha parado (lucro cesante), algo funciona mal (también lucro cesante) o alguien sabe algo que no debería (y eso nunca es bueno).
• De los incidentes sólo nos enteramos cuando alguien lo notifica. Esto quiere decir que el hecho es conocido, al menos a nivel interno de la organización.
• Los incidentes siempre tienen connotaciones negativas (intrínsecas al concepto, por éso hay gente que prefiere hablar de incidencias, más allá de las definiciones exactas que hagamos de ambos términos), y por tanto son intrínsecamente morbosos, lo que va a propiciar la progresiva expansión de su conocimiento, cuya velocidad será proporcional al impacto percibido.
• Lo negativo y morboso, una vez que se ha difundido suficientemente, siempre ocasiona críticas, que se van realimentando y creciendo con la difusión. En el caso de la pérdida de confidencialidad estas críticas serán más evidentes, pero en cualquier caso el posicionamiento generalizado tenderá a criticar el hecho de que la organización haya "permitido" que ocurra el incidente, y más cuanto mayores sean las medidas dispuestas por la organización para tratar de evitar que ocurran.
• Como consecuencia de lo anterior, es previsible un posicionamiento del personal "en contra" de la organización, al menos del grupo de personas conocedoras del hecho.
• Este posicionamiento social contrario probablemente vaya a provocar reducciones en el rendimiento de la organización, derivadas de la desmotivación provocada.
• Cuanto mayor sea el impacto del incidente, su morbosidad potencial o el posicionamiento negativo del personal más probabilidades habrá de que su existencia pueda ser conocida fuera de la organización. Obviamente, si la parada o el mal funcionamiento propios del incidente estaban asociados a servicios externos, su conocimiento por parte de entidades externas será mucho más probable.
• A nivel externo las pautas de propagación del incidente son equivalentes, sustituyendo las personas por entidades y los agentes externos por medios de comunicación, aunque la velocidad de propagación a nivel externo habitualmente es mucho menor.
• En el caso de incidentes a nivel externo tendremos que considerar también los efectos derivados del tipo de información que haya sido revelada o de los servicios que hayan dejado de estar operativos, y que pueden ir desde pérdidas de competitividad hasta incumplimientos contractuales o regulatorios, con los consiguientes efectos económicos asociados.
• Todo ello podrá terminar provocando, a nivel externo, pérdida de prestigio o de reputación corporativa.

En definitiva, un incidente de seguridad ha podido ocasionar lucro cesante, pérdida de credibilidad a nivel interno, posicionamiento "social" en contra de la organización, reducción del rendimiento de la organización, pérdida de competitividad, penalizaciones económicas y pérdida de imagen pública. Obviamente, no todos los incidentes de seguridad van a tener tan "catastróficos" efectos, pero la clave es que debemos ser conscientes de que la gestión de los incidentes de seguridad no debe cubrir sólo los efectos directos del mismo, sino que todas estas derivadas deberían ser consideradas a la hora de llevar a cabo una gestión integral del mismo. Si no, corremos el riesgo de resolver el incidente y al mismo tiempo no ser capaces de cortar el flujo de acontecimientos que acabo de señalar...

Cuestion de confianza

Con el paso del tiempo, cada vez son más las organizaciones certificadas en ISO 27001. Ahora ya no es extraño encontrar empresas que luzcan un certificado de seguridad, y poco a poco comienza a verse cómo algunas de ellas incluso están comenzando a valorar que sus proveedores también estén certificados.

Ante este panorama, la pregunta clave en torno al mercado de las certificaciones comienza a hacerse cada vez más patente. ¿Hasta qué punto una organización está dispuesta a confiar en el certificado de la otra? ¿Es requisito suficiente el hecho de estar certificado para que todo el mundo pueda confiar en tu gestión de la seguridad?

La pregunta tiene más miga de lo que parece. Por un lado, todo el que conozca cómo funcionan los esquemas de certificación sabe que no es suficiente con tener un certificado, sino que el alcance de dicha certificación debe cubrir el ámbito que nos interesa. Pero una vez verificado este aspecto (algo sencillo, ya que figura en el propio certificado), qué más aspectos hay que tener en cuenta?

Como ya he comentado en alguna ocasión, un SGSI tiene varias dimensiones. La primera viene dada por el alcance, pero no es la única. También deberíamos tener en cuenta la Declaración de Aplicabilidad (es decir, qué controles de seguridad tiene aplicados la organización y cuáles no), y además sería muy útil conocer cuál es el nivel de riesgo asumido por la organización, ya que ese parámetro nos va a dar la clave para conocer el grado de "intensidad" con el que se están aplicando los controles. Por tanto, para poder estimar el "nivel de seguridad" de una organización sin necesidad de conocer el detalle de su SGSI sería necesario conocer estos 3 parámetros.

Teniendo esto en mente, podemos darnos cuenta de que la clave de la confianza en el SGSI de otra organización no radica en el certificado en sí mismo, sino en el "nivel de seguridad" que dicha organización presenta en relación al que nuestra organización exige. De este modo, podría existir una organización para la que la simple posesión del certificado por parte del proveedor fuese suficiente garantía de seguridad, ya que esta organización no tiene requisitos particularmente exigentes en materia de seguridad para el servicio o producto de este proveedor, mientras que otra organización opte por definir exigencias mucho mayores en este ámbito debido a que las necesidades de seguridad que tiene para el mismo servicio o producto son mucho mayores.

El "problema" de los certificados en ISO 27001 es que los criterios de auditoría, las exigencias contra las que se contrastan los SGSIs en las auditorías de certificación, son sencillamente (que no es poco) la propia norma y la normativa interna de la organización, pero nunca se tendrán en cuenta las exigencias de los clientes (a no ser que se establezca expresamente o que la organización asuma explícitamente como propias dichas exigencias). Por lo tanto, si dichas exigencias exceden las de la propia organización, el diferencial existente nunca será auditado en las auditorías de certificación, y por tanto debería ser auditado expresamente en auditorías de segunda parte (realizadas por el cliente al proveedor), en las que se incluyan dichas exigencias como criterios de auditoría.

En definitiva, la cadena de confianza establecida por los certificados (presuponiendo que son certificados acreditados, y por tanto de reconocimiento mutuo independientemente de la entidad de certificación) es suficiente si las exigencias en materia de seguridad son las "normales", si consideramos que el cumplimiento de la ISO 27001 es suficiente garantía, mientras que si las exigencias en esta materia son superiores tendremos que recabar más información acerca del SGSI de nuestro proveedor o recurrir a las auditorías de segunda parte para poder verificar el cumplimiento de nuestras exigencias en seguridad.

La culpa la tiene el gobierno... de TI

Buenos días a todos,

Aunque estoy de vacaciones, hoy quiero saldar una deuda pendiente con un colega. Hace ya algún tiempo (más del que me gustaría) recibí un mail suyo invitándome a publicitar un artículo escrito por él en el que indica una serie de recomendaciones para el correcto establecimiento de un Modelo de Gobierno TI, y la verdad es que, aunque leí el artículo y me pareció completamente recomendable, entre unas cosas y otras olvidé el mail y la recomendación asociada. Así que hoy cumplo con la deuda pendiente, con el consejo a todos los lectores de este blog de que lean el artículo con atención, ya que seguro que en algunos contraejemplos se van a sentir identificados:

La culpa la tiene el gobierno de TI, por Jose Manuel Fernández


Que paséis unas buenas vacaciones.

Gestion de Riesgos Vs Baselines

Hola a todos! La verdad es que últimamente tengo el blog bastante desatendido. Lo siento, pero por diversos motivos la verdad es que el tiempo no me da de sí ... Los días deberían tener más de 24 horas. Verdad?

Hoy sencillamente os quiero proponer un pequeño debate. O, al menos, una reflexión en la que os invito a participar. ¿Qué ventajas e inconvenientes veis a las dos estrategias de gestión de la seguridad que figuran en el título? ¿Cuál os gusta más? ¿Creéis que son compatibles?

En una de las esquinas del ring tenemos la gestión de riesgos de seguridad. Consiste en analizar los riesgos a los que estamos expuestos y aplicar medidas de seguridad para reducir aquellos riesgos que "sobresalen" por encima del nivel de riesgo que consideramos asumible. Las ventajas seguramente ya las conozcamos, pero como todo, siempre tiene un lado criticable: nada obliga a establecer un bajo nivel de riesgo aceptable, así que si asumimos riesgos elevados la seguridad que aplicaremos será "débil".

En la otra esquina tenemos la aplicación de baselines de seguridad. Consiste en establecer un cierto nivel de seguridad que conseguiremos mediante la aplicación de un determinado conjunto de medidas de seguridad específicas. Independientemente del riesgo, las medidas a aplicar son unas determinadas, con lo que conseguimos un nivel de seguridad "estandarizado", pero podremos estar haciendo una aplicación de medidas de seguridad ineficiente desde el punto de vista del riesgo.

Son dos alternativas válidas, cada una con sus ventajas y sus inconvenientes, aunque aparentemente poco compatibles. ¿Cuál os gusta? ¿Creéis que pueden ser compatibles? ¿Cómo? Estaré encantado de leer las opiniones de todos los que no estén de vacaciones...