La comunidad

[N.d.E.: A pesar de la entrada LOPD, les aseguro que tenemos muy en cuenta el resultado de la encuesta]

Recientemente, en el edificio donde viven unos familiares aparecía publicado junto al ascensor un listado con los propietarios de aquellos pisos que debían dinero a la comunidad, indicando el nombre, los apellidos y la cantidad de dinero a deber. La pregunta que me plantearon es si esos datos podían publicarse de esa manera o estaba prohibido por la LOPD. Mi respuesta inmediata fue, como en casi todos los casos que me plantean una consulta sobre seguridad legal, “depende”.

Normalmente, las consultas planteadas tienen un contexto, el cual resulta fundamental para analizar la consulta, y de esta forma poder plantear la respuesta más acertada. Cabe tener en cuenta que estamos interpretando una Ley, que en muchos casos, establece unas pautas subjetivas que dependen de varios factores de acuerdo a cada situación.

13rue1Volviendo al tema planteado, en cuanto al tablón de anuncios con los impagos de la comunidad (con nombres y apellidos de los “morosos”), parece claro que se trata de una cesión de datos. La comunidad de propietarios, como responsable del tratamiento, está publicitando esos datos personales, de manera que cualquiera que pase por delante de ese tablón de anuncios, desde el vecino del primero, la amiga de la hija de la vecina del sexto, hasta el personal de la compañía eléctrica que va a realizar una lectura de los contadores, pasando por la persona encargada de la limpieza de la escalera, todos ellos, pueden saber qué propietarios deben dinero a la comunidad.

Parece incuestionable que se trata de una cesión de datos —me planteé yo— por lo que sería necesario el consentimiento por parte de cada uno de los propietarios para la publicación de dichos datos. Hasta ahí bien. Pero… si se le va a pedir el consentimiento a la gente para aparecer en un listado como “moroso”, ¿quién va a dar su consentimiento para aparecer en esta lista? La cosa empieza a oler mal, pero mantengo mi posición inicial de que, desde el punto de vista de la LOPD, se trata de una cesión y la finalidad está claro que es poner al corriente al resto de propietarios sobre los impagos y los “morosos”. Por tanto, en un principio se me ocurre que habría que informar de dicha finalidad al propietario y obtener el consentimiento del mismo para poder efectuar la publicación de estos datos, pero tenemos el problema de que nadie daría su consentimiento porque a nadie le gusta aparecer en esa lista de impagos.

Tras darle unas cuantas vueltas al tema, la LOPD también nos dice que, respecto a la cesión de datos, el consentimiento exigido no será preciso cuando la cesión esté autorizada en otra ley. Y aquí encontré la solución a la consulta planteada. El artículo 16.2 de la Ley de Propiedad Horizontal establece “La convocatoria contendrá una relación de los propietarios que no estén al corriente en el pago de las deudas vencidas a la comunidad y advertirá de la privación del derecho de voto si se dan los supuestos previstos en el artículo 15.2“, lo cual hace necesario la cesión de dichos datos al resto de propietarios para su conocimiento previo a una reunión de la comunidad, pero únicamente a cada uno de los propietarios de la comunidad. Por tanto no sería correcto realizar el comunicado a través del tablón de anuncios de la comunidad, para que personas ajenas a la comunidad no pudieran acceder de una manera directa al listado de morosos de la comunidad. Bastaría, por ejemplo, enviando una circular informativa con el listado de impagos, en sobre cerrado, dirigida a cada uno de los propietarios de una vivienda de la comunidad.

De charlas va el tema

A continuación les muestro las presentaciones de dos charlas realizadas por Antonio Villalón, la primera de ellas ayer mismo en la jornada “La Seguridad y Fiabilidad Informática Factor Clave para el Crecimiento de las Empresas” organizada por el Instituto Tecnológico de Informática de la Universidad Politécnica de Valencia, y la segunda el pasado 18 de diciembre, en el ciclo de charlas técnicas del chapter ISACA de Valencia. Espero que les resulten interesantes. En cualquier caso, buen fin de semana a todos.

[Read more…]

Security Art Work

Como sabrán si visitan blogs de manera asidua, cualquier blog que se precie está obligado a dedicar una parte de sus entradas a mirarse el ombligo, o si quieren llamarlo así, a publicar “metaentradas”, cuya única finalidad es hablar del propio blog. Puesto que en los casi 2 años que llevamos de vida apenas nos hemos dado palmaditas en la espalda, y aprovechando la actualización e instalación del WordPress y diversos plugins, he creído conveniente aprovechar esta entrada para que Security Art Work hable de sí mismo.

