Security Art Work

Siguiendo con la entrada relacionada con las Declaraciones de Políticas de Certificación, nos queda pendiente detallar el contenido de la RFC 3647.

El documento está estructurado en distintos puntos, en los que se describe la finalidad del mismo, definiciones y comparativas con el estándar anterior (RFC 2527), entre otros. El punto más importante de la misma, y sobre el cual deberíamos centrar nuestra atención es el que describe la especificación de la estructura que debe seguir una CPS; el apartado 4. Se pasa a detallar a continuación los puntos principales de la especificación, junto a una pequeña descripción de los mismos:

• 1 – Introducción: En este punto se describen principalmente los datos de la CA, datos concretos de identificación del documento, implicados en la infraestructura de la PKI, condiciones de uso de los certificados, etc.
• 2 – Publicación de información y repositorio de certificados: Se detalla información respecto al repositorio de información y certificados; dicha información abarca su ubicación, frecuencia de actualización, controles de acceso aplicados, etc.
• 3 – Identificación y Autenticación: Se debe describir el mecanismo empleado para la identificación de los usuarios y los certificados; así como las restricciones aplicables. Adicionalmente se establecen los mecanismos de validación inicial, con validación se entienden las comprobaciones previas a realizar antes de expedir, renovar o revocar un certificado digital, sea del tipo que sea, para asegurar la identidad del suscriptor.
• 4 – Ciclo de Vida de los Certificados: En este punto se detallan todas las medidas o tratamientos establecidos para el tratamiento de los certificados digitales en cualquier punto de su vida; desde la emisión, renovación, revocación, modificación, comprobación de estado, etc.
• 5 – Controles de Seguridad Física, Gestión y Operaciones: En este apartado se detallan las medidas de seguridad aplicadas en el entorno de la CA, concretamente se establecen las siguientes categorías:
  • Controles de Seguridad Física
  • Controles sobre Procedimientos
  • Controles de Seguridad del Personal
  • Controles de Registro de Seguridad
  • Controles sobre Archivo de Información
  • Cambio de Clave
  • Controles en caso de Compromiso de la Clave y Recuperación ante Desastres
  • Finalización de la Actividad de la CA

• 6 – Controles de Seguridad Técnica: En este punto pasamos de centrarnos en controles del entorno de la CA, ahora se realiza una especificación formal de las acciones o medidas tomadas durante el tratamiento de la claves, dispositivos criptográficos empleados, etc.
• 7 – Certificados, OCSP y CRL: Se establece el perfil del certificado, con perfil de certificado entendemos que se establece exactamente que campos debe contener el mismo, así como que campos son variables dependiendo del suscriptor. Así mismo se establecen los requisitos y configuración de los servidores de validación OCSP y CRL (estos mecanismos se describieron en detalle en otra entrada de la serie, concretamente en la que se refiere a Mecanismos de Validación de Certificados).
• 8 – Auditorías de Cumplimiento: En este caso, se describen las prácticas de auditorías de cumplimiento que se han establecido para la CA, las condiciones y periodos en los que se realizará la auditoría, así como la cualificación del personal encargado de su realización.
• 9 – Requisitos Comerciales y Legales: Por último, este punto agrupa desde requisitos legales y comerciales. Lo que incluye desde tasas por la emisión de certificados, medidas concretas sobre datos de carácter personal, responsabilidad financiera en caso de desastre, etc.

Como se puede ver, y como para más de uno que esté familiarizado con la gestión de seguridad de la información, esta especificación tiene en cuenta muchos puntos en común con estándares generalistas de seguridad como ISO 27001; aunque se incluyen más requisitos concretos y propios del tipo de actividad (como la gestión del ciclo de vida del certificado). Hay que entender que una CA es un entorno de muy alta criticidad, ya que si se vulnerara una clave de la misma, podría afectar a gran cantidad de personas o organizaciones; pudiendo llegar a graves perjuicios económicos en las mismas.

Con esto es todo para esta entrada, a modo de ampliación de información os dejo un enlace a una CPS de una Autoridad de Certificación Nacional, la cual se ha construido siguiendo los estándares marcados por la RFC 3467.

Más sobre certificado digital e infraestructura de PKI en próximas entradas. Como siempre, muchas gracias por leernos.

CPS Agencia de Certificación de la Comunidad Valenciana (ACCV) – http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V3.0.pdf

