26 agosto 2009

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...

24 agosto 2009

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.

03 agosto 2009

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.