Imaginemos el siguiente escenario:

Tenemos un establecimiento público, un bar, por ejemplo. En ese bar disponemos de una cámara que no está grabando, la utilizamos, pongamos una vez al trimestre para ver qué ocurre o por si salta la alarma y nos avisan poder ver qué esta pasando en nuestro local. ¿Nos aplica la LOPD?.

Pues si nos vamos a la LOPD o al RD 1720 / 2007 en su artículo 2 podemos encontrar la siguiente descripción dentro del ámbito de aplicación:

Art 2. Ámbito Objetivo de Aplicación

El presente reglamento será de aplicación a los datos de carácter personal registrados en soporte físico que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores público y privado.

Nuestra cámara no está registrando nada en un soporte físico por lo que la cosa está clara, no nos aplica la ley, si no está dentro del ámbito de aplicación y además no hay fichero no nos aplica.

Pero si seguimos leyendo (aun con la idea en mente de que no registramos nada y no tenemos fichero), encontramos la definición de Datos de Carácter Personal que todos conocemos ya sobradamente:

Cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables

Y… la de Tratamiento de Datos:

Cualquier operación o procedimiento técnico, sea o no automatizado, que permita la recogida, grabación, conservación, elaboración, modificación, consulta, utilización, modificación, cancelación, bloqueo o supresión, así como las cesiones de datos que resulten de comunicaciones, consultas, interconexiones y transferencias.

La cosa ya no es lo que parecía porque se está haciendo un tratamiento de datos personales pero… es que el ámbito de aplicación es el que es. Pues aquí entra en juego la instrucción 1/2006 de 8 de noviembre, de la Agencia Española de Protección de Datos, sobre el tratamiento de datos personales con fines de vigilancia a través de sistemas de cámaras o videocámaras.

Esta instrucción clarifica qué se debe hacer en el caso del bar de nuestro amigo:

• Información.

1. Colocar, en las zonas videovigiladas, al menos un distintivo informativo ubicado en lugar suficientemente visible, tanto en espacios abiertos como cerrados y
2. Tener a disposición de los/las interesados/as impresos en los que se detalle la información prevista en el artículo 5.1 de la Ley Orgánica 15/1999.

El distintivo informativo deberá de incluir una referencia a la LEY ORGÁNICA 15/1999, DE PROTECCIÓN DE DATOS, incluirá una mención a la finalidad para la que se tratan los datos (ZONA VIDEOVIGILADA), y una mención expresa a la identificación del responsable ante quien puedan ejercitarse los derechos a los que se refieren los artículos 15 y siguientes de la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal. El contenido y el diseño del distintivo informativo se ajustará a lo previsto en el Anexo de esta Instrucción.

• Seguridad y Secreto.

El responsable deberá adoptar las medidas de índole técnica y organizativa necesarias que garanticen la seguridad de los datos y eviten su alteración, pérdida, tratamiento o acceso no autorizado.

Asimismo cualquier persona que por razón del ejercicio de sus funciones tenga acceso a los datos deberá de observar la debida reserva, confidencialidad y sigilo en relación con las mismas.

El responsable deberá informar a las personas con acceso a los datos del deber de secreto a que se refiere el apartado anterior.

Dilema resuelto.

Un saludo.

En este casi año y medio de andadura en la blogosfera he conseguido publicar 100 post y quería dedicaos este a vosotros, a todos los que me leeis o me habéis leido en alguna ocasión y por qué no, también a los que algún día espero que me lean.

Hasta ahora he tratado de mantener un ritmo de publicación lo más frecuente posible aunque se que en ocasiones las actualizaciones no han sido todo lo asiduas que deberían. Los quehaceres diarios y las circunstancias a veces pueden con el tiempo para esta, una de mis aficiones.

Me gustaría agradeceos enormemente a aquellos que me habéis consultado o que me habéis dado ánimos para continuar en alguna ocasión porque sinceramente se me han hecho necesarios y cada persona que se suma al feed o que te deja un comentario (sea crítica constructiva, agradecimiento, o sólo crítica), es para mí una muestra de que este tiempo es valisoso para vosotros.

A todos, Muchas Gracias y espero poder dedicar a mucha más gente el post número 200.