Seguimos teniendo tiempo. Desde aquel famoso Día Mundial de IPv6 de 2011, dónde los principales operadores en internet pusieron en funcionamiento su infraestructura para este protocolo, no se ha vuelto a oír mucho movimiento. Pero sí es verdad que se van planteando posibilidades y se van perfilando opciones de migración. Los tiempos no se han fijado y teniendo en cuenta el alcance global, la cosa va para largo.

Esto no quita que se empiece a plantear y a estudiar cómo enfocar esta migración. Si bien, dependemos de la propia tecnología, ISPs, software de los dispositivos, etc. la mayoría de implicados están poniéndose al día sin dilación y siempre es recomendable entender la situación. Claro está que antes de mover un dedo hay que entender bien los funcionamientos de los protocolos, y ver sus implicaciones tanto a nivel de seguridad, como de gestión y configuración, para estar preparado ante cualquier posible eventualidad.

IPv6 cambia por completo la visión que tenemos de las comunicaciones. El hecho de disponer de una única dirección para encontrar cualquier equipo, sin necesidad de realizar NAT, así como el hecho de tener obligatoriamente IPSEC en el propio protocolo, nos hace rediseñar la base de nuestra visión de las redes. Este protocolo redefine la esencia de las comunicaciones a todos los niveles.

Debemos sentarnos y valorar las implicaciones de este cambio, y plantearnos los primeros pasos para acometerlo. Para simplificar, sin entrar en detalles técnicos, podemos decir que hay 3 modelos de migración a estudiar:

• Doble Pila: Los dispositivos de red soportan ambos protocolos, y utilizan cada uno de ellos en función de la configuración de los destinos. En principio es muy sencillo y escalable, pero implica tener duplicidades que pueden repercutir en la gestión y los recursos de la infraestructura.
• Tunelización: Consiste en encapsular los paquetes IPv6 en paquetes IPv4, de manera que para la mayor parte de la topología IPv4 es transparente, salvo en los extremos dónde se encapsula y se desencapsula el protocolo. Los dispositivos extremos trabajarían como si de un túnel se tratase.
• Traducción: Se requiere una traducción entre protocolos cuando algún dispositivo implicado no soporta, o no contempla uno de los protocolos, generalmente no soporta IPv4. Se requiere un pool de direcciones para asignar en la propia traducción.

Desde mi punto de vista, obviamente dependerá de cada caso, creo que la primera opción sería la ideal. De esta manera tenemos los dos entornos en funcionamiento y podemos ir pasando servicios poco a poco, de manera lo más transparente posible para los usuarios/clientes, los que en el fondo mandan, y a los que no queremos marear nunca más de lo necesario.

Mi intención con esta entrada era recordar que IPv6 cada vez está más cerca, y que hay que empezar a contemplar opciones, que ya están muy trilladas, y no podemos dormirnos en los laureles. Pero que no nos entre el pánico porque en nuestro sector, gracias a Dios, se plantea siempre todo desde el punto de vista de la simplicidad para todas las partes y de la manera más transparente posible de cara a la gestión de servicios.

Lo que está claro a fin de cuentas, viendo cómo avanza la tecnología hoy en día, es que no cabe la posibilidad de quedarnos anclados en el pasado. Si no nos actualizamos, poco a poco iremos perdiendo servicios que solo estarán disponibles para los nuevos protocolos. Y al final sí que nos entrará la sicosis de estar aislados del mundo.

Entre los días 25 y 27 de noviembre de 2013, algunas instituciones públicas europeas fueron objetivo de una oleada de ataques dirigidos muy interesante: para los ataques se utilizaba una infraestructura que ya se había usado en el pasado en otras campañas de malware.

Infección
Como en la mayoría de estos ataques, el vector de infección fue una campaña de spearphising. Los correos tenían un documento de MS Word, el cual contenía un exploit embebido que aprovecha una vulnerabilidad conocida desde 2012, en concreto la vulnerabilidad CVE-2012-0158.

El dominio que aparecía en el campo “FROM” de los correos pertenecía a una de las más renombradas organizaciones humanitarias. Esto hace que los correos puedan parecer totalmente legítimos.

Los asuntos en los distintos correos hacían referencia a fechas cercanas a la fecha del ataque, excepto en uno de los correos, en el que se mencionaba el Top 10 de las ciudades con las mujeres más bellas… bastante tentador.

