viernes, 19 de diciembre de 2008 2 comentarios

¿Dónde están las copias, matarile, rile, rile?

Tras la difusión de la noticia del "barrido informático", el mismo viernes toda la prensa se hizo eco de que ese "borrado de datos" es un supuesto delito. Como continuación a la noticia, quiero reflexionar ahora sobre algunas deficiencias obvias que se perciben en este asunto y que ponen de manifiesto una mala gestión en la seguridad de los sistemas de información de Moncloa.

Aunque por las noticias se ha sabido que dicho barrido fue encargado a una empresa especializada en destruir datos (imagino que se refiere a que se han utilizado técnicas de borrado seguro, de eliminación de datos que no permite la posterior recuperación), la primera cuestión que surge es, ¿Donde están las copias de seguridad de dichos sistemas de información?
Si bien es posible destruir de forma inmediata la información almacenada dentro de los sistemas, eliminar las copias de seguridad requiere la destrucción de todos los soportes utilizados durante meses para almacenar dicha información. Además, dichos soportes no deben guardarse nunca en el lugar donde se encuentran los sistemas de información a lo que respaldan. Por tanto, si tales hechos se hubieran producido, deberían aparecer ciertas evidencias físicas sobre el supuesto barrido.

También sorprende mucho la ausencia de logs de todas estas acciones y la importancia que debería tener ya actualmente la figura del auditor de sistemas de información. Si en la gestión económica siempre hay una segregación de funciones respecto a quien solicita y tramita, quién ejecuta el pago y quién fiscaliza el gasto, en los sistemas de información deberíamos empezar ya a disponer de estos tres roles o funciones de control segregados e independientes. Deberían existir siempre la figura del administrador de sistemas, el responsable de seguridad y el auditor, de forma que un sólo rol no sea todopoderoso para poder hacer cualquier cosa.

De esta manera, las actividades de "barrido informático" podrían haber contado con la autorización o el visto bueno del administrador, pero se habría topado con el responsable de seguridad que habría evitado la extralimitación de funciones del área de sistemas y al auditor que podría recoger las evidencias suficientes para realizar la oportuna denuncia si los hechos son constitutivos de delito.

Igual que estas figuras en la gestión del dinero nos parecen imprescindibles, en la gestión de información todavía no hemos adquirido la madurez necesaria como para entender que estos tres roles deben empezar a coexistir en nuestros sistemas de información (al menos, en los más importantes). Y es que realmente no somos conscientes de que la información anda muy descontrolada y su gestión carece muchas veces del control necesario.

De lo contrario, ¿qué confianza va a darnos la E-Administración si cualquier político es capaz de someter al personal tecnológico para que desaparezca información sin control? Tendremos que esperar a que ocurran "Gescarteras de información" o "Forum filatélicos de datos" para poner los controles necesarios?

Para terminar, quiero enlazar a las interesantes reflexiones que realiza Bruce Schneier sobre la importancia de la figura de la auditoría como órgano de control interno en Schneier on Security: Audit.
6 comentarios

"Barrido" o "borrado" masivo informático. Una nueva profesión, los barrenderos informáticos.

A vueltas de la no regulación de nuestra profesión, he decidido usar el blog para denunciar todos los incidentes o situaciones donde se use la Informática como excusa.
Ultimamente la radio es mi principal fuente de información. Hoy de camino al trabajo no he podido sorprenderme más al escuchar un titular sobre la entrevista de Zapatero ayer en Cuatro. En diferentes periódicos, la noticia hace directamente referencia al hecho de un supuesto "Barrido informático" que eliminó datos.
En los diferentes medios se cubre la noticia como son El País, La Vanguardia, Público.

Estas cosas siempre me hacen gracia e indignan al mismo tiempo. La frase "barrido informático" de nuevo es la excusa por la que se desconocen unos hechos pero sin embargo, en ningún medio se aclara qué coj...s es un "barrido informático". A ver si entre todos lo logramos aclarar:

  • Opción a (y más probable): En Moncloa el servicio de limpieza lo realiza personal informático porque tal como está el mercado es más rentable limpiar que programar.

  • Opción b: El señor Aznar hizo un "del *.*" o "erase *.*" de su ordenador y eliminó todos los documentos que curiosamente sólo estaban en soporte electrónico.

  • Opción c: El señor Aznar, como presidente de Gobierno disponía de la clave de administrador y eliminó todos los datos de todos los servidores.


Voy a justificar por qué la opción a es la más probable.
  • En la opción B, hemos de suponer que esos documentos solo estaban en el ordenador del Sr. Aznar y por tanto, tenía privilegios suficientes para borrarlos. Por otro lado, si se trata de un Pc doméstico, es probable que el servicio de informática de Moncloa no hiciera copias de seguridad. En cualquier caso, si esta fuera la hipótesis correcta, ¿Cómo están esos documentos en soporte papel y publicados en un periódico? ¿Es que es el Sr. Aznar el responsable directo del envío de las únicas copias en papel?


  • En la opción C, la asignación de privilegios excesiva podría haber permitido al Sr. Aznar un abuso de privilegios y por tanto, la destrucción de esa información. Pero...¿Qué pasa con las copias de seguridad? ¿Es que también fue capaz de borrar la información en esos soportes que supuestamente debe almacenarse durante varios años y que debe realizarse de forma diaria?


Mi opinión particular es que debe tratarse de la Opción A, porque además, la opción B y C implica un delito recogido por el Código Penal dentro del Capítulo IX, «De los Daños», del Título XIII, «Delitos contra el patrimonio y contra el orden socioeconómico». En el artículo 264.2 que literalmente dice "
«2. La misma pena se impondrá al que por cualquier medio destruya, altere, inutilice, o de cualquier otro modo dañe los datos, programas o documentos electrónicos ajenos contenidos en redes, soportes o sistemas informáticos».
Obviamente todos pensamos que lo que el Sr. Zapatero quiso decir ayer no es que el Sr. Aznar cometiera un delito relacionado con la destrucción de datos, por tanto y por descarte, el barrido tuvo que ser cosa de barrenderos informáticos.

De todas formas, señores políticos, solo quiero dejar una advertencia.
"La Informática que ustedes no quieren reconocer como Ingeniería no va a permitir que sea arrastrada por el lodazal de sus intereses para que sirva de coartada o excusa que les habilite o permita impunidad ante todo tipo de fechorías. Detrás de cada "fallo informático" siempre puede haber un "peritaje informático" y lucharemos para que todo este tipo de circunstancias sean aclaradas y sobre todo, sirvan para depurar responsabilidades."


Buceando un poco por las noticias publicadas en su momento sobre este asunto, he dado con bastantes referencias interesantes:

Europa Press, 25/05/2006
APEDANICA(Asociación para la Prevención y Estudios de Delitos, Abusos y Negligencias en Informática y Comunicaciones Avanzadas) ratifica ante un Juzgado de Madrid la querella contra Aznar por el borrado de archivos de La Moncloa
El presidente de la Asociación para la Prevención y Estudios de Delitos, Abusos y Negligencias en Informática y Comunicaciones Avanzadas (APEDANICA), Miguel Ángel Gallardo Ortiz, ratificó hoy ante el Juzgado de Instrucción número 9 de Madrid la querella presentada contra el ex presidente del Gobierno José María Aznar por el borrado de los archivos informáticos del Palacio de la Moncloa, tras el abandono del poder por el Gobierno del PP después de las elecciones generales de marzo de 2004.
El titular del Juzgado de Instrucción número 9 de Madrid, Mario Pestana Pérez, incoó diligencias previas en junio de 2004 para aclarar si existió delito en el citado borrado de archivos a raíz de una denuncia interpuesta por el abogado murciano José Luis Mazón, en la que también pidió investigar al Ministerio del Interior, cuyo titular era entonces Ángel Acebes, por un "volcado" de documentos relacionados con los atentados del 11-M.
La querella presentada por APEDANICA se refiere a los mismos hechos recogidos en la denuncia del abogado Mazón, quien está personado en la causa como acusación popular junto con la abogada Encarnación Martínez, que también presentó otra querella criminal sobre el mismo contenido. Ratificada la denuncia y las dos querellas presentadas por estos hechos, el juez Pestana se pronunciará en los próximos días sobre si las admite a trámite o no.
BORRADO DE ARCHIVOS
En concreto, el abogado murciano interpuso una denuncia el 14 de diciembre de 2004, en la que cita dos noticias publicadas por el diario "El País" el 13 de diciembre de 2004 en las que se informaba de que una empresa cobró 12.000 euros por eliminar archivos informáticos y sus respectivos copias de seguridad de La Moncloa, mientras que en el Ministerio del Interior se realizó un "volcado" de documentos sobre los atentados del 11 de marzo de 2004 en Madrid.
Asimismo, añade que durante la comparecencia ante la Comisión de investigación del 11-M, el presidente del Gobierno, José Luis Rodríguez Zapatero, "ratificó la citada información" al señalar que los archivos informáticos, incluidas las copias de seguridad, fueron destruidos en los días posteriores a los atentados.
Mazón señala en su denuncia que, aunque Rodríguez Zapatero manifestó entonces que no pediría responsabilidades por los hechos, "la aplicación del Código penal en un Estado de Derecho no está sometido al principio de oportunidad". Agrega que "nadie, ni el Gobierno ni el Poder Judicial, puede otorgar dispensas penales que impidan la investigación de una conducta sospechosamente delictiva.

