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?
20 marzo 2012
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í?
28 febrero 2012
Incumpliendo el ENS
Una pregunta recurrente, que yo mismo he lanzado al aire en varias ocasiones, es la de¿Qué consecuencias tiene incumplir el ENS?
Como casi todo en este mundo, el incumplimiento legal es un riesgo gestionable, y habrá quien decida asumirlo (aunque sea políticamente incorrecto decirlo, es la realidad). No obstante, antes de tomar esa decisión habría que tener claras las consecuencias derivadas de dicho incumplimiento, su coste. Y aquí es donde empieza el juego.
Por lo que he podido constatar, las responsabilidades derivadas de los incumplimientos legales se enmarcan en el concepto de responsabilidad patrimonial de las administraciones públicas. Básicamente, esto quiere decir que, si con el incumplimiento del ENS (o de cualquier otra ley) se provoca algún tipo de daño objetivo (u objetivable) que pueda ser cuantificable económicamente, la Administración Pública deberá asumir las consecuencias. Dicho de otra forma, si alguna persona (física o jurídica) sufre algún inconveniente objetivo por que las medidas de seguridad definidas por el ENS no estén aplicadas, y dicho inconveniente puede ser cuantificable económicamente, es probable que la Administración Pública sea denunciada por ello, y posiblemente acabe teniendo que pagar la correspondiente sanción por daños y perjuicios.
Este concepto no es nuevo. Seguro que todo el mundo conoce casos en los que un vecino denuncia a su ayuntamiento por un esguince provocado por una baldosa rota. Pues bien, ese mismo concepto es el que aplica en este caso. Es cierto que en este sector la cuantificación del daño producido no es tan sencilla, puesto que los precedentes son escasos y las posibilidades enormemente amplias, pero... ¿Resultaría difícil a un abogado cuantificar los daños por una supuesta usurpación de identidad en un trámite administrativo en el que no se hayan implementado los sistemas de autenticación apropiados? ¿O estimar las pérdidas económicas sufridas por una empresa cuya imagen se ha visto dañada porque desde una administración pública han publicado el estado de sus cuentas? ¿O incluso porque el nombre de esa empresa ha aparecido de forma incorrecta en un listado oficial de empresas con ERE?
Lo mismo que decimos del ENS se podría decir del ENI o incluso de la LACSP. ¿Qué perjuicios se puede provocar por no aceptar en un procedimiento administrativo un determinado formato de documento, con la consiguiente denegación de dicho procedimiento? ¿Cómo de complicado sería demostrar daños si se desea acceder a través de Internet a un servicio que todavía no ha sido puesto a disposición de los ciudadanos de forma electrónica, cuya consecuencia sea la imposibilidad de hacer uso del mismo?
En definitiva, creo que aún es pronto para ser capaces de cuantificar los costes que se podrían derivar de un incumplimiento del ENS por parte de una Administración Pública, pero tengo la sensación de que dichos costes no van a ser en absoluto despreciables. ¿Son conscientes los responsables de gestionar ese riesgo de cuáles son las consecuencias de hacerlo? ¿Puede ser esta vía un método válido para concienciar a los responsables públicos en torno a la seguridad? Espero vuestros comentarios...
Como casi todo en este mundo, el incumplimiento legal es un riesgo gestionable, y habrá quien decida asumirlo (aunque sea políticamente incorrecto decirlo, es la realidad). No obstante, antes de tomar esa decisión habría que tener claras las consecuencias derivadas de dicho incumplimiento, su coste. Y aquí es donde empieza el juego.
Por lo que he podido constatar, las responsabilidades derivadas de los incumplimientos legales se enmarcan en el concepto de responsabilidad patrimonial de las administraciones públicas. Básicamente, esto quiere decir que, si con el incumplimiento del ENS (o de cualquier otra ley) se provoca algún tipo de daño objetivo (u objetivable) que pueda ser cuantificable económicamente, la Administración Pública deberá asumir las consecuencias. Dicho de otra forma, si alguna persona (física o jurídica) sufre algún inconveniente objetivo por que las medidas de seguridad definidas por el ENS no estén aplicadas, y dicho inconveniente puede ser cuantificable económicamente, es probable que la Administración Pública sea denunciada por ello, y posiblemente acabe teniendo que pagar la correspondiente sanción por daños y perjuicios.
Este concepto no es nuevo. Seguro que todo el mundo conoce casos en los que un vecino denuncia a su ayuntamiento por un esguince provocado por una baldosa rota. Pues bien, ese mismo concepto es el que aplica en este caso. Es cierto que en este sector la cuantificación del daño producido no es tan sencilla, puesto que los precedentes son escasos y las posibilidades enormemente amplias, pero... ¿Resultaría difícil a un abogado cuantificar los daños por una supuesta usurpación de identidad en un trámite administrativo en el que no se hayan implementado los sistemas de autenticación apropiados? ¿O estimar las pérdidas económicas sufridas por una empresa cuya imagen se ha visto dañada porque desde una administración pública han publicado el estado de sus cuentas? ¿O incluso porque el nombre de esa empresa ha aparecido de forma incorrecta en un listado oficial de empresas con ERE?
Lo mismo que decimos del ENS se podría decir del ENI o incluso de la LACSP. ¿Qué perjuicios se puede provocar por no aceptar en un procedimiento administrativo un determinado formato de documento, con la consiguiente denegación de dicho procedimiento? ¿Cómo de complicado sería demostrar daños si se desea acceder a través de Internet a un servicio que todavía no ha sido puesto a disposición de los ciudadanos de forma electrónica, cuya consecuencia sea la imposibilidad de hacer uso del mismo?
En definitiva, creo que aún es pronto para ser capaces de cuantificar los costes que se podrían derivar de un incumplimiento del ENS por parte de una Administración Pública, pero tengo la sensación de que dichos costes no van a ser en absoluto despreciables. ¿Son conscientes los responsables de gestionar ese riesgo de cuáles son las consecuencias de hacerlo? ¿Puede ser esta vía un método válido para concienciar a los responsables públicos en torno a la seguridad? Espero vuestros comentarios...
27 febrero 2012
Conclusiones del CNIS 2012
Siento decir que este año el CNIS 2012 me ha decepcionado bastante. Lo mínimo que esperaba de un congreso denominado "de interoperabilidad y seguridad" era que se hablara de eso, de interoperabilidad y de seguridad. Sin embargo, es como si la temática se hubiera quedado corta, escasa de propuestas, y la organización hubiera tenido que abrir el abanico de temas a tratar para poder completar el evento. Sólo así me explico que la mayor parte de las ponencias versaran sobre administración electrónica en su más amplio especto, y que en muchos casos los términos interoperabilidad o seguridad apareciesen (si es que aparecían) de manera forzada o anecdótica.
Puedo entender que la crisis ha hecho mucho daño, y que la mayor parte de las administraciones públicas prácticamente no han avanzado nada en términos prácticos desde la pasada edición, pero creo que un año es tiempo suficiente como para poder profundizar en los debates, afinar en los comentarios o abordar la temática desde nuevas posiciones. Sin embargo, la mayor parte del congreso tan sólo fue más de lo mismo, y casi nada nuevo. Centrándonos en el ENS, los pocos proyectos reales que se presentaron (lo cual, visto lo visto, ya es de destacar), lamentablemente, no ofrecieron demasiados detalles sobre los trabajos realizados. Da la sensación de que para ver casos de adecuación (real y completa) al ENS tendremos que esperar al límite del plazo... como poco. En resumen, mucha teoría y poca práctica.
No obstante, no todo fue negativo en el CNIS. También hubo ponencias interesantes, aunque me gustaría destacar la última del congreso, titulada "TENGO UNA PREGUNTA PARA USTED: Marco y modelo jurídico en el que nos movemos", que me pareció buenísima. En ella, dos abogados especialistas en legislación tecnológica, tras una breve revisión del estado del arte en la materia, se dedicaron a responder las dudas del público, hablando claro y mojándose a la hora de dar respuestas, concretas y con justificación. Un formato sencillo, participativo y con más contenido real en una sola ponencia que en prácticamente el resto del congreso. Sin duda (y creo no ser el único que lo piensa), la mejor del congreso.
Puedo entender que la crisis ha hecho mucho daño, y que la mayor parte de las administraciones públicas prácticamente no han avanzado nada en términos prácticos desde la pasada edición, pero creo que un año es tiempo suficiente como para poder profundizar en los debates, afinar en los comentarios o abordar la temática desde nuevas posiciones. Sin embargo, la mayor parte del congreso tan sólo fue más de lo mismo, y casi nada nuevo. Centrándonos en el ENS, los pocos proyectos reales que se presentaron (lo cual, visto lo visto, ya es de destacar), lamentablemente, no ofrecieron demasiados detalles sobre los trabajos realizados. Da la sensación de que para ver casos de adecuación (real y completa) al ENS tendremos que esperar al límite del plazo... como poco. En resumen, mucha teoría y poca práctica.
No obstante, no todo fue negativo en el CNIS. También hubo ponencias interesantes, aunque me gustaría destacar la última del congreso, titulada "TENGO UNA PREGUNTA PARA USTED: Marco y modelo jurídico en el que nos movemos", que me pareció buenísima. En ella, dos abogados especialistas en legislación tecnológica, tras una breve revisión del estado del arte en la materia, se dedicaron a responder las dudas del público, hablando claro y mojándose a la hora de dar respuestas, concretas y con justificación. Un formato sencillo, participativo y con más contenido real en una sola ponencia que en prácticamente el resto del congreso. Sin duda (y creo no ser el único que lo piensa), la mejor del congreso.
21 febrero 2012
CNIS 2012
Mañana comienza la segunda edición del Congreso Nacional de Interoperabilidad y Seguridad. A lo largo de dos jornadas, varias administraciones públicas y algunos representantes de las organizaciones patrocinadoras expondrán el estado del arte en torno a los esquemas nacionales de interoperabilidad y seguridad, y nos contarán los avances que se han producido desde la pasada edición, en unos tiempos en los que probablemente los recortes presupuestarios hayan supuesto la nota dominante. ¿Cuáles serán las administraciones públicas que "saquen pecho" públicamente? ¿Quiénes serán los más críticos? Y mi principal interés: ¿Cuánta teoría y cuánta práctica veremos? En menos de 24 horas seguro que tenemos ya alguna respuesta... Nos vemos allí!
Suscribirse a:
Entradas (Atom)
