27 diciembre 2012

Que espero del 2013

No creo que hacer predicciones para el próximo año sea algo al alcance de todo el mundo. Al fin y al cabo, creo que se requiere una visión mucho más global que la que puedo tener yo. Así que he decidido hacer un "pronóstico" mucho más cercano, y dejar las predicciones globales para gurús y grandes corporaciones.

Esto es lo que yo espero para el próximo año 2013:

  • Creo que la crisis va a continuar más o menos como en 2012. Me gustaría creer en esa idea que nos quieren vender de que a finales de 2013 empezará a remontar la economía, pero la verdad es que ya no sé qué pensar. Por cierto, ya sé que esta primera "predicción" no tiene que ver estrictamente con la temática del blog, pero me parece importante resaltarlo, porque creo que condiciona el resto. 
  • No creo que las empresas decidan gastar mucho dinero en mejoras en su gestión o su seguridad. Dicho de otro modo, no creo que vaya a ser un buen año para ver nuevas certificaciones en ISO 27001, ISO 20000 o ISO 22301. En línea con el año que dejamos atrás.
  • Espero ver un pequeño repunte en torno a la adopción del ENS y del ENI, sobre todo a finales de año. Pese a que las Administraciones Públicas van a seguir recortando presupuestos, la "presión" de ver de cerca la fecha límite del 30 de Enero de 2014 creo que va a provocar que algunas administraciones peguen un pequeño "empujón" al tema (aunque probablemente vaya más en la línea de ver aparecer nuevos planes de adecuación que en la de ver publicados los informes de cumplimiento). 
  • Me temo que uno de los temas estrella del año que viene, y en aumento, será el del malware para Android. Las aplicaciones gratuitas son un señuelo demasiado jugoso... 
  • Seguro que el Cloud Computing sigue pegando fuerte en 2013. El eslógan de reducción de costes es demasiado apetecible como para que las empresas se resistan a él. Aunque es probable, simplemente por madurez de la propuesta, que en 2013 surjan las primeras noticias negativas en forma de organizaciones que, tras probar el cloud, deciden volver al formato tradicional. Seguro que surgirán debates interesantes. 
  • A nivel tecnológico no espero ver grandes novedades en materia de seguridad, ni en el entorno clásico de Internet ni en el "nuevo" segmento de la ciberseguridad industrial. No obstante, seguro que los fabricantes nos obsequian con grandes lanzamientos e innovadoras formas de vender sus productos. El mercado es lo que pide...
  • Tengo la sensación de que el BYOD va a seguir siendo un tema de debate bastante importante, aunque más a causa de la realidad que se encuentran las empresas que en relación a las soluciones que plantea el mercado. Los usuarios somos cada vez más sibaritas... a pesar de los departamentos de TI.  
Y más o menos, creo que eso es todo. En definitiva, un año difícil, en el que habrá que echarle bastante imaginación... y un poco de inteligencia.

Feliz navidad, que paséis unas buenas vacaciones, y nos vemos en 2013.

Saludos,

Joseba

10 diciembre 2012

El problema del Cloud Computing

Que el cloud computing es algo más que una moda es evidente. Ha nacido para quedarse, y haríamos mal en intentar negarlo o no darle la importancia que se merece. Muchas organizaciones lo están adoptando o acabarán haciéndolo, nos guste o no a los que trabajamos en el ámbito de la seguridad. Quizás los profesionales del sector de la seguridad hayamos pecado a veces de idealistas, de precavidos, maximizando unos inconvenientes que desde el punto de vista del negocio van a ser en muchos casos asumibles. Pero lamentablemente también es cierto que el negocio se ha dejado impresionar más veces de las que debería por un planteamiento que en ningún caso es la panacea que nos quieren vender los proveedores de servicios cloud. Y es que, en el fondo, el problema del cloud computing no es un problema de seguridad, sino de negocio.

El planteamiento, como vais a ver, es muy simple. El negocio de un proveedor de servicios cloud son, obviamente, esos servicios: infraestructuras TIC, plataformas, aplicaciones... Su objetivo será maximizar el beneficio que le proporcionan esos servicios, tratando de ofrecérselos al mayor número de clientes posible. Por lo tanto, el objetivo será diseñar servicios lo más completos y universales que sea posible, manteniendo obviamente unos niveles de servicio aceptables.

Por el contrario, el negocio de un cliente de servicios cloud es... aquello a lo que se dedique cada cliente. Fabricación, transporte, energía, servicios públicos... Lo que sea. Para ello hará uso de los mejores medios tecnológicos que pueda conseguir. Y entre estos medios aparecerán, como no, diferentes servicios informáticos. Algunos los implementará el departamento TI de la propia organización, y otros tratará de conseguirlos en forma de servicios cloud. Y aquí es donde se produce el problema.

El cliente va a requerir que los servicios informáticos que utiliza estén lo más alineados posible con su negocio. Dicho de otro modo, que sean lo más a medida posible. Sin embargo, el proveedor cloud va a tratar de ofrecer los servicios cloud que más encajen con su propio modelo de negocio, es decir, lo más genéricos y estándares posible. Y obviamente esto va a producir un importante desencuentro entre ambos planteamientos.

En este punto, y no antes, es donde entra en juego la seguridad. Cada cliente, dentro de su modelo de negocio, va a tener unos requisitos de seguridad específicos. Si en su actividad trata datos de carácter personal de nivel alto, requiere que los servicios informáticos cumplan con las medidas de seguridad definidas por el RDLOPD. Si gestiona datos de tarjetas de crédito necesita que los servicios implementen las medidas de seguridad exigidas por PCI-DSS. Si es una administración pública, necesitará que los citados servicios cumplan con las medidas de seguridad exigidas por el ENS para el nivel que corresponda en cada caso. Sencillamente, porque su negocio se lo exige.

Lamentablemente, los actuales proveedores de servicios cloud no suelen ser capaces de responder adecuadamente a estas exigencias. Cada vez podemos encontrar más proveedores de servicios cloud que presumen de seguridad, se certifican en ISO 27001, cumplen con la directiva europea de protección de datos... y piensan que eso es suficiente. No se dan cuenta de que es suficiente para SU modelo de negocio, pero puede no serlo para el de sus clientes. Un cliente español que trate datos personales de nivel alto mediante una aplicación SaaS necesita que el log del registro de accesos a la base de datos de dicha aplicación esté bajo el control directo del responsable de seguridad, lo cual va más allá de cualquier directiva europea de protección de datos o certificación ISO 27001. Del mismo modo, un cliente que trate información confidencial o de carácter estratégico a nivel europeo debería pensárselo mucho antes de contratar un proveedor de servicios cloud estadounidense, sujeto a la Patriot Act por mucho que sus datos no vayan a salir de territorio europeo. ¿Cuántos proveedores de servicios cloud estadounidenses podrían garantizar el suficiente nivel de confidencialidad frente a este hecho?

En definitiva, no podemos olvidar que un proveedor de servicios cloud no es ni más ni menos que una empresa, con sus propios intereses, modelo de negocio y restricciones legales. Por lo tanto, en caso de querer hacer uso de los servicios informáticos que ofrece habrá que evaluar detenidamente si todas esas particularidades son compatibles con nuestro propio modelo de negocio y con los requisitos funcionales, legales y de seguridad que sean aplicables al uso que queremos hacer de esos servicios. Que no hay inconveniente? Adelante, seguro que el modelo cloud aporta grandes beneficios a nuestra organización. Que sí que los hay? Buenas noticias para el departamento de TI, que seguro que hace todo lo posible para demostrarnos que la decisión de no externalizar el servicio ha sido la adecuada.