Europa Press, 26/02/2005
La Abogacía del Estado estima que no hay datos suficientes para saber qué tipo de documentos destruyó el Gobierno Aznar
La Abogacía General del Estado establece que los datos aportados por la subdirección informática de Presidencia del Gobierno son "manifiestamente insuficientes" para determinar la naturaleza de los documentos destruidos por el gabinete del anterior jefe del Ejecutivo, José María Aznar, antes de abandonar La Moncloa. Además, en el informe elaborado al respecto por los servicios jurídicos del Estado, al que tuvo acceso Europa Press, se recomienda además que se paguen los gastos derivados del proceso de destrucción de documentación.
El citado informe fue elaborado a petición del actual Director del Gabinete de la Presidencia, José Enrique Serrano, para conocer los trámites a seguir ante una serie de operaciones de destrucción de documentos y de borrado de los sistemas informáticos, "realizadas en fecha inmediatamente anteriores a la toma de posesión" del nuevo Ejecutivo. Después, el Grupo parlamentario de IU lo solicitó en el Congreso de los Diputados.
Así, el equipo de José Luis Rodríguez Zapatero formulaba consulta respecto a dos aspectos concretos: Al hecho del borrado en sí mismo, con la posible desaparición de documentos oficiales de la Administración, y las facturas que, por una actividad de este tipo, han sido presentados por algunas empresas.
TRES HIPÓTESIS DE TRABAJO
Ante esto, los servicios jurídicos del Estado establecen en su informe distintas hipótesis de las responsabilidades que se pudieran derivar de la destrucción de documentos del Gobierno, dependiendo de si se tratara de documentos originales, copias de originales o informes o borradores de un partido político.
"Hay que afirmar que si la mencionada destrucción y borrado afecta a documentos personales o con carácter general, a documentos ajenos o extraños a la estricta área de funciones o competencias de la Presidencia del Gobierno (documentos personales, documentos del partido político que sostenga al Gobierno, documentos del Presidente en su condición de líder del partido...), nada habrá de decirse de la destrucción-borrado realizada por ser una actividad neutra desde la óptica el examen de los intereses generales", se especifica.
Como segunda hipótesis, se señala que si la destrucción o borrado atañe a documentos de carácter administrativo u oficial que constituyan "copias almacenadas en archivos o sistemas informáticos" de otros documentos originales que estén en poder de la Administración, "la conducta realizada será igualmente neutra".
En tercer lugar, formulan que si se examina la posibilidad de que las operaciones de destrucción y borrado vengan referidas a originales de los que no haya copia, se podría deducir responsabilidad administrativa por incumplimiento de la normativa reguladora del Patrimonio Documental --con su correspondiente sanción económica si el daño es cuantificable-- y responsabilidad disciplinaria exigible a los poseedores de documentos administrativos de acuerdo con la legislación del Patrimonio Histórico Español.
En cuanto a las posibles responsabilidades penales, desde la Abogacía del Estado se recuerda que el artículo 413 del Código Penal sanciona, en la custodia de documentos, a "la autoridad o funcionario público que, a sabiendas, sustrajere destruyere u ocultare, total o parcialmente, documentos cuya custodia le esté encomendada por razón de su cargo".
No obstante, en el informe recogido por Europa Press se resalta que el examen de la documentación enviada no permite llegar a una "idea cierta" y "ni siquiera aproximada" sobre el contenido de los documentos destruidos o borrados. "Y este dato fáctico es crítico para llegar a una conclusión jurídica razonada", se especifica.
jueves, 18 de diciembre de 2008 0 comentarios

Tomandose en serio la palabra confidencial

Ayer nombraba la Ley de Secretos oficiales y hoy sale a la palestra en base a unas declaraciones del Ministro Moratinos que está preocupado e indignado por las continuas filtraciones de su Ministerio a la prensa. Parece que alguien si quiere tomarse en serio la palabra confidencial y está dispuesto a tomar las decisiones que considere oportunas para garantizar la correcta custodia de la información.
Parece un tema baladí pero es preocupante que a tan altas esferas, España vaya perdiendo papeles o "los papeles". El Ministerio de Exteriores, junto con el de Defensa e Interior forman tres patas muy importantes en la protección de la información sensible del Estado.

La noticia que aparece en varios medios como "La Ser", "El Mundo" o "Público" comenta precisamente cómo se plantea la reforma de la Ley que Secretos oficiales que ayer comentaba.

Aunque por lo que venía escuchando en la radio, todavía no tiene muy claro las acciones a tomar y baraja la implantación de protocolos de intercambios de información y custodia basados en modelos militares, lo suyo sería realizar un análisis de riesgos de la problemática del Ministerio. Sería un bonito proyecto que le permitiría identificar los requisitos de seguridad de sus actividades, y no solo los criterios de confidencialidad.

Tal como aparece en prensa, las medidas apuntan a una implantación de protocolos de intercambio de información. En concreto, todos estos aspectos pueden ser fácilmente resueltos si nos apoyamos en la norma ISO 27002:2005, en concreto en el objetivo de control 10.8 y unos buenos medios sería la implantación de los siguientes controles:
  • 10.8.1. Política de intercambio de información

  • 10.8.2 Acuerdos de intercambio

  • Soportes físicos en tránsito

  • Mensajería electrónica

  • Sistemas de información empresariales

Lo recogido en prensa al respecto es:
"Moratinos avanzó que este grupo de trabajo está analizando distintos "modelos europeos" en gestión y custodia de documentos, así como el modo de circulación de documentos que emplea la OTAN.
El jefe de la Diplomacia española consideró además que "probablemente habrá que revisar" la Ley de Secretos Oficiales para "garantizar" la seguridad de los textos y evitar filtraciones que, en su opinión, "debilitan" la gestión del Estado y del Gobierno.
Moratinos, que explicó que se ha decidido cesar al cónsul de España en Sao Paulo porque él mismo ha reconocido que filtró el informe, reiteró que su departamento aún investiga cómo desaparecieron los llamados 'papeles de Guantánamo' del Ministerio.
Por otra parte, el ministro no pudo avanzar qué tipo de medidas emprenderá contra Manuel Aguirre de Cárcer, el autor del informe 'muy secreto' desvelado por 'El País' que trasladaba la petición estadounidense sobre las escalas de los vuelos y actual embajador en misión especial para cuestiones de Desarme.
Moratinos precisó que hay un jefe inspector de la Carrera Diplomática encargado de este caso y que, cuando concluya su investigación, propondrá medidas."


Es también ejemplarizante que las fugas generen un proceso disciplinario y que supongan el cese del personal que la produce. Si no, sólo se anima a la impunidad y en seguridad de la información, ésto es siempre un mal precedente.
El problema es seguramente que otras veces es el propio Ministerio el interesado en realizar dichas filtraciones, aun a costa de la seguridad del Estado.
martes, 16 de diciembre de 2008 0 comentarios

Lo que debe saber un terrorista, por Arturo Pérez-Reverte

Este fin de semana,como lector fiel a la columna de Arturo Pérez-Reverte en el suplemento XLSemanal, me ha llamado la atención su artículo. Escribe con tono sarcástico sobre el afán informativo de la prensa española y nuestros políticos y cómo esto aparte de no aportar mucho al ciudadano, sirve al terrorista para depurar sus métodos. Y es que Perez Reverte tiene mucha razón en que en estos casos, más información implica menos seguridad. Pero mejor leer su artículo en "LO QUE DEBE SABER UN TERRORISTA", de Arturo Pérez-Reverte.

Y es que parece que no entra dentro de nuestra cultura el tener y guardar secretos. Hace no mucho comentaba en un post "Cuando confidencial no significa nada" como es algo cotidiano que cierta información clasificada como confidencial sea publicada en prensa. Hoy profundizando un poco más en la materia, y recordando algunos apuntes de la metodología Magerit 2.0 cuando hablaba de la clasificación de la información me he dado una vuelta por la Ley 9/1968, de 5 de abril, reguladora de los Secretos Oficiales y su reglamento para ver cómo se contemplan los aspectos esenciales de gestión de la información: clasificación, traslado, almacenamiento, destrucción, desclasificación y todo parece estar bien definido.

