14 julio 2011

Hacia un nuevo modelo de auditoría de protección de datos

Hacia un nuevo modelo de auditoría de protección de datos
Principios y valores

Son ya doce años, desde que se promulgo el RD 994/99 de 11 de Junio, a través del cual se establecía por primera vez, la obligatoriedad de realizar auditorías sobre protección de datos de carácter personal.

El legislador perdió una magnífica oportunidad de desarrollar este precepto con el RD 1720/07 de 21 de Diciembre, quien mantuvo el mismo texto con una única salvedad, la realización de auditorías extraordinarias, cuando hubiese modificaciones sustanciales en los sistemas de información que pudieran repercutir en el cumplimiento de las medidas de seguridad.

El actual texto vigente, determina que el informe de auditoría deberá dictaminar sobre la adecuación de las medidas y controles a la Ley y su desarrollo reglamentario, identificará sus deficiencias y propondrá las medidas correctoras o complementarias, incluyendo hechos y observaciones en los que se basen los dictámenes alcanzados y las recomendaciones propuestas.

En una línea muy parecida, se definen las auditorías de seguridad en el Esquema Nacional de Seguridad (RD 3/2010 de 8 de Enero), pero incorporando un elemento clave en esta materia la independencia. De este modo se describe como revisión y examen independiente de los requisitos y actividades del sistema para verificar la idoneidad de los controles del sistema, asegurar que se cumplen la política de seguridad (mutatis mutandis Documento de Seguridad) y los procedimientos operativos establecidos, detecta las infracciones y recomienda modificaciones apropiados de los controles y de los procedimientos (El Centro Criptográfico Nacional desde el sentido común, habilita la concurrencia de auditorías del artículo 96 del RD 1720/07 de 21 de Diciembre con las del Artículo 34 del RD 3/2010 de 8 de Enero). Guía de Seguridad CCN-STIC-802).

Desde el estándar ISACA para la realización de auditorías de sistemas de información, Institución que debe ser tomado como referente en esta materia (Memoria Anual de la Agencia Española de Protección de Datos del año 2.002) a falta de una reglamentación, define como estructura y contenido mínimo de una auditoría de sistemas de información:
  • Introducción, declaración de objetivos, alcance, carácter y extensión de los procedimientos de auditoría
  • Opinión y conclusión respecto a si los controles y procedimientos son adecuados
  • Hallazgos detallados
  • Limitaciones
  • Declaración sobre las directrices seguidas
La función de la auditoría debe jugar un papel crucial como garante del adecuado diseño del sistema de protección de los datos y del correcto funcionamiento del mismo, por lo que la auditoría bien sea interna o externa, no debe quedarse en un mero testeo de los controles y debe recogerse de manera implícita toda una serie de valores y formalismos.

En este sentido, la auditoría debe contar con un enfoque integrado, tolerancia cero al riesgo al estar en juego derechos fundamentales del individuo y obligaciones de resultado, y bajo los valores y principios de transparencia, objetividad, seguimiento, neutralidad, independencia y recursos especializados.



Desde la experiencia en el sector, considero que se debe alcanzar una mejora global, sustancial y en su conjunto de la calidad de los trabajos de auditoría, debiéndose proyectar sobre todos los actores que ejercitan la actividad de auditoría.

El sector de las auditorías sobre protección de datos, no deben ser totalmente ajenas en cuanto a los principios del sector de otro tipo de auditorías como las de cuentas. La Comisión Europea en un estudio el sector de la auditoría en la UE, mostraba la falta de objetividad y estima explorar la posibilidad de crear un certificado de calidad europeo para sociedades de auditoría de cuentas (Libro Verde de la Comisión Europea. Política de Auditoría. Lecciones de la Crisis).

El Supervisor Europeo de Protección de Datos, en su reciente Dictamen 2011/C 181/01, un enfoque global de la protección de datos personales en la UE, reconoce la necesaria certificación de servicios desde una perspectiva general, que entre otros elementos ayudará a las Autoridades encargadas de la protección de datos en su papel de supervisión. Camino que beneficiara a todos los agentes en juego.

