Diferentes Niveles de Seguridad en los Archivos PDF

Hace más de quince años, Adobe Systems Incorporation introdujo en el mercado mundial el concepto del documento electrónico ubicuo, logrando posicionar un formato que ha sido adoptado como estándar “de facto” para el intercambio de documentos electrónicos; me refiero al formato PDF, por sus siglas en inglés Portable Document Format (Formato de Documento Portable), un PDF puede ser visualizado en casi cualquier computadora o dispositivo móvil utilizando un producto gratuito llamado Adobe Reader (antes conocido como Acrobat Reader). En la actualidad, PDF es un formato reconocido por la organización de estándares internacionales (ISO, International Standards Organization).

Este formato PDF es el complemento ideal para trabajar con documentos electrónicos firmados digitalmente, dado que entre otras propiedades puede proteger su contenido, puede evitar que sea modificado y mantiene todas sus propiedades independientemente de la computadora que se use para visualizarlo.

Es muy importante que todas las empresas, grandes y pequeñas, evalúen el impacto que tendrá el uso de documentos electrónicos con validez oficial y que definan una estrategia a seguir en el corto y mediano plazo.

El tener un documento electrónico o un formato electrónico trae muchas ventajas a una organización, por ejemplo, una orden de compra electrónica puede tener catálogos que ayuden a la persona que está llenándola, reduciendo los errores típicos de la captura, agregando validaciones de la información; incluso se puede tener un documento “inteligente”, capaz de mostrar y ocultar información de acuerdo como sea necesario.

Con la evolución de la tecnología hemos observado grandes cambios en la forma de operar de los negocios, en la calidad del servicio que ofrecen empresas de todos los ramos y en la creciente necesidad de tener acceso a servicios “en línea” para poder realizar trámites personales; sin embargo, con todos estos avances, hoy dependemos más que nunca de grandes cantidades de papel, con sellos y firmas que le dan autenticidad y que, en ocasiones, estamos obligados a conservar por muchos años.

Por supuesto, el gran reto para estos documentos es el garantizar su autenticidad, para lo cual se ha acuñado el concepto de “firma electrónica”, que es una analogía digital de la firma autógrafa que usamos cotidianamente. Esta firma electrónica se vale de mecanismos de cifrado de información (también llamado encripción) que garantizan la autenticidad del documento; de tal forma que se puede asegurar que el documento no ha sido alterado desde que fue firmado, además de identificar plenamente a la persona que firmó el documento.

• Seguridad Básica.

El nivel de seguridad más básico que se puede aplicar a un archivo PDF se consigue mediante una contraseña de administrador que bloquea algunas características del archivo, por ejemplo, pedir una clave para abrir el documento, prevenir que se modifique el contenido del documento, evitar que se pueda copiar el contenido y pegarlo en otra aplicación e incluso no permitir la impresión del mismo.

Este nivel de seguridad existe en un PDF desde hace mucho tiempo y ha permitido proteger parcialmente la información, sin embargo, la contraseña reside dentro del PDF y, por lo tanto, es susceptible de ataques conocidos como “fuerza bruta”, en los cuales un programa intenta posibles combinaciones de letras y palabras hasta que se logre “adivinar” la clave.

La ventaja de este mecanismo de seguridad es que no requiere de ningún componente adicional para ser implementado y es adecuado para documentos con información pública o información de bajo nivel de sensibilidad.

Para la implementación de esta funcionalidad Adobe utiliza algoritmos de cifrado con llave simétrica como AES (128 y 256 bits) y RC4 (128 bits).

• Seguridad por cifrado (encripción)

Mediante el uso de certificados digitales es posible tener un mayor nivel de seguridad en un documento PDF, para lo cual es necesario contar con certificados digitales con llave asimétrica, es decir, un una pareja de llaves pública y privada.

En este caso, no hay suficiente información dentro del documento PDF que permita romper la seguridad con un ataque de fuerza bruta, solamente mediante el uso de la llave pública correspondiente a la llave privada utilizada para encriptar (cifrar) el documento, se podría abrir o modificar la configuración de seguridad. Para este tipo de implementación Adobe utiliza el algoritmo RSA (512, 1024 y 2048 bits).

• Seguridad máxima

El mayor nivel de seguridad que se puede lograr actualmente en un documento PDF está relacionado con un concepto que se utiliza en la actualidad llamado “administración digital de derechos” (DRM, Digital Rights Management), en este caso, además de poder controlar la modificación o la impresión de un documento, se puede controlar la autorización de quien puede hacer qué con un documento PDF e incluso la vigencia del mismo.