Otra cosa es que la ley se incumpla, que en este país de eso también sabemos mucho.
miércoles, 10 de diciembre de 2008 2 comentarios

Estado de situación de la serie ISO 27000 a fecha 10 de diciembre 2008

A continuación voy a listar el conjunto de normas publicadas o en proceso de elaboración de la serie ISO 27000 a fecha 10 de diciembre de 2008. Estos resultados son fruto de una consulta a la Web de ISO.org en relación al área de trabajo del Subcomité 27 del JTC 1 - IT Security techniques.

El estado de las normas se codifica en base a unos acrónimos que ISO tiene identificados y que son:
  • 1.PWI = Preliminary Work Item - initial feasibility and scoping activities

  • 2.NP = New Proposal (or study period) - formal scoping phase

  • 3.WD = Working Draft (1st WD, 2nd WD etc.) - development phase

  • 4.CD = Committee Draft (1st CD, 2nd CD etc.)- quality control phase

  • 5.FCD = Final Committee Draft - ready for final approval.

  • 6.DIS = Draft International Standard - nearly there. Stage 40.

  • 7.FDIS = Final Draft or Distribution International Standard - just about ready to publish. Stage 50.

  • 8.IS = International Standard - published. Stage 60.

  • 9. Under revisión. Stage 90.


Como podréis comprobar en la siguiente relación de normas, hay bastantes ya en el Stage 40 y 50 lo que indica que pronto pueden ver la luz. La situación actual del marco internacional de normas ISO 27000 es:

  • ISO/IEC FCD 27000.
    Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary. Stage:40.99

  • ISO/IEC 27001:2005.
    Information technology -- Security techniques -- Information security management systems -- Requirements. Stage:60.60

  • ISO/IEC 27002:2005
    Information technology -- Security techniques -- Code of practice for information security management. Stage:90.92

  • ISO/IEC FCD 27003
    Information technology -- Information security management system implementation guidance. Stage:40.20

  • ISO/IEC FCD 27004.2
    Information technology -- Security techniques -- Information security management -- Measurement. Stage:40.20

  • ISO/IEC 27005:2008
    Information technology -- Security techniques -- Information security risk management. Stage:60.60

  • ISO/IEC 27006:2007
    Information technology -- Security techniques -- Requirements for bodies providing audit and certification of information security management systems. Stage:60.60

  • ISO/IEC WD 27007
    Guidelines for Information security management systems auditing. Stage:20.60

  • ISO/IEC FDIS 27011
    Information technology -- Information security management guidelines for telecommunications organizations based on ISO/IEC 27002. Stage:50.60

  • ISO/IEC NP 27012
    Information technology - Security techniques -- ISM guidelines for e-government services. Stage:10.99

  • ISO/IEC NP 27032
    Guidelines for cybersecurity. Stage:10.99

  • ISO/IEC NP 27033
    Information technology -- IT Network security.Stage:10.99

  • ISO/IEC CD 27033-1
    Information technology -- Security techniques -- IT network security -- Part 1: Guidelines for network security. Stage:30.60

  • ISO/IEC WD 27033-2
    Information technology -- Security techniques -- IT network security -- Part 2: Guidelines for the design and implementation of network security. Stage:20.60

  • ISO/IEC WD 27033-3
    Information technology -- Security techniques -- IT network security -- Part 3: Reference networking scenarios -- Risks, design techniques and control issues. Stage:20.60

  • ISO/IEC NP 27033-4
    Information technology -- Security techniques -- IT network security -- Part 4: Securing communications between networks using security gateways - Risks, design techniques and control issues. Stage:10.99

  • ISO/IEC NP 27033-5
    Information technology -- Security techniques -- IT network security -- Part 5: Securing Remote Access - Risks, design techniques and control issues. Stage:10.99

  • ISO/IEC NP 27033-6
    Information technology -- Security techniques -- IT network security -- Part 6: Securing communications across networks using Virtual Private Networks (VPNs) -- Risks, design techniques and control issues. Stage:10.99

  • ISO/IEC NP 27033-7
    Information technology -- Security techniques -- IT network security -- Part 7: Guidelines for securing (specific networking technology topic heading(s) to be inserted3) -- Risks, design techniques and control issues. Stage:10.99

  • ISO/IEC NP 27034
    Guidelines for application security. Stage:10.99

  • ISO/IEC NP 27037
    Information technology - Security techniques -- on Information security management: Sector to sector interworking and communications for industry and government . Stage:10.99


El detalle de los diferentes escalones dentro de cada nivel o stage lo podéis consultar en Stages ISO.
jueves, 4 de diciembre de 2008 4 comentarios

Supuesto "fallo informático" cuesta una vida humana

Hoy leo con tristeza un titular de "El Mundo" donde se destaca "Un sindicato achaca a un fallo informático los errores en el crimen de A Lama".

La noticia es recogida en otros medios con similar contenido, donde se destaca que el aparato GPS funcionó y generó la notificación de la posición al sistema de recogida de alarmas pero que el funcionario fue incapaz de poder gestionarla por no poder verificar la incidencia.

Como informático y como conocedor de los temas relacionados con la seguridad de la información, siempre me preocupa la poca conciencia que parece haber sobre la importancia tanto de la correcta instalación como de la gestión de un sistema de información. Lo que ya me pone los pelos de punta es pensar que quien adquiere un sistema como este, pensado para notificar una situación potencialmente peligrosa para una víctima de la violencia de género, no cuida hasta el último detalle para garantizar la fiabilidad del mismo. Y es que desgraciadamente en este caso, se vuelve a cumplir algunas máximas de la (in)seguridad:
  • Backwards Maxim: La mayoría de la gente asumirá que todo es seguro hasta que se les muestren evidencias significativas de lo contrario, justo lo contrario de lo que sugiere una aproximación razonable.

  • Segunda Ley de Schenier: el control será confundido irremediablemente con seguridad.

Ya anteriormente en este blog he recogido algunas opiniones sobre lo preocupante que es ver el "fallo informático" como el comodín de la irresponsabilidad y lo relevantes que empiezan a ser ya algunos de estos fallos. Era de esperar que un error de un sistema informatico acabaría costando vidas humanas. Es más, en la metodología que utilizo para hacer análisis de riesgos contemplamos esta escala de valoración para identificar aquellos procesos donde un incidente de seguridad podría acabar con estos trágicos resultados. Es habitual que el entrevistado se asombre dado que la escala tiene en cuenta el número de victimas para contemplar su gravedad, pero que dentro de ciertos sectores parece un criterio inaplicable o exagerado.
En el post "Fallos informáticos, esos animalillos (gremlins) sin padre" ya apuntaba sobre la importancia que van a empezar a tener estos fallos a los que en general damos poca importancia y que socialmente aceptamos. Sin embargo este tipo de hechos deben y merecen ser esclarecidos y sobre todo, deben depurar responsabilidades. Que un sector no disponga de atribuciones profesionales no debe dar pie a la no profesionalidad de las personas que ejecutan o realizan estas actividades.
Esta vez, el Consejo de Colegios de Ingenieros en Informática, que últimamente anda movilizado por las cuestiones ya conocidas en relación a la regulación de la Ingeniería e Ingeniería Técnica en Informática, ha ofrecido peritos informáticos para determinar las causas del fallo y que se atribuyan responsabilidades y sobre todo, cambios para la mejora de este tipo de servicios tan críticos.Tal como explica la noticia:
"El Consejo de Colegios de Ingenieros en Informática (CCII) pondrá a disposición de las partes interesadas sus peritos informáticos para determinar si el sistema informático funcionó o no correctamente en el caso de la muerte de una mujer el pasado fin de semana en Pontevedra. La organización se ofrece así a realizar un peritaje formal sobre la materia, con la finalidad de esclarecer la posible responsabilidad del fallo en el sistema informático de vigilancia de maltratadores y determinar las causas reales que lo motivaron. Con esta iniciativa pretenden evitar "que en un futuro se vuelvan a producir hechos similares, luctuosos y que generan una enorme alarma social. El CCII no tolerará que "la responsabilidad derivada de los hechos termine en un fallo del sistema informático".


Y es que una profesión debe estar a las duras y a las maduras. La misión del peritaje informático es esclarecer este tipo de situaciones y sobre todo, aprender de los incidentes. No debemos caer en el error de confundir los medios técnicos con la solución. Un sistema informático no es un conjunto de equipos, son también las personas que los administran y las que lo utilizan. La tecnología debe tener siempre unos objetivos y la gestión de los mismos debe verificar que éstos se alcanzan. En este caso, este sistema era un mecanismo de control con el objetivo de proteger a las victimas de la violencia de género de sus maltratadores. Si finalmente el objetivo no se ha logrado, puesto que hay un fallecido, se deben revisar de nuevo todo el funcionamiento para garantizar que realmente es una solución al problema planteado. De lo contrario, sólo estamos gastando dinero en hierro, silicio y cobre.