Tal y como exponía, el legislador perdió una oportunidad de oro para desarrollar esta materia en aras de buscar calidad, independencia, neutralidad y objetividad en la realización de auditorías sobre protección de datos, habiendo desarrollado en su día el articulado relativo a las auditorías, aunque hubiese sido como mera recomendación “ad cautelam”.

Comparándonos con el modelo de auditoría de cuentas, que cuenta con una mayor proyección histórica y mayor desarrollo legislativo, es interesante como han ido incorporando mejoras de carácter técnico aconsejadas por la experiencia y la practica desarrollada desde el año 1.988, hasta su reciente Texto Refundido por RDL 1/2011 de 1 de Julio:
  • Contenido mínimo del informe de auditoría
  • Responsabilidad plena de la empresa auditora
  • Sistema de fuentes jurídicas a las que se debe someter la actividad de auditoría:
    • Normas de auditoría
    • Normas Éticas
    • Normas de control de calidad
  • Régimen de incompatibilidades
  • Inscripción en el Registro Oficial
En línea con lo expuesto y con el objeto de crear seguridad jurídica entre todas las partes (Prestadores de Servicios, Responsable de Ficheros y/o Encargados de Tratamiento), considero que debe desarrollarse el marco jurídico de auditorías con el fin de garantizar los principios, valores y resultados de las auditorías, con un nivel de calidad mínimo y donde quede claro y manifiesto entre otros muchos elementos el régimen de responsabilidad civil.

En cuanto al modo de reglamentación. Considero que la figura de la Instrucción de la Agencia Española de Protección de Datos, quizás no tenga cabida, a pesar del valor normativo de éstas (Sentencia del Tribunal Supremo de 16 de Febrero de 2.007. Fundamento Jurídico Tercero), La figura de la Instrucción debe ir dirigida a adecuar tratamientos a los principios de la Ley, por lo que a mi entender lo realizaría a través de un nuevo texto Reglamentario y huir de otras vías del tipo, disposición adicional trigésimo octava de una Ley de Acompañamiento, o como Disposición Adicional Primera de una Ley relativa a la protección del Lince Ibérico. Tendencia habitual del legislador de denominar inadecuadamente las Leyes. Las esconde bajo rótulos, títulos e indicadores que nada tienen que ver con el ámbito objeto de regulación. Lo que el Primer Presidente del Tribunal Supremo tras la Transición, el eminente jurista, Excmo. Don Federico Carlos Sainz de Robles llamó “el juego del escondite”.

Lo justo y lo injusto no son productos de la naturaleza, sino de la Ley (Arquelao).

------------------------------------------------------------------------------------------

Contribución por:
Gonzalo Salas Claver
Senior Manager
Grupo SIA
Leer más...

13 julio 2011

Swivel Pinsafe: Autenticación Fuerte sin Tokens

Cuando empecé a escribir en SecurityByDefault, trabajaba como preventa técnico para un fabricante de Cortafuegos de Aplicaciones Web (o WAF), y de ahí que haya mencionado en varios posts este tipo de protección ante ataques de nivel 7 a las aplicaciones web.

Desde la semana pasada, y espero que por muchos años, he cambiado la protección web, los SQLi, XSS, RFIs y demás,… por otra empresa dedicada a la protección de accesos remotos mediante mecanismos de autenticación fuerte,... bastante curiosos.

Esta claro que los accesos usuario/contraseña únicamente, pueden llegar a ser bastante inseguros. Los riesgos: fuerza bruta, diccionario, robo de credenciales, troyanos, contraseñas almacenadas en claro, etc,…  Además de que, como hemos contado varias veces también, la gente utiliza contraseñas débiles por longitud, y baja complejidad, así como fácilmente adivinables.

Para determinadas conexiones, en las que con una autenticación se da acceso a toda una organización (por ejemplo mediante un acceso VPN), puede ser realmente peligroso dejarlo en manos de un único mecanismo por usuario/contraseña que no siempre cumple características de gran complejidad, que puede estar escrita en un post-it en el monitor o de fondo de pantalla del escritorio, que puede ser vox populi porque hubo que decírsela a alguien una vez para que pudiera hacer determinada operación o que simplemente ha sido robada por Shoulder Surfing al escribirla en el teclado varias veces. El principal peligro de una autenticación por usuario/contraseña es que éstas últimas, sean como sean, son estáticas.