Fw: 2013-11-27
Fw: Top 10 Cities with the Most Beautiful Women
RV: Teheran 2013-11-25

En los nombres de los documentos adjuntos, aparecían las mismas referencias.

27-11-2013.doc
20131125.doc
Top 10 Cities with the Most Beautiful Women.doc

Gracias a las políticas de parcheo y actualización, el impacto del ataque fue nulo, ya que el documento de MS Word aprovecha una vulnerabilidad antigua que afecta a los controles de ActiveX y permite la ejecución de código remoto. Esta vulnerabilidad fue parcheada en abril de 2012.

Hashes
Al calcular los hashes de los ficheros, se comprobó que se trataba de sólo dos documentos diferentes.

1598f39b5d670eb0149141df7bbcc483
60fd6b6bcf73586284ab8c403c043c6e

Al comprobar estos MD5 en Virustotal, se vio que alguien ya los había subido con anterioridad, por lo que desde ese momento se trataron las muestras como información pública.

A continuación, paso a desglosar resumidamente el análisis. No se trata de un análisis completo de las muestras, sino solamente de la información útil que sacamos para dar la respuesta al incidente.

Las siguientes tablas muestran los ficheros descargados por cada uno de los dos documentos:

He marcado en rojo los ficheros que malwr.com considera maliciosos. Aunque estos ficheros compartan nombre, no comparten los hashes. Más adelante veremos por qué.

Aun así, al cruzar las tablas anteriores, sí que se encuentran varios ficheros idénticos:

La recepción de los distintos correos en una ventana de tiempo tan estrecha y la descarga de una serie de ficheros idénticos al abrir el documento indican que, probablemente, ambos ataques estén relacionados.

Si queréis mirar los análisis más en profundidad, los podéis encontrar en malwr.com en los siguientes enlaces:
1598f39b5d670eb0149141df7bbcc483 @ malwr.com
60fd6b6bcf73586284ab8c403c043c6e @ malwr.com

Dominios
Tras la ejecución de los documentos en cuckoo y la infección de una máquina virtual mediante la ejecución manual de los ficheros con nombre “kav.exe”, se vio que cada una de las muestras se conectaba a un dominio distinto:

yahoo.offlinewebpage.com
link.antivirusbar.org 

Esto explica que, aunque el resto del comportamiento sea igual en ambos ficheros, la firma MD5 sea distinta para cada uno de ellos.

Además, gracias a otra información recibida de fuentes externas, se añade también el siguiente dominio:

ks.pluginfacebook.com

Al realizar peticiones a estos dominios, siempre se recibe la misma respuesta:

HTTP/1.0 200 OK
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html
Date: Wed, 27 Dec 2013 15:23:45 GMT
Accept-Ranges: bytes
Content-Length: 362
X-Cache: MISS from ta-prx21
X-Cache-Lookup: MISS from ta-prx21:3128
Via: 1.0 ta-prx21 (squid/3.1.20)
Connection: keep-alive

<.h.t.m.l.>.
.
.<.b.o.d.y.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.1."
        .>.U.n.d.e.r. .C.o.n.s.t.r.u.c.t.i.o.n.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<.d.i.v. .a.l.i.g.n.=.".c.e.n.t.e.r.".>.<.s.p.a.n. .c.l.a.s.s.=.".s.t.y.l.e.2."
          .>.w.w.w...m.i.c.r.o.s.o.f.t...c.o.m.<./.s.p.a.n.>.<./.d.i.v.>.
.
.<./.b.o.d.y.>.
.
.<./.h.t.m.l.>.
.
.

Al acceder al dominio desde un navegador desactualizado, no se observa ningún comportamiento extraño y la respuesta es la esperada:

Con estos datos, se reafirma la hipótesis de que todo se trata de un mismo ataque.

Atribución
Al hacer whois a los dominios, aparecieron las siguientes direcciones de correo como registradores de dominio:

qingwa20112011[at]163[dot]com
dnsjacks[at]yahoo[dot]com 
usa87654310[at]126[dot]com

Tanto los dominios como las direcciones de e-mail de los registradores de los dominios apuntan a China, como se puede ver en esta lista de e-mails relacionados con ataques dirigidos con origen en China.

Haciendo una búsqueda rápida en Google de los e-mails implicados, se puede ver que la direccióndnsjacks[at]yahoo[dot]com está relacionada con una campaña Mirage, también con origen en China.