(A la memoria de María del Rosario Peso, de 57 años, víctima de la violencia de género. Mi más sentido pesame para los familiares.)
lunes, 1 de diciembre de 2008 0 comentarios

(In)Secure Magazine 19

Ya se ha publicado el número 19 de la revista (In)Secure Magazine. En este número, se tratan los siguientes contenidos:
  • The future of AV: looking for the good while stopping the bad

  • Eight holes in Windows login controls

  • Extended validation and online security: EV SSL gets the green light

  • Interview with Giles Hogben, an expert on identity and authentication technologies working at ENISA

  • Web filtering in a Web 2.0 world

  • RSA Conference Europe 2008

  • The role of password management in compliance with the data protection act

  • Securing data beyond PCI in a SOA environment: best practices for advanced data protection

  • Three undocumented layers of the OSI model and their impact on security

  • Interview with Rich Mogull, founder of Securosis


El número puede ser descargado en el siguiente enlace.
viernes, 28 de noviembre de 2008 1 comentarios

Computer Aided INvestigative Environment (CAINE) y Buenas Prácticas

Esta semana ha sido intensa de trabajo y sólo me permite hacer una recolección de dos post interesantes sobre análisis forense de otros blogs vecinos.

Por un lado, Sergio Hernando que nos informa sobre CAINE, una distribución Linux distribuida como LiveCD con herramientas para este propósito. Podéis leer extensamente el post en Linux forense: Computer Aided INvestigative Environment (CAINE).


Por otro, la Asociación AEDEL que recomienda la “Good Practice Guide for Computer-Based Electronic Evidence” de la Association of Chief Police Officers (ACPO). Parece ser todo un clasico del mundo del análisis forense, ya que su primera version data de 1999. Aporta un muy buen punto de partida para el examen inicial de un ordenador; multiples graficos y formularios que seran de utilidad.
lunes, 24 de noviembre de 2008 0 comentarios

Cryptool

He podido dar hace unos días con una aplicación didáctica sobre las tecnologías de cifrado llamada Cryptool.
Tal como explican en la propia Web, "Cryptool es una aplicación de aprendizaje electrónico gratuita para Windows. Puede utilizarse para aplicar y analizar algoritmos criptográficos. La versión actual de Cryptool se utiliza en todo el mundo. Soporta tanto los métodos actuales de enseñanza en escuelas y universidades como la concienciación de los empleados.La versión actual ofrece, entre otras cosas, lo siguiente:

  • Numerosos algoritmos criptográficos, clásicos y modernos (cifrado y descifrado, generación de clave, contraseñas seguras, autentificación, protocolos seguros, ...)

  • Visualización de varios métodos (p.ej. César, Enigma, RSA, Diffie-Hellman, firmas digitales, AES)

  • Criptoanálisis de ciertos algoritmos (p.ej. Vigenère, RSA, AES)

  • Métodos de medida criptoanalítica (p.ej. entropía, n-grams, autocorrelación)

  • Métodos auxiliares (p.ej. tests de primalidad, factorización, codificación en base64)

  • Tutorial sobre teoría de números.

  • Ayuda detallada on-line.

  • Script con más información sobre criptografía.



Desde su uso original para la formación en seguridad de una compañía, Cryptool ha evolucionado en un destacado proyecto de código abierto para temas.
En la siguiente presentación se explica extensamente el objetivo del proyecto Cryptool.


CrypTool: Criptografía para todos

From: gonalvmar,
1 week ago





CrypTool es un software libre para el aprendizaje de la criptografía



SlideShare Link


La presentación detallada del proyecto puede ser obtenida en este enlace.
domingo, 23 de noviembre de 2008 0 comentarios

¡Hambre no!

Acción contra el Hambre ha puesto en marcha una campaña bajo el título «Pídeselo a Al Gore» . Se pretende convencer al ex presidente de Estados Unidos, que recorre el mundo en su cruzada contra el cambio climático, para que financie una película sobre el hambre en el mundo.

Da verguenza ver como al primer quejido del "capitalismo" se han podido reunir los más grandes para planificar su salvación y que un esfuerzo muchisimo menor para solucionar el hambre en el mundo no consiga nunca sus metas.


Por eso, esta campaña de Acción contra el Hambre pretende que Al Gore, el "cruzado del cambio climático" que lucha contra un problema serio a medio y muy largo plazo, también centre sus esfuerzos en las lacras del presente, el hambre. El eterno problema olvidado e ignorado. Los 3.000 millones de euros necesarios son cifras ridículas en comparación con lo que se ha logrado movilizar para salvar al capitalismo.
Nuestra contribución es la adhesión al escrito para solicitar la creación de una película que pueda suponer una fuente de recaudación de dinero. Es quizás una de las entregas de datos de carácter personal más justificadas atendiendo a la finalidad de la recogida.

jueves, 20 de noviembre de 2008 0 comentarios

Aedel, Asociación Española de Evidencias Electrónicas

Ayer hojeando la revista SIC di con una asociación que me parece muy interesante y relevante de cara al futuro.

Asociación Española de Evidencias Electrónicas (AEDEL) nace con el objetivo de ser referente técnico y jurídico en aquello que las evidencias y pruebas electrónicas afecten a los ciudadanos, queriendo hacer posible con su actividad que la sociedad española – ciudadanos, padres, jóvenes, entidades públicas y privadas, sin distinción de tamaño o sector- puedan disfrutar de un marco de seguridad y confianza en los entornos digitales y en Internet.



Visión

Nuestra visión es ser la asociación líder en la promoción de iniciativas de estudio de evidencias y pruebas electrónicas, en la promoción normativa y regulatoria en este campo, en la difusión y capacitación del conocimiento, destacando como punto de encuentro de profesionales, sociedad, empresas y administración Pública, canalización cuanta iniciativa se enmarca en dotar de mayor confianza y robustez a las evidencias electrónicas y seguridad a las transacciones y operaciones que se desarrollan en el mundo telemático.


Misión

AEDEL nace con la finalidad de impulsar la seguridad y la confianza en la fiabilidad de las evidencias y pruebas electrónicas. Y ello mediante el impulso del conocimiento y desarrollo de las buenas prácticas y normas de voluntario cumplimiento, así como de la regulación de naturaleza legal que permita que la información en formato electrónico equipare su valor probatorio a la información existente en otros soportes.

Todas estas acciones se dirigen a posibilitar que la sociedad en su conjunto (ciudadanos, consumidores, padres, jóvenes, entidades públicas o privadas, sin distinción de su tamaño o sector) puedan disfrutar de un marco de seguridad y confianza en los entornos digitales incluido Internet.




Tal como expresan claramente, sus intenciones son todas muy loables y necesarias:

"AEDEL impulsará el conocimiento y el desarrollo de buenas prácticas y normas en torno a las evidencias electrónicas, así como su regulación legal con el fin de permitir que la información en formato electrónico equipare su valor probatorio –en procesos judiciales– a la información presentada actualmente como prueba legal en otros soportes.

Aspectos básicos como la igualdad de género ante el acceso a la sociedad de la información, o cuestiones prácticas de las pruebas electrónicas en teléfonos móviles y correo electrónico, son ejemplos de las lagunas que AEDEL pretende cubrir con información, formación y apoyo a la normalización y legislación.

AEDEL quiere, además, ser un punto de encuentro de profesionales, sociedad, empresas y Administración Pública, para la canalización de iniciativas orientadas a dotar de mayor confianza y robustez a las evidencias electrónicas y seguridad a las transacciones y operaciones que se desarrollan en entornos digitales."


Y estando Paloma Llaneza como presidenta y entre otros, el murciano Miguel Bañón Puente seguro que todas esas intenciones se transforman en proyectos que den frutos a la sociedad.
miércoles, 19 de noviembre de 2008 3 comentarios

19-N, Manifiesto por una informática digna

Informática (Del fr. informatique).
1. f. Conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la información por medio de ordenadores.

Ingeniería.
1. f. Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología.
2. f. Actividad profesional del ingeniero.