Así pues, para otorgar un mayor nivel de seguridad para estos accesos, es por lo que se utiliza lo que se llama un 2FA o una autenticación de doble factor. En general, la autenticación fuerte por 2FA viene dado por la composición de una doble autenticación en base a tres tipos de factores: algo que se sabe (la contraseña), algo que se tiene (generalmente un token que genera un código OTP) y algo que se es (autenticación biométrica).

Para la autenticación biométrica, es necesario contar con dispositivos que sean capaces de "reconocer" una característica de los usuarios (la voz, el iris, la retina, las huellas dactilares, la disposición de las venas…). Esto, estando en la playa, por ejemplo ahora que empiezan los meses de vacaciones de verano, no resulta muy cómodo.

En menor medida, para poder acceder remotamente a una organización, no siempre es agradable tener que estar cargando en todo momento con el típico llavero rojo y azul que genera numeros aleatorios válidos durante un tiempo finito. Si olvidamos el token en el coche, en casa, en otra chaqueta, etc,… estaremos todo un día sin podernos autenticar y por ello, en algunas ocasiones, hasta trabajar. Por experiencia, si me dejo el móvil en casa, lo utilice o no como soft-token, vuelvo a por él.

Os quiero contar como es, a muy grandes rasgos, la solución de Swivel Secure, no porque trabaje para esa compañía desde este mes (que también :D), sino porque me ha parecido muy original, seguro y cómodo. PinSafe permite generar un One-Time-Code sin necesidad de llevar llaveros, tarjetas empresariales, tarjetas de coordenadas, chips, ni demás "amuletos". Lo único que hay que saberse es un PIN, además de tu usuario/contraseña. Pero ojo, el PIN que te sabes, no hay que ponerlo en ningún sitio, sino no valdría para nada al ser siempre el mismo. El dispositivo de autenticación presentará al usuario lo que se llama una "security string": básicamente una cadena de caracteres aleatorios que puede ser presentado en formato imagen de TURing, o enviado por SMS, email, a través de una aplicación de un dispositivo móvil (iPhone, Android, applet Java, Windows Mobile, etc,…) Los números del PIN que nos sabemos, marcará las posiciones de los caracteres de la security string que se nos presenta.


El OTC (One Time Code) que deberemos introducir será diferente en cada autenticación, pudiendo forzar las características del PIN (longitud, complejidad, nivel de repetición, etc,…). Incluso se puede hacer que las imágenes de TURing aparezcan animadas para evitar troyanos que monitorizan la  pantalla de un usuario infectado. Muchos diréis, oye pero si estás en un entorno con posibilidad de MiTM, se podrá averiguar el PIN también en base a analizar el TURing y los caracteres enviados. La respuesta es sí, pero siempre puedes hacer que el security string le llegue al usuario por un canal diferente (SMS, aplicación para móvil, etc,..), entonces será necesario tener troyanizada tu vida entera para que averigüen tu PIN.

Si queréis ver la presentación que hizo mi compañero Alex Rocha en el Asegur@IT 9, os dejo el video con la misma, bajo estas líneas.




Podéis comprobar por vosotros mismos algunas de las capacidades de la solución, así como la diversidad de productos empresariales con los que se integra.
Leer más...

12 julio 2011

Comienza Wargame II de SecurityByDefault #wgsbd2 #cpes15


https://portal.securitybydefault.com/
Leer más...

11 julio 2011

Comenzamos la semana de Campus Party Valencia 2011, y con ella, la segunda edición de nuestro Wargame de SBD, #wgsbd2. Mañana martes 12 de Julio será la presentación del Área de Seguridad y Redes de esta edición de la Campus Party, la cual contendrá charlas (incluida una de Hackeos Memorables de la mano de nuestros compañeros Yago Jesus y Lorenzo), talleres, la presencia de Kevin Mitnick y como no, nuestro concurso, con 2.000€ en premios, gracias a ESET.