22 noviembre 2012

Reflexiones sobre el congreso nacional de itSMF #Vision12

Este lunes y martes pasado se celebró el congreso nacional de itSMF, al que tuve la suerte de asistir por primera vez. Por unas cosas u otras, otros años no había podido asistir, de modo que tenía ganas de conocer de primera mano un congreso del que me habían hablado bastante bien, y la verdad es que no me defraudó. La organización me gustó mucho, y las ponencias en general estuvieron bastante bien, con algunas excepciones por arriba y -lamentablemente- también por abajo.

En este post simplemente quería destacar algunos aspectos que me parecen dignos de reflexión:

  • El cloud computing fue el tema estrella del evento, aunque más visto desde el punto de vista del consumidor de servicios cloud que del proveedor. Eché de menos alguna ponencia de algún proveedor de servicios cloud que se atreviese a discutir el punto de vista "cliente", predominante.
  • Me sorprendió que hubiera unas cuantas ponencias que abordasen de algún modo el propio concepto  de "servicio". Pensaba que sería un tema bastante más "trillado", pero me dio la sensación de haber vuelto a los debates que yo tenía hace 3 ó 4 años, cuando estábamos escribiendo el libro ISO 20000 para pymes.
  • Me hizo ilusión ver cómo se estaban materializando algunas de las ideas de aquella época, y en concreto me gustó mucho el modelo incremental para la adopción de la ISO 20000 recogido en la próxima UNE 71020. 
  • El congreso me pareció ideológicamente endogámico, en todo momento se analizaba el sector TIC desde dentro del sector TIC. Es lo habitual, y no me parece mal, pero quizás la visión del usuario o la aportación directa de la dirección pudiera servir de soplo de aire fresco para este tipo de eventos, de forma que dejásemos de verles como externos con los que nos tenemos que alinear y empezásemos a entenderles como una parte imprescindible para nuestros servicios. 
  • Una misma reflexión me martilleaba la cabeza una y otra vez: Si el futuro de los departamentos TIC es cada vez más gestión de servicios y menos tecnología... ¿Están los profesionales TIC (informáticos, "telecos") preparados para el futuro que les espera? ¿O en un futuro veremos los departamentos TIC poblados por profesionales de la gestión en lugar de estarlo por profesionales de la tecnología?  
En definitiva, un gran evento al que espero volver a acudir en próximas ediciones. Y mientras tanto, contento de poder disfrutar de su hermano pequeño en el recién nacido itSMF Euskadi. Nos vemos!

31 octubre 2012

Todas las seguridades

A veces es un poco confuso entenderse con tanta "seguridad". Es un término que significa muchas cosas... y que usamos todavía para más, solo o compuesto. Así que, por si alguien se pierde, aquí hay una breve definición de todos estos conceptos:
  • Seguridad (1): La seguridad entendida en su concepto más amplio sería la que define la RAE, es decir, la cualidad de estar libre y exento de todo peligro, daño o riesgo. Aquí entraría TODO, tanto la security como la safety, es decir, todo lo relacionado con los riesgos laborales, la seguridad patrimonial (cajas fuertes, vigilantes jurado, furgones blindados), la seguridad informática... 
  • Seguridad (2): También se usa el término seguridad como traducción exclusiva del security anglosajón. En este caso dejaríamos de lado todo lo relacionado con la safety (riesgos laborales, integridad física de las personas) y nos centraríamos exclusivamente en la protección expresa. No hay forma de distinguir este uso del anterior, sólo el contexto sirve para identificar una acepción u otra. En este ámbito tenemos la seguridad física, la seguridad lógica, las medidas de seguridad organizativas y/o contractuales, etc. 
  • Seguridad de la información: Se utiliza en muchas ocasiones como sinónimo de la acepción (2) de seguridad, con el fin de que no haya errores de interpretación. Esto es así porque, en la práctica, cubre todas las disciplinas de protección que cubre el concepto security. Sin embargo, no hay que olvidar que el punto de vista de la protección física que subyace en el concepto de seguridad de la información es que se protegen los activos físicos y a las personas principalmente por el hecho de ser contenedores de información, es decir, a causa de la capacidad que tienen para tratar y/o conservar información, más que por el valor intrínseco propio en términos económicos, éticos o de otro tipo. 
  • Seguridad patrimonial: Generalmente se utiliza este término para definir la seguridad aplicada a la protección de bienes patrimoniales y/o personales especialmente valiosos, y que clásicamente ha venido desempeñando la seguridad privada (vigilantes de seguridad, sistemas de video-vigilancia, blindajes, etc.). Normalmente se suele utilizar como sinónimo de seguridad física, y en general no se suele incluir bajo este término la seguridad lógica, aunque esta exclusión es un hecho de facto más que  conceptual. A diferencia del caso anterior, la protección se debe principalmente al valor económico de los activos protegidos. 
  • Seguridad física: Este término se utiliza para definir todas aquellas medidas de seguridad de carácter físico aplicadas a la protección de activos físicos. Normalmente se incluyen tanto los sistemas de limitación y control de acceso físico (vallas, vigilancia, cerraduras, etc.) como los sistemas de control y acondicionamiento ambiental (aire acondicionado, detección de incendios, etc.). Aunque no tiene por qué ser así, se suele centrar más en la protección de activos materiales (equipos, sedes, etc.) que en la protección de personas, quedando habitualmente este último aspecto más relegado al concepto de seguridad patrimonial. 
  • Seguridad lógica o seguridad informática: Se suele utilizar este término para definir todas aquellas medidas de seguridad de carácter informático aplicadas a la protección de activos lógicos (de naturaleza informática), bien información propiamente dicha (ficheros lógicos, bases de datos, etc.) o bien servicios implementados por aplicaciones informáticas. No hay consenso en si la seguridad lógica contempla también las medidas de seguridad operativas ligadas a la informática (todas las relativas a la gestión de los sistemas informáticos) o si dicho concepto se debe limitar sólo a las medidas de seguridad técnicas, y por lo tanto es habitual encontrar ambos planteamientos al lidiar con este término.
  • Ciberseguridad: Este es un término cuya adopción generalizada es relativamente nueva (al menos en el mercado español), aunque su aparición sea mucho más vieja. En muchos casos se utiliza como otro sinónimo de seguridad lógica o seguridad informática, pero en los últimos tiempos su uso se ha extendido de forma matizada, utilizándose para definir la seguridad lógica o informática aplicada específicamente a infraestructuras críticas en particular o a sistemas de control industrial en general. Al igual que en el caso anterior, hay autores que incluyen en dicho concepto las medidas operativas y otros que no lo hacen. 
Conviviendo con los términos anteriores existen otros ámbitos (organizativo, operativo, contractual, gestión de personal) en los que a día de hoy el mundillo de la seguridad no ha acuñado un término específico. No obstante, cada día surgen nuevos usos y modas, de forma que habrá que estar atento a la evolución terminológica, no vaya a ser que este post se quede rápidamente desactualizado...

22 octubre 2012

Cumplimiento ENS

Hoy os quiero hablar de una iniciativa que me han propuesto "apadrinar" (o para ser más exactos, promover): el mini-site www.cumplimientoens.es. La idea es que esta web se vaya convirtiendo, con las aportaciones de todos, en un listado de administraciones públicas inmersas en la adecuación al Esquema Nacional de Seguridad. El objetivo es promover el despliegue del Esquema Nacional de Seguridad entre las Administraciones Públicas, y tratar de ir reflejando en una web de referencia los avances que cada administración vaya llevando a cabo, con la intención de que, cuanto más completo sea el listado, más "verguenza" les entre a todas aquellas administraciones públicas que no aparezcan en él...

