Cuando una organización sufre determinados incidentes de seguridad (por ejemplo, una intrusión), se plantea la realización de un análisis forense, en el que se tratan de obtener y presentar evidencias electrónicas del problema acaecido; adicionalmente, en ocasiones —no siempre, aunque si se ha producido un delito debería ser así—, es necesario efectuar una denuncia, y es entonces cuando surge la necesidad de realizar un peritaje informático por parte de un perito cualificado.

Un peritaje informático tiene como objeto dar respuesta técnica a una serie de cuestiones planteadas bien por una de las partes bien por el propio juez; dicha respuesta, por muy complejos que sean el desarrollo o las bases de la misma, debe ser concisa y sencilla (pensemos que la tienen que interpretar personas que no tienen por qué estar familiarizadas técnicamente con el objeto del informe). Así, siempre es conveniente incluir un apartado de “conclusiones” dentro de nuestro informe, en el que en base a todo lo desarrollado en el cuerpo del mismo, se muestren de forma resumida las respuestas a las cuestiones planteadas.

No es un secreto que Estados Unidos está expuesto a ataques cibernéticos de cualquier procedencia, y cada vez más. Un informe que se encuentra actualmente en preparación y que fue solicitado por la Casa Blanca y que pueda confirmar la falta de “ciberseguridad” de las infraestructuras de los Estados Unidos llegará cómo agua de mayo; además de los fallos informáticos detectados en sectores clave, existe la percepción de que la situación general en todos los sectores de actividad es de vulnerabilidad. Pasen y vean.

En diez años, se han censado en los EEUU ciento veinticinco incidentes de seguridad en sistemas SCADA, sistemas que son utilizados en centrales nucleares, plantas de tratamiento de agua, plataformas petrolíferas y todo tipo de infraestructuras críticas. Los incidentes detectados van desde problemas locales y/o autónomos, hasta otros que agravan o se nutren de ataques desencadenados en otro lugar por empleados o consultores externos. Según el Summary Report #757 del Senado americano, hecho público el 20 de Marzo pasado, las consecuencias de este tipo de fallos pueden ser tanto materiales, medioambientales como humanas, según el testimonio de Mr. Keith Lourdeau, FBI Deputy Assistant Director, Cyber Division.

Desde hace un tiempo, es de notoria actualidad la problemática que supone la pérdida y robo de equipos portátiles, con los consiguientes problemas al respecto de la información corporativa albergada en ellos; hasta una organización como el FBI llega a perder más de un centenar y medio, y aun peor, el Departamento de Energia de EEUU cifra en aproximadamente 1,400 los portátiles perdidos durante 6 años. En base a esto, hoy vengo a comentarles una técnica de protección presente en muchos portátiles, pero desconocida, y destinada a proteger la información de sus discos duros.

Todos los discos duros (según el estándar ATA de la Wikipedia) disponen de un mecanismo de protección mediante contraseña, que bloquea el acceso al disco si éste no recibe la contraseña adecuada al arrancar. Dicha opción está disponible en la BIOS del ordenador, normalmente identificada como HDD Password.

Actualización 22/04/09 12:10h: Ya tienen la solución al pasatiempo al final de la entrada…

(N.d.E.: Aprovechando el día extra que tiene este fin de semana, les dejamos con un pequeño pasatiempo. Son diez palabras sobre un mismo tema. Les adelanto que es difícil y que necesitarán la Wikipedia si no son ustedes Bruce Schneier. Nos vemos el lunes. Cuidado ahí fuera. Ah… esta semana no hay encuesta.)

No sé si han leído ustedes la genial y totalmente recomendable serie de novelas de ciencia-ficción Fundación, de Asimov, pero si no es así, ésta tiene como parte fundamental de su argumento a la Psico-historia (no confundir con el término Psicohistoria en tanto que estudio de las motivaciones psicológicas de eventos históricos). Tirando de Wikipedia, según la descripción que hace Asimov a través de Hari Seldon, el personaje creador de dicha “ciencia”:

En numerosas entradas de este blog se han expuesto ejemplos y casos prácticos muy buenos que nos han ayudado a entender las normas que marcan tanto LOPD como el RDLOPD. Sin embargo, muchas veces cuando estudiamos una ley pasamos por alto algo que para muchos es trivial pero que estoy seguro que para muchos otros no lo es: la propia definición de la ley. Es decir, todos sabemos que la LOPD es La ley Orgánica 15/1999 del 13 Diciembre de Protección de Datos de Carácter Personal. Y también sabemos que el RDLOPD es el Reglamento de Desarrollo de la LOPD aprobado por el Real Decreto 1720/2007 del 21 Diciembre. Pero, ¿tenemos claro que significa “Ley Orgánica”? ¿Y “Real Decreto”?

Pues eso es básicamente lo que viene a comentar este post, de manera resumida. Pongámonos la toga por un momento y veamos que significan:

Desde que empecé en esto del desarrollo Web he tenido siempre la “manía” de probar las aplicaciones que desarrollo en todos los navegadores posibles que existen, procurando siempre seguir los estándares Web en el código, así como hacer que su resultado sea lo mas accesible posible. Hasta el momento el navegador con el que me he sentido mas cómodo ha sido con el Firefox, que se caracteriza por ser el que cumple los estándares Web más “a rajatabla”; por eso suele el primer navegador en el que pruebo mi código. Otras de sus ventajas son el amplio abanico de extensiones y plug-ins que te asisten en el desarrollo y su disponibilidad en diferentes plataformas; como aspecto negativo, consume demasiada memoria y se descubren bastantes vulnerabilidades, aunque a diferencia de otros, éstas son rápidamente corregidas en cuestión de horas. Después de verificar el funcionamiento de la aplicación en Firefox, realizo las pruebas en el resto de navegadores: Opera, Safari, Konqueror, y el Explorer (principalmente por la cuota de mercado que tiene, y porque como sigue sus propios estándares, lo que funciona en los demás navegadores seguramente se vea mal en éste).

Pero entonces llegó Google Chrome, y cómo no, me decidí a probarlo.

La semana pasada cogí el autobús de línea para ir a visitar un cliente, vehículos que vienen equipados con diversos sistemas informáticos que generan o cancelan los billetes electrónicos. En concreto, este autobús tenía una canceladora automática de bonos de transporte y una impresora de los billetes individuales, pero sin embargo ninguno de los dos sistemas funcionaba, y estaban completamente “muertos”.

La empresa de transporte dispone de un plan para estas ocasiones, con el cual se asegura que las “cosas” sigan funcionando. En este caso, el conductor dispone de una troqueladora manual de bonos, y de un taco de billetes preimpresos, preparados para una situación como la que nos ocupaba. Esto implica que una caída total de los elementos informáticos no impide que se puedan cobrar los viajes del autobús.

(La entrada de hoy es la segunda colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

Hace algo más de un lustro me enfrente a una situación un tanto extraña en el área de Sistemas de la organización para la que trabajaba, y que les describo a continuación (NOTA: parte de la situación descrita es ficción, para dar dramatismo y mayor realidad a la historia; no crean todo lo que leen).