En resumen, se puede tener el control de acceso a un PDF, sin importar el lugar donde se encuentre el mismo, es decir, puede estar en un repositorio, en un disco portátil, en un disco óptico, incluso en la computadora de la casa de una persona y se sigue teniendo el control del documento.

¿Cómo se puede lograr esto?, en realidad, se utiliza un servidor (Adobe LiveCycle Policy Server) que encripta un documento cuando se le aplica una política y cada vez que alguien intenta abrirlo, se establece una conexión hacia el servidor para identificar el documento, autenticar a la persona (via una conexión con el directorio corporativo LDAP) y, en caso de que todo sea válido y la apertura este permitida, se envía una llave temporal para desencriptar y abrir el documento.

Con esta solución se puede tener incluso una historia de los eventos relacionados con el documento, por ejemplo, se puede saber quién abrió un documento, quién lo mandó a impresión, desde qué computadora lo hizo, entre otras cosas.

Este nivel de seguridad es ideal para documentos confidenciales que deben ser preservados en todo momento.

• Conclusión

Existen diferentes niveles de seguridad que deben ir relacionados con el contenido de cada archivo PDF, en algunos casos es suficiente con la seguridad básica, en otros casos es necesario utilizar una firma electrónica o encriptar el contenido; y para la información confidencial se puede utilizar la seguridad máxima; pero siempre bajo el entendido que el documento sigue siendo un PDF y puede ser abierto en cualquier plataforma donde está disponible el Adobe Reader gratuito.

Por Luis Carselle Gerente de Cuentas Corporativas en Adobe Systems Latino América

Fuente: http://www.tynmagazine.com/notas.php?id=734

Los Ataques Internos, un gran peligro

Secure Computing Corporation, un a empresa de seguridad informática empresarial ha realizado una encuesta a 103 directores de tecnología y ha sacado unas conclusiones interesantes:

El 80% creen que tiene un gran problema con los ataques internos a la seguridad.
El 37% ha detectado fugas de información sensible en el último año.
El correo electrónico es la vía de apertura de la brecha de seguridad en la mayor parte de los casos las mayores inversiones en seguridad pasan por reforzar la seguridad interna de la empresa.

Respecto a los problemas de seguridad externos, las respuestas de la encuesta dicen lo siguiente el malware preocupa más que los hackers, los virus y el spam siguen manteniéndose como elementos degran preocupación.

Fuente: http://www.blogantivirus.com/los-ataques-internos-un-gran-peligro

ISO 27005:2008: Gestión de Riesgos

Desde el día 4 de Julio se dispone de la nueva norma ISO 27005:2008,"Information security risk management".Esta norma ISO/IEC 27005:2008 proporciona directrices para la gestión de riesgos de seguridad de la información.

Esto apoya los conceptos generales especificados en ISO/IEC 27001 y ha sido diseñada para ayudar a la puesta en práctica satisfactoria del análisis y la gestión del riesgo, fase principal del diseño de todo buen sistema de gestión de la seguridad de la información (SGSI).

El conocimiento de los conceptos, modelos, procesos y terminologías descritas en ISO/IEC 27001 e ISO/IEC 27002 es importante para lograr el entendimiento completo de la ISO/IEC 27005:2008.ISO/IEC 27005:2008 es aplicable a todos los tipos de organizaciones (p.ej. sociedades mercantiles, administraciones públicas, organizaciones no lucrativas) que tengan la intención de manejar los riesgos que podrían comprometer la seguridad de la información de la organización.Esta norma actualiza a la antigua ISO 13335, partes 3 y 4.

La legislación suele pecar de ambigua a la hora de hablar de seguridad. En general se venía diciendo que los procesos telemáticos deben garantizar la disponibilidad, integridad y confidencialidad de la información, sin establecer mínimos (A excepción de la legislación en materia de protección de datos de carácter personal que lo regula vía reglamentaria).

Como mucho aparece que las medidas de seguridad serán proporcionales a los "riesgos y el estado de la tecnología".

Pues bien, he hallado una nueva redacción a estos requisitos en la Orden PRE/1551/2003, de 10 de junio, por la que se desarrolla la disposición final primera del Real Decreto 209/2003, de 21 de febrero, por el que se regulan los registros y las notificaciones telemáticas, así como la utilización de medios telemáticos para la sustitución de la aportación de certificados por los ciudadanos y en la ORDEN PRE/3949/2006, de 26 de diciembre,por la que se establece la configuración, características, requisitos y procedimientos de acceso al Sistema de Verificación de Datos de Identidad donde para determinar la seguridad de la información necesaria aparece el siguiente texto:

Adopción de las medidas de seguridad, organizativas o técnicas, de los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única.

1. Con carácter general se aplicarán a los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única las medidas de seguridad, conservación y normalización que se detallan en los Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades aprobados por el Consejo Superior de Informática y para el impulso de la Administración Electrónica y accesibles en su sitio web.

Dichas medidas de seguridad, conservación y normalización vendrán determinadas por el resultado del análisis y gestión de riesgos que se realice, recomendándose a estos efectos la utilización de la metodología Magerit.

2. Lo dispuesto en esta Orden Ministerial se aplicará en todo caso de conformidad con lo previsto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal y demás normativa aplicable en esta materia.

Lo significativo que merece ser destacado es la exigencia de la realización de un análisis y gestión de riesgos previo a determinar las medidas de seguridad necesarias y además, establecido mediante una Orden Ministerial.

Me inicié en esto de la seguridad de la información ya hace casi 10 años justo en un proyecto piloto de valoración de la metodología MAGERIT (En aquella época, versión 1.0) y aunque siempre he considerado, pese a detractores, que el análisis y gestión de los riesgos es el criterio de diseño del conjunto de medidas, el reconocimiento que realiza esta nueva redacción de los requisitos de seguridad va a forzar a las instituciones a pasar forzosamente por el proceso.

Se discute mucho sobre la rigurosidad de esta disciplina, basada en estimaciones y valoraciones subjetivas pero lo importante al final es que obliga a determinar qué elementos son importantes, cual es su valor y qué podría pasarles respecto a potenciales incidentes de seguridad.

Este mínimo ejercicio de reflexión es necesario para que la seguridad no se base en la percepción del riesgo. Debe ocurrir que la sensación de seguridad sea igual que la seguridad real de la que se dispone.

En cuanto a la metodología MAGERIT 2.0, no creo que se diferencie en su esencia de lo contenido en esta norma ISO 27005:2008 porque básicamente todo análisis y gestión de riesgos pasa por las siguientes fases:

Fase de análisis de riesgos:

Determinación de activos
Determinación de amenazas
Estimación de impactos
Estimación de vulnerabilidad de las amenazas sobre los activos

Cálculo del nivel de riesgo.

Fase de gestión de riesgos:
Determinación de los criterios de aceptación del riesgo
Determinación de las medidas de seguridad necesarias
Estimación del nivel de riesgo residual

La documentación de MAGERIT 2.0 puede obtenerse en el Consejo Superior de Informática en la siguiente ficha descriptiva y en la propia página del Centro Nacional de Inteligencia en la urlhttp://www.ccn.cni.es/series.html hay un documento titulado CCN-STIC-410 Análisis de Riesgos Sistemas de la Administración v1.0.pdf con un ejemplo de su aplicación.

Fuente: http://seguridad-de-la-informacion.blogspot.com/2008/06/publicada-la-iso-270052008.html

Problema Grave de SSL

Debian fallo seguridad SSL.

Hoy he recibido por correo de Hispasec esta estupenda descripción del fallo de seguridad SSL que se ha descubierto en Debian recientemente.

Copio y pego.Hispasec - una-al-día 16/05/2008.