Por supuesto, la web no pretende ser un listado oficial, y seguro que habrá inexactitudes, ausencias e incorrecciones... Por éso precisamente está orientada a ser un listado dinámico, de forma que cualquiera pueda aportar y/o corregir la información que aparece en ella. Aunque me temo que, mientras no haya un desarrollo más potente por detrás, el método de notificación es tan sencillo como enviar un correo electrónico a la dirección que aparece en la pantalla de colaboración.  ;-)  Espero que en un futuro la web puede ser bastante más potente, aunque principalmente dependerá del impulso que pueda recibir en forma de contenido. Así que si os gusta la iniciativa, ya sabéis...

18 octubre 2012

Publicada ISO/IEC 27013:2012 - Integración de ISO 20000 e ISO 27001

Esta semana se ha publicado la nueva norma ISO/IEC 27013:2012, una guía de implementación integrada de un SGSI (Sistema de Gestión de Seguridad de la Información) y de un SGS (Sistema de Gestión de Servicios) según las normas ISO 27001 e ISO 20000, respectivamente.

La norma sirve tanto para integrar ambos sistemas de gestión cuando ambos ya existen como para implementar uno de ellos aprovechando la existencia del otro, e incluso para la implementación inicial conjunta de ambos. Una herramienta bastante útil para organizaciones que quieren buscar la eficiencia y eficacia de la integración de ambos sistemas de gestión...

17 octubre 2012

Nos vemos en ENISE 6

El próximo martes 23 y miércoles 24 de Octubre de 2012 se celebra en León la sexta edición de ENISE, el encuentro internacional de seguridad de la información que organiza anualmente INTECO bajo el lema "La Ciberseguridad, un elemento clave para el futuro de nuestra sociedad".

Un año más estaré presente en representación de la empresa en la que trabajo, Nextel, participando en el taller T12 - Retos de ciberseguridad en la modernización de la Administración con la presentación Aprovechando oportunidades, cloud en la e-Administración. En ella contaré cómo muchas Administraciones Públicas están planteándose utilizar los servicios que ofrece el Cloud Computing como una forma de optimizar su inversión TIC, sin ser conscientes de las dificultades legales y prácticas que puede suponer el uso de estos servicios. A lo largo de la ponencia analizaré algunas de estas dificultades y presentaré posibles soluciones a ellas, para cuestionar en última instancia si estas soluciones permiten hacer uso de todos los beneficios teóricos que ofrece el Cloud Computing.

Por la tarde, como no podía ser de otra manera, también asistiré al taller T14 - Encuentro de blogueros de seguridad 2012. En este caso no participaré como ponente, aunque por supuesto estaré entre el público, tratando de aportar mi granito de arena como autor de este blog y colaborador del blog de seguridad de INTECO


Y por la noche... mi intención es disfrutar del excelente turismo gastronómico que se puede practicar por el barrio húmedo. De modo que si a alguno le apetece disfrutar de unas cervezas en compañía, ya sabe dónde puede encontrarme!   ;-)

25 septiembre 2012

Faldas y privacidad

Basta con salir un sábado por la noche para darse cuenta de que la longitud de las faldas que llevan las jóvenes (y no tan jóvenes) no se parece en absoluto a la de hace 10 ó 15 años. De hecho, si echamos la vista atrás podremos observar cómo en los últimos 100 años la cantidad de tela que cubría los cuerpos femeninos no ha hecho sino disminuir progresivamente. Durante el último siglo, la madre (ya no digamos la abuela) riñendo a la hija por la longitud de la falda ha sido un tópico repetido generación tras generación.

Lo que a veces no nos paramos a pensar es en lo que hay detrás de ese tópico. Y no estoy hablando de la teoría económica de la longitud de las faldas, sino de los motivos que llevan a las madres a insistir a sus hijas en que se tapen más. Sencillamente, consideran que están exponiendo demasiado su intimidad, al menos más de la que ellas consideran aceptable. Olvidando, por cierto, que ellas mismas hicieron lo mismo en su juventud...

En definitiva, creo que es evidente que cada generación tiende a mostrar en público más aspectos íntimos que la generación anterior. Las faldas, escotes o trajes de baño no son sino una representación muy gráfica de este hecho. Y la aparición de las redes sociales no ha hecho más que trasladar esta realidad al ciberespacio.

Mientras unos pocos (generalmente en la edad adulta) nos empeñamos en que las redes sociales implementen mayores medidas de privacidad, vemos escandalizados cómo las nuevas generaciones (nativos digitales, no lo olvidemos) no se preocupan por la cantidad de información íntima que publican en ellas. Y observamos cómo, incomprensiblemente para nosotros, no hacen prácticamente uso de las opciones de privacidad ni siquiera cuando saben que existen. Olvidando que no hacen sino trasladar a su realidad cotidiana los mismos principios que nosotros, en nuestra juventud, aplicamos a la nuestra: lucir un poco más de palmito tratando de conseguir un poco más de atención e interés por parte de los jóvenes del sexo opuesto de nuestro entorno. Al fin y al cabo, las únicas diferencias son que nuestro entorno físico era mucho más reducido que el suyo virtual, y que las posibilidades de "parecer interesantes" que tienen ellos van mucho más allá de los centímetros cuadrados de piel que estén dispuestos a enseñar.

Bajo ese punto de vista, creo que las estrategias que utilizamos para inculcar principios de privacidad entre las nuevas generaciones no son las más eficaces. Insistimos una y otra vez en que conozcan las opciones de privacidad que existen, en que sean conscientes de los peligros que acechan... ¿Acaso el clásico dicho de que "hay mucho violador suelto" ha amedrentado alguna vez a una joven para cambiar su indumentaria por una más "recatada"?

Me temo que la única estrategia que a medio plazo puede servir para tratar de inculcar una cierta preocupación por la privacidad en las nuevas generaciones es la de fijar el umbral mínimo socialmente aceptable. Lo mismo que una joven nunca estaría dispuesta a salir a la calle "vestida como una p..." (ojo, bajo su criterio, no bajo el de su madre), creo que nuestra aspiración debería ser la de definir ese nivel de privacidad mínimo que "una persona decente" no debería superar. Con la dificultad añadida no sólo de definir ese nivel (que siempre va a ser menor que el que nos gustaría), sino de lograr asociarlo a una figura "socialmente rechazable", como en el caso anterior. Y mientras tanto, resignarnos a ver cómo los jóvenes de hoy en día están dispuestos a enseñar a todo el mundo partes de sí mismos que a nosotros nos parecen íntimas y personales. Al fin y al cabo... no ha sido siempre así?

29 agosto 2012

El dilema de la calidad: ¿Real Madrid o Athletic de Bilbao?

Ahora que todos estamos volviendo a la dura rutina post-vacacional, espero que un post más "polémico" de lo habitual sirva para ir calentando motores... Y para que la vuelta al trabajo se haga más llevadera. Así que hoy he decidido hablar del concepto de calidad con un par de ejemplos futboleros. A ver si consigo que algún "hincha" entre al trapo...