Si bien se trata de un concurso para la Campus Party, podrá participar todo aquel que lo desee, aunque no pueda asistir al evento. Eso si, como hemos repetido varias veces, únicamente podrán optar a premios aquellos usuarios que se hayan registrado como campuseros mediante la página web de Campus Party. A continuación, publicamos las indicaciones básicas del wgsbd2 (que también podréis consultar en la página de bases dentro del panel de puntos cuando esté publicado en internet),  del que si todo va bien, comenzará mañana martes, por lo que permaneced atentos a nuestro blog y twitter, ya que publicaremos las direcciones para que podáis acceder a él.

   


-------- Resumen de indicaciones acerca del concurso Wargame SecurityByDefault 2 --------
  • Fechas:
    • El concurso comenzará el martes 12 de Julio de 2011 (hora por determinar, iremos informando)
    • El concurso finalizará el sábado 16 de Julio de 2011 (hora por determinar, iremos informando)
  • Participantes:
    • Es necesario registrarse utilizando el formulario de registro del panel de puntos para acceder a él y enviar los tokens de cada prueba.
    • Se permite la participación tanto individual como por grupos. Únicamente registrar una cuenta en caso de participar por grupos. Dicha cuenta será la "portavoz" del grupo, así como la dirección de correo electrónica facilitada el punto de comunicación con el grupo.
    • Se requiere que no se publiquen solucionarios hasta que el concurso haya finalizado.
  • Pruebas:
    • Se dispone de un total de 24 pruebas, no categorizadas explicitamente pero si recorriendo diferentes temáticas, desde pruebas forense, a seguridad web, ingeniería inversa, redes, criptografía...
  •  Sistema de puntuación:
    • Cada prueba tiene un valor de 150 puntos.
    • Los puntos asignados al usuario que resuelva la prueba dependerán del número de personas que hayan conseguido solucionarla previamente. Ejemplos:
      • Ejemplo I - Si eres el primero en resolver la prueba, conseguirás 150 puntos.
      • Ejemplo II - Si previamente se han pasado la prueba 12 personas, se obtendrán 150 - 12 = 138 puntos.
  • Comunicación con la organización:
    • Mediante twitter, utilizando el hashtag #wgsbd2
    • Mediante correo electrónico, escribiendo a wgsbd@securitybydefault.com
    • Dirigiéndose al Área de Seguridad y Redes dentro de Campus Party Valencia 2011
  • Premios:
    • Para optar a los premios, es necesario estar registrado como campusero de Campus Party (no es necesario haber asistido a ninguna Campus anterior para ser campusero). Para ello, utilizar el siguiente formulario de registro http://www.campus-party.org/signup.html
    • Para los ganadores:
      • Primero: 1.000 € + hardware valorado en 2.000€ (gracias a ESET)
      • Segundo: 600 €
      • Tercero: 400 €
    • Se solicitarán los solucionarios de las pruebas a los ganadores para su comprobación.
  • Descalificaciones:
    • Denegaciones de servicio.
    • Atacar el portal de puntos de cualquier manera.
    • Robar soluciones a otros participantes.
    • Comportamientos anómalos.
    • Insultar, escupir, dar puñetazos, hadoukens, kamehamehas,...
----------------------------------------------------------------------------------------

Mañana cuando se presente el concurso y sea posible participar, publicaremos las direcciones del panel de puntos y presentación en un post. Hasta entonces, y como se suele decir, ¡permanezcan atentos! Al igual que en anteriores ediciones, se dispondrá de video streaming para seguir todas las actividades de las diferentes áreas, a través de CampusTV, por lo que si no podéis pasaros por Valencia, todavía tenéis una oportunidad de disfrutad del evento gamer y tecnológico del año.
Leer más...

10 julio 2011

Enlaces de la SECmana - 79


Leer más...

09 julio 2011

Hace no demasiado tiempo fue muy sonado el caso de Gary McKinnon, un hacker británico que presuntamente habría conseguido entrar en redes de la NASA, US Army, DoD y US Air Force. Y cuando decimos entrar, es entrar hasta la cocina, y no juguetear con su página web.

Ésto sucedió durante los años 2001 y 2002, a partir de entonces estuvo involucrado en todo un entresijo legal con Estados Unidos, que finalmente pidió su extradición.