El 20 de Agosto de 2008 el vuelo 5022 de la compañía Spanair que realizaba el trayecto Madrid – Gran Canaria sufría un terrible accidente en el que fallecieron 154 personas. El caso sigue sin sentencia y la instrucción judicial suma ya más de 11.000 folios.

Una de las últimas novedades que ha salido a la luz es la posible existencia de troyanos en la máquina encargada de reportar las incidencias. La noticia se ha extendido por Internet a la velocidad del rayo y cada cual ha hecho ya sus valoraciones. La alternativa que se baraja es que el ordenador encargado de dar las alarmas no operó correctamente debido a una carga elevada de malware que impidió el registro de la incidencia y la posterior alarma. Al parecer el sistema lanzaba una alarma cuando se acumulaban 3 incidencias del mismo tipo y ésta era la que hacía 3, pero no se pudo registrar, la alarma no se disparó y el avión despegó con las consecuencias ya conocidas. De cualquier forma, al parecer, el registro de la incidencia no se hubiera llevado a cabo a tiempo.

La fuente principal de esta noticia se encuentra en el pais. Cualquiera que lea esta noticia se da cuenta de que la información no es todo lo correcta que debería ser y hay que hacer algunas suposiciones. De esta noticia se ha hecho eco hasta el gurú de la seguridad informática Bruce Schneier con una edición posterior al primer post pidiendo cautela a la hora de valorar esta información.

La información de la investigación apunta como primer causa del accidenta al fallo humano en la verificación de uno de los puntos de la lista que deben ser examinados de forma previa al despegue. Este error habría sido provocado por la prisa tras el retraso del avion que llevó al piloto a una respuesta automática sin verificación de la posición de una pieza básica para el despegue.

Bien, pues en toda esta historia a mi me gustaría poner énfasis en otro aspecto diferente. La conferencia de prensa del dia después de los máximos dirigentes de spanair (Hacia el minuto 5:00) arrojaba datos sobre las auditorías por terceras partes  de diferentes aspectos relacionados con la seguridad aérea afirmando que Spanair había obtenido la certificación IOSA y que ésta había sido renovada en su segundo año lo que implicaba una revisión extensa de todos los procesos y sistemas.  El checklist de la norma IOSA de IATA está redactado estilo ISO 27002 como una guía pero que además incorpora tras cada control una evaluación al respecto del mismo. El cheklist es bastante extenso, supera las 300 páginas y para poder dar una opinión fundamentada habría que pasar largas horas delante del ordenador si no se controlan los conceptos (como es mi caso, aun asi, vease ORG.3.3.11, ORG 3.3.12,  MNT 1.8.1). La cuestión es, ¿Se comprobó durante esa auditoría si los sistemas que soportaban los procesos de negocio estaban en las condiciones adecuadas?, y si era así, ¿De qué sirve un proceso de negocio que debe darme una alarma si algo va mal si no llega a tiempo?. ¿De que sirvió el sello IOSA?, y generalizando, ¿realmente acredita un sello aquello por lo que clama más allá de una buena gestión?.

Como todo accidente, es producto de un cúmulo de circunstancias adversas y en este confluyeron, al parecer, varias. ¿Cuanto influyó cada una?, ¿Podría el malware tener parte de culpa del accidente? (en caso de que la gestión de incidencias hubiera llegado a tiempo). Cada cual que saque sus conclusiones al respecto y si lo desea contribuya con un comentario ofreciendo su opinión. Yo ya tengo la mía.

Un saludo.

Cuando surge la necesidad de realizar la auditoría de este tipo, son varios los factores que se han de tener en cuenta de cara a la selección del producto más adecuado. Estos factores, entre otros, pueden ser:

• Parque de PCs: Número de PCs objeto de la auditoría
• Privilegios sobre los PCs a Auditar: Si el responsable de realizar la auditoría dispone de privilegios de Administración y en tal caso, si la instalación por defecto de cada PC dispone de un password de administración único por cada PC.
• Impacto en PC auditado: se ha de considerar si el impacto sobre el PC auditado debe ser mínimo.

Si trasladamos esto a nuestro caso, las respuestas a las cuestiones anteriores se traducen en:

• Parque de PCs: Desconocido. el auto no reflejaba el número de PCs a investigar. Recopilando información por internet traté de construirme una imagen mental de cómo sería y existía la posibilidad de verme desbordado por lo que recurrí a un compañero del Cuerpo Oficial de Peritos para que me acompañase lo que sin duda ha redundado en un trabajo de campo mucho más eficiente.
• Privilegios sobre los PCs a Auditar: Desconocido. La configuración de los PCs nos era desconocida también.
• Impacto en PC Auditado: Mínimo. Para el desarrollo de una pericia de este tipo se debe mantener el sistema impoluto, como no es posible, hay que ejecutar un programa que alterará los procesos, la memoria, creará un informe que se grabará en el disco duro, etc… hay que minimizarlo al máximo.

Ante esta definición de requisitos vamos a ver algunas de las posibilidades que nos ofrece el mercado para generar informes de las aplicaciones instaladas en los PCs de la organización.

• Network Inventory Expert: Esta aplicación nos va a permitir extraer el software de cualquier PC de la organización que disponga de una contraseña conocida por quien lo ejecuta. Precisa Instalación en el PC del administrador pero no en el resto de PCs de la organización. De pago.
• Total Network Inventory: Del corte del anterior, son programas diseñados para un seguimiento cómo del inventario ya que permiten extraer informes muy detallados de forma remota con la instalación del software en único PC. De pago.
• WinAudit: Inventario muy completo del PC, Incluido el Software, pero no los Product Keys. El problema que tiene es que hay que ejecutarlo PC por PC, pero por contra es Stand Alone. Freeware.
• Softkey Revealer: Esta herramienta no es como las demás, está diseñada expresamente para extraer los product key de una larga lista de productos comerciales por lo que es el complemento perfecto a Winaudit en caso de necesitar esta información. Freeware
• Everest: Herramienta de inventariado hardware y software muy profesional con posibilidad de instalación StandAlone. A pesar de ser comercial, su precio es bastante asequible.
• Microsoft Assessment and Planning Toolkit: Este software me ha sorprendido por su cantidad de opciones, con un proceso de instalación bastante largo precisa de un gestor de base de datos que se descarga durante la instalación donde almacena el inventario. Permite la recolección vía protocolos de red de windows y recolección por IPs, además es gratuito.
• Muchas más: GASP, Free PC Audit, y un larguísmo etcétera tanto de pago como freeware.

Finalmente nuestra opción fue Everest y como alternativa llevábamos la dupla Winaudit + softkey revealer que son herramientas no comerciales. Elegimos Everest ya que permite una instalación en modo stand-alone y además del software, incluida información sobre product keys, nos ofrecía información sobre el hardware de manera que teníamos una prueba más sobre los PCs examinados.

Pero esta búsqueda sin duda nos ha reportado algo más que el software que escogimos, nos ha dado una perspectiva de cómo se puede gestionar cómodamente el inventario de software en organizaciones con un parque de PCs elevado manteniendo una buena política de configuración de los PCs cuando éstos se ponen en uso (Incluyendo un usuario Administrador con contraseña robusta). Esto permite de forma sencilla la ejecución de una tarea de chequeo que nos dará desde el puesto de administración todos los informes de forma automática.

Un saludo.

El mes pasado, acompañado del secretario judicial, el procurador y un compañero de profesión nos dirigimos a la sede de una empresa con objeto de realizar una auditoría de software por una denuncia anterior de las empresas Autodesk, Microsoft, Adobe y Symantec. Aquí está mi experiencia.

Una vez nos encontramos en la empresa, el secretario judicial solicitó la presencia del gerente, quien rápidamente apareció por el hall y se prestó a todo lo que necesitábamos. Tras exposición de lo que había ocurrido al Gerente, nos dispusimos a realizar nuestro trabajo, que básicamente según rezaba el auto se reducía a una Auditoría de Software en la que se obtuvieran determinadas propiedades del software instalado, entre las que se encontraba, como no, el serial  o product key del producto.

Solicitamos inspección visual de las instalaciones con objeto de hacer un conteo de los PCs y, por ende poder dar una estimación de la duración de la intervención. Una vez estimado el volumen de PCs y el tiempo se lo transmitimos al secretario judicial que debe estar presente durante toda la intervención como fedatario del procedimiento seguido por el perito.