Por un lado, la calidad debería ser algo sencillo de entender. Al fin y al cabo, todos tenemos más o menos claro cuándo algo es bueno, no? En este caso, cuándo un equipo hace "buen fútbol"... Por éso se me ha ocurrido como ejemplo el Athletic de Bilbao, un equipo del que prácticamente todo el mundo coincide en decir que la temporada pasada hizo muy buen fútbol. ¿Si su producto es bueno, es un equipo "de buena calidad"?

Sin embargo, los estudiosos de la calidad no están del todo de acuerdo con el planteamiento anterior, y muchos defienden que calidad consiste en satisfacer al cliente, en darle lo que quiere (incluso aunque no sepa que lo quiere). Si entendemos que el cliente de un equipo de fútbol son sus hinchas (no quiero entrar en el debate de cliente Vs sociedad, dos grupos de interés muy importantes para una sociedad deportiva)... ¿Qué es lo que quieren? Buen juego sí, pero sobre todo victorias y títulos. Y aquí es donde entra el ejemplo del Real Madrid.

Prácticamente todo el mundo coincide en que el Real Madrid no ha destacado la temporada pasada por su buen juego. Sin embargo, fue el equipo que más partidos ganó, y además consiguió un título. El Athletic de Bilbao, sin embargo, no consiguió ni la mitad de victorias que el Real Madrid, y tampoco logró ningún título, pese a alcanzar dos finales. ¿Podemos decir, por tanto, que el el Real Madrid es un equipo "de buena calidad"?

Obviamente, todo es matizable. Al fin y al cabo, el Athletic de Bilbao llegó a dos finales, y el juego del Real Madrid no era desastroso, ni mucho menos. Si preferís, vamos a poner dos ejemplos más clásicos y diferenciados: la selección italiana del catenaccio y los títulos frente a la selección española del toque y la eliminación en cuartos.

Y la pregunta es la siguiente: ¿Con qué definición de calidad te quedas? ¿Qué opción prefieres? ¿Athletic de Bilbao o Real Madrid? ¿La Italia histórica o la España histórica? A ver quién se atreve a mojarse y no opta por la respuesta fácil de elegir al FC Barcelona o al Brasil histórico...

12 junio 2012

ISO 20000, camino a la excelencia

Seguro que a estas alturas todos los lectores del blog conocen la ISO 20000. Pero puede que no conozcan demasiado los modelos de excelencia empresarial (también conocida como excelencia en la gestión, o a veces Calidad Total). Son modelos de gestión que tratan de ir más allá de la gestión de la calidad clásica, entendida como "bondad" de los productos o servicios. Su objetivo es que las empresas sean "buenas" (tengan calidad) en todos los sentidos: en el aspecto productivo, en la gestión de su personal, en el papel de la empresa respecto de la sociedad, en los resultados que obtiene, ... Para ello, plantean un modelo ideal (prácticamente utópico) de empresa excelente, y tratan de medir el grado de aproximación de las empresas a ese modelo de referencia.

El modelo de excelencia adoptado a nivel europeo es el modelo EFQM. Sin embargo, cada región tiene el suyo: Iberoamérica tiene el Modelo Iberoamericano de Excelencia en la Gestión, Estados Unidos el Malcolm Baldrige... No obstante, todos son similares, y aunque el modelado en cada caso es parcialmente distinto, la filosofía que subyace en todos ellos es la misma. Por lo tanto, me voy a centrar en los modelos europeo e iberoamericano, que son los dos que mejor conozco. 

Lo que quiero plantear en este post es la posibilidad de utilizar el modelo propuesto por la ISO 20000 para la gestión de servicios como patrón de referencia para el desarrollo de un modelo organizativo compatible con los planteamientos de los modelos de excelencia. ¿Hasta qué punto sirve la ISO 20000 como palanca para avanzar hacia un modelo de excelencia?

Como primer punto de referencia, creo que es necesario recordar la insistencia de los modelos de excelencia con medir objetivamente los resultados. Obsesión compartida por la ISO 20000, que exige tener mediciones de los servicios prestados, de los procesos y del propio sistema de gestión. ¿No encaja acaso esta exigencia con los criterios de resultados en clientes y resultados clave/globales? Además, el desarrollo de estos factores encaja a la perfección con el desarrollo de los criterios de estrategia y procesos, entre otros. 

Si desglosamos la ISO 20000, también podemos encontrar un proceso enfocado a la gestión de recursos (criterio 4 en ambos modelos de excelencia), así como elementos del sistema de gestión que encajan dentro de los criterios de personas. No encontramos en la ISO 20000 un desarrollo específico del apartado de liderazgo, pero sí un requisito de designación de responsabilidades que puede encajar a la perfección en el primer criterio de ambos modelos de excelencia. 

En definitiva, el modelo de gestión planteado por la ISO 20000 puede ser un modelo de referencia perfectamente válido para asentar sobre él un sistema de gestión corporativo compatible con los modelos de excelencia empresarial vigentes en la actualidad. Y si esto es así... cuánto tardarán las organizaciones en sacar provecho de esta convergencia?

ACTUALIZACIÓN: En el blog de Euskalit, la fundación vasca para la excelencia empresarial, publican una reseña a un artículo en el que profundizo en este planteamiento de utilizar ISO 20000 como camino hacia la excelencia empresarial. Por si queréis más información...  :-)

31 mayo 2012

Gestión ITILizada de vulnerabilidades

Existen multitud de referencias para la gestión de la seguridad. No obstante, dicha gestión acaba quedando traducida, habitualmente, a dos ámbitos complementarios: gestión de riesgos + gestión de incidentes de seguridad. Una simplificación que en la mayor parte de las organizaciones puede resultar suficiente, pero que a veces se pude quedar un poco corta. ¿Cómo aplica ese planteamiento para la gestión de vulnerabilidades?

El modelo de gestión de riesgos "clásico" es un modelo estático. Analizamos los riesgos una vez, y no revisamos el análisis hasta pasado un ciclo completo del proceso (normalmente, anual). Sin embargo, la gestión de vulnerabilidades es algo mucho más dinámico. De ocurrencia puntual, pero que al cabo de un mes en general tendremos que aplicar. Un ciclo excesivamente corto para el análisis de riesgos.

El modelo ITIL de gestión de incidentes aplicado a las vulnerabilidades tiene algunas dificultades. Para empezar no encaja con el planteamiento clásico (ITIL) de resolución de incidentes igual a restablecimiento del servicio, ya que no hay servicio degradado. Una vulnerabilidad no afecta al SLA del servicio, al menos no directamente. No obstante, los principios de la gestión de problemas sí que parecen encajar con la gestión que requieren las vulnerabilidades. ¿Cuál podría ser el detonante para este proceso?

Otros modelos de referencia tampoco terminan de encajar. Todos los que tienen implantados sistemas de gestión conocen la sistemática aplicable a las acciones preventivas, pero... ¿Es suficientemente ágil ese planteamiento para ser aplicado en relación a las vulnerabilidades técnicas? Teniendo en cuenta que ambas metodologías de gestión suelen quedar en manos de departamentos diferentes, tampoco parece una solución óptima.

Mi propuesta para la gestión de vulnerabilidades es hacer uso del proceso ITIL v3 de Gestión de Eventos. Este es un proceso en general infrautilizado, que se suele limitar a la monitorización de sistemas. Sin embargo, es un proceso que puede dar mucho más de si, tanto desde el punto de vista de la correlación de logs como desde el punto de vista de la gestión de vulnerabilidades.