Analizando las peticiones vistas en la campaña Mirage y comparándolas con las encontradas en el ataque, se pueden apreciar ciertas similitudes.

A simple vista, se ve que utilizan los mismos campos (“hl” y “meta”). Si además añadimos otra de las peticiones de la campaña analizada por Secureworks, también aparece el campo “q”:

A continuación, se puede ver una imagen resumiendo los resultados de la investigación de la atribución.

Conclusión
Basándonos en los datos obtenidos durante la investigación, se puede concluir que el ataque venía desde China.

Además, si se analizan los receptores de los correos electrónicos, se ve que no solo iban dirigidos a una organización concreta, sino que se apuntaba a varias instituciones europeas.

Se estaba usando una infraestructura utilizada en campañas anteriores. Esto, unido al envío de correos con una gran cantidad de receptores y a la naturaleza del malware Mirage, hace que el ataque no sea silencioso, lo que hace pensar que trataba de robar algún tipo de información concreta de manera rápida (probablemente información financiera).

Este tipo de ataques es bastante común en instituciones públicas y casi siempre utilizan el spearphising como medio de infección. El uso de dominios de buena reputación, como en este caso el de una organización humanitaria muy conocida, legitima ese correo, por lo que hace muy difícil la detección.

Aun así, la prevención de estos ataques suele ser sencilla y venir de la mano de una rápida aplicación de actualizaciones y parches de seguridad, ya que en la mayoría de estos ataques no se utilizan 0days, sino vulnerabilidades conocidas y ya parcheadas. Por ejemplo, en este caso se utilizó una vulnerabilidad con más de un año de antigüedad.

Para detectar si vuestra organización se ha visto afectada por esta oleada, basta con buscar en los logs de navegación si aparece alguno de los dominios mencionados anteriormente.

Espero que os haya sido de utilidad o por lo menos una lectura interesante.

En la primera parte de esta entrada llegamos hasta el punto de sobrescribir registro EIP con el valor que nosotros queríamos. Ahora llega el momento de explotar la vulnerabilidad y ejecutar código.

Recordar que el enlace que me ha sido imprescindible para resolver el ejercicio ha sido la entrada del blog de Kroosec. En esta entrada espero, sobretodo, que quede clara la técnica para crear un ROP en múltiples fases y mostrar cuando nos puede venir bien.

Como en la primera entrada, nos plantearemos preguntas e iremos resolviéndolas hasta llegar a explotar la vulnerabilidad:

1. ¿Contra qué nos enfrentamos?
[Read more…]

Desde la adquisición por parte de google de la empresa Nest, empresa que diseña y crea sensores varios para el control del hogar, me planteo hasta qué punto es necesario tener tantos sensores, y no sólo esto, sino quién tiene acceso a la información que generan.

Obviamente, no critico el tener un detector de incendios en tu propia casa, critico el hecho de que un día haga frío dentro de mi casa y al día siguiente aparezca en mi correo de Gmail publicidad sobre abrigos y bufandas o pastillas para dejar de fumar, en el caso de que estos sensores detecten que fumo plácidamente en mi sofá.
[Read more…]

Es viernes por la tarde y aunque solo son las tres, iniciamos la parada de los usuarios de los sistemas centrales para lanzar los procesos de copias de seguridad, antes del horario habitual, porque vamos a realizar la instalación de una nueva versión del sistema operativo. Está todo planificado y revisado así que hacia la media noche, deberíamos tener las copias de los datos y programas en los carretes de cinta e iniciar la carga del nuevo sistema operativo. Antes ha habido que añadir el salvado de la configuración del sistema, de los perfiles de usuarios, de sus privilegios de acceso y atributos, de las colas de entrada y salida, etc. Todo ello supone un tiempo extra de copias y de recuperación en caso de tener problemas, cosa que el fabricante del sistema nos garantiza que no va a ocurrir.

Habíamos decidido instalar la nueva versión porque habían bastantes problemas de velocidad en los procesos de backup, que se comían la noche, y para poder utilizar las nuevas unidades de cintas de 8mm era necesario saltar a la versión siguiente del sistema operativo. Esperábamos que a partir de ahí, los backups se acortasen y la disponibilidad del sistema para los usuarios mejorase notablemente, como así fue finalmente, sin necesidad de cambiar la CPU, tal como sugería el proveedor, lo requería la aprobación de un presupuesto mayor para la gestión de los sistemas, que la dirección no estaba dispuesta a aprobar. Dado el riesgo que conllevan estas operaciones, habíamos advertido –por escrito- a los usuarios, durante algunos días, de que mantuvieran el control de su información escrita, por si fuese necesario trabajar manualmente en algún momento.