Comenzamos pues la actuación y fuimos realizando las siguientes acciones:

• Extracción de listado de programas instalados en cada PC y su fecha de creación
• Extracción de listado de programas instalados en cada PC y su fecha de último acceso
• Ejecución de una herramienta automática Stand Alone que extraía todos los datos solicitados por los demandantes (Me reservo para un post posterior la exposición de las alternativas posibles para este objetivo)
• Fotografiar las posibles licencias que encontráramos en forma de pegatinas adheridas a cada uno de los PCs
• Fotografiar la pestaña General y Nombre de Equipo de cada PC
• Construir un mapa con la ubicación física de cada uno de los PCs examinados

Antes de nada pusimos al corriente al gerente de la empresa, ya que el responsable de sistemas estaba de vacaciones, de cuáles iban a ser nuestras actuaciones y qué íbamos exactamente a extraer de cada uno de los PCs corporativos.

Nada más comenzar la situación se volvió algo tensa dado que a nadie le gusta que le toquen sus… sistemas. Salimos bien de la situación por algo coyuntural, el gerente era conocido de uno de los allí presentes y esa confianza nos ahorró tener que lidiar con los abogados del demandado, pero es más probable que sean requeridos por el demandado que que no lo sean.

Así todo, fuimos ordenador por ordenador ejecutando los comandos y desde un CD la herramienta y grabando en local los informes que finalmente ubicamos en una carpeta de red para poder grabarlos desde una máquina que disponía de grabador de CD. El uso del CD como soporte para este tipo de actuaciones se hace indispensable. Plantearse utilizar un dispositivo tipo pendrive tanto para la ejecución de la herramienta stand-alone para la extracción de informes como para almacenar las evidencias obtenidas es poco menos que un suicidio por las altas probabilidades de infección de alguno de los sistemas.

Con todo eso, desde un PC portátil de nuestra propiedad, grabamos las fotografías a un CD y copiamos su contenido a la misma carpeta en la que disponíamos de los informes. Acto seguido ordenamos todo por nombre del PC de forma que disponíamos de todas las evidencias clasificadas. Finalmente todo este contenido fue grabado por triplicado dejando una copia a la empresa demandada, otra al secretario judicial y otra que nos quedamos nosotros para la elaboración del correspondiente dictámen.

Nos despedimos y fin del trabajo de campo, que se cuenta rápido pero llevó unas 5 horas para 23 sistemas.

En resumen una nueva experiencia que requiere más de aplomo y saber estar que de cualidades técnicas y que tiene varios puntos críticos:

1. Selección de Software
2. Elaboración de la Metodología más apropiada
3. Cambios on the fly por restricciones de la infraestructura de sistemas de la empresa
4. Y sobre todo, saber estar en los momentos de presión, no ponerse nervioso y ser consciente de que simplemente haces tu trabajo.

Salu2 y felices vacaciones para los que las estéis disfrutando actualmente!

Accidente de la Plataforma de BP

El día 20 de Abril de este año, un desgraciado accidente que se llevó la vida de 11 trabajadores se pudo haber evitado. Esto que pensarás suena a tópico dejará de serlo si reconstruyes las circunstancias en las que el accidente se produjo.

Estando este fin de semana en casa, en uno de los pocos momentos que tengo para escuchar la televisión, escuché por casualidad la declaración de uno de los supervivientes al accidente. Mike Williams, ex empleado de la plataforma y técnico jefe de los sistemas electrónicos, declaró en una audiencia sita en Nueva Orleans que el sistema de detección encargado de monitorizar las acumulaciones de gas o la existencia de fuego no se activó. Preguntado por qué, Mike contestó que el sistema se encontraba apagado y que era una práctica habitual porque los responsables de la plataforma no querían despertar a nadie a las 3 de la mañana por una falsa alarma. A partir de aquí pueden haber dos líneas argumentales principales:

- El sistema de detección fue ineficaz porque estaba apagado pero… ¿Por qué estaba apagado?. Un sistema que emite muchas falsas alarmas resulta del todo inútil de forma que o se sustituye, o se perfecciona o se termina apagando. Si el sistema había demostrado no ser eficaz estando en funcionamiento, el responsable del sistema debía haber hecho notar esta circunstancia y haberlo corregido a tiempo dado que, por lo demostrado, se trataba de un sistema crítico.