En su momento se decidió que las carreras universitarias que abarcaran el área de la informática debían pasar de ser licenciaturas a transformarse en ingenierías. Es muy interesante la reflexión que publica Enrique Barreiro en su blog con el Comunicado de la CODDI del cual extracto algunos apartados.
La primera vez que se asoció el término “ingeniería” con la informática fue en el año 1968 durante la primera conferencia de la OTAN sobre desarrollo de software. En dicha conferencia se constató que, aún ya por entonces, la capacidad de los ordenadores y la complejidad de los problemas que se solucionaban con ellos crecía demasiado rápidamente para la forma en que se desarrollaban sus programas, resultando con los métodos que se utilizaban entonces un software no fiable, con fallos frecuentes y con enormes necesidades de mantenimiento. Todo esto hizo que naciera la disciplina de la Ingeniería del Software, que tomando como fuente los métodos de las ingenierías clásicas establecía cómo desarrollar software siguiendo los estándares de cualquier ingeniería.
Además, hay que tener en cuenta que la complejidad de desarrollar un sistema informático no sólo radica en cómo realizar su software sino en cómo manejar la máquina que lo ejecuta. Muchos de los sistemas informáticos actuales no se desarrollan para ejecutarse en un único ordenador sino en una red. Por ejemplo, el también familiar Google realiza tan rápidamente sus búsquedas porque se ejecuta sobre una red de ordenadores que se estima entre unos 450.000 y un millón, distribuidos en más de 25 centros a lo largo y ancho del mundo. Tampoco es frecuente encontrar en otras ingenierías que se utilice una maquinaria tan compleja para una tarea tan aparentemente sencilla, útil y con tanto impacto en la sociedad. Por último, el despliegue del sistema informático de una empresa de servicios puede requerir la coordinación en su funcionamiento de miles de ordenadores y programas que interactúan entre si en tiempo real, y con miles de usuarios que solicitan un servicio inmediato y seguro a prueba de cualquier imprevisto.


Esto nos lo enseñaron en la carrera a todos y lo que se denominó "La crisis del software" fue un punto y aparte en el enfoque que debía de darse al diseño, desarrollo e implantación de sistemas de información. Hablamos de 1968 y aunque las cosas han cambiado un poco, muchos de aquellos errores se siguen constatando cincuenta años después. Las grandes empresas del software no dudan en apostar por la Ingeniería del software pero en empresas más pequeñas, los plazos y la rentabilidad lleva a renunciar a estos aspectos, aunque a medio y largo plazo estas empresas (o bien sus clientes) acaban pagándolo lo caro.

Por tanto, es el momento de que la Ingeniería en Informática sea reconocida como tal y la regulación llegue al diseño, fabricación e implantación de sistemas de información, dotando de unas garantías al consumidor y unas responsabilidades al "arquitecto" o al "constructor". En otras áreas y disciplinas llegó un momento similar y fueron reguladas por su importancia en la sociedad. No puede ser que construyamos el futuro con cimientos de barro. Los errores cada día son más relevantes y no puede permitirse que circule software sin unas garantías mínimas o de hacerlo, que acabe en los tribunales si se producen daños. Seguro que ante este tipo de responsabilidad, las presiones, las prisas, los plazos pasarán a un segundo plano dado que hacerlo mal saldrá más caro que seguir chapuceando.

No son reflexiones nuevas, es un reclamo que desde el mundo de la seguridad de la información viene anunciándose durante ya demasiado tiempo. Por algún motivo (económico seguramente), dada la impunidad del "error informático" o dado el carácter escudo que proporciona este fallo para esconder cualquier otra negligencia, conviene que las cosas no cambien.




Por el reconocimiento de un área que cada día demuestra más su relevancia y necesita empezar a ser considerada como una ingeniería por el bien de nuestro futuro, este blog cierra un día en apoyo a las reivindicaciones que los Ingenieros e Ingenieros Técnicos en Informática estamos realizando a través del MANIFIESTO POR UNA INFORMATICA DIGNA.

PD: En Murcia la manifestación ha sido un éxito superando todas las expectativas previstas. Unos 1500 manifestantes. La prensa nacional y regional también se hace eco de la repercusión de las movilizaciones.

Prensa nacional:

Prensa Regional:

Y los videos de los manifiestos en diferentes ciudades.
martes, 18 de noviembre de 2008 0 comentarios

El ciclo de desarrollo seguro del software (SDLC)

Desde hace unos días y con lo agitado del mundillo informático por el tema de mañana, la manifestación 19-N, parece que está llegando el momento de "tirar de la manta" y destapar los trapos sucios que deja la industria del software y su ausencia de regulación.

No quiero defender en ningún momento la "titulitis", pero hay una evidencia clara que todos los días pagamos caro, el software es inseguro. No voy a entrar en profundizar mucho sobre las causas dado que otros blogs amigos ya lo han hecho con gran calidad (Security at Work) y profundidad (Hispasec).

Mi aportación viene más a contar la R-(evolución) de Microsoft en este tema. Ni que decir tiene que saben de lo que hablan. Han pasado de conocerse a sí mismos a intentar conocer a su enemigo (siguiendo la filosofía de Sun Tzu). Y ahora, fruto de ese esfuerzo y de la madurez de su estrategia para robustecer el software, van a la raíz del asunto: las metodologías del desarrollo software.

Esta r-(evolución) no es nueva: lleva ya algunos años en marcha y Vista creo que es el primer producto con este enfoque desde su nacimiento. Pero no contentos con eso, explican al resto cómo deben hacerse las cosas.
Para quien no tenga claro de que va esto, recomiendo ver este video What is Microsoft Application Threat Modeling?
Los resultados de este proceso son un conjunto de requisitos de seguridad necesarios para lograr que la aplicación sea robusta. En este video se pueden consultar los resultados de usar esta herramienta.

Como habréis podido observar quienes hayáis visto los videos, ¡Esto sí es SEGURIDAD en el DISEÑO de la solución SOFTWARE!.

Para quien tenga más hambre de conocimientos, puede saciar su sed en Microsoft Application Threat Modeling. También es destacable que todo este material es de acceso libre y que no cabe duda que es una gran contribución al mundo de la Ingeniería del Software.
La herramienta puede ser descargada en Microsoft Threat Analysis & Modeling v2.1.2
lunes, 17 de noviembre de 2008 0 comentarios

Truecall, el firewall de la telefonía fija

Leo vía Tuexperto.com que se ha dado a conocer un nuevo producto que puede ser la solución frente al spam telefónico.
Si estás harto, cada vez que estas en casa disfrutando de tranquilidad, de que suene el teléfono y no sea un conocido para hablar contigo, es el momento de plantearse adquirir este producto. Tal como explica Tuexperto.com, "Lo han inventado Steve Smith y John Price, dos expertos del telemárketing que, como es obvio, han dejado de trabajar para el sector. Bueno, en realidad siguen vinculados. Aunque más bien con el fin de hundir el negocio. Truecall es un potente filtro de llamadas no deseadas, que logra que ni tan siquiera suene nuestro teléfono. El aparato se basa en una lista negra en la que figuran una relación de números enemigos. Y, para empezar, filtra todas esas llamadas que ocultan el número desde el que llaman."

Mientras la legislación no cambie al respecto, este aparato puede ser una buena solución de frenar comportamientos de marketing tan agresivos. Uno, conocedor de la legislación en materia de protección de datos, solicitó en su momento no aparecer en el listín telefónico, pero las últimas modas ya se han aprendido el cuento y te informan que tu numero ha sido elegido al azar.
La lógica de Truecall es sencilla. "Detecta que la llamada entrante viene de uno de nuestros amigos, familiares o clientes y el teléfono suena para que podamos hablar con toda normalidad. Pero si quien intenta hablar con nosotros, es un número de la lista negra, la llamada es bloqueada y el teléfono no llega ni a sonar."
viernes, 14 de noviembre de 2008 0 comentarios

Little Bighorn y las ingenierías informáticas

Quería hacer un post especial en relación al 19 de noviembre, pero como adelanto, sirva esta excelente reflexión publicada por Fernando Llopis Pascual en "Little Bighorn y las ingenierías informáticas"


Para aquellos que aún no estén enterados dejo aquí una batería de enlaces necesarios para entender todo este embrollo desde diferentes puntos de vista y por supuesto para cualquier duda pasaros por la web iniciadora www.huelgainformatica.es.



En resumen, creo que al menos si eres un ingeniero/ingeniero técnico en Informática o estás relacionado con el tema merece la pena que inviertas un poco de tu tiempo en informarte y que así puedas tomar una decisión clara respecto a si ves o no necesario movilizarte y por qué.
viernes, 7 de noviembre de 2008 0 comentarios

La seguridad de la informacion en el sector sanitario: ISO 27799:2008

Ya he comentado alguna vez que la serie 27000 va a servir como marco normativo para todo lo relacionado con la seguridad de la información.

Pues bien, hemos de recibir una nueva norma de este marco, "ISO 27799:2008 Health informatics -- Information security management in health using ISO/IEC 27002". He dado con ella gracias a ISO 27002.es
Tal como aparece en la Web de ISO, su resumen es:

ISO 27799:2008 defines guidelines to support the interpretation and implementation in health informatics of ISO/IEC 27002 and is a companion to that standard.

ISO 27799:2008 specifies a set of detailed controls for managing health information security and provides health information security best practice guidelines. By implementing this International Standard, healthcare organizations and other custodians of health information will be able to ensure a minimum requisite level of security that is appropriate to their organization's circumstances and that will maintain the confidentiality, integrity and availability of personal health information.