En cifras, desde el pasado 25 de abril de 2007 llevamos publicadas un total de 220 entradas, sin contar la presente, que han recibido un total de 284 comentarios, es decir una media de 1.29 comentarios por entrada, valor que, todo sea dicho, es francamente mejorable. Si nos vamos a las estadísticas, aunque durante su comienzo los números fueron bastante modestos, lo cierto es que durante los últimos meses Security Art Work ha experimentado un apreciado incremento de suscriptores y visitantes, especialmente a raíz de la aparición en portada de menéame de la entrada sobre la rotura de WPA/WPA2 anunciada por Elcomsoft; tampoco crean que estamos hablando de un aumento impresionante, tal y como verán en las gráficas de debajo.

A partir de los datos de Feedburner (i.e. Google), la gráfica de suscriptores es la siguiente (la caída a mediados de enero fue provocada por un error de Google en la migración de feeds a sus sistemas):

Suscriptores

Mientras que esta es la gráfica de visitas, sacada de Google Analytics:

analytics

Esos son los números de Security Art Work. Como editor y principal colaborador del blog, mi opinión es que el margen de mejora tanto de visitantes/lectores, incluso manteniendo las cifras en una escala “modesta”, es todavía inmenso, y lo mismo puede decirse de la frecuencia de publicación del blog; cada tres días aproximadamente ha habido una nueva entrada, y aunque puede verse como el vaso medio lleno, me permitirán que me quede con el vaso medio vacío. Al fin y al cabo, ya saben que como dijo Antonio Mingote, un pesimista no es otra cosa que un optimista bien informado.

Para acabar, les dejo con una encuesta, que actualizaré cada jueves y a la que podrán acceder a través de la entrada en cuestión y a través de la columna de la derecha. Naturalmente, tras esta breve pausa retomamos nuestra programación habitual, más y mejor si cabe.


[poll id=”3″]

Sistemas Windows: Caídas e inicios de servidor

Los administradores de sistemas necesitamos tener constancia en todo momento de: los períodos de tiempo entre caídas de servidor, así como determinar cuando se ha producido una caída o un apagado ordenado de un sistema. En los sistemas Windows, toda esta información se almacena en el Visor de Sucesos, lo cual supone de gran ayuda para entornos no monitorizados. El problema que surge es la escasa “manejabilidad” de este registros de eventos y su extracción de información, por lo que con objeto de facilitar su tratamiento voy a dar información muy básica sobre este sistema, y cómo extraer información de una manera sencilla.

Cada tipo determinado de información viene marcada por un número de Identificador de evento, que indica un tipo distinto de acción en el servidor. Por ejemplo, respecto a las caídas e inicios de servidor podemos observar tres eventos tipo:

Evento 6006, que refleja que se detiene el Registro de sucesos. Esto indica por regla general un cierre ordenado del sistema, aunque evidentemente podría detenerse únicamente el servicio de registro de sucesos:

c:\> net stop eventlog

Tipo de suceso: Información
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6006
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
Se ha detenido el servicio de Registro de sucesos.

Evento 6009, que refleja que el servidor ha sido iniciado.

Tipo de suceso: Información
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6009
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
Microsoft (R) Windows (R) 5.02. 3790 Service Pack 2 Multiprocessor Free.

Evento 6008. Este evento nos avisa de cuando se produjo una caída inesperada de sistema, lo cual nos proporciona información para poder determinar que otros sucesos ocurrieron entorno a ese hora/día y determinar las causas de la caída del sistema.

Tipo de suceso: Error
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6008
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
El cierre anterior del sistema a las hh:mm:ss del dd/mm/aaaa resultó inesperado.

Una vez sabemos dónde tenemos que buscar la información, queda la cuestión de cómo estructurarla. Aunque se pueden aplicar filtros en el Visor de sucesos para la búsqueda de información, a continuación planteo una forma más automatizada para la obtención de dicha información, y a través de la que podremos exportar la información. Para ello utilizaremos lenguaje VBS.