- El sistema de detección funcionaba adecuadamente pero esporádicamente saltaba una falsa alarma que molestaba a alguien que no debía (o que si debía pero no le hacía mucha gracia levantarse a las 3 de la mañana).

Pues bien, el impacto, arriba descrito ha sido terrible, las consecuencias no sólo en términos de vidas humanas sino también de flora y fauna marinas, aves, plantas, contaminación atmosférica y un largo etcétera aún a día de hoy colean y el problema sigue sin cerrarse.

En infraestructuras y servicios críticos, la seguridad no es una opción, los impactos de la no seguridad no son admisibles bajo ningún punto de vista y es por eso que crece mi preocupación cuando veo empresas y servicios en los que aún no se les ha pasado por la cabeza pensar en la seguridad de sus activos, algunos de ellos teniendo como actividad principal la seguridad de los demás.

Enlazando todo esto con mi quehacer diario resulta algo curioso que cuando se finaliza la implantación de un SGSI, los controles que se han introducido para monitorizar determinados activos generan alarmas que a su vez se convierten en críticas, tan peligroso o más es no tener seguridad como pensar que se tiene y que ésta no funcione, sentirse seguro no es estar seguro. Esto nos lleva a la gran importancia de comprobar el buen funcionamiento de los controles implantados para aparte de sentirnos seguros tras la implantación del SGSI, estarlo, y a una pregunta más, ¿deben los activos de información generados por los controles implantados durante la construcción del SGSI formar parte del análisis de riesgos en futuras iteraciones?.

Espero vuestras opiniones.

Saludos a tod@s

https://formacion-online.inteco.es/inscripcion/

No espereis cursos que profundicen en exceso pero aún así resultarán sin duda de utilidad para muchos.

Salu2!

ConAn

Esta herramienta de adquisición gratuita (registro necesario) y sencilla instalación realiza un análisis bastante completo del sistema y ofrece mucha información al respecto entre la que podemos destacar:

• Nivel de seguridad del sistema detallando cuáles son los puntos débiles (aplicaciones o procesos afectados) y cómo se solucionan ofreciendo enlaces que apoyan al usuario.
• Información detallada del análisis
  • Sistema Operativo
  • Firewall
  • Antivirus
  • Navegadores
  • Conexiones de red
  • Interfaces de red
  • Unidades lógicas
  • Variables de entorno
  • Recursos Compartidos
  • Actualizaciones
  • Servicios y Procesos en Ejecución
  • ActiveX
  • Drivers
  • Aplicaciones que se ejecutan al inicio
  • Archivo de Hosts
  • Políticas de Seguridad
  • Páginas de inicio y búsqueda, extensiones, prefijos, zonas de confianza y opciones agregadas de IE
  • Plugins
  • Browser Helper Objects

Informe de ConAn

Como podéis comprobar es muy completo, quizá lo único que he echado de menos es la posibilidad de que los informes se generen y almacenen en local ya que éstos son almacenados y consultados bajo identificación en el sitio web https://conan.cert.inteco.es/ que se encarga de mantener todos los informes generados por la aplicación. No he evaluado si las conexiones que se realizan para el envío de la información van cifradas. Tampoco he localizado el código hash para comprobar la autenticidad del archivo.

La descarga está disponible a partir de la web: https://conan.cert.inteco.es/analizador.php

Es un placer para mi volver a saludaros y reemprender de nuevo la actualización de este blog que se ha visto interrumpida por motivos diversos.

He querido en mi retorno hacer un breve resumen de lo que en estos dos meses ha ocurrido y subrayaros lo que he considerado más destacado en este post:

• Bug en Twitter: Haz que cualquiera te siga –> security by default
• III Curso de Seguridad en Valencia –> security by default
• Revistas de Hackin9 gratis –> comunidad dragonjar
• Crítica Práctica al ENS –> Joseba Enjuto
• Correcciones a la redacción del ENS –> Javier Cao Avellaneda

Ni que decir tiene que he seguido trabajando en el artículo que tengo pendiente pero no consigo hacerlo funcionar para poder dejarlo todo disponible, en cuanto lo tenga lo sabréis.

Salu2!