ISO 27799:2008 applies to health information in all its aspects; whatever form the information takes (words and numbers, sound recordings, drawings, video and medical images), whatever means are used to store it (printing or writing on paper or electronic storage) and whatever means are used to transmit it (by hand, via fax, over computer networks or by post), as the information must always be appropriately protected.



Su estructura es:

  • Alcance

  • Referencias (Normativas)

  • Terminología

  • Simbología

  • Seguridad de la información sanitaria

  • Objetivos; Seguridad en el gobierno de la información; Infomación sanitara a proteger; Amenazas y vulnerabilidades

  • Plan de acción práctico para implantar ISO 17799/27002

  • Taxonomía; Acuerdo de la dirección; establecimiento, operación, mantenimiento y mejora de un SGSI; Planning; Doing; Checking, Auditing

  • Implicaciones sanitarias de ISO 17799/27002

  • Política de seguridad de la información; Organización; gestión de activos; RRHH; Fisicos; Comunicaciones; Accesos; Adquisición; Gestión de Incidentes; Continuidad de negocio; Cumplimiento legal

  • Annex A: Amenazas

  • Annex B: Tareas y documentación de un SGSI

  • Annex C: Beneficios potenciales y atributos de herramientas

  • Annex D: Estándares relacionados


La norma tiene stage 60.60 (Publicada) con fecha de 12 de Junio de 2008. Podéis adquirirla en ISO 27799:2008 - Health informatics -- Information security management in health using ISO/IEC 27002

Estos movimientos serán también continuos en años próximos dado que es intención de ISO extender la norma ISO 27002 con contenidos específicos en aquellos sectores que plantean una problemática especial.
martes, 4 de noviembre de 2008 2 comentarios

Protección de datos: concienciando que es gerundio

La Agencia Vasca de Protección de Datos llegó a un acuerdo con la Oficina del Comisionado de la Información del Reino Unido (Information Commissioner´s Office, ICO) para adaptar y editar un video formativo bajo su licencia.


El video es una breve introducción dramatizada a los principios de la protección de datos. Su uso está pensado como parte de un programa de sensibilización y formación para los trabajadores que ayude a las organizaciones en el cumplimiento de los requerimientos legales y en la adopción de buenas prácticas.

Este son el tipo de actuaciones formativas que generan una mayor concienciación: la exageración de situaciones cotidianas para hacer reflexionar sobre la problemática que se plantea en materia de protección de datos. No tiene desperdicio y debería usarse en cualquier curso básico sobre normativa en materia de protección de datos.

Podéis descargar el video en "Las luces funcionan... Cumpliendo con la protección de datos personales"
miércoles, 29 de octubre de 2008 2 comentarios

Cursos de seguridad del IE bajo licencia Creative Commons

Ultimamente la carga laboral no me permite extenderme demasiado pero vía Sergio Hernando he dado con un par de cursos de muchísima calidad, ofrecidos por el Instituto Empresa bajo licencia Creative Commons.

El anuncio lo realiza en su blog Enrique Dans y los contenidos que he podido mirar por encima están ambos relacionados con la seguridad. Me han encantado por la precisión técnica pero a la vez la claridad para transmitir puro conocimiento.
  • Security Experts: El material nos muestra las principales amenazas a un sistema y las posibles medidas de protección, dándonos además una visión práctica del día a día de un administrador de sistemas y sobre los posibles costes de la inseguridad informática.

  • Firma Electrónica: El objetivo del material es conocer en profundidad la aplicación práctica de la firma electrónica en el marco actual de la empresa española. Mediante el análisis previo de su funcionamiento operativo y de su marco legal, el curso sienta las bases para su comprensión por parte del alumno, y para evaluar el impacto esperado en la organización de sus diversas modalidades: su aplicación en las relaciones con empleados, clientes y proveedores, así como sus implicaciones en el desarrollo de la administración electrónica (e-administración).

Enhorabuena a los autores de ambos cursos por la calidad de los mismos. También es de agradecer a Enrique Dans y el equipo del Instituto Empresa el esfuerzo por proponer un proyecto arriesgado e innovador y comparto con él y con Sergio Hernando las reflexiones que hacen en relación a compartir conocimiento. Que la fuerza de compartir enlaces, información y conocimiento tenga también un hueco en este blog si podemos contribuir en algo a aumentar las visitas a estos excelentes cursos.
miércoles, 22 de octubre de 2008 0 comentarios

Modelos de "políticas" de seguridad

Vía ISO27002.es he podido dar con la Web
Open Directory - Computers: Security: Policy: Sample Policies que contiene un buen catálogo de documentos sobre políticas de seguridad.

En Guía para la elaboración del marco normativo de Seguridad ISO 27002 ya comenté las diferencias entre Política, Norma y Procedimiento aunque en ingles el término "policy" suele tener un carácter más general. Es habitual encontrar "policies" para todo, aunque muchas veces estos documentos tienen el objetivo de establecer regulaciones y por tanto deberían entenderse como normas.

Aumenta esta confusión además que en la norma ISO 27002 aparezca como control en el punto 5.1.1. la famosa "política de seguridad de la información".
En cualquier caso, el catálogo de documentación contiene una buena recopilación de diferentes enfoques a la hora de establecer un marco normativo, lo que suele venir bien cuando se anda intentando escribir estas cosas.

Como reflexión final, todo documento que intenta ser una política, norma o procedimiento tiene que tener un objetivo base "Que pueda ser algo cumplible".No se trata por tanto de hacer algo que quede bien o que sea completo, sino algo que sea real, asumible y cumplido por el área regulada.
martes, 21 de octubre de 2008 2 comentarios

Sexto cumpleaños del blog

Con una semana de retraso, quiero conmemorar ya el sexto aniversario de este blog que empezó como un medio personal de masticar las noticias y digerir los conocimientos en materia de seguridad que se han ido produciendo. Este lugar es un buen reflejo y fuente de evidencias del cambio de orientación que se ha producido en esta disciplina, cada vez más relevante en las organizaciones. Las tecnologías son un pilar fundamental que ejercen a día de hoy ya como el verdadero sistema circulatorio de toda organización y garantizar la seguridad de estas infraestructuras ya no es una opción sino una necesidad vital para poder sobrevivir en el futuro.



Aunque los comienzos fueron duros con un servicio Blogger recién parido sin el apoyo todavía de Google y siendo este fenómeno totalmente desconocido, la constancia y el creer que publicar tiene su sentido siempre son el aliento necesario para intentar sacar un hueco a la semana para comentar cosas. Como experiencia personal, animo a quien tenga un mensaje claro que transmitir a hacerlo. No dejo de sorprenderme cada día con las oportunidades y situaciones que genera tener un escaparate de reflexiones en torno a la seguridad de la información. Por eso también este año he decidido que sea un blog FREE-ADSENSE, la información que se publique que sea libre de banners relacionados y así evitaremos cosas tan curiosas como las que posteó Paloma Llaneza. No quiero ni imaginarme la publicidad que puede estar relacionada llamandome "Cao". Bastante sufrí ya de pequeño con el juego del "Cola-cao" que usaba la palabra "cao" como disparo.

Gracias a todos los lectores por seguir estando ahí a diario.
lunes, 20 de octubre de 2008 2 comentarios

La subcontratación del riesgo

Tenía pendiente desde hace unos días elaborar esta entrada. Tras unos comentarios en relación al post de Joseba Enjuto sobre la caracterización de los Servicios TI, quería hablar sobre la " subcontratación del riesgo". Lo primero que quiero justificar es el titulo. La gestión del riesgo sólo permite cuatro decisiones posibles:
  • Aceptarlo

  • Evitarlo

  • Reducirlo o

  • Transferirlo a un tercero
En general, se suele entender por transferencia del riesgo cuando éste se tiene identificado y se decide que un externo sea quien lo gestione a cambio de cierta contraprestación: habitualmente puede ser la externalización de servicios, la contratación de seguros, etc.

Es habitual, como bien apuntaban en los comentarios de "Seguridad y Gestión" que el término para definir este proceso sea la "externalización del riesgo" pero ahora voy a justificar un poco por qué prefiero no llamarlo así.