Para empezar, la gestión de eventos es un proceso "interno" de un departamento TIC. Tiene vocación preventiva, y dos de sus principales salidas van hacia la gestión de problemas y la gestión de cambios. Por lo tanto, entre el propio proceso y aquellos con los que se relaciona se puede cubrir el ciclo completo de gestión de la vulnerabilidad:
  • Aparición --> Detección y Notificación --> Registro --> Análisis --> Aplicación de WorkAround --> Análisis de causa --> Parcheo --> Cierre
Además, desde el punto de vista de proceso con uso intensivo de soluciones tecnológicas, la gestión de eventos puede ser un proceso muy apropiado para ser revalorizado desde el punto de vista de la seguridad. Por un lado, es el proceso más apropiado para la introducción de soluciones de correlación de logs y SIEM. Por otro lado, también es una tentación la introducción de soluciones de auditoría automatizada de red, que refuercen el apartado de gestión de vulnerabilidades y se integren con las herramientas de gestión de incidentes y problemas.

En definitiva, la gestión de vulnerabilidades es un proceso peculiar, para el que los modelos de gestión más habituales no terminan de encajar, pero que puede encontrar en los procesos de ITIL v3 el formato más apropiado para introducirse de forma nativa en los procesos de operación TIC de cualquier organización.

A vosotros, qué os parece la propuesta? ¿Qué ventajas e inconvenientes le veis? Estaré encantado de leer vuestros comentarios.

22 mayo 2012

Publicada la nueva ISO 22301:2012

El pasado 15 de Mayo se llevó a cabo la publicación oficial de la nueva ISO 22301:2012, el esperado estándar que recoge los requisitos que debe cumplir un sistema de gestión de la continuidad del negocio. Esta norma, que viene a ser la evolución internacional de las normas BS 25999 -2:2007 / UNE 71599-1:2010, determina los requisitos que debe cumplir cualquier organización que quiera desarrollar un sistema capaz de gestionar de manera eficaz incidentes "graves" capaces de poner en riesgo su continuidad operativa.

La norma desarrolla, a lo largo de 7 apartados (aparte de los clásicos de introducción, referencias y terminología), los requisitos que debe cumplir un SGCN (Sistema de Gestión de la Continuidad del Negocio) en cada uno de sus ámbitos (contexto de la organización -alcance-, liderazgo -responsabilidades de la dirección-, planificación, soporte -designación de recursos-, operación, evaluación y mejora). Contiene todos los elementos de cualquier Sistema de Gestión ISO, aunque se echa de menos una mejor alineación con el marco de referencia desarrollado por ISO para los sistemas de gestión, al que sí se aproximan otras normas más veteranas.

Aunque no deja de ser una buena noticia, le sigo viendo un problema de base. ¿Podemos hablar de continuidad de negocio cuando sólo nos centramos en gestionar riesgos operativos? ¿Qué ocurre con otro tipo de riesgos (financieros, de mercado, regulatorios) que también son parte del negocio? Desde mi punto de vista, creo que el alcance de esta norma es, en sí mismo, su principal hándicap: demasiado grande para las consultoras de TI (que son principalmente las que han impulsado los SGCN hasta la fecha) y demasiado pequeño para las empresas de consultoría estratégica, que centran su actividad en otro tipo de riesgos. Pero los que realmente tienen que asumir los principios de este nuevo estándar son las empresas en general. ¿Cómo lo acogerán? ¿Verán claras sus ventajas? ¿O seguirán sin tenerlo claro? Lo veremos con el paso del tiempo...

21 mayo 2012

Seguridad, Transparencia y ENS

Hace casi dos años que en este mismo blog hablaba del borrador de la Ley de Transparencia. Desde entonces esta Ley ha sufrido muchos cambios, incluyendo varios borradores y un cambio de gobierno, hasta llegar a la situación actual (aunque en este momento el texto todavía no está actualizado con la última versión). Un anteproyecto de Ley que ha suscitado bastante polémica, y que probablemente lo siga haciendo durante su tramitación.

No obstante, mi objetivo en este post no es criticar el contenido del anteproyecto, sino analizar la estrecha relación entre Seguridad y Transparencia, y ver las consecuencias prácticas que puede tener esta Ley.

Por un lado, tenemos que tener en cuenta que el concepto de "transparencia" es precisamente el complementario al de "confidencialidad". Estamos hablando de lo mismo desde el punto de vista contrario. Por lo tanto, es necesario tener en cuenta que es una Ley que regula, en ciertos aspectos, la seguridad de la información de las Administraciones Públicas (os suena a algo relacionado con el ENS?).

Además, el concepto de transparencia también tiene cierta relación con la necesidad de garantizar la autenticidad de dicha información publicada, su integridad o su disponibilidad (aspectos que, de hecho, cobran mayor importancia cuanto más se deba permitir el acceso a dicha información).

Si profundizamos en la citada Ley, podemos ver cómo hace referencia a la información que debe ser pública (artículos 3 - 6 y 9), la que debe ser "publicable", con ciertas restricciones en su publicación (artículos 10-13) y la que no debe ser publicada (artículo 9). Establece, por tanto, 3 niveles de clasificación desde el punto de vista de la confidencialidad de la información, que podemos entender como 3 escalones de confidencialidad (podemos hablar de confidencialidad Baja/Media/alta?).

Bajo este punto de vista, creo que la relación con el Esquema Nacional de Seguridad es obvia. Estamos frente a una regulación con caracter de Ley, y que por tanto puede incluir este tipo de directrices (por lo que tengo entendido, el ENS, por ser un Real Decreto, y por tanto de inferior rango, no podía). Sin embargo, echo de menos alguna relación más específica con dicha regulación, y sobre todo una mejor explicación de los tipos de información que deben ser clasificados en cada uno de los ámbitos. Soy consciente de cierta deformación profesional a la hora de estructurar contenidos (un ingeniero suele tener la mente más cuadriculada que un jurista), pero... No hubiera sido conveniente establecer una "tabla" un poco más clara de los diferentes tipos de información que puede tener una Administración Pública y la clasificación asociada en cada caso? Y lo que es más importante... Será el texto actual una referencia válida para su utilización práctica por parte de quienes tienen que clasificar cada información? No lo tengo nada claro...

02 mayo 2012

Securmatica 2012

La semana pasada estuve en el congreso Securmática 2012. No pude asistir al congreso completo, aunque las pinceladas que me llevé creo que pueden ser suficientes para hacer un mini-diagnóstico del sector:
  • Se está poniendo de moda el término ciberseguridad, aunque no dejan de ser los mismos conceptos de siempre puestos al día.
  • El cumplimiento legal cada vez preocupa más a la empresa privada, que se ve cada vez más presionada pero sigue sin considerar que pueda ser aprovechado como ventaja competitiva.
  • Sigue existiendo una pugna filosófica entre los partidarios de la seguridad por oscuridad y los defensores del full-disclosure, que tengo la sospecha que no es tan grave a nivel práctico (una vez que se considera el dinero dentro de la ecuación).
  • El precio va a ser un fuerte impulsor de los servicios cloud y el software libre aplicado a la seguridad durante los próximos años... Pero muchos no van a conocer el significado real de lo que están comprando.
  • La gestión de vulnerabilidades puede empezar a ser un nicho de negocio en sí mismo, con múltiples variantes y posibilidades.
  • Todo el mundo empieza a vender inteligencia en seguridad... y yo no veo mucho más que correlación de eventos.
En definitiva, tengo la sensación de que el sector ha invertido mucho en marketing en los últimos años, reinventando nombres para los principios de toda la vida, pero sin que haya habido un salto diferencial en la evolución real. No obstante, hay que reconocer que los nuevos términos están sirviendo para vender más seguridad a más gente, que en el fondo es el objetivo de todo esto. Por tanto... bienvenido sea el medio, si se acaba consiguiendo el fin.