El siguiente script (que obviamente, y como disclaimer previo, deberán utilizar bajo su propia responsabilidad y de cuyos posibles efectos perjudiciales no asumimos responsabilidad alguna) se encarga de realizar un volcado de la información a un fichero .txt. Si bien es cierto que la información volcada al fichero es pequeña, en esta entrada simplemente trato de abrir la puerta a las posibilidades que nos ofrece el hecho de automatizar procesos de obtención de información. El resto se deja como ejercicio para el lector interesado (o necesitado).

REM Definimos la máquina (en este caso local)
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
  & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

REM Creamos fichero para añadir texto
Const ForAppending = 8
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile ("c:\informe.txt", ForAppending, True)

REM Recolectamos los eventos de Sistema con EventID: 6009)
Set colLoggedEvents = objWMIService.ExecQuery _
  ("Select * from Win32_NTLogEvent Where Logfile = 'System' and " _
    & "EventCode = '6009'")

REM Introducimos en el fichero cada una de las lineas obtenidas
For Each objEvent in colLoggedEvents
  objTextFile.WriteLine(objEvent.EventCode & vbTab _
    & objEvent.TimeWritten & vbTab & _
      objEvent.Message)
Next

Al ejecutar el anterior script, en el fichero “informe.txt” tendremos los eventos registrados en el Visor de Sucesos para el evento 6009, Inicio de servidor. Modificando los valores del EventID, dependiendo del tipo de evento que deseemos buscar, o el nombre de la máquina (ya que con un usuario privilegiado en el dominio podriamos acceder a máquinas remotas) obtendremos informes completos sobre las caídas y reinicios de los sistemas de nuestra red, que podremos exportar y tratar de manera más automatizada que visualizando el visor de sucesos.

El resto de aplicaciones y posibilidades se dejan como ejercicio.

Seguridad y riesgos en las TIC (IV): Proceso de Administración del Riesgo

Retomando la serie introductoria de “Seguridad y Riesgos en las TIC” (uno, dos, y tres), que habíamos dejado temporalmente aparcada, en esta última entrada entraremos a considerar el proceso de Administración del Riesgo, para acabar con unas breves conclusiones. Dicho esto, vamos con la cuarta parte de esta serie.

El proceso de administración de riesgos es un proceso continuo, dado que es necesario evaluar de manera periódica si los riesgos identificados y la exposición de la organización a éstos, calculada en etapas anteriores, se mantiene vigente. La dinámica en la cual se encuentran inmersas las organizaciones actualmente, requiere que ante cada nuevo cambio, se realice en etapas tempranas un análisis de riesgo del proyecto así como su impacto futuro en la estructura de riesgos de la organización.

riesgo.jpg

A continuación se presenta una matriz simplificada, donde en cada fila se presenta una amenaza identificada, y en las columnas se indica, en primer orden la probabilidad de que esa amenaza actúe, y en las columnas siguientes, para cada uno de los activos a proteger cuál es el importe de la pérdida media estimada que ocasionaría esa amenaza en ese activo. La suma de los datos precedentes permiten calcular la columna “Riesgo total”, a la cual se le aplica la efectividad del control actuante, para obtener el riesgo residual.

Como verán en la tabla, y por poner algunos ejemplos, la amenaza de inundación puede ser mitigada ubicando el Centro de Cálculo en un piso elevado, o por razones de seguridad bajo tierra. Por otra parte, los accesos no autorizados vía Internet pueden ser mitigados con un cortafuegos (barrera de control de accesos desde fuera y hacia fuera) correctamente configurado.

riesgo2.jpg

Acabamos de mencionar la presencia de controles, pero, ¿qué es un control? Un control es una medida técnica, organizativa, legal o de cualquier otro tipo que mitiga el riesgo intrínseco del escenario de riesgo, reduciéndolo y generando lo que denominamos riesgo residual, que es el riesgo que obtenemos tras la valoración de la efectividad de los controles. Puede decirse que existe una relación biunívoca entre riesgo y control, por la cual se establece que el coste de un control no debe nunca superar el coste de la materialización del escenario de riesgo. Esto no obstante tiene el problema de poder cuantificar adecuadamente el coste de una amenaza, ya que más allá de costes económicos directos, es necesario considerar costes indirectos, tales como reputabilidad o pérdida de productividad.