El problema encontrado en OpenSSL de Debian puede ser considerado, lamentablemente, un verdadero acontecimiento criptográfico. La criptografía es una ciencia compleja, y con el ánimo de aclarar las graves y extensas consecuencias del fallo, hemos redactado una serie de preguntas frecuentas para intentar, aun tratándose de un tema tan complejo, arrojar algo de luz. ¿Qué ha pasado exactamente? Alguien (por error) del equipo de Debian eliminó una línea de código en el paquete OpenSSL de Debian que ayudaba a generar la entropía al calcular el par de claves pública y privada. Las claves sólo se calculaban tomando como semilla el PID del proceso. Al estar limitado a 32.768 semillas (tantos como PIDs de proceso son posibles) para la generación de números seudoaleatorios, el número de claves posibles es pequeño. Se han estado generando las mismas claves dentro de este número limitado de posibilidades desde septiembre de 2006. Como son pocas y de entropía pobre, se puede deducir la clave privada a partir de la pública porque el espacio de primos es muy pequeño y está precalculado. Ya se han generado listas disponibles para todos con la clave pública (del espacio a que han quedado limitado después del fallo) y su correspondiente privada. Para los usuarios de este OpenSSL de Debian sin entropía suficiente, se han roto las reglas de la criptografía asimétrica en la que por ahora confiamos todos y que sustentan las bases de la (poca) seguridad y confianza que pueda existir en Internet. ¿Es tan grave como parece? Es más grave. Mucho más grave. Podríamos considerar que la criptografía de Debian en los últimos dos años ha sido una pantomima. Y es grave además porque no se resuelve por completo parcheando. Esa no es la solución definitiva. Hay que regenerar claves, revocar las antiguas, certificarlas en el caso de SSL, comprobar dónde fueron a parar claves generadas con Debian... No es un bug en un programa que eventualmente quedará obsoleto porque todo el mundo estará parcheado. Habrá administradores que no comprueben la debilidad sus claves, servidores SSL que jamás certifiquen de nuevo sus claves, claves perdidas de usuarios que dejen la puerta abierta a servidores SSH... También es grave porque arrastra a decenas de programas y sistemas que se valen de claves generadas con OpenSSL. SSL, SSH, OpenVPN, DNSSEC... Alguien lo ha calificado de "apocalipsis criptográfico". Además los principales perjudicados son los servidores que precisamente hayan buscado más seguridad con la criptografía de clave pública, porque contenían información crítica. El SANS Internet Storm Center ha elevado el nivel de alerta general a 'amarillo'. No ocurre a menudo. ¿Cómo ha podido ocurrir? Ha sido todo un desafortunado error. Aunque surgirán las teorías conspiratorias porque el código abierto ha estado ahí durante dos años, no ha sido hasta que Luciano Bello se ha dado cuenta que se ha corregido el fallo y se ha dado la voz de alarma. Pero el daño ya está hecho. Dos años de claves débiles generándose en cientos de miles de sistemas. Ha pasado desapercibido porque en general cualquier programa es complejo, pero la criptografía lo es aún más. Además, Bruce Schneier dijo algo así como 'Good security looks the same as bad security' ('La buena seguridad se ve igual que la mala', frase aplicable aún más a la criptografía). Kurt Roeckx fue quien planteó en un principio borrar líneas que consideraba problemáticas. Existe un correo de 2006 en una lista pública, en el que Roeckx plantea en una lista de OpenSSL qué pasaría si las eliminara. Pregunta si resultaría en una posible pérdida de aleatoriedad. La respuesta no oficial desde OpenSSL es que "no mucho" y que es partidario de borrarlas si ayuda en la depuración. Y era cierto, esas líneas no suponían problema: el problema es que en Debian se borraron más líneas de la cuenta, de las habladas en la conversación y para colmo los cambios no se enviaron a OpenSSL para que fueran revisados.

¿Se soluciona parcheando? No. No se trata de un fallo de seguridad al uso. Ha existido una fuente de claves inseguras que se han esparcido durante dos años. Hay que comprobar y regenerar claves. El fallo fue anunciado a la vez que el parche, pero hay que tener en cuenta, que las primeras versiones de los parches para Debian y Ubuntu contenían regresiones. Han publicado nuevas actualizaciones para los propios parches que es necesario aplicar también.

¿Qué pasa si tengo un servidor web con acceso por HTTPS? Si las claves han sido generadas con la versión de OpenSSL con el problema, las consecuencias son que alguien se puede hacer pasar por el servidor porque tendrá la privada de forma instantánea a partir de la pública. Además, cualquiera que haya tenido acceso a una conversación cifrada con el servidor, podría también descifrarla. Esto es así porque la clave simétrica que se utiliza para el cifrado ha sido intercambiada con la ayuda de claves asimétricas débiles. Un administrador debe además revocar la clave, generar una nueva, enviarla a la Autoridad Certificadora (que cobra por certificar) e instalarla. La catástrofe hubiese sito total, si una Autoridad Certficadora, hubiese generado claves y firmado certificados con estas claves débiles, pues el problema se extendería hacia abajo a todos sus clientes, en cuyos certificados ya no se podría confiar. Al parecer han comprobado que las principales Autoridades no se ven afectadas.