Y para no perder la ola, yo también aproveché el congreso para estrenar mi nueva cuenta de twitter @JosebaEnjuto. Así que si quieres seguirme... Ahora también estoy en twitter!

23 abril 2012

Anonimato on-line

Hace unos días leí una noticia que me pareció bastante interesante. Parece que Google quiere patentar los "perfiles fantasma", una especie de perfil virtual asociado al personal y que se podría utilizar para navegar con múltiples identidades (o con identidad anónima) por la web, con la capacidad de mostrar esos alter-ego a quien nosotros decidiésemos.

La idea, de ser correcto el planteamiento, me parece muy interesante. Por un lado, existiría la capacidad de crear identidades virtuales permanentes específicas por entorno, de modo que sería posible aislar la actividad on-line profesional y privada, por ejemplo, manteniendo un control uniforme sobre ambas. Por otro lado, sería posible crear perfiles completamente anónimos, de modo que los más paranoicos pudieran hacer uso de múltiples perfiles zombi para sentir su intimidad a salvo. Y además cabría la posibilidad de "descubrir" esas múltiples identidades a personas específicas, gestionando de forma dinámica la pertenencia de cada "amigo" a los diferentes círculos (o a varios de ellos).

En cualquier caso, es obvio que siempre quedaría una duda. Si esos perfiles están relacionados entre sí a través de una herramienta proporcionada por Google... No podría Google trazar la actividad completa de todos los perfiles en conjunto en un momento dado? En definitiva... ¿Creemos que a día de hoy Google mantiene en vigor su famoso lema "don't be evil"?

10 abril 2012

Internet: lo que no vemos

En vacaciones mucha gente cambia su comportamiento on-line. Dejamos de lado las webs profesionales y las sustituimos por webs de viajes, de juegos on-line, de ocio en general... Nuevas páginas web, más interesantes y atractivas que las habituales... y muchas veces más peligrosas.

En general, no somos conscientes de la cantidad de tráfico web que generamos con nuestra navegación. Y no me refiero al contenido de las webs que visitamos, sino a la cantidad de información que genera nuestra navegación, y que sirve para monitorizar nuestro comportamiento. Pongamos como ejemplo las páginas web de tres medios de comunicación generalistas:
  • ABC: Proporciona información a 3 redes de anunciantes (Dedicated Networks, Nielson y TradeDoubler) y a 5 compañías específicas (Doubleclick, Comscore Beacon, Netratings Site Census, Google Analytics y ChartBeat) que rastrean la información de los visitantes.  
  • El Mundo: Proporciona información a 4 redes de anunciantes (AudienceScience, Dedicated Networks, Nielson y TradeDoubler) y a 4 compañías específicas (Doubleclick, Omniture, Netratings Site Census y Revenue Science) que rastrean la información de los visitantes.
  • El País: Proporciona información a 4 redes de anunciantes (24/7 Real Media, Dedicated Networks, Invite Media y Smart Adserver) y a 5 compañías específicas (Doubleclick, Omniture, Real Media, Invite Media y Comscore Beacon) que rastrean la información de los visitantes.
 Y eso no es todo. Estas compañías no sólo recopilan información sobre los visitantes de las webs, sino que la utilizan para ofrecer anuncios e información personalizada en función de esa información recopilada. Anuncios habitualmente en forma de banner que, en muchos casos, se cargan de forma dinámica desde las páginas web de los propios anunciantes o de compañias intermediarias.

Qué quiere decir esto? Que cada vez que accedemos a una página web (prácticamente a cualquiera), no sólo estamos cargando información de esa web, sino de muchas otras, y a la vez enviando información sobre nosotros a una gran variedad de destinatarios diferentes al dueño de la web visitada.

Toda esta navegación "encubierta" puede suponer un importante riesgo para nuestra privacidad e incluso para nuestra seguridad. Por tanto, cuantas más webs visitemos más probabilidades habrá de toparnos con una empresa anunciante "poco ética", que utilice esa información de manera ilegítima. Probabilidades que aumentan al visitar webs más minoritarias, que generalmente se preocupan menos de la ética de las empresas de anuncios contratadas. Y este problema puede llegar a ser un problema de seguridad, porque aunque la página visitada pueda ser en principio segura (y en general las de la mayoría de las empresas conocidas lo son), basta que una de las webs de los anunciantes haya sido infectada para que los banners que se cargan desde la web principal puedan contener un virus que a través de esa web llegue a nuestro ordenador.

Por lo tanto, la conclusión es muy sencilla. En vacaciones, extremar las precauciones.

29 marzo 2012

Riesgos y responsabilidad

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?

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?

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?

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í?

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

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.

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í!

14 febrero 2012

Seguridad y regimen interno

Supongo que todos los lectores del blog habrán leido (y puede que incluso redactado) más de una Política de Seguridad. En definitiva, no es más que un documento en el que se recogen cuáles son los criterios y directrices de una organización en materia de seguridad. Uno de los ejemplos probablemente más conocidos, para todo aquél que quiera una referencia específica, es el modelo de Política de Seguridad de la Información para la Administración Pública argentina. No obstante, muchas organizaciones suelen optar por planteamientos algo más reducidos y específicos, más enfocados a sus necesidades... y algunas veces, demasiado enfocados. Me explico.

No son ni uno ni dos los casos en los que me he encontrado con políticas y/o normativas de seguridad que prohiben la navegación por sitios de contenido "inapropiado" (lease pornográfico, por ejemplo). Y me pregunto: ¿qué tiene que ver la seguridad con la pornografía? ¿Acaso la visualización de un vídeo o una imagen de contenido pornográfico va a provocar un incidente de seguridad que no se hubiera producido si el contenido de esa imagen o vídeo hubiera sido diferente? Algunos argumentarán que las páginas de contenido pornográfico se utilizan para alojar malware, pero la realidad es que ya hace bastante tiempo que el malware se distribuye de igual forma por páginas de contenido pornográfico que por webs de cualquier otra temática. 

Lo que quiero resaltar con este ejemplo, que me parece el más evidente (aunque igualmente podríamos hablar de webs de juegos online, diarios deportivos o cualquier otro tipo de contenido), es que a veces caemos en el error de mezclar la seguridad de la información con los reglamentos de régimen interno, las directrices sobre seguridad de la información con otras únicamente relacionadas con la productividad o la imagen de marca. Es cierto que en muchos casos ambos mundos se regulan mediante el establecimiento de normas de conducta, pero puede llegar a ser un peligro para la profesión que se utilice la seguridad como excusa para meterse en temas mucho más delicados y, sobre todo, conflictivos.

Con esto no quiero decir que ambos mundos sean totalmente independientes. El uso de redes sociales en el puesto de trabajo, por poner un ejemplo, puede tener tanto implicaciones en términos de seguridad de la información como en términos de productividad, y a la hora de regular la conducta en dichos ámbitos no tiene mucho sentido práctico que existan duplicidades documentales. No obstante, creo que es importante que, más allá de la materialización práctica de las directrices, toda la organización sea consciente de qué ámbitos son responsabilidad de la función de seguridad y cuáles lo son del departamento de recursos humanos, con el fin de que ni haya malentendidos entre el personal ni se acaben produciendo conflictos internos entre las diferentes áreas. Como dice la sabiduría popular, "zapatero, a tus zapatos". Por algo será, no?

31 enero 2012

ISO 20000 de alcance global

