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

ISO 20000 para PYMEs

Uno de los principales culpables de que le dedique menos tiempo a publicar comentarios en el blog es un proyecto de implantación de ISO 20000 en PYMEs en el que estoy participando. El objetivo es muy sencillo: ¿No dice el estándar que el Sistema de Gestión de Servicios TI (SGSTI) que propone la ISO 20000 es válido para organizaciones de cualquier tamaño? Pues vamos a demostrarlo implementándolo en PYMEs, con todas las limitaciones de este tipo de empresas (pocos recursos técnicos, pocos recursos humanos, pocos recursos económicos) y alguna más que nos hemos buscado, ya que para conseguir que el proyecto sea subvencionado por el Plan Avanza los plazos de implantación deben garantizar que dichos SGSTIs estén certificados antes de fin de 2009.

La verdad es que es un proyecto muy complejo, tanto a nivel "técnico" como a nivel de gestión. Pero de momento puedo decir que, con sus puntos fuertes y sus áreas de mejora, el proyecto marcha más o menos según lo previsto. Y aunque todavía no tengamos resultados definitivos, sí que hay algunos aspectos que a día de hoy ya creo que se pueden ir destacando. Entre ellos, tenemos:

• Para las empresas que venden servicios TIC realmente la ISO 20000 tiene importantes connotaciones de negocio: sólo el hecho de adecuar los servicios prestados a las exigencias de la norma está proporcionando ventajas competitivas a las organizaciones a la hora de posicionar sus servicios respecto de los de la competencia.
• Un SGSTI no tiene por qué ser un monstruo: Si atendemos exclusivamente a los requisitos mínimos que exige la ISO 20000, es posible desarrollar procesos y servicios con unas dedicaciones totalmente asumibles por pequeñas organizaciones.
• No es imprescindible una super-herramienta para implementar los procesos definidos por la ISO 20000: Aunque las herramientas ayuden mucho, unas pocas aplicaciones bien seleccionadas, la voluntad del equipo de trabajo y un poco de sentido común nos pueden permitir suplir las funcionalidades de herramientas de elevado coste.

En definitiva, sigo pensando no sólo que es posible implementar un SGSTI certificable bajo ISO 20000 en una PYME, sino que un proyecto bien definido en este ámbito puede permitir a dicha PYME obtener beneficios directos y tangibles a la hora de comercializar sus servicios TI, con una inversión relativamente pequeña y amortizable a corto plazo. Y a día de hoy, eso es todo lo que puedo contar...

Tecnología Vs Uso

Hoy me he encontrado con este post, un poco por casualidad, pero la verdad es que me ha resultado muy interesante. En él, un conocido blogger (entre otras cosas) analiza las implicaciones de la tecnología de reconocimiento facial en función de los casos de uso, a través de dos casos concretos con distintas implicaciones y percepciones incluso opuestas de la misma tecnología.

La verdad es que el post me parece un ejemplo muy ilustrativo de la neutralidad tecnológica y de cómo lo importante no es la tecnología en sí misma, sino el uso que se haga de ella. E incluso hay que tener en cuenta que usos similares en entornos distintos pueden tener consecuencias muy diferentes, y apreciaciones subjetivas muy distintas, en función de las características del entorno.

Más allá del propio ejemplo, sería muy interesante analizar la aplicabilidad de la LOPD a los usos comentados en el artículo, y las implicaciones que puede tener eso de poder identificar a las personas que aparecen en las fotografías. ¿Estamos en un ámbito estrictamente personal, o es dicha ley aplicable? ¿Qué entidades desempeñarían cada uno de los roles definidos por dicha reglamentación? Un caso de estudio bastante interesante para cualquiera que esté dispuesto a moverse por terrenos resbaladizos, creo...

En definitiva, creo que el citado artículo supone un estupendo ejemplo para poder analizar cómo lo técnico, lo legal y lo moral se entremezclan hasta mucho más allá de lo que podríamos suponer en un principio. ¿Está nuestra sociedad preparada para dar respuestas a estas situaciones? ¿En los 3 ámbitos? Seguro que todavía hay mucho que decir al respecto.