Hoy quiero plantear una duda, poco menos que existencial, que me surge siempre que hablamos de gestión de riesgos. Adelanto desde ahora que no tengo una respuesta clara a esta pregunta, y que estaría encantado de que dejarais vuestras opiniones al respecto.
Todos sabemos que una de las estrategias de gestión de riesgos puede ser (junto con reducir, eliminar y asumir) la de transferir los riesgos a un tercero. Por otro lado, también es muy conocida y aceptada la máxima de que la responsabilidad no se puede delegar. ¿Qué ocurre si juntamos ambas afirmaciones?
La duda me surge en el concepto de transferencia del riesgo. ¿Si estamos transfiriendo un riesgo, también transferimos la responsabilidad asociada? ¿Si es así, no estamos yendo contra la segunda afirmación? Y si no es así, qué significa exactamente eso de transferir? Según el diccionario, es "ceder a otro el derecho, dominio o atribución que se tiene sobre algo". ¿No es ceder a otro la responsabilidad, en este caso, sobre el riesgo?
Vayamos ahora a un caso concreto. Por poner un ejemplo cercano, el mismo incidente del que hablaba en el último post. Supongamos que Microsoft ha seguido a nivel contractual todos los consejos indicados. ¿Tiene Microsoft algún tipo de responsabilidad por el incidente? En principio, podríamos pensar que no, aunque... por otro lado, ha sido la propia Microsoft quien ha decidido confiar en la empresa que ha sufrido el incidente... Es ese motivo suficiente para considerarla responsable?
Si la organización que teóricamente ha transferido un riesgo sufre un daño (económico, en imagen, etc.) por una inapropiada gestión de dicho riesgo por la parte contratada, debe ser considerada responsable? Cuál de las dos premisas iniciales ponemos encima de la otra?
29 marzo 2012
20 marzo 2012
Incidentes de terceros
Estos últimos días, en los foros de seguridad ha sido muy comentada la noticia de que un partner de seguridad de Microsoft ha publicado un exploit para una vulnerabilidad crítica. Básicamente, lo que ha ocurrido es que el descubridor de dicha vulnerabilidad la notificó a Microsoft junto con una prueba de concepto que la explotaba, que a su vez Microsoft distribuyó a su red de partners de seguridad (fabricantes de antivirus, IDSs, etc.) con el fin de que fueran preparando las contramedidas correspondientes, y uno de esos partners ha sido la fuente de la filtración, lo que hace que el exploit esté disponible públicamente a todo Internet.
Lo que quiero analizar en este post no es el resultado de este incidente, sino el hecho en sí de que un incidente de seguridad de un tercero afecte a tu negocio. ¿Qué medidas de seguridad se pueden adoptar para prevenir y/o mitigar este hecho?
En primer lugar, es evidente que el requisito mínimo es tener regulada contractualmente la relación. Más allá de la legislación de cada país, es evidente que si no disponemos de un contrato que regule las responsabilidades de cada parte, difícilmente podremos transferir el riesgo derivado de un posible incidente de seguridad a nuestro partner. No obstante, tener un contrato no es suficiente. Dicho contrato tendría que contemplar específicamente las responsabilidades derivadas de un posible incidente de seguridad, y este aspecto no es en absoluto trivial, ya que requiere definir algo tan genérico, hipotético o imprevisible como un incidente de seguridad, y determinar, en función de las nuevamente hipotéticas consecuencias de dicho incidente, las responsabilidades asociadas.
Sin embargo, ni siquiera con tener contractualmente regulado este aspecto sería suficiente. ¿Cómo asume la parte contratada las responsabilidades definidas? Las consecuencias no tienen por qué limitarse a un servicio no prestado, sino que el contratante puede argumentar lucro cesante, pérdida de imagen, incumplimientos legales o regulatorios... ¿Puede asumir la parte contratada una indemnización que satisfaga todos esos aspectos? En el mundo anglosajón se empiezan a contratar seguros específicos que cubran estas casuísticas, pero ni es una práctica generalizada ni prácticamente aplicada en el mercado español...
Aun en el caso de que realmente exista un seguro... ¿Cuál es la prima que requiere su contratación? El importe puede ser muy variable, y potencialmente elevado, aunque parece lógico pensar que dependerá de la probabilidad real de que realmente ocurra un incidente de seguridad... ¿Cómo se puede "estimar" esta probabilidad de ocurrencia? Como alguno de los lectores ya habréis adivinado, disponer de elementos de seguridad como un SGSI certificado o contar con diferentes dispositivos de seguridad técnica son factores que se tienen en cuenta a la hora de calcular dicha prima.
Y qué puede hacer la parte contratante? Por un lado, se puede entender que si ha llegado hasta aquí ha transferido adecuadamente el riesgo... Pero por otro lado, si aun así el incidente de seguridad se materializa, los daños los va a seguir sufriendo, aunque estén mitigados... Llegados a este punto, lo que debería hacer el contratante es llevar a cabo una vigilancia activa del contrato. O dicho de otro modo, no sólo asegurarse de que el contrato contiene las cláusulas necesarias, sino verificar que se cumple: reuniones de seguimiento, solicitud de informes, auditorías... Y por supuesto, que el propio contrato contemple todos estos mecanismos.
Para acabar, sólo una pregunta. ¿Cuánto se aproximan vuestros contratos a estas recomendaciones?
Lo que quiero analizar en este post no es el resultado de este incidente, sino el hecho en sí de que un incidente de seguridad de un tercero afecte a tu negocio. ¿Qué medidas de seguridad se pueden adoptar para prevenir y/o mitigar este hecho?
En primer lugar, es evidente que el requisito mínimo es tener regulada contractualmente la relación. Más allá de la legislación de cada país, es evidente que si no disponemos de un contrato que regule las responsabilidades de cada parte, difícilmente podremos transferir el riesgo derivado de un posible incidente de seguridad a nuestro partner. No obstante, tener un contrato no es suficiente. Dicho contrato tendría que contemplar específicamente las responsabilidades derivadas de un posible incidente de seguridad, y este aspecto no es en absoluto trivial, ya que requiere definir algo tan genérico, hipotético o imprevisible como un incidente de seguridad, y determinar, en función de las nuevamente hipotéticas consecuencias de dicho incidente, las responsabilidades asociadas.
Sin embargo, ni siquiera con tener contractualmente regulado este aspecto sería suficiente. ¿Cómo asume la parte contratada las responsabilidades definidas? Las consecuencias no tienen por qué limitarse a un servicio no prestado, sino que el contratante puede argumentar lucro cesante, pérdida de imagen, incumplimientos legales o regulatorios... ¿Puede asumir la parte contratada una indemnización que satisfaga todos esos aspectos? En el mundo anglosajón se empiezan a contratar seguros específicos que cubran estas casuísticas, pero ni es una práctica generalizada ni prácticamente aplicada en el mercado español...
Aun en el caso de que realmente exista un seguro... ¿Cuál es la prima que requiere su contratación? El importe puede ser muy variable, y potencialmente elevado, aunque parece lógico pensar que dependerá de la probabilidad real de que realmente ocurra un incidente de seguridad... ¿Cómo se puede "estimar" esta probabilidad de ocurrencia? Como alguno de los lectores ya habréis adivinado, disponer de elementos de seguridad como un SGSI certificado o contar con diferentes dispositivos de seguridad técnica son factores que se tienen en cuenta a la hora de calcular dicha prima.
Y qué puede hacer la parte contratante? Por un lado, se puede entender que si ha llegado hasta aquí ha transferido adecuadamente el riesgo... Pero por otro lado, si aun así el incidente de seguridad se materializa, los daños los va a seguir sufriendo, aunque estén mitigados... Llegados a este punto, lo que debería hacer el contratante es llevar a cabo una vigilancia activa del contrato. O dicho de otro modo, no sólo asegurarse de que el contrato contiene las cláusulas necesarias, sino verificar que se cumple: reuniones de seguimiento, solicitud de informes, auditorías... Y por supuesto, que el propio contrato contemple todos estos mecanismos.
Para acabar, sólo una pregunta. ¿Cuánto se aproximan vuestros contratos a estas recomendaciones?
12 marzo 2012
Seguridad y reputacion
Hace dos meses nos enterábamos de que una compañía de antivirus, Symantec, había sido hackeada. Aunque inicialmente la organización sólo reconoció haber sufrido un ataque menor, finalmente reconocieron que parte del código fuente de algunos de sus productos había sido robado.
La semana pasada era otra compañía de antivirus, Panda Security, la que había sido hackeada. En este caso parece que el objetivo ha sido una plataforma externa desde la que se prestan algunos servicios específicos, y el comunicado oficial indica que ningún servicio relacionado con productos, código fuente o actualizaciones se ha visto afectado.
Sea como sea, la realidad es que el daño ya está hecho. La imagen de ambas compañías se ha visto afectada, su reputación como marcas de referencia en materia de seguridad ha sido dañada. Aunque sólo sea de manera colateral, hay servicios (como PandaLabs) que desde el ataque siguen sin ofrecerse. Quizás ninguno de los dos incidentes ha sido portada en medios generalistas, pero dentro del sector, donde quien más quien menos ha accedido a noticias un poco más detalladas, es inevitable que surjan las dudas. ¿Qué grado de aislamiento real tenían los servidores aparentemente "core" del negocio de Symantec? ¿Qué política de claves usa Panda?
Lo difícil no es deducir que la imagen de ambas compañías se ha visto afectada, sino cuantificar el daño sufrido. ¿Cuántos antivirus van a dejar de vender ambas compañías a causa de los incidentes sufridos? Supongo que es una pregunta difícil de responder incluso para estas compañías. ¿Serán capaces de cuantificar económicamente el daño sufrido?
Y ahora pensemos en el mundo mayoritario, en la mayor parte de las empresas del mundo, que no se dedican al sector de la seguridad TIC. ¿Cuántas empresas "normales" son capaces de cuantificar el daño sufrido por un incidente de seguridad? Por mucho que la nueva directiva europea de protección de datos pudiese llegar a exigir el anuncio público de los incidentes de seguridad sufridos (cosa que personalmente dudo que vaya a acabar sucediendo)... ¿Cuántas compañías serían capaces de estimar económicamente el daño sufrido por tener que realizar dicho anuncio? Y si no lo saben hacer... ¿Cómo van a calcular el ROSI? ¿A efectos prácticos, les servirá para algo positivo ese anuncio?
La semana pasada era otra compañía de antivirus, Panda Security, la que había sido hackeada. En este caso parece que el objetivo ha sido una plataforma externa desde la que se prestan algunos servicios específicos, y el comunicado oficial indica que ningún servicio relacionado con productos, código fuente o actualizaciones se ha visto afectado.
Sea como sea, la realidad es que el daño ya está hecho. La imagen de ambas compañías se ha visto afectada, su reputación como marcas de referencia en materia de seguridad ha sido dañada. Aunque sólo sea de manera colateral, hay servicios (como PandaLabs) que desde el ataque siguen sin ofrecerse. Quizás ninguno de los dos incidentes ha sido portada en medios generalistas, pero dentro del sector, donde quien más quien menos ha accedido a noticias un poco más detalladas, es inevitable que surjan las dudas. ¿Qué grado de aislamiento real tenían los servidores aparentemente "core" del negocio de Symantec? ¿Qué política de claves usa Panda?
Lo difícil no es deducir que la imagen de ambas compañías se ha visto afectada, sino cuantificar el daño sufrido. ¿Cuántos antivirus van a dejar de vender ambas compañías a causa de los incidentes sufridos? Supongo que es una pregunta difícil de responder incluso para estas compañías. ¿Serán capaces de cuantificar económicamente el daño sufrido?
Y ahora pensemos en el mundo mayoritario, en la mayor parte de las empresas del mundo, que no se dedican al sector de la seguridad TIC. ¿Cuántas empresas "normales" son capaces de cuantificar el daño sufrido por un incidente de seguridad? Por mucho que la nueva directiva europea de protección de datos pudiese llegar a exigir el anuncio público de los incidentes de seguridad sufridos (cosa que personalmente dudo que vaya a acabar sucediendo)... ¿Cuántas compañías serían capaces de estimar económicamente el daño sufrido por tener que realizar dicho anuncio? Y si no lo saben hacer... ¿Cómo van a calcular el ROSI? ¿A efectos prácticos, les servirá para algo positivo ese anuncio?
08 marzo 2012
Ceder la seguridad a la nube
Todo el mundo coincide en que la nube es una tendencia imparable. Yo no voy a ser quien niegue las ventajas de la nube, ni creo que sea necesario enfrentarse con ella, pero sí que me gustaría que todo el mundo fuera un poco más consciente de qué significa la nube.
La nube no es humo ni gas, no es "algo que está pero no se ve". La nube tiene técnicos, tiene infraestructuras TIC, tiene proveedores de energía y tiene software que utilizan para darte un servicio. La nube son empresas normales y corrientes, que pueden tener incidentes de seguridad, igual que tu empresa, igual que te puede pasar a ti en tu casa. ¿Debemos ceder nuestra seguridad a esas empresas?
Hace un par de semanas, Google publicó una iniciativa de incluir en Chrome un generador de comtraseñas de calidad. Iniciativa muy interesante, salvo por una pequeña pega: parece ser que se trata de un generador de contraseñas on-line, una especie de sistema Single-Sign-On que almacena todas las contraseñas en la nube... de Google. Yo no digo que no haya que hacerlo, pero... ¿Somos conscientes de que le estamos dando a una empresa todas las llaves de los servicios web que usamos?
Esto, en el mundo real, se hace. Todos hemos visto películas en las que el protagonista le entrega las llaves a un aparca-coches, que se las guarda a cambio de un resguardo. ¿Queremos que sea Google nuestro "aparca-coches integral on-line? ¿Cuánto nos fiamos de Google como empresa? ¿Cuánto nos fiamos de lo que vaya a hacer Google con nuestras llaves? ¿Y cuánto nos fiamos de la seguridad con la que Google va a conservar todas nuestras llaves? Esas son las preguntas que debemos responder.
Esta misma semana un compañero del Blog de Seguridad de INTECO publicaba en él un artículo sobre la seguridad de los servicios de Cloud Storage. En él se hacen algunos comentarios sobre la responsabilidad de dichos proveedores frente al servicio de almacenamiento provisto. ¿Somos conscientes de la responsabilidad real que asumen estas empresas en torno a los servicios que proveen? ¿Estamos dispuestos a asumir que esas responsabilidades son suficientes? ¿Somos capaces de estimar los riesgos que estamos asumiendo por confiar en la nube una parte de nuestra seguridad? ¿Y si no es así, estamos adoptando nosotros medidas para complementar la responsabilidad del proveedor?
La verdad es que, personalmente, desconfío bastante de la seguridad que ofrecen los proveedores de servicios en la nube. A mí me gustaría que me garantizasen que todos mis datos, en todo el servicio, se cifran con algoritmos robustos. Y que la clave de cifrado es única y soy yo quien la gestiona, de modo que el propio prestador del servicio no pueda acceder a mi información. Me gustaría que el prestador del servicio me reportase periódicamente informes en los que yo pudiera evaluar la calidad y seguridad del servicio que me prestan, y que se hiciera contractualmente responsable de los incidentes de seguridad achacables a la infraestructura que soporta el servicio. ¿Alguien conoce un proveedor así?
La nube no es humo ni gas, no es "algo que está pero no se ve". La nube tiene técnicos, tiene infraestructuras TIC, tiene proveedores de energía y tiene software que utilizan para darte un servicio. La nube son empresas normales y corrientes, que pueden tener incidentes de seguridad, igual que tu empresa, igual que te puede pasar a ti en tu casa. ¿Debemos ceder nuestra seguridad a esas empresas?
Hace un par de semanas, Google publicó una iniciativa de incluir en Chrome un generador de comtraseñas de calidad. Iniciativa muy interesante, salvo por una pequeña pega: parece ser que se trata de un generador de contraseñas on-line, una especie de sistema Single-Sign-On que almacena todas las contraseñas en la nube... de Google. Yo no digo que no haya que hacerlo, pero... ¿Somos conscientes de que le estamos dando a una empresa todas las llaves de los servicios web que usamos?
Esto, en el mundo real, se hace. Todos hemos visto películas en las que el protagonista le entrega las llaves a un aparca-coches, que se las guarda a cambio de un resguardo. ¿Queremos que sea Google nuestro "aparca-coches integral on-line? ¿Cuánto nos fiamos de Google como empresa? ¿Cuánto nos fiamos de lo que vaya a hacer Google con nuestras llaves? ¿Y cuánto nos fiamos de la seguridad con la que Google va a conservar todas nuestras llaves? Esas son las preguntas que debemos responder.
Esta misma semana un compañero del Blog de Seguridad de INTECO publicaba en él un artículo sobre la seguridad de los servicios de Cloud Storage. En él se hacen algunos comentarios sobre la responsabilidad de dichos proveedores frente al servicio de almacenamiento provisto. ¿Somos conscientes de la responsabilidad real que asumen estas empresas en torno a los servicios que proveen? ¿Estamos dispuestos a asumir que esas responsabilidades son suficientes? ¿Somos capaces de estimar los riesgos que estamos asumiendo por confiar en la nube una parte de nuestra seguridad? ¿Y si no es así, estamos adoptando nosotros medidas para complementar la responsabilidad del proveedor?
La verdad es que, personalmente, desconfío bastante de la seguridad que ofrecen los proveedores de servicios en la nube. A mí me gustaría que me garantizasen que todos mis datos, en todo el servicio, se cifran con algoritmos robustos. Y que la clave de cifrado es única y soy yo quien la gestiona, de modo que el propio prestador del servicio no pueda acceder a mi información. Me gustaría que el prestador del servicio me reportase periódicamente informes en los que yo pudiera evaluar la calidad y seguridad del servicio que me prestan, y que se hiciera contractualmente responsable de los incidentes de seguridad achacables a la infraestructura que soporta el servicio. ¿Alguien conoce un proveedor así?
Suscribirse a:
Entradas (Atom)