Como ya comenté en su momento, la nueva ISO 20000 (ahora también UNE-ISO/IEC 20000-1:2011, desde el pasado 21 de Diciembre) introduce importantes cambios, siendo el principal la "universalización" de su alcance, puesto que se elimina el término TI y se convierte en aplicable a cualquier tipo de servicios.

La versión española de la norma incluye, además, un anexo informativo en el que se relacionan, en forma de tabla de correspondencia, los apartados de la ISO 20000 con los apartados de la ISO 9001. Y si se analizan uno por uno... Sorpresa! Prácticamente todos los apartados de la ISO 9001 encuentran una relación directa con los apartados de la ISO 20000.

¿Qué quiere decir esta correspondencia? A mí se me ocurren dos consecuencias interesantes. La primera, que cualquier SGS (Sistema de Gestión de Servicios) certificado bajo ISO 20000 requiere de muy poco trabajo adicional para cumplir con los requisitos de la ISO 9001, y por lo tanto ser certificable por ella como SGQ (Sistema de Gestión de la Calidad). Y la segunda, vista en la dirección contraria, que cualquier empresa de servicios (una mayoría a nivel nacional) certificada en ISO 9001 podría utilizar la ISO 20000:2011 como modelo de referencia para el despliegue de sus procesos de soporte.

Teniendo esto en cuenta, y sabiendo que la mayor parte de las organizaciones han adoptado un enfoque global para la certificación ISO 9001, la consecuencia es clara: a futuro, el sistema de gestión propuesto por la ISO 20000 debería tender a un alcance global, en el que cualquiera de los servicios de la organización se gestione a través del modelo de procesos propuesto por el estándar, de modo que fuesen procesos transversales. Es cierto que antes de dar este paso tendremos que ser capaces de soltar el lastre TIC que todavía fluye por las venas de la ISO 20000, de forma que adaptemos los conceptos tecnológicos a la filosofía de gestión clásica, la aplicable de manera general a los procesos de negocio (por ejemplo, tendremos que asumir que, en un caso general, la gestión de la capacidad es más gestión de recursos humanos que otra cosa). Sin embargo, una vez que consigamos dar ese paso, nos daremos cuenta de que el modelo de gestión propuesto por la ISO 20000 es mucho más completo y eficaz que el levemente esbozado por la ISO 9001 a la hora de gestionar servicios. Aunque no creo que lleguemos a ver, ni siquiera en un futuro lejano, cómo la ISO 20000 sustituye a la ISO 9001 en las empresas de servicios (el peso -y poso- de la ISO 9001 a nivel mundial es demasiado grande), sí que creo que podremos contemplar, de aquí a unos años, cómo la ISO 20000 va calando en las empresas de servicios, que irán adoptando progresivamente ciertas prácticas de gestión derivadas de esa norma, si no el modelo de gestión completo.

27 enero 2012

Protección de datos europea

Hace unos días recibíamos la noticia de que esta misma semana íbamos a poder ver las nuevas propuestas europeas de protección de datos personales. Se hablaba de notificaciones públicas de incidentes de seguridad sufridos, de multas proporcionales a los ingresos, de derecho al olvido... ¿Qué había de cierto en esos adelantos?¿Cuál iba a ser el conetenido exacto de las propuestas?

Finalmente, el pasado miércoles la Comisión Europea publicaba la propuesta de reforma general de las normas de protección de datos europeas. Los rumores se confirmaban, con algunos detalles específicos como la cuantía máxima de las multas (1M€ o el 2% de la facturación anual) o la previsión de desarrollo de una directiva específica para el mundo policial y judicial. La nota de prensa oficial presentaba la propuesta como un gran avance para los ciudadanos y un importante ahorro para las empresas, aunque al parecer hay fuentes que creen que la propuesta no sólo incorpora luces en su contenido, sino que también incluye algunas sombras. De hecho, ya ha habido empresas que se han mostrado contrarias a esta nueva normativa, aduciendo que provocará importantes pérdidas económicas.

Desde mi punto de vista, creo que es demasiado pronto como para posicionarse en torno a esta nueva normativa. A partir de ahora se abren dos años de discusiones en el Parlamento Europeo, en los que seguro que se introducen cambios en el texto. Muchos detalles serán modificados, y es posible que incluso pueda desaparecer alguna de las grandes líneas de actuación presentadas, a causa de los diversos intereses que confluyen en este ámbito. Por lo tanto, no creo que este sea el momento para preocuparse de detalles que probablemente variarán, sino para alegrarse de que finalmente vea la luz una iniciativa para actualizar y armonizar la protección de datos personales a nivel europeo. Y qué mejor fecha para celebrar esta iniciativa que este sábado, no?

25 enero 2012

Seguridad industrial

A estas alturas, hablar de la seguridad en torno a los sistemas de control industrial no es nada novedoso. Stuxnet supuso el punto de inflexión, el hito a partir del cual la industria comenzó a prestar más atención a la seguridad en este tipo de entornos. Se había demostrado que era posible atentar contra la población civil a través de Internet, y era imposible que la sociedad no reaccionase ante tal constatación.

Sin embargo, que el verano de 2010 fuese el detonante de los cambios en la concepción de la seguridad en torno a los sistemas SCADA no quiere decir que año y medio más tarde la situación real haya cambiado mucho. Cualquier cambio tecnológico de envergadura es lento, y la adopción de nuevas tecnologías en este tipo de entornos industriales lo es todavía más. No obstante, iniciativas como la publicación de fallos de seguridad en sistemas SCADA llevada a cabo en el S4 demuestra que la concepción de la seguridad en este tipo de entornos está cambiando, pareciéndose cada vez más a la existente en el mundo TIC "clásico", el conectado a Internet. Ver cómo prácticas como el full disclosure empiezan a abrise camino en el cerrado mundo de los sistemas de control industrial es una prueba de que la seguridad empieza a tener la relevancia que se merece.

En cualquier caso, no es momento de echar las campanas al vuelo. Una compañía como Microsoft ha tardado casi diez años en integrar la seguridad en sus desarrollos, y ha necesido desarrollar una iniciativa global específica para seguridad y desarrollar dos nuevos sistemas operativos (desde el Windows XP hasta el Windows 7, sin contar el Windows XP SP2) para conseguir un entorno que puede considerarse aceptablemente seguro. Vistos los antecedentes, no creo que podamos esperar grandes revoluciones de los fabricantes de productos SCADA, y mucho menos de empresas que a día de hoy utilizan versiones de estos productos que funcionan sobre equipos Windows 98 o incluso anteriores. No obstante, las bases poco a poco se están asentando, de modo que quizás dentro de 10 años alguien pueda escribir, en torno a estos productos, un artículo similar al referenciado para Microsoft.

16 enero 2012

ISO 20000 y ENS

En mi último post sobre el ENS y la mejora continua incluía al final un breve apunte para la reflexión, acerca de los estándares de referencia que podrían ser utilizados para cumplir con las exigencias del Esquema Nacional de Seguridad. ¿Es necesariamente la ISO 27001 la mejor referencia para su implementación?

La verdad es que las analogías entre la ISO 27001 y el ENS son tantas que parece obvio tomar este estándar como referencia para la implantación de un "buen" ENS. Sin embargo, creo que esa facilidad en el paralelismo ha hecho que no nos preocupemos en buscar alternativas, en ser críticos y plantearnos seriamente la existencia de otras opciones. ¿Qué supondría basar una implementación de un ENS en la implantación de un SGSTI (Sistema de Gestión de Servicios TI) que cubra los servicios electrónicos prestados por una administración pública?