Yo concibo la idea de la externalización de un riesgo cuando una Organización identifica claramente qué necesita y establece una relación contractual de prestación de servicios que permite al cliente quedarse tranquilo respecto a cómo va a gestionar el tercero ese riesgo. Para ello, evidentemente, los servicios prestados por el tercero deberían poder acreditar ciertas garantías respecto a la seguridad con la que van a ser proporcionados. La existencia de unos adecuados "Acuerdos de nivel de servicio" ( o su término en ingles Service Level Agreement, SLA) centrados exclusivamente bajo la perspectiva de la seguridad podrían ser suficiente garantía. La Organización que traslada el riesgo sabe que en caso de problemas, podrá arremeter contractualmente contra la empresa a la que transfiere el riesgo siendo recompensada adecuadamente en caso de una gestión no adecuada de ese riesgo. Para ello, aparece el control 6.2.3 de la norma ISO 27002 que indica que "Los acuerdos que comporten el acceso de terceros a recursos de tratamiento de información de la Organización deben basarse en un contrato formal que tenga o se refiera a todos los requisitos de seguridad que cumplan las políticas y normas de seguridad de la Organización."
Si atendemos a la guía de implantación de la norma, que es la forma más completa de implantar el control, este tipo de ANS o SLA de seguridad deben cubrir cosas como:
  • 1.-La política sobre seguridad de la información del tercero.
  • 2.-Los controles para asegurar la protección de los activos que el tercero tiene implantado, incluyendo:
    • procedimientos para proteger los activos de la organización, incluida la información, el software y el hardware.
    • cualquier control o mecanismo de protección física requeridos.
    • controles para asegurar la protección contra el software malicioso
    • procedimientos para determinar si ha ocurrido algún incremento del riesgo de los activos, por ejemplo, pérdida o modificación de información, software o hardware;
    • controles para asegurar la recuperación o destrucción de la información y los activos, al terminar el contrato o en algún momento acordado dentro del periodo de vigencia del contrato;
    • la confidencialidad, integridad, disponibilidad, y cualquier otra propiedad importante de los activos
    • restricciones en la copia o revelación de la información; junto con la utilización de acuerdos de confidencialidad
  • 3.- Una clara estructura de los informes y de los formatos de informe acordados.
  • 4.- Un proceso especificado y claro de la gestión del cambio.
  • 5.- Disposiciones para informe, notificación e investigación de los incidentes de seguridad de la información e infracciones de seguridad, así como violaciones de los requisitos establecidos en el acuerdo.
  • 6.- Una descripción del producto o servicio que se va a proporcionar, y una descripción de la información que se hará accesible, con su clasificación de seguridad.
  • 7.- El nivel objetivo de servicio y los niveles de servicio inaceptables.
  • 8.- La definición de los criterios de verificación del comportamiento, su control e informe.
  • 9.- El derecho a controlar, y revocar, cualquier actividad relacionada con los activos de la organización.
  • 10.- El derecho de auditar las responsabilidades definidas en el acuerdo, teniéndose que llevar a cabo tales auditorías por una tercera parte, y de enumerar las obligaciones y derechos legales de los auditores.
  • 11.- El establecimiento de un procedimiento de escalado para la resolución de los problemas.
  • 12.- Requisitos de continuidad de servicio, incluyendo las medidas de disponibilidad y fiabilidad, de acuerdo con las prioridades de negocio de la organización.
  • 13.- Las responsabilidades respectivas de las partes del contrato.
  • 14.- Las responsabilidades con respecto a temas legales y como se garantiza que se cumplen los requisitos legales, por ejemplo legislación de protección de datos, teniendo en cuenta sobre todo los distintos sistemas legales nacionales si el contrato implica la cooperación con organizaciones de otros países.
  • 15.- Etc.
El primer problema con el que nos solemos encontrar en las Organizaciones es que se externalizan servicios pero no se definen, desde la perspectiva de la seguridad, en qué condiciones se transfiere el riesgo. Llegado a estas alturas del texto, cabe pensar si realmente conocéis a alguna empresa que "externalice su riesgo" o si en general todas "subcontratan servicios de riesgo" entendiendo por esto segundo, un término menos formalizado de dar a un tercero un riesgo. Quiero destacar que el riesgo SI se puede transferir, pero no así la responsabilidad. Por tanto, que las cosas no estén bien definidas, explícitamente documentadas y contractualmente reflejadas solo hace que perdamos "control" sobre nuestro riesgo que además, no vamos a gestionar nosotros mismos.

Dependerá de cómo entienda e interprete ese tercero el riesgo que asume al prestar el servicio el tipo de garantías que pudiera proporcionarnos en caso de un incidente de seguridad. Y lo que me parece más preocupante es que la "externalización de servicios TI" está muy de moda y si bien tenemos normas como ISO 20000 o ITIL que definen bien cómo debe hacerse este proceso y cómo deben establecerse los SLA y ANS, es importante que los aspectos relacionados con la seguridad queden perfectamente definidos. Es cierto que para los servicios TI el factor más importante a considerar suele ser la disponibilidad, pero debemos contemplar qué ocurriría si la naturaleza del incidente o error afecta a la integridad o confidencialidad de nuestra información.

Toda externalización supone pérdida de control si no se establecen mecanismos de regulación y seguimiento que permitan aportar evidencias, por parte del externo, de estar haciendo las cosas bien. A esta problemática general, todavía cabría añadir la complejidad que surge cuando se manejan cadenas de subcontratación. Si la empresa A transfiere un servicio a la empresa B, que a su vez utiliza a las subcontratas C y D para proporcionar el servicio final al cliente A. Si estos eslabones de subcontratación no están claramente identificados y bien atados, la empresa A puede ver comprometida su seguridad y no tener muy claro cuál ha podido ser la cadena de fallos y por tanto, la cadena de responsabilidades.

Y decía al principio que los acontecimientos siempre nos ponen de manifiesto estas reflexiones por el incidente este fin de semana en los hospitales madrileños. El titular de "El País" que se hace eco de la noticia es Siete hospitales se quedan seis horas sin sistema informático.

Cuando hacemos el análisis de riesgos y estamos en la fase de valoración de activos, siempre usamos una escala denominada "laboral" donde precisamente se tiene en consideración si un incidente de seguridad puede costar "vidas humanas". Normalmente nuestros entrevistados suelen hacer alguna broma al respecto, pero es cierto que en ciertos "modelos de negocio", los servicios TI son críticos pudiendo causar la muerte de personas. Además, el proceso de digitalización que tantos beneficios genera y que tan bien venden nuestros políticos en relación a la atención sanitaria, tiene requisitos de seguridad que requieren hacer las cosas bien desde el principio. Sin entrar a valorar en concreto estos hechos, dado que no tenemos información suficiente que pudiera servir para valorar técnicamente que ha fallado, las evidencias son un cese de servicios de seis horas, algo posiblemente "intolerable" para un sector sanitario donde mucha información se requiere "en tiempo real". Merece la pena destacar frases como "La caída del programa la provocó una bajada de tensión eléctrica en la zona de Tres Cantos, donde está el centro tecnológico que aloja el servidor central de los nuevos hospitales".

¿Un sólo servidor para un activo de información tan crítico? ¿Ningún plan de contingencia para recuperarse frente a una situación así en menos de una hora?

El blog APISCAM parece proporcionar más información sobre lo sucedido, aunque quizás con una versión menos imparcial (seguramente muy justificada). Parece que toda la gestión informática hospitalaria está subcontratada y en los diferentes pliegos y concursos se habían contemplado requisitos respecto a la continuidad de servicio.

De los hechos se deduce, al menos, un fallo grave en el plan de continuidad de negocio o planes parciales de contingencia. En sistemas de información como los del entorno hospitalario, con cada vez más dependencia de la tecnología para obtener información relativa al diagnóstico, hablamos de sistemas críticos que requieren información en tiempo real ("Fue el servicio de urgencias el que más sufrió las consecuencias de las demoras. "Tenemos que ir corriendo de un lado para otro para llevar historias, análisis...", explicaba ayer una enfermera de este departamento del hospital de Vallecas").

Quizás en el pliego las condiciones del servicio pudieran estar bien contempladas, pero para nada se ha garantizado la correcta supervisión de la ejecución del mismo y el adecuado cumplimiento del ACUERDO DE NIVEL DE SERVICIO. Además se suma que el supuesto Plan de Contingencias o de Continuidad de Negocio no ha funcionado, dado que la parada de seis horas es excesivo tiempo en el entorno hospitalario si se hubiera hecho el correspondiente BIA (Bussines Impact Analysis).

Y por último y como reflexión final, quisiera destacar que el nuevo Reglamento de desarrollo de la Ley 15/1999 de Protección de Datos, ha incluido importantes y significativas reformas en torno a la figura del "encargado de tratamiento", que desde la perspectiva de la seguridad van en la línea de mejorar el control y la externalización del riesgo sobre los terceros.
Artículo 20. Relaciones entre el responsable y el encargado del tratamiento.
1. El acceso a los datos por parte de un encargado del tratamiento que resulte necesario para la prestación de un servicio al responsable no se considerará comunicación de datos, siempre y cuando se cumpla lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente capítulo. El servicio prestado por el encargado del tratamiento podrá tener o no carácter remunerado y ser temporal o indefinido. No obstante, se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado.

2. Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento.

3. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato al que se refiere el apartado 2 del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, será considerado, también, responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente.
No obstante, el encargado del tratamiento no incurrirá en responsabilidad cuando, previa indicación expresa del responsable, comunique los datos a un tercero designado por aquél, al que hubiera encomendado la prestación de un servicio conforme a lo previsto en el presente capítulo.

Artículo 21. Posibilidad de subcontratación de los servicios.
1. El encargado del tratamiento no podrá subcontratar con un tercero la realización de ningún tratamiento que le hubiera encomendado el responsable del tratamiento, salvo que hubiera obtenido de éste autorización para ello. En este caso, la contratación se efectuará siempre en nombre y por cuenta del responsable del tratamiento.

2. No obstante lo dispuesto en el apartado anterior, será posible la subcontratación sin necesidad de autorización siempre y cuando se cumplan los siguientes requisitos:
  1. Que se especifiquen en el contrato los servicios que puedan ser objeto de subcontratación y, si ello fuera posible, la empresa con la que se vaya a subcontratar.  Cuando no se identificase en el contrato la empresa con la que se vaya a subcontratar, será preciso que el encargado del tratamiento comunique al responsable los datos que la identifiquen antes de proceder a la subcontratación.
  2. Que el tratamiento de datos de carácter personal por parte del subcontratista se ajuste a las instrucciones del responsable del fichero.
  3.  Que el encargado del tratamiento y la empresa subcontratista formalicen el contrato, en los términos previstos en el artículo anterior.
En este caso, el subcontratista será considerado encargado del tratamiento, siéndole de aplicación lo previsto en el artículo 20.3 de este reglamento.

3. Si durante la prestación del servicio resultase necesario subcontratar una parte del mismo y dicha circunstancia no hubiera sido prevista en el contrato, deberán someterse al responsable del tratamiento los extremos señalados en el apartado anterior.

En los aspectos de seguridad del R. D. se tiene:
Artículo 82. Encargado del tratamiento.

1. Cuando el responsable del fichero o tratamiento facilite el acceso a los datos, a los soportes que los contengan o a los recursos del sistema de información que los trate, a un encargado de tratamiento que preste sus servicios en los locales del primero deberá hacerse constar esta circunstancia en el documento de seguridad de dicho responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento. Cuando dicho acceso sea remoto habiéndose prohibido al encargado incorporar tales datos a sistemas o soportes distintos de los del responsable, este último deberá hacer constar esta circunstancia en el documento de seguridad del responsable, comprometiéndose el personal del encargado al cumplimiento de las medidas de seguridad previstas en el citado documento.

2. Si el servicio fuera prestado por el encargado del tratamiento en sus propios locales, ajenos a los del responsable del fichero, deberá elaborar un documento de seguridad en los términos exigidos por el artículo 88 de este reglamento o completar el que ya hubiera elaborado, en su caso, identificando el fichero o tratamiento y el responsable del mismo e incorporando las medidas de seguridad a implantar en relación con dicho tratamiento.

3. En todo caso, el acceso a los datos por el encargado del tratamiento estará sometido a las medidas de seguridad contempladas en este reglamento.

Es de destacar lo apostillado en el artículo 22, donde obliga de alguna manera al responsable de los datos a ejercer como tal y controlar el cumplimiento de sus prestadores en la frase "Cuando el responsable del tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este Reglamento." sobre todo, en lo referente a la seguridad de la información. Así que de nuevo, el cumplimiento de la protección de datos puede ser una buena escuela para hacer las cosas como Dios manda. Está muy bien eso de ceder el marrón a un tercero, pero esa delegación no exime de responsabilidad. Si eres el que cede o transfiere el riesgo, la adecuada gestión es verificar que ese tercero estará a la altura de las circunstancias y que los servicios que presta, reunen las garantías mínimas necesarias para salvaguardar tus intereses. 


Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.





viernes, 10 de octubre de 2008 5 comentarios

Encriptar no existe en el Diccionario

Esto que hoy quiero comentar lo he leído ya en algún blog pero no recuerdo donde y por tanto no puedo referenciar la fuente. De todas formas, el titular corresponde a una captura realizada hoy.
Encriptación cuántica: Comunicaciones seguras a prueba de intrusos.

Como cada vez que lo leo me duelen los ojos, he querido destinarle un post-log. Señores periodístas, ¡ENCRIPTAR NO EXISTE EN EL DICCIONARIO RAE!

Cifrar:
1. tr. Transcribir en guarismos, letras o símbolos, de acuerdo con una clave, un mensaje cuyo contenido se quiere ocultar.
2. tr. Valorar cuantitativamente, en especial pérdidas y ganancias.
3. tr. Compendiar, reducir muchas cosas a una, o un discurso a pocas palabras.
4. tr. Reducir exclusivamente a una cosa, una persona o una idea determinadas lo que ordinariamente procede de varias causas.


Según la Wikipedia que para estas cosas está más al día del uso de los términos.:

La criptografía (del griego κρύπτω krypto, «oculto», y γράφω graphos, «escribir», literalmente «escritura oculta») es el arte o ciencia de cifrar y descifrar información utilizando técnicas que hagan posible el intercambio de mensajes de manera segura que sólo puedan ser leídos por las personas a quienes van dirigidos.
En la Jerga de la criptografía, la información original que debe protegerse se denomina texto en claro. El cifrado es el proceso de convertir el texto plano en un galimatías ilegible, denominado texto cifrado o criptograma. Por lo general, la aplicación concreta del algoritmo de cifrado (también llamado cifra) se basa en la existencia de una clave: información secreta que adapta el algoritmo de cifrado para cada uso distinto. Cifra es una antigua palabra arábiga para designar el número cero; en la antigüedad cuando Europa empezaba a cambiar del sistema de numeración romano al arábigo, se desconocía el cero por lo que este resultaba misterioso, de ahí probablemente que cifrado signifique misterioso.



Con frecuencia los procesos de cifrado y descifrado se encuentran en la literatura como encriptado y desencriptado, aunque ambos son neologismos -anglicismos de los términos ingleses encrypt y decrypt- todavía sin reconocimiento académico. Hay quien hace distinción entre cifrado/descifrado y encriptado/desencriptado según estén hablando de criptografía simétrica o asimétrica, pero la realidad es que la mayoría de los expertos hispanohablantes prefieren evitar ambos neologismos hasta el punto de que el uso de los mismos llega incluso a discernir a los aficionados y novatos en la materia de aquellos que han adquirido mas experiencia y profundidad en la misma.
jueves, 9 de octubre de 2008 4 comentarios

Cuando confidencial no significa nada

Aparece publicado en la Web de Cadena Ser, documentación donde los servicios secretos españoles acusan a Irán de proteger y armar a terroristas islámicos.

Si lo de la semana pasada era repugnante porque se vendía información, lo de esta tiene más guasa, puesto que son documentos de "Los Servicios Secretos" (Deben ser de la TIA, como Mortadelo y Filemón). Lo que deberían los periodistas hacer en estos casos sería matizar bien los titulares cambiando "Según nuevos informes confidenciales a los que ha tenido acceso la SER" por "Según nuevos informes que han dejado de ser confidenciales a los que ha tenido acceso la SER.



Por centrarme en el tema, siempre que tratas la implantación de controles de la norma ISO 27001 aparece el escollo en lo relacionado al bloque "7 Gestión de activos", y en concreto, el objetivo de control "7.2 Clasificación de información".

En este asunto hay que hilar muy fino y no por lo complejo de la implantación de las medidas sino por la extensión que debe tener su aplicación, afectando generalmente a toda la organización que se encuentre dentro del alcance del sistema de gestión de la seguridad de la información. En general, solemos recomendar la aplicación de tres escalones de protección:
  • Confidencial

  • Uso interno

  • Uso público


¿Puede haber más? Pues claro que sí, tantos como la organización necesite para poder garantizar los requisitos de protección adecuados a cada nivel. Pero lo que quiero destacar es que las etiquetas no son lo importante. Lo esencial es establecer diferentes formas de tratar cada uno de estos tipos de información, dado que atendiendo a su naturaleza, tienen requisitos diferentes. Por eso, cuando ves "información confidencial" en manos de extraños o publicada en una Web, te preguntas ¿Habrán desclasificado ya este documento? porque de confidencial, a partir de ese momento, solo le queda la etiqueta y debería ser ya desclasificada.

Por tanto, cualquiera que quiera hacer bien las cosas en relación al manejo de información clasificada, debe pensar en procesos de tratamiento y lo adecuado, sería definir los requisitos que hay que espeficar para:
- Etiquetado
- Acceso o autorización
- Desclasificación
- Transmisión o transporte
- Destrucción
- Requisitos adicionales si se trata de datos de carácter personal.

Si un empleado, vinculado a los niveles de clasificación, no tiene claro para cada "tipo de información" que es lo que tiene que hacer, simplemente lo que se ha hecho es "clasificar información y etiquetarla" pero no mejorar su seguridad.
 
;