Hacia las once y media de la noche del viernes lanzamos la primera cinta de carga de la nueva versión del sistema. Nos fuimos a comer el bocadillo porque sabíamos por experiencia que este primer paso era bastante largo. La consola iba dando mensajes y finalmente decía “Este proceso puede durar algunas horas o más” y se quedaba tan fresco. Es una muestra de la traducción del Inglés al Español, tan habitual en la época. Hacia las dos de la mañana, a petición del sistema, pusimos la segunda cinta. Todo iba bien hasta que un llamativo mensaje de error de lectura del soporte nos hizo temblar. Tras reintentar varias veces, el proceso continuó, pero la cinta iba y venía adelante y atrás cada vez que leía un trozo y eso era muy mal síntoma, era claro que el soporte recibido estaba dañado. El caso es que a medio día del sábado, decidimos abortar la instalación y dar marcha atrás ya que el proveedor no tenía otra copia del sistema en Valencia y esta no parecía estar en condiciones de continuar instalándose.

Iniciamos la recarga de la versión anterior y pasamos el resto del sábado y la madrugada del domingo en este proceso. Por la tarde recuperamos configuración, usuarios, etc. Ya parecía que todo iba a ir bien, así que antes de terminar, hicimos algunas pruebas para asegurarnos de que en la mañana del lunes, nuestros problemas serían transparentes a los usuarios. Probamos accesos y procesos con las limitaciones que teníamos y confiamos que el entorno de producción estaría en condiciones.

El lunes por la mañana, los usuarios no podían acceder al sistema. Las autorizaciones y los perfiles parecían no trabajar adecuadamente. Iniciamos contacto con el soporte del proveedor para verificar que habíamos hecho la recuperación correctamente y así parecía ser, sin embargo no dábamos con el problema. Para no aburrir, la conclusión fue que una vez iniciada la instalación de ciertos módulos de la versión nueva del sistema, el proveedor advertía de que no podía garantizar la vuelta atrás, es más, no lo recomendaba. Sin embargo nadie lo sabía, al menos en Valencia y claro ahora habría que instalar la nueva versión cuando dispusiéramos de una cinta en condiciones y eso no sería antes del lunes al medio día. El proceso se repitió entonces y el martes a mitad de mañana todo volvió a funcionar correctamente.

Hasta aquí un relato real, como muestra de que aún haciendo el plan perfecto, puede darse el caso de que los sistemas vitales para la gestión de la empresa, no estén disponibles. Y ¿qué hace el usuario en este caso? Yo solo hablaré de mi experiencia y puedo decir que el usuario no está preparado para que le caigan los sistemas de información y en caso de suceder esto, en un breve plazo se queda bloqueado.

¿Es que el usuario es un irresponsable o un incompetente? NO y rotundamente NO. Lo que ocurre es que conforme los sistemas de proceso de la información lo permiten, la complejidad de los mismos crece y se eliminan elementos esenciales para realizar el trabajo sin ellos, léase personal suficiente para gestionar el negocio a mano, para prevenir cada paso del mismo y documentarlo, para hacer pruebas y entrenar a la gente que procesa la información, para disponer de información alternativa en otros soportes que le permitan organizarse rápidamente y seguir atendiendo a sus clientes sin impacto importante en ellos, etc.