El motivo por el que Gary irrumpió en esos sistemas fue su búsqueda de tecnología extraterrestre, especialmente la generación de energía gratuita. Pensaba que era injusto que hubiera guerras y países invadidos por culpa del petróleo mientras que departamentos secretos de Estados Unidos podrían estar ocultando fuentes de energía gratuita. De hecho, pensaba que ésta tecnología extraterrestre era el mayor secreto jamás guardado, y si encontraba la información la liberaría para beneficio de la humanidad.

Programó un pequeño script en Perl que escaneaba máquinas con contraseñas vacías o por defecto. Según sus cálculos podría escanear 65000 máquinas cada 8 minutos aproximadamente. Una vez lo puso a funcionar quedó impresionado con la poca seguridad, o mejor dicho la ausencia de ésta, de esas redes.

Durante los dos años que estuvo investigando cuidó meticulosamente sus horarios para conectarse durante las noches de Estados Unidos. Aún así comenta que un ingeniero de redes le detectó mientras lo controlaba mediante escritorio remoto, y le preguntó vía WordPad "¿Qué estás haciendo?", a  lo que contestó que pertenecía a un cuerpo militar de seguridad informática, cosa que el ingeniero aceptó.

Finalmente cuenta que en el centro espacial Johnson de la NASA encontró fotografías en alta resolución de tecnología no humana (concretamente de lo que podríamos llamar un OVNI), la culminación de todo su trabajo. No consiguió descargarlas porque estaba ejecutando un programa de control remoto y cuando se dispuso a descargar los ficheros fue detectado y expulsado del sistema.

Y hasta aquí su pintoresca historia. Es un caso realmente extraño ya que por un lado no hay ninguna prueba, pero por el otro ha tenido gran repercusión, no sólo por la prensa, sino también por parte de Estados Unidos que ha puesto grandes esfuerzos para capturarle. ¿Miedo por lo que pudiera haber visto? Quién sabe ...

Leer más...

08 julio 2011

Vulnerabilidades en Bind 9 y los australianos prematuros

Este pasado 5 de Julio, mientras todos los americanos estaban de resaca por el día de la independencia, se publicaba prematuramente por parte del CERT Australiano (AusCERT) un nuevo advisory (nota de seguridad) sobre el DNS de BIND. Se trataba de un par de vulnerabilidades que afectaban remotamente al servicio, y que mediante paquetes malformados serían capaces de provocar la denegación del servicio named, afectando tanto a servidores autoritativos como a recursivos. De criticidad severa y explotable remotamente. Las vulnerabilidades corresponderían con los CVE CVE-2011-2465 y CVE-2011-2464.

La nota de prensa por parte del AUSCERT la podréis consultar en este enlace (pastebin). Si bien su fecha de publicación oficial finalmente ha sido el 5 de Julio, el AUSCERT especificaba que esta información se publicaría el 6 de Julio en la sección de seguridad del ISC, www.isc.org/security (buscad la cadena "Document URL: http://www.isc.org/security (to be published July 6)"). ¿Desfases horarios? ¿Mala coordinación? ¿Despiste?

Seguidamente, el AUSCERT se disculpaba enviando la siguiente nota a todos sus usuarios:
Pedimos disculpas si el anuncio prematuro ha causado que hayan iniciado algún tipo de acción para la que no estén preparados y que debería ser interrumpida. Por favor, no distribuyan el boletín del AusCERT. Por favor, elimínenlo de sus sistemas inmediatamente y permanentemente.
Tarde, lo que publicas en internet, ya nunca puede desaparecer o ser eliminado.

Volviendo al tema más importante, estas vulnerabilidades se resuelven actualizando a las siguientes versiones de Bind 9:

  • 9.6-ESV-R4-P3
  • 9.7.3-P3
  • 9.8.0-P4
Según el ISC acerca de que servidores resultarían vulnerables: "Servidores que tuviesen la recursión habilitada y estuviesen configurados con una zona RPZ conteniendo ciertos tipos de registros. Sobretodo, registros DNAME y algunos tipos de registros CNAME"

Leer más...