Uno de los procesos que forman parte de un SGSTI que cumpla con la ISO 20000 es el proceso de gestión de la seguridad. Por lo tanto, el desarrollo de un proceso de gestión de la seguridad de la información tal y como establece el ENS estaría directamente contemplado. Este hecho supone, además, que podemos articular a través de él todas las medidas de seguridad que requiere el ENS. Aunque... son realmente tales las medidas de seguridad del Anexo II?

Desde mi punto de vista, una gran cantidad de medidas de seguridad propuestas por el ENS no lo son estrictamente hablando. O dicho de otra forma (antes de que los más puristas se lleven las manos a la cabeza), son antes medidas de "gestión correcta de las TIC" que medidas de seguridad. Actividades como la gestión de la capacidad, la gestión de la configuración,  el mantenimiento de los sistemas, la gestión de cambios, la gestión de incidentes, el acondicionamiento de los locales, la formación al personal, la gestión de medios removibles u otras de similares características no son patrimonio exclusivo de la seguridad. Todas estas actividades son necesarias en cualquier organización que quiera prestar servicios TIC de calidad, independientemente de que la seguridad sea o no una preocupación expresa. Y la ISO 20000 establece un modelo general de gestión de servicios TIC mucho más completo que el propuesto por la ISO 27001. ¿No sería, por tanto, mejor opción utilizar el modelo de gestión propuesto por la ISO 20000 como referencia para el cumplimiento de los requisitos del ENS?

Por supuesto, en términos de eficiencia es fácil encontrar una objeción a este planteamiento. Dado un mismo alcance, desplegar un SGSI (Sistema de Gestión de la Seguridad de la Información) conforme con ISO 27001 es más sencillo, fácil y rápido que desplegar un SGSTI que cumpla con ISO 20000. En los tiempos que corren, la premisa general de reducción de costes vigente en todas las administraciones públicas es un argumento contundente a favor del modelo basado en ISO 27001. No obstante, también es habitual encontrar en los objetivos de muchas administraciones públicas una gran cantidad de iniciativas relacionadas con la búsqueda de la excelencia, de altas cotas de calidad en los servicios ofrecidos, etc. Si ofrecer servicios de calidad es uno de los eslóganes más repetidos, por qué no utilizar como modelo de referencia el estándar más completo? Quizás no sea tiempo de correr, y la ISO 27001 pueda ser un primer paso, pero... por qué no utilizar la sistemática de mejora continua para que la evolución cubra no sólo las propias medidas de seguridad, sino también el modelo de gestión seleccionado?

09 enero 2012

ENS y la mejora continua

Hace algunos años era habitual que existieran empresas que vendían "malas adecuaciones" a la ISO 27001. Empresas que lo que hacían era diseñar proyectos de implantación sistemática de los 133 controles que componen el Anexo A de la norma, es decir, implantaban la ISO 27002. Eran proyectos que se olvidaban de la parte fundamental de la ISO 27001, del cuerpo de la norma: la gestión de riesgos, la mejora continua, el compromiso de la dirección... Afortunadamente, en la actualidad esa situación prácticamente ha sido desterrada por completo (aunque ahora existan casos en los que se da el caso contrario, pero bueno, eso es otra cuestión).

Sin embargo, a veces tengo la sensación de que en la actualidad se está dando una situación similar con el Esquema Nacional de Seguridad. En cierto modo, tengo una sensación de deja-vu al ver que, en muchos casos, cuando se habla del ENS se piensa automáticamente en su Anexo II, en el catálogo de medidas de seguridad que incorpora, obviando (al igual que en el caso anterior) la parte fundamental del documento, el cuerpo del Real Decreto: los principios básicos y requisitos mínimos que debe cumplir la política de seguridad de cualquier administración pública. ¿No aprendemos de los errores del pasado?

Digo esto porque una de las carencias que se le suelen achacar al ENS, desde mi punto de vista de manera completamente errónea, es que no contempla la mejora continua. Es más, yo creo que la contempla de manera explícita y bastante completa:
  • Uno de los principios básicos de la seguridad es su reevaluación periódica (Art.9), donde establece la necesidad de reevaluar las medidas de seguridad hasta replantear la seguridad de forma completa si fuera necesario.
  • Uno de los requisitos mínimos de la seguridad es la mejora continua del proceso de seguridad (Art. 26), donde se exige la actualización y mejora continuas del proceso integral de seguridad, aplicando para ello mecanismos reconocidos a nivel nacional e internacional.
¿No es suficiente con esa referencia? Está claro que no establece ningún tipo de sistemática de mejora continua, ni regula la gestión de mejoras mediante la articulación de acciones preventivas y/o correctivas como hacen los estándares ISO de gestión, pero... es necesario?

Y como tema adicional de reflexión, por si alguien le quiere dar una vuelta: el citado artículo 26 habla de mecanismos reconocidos relativos a gestión de las tecnologías de la información, no relativos a gestión de riesgos o gestión de la seguridad. ¿Qué lectura hacéis de este hecho?

03 enero 2012

ENS, ENI y sociedades públicas

A estas alturas no creo que ninguno de los lectores de este blog desconozca la Ley 11/2007 (LAECSP) ni los Reales Decretos que se derivan de ella (ENS y ENI, respectivamente). Pero sí que me gustaría abordar una cuestión sobre la que muchos pasan de puntillas, pero que me parece muy importante: ¿Aplican estas regulaciones a las sociedades públicas?

Uno de los análisis "oficiales" más profundos que conozco respecto de la aplicabilidad del ENS es el realizado por el CCN en sus FAQ. En ellas viene a decir que, en el ámbito de las sociedades públicas, cada caso es diferente y que hay que analizarlos uno por uno. Sin embargo (y disculpad mi osadía, supongo que se debe a que no soy jurista), yo tengo la sensación de que hay muchas similitudes entre ellas, y que se pueden establecer algunas pautas generales.

En general, yo soy de la opinión de que TODAS las sociedades públicas DEBEN CUMPLIR con el ENS/ENI. Al menos, en parte de sus servicios. Me explico.

Hasta donde yo sé (y espero que si hay algún jurista que lea esto y detecte algún error, me lo notifique), todas las sociedades públicas están sujetas al régimen de licitación pública. Y ese régimen entiendo que es un derecho de los ciudadanos y/o un deber de las administraciones públicas. Por lo tanto, debería ser accesible electrónicamente según la Ley 11/2007 (de hecho, la mayoría de las sociedades públicas tienen un "perfil del contratante" en Internet)... y por consiguiente, debería cumplir con el ENS y el ENI. Al menos, el servicio de licitaciones públicas debería hacerlo.

Por otro lado, entiendo que cualquier sociedad pública cuyos servicios impliquen la concesión de becas, subvenciones y/o ayudas económicas utilizando dinero público también realiza esa concesión de dinero en régimen de derecho público... y de nuevo dicho servicio de concesión de ayudas debería estar sujeta a la LAECSP y por tanto al ENS y al ENI.

En definitiva, creo que hay una gran cantidad de sociedades públicas cuyos servicios se prestan en régimen de derecho público y que implican la interacción con los ciudadanos y el ejercicio de derechos y/o deberes. Y lo que me parece destacable es que, hasta donde yo sé, tengo la sensación de que el sector está pasando de puntillas sobre este hecho... dejando pasar oportunidades de negocio y dejando sin las garantías asociadas a dicho cumplimiento legal a los ciudadanos que utilizan dichos servicios.