Cuando sucedió lo que he relatado, la dirección de la empresa me llamó para una reunión de crisis. Después de tratar de explicar en lenguaje llano los tecnicismos del problema, y probablemente sin que estuvieran convencidos de que estas cosas pasan hagas lo que hagas para evitarlas, mi pregunta fue: ¿Cuánto le cuesta a la compañía en ventas un día de parada de sistemas? La respuesta era que el impacto es poco sobre el cliente si son solo 24 horas, pero es importante a partir de ahí y crítico si llega a durar 72 horas o más. Entonces ¿debemos asegurar la disponibilidad de sistemas con un margen de parada de 24 horas? pregunté al comité de dirección. SI CLARO, eso es imprescindible, no podemos permitirnos trabajar sin sistemas más de un día entero. Recordarles mi propuesta de mejora de la seguridad y disponibilidad de los sistemas fue fácil porque la tenían hacía meses en un cajón y ahora tendrían que reconsiderarla. Se aceptó un nuevo presupuesto, se instaló un sistema redundante (MIMIX en aquella época) y se mantuvo una copia en línea de las bases de datos y librerías de programas. Desde entonces las crisis tecnológicas dejaron de tener impacto directo en la actividad de los negocios, pero el plan de recuperación de desastres empezó a figurar en la agenda de todos los departamentos ya que siempre pueden darse circunstancias en las que el usuario tendrá que tomar acciones para continuar trabajando, pues el fallo tecnológico es tan solo uno de los posibles problemas que se pueden presentar. Catástrofes naturales, incendio o inundación de locales, o hasta una enfermedad contagiada a la plantilla, son ejemplos de situaciones de riesgo en las que el día a día no permite pensar pero que pueden hacer caer las cifras de un negocio si no se ha previsto como actuar en los casos de crisis.

Los departamentos o personas responsables de la organización de las empresas deben diseñar e implementar los procedimientos necesarios para dar respuesta a las situaciones de crisis y para ello, hay metodologías cuyo uso es necesario y expertos en la materia, cuya participación es recomendable si se desea garantizar un cierto nivel de seguridad en la continuidad de los negocios. Implementar el plan de recuperación de desastres, auditarlo y probarlo periódicamente es la mejor manera de garantizarse la supervivencia ante las crisis no previstas.

Sabemos que las MIFARE Classic están totalmente rotas, como hemos podido comprobar en los posts anteriores de esta saga. Las claves de lectura y escritura de las zonas de memoria son fácilmente recuperables. Ahora nos queda enfrentarnos al último bastión de las tarjetas: el Unique Identification Number (UID).

En el Sector 0 Block 0 de la tarjeta, conocido como el Manufacturer Block es donde podemos encontrar almacenado el identificador único de la tarjeta o UID.

Ese UID es el número de serie de las MIFARE. Cada tarjeta tiene el suyo propio, consta de 4 bytes, y en principio es de sólo lectura.

Por eso las implementaciones que aún se basan en las MIFARE Classic confían en ese número para identificar los usuarios. Podemos fácilmente encontrar sistemas de ese estilo en puertas de acceso y en parkings por ejemplo.

[Read more…]

En esta entrada dentro de la serie de Fundamentos sobre Certificados Digitales nos vamos a centrar en uno de los requisitos fundamentales a tener en cuenta por cualquier Autoridad de Certificación (CA). Este requisito no es una opción, sino una obligación establecida para cualquier normativa o legislación aplicable relativa a la generación y tratamiento de certificados digitales. Estamos hablando de las Declaraciones de Prácticas de Certificación y de las Políticas de Certificación. Como siempre, vayamos paso a paso.

Una Declaración de Prácticas de Certificación (CPS) es un documento propio de cada CA en el que se declaran y establecen un conjunto de compromisos que adquiere la entidad respecto las prácticas para la gestión del ciclo de vida de los certificados digitales que emite, así como un conjunto de medidas de seguridad del entorno. Este documento es en sí un compromiso adquirido, que se referencia al mismo en todos los certificados emitidos en un campo establecido a tal efecto (en próximas entradas detallaremos la estructura estándar de los certificados).

Por otro lado, una Política de Certificación (CP) es del mismo modo un conjunto de compromisos adquiridos por la CA con los usuarios de sus certificados, aunque en este caso, este documento únicamente hace referencia a un tipo concreto de certificados dentro de la jerarquía. Por tanto la Política de Certificación únicamente afecta a una tipología concreta de certificado de CA Subordinada (este concepto se explica de forma detallada en otra de las entradas de esta serie, concretamente la que hace referencia a Cadena de Confianza). Este mecanismo le facilita a la CA la capacidad de establecer unas directivas de certificación globales y comunes mediante la Declaración de Prácticas de Certificación, así como la posibilidad de establecer requisitos concretos para tipos de certificado concreto cuando proceda.

Es importante destacar que en ningún caso es una obligación la implementación de Políticas de Certificación, por lo que se deja a elección de la CA su implementación en base a sus requisitos y necesidades.

