tag:blogger.com,1999:blog-339466542024-03-16T02:09:38.035+01:00Seguridad y GestiónBlog sobre gestión de la seguridad de la información, en el que también se habla de continuidad de negocio, gestión de los servicios IT, seguridad informática, gestión de riesgos, ética de la seguridad, y muchos otros temas relacionados. Aquí encontrareis apuntes sobre ISO 9001, ISO 27001, ISO 17799, ISO 20000, ITIL, BS 25999, ... En resumen, todo lo que pueda tener relación con la gestión (en general) y con la seguridad (en particular)Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.comBlogger342125tag:blogger.com,1999:blog-33946654.post-13261413466782858032014-05-15T15:31:00.002+02:002014-05-15T15:31:46.474+02:00Ni Google ni AEPD: La tercera víaEstoy seguro de que a estas alturas todo el mundo ha oído hablar del <a href="http://curia.europa.eu/juris/document/document.jsf?text=&docid=152065&pageIndex=0&doclang=ES&mode=lst&dir=&occ=first&part=1&cid=97297">fallo del TJUE contra Google</a> en relación al llamado "derecho al olvido". Las noticias sobre <a href="https://www.google.es/#q=derecho+al+olvido&tbm=nws">Google y el derecho al olvido</a> han llegado prácticamente a colapsar los temas de debate de los últimos días en los foros especializados. Sin embargo, estoy bastante decepcionado con todas las aproximaciones que he leído al respecto, ya que, tanto a favor como en contra, se limitan (en los mejores casos) a cuestionar los argumentos, pero sin plantear alternativas.<br />
<br />
Personalmente, reconozco que la sentencia me ha sorprendido. Sin entrar en términos técnicos, los buscadores son meros intermediarios, y aceptar que la defensa de la privacidad se puede dirigir contra el mensajero (en lugar de dirigirse contra quien publica realmente la información) me parece peligroso. Si el intermediario tiene que dejar de ser neutral... es cuestión de tiempo que esa falta de neutralidad de subvierta.<br />
<br />
Sin embargo, esto no quiere decir que el buscador no tenga ninguna responsabilidad. Obviamente es él quien ordena la información antes de mostrársela al usuario, en base a sus famosos (aunque <a href="http://deteresa.com/cambios-algoritmo-google/">desconocidos</a>) algoritmos, y por lo tanto quien decide la relevancia del contenido. Y en esa relevancia, en ese orden, creo que es donde puede estar la tercera vía.<br />
<br />
En el fondo, olvidar es un proceso natural por el cual nuestros recuerdos van siendo enterrador debajo de otros más recientes, de forma que cada vez sean menos patentes. Mi propuesta sería tan simple (de entender, al menos) como exigir que los buscadores incorporasen en su algoritmo un proceso similar, por el cual el contenido "antiguo" es progresivamente relegado a un puesto inferior en la lista de resultados según va pasando el tiempo. De este modo, el contenido no desaparece, pero sólo quien esté suficientemente interesado en "recordar" va a ser capaz de llegar a la información que busca (o a encontrarse con ella).<br />
<br />
De hecho, este planteamiento ni siquiera es nuevo para Google. En su motor de búsqueda de noticias, <a href="https://www.google.es/#tbm=nws">Google News</a>, ya incorpora esta funcionalidad. ¿Por qué no adoptar el mismo planteamiento? No sólo estarían favoreciendo el "derecho al olvido", sino que además estarían aproximando el funcionamiento del algoritmo al funcionamiento del cerebro humano. ¿No os parece que ganamos todos?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com51tag:blogger.com,1999:blog-33946654.post-80028741547265584842014-04-07T15:12:00.000+02:002014-04-07T15:12:00.062+02:00No te defiendas. RecupérateReconozco que últimamente no me prodigo mucho en el blog. La verdad es que llevo una temporada bastante ocupado... pero hoy quiero compartir con todos vosotros uno de los temas que me están manteniendo ocupado estos últimos tiempos.<br />
<br />
Los que leéis el blog habitualmente ya sabréis que llevo bastante tiempo dándole vueltas a la idea de que la seguridad, tal y como se plantea a día de hoy, está condenada al fracaso. A lo largo de la historia hemos levantado muros, portado escudos, instalado firewalls o desplegado antivirus con el fin de protegernos frente a los ataques... sabiendo que, tarde o temprano, nuestras defensas iban a ser inevitablemente vulneradas. Día tras día comprobamos eso de que la seguridad total es imposible... y pese a todo nos seguimos empeñando en tratar de alcanzarla.<br />
<br />
Frente a este planteamiento, un poco ilógico si lo pensamos fríamente, quiero abogar por un cambio total de paradigma. Sabemos que los incidentes de seguridad son inevitables. Algunos serán leves, otros más graves, y unos pocos requerirán, por su extrema gravedad, la activación de nuestros planes de contingencias. ¿Y si tomamos esta situación como punto de partida para nuestro planteamiento frente a la seguridad?<br />
<br />
La propuesta se resume en el título del post: dejemos de centrar nuestros esfuerzos en evitar lo inevitable, y enfoquémoslos en minimizar su impacto. Asumamos que vamos a tener incidentes de seguridad, y tratemos de garantizar que, pase lo que pase, el daño que provoquen sea mínimo. Orientemos nuestras medidas de seguridad hacia la reducción de la criticidad de los propios activos, en lugar de dedicar recursos a preservarla.<br />
<br />
La teoría dice que los incidentes de seguridad pueden afectar a la disponibilidad, a la integridad o a la confidencialidad de nuestros activos. Pero en la práctica esto se reduce a una casuística muy sencilla: podemos perder (porque se paran) nuestros servicios, podemos perder (porque desaparece o porque se corrompe o modifica incorrectamente) la información o se puede difundir (de forma no autorizada) esa información. Si el objetivo es minimizar la gravedad de que eso ocurra, el planteamiento pasaría por:<br />
<br />
<ul>
<li>Tener servicios replicados, de forma que la caída de uno no suponga un problema ya que hay un servicio idéntico funcionando. Esto no sería estrictamente tener servicios en alta disponibilidad, sino tener múltiples servicios idénticos. </li>
<li>Que la información sea lo más volátil posible, que tenga "fecha de caducidad". </li>
<li>Que la información sea lo más abierta y pública posible.</li>
</ul>
No obstante, mi propuesta es ir un paso más allá. No propongo que dejemos de protegernos de los incidentes, sino que los provoquemos intencionadamente. Frecuentemente. Qué pasaría si todas las semanas tiramos nuestros servicios? Si todas las semanas eliminamos nuestra información? Si todas las semanas divulgamos en Internet nuestra información? Cómo actuaríamos? Qué cambiaríamos en nuestra seguridad para lidiar con estas situaciones?<br />
<br />
Si nos acostumbramos a gestionar incidentes graves de manera habitual nuestras medidas de seguridad nos garantizarán no sólo que nuestros servicios (y por tanto nuestro negocio) son resilientes, sino que acabaremos centrando nuestros recursos en aquello que realmente es lo importante, y seremos capaz de lidiar de manera tan habitual con este tipo de incidentes que dejarán de ser graves. Siendo menos seguros habremos conseguido ser más seguros. Contrasentido? Un poco. Arriesgado? Por supuesto. Utópico? Puede ser. Pero... Y si funciona?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-72941116862857468172014-02-18T16:59:00.000+01:002014-02-18T16:59:14.621+01:00Esteganografía informativa: defendiendo la privacidad ante el Big DataReconozco que el título del post no es "apto para todos los públicos", pero creo que resume bastante bien el planteamiento que quiero recoger en este post.<br />
<br />
Cada vez es más complejo mantener unos niveles de privacidad elevados en el mundo digital. Bien sea porque nosotros mismos no nos preocupamos por nuestra privacidad, porque la "vendemos" a cambio de servicios o porque directamente hay empresas y/o gobiernos que se encargan de limitarla, la privacidad en el mundo digital es cada vez más ilusoria. Nuestro rastro digital, queramos o no, cada vez es más nítido. Y por si fuera poco, cada vez surgen tecnologías más capaces de rebuscar en ese confuso mar de datos inconexos para extraer información útil que, generalmente, suele estar ligada a nuestra identidad digital. El <a href="http://es.wikipedia.org/wiki/Big_data">Big Data</a> no sé si es el presente, pero claramente es el futuro.<br />
<br />
El objetivo de la privacidad es, precisamente, el contrario: evitar que la información sobre nuestra identidad digital salga a la luz. Pero como en cualquier otro caso, la defensa siempre va por detrás del ataque. Ocultar nuestros datos mientras otros intentan descubrirlos es una batalla asimétrica en la que siempre vamos a ir varios pasos por detrás.<br />
<br />
Frente a este planteamiento, basado en el principio clásico de <a href="http://es.wikipedia.org/wiki/Seguridad_por_oscuridad">seguridad por oscuridad</a>, mi propuesta es buscar una alternativa diferente, más en línea con los planteamientos de la seguridad abierta. No obstante, la idea no es nueva. Hay mucha gente que no se preocupa por su privacidad digital porque se considera "una gota en el océano". ¿Y si pudiéramos utilizar ese planteamiento para asegurarnos, de algún modo, que el océano es tan grande que nadie va a poder identificar nuestra gota? Es más... ¿Y si generásemos datos ficticios en forma de <a href="http://es.wikipedia.org/wiki/Progresi%C3%B3n_geom%C3%A9trica">progresión geométrica</a> cada vez que se intenta acceder a un dato ligado a nuestra identidad digital?<br />
<br />
La idea de ocultar una serie de datos válidos rodeándolos de datos no válidos es precisamente lo que se conoce como <a href="http://es.wikipedia.org/wiki/Esteganograf%C3%ADa">esteganografía</a>. La única diferencia sería que en este caso no nos limitaríamos a rodear los datos válidos de datos falsos, sino que dispondríamos de algún sistema capaz de incrementar exponencialmente la cantidad de datos falsos, de modo que se pudiera limitar en gran medida la eficacia de los sistemas de Big Data a la hora de analizar nuestra información personal.<br />
<br />
Por supuesto, como todas las buenas ideas, esta no es mía. Simplemente he tratado de extrapolar los principios de un nuevo sistema de "cifrado", <a href="http://www.technologyreview.es/read_article.aspx?id=44695">Honey Encryption</a>, que descubrí hace unos días, pero cuyos principios no sólo me parecen enormemente innovadores, sino que creo que tienen un prometedor futuro por delante. Ójala veamos en un futuro avances en este tipo de planteamientos... porque creo que por ahí puede venir el futuro de una parte de la seguridad.Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com3tag:blogger.com,1999:blog-33946654.post-34918276541240670422014-01-30T15:04:00.001+01:002014-01-30T15:04:49.684+01:00ENS: El día D ha llegadoEl Esquema Nacional de Seguridad <a href="http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE-A-2010-1330.pdf">se publicó en el BOE el 29 de Enero de 2010</a>, por lo que entró en vigor el 30/01/2010, tal y como establece su disposición final tercera. No obstante, en su disposición transitoria establecía que los sistemas de información existentes en ese momento tenían un plazo de 12 meses para adecuarse a sus exigencias, que podía ser ampliado hasta los 48 meses si existían circunstancias que impidiesen su plena aplicación y se dispusiera de un plan de adecuación aprobado.<br />
<br />
Hoy es 30 de Enero de 2014, de modo que se acaban de cumplir los 48 meses del plazo máximo admitido para que las Administraciones Públicas cumplan con el ENS. ¿Cuál es la situación actual?<br />
<br />
La mejor forma de analizar el cumplimiento del ENS es acudir al Artículo 41 del Real Decreto, que establece que los organismos públicos tienen que publicar en sus respectivas sedes electrónicas las correspondientes declaraciones de conformidad, diciendo que cumplen con todas las exigencias del ENS (y esta es una de ellas). De hecho, incluso existe una guía específica (<a href="https://www.ccn-cert.cni.es/publico/seriesCCN-STIC/series/800-Esquema_Nacional_de_Seguridad/809-Declaracion_de_conformidad_ENS/809-Declaracion_de_conformidad_ENS-jul10.pdf">CCN-STIC-809</a>) que establece cuál debe ser el contenido de dicha declaración de conformidad.<br />
<br />
Dicho esto... cuál es la situación? Pues bien, después de recurrir a la <a href="https://www.google.es/search?q=%22declaraci%C3%B3n+de+conformidad%22+esquema+nacional+de+seguridad">clásica búsqueda</a> y de analizar la información de la web <a href="http://www.cumplimientoens.es/">www.cumplimientoens.es</a>, el resultado es:<br />
<br />
<ul>
<li>Sólo un organismo público en todo el estado, <a href="https://sede.dip-badajoz.es/ficheros/declaracion_conformidad_diputacion_ENS.pdf">la diputación de Badajoz, cumple con las exigencias del Esquema Nacional de Seguridad</a>. </li>
</ul>
<br />
Vaya por delante mi más sincera enhorabuena a la Diputación de Badajoz, aparentemente único organismo público de los más de 8.000 en todo el estado que ha cumplido con su obligación legal en materia de seguridad de la información, y al que todos deberíamos agradecer el habernos salvado del bochornoso 0. Ahora bien... Un 0,01% debería ser aceptable?<br />
<br />
No quiero meter el dedo en la llaga, puesto que los datos (incluso aunque no haya sido capaz de localizar unos cuantos casos más) son bastante elocuentes. Sin embargo, sí que creo que los datos deberían servir para reflexionar acerca del motivo por el cual hemos llegado a esta situación. Y se me ocurren varias alternativas:<br />
<br />
<ul>
<li><b>Plazo insuficiente</b>: El punto de partida era tan malo que no ha dado tiempo a cumplir con todas las exigencias. </li>
<li><b>Exigencia excesiva</b>: Había que llegar a un nivel de seguridad tan alto que no somos capaces de alcanzarlo. </li>
<li><b>Presupuesto insuficiente</b>: Requiere tal cantidad de productos de seguridad que el presupuesto no ha sido suficiente para adquirirlos e integrarlos a tiempo. </li>
<li><b>Medios propios insuficientes</b>: Requiere tal cantidad de dedicación de personal interno para conseguir la adecuación que no se ha podido sacar el tiempo suficiente para realizar la adecuación. </li>
<li><b>Concienciación insuficiente</b>: La seguridad preocupa tan poco que no se ha sido capaz de priorizarlo lo suficiente como para conseguir los recursos necesarios para la adecuación.</li>
</ul>
A mi se me ocurren estos como los motivos principales para que un organismo público no haya concluido su adecuación al ENS. ¿Cuáles pensáis vosotros que son los más importantes? ¿Cuál ha sido vuestro caso?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-5849663996452847722014-01-13T15:10:00.000+01:002014-01-13T15:10:50.109+01:00Mi pronóstico: InseguridadNo, no voy a escribir un post de pronósticos de seguridad para el año 2013. Hoy sólo quiero plantear cuál es mi visión del futuro que nos espera, aprovechando que esta mañana he leído un par de artículos muy interesantes y que, en conjunto, me temo que plantean una visión bastante pesimista del futuro que nos espera en términos de seguridad.<br />
<br />
El primero es un post en el que Enrique Dans afirma que, nos guste o no, <a href="http://www.enriquedans.com/2014/01/la-internet-de-las-cosas-la-seguridad-y-la-inevitabilidad.html">los avances tecnológicos van más rápido que la seguridad</a>, y que la inseguridad asociada a esta situación no va a detener su evolución. El segundo es un post de David Maeztu en el que, pronosticando un futuro en el que <a href="http://derechoynormas.blogspot.com.es/2014/01/alto-o-tu-coche-denuncia-mas-cerca-de.html">nuestro coche será capaz de denunciarnos automáticamente por exceso de velocidad</a>, plantea un panorama en el que la legislación no sólo no nos va a proteger de esa inseguridad asociada a los avances tecnológicos, sino que probablemente la acabe amparando (al menos, en términos de privacidad).<br />
<br />
Mi pronóstico es pesimista porque, sintiéndolo mucho, comparto gran parte de las visiones anteriores. No creo que la seguridad sea una prioridad en la sociedad moderna, y por lo tanto ni tecnólogos ni legisladores creo que le vayan a dar una importancia que la sociedad no le da. La <a href="http://es.wikipedia.org/wiki/Pir%C3%A1mide_de_Maslow">pirámide de Maslow</a> de nuestra sociedad ha cambiado, y la seguridad/privacidad ha perdido peso. Nuestra sociedad está dispuesta a sacrificar parte de los niveles de la base a cambio de conseguir un poco más de aquello que está en la cúspide de la pirámide.<br />
<br />
Ante este panorama no creo que se pueda hacer mucho. La respuesta de libro serían programas de formación, trabajos de concienciación, pero... Acaso sirve de algo nadar contra corriente? A veces pienso si no sería mejor dejarse llevar, y simplemente tratar de minimizar los daños. Si en la eterna lucha contra el riesgo vemos que no podemos ganar, no deberíamos cambiar nuestra estrategia y tratar de aprovecharnos de él?<br />
<br />
Será que hoy me he levantado pesimista...Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-35205398991933836552013-12-16T18:41:00.000+01:002013-12-16T18:41:00.513+01:00Seguridad Vs Privacidad. O estamos equivocados?<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.claybennett.com/images/archivetoons/security_fence.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="226" src="http://www.claybennett.com/images/archivetoons/security_fence.jpg" width="320" /></a></div>
Es muy habitual pensar en la privacidad y en la seguridad como dos aspectos prácticamente antagónicos. No hay más que <a href="https://www.google.es/#q=privacidad&tbm=nws">buscar noticias sobre privacidad</a> y seguro que nos encontramos con alguna en la que ambos conceptos estén enfrentados. Sin embargo, cuando participas en congresos sobre alguna de las dos temáticas, te das cuenta de que los profesionales que se dedican a ambas disciplinas trabajan de la misma manera, persiguen objetivos similares y tratan asuntos prácticamente idénticos. Cómo puede ser posible que una misma cosa y su contraria puedan ser tan similares?<br />
<br />
La realidad es que seguridad y privacidad son prácticamente lo mismo. La única (aunque gran) diferencia entre ambos conceptos está en el foco: la privacidad se preocupa por las personas, la seguridad se preocupa por las organizaciones (empresas o incluso estados). O dicho de otro modo: si aplicásemos todos los conceptos que maneja una de las disciplinas al foco de la otra, estaríamos hablando de lo mismo.<br />
<br />
Siendo conscientes de la gran proximidad entre ambas disciplinas todavía puede sorprender más ese antagonismo percibido. Si la privacidad consiste en levantar los muros de mi casa y la seguridad supone añadir una valla exterior, no deberían ser dos planteamientos convergentes en lugar de divergentes?<br />
<br />
Por añadir otro argumento más a esta visión, no deberíamos olvidarnos del hecho (trivial, pero importante) de que las organizaciones están compuestas por personas. Por lo tanto, si protegemos la seguridad de las personas, no estaríamos protegiendo también la seguridad de la organización? Por qué en la ilustración montan la seguridad de la organización destruyendo la privacidad de los individuos?<br />
<br />
Vistos los argumentos anteriores, el planteamiento clásico de seguridad Vs privacidad no tendría ningún sentido si no fuera por un aspecto importante, y es que la seguridad trata de proteger a la organización INCLUSO de sus propios miembros. La valla de la ilustración no está completa, ya que en realidad debería ser una valla doble con otro frente hacia el interior. Y es precisamente bajo ese planteamiento, consistente en que los propios miembros de la organización también pueden ser una amenaza, cuando tiene sentido que uno de los objetivos de la seguridad sea conocer lo mejor posible a estas potenciales amenazas, tratando de limitar por tanto la seguridad de las personas en favor de la seguridad de la organización.<br />
<br />
Y precisamente es en este punto en el que quería plantear un par de reflexiones que me parecen importantes, aunque no sé si fáciles de responder. La primera es en torno al debate sobre las organizaciones y las personas que las componen. ¿Qué es lo que hay exactamente entre esas dos vallas, para que tengamos que protegerlo "contra" (y a costa de la privacidad de) los miembros de la organización? Y la segunda es sobre la forma de aplicar la seguridad. ¿Nos estamos planteando estrategias complementarias o alternativas de tipo "zanahoria" (recompensas, incentivos, etc.) en relación al personal de la organización, o sólo estamos planteando estrategias de tipo "palo" a la hora de aplicar la seguridad?<br />
<br />
En definitiva, creo que el debate de seguridad contra privacidad no hace sino ocultar otros debates más profundos, como es el de la definición de las estrategias en las que basamos la aplicación de la seguridad, y en última instancia el eterno debate entre personas físicas y jurídicas y las consecuencias sociales de su disociación. No os parecen estos debates mucho más apasionantes?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-3139565615716606332013-12-10T15:56:00.000+01:002013-12-10T15:56:46.730+01:00Información, transparencia y limitacionesHoy se ha publicado en el BOE la esperada <a href="http://www.boe.es/boe/dias/2013/12/10/pdfs/BOE-A-2013-12887.pdf">Ley 19/2013 de Transparencia</a>. Para los habituales del blog no resultará nueva la <a href="http://secugest.blogspot.com.es/2012/05/seguridad-transparencia-y-ens.html">relación entre el ENS y la Transparencia</a>, ni creo que les sorprenda ver un post al respecto teniendo en cuenta que <a href="http://secugest.blogspot.com.es/2010/08/ley-de-acceso-la-informacion-publica.html">hace más de 3 años que esperaba poder publicar algo en este sentido</a>. Por lo tanto, hoy tocaba postear algo, aunque sea breve...<br />
<br />
Como positivo, esta Ley nos proporciona una especie de "catálogo" de información clasificable como pública, si hacemos un análisis de su Capítulo II:<br />
<br />
<ul>
<li><b>Información institucional y organizativa</b>: Funciones del organismo, normativa aplicable, estructura organizativa, responsables (y su perfil y trayectoria profesional), etc. </li>
<li><b>Información de planificación</b>: Planes y programas, objetivos, actividades, medios y plazos previstos para su ejecución, resultados de todos ellos, etc. </li>
<li><b>Información de relevancia jurídica</b>: Interpretaciones legislativas, proyectos legislativos y reglamentarios, memorias e informes, etc.</li>
<li><b>Información económica y presupuestaria</b>: Información económica del organismo (contratos, convenios, subvenciones, presupuestos, cuentas anuales, etc.) así como información económica asociada a los altos cargos (retribuciones, indemnizaciones, declaraciones de bienes, etc.</li>
<li><b>Información estadística</b>: Tanto de carácter económico como de funcionamiento, necesaria para valorar la calidad de los servicios prestados. </li>
</ul>
<div>
También nos da una serie de criterios en base a los cuales deberíamos considerar la "confidencialidad" de la información que manejan los organismos públicos (junto a los "clásicos" como la seguridad nacional, la defensa o la seguridad pública se incluyen otros previsibles, como los aspectos relacionados con la comisión de ilícitos, las funciones administrativas de supervisión o los procesos judiciales, y otros que me parecen potencialmente polémicos, como los económico-comerciales o los medio-ambientales). Sin embargo, no se para a establecer niveles de criticidad en relación a estos criterios, indicando simplemente que dicha evaluación será específica para cada caso, justificada y proporcionada. </div>
<div>
<br /></div>
<div>
Uno de los aspectos que más me ha llamado la atención es que no se habla expresamente de los procedimientos administrativos, ni en el "catálogo de información clasificable como pública" ni en la lista de limitaciones. Por lo tanto, la mayor parte de la información en poder de las administraciones públicas parece quedar al margen de estos "criterios" de clasificación.</div>
<div>
<br /></div>
<div>
Pero sobre lo que me gustaría incidir es sobre una limitación existente en torno al concepto de "clasificación" de la información, y es su carácter estático. El ENS nos "anima" a clasificar la información, a determinar si un determinado tipo de información es público, confidencial o secreto. Pero no podemos olvidar que esta clasificación puede variar a lo largo del tiempo. Un ejemplo de película podría ser la desclasificación de expedientes, por la que un determinado expediente X pasa a ser público transcurrido un determinado número de años. Otro más cercano podría ser la valoración de las ofertas asociadas a un contrato público, que sería confidencial mientras se están evaluando las ofertas pero pasaría a ser pública (información económica y presupuestaria) una vez que haya concluido el proceso de adjudicación. Este tipo de situaciones no quedan bien contempladas dentro de los planteamientos del ENS, y la Ley de Transparencia pone más de manifiesto este tipo de situaciones. </div>
<div>
<br /></div>
<div>
En definitiva, creo que la Ley de Transparencia, más allá de valoraciones de otro tipo, ha sido una oportunidad perdida para establecer un catálogo de referencia general para clasificar la información administrativa, y por lo tanto una cierta decepción para muchos organismos que podrían haber visto en esta Ley una importante ayuda para impulsar la adopción del ENS. Adopción que, por otra parte, no aparece ligada en ningún punto. No hubiera sido deseable que la seguridad de la información hubiera estado expresamente citada? Una pena...</div>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-88265130553042065272013-11-06T16:28:00.003+01:002013-11-06T16:28:56.031+01:00De itSMF Euskadi al Congreso Nacional VISION13El pasado día 24 de Octubre se celebró la I Jornada organizada por el comité regional de Euskadi de itSMF, titulada <a href="http://www.itsmf.es/index.php?option=com_content&view=article&id=1162">Presente y Futuro de la Gestión TIC en Euskadi</a>. La jornada, con un gran éxito de asistencia (más de 120 asistentes creo que es una buena muestra del interés que despertó) fue la guinda al primer año de trabajo de este comité, al que auguro un gran futuro, vistos los resultados. <div>
<br /></div>
<div>
Las principales conclusiones que pude sacar del evento son las siguientes:</div>
<div>
<ul>
<li>La cultura de los departamentos TIC sigue centrada en la tecnología. Aunque sus responsables empiezan a pensar en servicios, el cambio de mentalidad todavía no está asimilado.</li>
<li>A causa de lo anterior, los planteamientos que se hacen sobre las nuevas modas del sector TIC (cloud, BYOD, BigData, ...) se siguen entendiendo bajo una visión técnica, sin mucha "orientación al cliente". </li>
<li>Se mide poco, no sólo porque sea difícil sino porque da miedo ver "cómo hemos salido en la foto". </li>
<li>El reto de los grandes departamentos de TI no es tecnológico, sino de gestión y coordinación. </li>
<li>La orientación al negocio sigue siendo algo a perseguir, pero que se ve muy lejos.</li>
</ul>
<div>
Algunas de estas conclusiones me han llamado mucho la atención, porque encajan bastante bien con la ponencia que voy a realizar en el <a href="http://www.itsmf.es/index.php?option=com_content&view=article&id=1051">congreso nacional de itSMF VISION13</a> el próximo día 11, a las 13:00 en la sala Plaza de Armas. En mi ponencia trataré de responder de forma sencilla (y un poco tajante, para qué negarlo) a preguntas como las siguientes: </div>
<div>
<ul>
<li>Por qué los departamentos de TI le tienen tanto miedo al Cloud Computing?</li>
<li>Cómo podemos dejar atrás definitivamente el problema de la "alineación con el negocio"?</li>
<li>Por qué la piedra angular del departamento de TI debería ser el catálogo de servicios?</li>
<li>Cómo encaja de manera natural el BYOD con la ISO 20000?</li>
<li>Es posible diseñar un modelo de departamento de TI que integre todos estos problemas... sin morir en el intento?</li>
</ul>
<div>
Si alguna de estas preguntas suscitan tu interés... Nos vemos el próximo lunes. </div>
</div>
</div>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-54878615435120993462013-09-26T15:39:00.001+02:002013-09-26T15:43:05.294+02:00Publicada la nueva ISO/IEC 27001:2013Tras un cierto tiempo ausente de este blog (espero recuperar mi ritmo de publicación habitual ahora que prácticamente he terminado con el Master que estaba cursando) me alegra poder comunicar que ayer se publicó la esperada <a href="http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54534">nueva versión de la norma ISO 27001</a>, varios días antes de lo previsto.<br />
<br />
Esta nueva versión, pese a no introducir cambios demasiado significativos, puede suponer un nuevo impulso al desarrollo de la seguridad de la información, sobre todo desde el punto de vista de su integración y aceptación por parte de áreas típicamente alejadas del mundo de la seguridad. Esto se debe a que esta nueva versión de la norma está adaptada a los requisitos del <a href="http://www.irca.org/es/Recursos/INform/Archivo/INform--Edicion-35/Temas-tecnicos---Edicion-35/Presentacion-del-Anexo-SL/">Anexo SL</a>, la nueva referencia de ISO para cualquier sistema de gestión. Esta adaptación supone que un SGSI tendrá exactamente la misma estructura que cualquier otro sistema de gestión normalizado por ISO, y por tanto será más fácilmente integrable con cualquier otro sistemas de gestión ya implantado en la organización.<br />
<br />
Más allá de estos cambios, la versión 2013 de la norma ISO 27001 incorpora una nueva versión del anexo de medidas de seguridad, en el que se ha modificado sobre todo la organización de los controles más técnicos y se han incluido dominios específicos para la criptografía y la relación con proveedores, a la vez que se ha reducido el número total de controles hasta los 113 (gracias sobre todo a la eliminación de controles redundantes).<br />
<br />
En definitiva, un nuevo lavado de cara para una norma con bastante éxito y mucho potencial, que esperemos que sirva para que poco a poco las organizaciones se animen a mejorar la seguridad de su información.Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-23601081717067394322013-05-28T15:39:00.002+02:002013-05-28T15:39:43.032+02:00Continuidad de los procesos de negocio y temporalidadEn muchas ocasiones, a la hora de hablar de procesos de negocio, nos solemos olvidar de un pequeño detalle que, sin embargo, es crítico desde muchos puntos de vista: su dimensión temporal. Obviamente, no todos los procesos de negocio tienen la misma duración, periodicidad ni frecuencia de ocurrencia. Los hay que duran segundos mientras otros duran días o meses. Hay procesos diarios mientras que otros muchos son mensuales o incluso anuales. Y por último, no es lo mismo un proceso que se desencadene (instancie, que dirían los programadores) 10 veces al día que uno que lo haga 1 vez al año... aunque ambos procesos tengan la misma duración y periodo. <br />
<br />
Estas dos dimensiones temporales van a tener un peso fundamental a la hora de caracterizar los procesos de negocio. Estos aspectos son fundamentales cuando hablamos de Continuidad de Negocio, y sin embargo no se suelen explicitar a la hora de realizar un BIA (<a href="http://en.wikipedia.org/wiki/Business_continuity_planning#Business_Impact_Analysis_.28BIA.29">Business Impact Analysis</a>, o Análisis de Impacto en el Negocio). De hecho, estos tres serían los parámetros fundamentales para evaluar la "degradación" que provocaría la materialización de una amenaza sobre un proceso de negocio, parámetro que combinado con el "valor" del proceso de negocio (su importancia para la actividad productiva de la organización) nos daría el "impacto" de dicha amenaza. Y si quisiéramos completar el estudio no tendríamos más que evaluar la "probabilidad" de ocurrencia de dicha amenaza y tendríamos como resultado el "riesgo" que supone esa amenaza para ese proceso de negocio, consiguiendo un análisis de riesgos completo.<br />
<br />
Pero volvamos sobre el primer análisis. ¿Cómo podríamos parametrizar los procesos de negocio habituales de una organización? Simplificando mucho podríamos decir algo así como:<br />
<br />
<ul>
<li>Los procesos de venta son de duración muy variable, en función del producto/servicio vendido, pero en general podríamos pensar que están entre 1 día y 1 mes. No tienen una periodicidad pre-establecida, y su frecuencia de ocurrencia podría ir desde la diaria (o incluso menos) hasta muchas (a veces, miles) veces al día </li>
<li>Los procesos productivos son los de mayor variabilidad, ya que tendriamos desde los de duración de segundos (entrega instantánea de información, como los bancarios o los web) hasta los de duración de días e incluso meses (por ejemplo, la fabricación de maquinaria pesada). No tienen por qué tener una periodicidad establecida, y su frecuencia de ocurrencia depende mucho del producto/servicio producido y de la estrategia de producción (en cadena, en paralelo, secuencial, etc.).</li>
<li>Los procesos de gestión económica podríamos pensar que tienen una duración de varios días, en general, una periodicidad mensual y una frecuencia de ocurrencia que puede ser diaria. </li>
<li>Podríamos pensar que los procesos de gestión de personal tienen en general una duración de varios días, una periodicidad variable (dependiendo de las características de la organización puede no tener periodicidad predeterminada) y una frecuencia directamente dependiente del tamaño de la organización. </li>
</ul>
<div>
Esta caracterización de los procesos puede facilitar el diseño de diferentes estrategias de continuidad en función de la tipología de los procesos de negocio soportados. ¿Encajan vuestras estrategias de continuidad con un análisis de este tipo? ¿Son las soluciones adoptadas coherentes con este planteamiento? Ya tenéis tema para la reflexión...</div>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com1tag:blogger.com,1999:blog-33946654.post-10777524669290991372013-05-13T14:59:00.000+02:002013-05-13T14:59:28.581+02:00Análisis de Riesgos para directivosMuchos responsables de seguridad se quejan de que les resulta difícil conseguir que la dirección revise con detalle (y no hablemos ya de participar en su realización) los análisis de riesgos. ¿Hay alguna forma de conseguir que el ejercicio sea más "natural" para ellos? Creo que sí.<br />
<br />
La propuesta que hago a continuación no es excesivamente ortodoxa, pero creo que puede servir para aproximar los análisis de riesgos a un colectivo como es el directivo que puede estar familiarizado con los conceptos que se tratan, pero que les cuesta usar la metodología "clásica". No obstante, los primeros que tendremos que hacer un esfuerzo seremos nosotros, que tendremos que dejar de pensar en riesgos de TI (o de cualquier otro ámbito) y empezar a pensar en riesgos de negocio.<br />
<br />
Si hemos superado el primer obstáculo, el resto es sencillo. Sólo hay que seguir unos pequeños pasos que indico a continuación:<br />
<br />
<br />
<ol>
<li>Identificar el "negocio" del ámbito que estemos analizando, listando los servicios que presta, o los procesos de negocio que desarrolla, o como queramos llamar a la actividad de negocio que desarrolla ese ámbito. </li>
<li>Clasificar esos servicios en 3 niveles, en función de su <i>importancia </i>para la organización (llamémosle importancia alta, normal y baja). </li>
<li>Realizar un análisis DAFO de cada uno de esos servicios, identificando sus Debilidades, Amenazas, Fortalezas y Oportunidades.</li>
<li>Valorar cada una de esas debilidades, amenazas, fortalezas y oportunidades en función de su <i>importancia </i>(llamémosle importancia alta, media o baja). </li>
<li>Ahora sólo queda que alguien, a nivel más técnico, interrelacione debilidades (aka vulnerabilidades) y amenazas por un lado, y fortalezas y oportunidades por otro, multiplique el valor de cada tripleta (servicio-debilidad-amenaza y servicio-fortaleza-oportunidad)... <i>et voila</i>! Ya tenemos el análisis de riesgos.</li>
</ol>
Con este sencillo ejercicio, que para un directivo puede ser bastante más fácil de llevar a cabo que un análisis de riesgos "de libro", hemos conseguido tener un análisis de riesgos de negocio cuantitativo por un lado y un análisis de <i>potencialidades</i> (no he querido usar oportunidades, que ya se usa, y no se me ocurre un término mejor como antónimo de riesgo) por otro. De este modo no sólo reducimos la complejidad técnica que puede tener un análisis de riesgos, sino que lo aproximamos a la visión de negocio, tanto por utilizar metodologías más propias de este nivel como por desarrollar una visión "en positivo" del análisis de riesgos, al identificar no sólo riesgos a mitigar sino también potencialidades a favorecer, dentro del mismo análisis (de hecho, esta propuesta de <a href="http://secugest.blogspot.com.es/2008/08/analisis-de-riesgos-en-tiempos-de.html">análisis de riesgos en positivo</a> ya la planteé en este mismo blog hace algún tiempo).<br />
<br />
Obviamente, si lo que estamos buscando es un análisis de riesgos TI probablemente no encontremos bajo este planteamiento una solución válida, aunque... realmente el análisis de riesgos TI es un análisis de riesgos para directivos?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com1tag:blogger.com,1999:blog-33946654.post-85635703388481467132013-05-02T15:43:00.000+02:002013-05-02T15:43:10.878+02:00Atentado de Boston y APTsSegún se han ido sucediendo las noticias relativas al <a href="http://es.wikipedia.org/wiki/Atentado_de_la_marat%C3%B3n_de_Boston">atentado de la Maratón de Boston</a> y las averiguaciones posteriores no he podido evitar la tentación de establecer una analogía entre los hechos de Boston (o el terrorismo en general) y las <a href="http://en.wikipedia.org/wiki/Advanced_persistent_threat">APT</a>s informáticas. Y la pregunta que surge a continuación es clave: ¿Es válido ese paralelismo? Y si fuera así... Podrían realimentarse ambos mundos?<br />
<br />
Analicemos el paralelismo. Para empezar, el punto de partida de una APT es un "troyano" que conseguimos introducir en el sistema de la víctima. En el mundo físico, el sistema objetivo sería el entorno a atacar, en este caso Boston (o EEUU, cada uno que lo interprete como quiera). Las personas serían las aplicaciones que corren en ese sistema, y por lo tanto tendríamos dos formas de "infectar" el sistema: introduciendo directamente un software malicioso tipo "virus" (terrorista proveniente del exterior) o "troyanizando" una aplicación del sistema ("convirtiendo a la causa" a un ciudadano local, al más puro estilo <a href="http://es.wikipedia.org/wiki/Homeland_(serie_de_televisi%C3%B3n)">homeland</a>).<br />
<br />
Al igual que en el mundo informático, los países están preparados para proteger el perímetro de la red (frontera) y controlar las entradas (<a href="http://es.wikipedia.org/wiki/Cortafuegos_(inform%C3%A1tica)">firewalls</a>), pero la capacidad de detección de terroristas externos que tienen estos sistemas es muy limitada, ya que generalmente se limita a firmas (identidades específicas que se chequean) y heurística básica (análisis de los datos del propio viaje -origen, destino, motivos del mismo, y cosas así). El resultado es que los "virus" sencillos se pueden llegar a detectar, pero las APTs más sofisticadas (personas "troyanizadas" o incluso malware durmiente con puertas traseras) suelen colarse. Además, al igual que en los sistemas de información, no sólo podemos infectarnos por la red. Los pendrives (inmigración ilegal o no controlada, cuerpos diplomáticos, etc.) también pueden llevar alguna aplicación maliciosa en su interior, consciente o inconscientemente.<br />
<br />
En el mundo TIC se suelen poner sistemas <a href="http://es.wikipedia.org/wiki/Sistema_de_detecci%C3%B3n_de_intrusos">IDS </a>en la red interna, para tratar de detectar ataques que hayan podido superar la protección perimetral. Sin embargo, en el mundo físico no hay (oficialmente) demasiados recursos destinados al "espionaje" interno, más allá de la labor policial habitual. En cualquier caso, normalmente un IDS tampoco suele ser capaz de detectar la actividad de una APT...<br />
<br />
Las APTs son difíciles de detectar porque su actividad es esporádica. Suelen ser aplicaciones "durmientes", que realizan una actividad aparentemente normal (o ninguna) hasta que, por un motivo determinado, activan su <i>payload </i>malicioso y lo ejecutan, realizando la fechoría en cuestión. Este funcionamiento es muy similar al de cualquier célula terrorista, y la dificultad de su detección estriba en identificar el detonante para su activación, que potencialmente puede ser cualquier cosa. Las autónomas pueden activarse con una cuenta atrás, un hito específico, una fecha, etc., mientras que otras dependen de la recepción de una orden externa desde un nodo de comando y control (C&C). Estas son algo más detectables, pero también mucho más flexibles, ya que pueden ser reprogramadas. En cualquier caso, esas comunicaciones llevadas al mundo físico son prácticamente imposibles de detectar, dada la infinidad de medios existentes y la poca capacidad de supervisión de los mismos.<br />
<br />
Y por último, las APTs actúan. Roban la información, hacen estallar la bomba... Este suele ser el momento en el que son detectadas, cuando el incidente se materializa. El problema es que en este momento ya no sirve de nada, su acción no ha podido ser evitada. En ese momento es cuando empieza la "desinfección"... si es que han sido detectadas. Si no es así, podrán continuar con su actividad.<br />
<br />
Hasta aquí la exposición. Ahora vuelvo a lanzar la pregunta, para la que no tengo respuesta. ¿Puede servir el conocimiento adquirido en cualquiera de ambos mundos para mejorar la lucha contra amenazas físicas y cibernéticas? Hay algún tipo de iniciativa de colaboración en este sentido? Seguro que un buen guionista sabe cómo hacerlo...Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-49072913053951191582013-04-16T16:07:00.002+02:002013-04-16T16:07:46.072+02:00Publicada la norma UNE 71020:2013 - Modelo incremental para la ISO 20000La semana pasada se publicó la norma española <a href="http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0051050&PDF=Si#.UW1RZLW9nk0">UNE 71020:2013 - Modelo de conformidad incremental basado en la norma UNE-ISO/IEC 20000-1</a>.<br />
<br />
Esta norma es, en resumidas cuentas, un modelo de adopción de la norma ISO 20000 por niveles, que establece dos niveles intermedios antes de llegar a cubrir todas las exigencias recogidas en la ISO 20000-1.<br />
<br />
Mucho ha llovido desde que se empezó a hablar de la ISO 20000 por niveles. <a href="http://secugest.blogspot.com.es/2008/04/certificarse-en-iso-20000.html">Yo mismo valoraba esta posibilidad allá por 2008</a>, como una vía para "aligerar" la adopción de la ISO 20000 sobre todo para las PYMEs. Y sin embargo, el tiempo, que es en el fondo quien puede dar o quitar la razón, en este caso me la ha quitado. No sólo es que la mayor parte de empresas certificadas en España en ISO 20000 sean PYMEs, sino que he vivido de forma directa la experiencia de la adopción de la ISO 20000 en múltiples PYMEs y os puedo asegurar que en absoluto han necesitado un modelo de este tipo.<br />
<br />
Y en ese caso, cuál es el motivo de que haya seguido adelante el desarrollo de esta norma? Pues desde mi punto de vista el argumento principal es precisamente el contrario, las grandes empresas. Los cambios organizativos y operativos que requiere la adopción de un sistema de gestión de servicios certificable bajo ISO 20000 son infinitamente más sencillos de realizar en una PYME que en un gran departamento de TI, tanto por flexibilidad interna como por posibles impactos en los servicios prestados, más críticos cuanto mayor sea su dimensión. Para estos casos, la existencia de niveles intermedios "oficiales" puede suponer una gran diferencia a la hora de subdividir los proyectos y tener metas intermedias que impulsen un proyecto de cambio que bajo otro planteamiento puede ser excesivamente complejo. No perdamos de vista que el hasta ahora gran éxito de los proyectos ITIL en grandes corporaciones se basaba precisamente en éso, en abordar proyectos más pequeños y específicos, y por tanto con resultados más rápidos y tangibles.<br />
<br />
Por otro lado, creo que este modelo de referencia puede ser muy útil para organizaciones que, sin tener un departamento TIC demasiado potente, cuenten con un cierto grado de madurez en su gestión interna corporativa y quieran mejorar la calidad de sus TIC sin encorsetarse demasiado. Estoy pensando, sobre todo, en empresas del sector industrial y productivo en general, en los que las TIC "apoyan" al negocio pero no son el "core" del negocio. En este tipo de organizaciones, plantearse un nivel 1 de madurez puede ser una meta mucho más interesante que la de desarrollar un sistema de gestión de servicios completo y certificable...<br />
<br />
Por qué digo esto? Echándole un vistazo a los niveles (visión simplificada y "redondeada") creo que quedará más claro:<br />
<br />
<ul>
<li><b>Nivel 1</b> = Núcleo del Sistema de gestión (básico) + Seguridad (básico) + Proveedores + Incidentes + Problemas + Configuración (básico) + Cambios (básico) + Entregas (básico).</li>
<li><b>Nivel 2</b> = Núcleo del Sistema de gestión (completo) + Seguridad (completo) + Niveles de servicio + Informes + Continuidad y disponibilidad (básico) + Financiero + Capacidad + Proveedores + Clientes (básico) + Incidentes + Problemas + Configuración (completo) + Cambios (completo) + Entregas (completo).</li>
<li><b>Nivel 3</b> = ISO 20000 completa (se completan todos los procesos y se añade el diseño y transición de servicios.</li>
</ul>
<div>
Así que ya sabéis, si queréis profundizar un poco más en este planteamiento de la ISO 20000 por niveles... ya tenéis un estándar a vuestra disposición. </div>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com4tag:blogger.com,1999:blog-33946654.post-79466814948754533452013-04-02T15:41:00.000+02:002013-04-02T15:41:10.097+02:00Herramientas para ISO 20000Una de las dudas más habituales a la hora de pensar en la ISO 20000 suele ser la de si es necesario disponer de herramientas específicas para su implantación. Y aunque la respuesta "de libro" debiera ser que no, la realidad es que en muchos casos se hace casi imprescindible disponer de alguna herramienta que facilite las tareas a realizar, sobre todo si queremos ser eficientes y eficaces a la hora de realizarlas. Otra cosa muy diferente sería valorar qué herramientas en cuestión se pueden utilizar, ya que hay desde herramientas gratuitas y de código libre hasta herramientas con precios al alcance de sólo unos pocos privilegiados, cada una de ella con sus ventajas y sus inconvenientes. Pero como no pretendo llegar a eso, a continuación va un listado de "tipos" de herramientas que se pueden utilizar, y para qué ámbitos son útiles:<br />
<br />
<ul>
<li>Herramientas de <b>monitorización</b>: Son prácticamente imprescindibles para los procesos de <i>gestión de la capacidad</i> y <i>gestión de la continuidad y disponibilidad</i>, ya que permiten monitorizar de forma automática la disponibilidad y capacidad de los sistemas. Además, pueden facilitar los procesos de <i>gestión de niveles de servicio</i> y de <i>informes</i>, en función de los parámetros en base a los cuales hayamos definido la calidad de nuestros servicios. </li>
<li>Herramientas de <b>ticketing</b>: Aunque la <i>gestión de incidentes y peticiones de servicio</i> pudiera hacerse de manera cuasi-manual, la utilización de una herramienta de ticketing se hace prácticamente imprescindible en el momento en el que queramos automatizar dicha gestión y sobre todo obtener indicadores de dicho proceso. En función de los parámetros en base a los que hayamos definido la calidad de nuestros servicios, estas herramientas también pueden facilitar los proceso de <i>gestión de niveles de servicio</i> y de <i>informes</i>. Además, en muchos casos la <i>gestión de problemas</i> también se automatiza mediante la misma herramienta de ticketing, incrementando su utilidad. </li>
<li>Herramientas específicas para <b>CMDB</b>: Aunque una CMDB se podría implementar con una base de datos relacional normal y corriente, las herramientas específicas para CMDB facilitan tanto el trabajo que su utilización acelera enormemente la implementación del proceso de <i>gestión de la configuración</i>, haciéndose muy aconsejables si no imprescindibles. Además, estas herramientas normalmente suelen tener capacidad para integrarse con las herramientas de ticketing, incrementando enormemente su funcionalidad. </li>
<li>Herramientas de <b>soporte a la gestión</b>: Aunque no sean imprescindibles, cada vez están surgiendo en el mercado más herramientas que<i> implementan diferentes procesos</i> de la ISO 20000, normalmente bajo un planteamiento ITIL-compliant. Este tipo de herramientas facilita la gestión de los procesos, y sobre todo mejora enormemente la capacidad de gobierno de los mismos, gracias a su potencial de obtención de indicadores y métricas asociadas. </li>
<li>Herramientas de <b>inventariado automático</b>: No son herramientas imprescindibles para la ISO 20000, pero las herramientas de auto-descubrimiento e inventariado de la infraestructura TIC facilitan la gestión de los activos, sobre todo en los casos en los que la infraestructura TIC es numerosa. Además, las herramientas de CMDB suelen tener interfaces con estas, facilitando la <i>gestión de la configuración</i>. </li>
<li>Herramientas de <b>administración TIC</b>: Tampoco son herramientas imprescindibles para la ISO 20000, pero al facilitar la administración centralizada de la infraestructura (sistemas y/o comunicaciones) permiten una implantación más sencilla y eficaz de los procesos de <i>gestión de la configuración</i> y <i>gestión de la entrega</i>. Además, este tipo de herramientas suele permitir su integración con otras señaladas anteriormente. </li>
</ul>
En definitiva, las herramientas "clásicas" en la gestión TIC facilitan la adopción de un Sistema de Gestión de Servicios certificable bajo ISO 20000, y muchas de ellas han ido evolucionando e incorporando los módulos específicos necesarios para cumplir con las exigencias de la ISO 20000, o al menos definiendo las interfaces necesarias para su integración con este tipo de herramientas. A día de hoy ya existe un amplio y completo catálogo de soluciones, de modo que el uso de este tipo de herramientas sólo dependerá de cada organización, y de la selección que quiera hacer en función de sus intereses y posibilidades.Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com3tag:blogger.com,1999:blog-33946654.post-13142456319478188212013-02-26T15:51:00.005+01:002013-02-26T15:51:59.892+01:00Las dashcam y la LOPDSeguro que a estas alturas todo el mundo ha visto alguno de los vídeos en los que aparece el <a href="https://www.google.es/search?hl=es&gl=es&tbm=nws&q=meteorito+rusia&oq=meteorito+rusia">meteorito que la semana pasada cayó en Rusia</a>. Y la grabación de estas imágenes ha sido posible porque parece que <a href="http://www.enriquedans.com/2013/02/rusia-siempre-hay-una-camara-grabando.html">en Rusia son muy habituales</a> las<i><a href="http://en.wikipedia.org/wiki/Dashcam"> dashcams</a></i>, o cámaras de parabrisas, que son unas cámaras que se instalan en el interior del coche para ir grabando lo que sucede delante de nosotros mientras vamos conduciendo.<br />
<br />
Reconozco que la idea de tener una <i>dashcam </i>se me ha ocurrido en innumerables ocasiones, incluso antes de conocer su existencia, sobre todo cuando el conductor de delante te hace una <i>pirula </i>y piensas "si esto se hubiera grabado, menudo <i>puro </i>le iba a caer". Por supuesto, en mi imaginación las <i>dashcams </i>eran mucho más completas, por éso de la deformación profesional: Módulo GPS integrado para posicionamiento y fechado de fuente externa, memoria <i>read-only</i> para evitar la manipulación de las grabaciones, sistema completo certificado por Common Criteria... Vamos, un sistema totalmente inexpugnable a nivel legal. No vaya a ser que el de la <i>pirula</i> se libre!<br />
<br />
No obstante, puestos a ser realistas, y teniendo en cuenta que en la práctica probablemente no fuese necesaria tanta <i>fortaleza legal</i> para que la grabación en cuestión fuese admitida en un juicio <i>corriente</i>, la idea de la dashcam actual parecería suficiente. Sin embargo, me asalta una duda legal: ¿Es compatible la idea de la dashcam con nuestra LOPD?<br />
<br />
Por un lado, parece que la videovigilancia debería ser la última solución, y no tengo claro si en este caso se podría considerar un medio excesivo. Por otro, entiendo que quien tuviera una dashcam debería llevar pegado el cartelito amarillo en el parabrisas (sería gracioso encontrarse con un coche así, la verdad). Pero la duda que más me asalta es la relacionada con la aplicabilidad de la LOPD. Mi idea general simplificada era, básicamente, que la LOPD no aplicaba a personas físicas, por aquello del Artículo 2.a. Sin embargo, hay <a href="http://www.samuelparra.com/2010/09/13/600-euros-multa-grabar-30-centimetros-pasillo/">resoluciones</a> y sentencias que sancionan a personas físicas por grabar el exterior. ¿Es por el "exclusivamente personales o domésticas"? Al final, no me termina de quedar claro...<br />
<br />
¿Hay algún jurista en la sala capaz de aclararme si podré instalarme una dashcam?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com3tag:blogger.com,1999:blog-33946654.post-4730400856213006402013-02-01T14:39:00.001+01:002013-02-01T14:39:45.703+01:00La LOPD lo permite TODOEn los últimos meses estamos asistiendo a una creciente aparición en prensa de una gran diversidad de documentos que destapan multitud de escándalos: <a href="http://es.wikipedia.org/wiki/Caso_G%C3%BCrtel">Gürtel</a>, <a href="http://es.wikipedia.org/wiki/Caso_N%C3%B3os">Noos</a>, <a href="https://www.google.es/search?hl=es&gl=es&tbm=nws&q=caso+barcenas&oq=caso+barcenas">Bárcenas</a>, ... En todos ellos acaban publicándose documentos cuasi-privados en los que aparecen, como era de esperar, datos personales, entre otra información.<br />
<br />
Ante estos hechos ya empiezan a aparecer, y cada vez con más volumen, posicionamientos en contra de la publicación de este tipo de documentos argumentando para ello la protección que la LOPD otorga a este tipo de información. ¿Se puede o no se puede, desde el punto de vista de la LOPD, publicar esa información?<br />
<br />
Partiendo del planteamiento de <i>interés legítimo</i>, apoyándome en<a href="http://gontzalgallo.wordpress.com/2012/11/12/quiero-participar-en-la-vida-politica/"> argumentaciones mucho</a> <a href="http://fjaviersempere.wordpress.com/2012/08/16/lopd-para-todode-como-la-ignorancia-y-falta-de-rigor-se-apoderan-de-una-ley/">más consistentes que las que pueda hacer yo</a>, y sin olvidarme del derecho a la información, entiendo que estos argumentos carecen de rigor jurídico, y que no hay ningún problema para publicar este tipo de documentos pese a que incluyan datos personales.<br />
<br />
No obstante, el objetivo del post de hoy no era el de profundizar en si se puede o no se puede publicar esa información, sino recordar que LA LOPD LO PERMITE TODO. Así, en mayúsculas. ¿Se pueden publicar datos personales de nivel alto en Internet? SI. ¿Se pueden difundir a los cuatro vientos, por cualquier medio? Por supuesto que SI. Lo único que necesitamos es el consentimiento del afectado.<br />
<br />
De hecho, tendríamos que estar aburridos de ver publicados y difundidos datos personales de nivel alto sin el más mínimo problema. ¿Acaso la pertenencia de Mariano Rajoy al Partido Popular no es un dato personal, y de nivel alto? ¿O que Jesús Vázquez sea gay? Por supuesto que sí. ¿Están vulnerando la LOPD quienes lo publican? Claro que no. Simplemente, tienen el consentimiento del afectado.<br />
<br />
En resumidas cuentas, la LOPD permite algo tan "duro" como publicar en Internet o a través de cualquier medio de comunicación el historial médico completo de cualquier persona. Tan sólo necesitamos su consentimiento explícito para difundirlo de forma indiscriminada a toda la sociedad. ¿Somos capaces de conseguirlo? Entonces la LOPD lo permite. Otra cosa es que no contemos con dicho consentimiento...<br />
<br />
En definitiva, lo que quiero transmitir con esta "reducción al absurdo" es que la LOPD no tiene por qué ser impedimento para nada. Por lo tanto, no hagamos de la LOPD la excusa para no publicar una cierta información, cuando en muchos casos el motivo principal suele ser otro bien distinto...Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com2tag:blogger.com,1999:blog-33946654.post-47652012925480987012013-01-24T15:11:00.001+01:002013-01-24T15:11:42.305+01:00Conceptualizando en Gestión de Crisis y ResilienciaEl post de hoy no está escrito por mí, es una contribución de <a href="http://www.linkedin.com/in/sobron">Jose Miguel Sobrón</a>, miembro de <a href="http://www.asisonline.org/">ASIS International</a> y el responsable de la Unidad de Sistemas de Gestión de Resiliencia Organizacional del <a href="https://dss.un.org/dssweb/"><i>Department of Safety and Security</i> de Naciones Unidas</a>. Espero que os guste!<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #222222; font-family: Arial, sans-serif; font-size: 10pt;">Esta es la era de la preparación (<i>preparedness </i>era) hay que estar listos
para todo lo que venga. Antes éramos reactivos y ahora somos proactivos. Ahora
además tenemos que ser resilientes, para todo también. En toda esta tendencia y
obsesión por “estar listos”, ¿qué pasa con continuidad de negocio? ¿Y con
gestión de crisis?</span></blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">A veces la rutina nos confunde y nos hace olvidar el significado real que a
las palabras damos, y el porqué de ese mismo significado. Esta es una confusión
o polémica muy habitual sobre el huevo y la gallina, o lo que es lo mismo, si fue
antes Continuidad de Negocio o Gestión de Crisis o viceversa, o cual de las dos
regula a cual.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Si hay algo que esta arrasando en todas las grandes corporaciones a nivel
mundial y que se está extendiendo como la pólvora, eso es el concepto de
Resiliencia, definida de mil maneras, pero simplificándola a cualquier áreas de
estudio, como capacidad de resistir cualquier impacto y conectarlo con las
maneras posibles de volvernos a levantar y continuar. Así es en multitud de
áreas. Recomiendo por lo exquisito y extenso del estudio un análisis muy
concienzudamente detallado llevado a cabo por el <i>US Department of Homeland
Security</i> (DHS, grosso modo nuestro Ministerio del Interior) en el <i><a href="http://www.umb.edu/editor_uploads/images/centers_institutes/ciocs/DHS_Operational_Framework.pdf">Journal ofHomeland Security and Emergency Management, vol 6, Issue 1-2009-Art 83</a></i>.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">En este nuevo mundo global de Resiliencia Corporativa (<i>Organizational
Resilience</i>) existe mucha confusión creada a veces por intereses obvios de
mercado e influencia de varias tendencias y a veces solo por confusión de la
terminología. Si inicialmente el primer paso de gigante en continuidad lo dio
la presentación del <i>BS25999</i> (1-2), el modelo que integraba todo bajo <i>BCM
</i>(Gestión de continuidad de negocio) no cubre todas las áreas, a pesar de tener un
amplio apoyo y marco experimental en Reino Unido, la misma Unión Europea y
algunos países. Es más, vista la escasa acogida actual y la reorientación del
mercado hacia la familia<i> ISO 31000</i> e <i>ISO 28000</i>, los grandes defensores del
modelo británico han reaccionado con celeridad y han aunado fuerzas con <i>ASIS
International</i> (que sigue el modelo ISO) para elaborar un producto de Gestión de Continuidad de Negocio (<i>Business Continuity Management</i>) “conjunto”, suma de las
dos tendencias, para crear una sola alrededor de las familias de estándares de<i>
</i>ISO <i>(<a href="http://www.asisonline.org/guidelines/published.htm">ASIS/BSI Business Continuity Management Standard - 2010</a></i>). Sabia elección,
porque siempre es mejor aunar que litigar. Muchos de los que practican el
modelo británico se han visto y se ven en una situación incómoda, por aquello de que a todos nos cuesta un trocito de ego reconocer que hay que tomar otro
camino contrario o diferente al que practicábamos desde hace un tiempo. Merece
la pena dejar el ego atrás, sin duda.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">El modelo basado en <i>ISO 31000</i> es mucho más integral y explora un marco que
no deja resquicio alguno. Además es relativamente multinacional y compila el
esfuerzo inicial australiano y neozelandés, con el impulso del Sudeste Asiático
y el reciente apoyo incondicional de Estados Unidos y la mayor parte de países europeos.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">En ese marco de <i>ISO 31000</i> la Gestión de Crisis sí es el pilar fundamental, que
no el único, y los demás son absolutamente no solo necesarios sino completamente
complementarios. En el ámbito de<i> ISO31000</i> y en íntimo contacto se localiza el
impulso creado y mantenido por<i> ASIS International</i> para Resiliencia Corporativa
(acabamos de publicar el <a href="http://www.asisonline.org/guidelines/published.htm">ultimo estándar aprobado por ANSI sobre el modelo demadurez de Resiliencia Corporativa</a>). En ese paraguas monumental que es la
Resiliencia, cabe todo, pero hace falta un hilo conductor que lo regule y
coordine, y ese hilo conductor debe de estar en lo más alto de la cadena de
Mando o Gestión si lo preferís.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Empezaré explicando por qué cuando acudimos a la definición se ve mucho mas
claro el concepto. Al hilo de esto, permitirme de nuevo recomendaros un sumario sobre el <i>PAS (Publicly Available Section) 200:2011 Crisis
Management-Guidance and Good Practice</i> <a href="http://www.regesterlarkin.com/backup/latest/PAS_200_An_assessment_by_Regester_Larkin_2011.pdf">llevado a cabo por <i>Regester Larkin</i></a>, que
recoge bastantes puntos interesantes y también críticos sobre el estudio de
Reino Unido </span><span style="color: #222222; font-family: Arial, sans-serif; font-size: 13px;">(el <i>PAS </i>completo es de pago y creo que cuesta alrededor de 100 libras esterlinas).</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Gestión de Crisis como su propio nombre indica hace referencia a dos cosas
absolutamente claras en cualquier organización por grande o pequeña que sea:
Gestión conecta con el Jefe Ejecutivo o el Consejo Directivo o los dos; y
Crisis es una palabra que hemos desgastado y contaminado de tanto usarla. Una
crisis no es un incidente ni un problema, es una situación muy, pero que muy
complicada que se desarrolla en un ambiente inestable, complejo e inesperado,
de desconocidas consecuencias (a veces “<i>black swans</i>”) y que pone en alto riesgo
cualquiera de nuestros activos o pasivos más importantes, nuestras
instalaciones y personal y nuestra reputación; y por ende hace peligrar la
existencia de la propia organización en su estado actual. Podéis hacer una
comparativa en uno de los últimos papeles de Marzo del <i>BCI </i>(<i><a href="http://www.bcifiles.com/CrisisManagementMarch2012.pdf">CM What is and howis it delivered, 2012 BCI</a></i>).</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Las crisis, como los riesgos, no son malas por naturaleza, pueden serlo
si nos pilla sin preparar pero pueden ser grandes oportunidades en las que
fortalecer y consolidar los cimientos de la Resiliencia Corporativa. Os dejo un
link de una definición escalable de<a href="http://www.scribd.com/doc/92048728"> cómo Gestión de Crisis conecta conResiliencia Corporativa</a>, que hace poco llevamos a cabo cuando colabore con un
par de buenas amigas del Fondo de Población (<i>UNFPA</i>) para finalizar su Plan de
Continuidad de Negocio.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Todos tenemos problemas, pero de eso a una crisis hay un trecho, distancia
que a veces no queda clara por falta de definición. Se trata en definitiva de
una escala temporal que comienza con la localización un problema de desconocido
impacto y consecuencias. El problema original se convierte en incidente cuando
requiere una intervención de nuestro mecanismo de –primera- respuesta sea el
que sea. Cuando la cosa se pone fea y parece ser que el sexto sentido del que
responde le dice que esto no tiene muy buena pinta, pues ¿que hace?, lo de
siempre, llama al jefe. Y el Jefe es quien declara si hay o no hay crisis. Eso
ha sido así contado un poco en “Román paladino” o español de andar por casa.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">En el Sistema de Gestión de la Resiliencia Corporativa (<i>ORMS </i>del inglés),
el Sistema de Gestión de Incidentes (<i>Incident Command System, ICS</i>; que es
básicamente nuestro servicio de seguridad y/o de emergencias internas,
incluyendo médicos, psicólogos, encargados de instalaciones y recursos humanos
de apoyo) se encarga de estimar la cuantía y calidad del impacto recibido
(irrelevante, limitado, relevante, severo y extremo/critico). En cuanto tiene
una somera idea de ello, determina si lo puede solucionar por si mismo, lo debe
de monitorizar y avisar a alguien para alertar por si acaso o lo lanza al
siguiente o más alto supervisor si se trata de un problema grave o gravísimo. También
el <i>ICS </i>dispone de mecanismos que son automáticos, como evacuaciones sanitarias,
evacuaciones de edificios, et al. que basados en determinados protocolos no
precisa de autorización previa por la emergencia de que se trate.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Esto pone en alerta a los mecanismos de gestión de crisis que se preparan
para lo peor y esperan lo mejor. Estos mecanismos o están en si mismos
compuestos por los mas altos directivos o tienen línea directa con ellos y el
consejo de Dirección. Una vez declarada la crisis por la autoridad interna que
corresponda, sea el CEO o el equipo de gestión de crisis (<i>CMT</i>), se determinan
las medidas a llevar a cabo: seguir monitorizando, activar el plan de
continuidad (<i>business continuity</i>), recuperación de desastres (<i>IT Disaster
Recovery</i>) o lo que haga falta en función de la situación. Hemos pasado en poco
tiempo de un problema a un desastre o incluso una catástrofe. Estos dos últimos
en realidad se ven venir inmediatamente, no los eventos en si mismos que son
impredecibles pero si sus consecuencias y la magnitud del impacto recibido. Por
eso hay que prepara mecanismos que disminuyan al mínimo la respuesta inicial,
por limitada y exigua que sea, y que aceleren la integración del modo crisis en
el mecanismo de gestión integral. Aquí se hace ver la valía de conectar y
coordinar la preparación mediante un marco global como es la Resiliencia
Corporativa. Rompemos los silos en la preparación y estamos preparados para la
respuesta.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">Con todo lo anterior vemos que aunque haya procesos que puedan automatizarse
y producirse en aislamiento, el flujo regular obliga a pasar de un escenario a
otro escalable en envergadura desde el <i>ICS </i>hasta Gestión de Crisis, y es
Gestión de Crisis (conectado al mas alto escalón de mando) quien activa
Continuidad o recuperación de desastres e indica como se van a llevar a cabo y
cuales operaciones de recuperación, así como la relocalización si fuera
precisa.</span></div>
</blockquote>
<blockquote class="tr_bq">
<div class="MsoNormal" style="background-color: white; background-position: initial initial; background-repeat: initial initial; margin-bottom: 0.0001pt;">
<span style="color: #222222; font-family: "Arial","sans-serif"; font-size: 10.0pt; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: ES;">La conclusión final nos lleva a determinar que efectivamente gestión de
crisis juega un papel de coordinación que facilita enormemente la toma de
decisiones al más alto nivel y que encaja a la perfección con el concepto de
Resiliencia Corporativa. Esto no desmerece en absoluto el papel indispensable
que ha jugado la Continuidad de Negocio desde los 90 y las enormes contribuciones
que han permitido madurar el modelo hasta el estado actual. Desde el entorno de
respuesta inmediata de un negocio de pequeña o mediana entidad, las barreras o
diferencias entre gestión de crisis y continuidad de negocio siguen siendo muy
difusas o difíciles de identificar, en grandes empresas o instituciones la cosa
esta muy clara, la apuesta es resiliencia.<o:p></o:p></span></div>
</blockquote>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com1tag:blogger.com,1999:blog-33946654.post-65230512975032197202013-01-22T15:37:00.000+01:002013-01-22T15:37:09.532+01:00La caza del Octubre RojoNo voy a hablar de la <a href="http://es.wikipedia.org/wiki/La_caza_del_Octubre_Rojo">película cuyo título se corresponde con el de este post</a>, por mucho que Sean Connery sea uno de mis actores preferidos, pero he de reconocer que el "virus" <a href="http://unaaldia.hispasec.com/2013/01/operacion-octubre-rojo-un-malware-muy.html">descubierto</a> <a href="http://unaaldia.hispasec.com/2013/01/operacion-octubre-rojo-un-malware-muy_18.html">públicamente </a>estos últimos días, bautizado como "Octubre Rojo", me ha recordado a la película por más motivos que por la simple coincidencia en el nombre: el papel de las instituciones gubernamentales, la capacidad del "virus" para permanecer <i>sumergido </i>en los sistemas... Un material que bien podría servir como argumento para una típica <i>peli de espías</i> hollywoodense.<br />
<br />
Sin embargo, mi intención no es analizar las características de la película ni sus coincidencias con este malware en particular, sino hacer una pequeña reflexión acerca de este tipo de malware avanzado, forma tangible de las cada vez más conocidas <a href="http://en.wikipedia.org/wiki/Advanced_Persistent_Threat">APTs </a>(Advanced Persistent Threats, o amenazas persistentes avanzadas).<br />
<br />
En el fondo, todas las APTs funcionan de la misma forma. Un pequeño malware llega al destinatario, consigue ser ejecutado (por utilización de alguna vulnerabilidad del equipo o simplemente engañando al usuario) y se instala en el equipo de la víctima. A partir de ese momento, ese pequeño malware se dedica a conectarse periódicamente a una serie de servidores en Internet, los centros de control (conocidos como C&C, o Command and Control), desde los que se reciben las órdenes de las actividades maliciosas a llevar a cabo y/o a los que se envía la información recopilada.<br />
<br />
En primer lugar me gustaría hacer una observación acerca del papel de los antivirus frente a este tipo de ataques. Obviamente, el software anti-malware es de propósito general, y su objetivo no es identificar ataques dirigidos y personalizados, como suelen ser (en distinto grado) las APTs. No obstante, el comportamiento básico de este tipo de malware es bastante similar en todos los casos, y se basa en actuar como puerta trasera. ¿No sería posible hacer un esfuerzo especial en identificar este tipo de patrón de funcionamiento? Siendo consciente de la dificultad que puede suponer, creo que este es uno de los ámbitos en los que más se puede incidir en un futuro cercano.<br />
<br />
Creo que también es destacable una de las características del "Octubre Rojo": el nivel de personalización (más allá de los destinatarios) del vector de infección (unos archivos en excel y word) era bastante bajo. O dicho de otro modo: esos mismos archivos podrían haber ido dirigidos a cualquiera. ¿Es la sociedad consciente de la existencia de esos ataques?<br />
<br />
Redundando en la pregunta anterior, creo que también es destacable que el objetivo potencial del "Octubre Rojo" era prácticamente <i>todo tipo de información</i> que tuviera el usuario. ¿Somos conscientes de que <i>TODA </i>la información que tenemos en nuestro equipo es objetivo potencial de un atacante?<br />
<br />
Por último, creo que también es destacable la modularidad del "Octubre Rojo", y su capacidad para cargar, ejecutar y eliminar de forma dinámica diferentes módulos con finalidades diversas, una vez realizas las acciones correspondientes. Me temo que ese planteamiento va a estar cada vez más extendido entre el malware moderno, de modo que cada vez será más complicado su identificación. Está preparado el mercado antimalware para hacer frente a software malicioso de estas características?<br />
<br />
En definitiva, creo que la caza del Octubre Rojo puede ser una de las primeras batallas que tenga que lidiar la industria del antimalware a los ojos de la luz pública, y posiblemente sus resultados nos sirvan para hacernos una idea de la capacidad real de la sociedad para hacer frente a este tipo de amenazas. ¿Conseguirán cercar y dar caza al Octubre Rojo? ¿O conseguirán sus <i>tripulantes </i>alcanzar sus objetivos (si no lo han hecho ya)?Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-21514970482091578292012-12-27T15:11:00.001+01:002012-12-27T15:11:21.627+01:00Que espero del 2013No 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.<br />
<br />
Esto es lo que yo espero para el próximo año 2013:<br />
<br />
<ul>
<li>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. </li>
<li>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.</li>
<li>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). </li>
<li>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... </li>
<li>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. </li>
<li>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...</li>
<li>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. </li>
</ul>
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.<br />
<br />
Feliz navidad, que paséis unas buenas vacaciones, y nos vemos en 2013.<br />
<br />
Saludos,<br />
<br />
JosebaJoseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-3363264161948632572012-12-10T15:56:00.000+01:002012-12-10T15:56:40.193+01:00El problema del Cloud ComputingQue 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <a href="http://www.agpd.es/portalwebAGPD/canaldocumentacion/legislacion/estatal/common/pdfs/RD_1720_2007.pdf">RDLOPD</a>. Si gestiona datos de tarjetas de crédito necesita que los servicios implementen las medidas de seguridad exigidas por <a href="http://es.wikipedia.org/wiki/PCI_DSS">PCI-DSS</a>. Si es una administración pública, necesitará que los citados servicios cumplan con las medidas de seguridad exigidas por el <a href="https://www.ccn-cert.cni.es/index.php?option=com_content&view=article&id=2420&Itemid=211&lang=es">ENS</a> para el nivel que corresponda en cada caso. Sencillamente, porque su negocio se lo exige.<br />
<br />
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 <a href="http://es.wikipedia.org/wiki/ISO/IEC_27001">ISO 27001</a>, 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 <a href="http://es.wikipedia.org/wiki/Software_como_servicio">SaaS </a>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 <a href="http://es.wikipedia.org/wiki/Ley_USA_PATRIOT">Patriot Act</a> 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?<br />
<br />
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.Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com8tag:blogger.com,1999:blog-33946654.post-62013568764467041072012-11-22T15:26:00.000+01:002012-11-22T15:26:10.992+01:00Reflexiones sobre el congreso nacional de itSMF #Vision12Este 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.<br />
<br />
En este post simplemente quería destacar algunos aspectos que me parecen dignos de reflexión:<br />
<br />
<ul>
<li>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.</li>
<li>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.</li>
<li>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. </li>
<li>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. </li>
<li>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? </li>
</ul>
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!Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-7028805474270144442012-10-31T08:28:00.000+01:002012-10-31T08:28:13.075+01:00Todas las seguridadesA 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:<br />
<div>
<ul>
<li><b>Seguridad (1)</b>: 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 <i>security</i> como la <i>safety</i>, es decir, todo lo relacionado con los riesgos laborales, la seguridad patrimonial (cajas fuertes, vigilantes jurado, furgones blindados), la seguridad informática... </li>
<li><b>Seguridad (2)</b>: También se usa el término seguridad como traducción exclusiva del <i>security </i>anglosajón. En este caso dejaríamos de lado todo lo relacionado con la <i>safety (</i>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. </li>
<li><b>Seguridad de la información</b>: 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 <i>security</i>. 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 <i>contenedores de información</i>, 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. </li>
<li><b>Seguridad patrimonial</b>: 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. </li>
<li><b>Seguridad física</b>: 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. </li>
<li><b>Seguridad lógica</b> o <b>seguridad informática</b>: 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.</li>
<li><b>Ciberseguridad</b>: 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. </li>
</ul>
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...</div>
Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-91598479291866953562012-10-22T15:17:00.000+02:002012-10-22T15:17:18.101+02:00Cumplimiento ENSHoy os quiero hablar de una iniciativa que me han propuesto "apadrinar" (o para ser más exactos, promover): el mini-site <a href="http://www.cumplimientoens.com/">www.cumplimientoens.es</a>. 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...<br />
<br />
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 <a href="http://www.cumplimientoens.com/colabora.html">pantalla de colaboración</a>. ;-) 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...Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-63148033046012388252012-10-18T09:55:00.000+02:002012-10-18T09:56:43.929+02:00Publicada ISO/IEC 27013:2012 - Integración de ISO 20000 e ISO 27001Esta semana se ha publicado la nueva norma <a href="http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43753" target="_blank">ISO/IEC 27013:2012</a>, 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.<br />
<br />
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...Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com0tag:blogger.com,1999:blog-33946654.post-53893281611619861502012-10-17T22:02:00.000+02:002012-10-17T22:08:06.405+02:00Nos vemos en ENISE 6<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCpTkZ8ihG_qbngetmQPMQNYQU2T9GhWwEYbPF4LQY1H_HujEwNquA-EJERH74vj8XT5Kvr1bNT82T35SrZw5PDTSXEsn8RNSijo-ZxvuSQ8SvvQEIAaIqvKOEAwgzuny-wFv6/s1600/cab_enise_izq.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="74" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCpTkZ8ihG_qbngetmQPMQNYQU2T9GhWwEYbPF4LQY1H_HujEwNquA-EJERH74vj8XT5Kvr1bNT82T35SrZw5PDTSXEsn8RNSijo-ZxvuSQ8SvvQEIAaIqvKOEAwgzuny-wFv6/s200/cab_enise_izq.png" width="200" /></a></div>
<span style="background-color: #f3f3f3; font-family: inherit;">El próximo martes 23 y miércoles 24 de Octubre de 2012 se celebra en León la sexta edición de <a href="http://enise.inteco.es/" target="_blank">ENISE</a>, el encuentro internacional de seguridad de la información que organiza anualmente <a href="http://www.inteco.es/" target="_blank">INTECO</a> bajo el lema "<i>La Ciberseguridad, un elemento clave para el futuro de nuestra sociedad</i>".</span><br />
<span style="background-color: #f3f3f3; font-family: inherit;"><br /></span>
<span style="background-color: #f3f3f3; font-family: inherit;">Un año más estaré presente en representación de la empresa en la que trabajo, <a href="http://www.nextel.es/" target="_blank">Nextel</a>, participando en el taller <a href="http://enise.inteco.es/sessions/programa/horario/retos_de_ciberseguridad_en_la_modernizacion_de_la_Administracion" target="_blank">T12 - Retos de ciberseguridad en la modernización de la Administración</a> con la presentación <i>Aprovechando oportunidades, cloud en la e-Administración</i>. 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.</span><br />
<span style="background-color: #f3f3f3; font-family: inherit;"><br />
Por la tarde, como no podía ser de otra manera, también asistiré al taller <a href="http://enise.inteco.es/sessions/programa/horario/Encuentro_de_blogueros_de_seguridad_2012" target="_blank">T14 - Encuentro de blogueros de seguridad 2012</a>. 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 <a href="http://www.inteco.es/blogs/inteco/Seguridad/BlogSeguridad/ultimos_articulos/" target="_blank">blog de seguridad de INTECO</a>. </span><br />
<span style="background-color: #f3f3f3; font-family: inherit;"><br />
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! ;-)</span>Joseba Enjutohttp://www.blogger.com/profile/18377573571989848760noreply@blogger.com1