¿Qué pasa con SSH? Los administradores que controlan sus sistemas a través de SSH se suelen autenticar a través de su clave privada y el servidor de SSH almacena la pública correspondiente. Esto es más seguro que usar una sola contraseña simétrica para autenticarse. El servidor cifra una cadena con la clave pública del que pretende autenticarse y se la envía, si puede descifrarla le deja pasar. En este caso puede que la clave pública sea realmente pública o no. En el primer caso, deducir la privada es instantáneo, y en el segundo caso, si no se conoce la pública, se debe hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño, algo que tarda unos 20 minutos con un ordenador de hoy día. Se ha creado un exploit para esto.Todos los administradores que permitan a sus usuarios utilizar la clave privada para acceder a sus sistemas a través de SSH, deben auditar las claves para saber si son de las "débiles". Los administradores de SSH también se encuentran ante una tarea concienzuda, peligrosa, (y que deben emprender ya) incluso si no utilizan Debian, porque puede que sus claves hayan sido generadas en una distribución Debian y exportadas. Los administradores de SSH comprobarán, con total seguridad, como los intentos de acceso ilegítimo se multiplican en estos días.

¿A Windows le pasó lo mismo? No. Se demostró que el generador de números aleatorios de Windows era débil, pero la diferencia es que según el estudio, había que conocer el estado previo del generador para saber el siguiente cálculo. Esto podría permitir descifrar conversaciones SSL entre dos sistemas. Pero para poder llegar a tener acceso a esa información inicial de la que se deducirían el resto de "estados del algoritmo", un atacante necesitaría poder tener acceso como administrador en el sistema. Digamos que para poder aprovechar el problema del algoritmo y poder descifrar la información, necesitaría tener el total control de la máquina para llegar a conocer un estado, con lo que el sistema ya estaría comprometido en sí.

Conclusiones

Lo peor no está ocurriendo ahora. Lo verdaderamente grave ha podido ocurrir antes (en los últimos dos años si alguien ha conocido este error y lo hubiese mantenido en secreto) y después (lo que nos espera a medida que se vaya descubriendo que sistemas importantes ha generado claves débiles).

Más información: The Debian OpenSSL disaster http://blog.drinsama.de/erich/en/linux/2008051401-debian-openssl-desaster.html

Random number generator, uninitialised data and valgrind http://marc.info/?l=openssl-dev&m=114651085826293&w=2

The Bug http://metasploit.com/users/hdm/tools/debian-openssl/ http://wiki.debian.org/SSLkeys

Debian and Ubuntu users: fix your keys/certificates NOW http://isc.sans.org/diary.html?storyid=4420

Gartner recomienda al empresariado abstenerse de incorporar iPhone

Cuando Apple lanzó su teléfono iPhone hace un año, la consultora Gartner desaconsejó incorporar el aparato en aplicaciones empresariales. A su juicio, el iPhone no era un dispositivo lo suficientemente seguro.

Gartner mantiene su opinión con el lanzamiento del nuevo iPhone 3G, a pesar que se trata de un producto mejorado. Gartner reitera su escepticismo ante la aceptación de iPhone como un teléfono para usos empresariales, a pesar que Apple ha incorporado una serie de funciones corporativas en su nuevo teléfono iPhone 3G. La seguridad del nuevo modelo ha sido considerablemente mejorada por Apple. Según Gartner, ahora es posible para el empresariado integrar el teléfono iPhone en sus entornos existentes, e incluso adaptar el aparato a éstos, lo que no significa que debe darse al iPhone el mismo acceso que a computadoras portátiles operando con Windows. “Esto se debe a que iPhone no ha sido probado acuciosamente en grandes entornos empresariales aún", indica Ken Dulaney, de Gartner, en un análisis. A juicio del analista, actualmente no hay pruebas de que iPhone pueda ser excluido en caso de ser necesario de las redes empresariales, como es el caso de laptops y otros dispositivos operados con Windows. Por lo tanto, Dulaney sugiere dar un acceso limitado a las funciones de la red, como por ejemplo Exchange y Apple Mail, en tanto que el resto de la red debe ser excluido del alcance del iPhone.“Gran parte de la seguridad informática implica ser consecuente.

Si tienes 2 plataformas, una computadora y un dispositivo de bolsillo, donde uno de ellos incluye varios años de desarrollo en el ámbito de la seguridad, y en la otra tienes un aparato que sólo tiene 1 año de antigüedad, toda la seguridad de la red dependerá del aparto más reciente", explica Dulaney al referirse a su escepticismo frente al popular teléfono de Apple.

Fuente: http://diarioti.com/gate/n.php?id=18058