El siguiente punto a abordar será, evidentemente, establecer o identificar los contenidos y requisitos que deben cumplir estos documentos. A este respecto, y comenzando por el ámbito Español, la Ley de Firma Electrónica (Ley Orgánica 59/2003) en uno de sus artículos menciona la obligación de construir y mantener publicada en un medio gratuito una Declaración de Prácticas de Certificación. Se puede obtener más información de la presente ley en pasadas entradas de esta serie Ley de Firma Electrónica I y II. Según dicho texto, el documento que debe cumplir al menos con los siguientes requisitos:

• Obligaciones del Prestador de Servicios de Certificación (CA) respecto a los datos de creación y verificación de la firma o certificados expedidos.

• Condiciones para la solicitud, expedición, uso, suspensión y extinción dela vigencia de los certificados.

• Medidas de seguridad técnica y organizativa.

• Roles y responsabilidades del personal implicado en el servicio.

• Condiciones y acceso a mecanismos de información sobre la vigencia de los certificados.

Como último punto determinante, se establece que las Declaraciones de Prácticas de Certificación tendrán validez como Documento de Seguridad en el ámbito de la Ley Orgánica de Protección de Datos de Carácter Personal (Ley Orgánica 15/1999). Sin embargo, y como a más de uno le puede haber parecido, esta especificación es muy generalista, por lo que para alguien que no tenga experiencia en la confección de este tipo de documentos dentro del ámbito de la constitución de una CA puede llegar a ser muy complicado y ambiguo.

Adicionalmente a los requisitos legales establecidos en España, a nivel internacional se han establecido distintos estándares destinados a establecer requisitos mínimos de calidad y seguridad en la implementación y operación de una Infraestructura de Clave Pública (PKI), así como del establecimiento de una CA. Para el caso que nos ocupa, la confección de una Declaración de Prácticas de Certificación, se han establecido diversos estándares, se destacan los siguientes:

• RFC 3467 y RFC 2527: Estos documentos llamados RFC, establecen una guía estricta de los puntos que debe contener una Declaración de Prácticas de Certificación. El primero de ellos, la RFC 3467, se incluye dentro del denominado “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”, propuesto por el “Network Working Group”. Relata con un elevado nivel de detalle los contenidos y estructura que debe tener el documento, y se considera un estándar internacional para la construcción de CPS. El segundo de ellos (RFC 2527) es una versión anterior de la RFC 3467, de los que únicamente se identifican algunas modificaciones.

• WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria: Del mismo modo que en el caso anterior, la especifiación establece un guión cerrado para los contenidos de una Declaración de Prácticas de Certificación, aunque en este caso se ha establecido por organismos distintos. Concretamente, los responsables de esta especificación son dos organismos estatales en primer lugar el “Canadian Institute of Chartered Accountants” (CICA), y en segundo lugar el “American Institute of Certified Public Accountants” (AICPA). A su vez, es importante destacar que estos organismos son responsables del estándar Webtrust, que marca directivas para la implantación de controles en las CA que regulan desde el ciclo de vida de los certificados digitales hasta las medidas de seguridad a aplicar en su entorno; entre otros puntos.

Nos vamos a centrar en la especificación establecida por la RFC 3467, que en mi humilde opinión, es la de uso más extendido en lo que a CPS se refiere. Dado que se trata de una especificación muy detallada y concreta, se va a abordar a grandes rasgos; así como finalmente, y con el fin de completar la información de esta entrada, se propondrá la lectura (o al menos el repaso), de un ejemplo real de Declaración de Política de Certificación. La especificación de la RFC 3467 se encuentra publicada en el siguiente enlace:

http://www.ietf.org/rfc/rfc3647.txt

En la próxima entrada detallaremos a grandes rasgos el contenido de la RFC, así como mostraremos un ejemplo real de CPS. Muchas gracias por leernos.

Hace ya un tiempo que estamos pensando alguna manera de mejorar en la detección de Malware y APTs y se nos ocurrió montar una sandbox que analizara ficheros automáticamente y nos generará un informe con los datos.

Esta idea no es nueva, es más algunas de las mejores marcas del sector ya ofrecen soluciones de este tipo. También existe una solución gratuita de sandbox.

Básicamente lo que hace este tipo de sandbox es ejecutar ficheros en una máquina virtual y generar informes de los cambios y conexiones que se realizan en este sistema. Una vez ejecutado el fichero la máquina virtual vuelve al estado inicial.

A continuación vamos a ver la instalación y configuración básica de esta sandbox.

[Read more…]