Los distintos controles que hemos indicado pueden ser agrupados, sobre la base de los objetivos primarios que quieren satisfacer, en tres categorías no excluyentes: aquellos integrantes del sistema de control interno, aquellos referidos a brindar seguridad y aquellos destinados a brindar calidad de las operaciones. El control interno busca asegurar la eficiencia y eficacia de las operaciones, el cumplimiento de leyes, normas y regulaciones, y la confiabilidad de la información (básicamente aquella publicable). La Seguridad busca asegurar la disponibilidad, confidencialidad e integridad de las operaciones, mientras que la gestión de calidad busca asegurar la adecuada calidad, entrega y coste de las operaciones.

Esto ha sido únicamente una introducción muy básica a los riesgos en el entorno TIC. Existe numerosa documentación sobre el tema, así como diversas metodologías: OWASP, MAGERIT II, CRAMM o la relativamente reciente norma ISO/IEC 27005:2008, cada una con su enfoque y su propia aproximación. Más allá de otros artículos que previsiblemente escribiremos sobre el tema, les dejo que indaguen sobre ellas y descubran sus virtudes y defectos. Sea como sea, no se debe olvidar nunca que los riesgos están presentes en el quehacer diario, aún cuando no se puedan o no se quieran identificar. Por ello, independientemente de la metodología y las herramientas utilizadas para la administración de los riesgos, la administración del riesgo informático debe ser una actividad llevada a cabo, del mismo modo que la implementación y funcionamiento de los sistemas de información. La única manera que evitar un riesgo es eliminar la, o las actividades que lo generan, pero debido a que algunas actividades no pueden ser eliminadas, eso nos obliga a un proceso continuo de administración del riesgo de las TIC.

Normativas

Cuando una persona o empresa decide abrir un negocio en una cierta ubicación, lo primero que debe hacer para estar en una situación legal es solicitar las licencias/permisos correspondientes para comenzar a funcionar y trabajar, así como cumplir ciertas normativas, que en algunos casos supone la elaboración de proyectos o memorias. Muchas veces, esto conlleva una serie de pagos de tasas, destinadas al ayuntamiento, a los servicios territoriales, etc. Ni que hablar tiene de la contratación de empresas externas para la gestión y tramitación de licencias, para reformas en caso de ser necesario y similares, lo que además genera un gran coste económico para la empresa.

Sin embargo, las empresas, por pequeñas que sean, realizan todos estos trámites obligatorios con el fin de conseguir los “papeles” que autoricen la apertura de su nuevo local. Al fin y al cabo, estaríamos hablando de cumplir con la normativa vigente.

No obstante, existe otra normativa que deben cumplir obligatoriamente la práctica totalidad de esas empresas, que como supondrán es la LOPD. Desde el punto de vista de la seguridad, no pretendo infravalorar las normativas pertenecientes a otros ámbitos distintos a la seguridad de la información, que estoy seguro contribuyen a proteger la integridad de las personas que ocupan un local, como puede ser el Reglamento Electrótécnico para Baja Tensión. Tampoco es mi intención promover que el ayuntamiento de una determinada localidad solicite el cumplimiento de la LOPD para otorgar una licencia de actividad de un local, lo que supondría un desembolso económico aún mayor para la empresa (en caso de que subcontrate el servicio).

Sin embargo, y esto sí que es algo que creo necesario, aún son muchas las empresas que desconocen la LOPD —o la conocen “de oídas”, con ideas preconcebidas, erróneas y confusas— precisamente por falta de iniciativas de los organismos públicos —entre ellos la AEPD, a pesar de la jornada de ayer—, que deberían promover mediante publicidad y propaganda el cumplimiento de una Ley obligatoria para todas las empresas (no importa su tamaño) que traten datos de carácter personal.

* * *

vigila.jpgPor último, comentarles que la AEPD ha publicado recientemente una Guía sobre Videovigilancia, que explica y cubre la mayor parte de las dudas de un sistema que cada vez encontramos en más lugares públicos y privados, y que con toda seguridad le resultará útil a muchos de ustedes.

Espero que este documento sirva para que la tienda de ropa de debajo de mi casa sustituya el cartel que reza “¡Sonría, le estamos grabando!” por un cartel más… “normalizado”.

Son *tus* datos

diaeuropeo.jpgAprovechando que hoy es el Día Europeo de la Protección de Datos, tal y como apunta la imagen de la izquierda, quería comentarles un par de errores de concepto relacionados con la protección de datos, y que mi compañero y amigo Fernando Seco intenta enmendar con mayor o menor éxito en prácticamente todas las sesiones de formación que imparte.

El primero de ellos, aunque les parezca obvio, es pensar que los datos son de la empresa. Los datos de carácter personal son, como indica su nombre, de la persona. Es decir, suyos, de ustedes. Usted, y sólo usted, es el propietario de sus datos personales; para bien o para mal, le pertenecen, y excepto en algunas cuestiones puntuales, tiene el derecho de decidir qué se hace con ellos. A pesar de lo obvio que esto parece, muchos ciudadanos todavía no son conscientes de este hecho, y muchas empresas siguen considerando los datos que gestionan como propios. No lo olviden. Sus datos son suyos.

El segundo de los errores está relacionado con los objetivos de la LOPD, aspecto que el entorno empresarial pervierte consciente o inconscientemente. Entre otros, el cumplimiento de la LOPD por parte de una empresa busca a) garantizar el adecuado tratamiento de los datos personales custodiados, y b) asegurar el cumplimiento de la legislación aplicable, con objeto de evitar las posibles sanciones de la AEPD. ¿Cuál creen ustedes que va primero? ¿Cuál creen ustedes que las empresas consideran como el primero?

Para acabar, más allá de regulaciones y leyes, hay un tema vital que es la concienciación de los ciudadanos respecto de sus datos y de los de otros. Cualquier persona que gestiona datos de otras personas debe entender que tratar datos correctamente es más que una obligación legal; es su pequeña aportación al ejercicio de un derecho constitucional, su participación en la defensa de los derechos no sólo propios sino también de los de sus conciudadanos. Es, de alguna forma, la aplicación de ese lema que dice aquello de “No hagas a los demás lo que no quieres que te hagan a ti”.

* * *

Después de un punto y aparte, le invitamos a asistir a la Jornada gratuita sobre Seguridad Informática organizada por el Instituto Tecnológico de Informática de la Universidad Politécnica de Valencia, titulada “Seguridad y Fiabilidad Informática Factor Clave para el Crecimiento de las Empresas“, que tendrá lugar en la el próximo día 5 de febrero por la mañana y en la que S2 Grupo participará a través de nuestro compañero Antonio Villalón, quien dará una ponencia sobre la gestión de las incidencias de seguridad. Esta y mucha más información la encontrarán en la página de la jornada. Le esperamos; al fin y al cabo, piense que el café es gratis.

In-session Phishing

insession.jpgRecientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos, y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing se vale de una vulnerabilidad en la mayoría de los navegadores web: Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso es visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javascript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba registrado en un site totalmente lícito.

[Read more…]

Ofuscación de la barra de estado en Firefox 3.0.5 / Clickjacking PoC

Pueden comprobar, si miran el código fuente de la prueba de concepto (adjunta debajo), que el enlace del “a href” efectivamente apunta a Google, y que por tanto, al pasar sobre el enlace, la barra de estado muestra la dirección de Google. Tengan cuidado con estas cosas.

https://www.securityartwork.es/PoC_clickjacking.html

El cuento de la lechera en la nube 2.0 (o porqué Google no contesta con rotundidad)

[Como habrán visto, y a petición del respetable, hemos introducido la funcionalidad de búsqueda, tanto simple (a su derecha), como avanzada, algo que empezaba a ser una necesidad teniendo en cuenta la cantidad de entradas en las que nos empezamos a mover.]

La semana pasada estuve de vacaciones, y me perdí la entrada de Enrique Dans insistiendo, otra vez, en la conveniencia de gestionar el correo corporativo a través de Google Apps Premium Edition. Bueno, en realidad no me la perdí, pero intenté mantenerme alejado del tema, al menos hasta mi vuelta.

Poco después, el abogado Javier Mestre del Bufete Almeida publicaba un artículo en elmundo.es titulado “El cuento de la lechera 2.0“, poniendo en tela de juicio la conveniencia legal de utilizar los servicios de Google Apps Premium Edition para cuestiones corporativas, en algo que parece casi una respuesta personalizada dirigida a Enrique Dans (“un experto asesor en nuevas tecnologías, de esos que van siempre a la última rodeado de ‘gadgets’ por todos lados”, Javier Mestre dixit). Como respuesta, Carlos Gracia, Director de Google Enterprise España y Portugal, replica con un artículo titulado “Esto no es un cuento 2.0“, y Enrique Dans remata la faena con un artículo en el que critica desde la ignorancia el enfoque de Javier Mestre y respalda los prácticamente inexistentes argumentos proporcionados por el portavoz de Google, casi en calidad del comercial del gigante norteamericano.

[Read more…]