?

Log in

No account? Create an account

Directo desde el Vaticano...

hit counter




"No sabemos qué sistema operativo usa Dios, pero nosotros usamos Linux"
Hermana Judith Zoebelein
Webmaster del Vaticano
Seguir a @facemar en Twitter

Fernando Acero Martin

Crea tu insignia

Licencia Creative Commons

Blog Fernando Acero por Fernando Acero Martín se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. El presente blog no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento, tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor.

Se permite la copia textual, la traducción y la distribución de los artículos del presente blog en cualquier medio, a condición de que este aviso sea conservado, no se modifiquen.

Se permite la cita.

El autor no cobrará por el ejercicio de los dos derechos anteriores, siempre que no se haga uso comercial de los mismos.

No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre.

Basada en una obra en fernando-acero.livejournal.com.
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."







Poco a poco, las organizaciones están implementando sistemas de calidad y de seguridad del código fuente, con un mayor o menor alcance. Algunos se conforman con utilizar sistemas de análisis estático de código fuente y otros van más lejos, llegando a realizar fuzzing de sus aplicaciones más críticas. Pruebas de caja blanca, gris y negra, complementan los test funcionales, para garantizar la seguridad del código. Dicho lo anterior, podemos decir, con toda seguridad, que el concepto de programación segura no es ajeno a muchas empresas fabricantes de software.

Simplificando mucho, podemos decir que un programa funciona adecuadamente, cuando recibe una entrada esperada y se comporta de forma predecible y podemos decir que es seguro, cuando recibe una entrada no esperada y también se comporta de forma predecible. Es lo que denominamos un adecuado manejo de excepciones, el santo grial de la programación segura.

Ahora bien ¿qué es la programación defensiva? pues es cuando un programa es seguro, es decir, gestiona adecuadamente todas y cada una de las excepciones posibles y además genera un log avisando de dicha contingencia. Dicho de otro modo, es una forma adecuada de explotar con fines de seguridad, nuestro notable esfuerzo en encontrar y gestionar adecuadamente cada una de las excepciones que pueden afectar negativamente a nuestro programa.

Ya he hablado de la problemática asociada al aumento del tráfico cifrado y de lo lo interesante que es explotar todas las capas del estándar OSI, siendo la información obtenida más útil para el análisis de seguridad, cuanto más cercana es la capa al usuario.

Por lo tanto, un forma de paliar de alguna forma la pérdida de visibilidad de la capa de presentación por el uso de SSL/TLS, es potenciando la información disponible en otras capas y la de aplicación, es una de las más interesantes, por ser la más cercana al usuario.

A pesar de lo evidente del concepto y lo sencillo y rentable que es su implementación, lo cierto es que no todas las aplicaciones generan logs con las excepciones que gestionan y eso es un problema que pone las cosas muy complicadas a los responsables de seguridad a la hora de correlar eventos.

Una de las cosas más interesantes de la programación defensiva, es que nos permite anticiparnos a un ataque efectivo. Pensemos por ejemplo, en el último fallo del iLO4 de HP, bastaba este mandato para tener acceso sin autenticación a la gestión del sistema en remoto:


curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Bien, hasta encontrar el fallo, el atacante ha tenido que probar muchas veces, un escenario de prueba y error, lo que podría ser detectado como un Indicador de Ataque (IOA) en nuestro sistema, aunque estuviera parcheado adecuadamente o se estuviera gestionando esa excepción (por ejemplo, podemos guardar en nuestro log, que se ha recibido una cadena de 26 caracteres idénticos, cuando el programa espera una cadena que cumpla determinadas reglas de construcción de la cadena y que la cadena tiene que ser de menor tamaño).

Es decir, cuando tenemos un IOA, tenemos algo mucho mejor que un IOC, que es un Indicador de Compromiso, y que lo que nos dice realmente, es que alguien ha ya vulnerado nuestro sistema y que nos toca recuperarlo y remediar los daños.

Los IOA nos permiten una defensa proactiva y reactiva, ante los primeros intentos sin éxito de un atacante, por lo que debemos intentar obtener el mayor número posible de dichos IOA, para correlar adecuadamente y rápidamente, los ataques en curso, antes de que tengan éxito.

El concepto de programación defensiva, se podría mejorar fácilmente, por ejemplo, si además de crear un log con las excepciones que gestiona el programa, nos avisa en las aplicaciones WEB, de las inconsistencias entre los datos incluidos interfaz de usuario y la validación de los mismos, antes de guardarlos en la base de datos. Con ello, la programación defensiva también nos puede proporcionar IOAs, ante ataques contra la lógica de negocio, como por ejemplo, los ataques producidos por Burp Suite actuando como HTTP proxy, o en modo scanner e intruder.

Eso es algo parecido a correlar que alguien intenta atacar por fuerza bruta un servidor SSH, o que está haciendo un escaneo de puertos, pero aplicado a las aplicaciones, si lo detectamos al principio, sabemos que algo está pasando, es eso es lo bueno de un IOA.

Si además se lograse una taxonomía adecuada de IOAs asociados a determinados ataques tipo a la capa de aplicación, podríamos detectar los intentos de ataque con más rapidez y precisión.

El efecto sería como quemar el pajar para encontrar la aguja, lo contrario a intentar buscar una aguja en un pajarcmediante bigdata y data minning, en los correladores de eventos con bases de datos monstruosas, lo que requieren grandes recursos de máquina, aplicaciones complejas y un tiempo precioso, que no siempre se tiene ante un ataque en curso.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."







En 2017 Google dijo que la mayor parte del tráfico de su navegador Crome ya era cifrado. Posteriormente, en un intento de aumentar estas cifras, a partir de julio del presente año, Crome también marcará como inseguras todas las páginas web que no usen https. Pero junto con el tráfico web, hay otras muchas conexiones que se están haciendo cifradas desde hace tiempo, como por ejemplo el correo electrónico. Con ello, estamos perdiendo la posibilidad de saber lo que pasa realmente en la capa de presentación del estándar OSI, que es la que soporta el SSL/TLS.

Aquí he de decir dos cosas. La primera, es que el poder acceder y explotar la información presente en todas las capas del estándar OSI, es fundamental para una defensa en profundidad de los sistemas. La segunda, es que cuanto más cerca del usuario esté la capa OSI, más información interesante podemos obtener para la seguridad, especialmente, de las capas de aplicación, de presentación, sesión y transporte.

No cabe duda de que el cifrado de todas las comunicaciones es una enorme mejora en la privacidad de los usuarios, pero también hemos de tener en cuenta, que tiene un enorme impacto en la seguridad de las organizaciones, puesto que cuando el tráfico es cifrado, los sistemas perimetrales no pueden saber si lo que entra y sale de la organización es bueno o malo, propiciando la entrada de código malicioso, o la salida de datos sensibles. Además, al perder una gran cantidad de información útil de la capa de presentación, la correlación de eventos de seguridad se hace mucho más complicada.

En esta situación, disponer de un buen "endpoint", con capacidades avanzadas como Protección Contra la Pérdida de Datos (DLP), Protección Contra la Intrusión (HIPS), filtrado de spam, antivirus con sandbox, o control de dispositivos, se convierte en una necesidad crítica para la seguridad de la organización. Es decir, que de una seguridad centrada en los perimetrales con control de la capa de aplicación, que era relativamente cómoda de gestionar, volvemos a un concepto de seguridad descentralizada basada en endpoints, que es mucho más complicada de gestionar.

Para evitar este problema, algunos fabricantes de equipos de protección de perímetro, como cortafuegos o proxies de gama media o alta, permiten la ruptura del túnel SSL/TLS. Para ello, proporcionan un hardware lo suficientemente potente, como para poder realizar, sin penalizar el tráfico, este trabajo intensivo de descifrado, análisis y posterior cifrado de las comunicaciones. Como es lógico, este incremento en la capacidad de proceso y en las funcionalidades de los equipos, se materializa en un precio sensiblemente superior al de los equipos que no permiten la ruptura del túnel. ¿Pero nos vale la pena? ¿Funciona bien esta funcionalidad?. Lo que está claro, es que hay guías de seguridad que recomiendan activar la ruptura de túnel SSL/TLS en nuestra organización, si se tiene disponible esta posibilidad.

El funcionamiento es sencillo, el dispositivo de protección de perímetro dispone de una Autoridad de Certificación (CA) integrada y a partir de ella, se generan unos certificados, que hay que instalar en todos los sitios en los que sea necesario, por ejemplo, en el almacén de certificados de los navegadores, de los clientes de correo, de máquina virtual JAVA y en el caso de Linux, en el almacén de certificados propio del sistema operativo, o de lo contrario, tendremos problemas a la hora de actualizar nuestros sistemas.

Dicho de otro modo, el sistema de ruptura de túnel SSL/TLS se comporta como un Man in the Middle (MitM), que rompe el túnel para poder analizar el tráfico entrante y saliente de nuestra organización en búsqueda de amenazas y luego lo vuelve a cifrar, para garantizar la confidencialidad de las comunicaciones.

A pesar de que todo parece sencillo, mi experiencia de campo no ha sido todo lo buena que esperaba con esta funcionalidad. Por ejemplo, a pesar de incluir el certificado en el almacén de mis sistemas Linux, he sufrido la ruptura del sistema de paquetes en varias ocasiones, por problemas de conexión a algunos repositorios. Básicamente, algunos repositorios no eran visibles para mis sistemas Linux, cuando estaba activada la ruptura del túnel SSL/TLS.

Pero el problema de fondo es mucho más grave, aún sin entrar en escabrosas consideraciones, que darían para varios artículos, relacionadas con la legislación de protección de datos y los lógicos temores por parte de los usuarios, de que su tráfico esté siendo monitorizado. Algo que permite hacer esta tecnología, tal como avisan algunos fabricantes en sus manuales.

Creo que el problema más grave es que la CA que genera el cortafuegos no es una CA de verdad, por lo que sus certificados no son "trusted" por defecto y no están en donde deben estar, es decir, con todos los certificados de las CA que sí cumplen con todos los requisitos para serlo. Por ello, estos certificados se han de instalar a mano en el área de usuario y editar su confianza también a mano, lo que crea problemas de seguridad bastante preocupantes, sobre todo, si nuestros usuarios no son muy avanzados.

Además, instalar el certificado en todos los sitios en los que debe estar, no es una tarea rápida ni sencilla. Si se nos olvida en algún sitio, habrá cosas que no funcionarán adecuadamente y cuando hablamos de actualizaciones fallidas, estamos hablando de fallos graves de seguridad y de posibles problemas de continuidad.

Veamos un problema típico tras activar la ruptura del túnel SSL/TLS. Tras instalar en el área de usuario el certificado de nuestro cortafuegos en un Android 8.0.0, tanto en la parte personal, como en la de trabajo (correspondiente a la Carpeta Segura), cada vez que nos conectemos a la WIFI del trabajo e intentemos bajar el correo corporativo desde la Carpeta Segura, nos aparecerá el siguiente mensaje, que para un usuario concienciado y debidamente formado en ciberseguridad, debe ser bastante inquietante:

"Certificado no seguro para: XXXX@XXX.es. El certificado no proviene de una entidad de confianza. Si continua con este certificado, es posible que la seguridad de sus correos electrónicos y de su cuenta se vea comprometida."

Seguido de las opciones Ver, Cancelar o Continuar.

Aquí está el problema, ante un mensaje que aparece todos los días y varias veces en el teléfono, muchos de los usuarios pulsarán directamente Continuar, sin comprobar que el certificado es el que tiene que ser, quedando claramente expuestos a un ataque de Man in the Middle (MitM), en el caso que acepten un certificado falso. Y si pulsan Ver, que es lo más seguro, la única información fiable para saber si es el certificado correcto o no, comprobar el SHA-256 del mismo, algo que es complicado de recordar y verificar cada vez que nos salta el mensaje.

Además, de vez en cuando, cuando activemos o desactivemos interfaces de comunicación y cambiemos al mismo tiempo de entorno, por ejemplo, al desactivar la WIFI y activar, los datos en el teléfono, nos aparecerá un aviso de que tenemos un certificado instalado a mano, y que eso puede afectar a la seguridad de nuestras comunicaciones.

La mejor solución, es que los fabricantes de dispositivos de seguridad perimetrales, con capacidad de ruptura del tunel SSL, se lo tomen en serio y creen CA's que cumplan con todos los requisitos necesarios, para que sus certificados puedan incluir por defecto en el área de sistema junto con los de otras CA "trusted".

Mientras que eso no ocurra, tendemos que formar y concienciar a los usuarios para que la ruptura del túnel SSL/TLS, no sea un problema más grave del que quiere evitar.

Pero también debemos considerar que también será necesario manejar excepciones. Habrá tráfico que no se podrá romper sin crear problemas, como es el caso de los servidores de actualización de algunos sistemas, o tráfico personal de los usuario a lugares "trusted", como banca, administración pública, correo personal, etc. Para ello, en lugar de listas nominales, sería mejor disponer de sistemas basados en categorías, por ejemplo: "banca online" en lugar de tener que enumerar todos los bancos y luego, si es necesario, eliminar los bancos que no se desee mediante listas negras nominales.

Pero si profundizamos más, podemos tener otros problemas de seguridad cuando activamos esta tecnología, por ejemplo:

a) "Forward proxy decryption" puede que no funcione cuando hay autenticación mutua.

c) En algunos casos, por problemas de soporte de TLS 1.2, se puede producir un downgrade a un inseguro TLS 1.1, con todo lo que ello supone para la seguridad de las comunicaciones. Recordemos que TLS 1.0 y TLS 1.1 estaban "deprecated" en enero de 2018 por sus problemas de seguridad.

d) Puede haber esquemas de cifrado no soportados, por ejemplo, AES128-GCM-SHA256 o AES256-GCM-SHA256, que forman parte de TLS 1.2.

e) Finalmente, es posible que no se puedan descifrar las sesiones en la se use un intercambio de claves Diffie-Hellman para "Forward Proxy Decryption".

En base a lo anterior, si somos unos atacantes, vemos que hay mecanismos para poner la cosas complicadas al sistema que está haciendo la ruptura del túnel SSL/TLS, ya sea para que no funcione, o para forzar un peligroso downgrade de protocolo.

Por lo tanto, creo que antes de proceder a la ruptura del túnel SSL/TLS, es conveniente realizar un análisis detallado de las ventajas e inconvenientes, incluyendo en el estudio, las posibles alternativas para paliar los problemas del cifrado en la capa de presentación, como por ejemplo, la mejora de los endpoint y la implantación de un sistema de eficaz, para facilitar la gestión de los mismos de forma centralizada.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

No hay mucho escrito sobre la mejor forma de atacar un sistema de mando y control, lo que sería aplicable a entornos militares, o civiles, como infraestructuras críticas, sistemas de control industrial, o incluso, barcos o aeronaves.

Ahora que el CCN ha publicado un informe sobre ciberamenazas en el sector salud, en el que se destaca la enorme vulnerabilidad que supone la obsolescencia en estos sistemas críticos (principalmente por el uso masivo de sistemas operativos obsoletos y sin soporte del fabricante, como Windows XP), creo que puede ser interesante hablar sobre los ataques al decisor, o el síndrome de la UVI conectada.

Imaginemos una UVI en la que todos los sistemas de monitorización médica disponen de interfaz de red, y se encuentran conectados a un sistema de mando y control, donde el personal de guardia vigila a los pacientes.

Para hacer más realista el entorno, dicho sistema está conectado también a la red de propósito general del hospital, para acceder a otros servicios básicos del hospital, como la farmacia, historiales clínicos, administración, etc. En este entorno tan exigente, hay protocolos médicos, con unos tiempos de reacción muy definidos, y que en muchos casos, son públicos, lo que podría facilitar las cosas a un posible atacante.

Supongamos que el tiempo que transcurre entre que salta una alarma de azúcar alto en un paciente, hasta que el médico de guardia le inyecta una dosis masiva de insulina, son 20 segundos. Ese es el tiempo preciso que ha de estar activo el malware en el sistema.

Hablamos de un malware sin archivo y sin persistencia, ya que los sistemas de la UVI, como es lógico, están permanentemente conectados a la red eléctrica y a la red de monitorización, por lo que también se puede autoeliminar del sistema sin dejar rastro.

Supongamos también, que ese malware genera una alarma de azúcar alto en un paciente y que a los 20 segundos exactos, modifica el histórico de lecturas de azúcar a valores normales y finalmente, se autoelimina de la memoria del sistema.

En ese tiempo de 20 segundos, el médico de guardia habrá activado el protocolo de emergencia, e inyectado una dosis adecuada de insulina al paciente, lo que le habrá provocado un grave coma diabético.

Una vez abierta la investigación, para los responsables de la misma, parecerá claro que el médico se ha equivocado, o que ha intentado matar al paciente, minando gravemente su prestigio y credibilidad.

Los ataques de decepción, orientados a atacar al decisor, son muy peligrosos ya que provocan un daño, encubren el origen y pueden repetirse varias veces, hasta que haya datos suficientes como para considerar que está ocurriendo una anomalía estadísticamente poco probable.

Está claro que es mucho mejor atacar a un sistema de mando y control aéreo engañando sobre la posición real de los aviones, que bloqueando completamente el sistema, ya que en primer caso, se puede usar el ataque varias veces sin que el decisor sea consciente de que está ocurriendo algo raro y que está tomando decisiones equivocadas.

Alguien puede pensar que ese escenario de la UVI conectada es improbable, pero se tiene la certeza de que se ha utilizado en la central nuclear de Natanz (Irán) y se tiene la sospecha de que puede haber sido utilizado en otra ocasión, provocando varios choques de buques de guerra estadounidenses en el Pacífico, algo que estadísticamente era improbable.

Tal como narra la periodista Yolanda Quintana, en el capítulo 4 de su excelente libro titulado "Ciberguerra", hubo un Stuxnet 0.5, que poca gente conoce. Dicho malware tenía como misión retrasar el programa nuclear iraní, y socabar el prestigio de los científicos responsables del mismo, lo que lo retasaría todavía más. Desde mi punto de vista, algo más sutil, refinado y efectivo que, lo que hizo la versión 1.0 de Stuxnet destruyendo físicamente las centrifugadoras, algo muy evidente y que hizo sospechar rápidamente que algo raro estaba pasando en la planta.

Stuxnet 0.5, fue subido de forma anónima a la plataforma de análisis de malware VirusTotal en 2007, pasando desapercibido por todo el mundo. La versión 0.5 de Stuxnet, que como la versión 1.0, iba dirigido a los sistemas SCADA de Siemens que controlaban la instalación nuclear iraní, variaba la presión del gas de hexafluoruro de uranio en las centrifugadoras, para reducir drásticamente la producción de uranio enriquecido de la central. En julio de 2009, el Presidente de Irán aceptó la dimisión de Gholam Reza Aghazadeh, que era el jefe del programa nuclear de Irán, al parecer, por el fracaso de su gestión.

Es decir, Stuxnet 0.5, además de lograr un retraso de dos años en el programa nuclear de Irán y sin que nadie se diera cuenta de que estaba pasando algo raro en la planta, también logró minar, de forma drástica y definitiva, la credibilidad del decisor, lo que lo retrasó todavía más el programa nuclear iraní, mientras se buscaba un sustituto.

Este malware tan sofisticado y sutil, estaba diseñado para desactivarse automáticamente el 4 de julio de 2009, fecha muy cercana a la dimisión de Gholam Reza. Es decir, que nos encontramos en un caso que bien lo podemos asimilar al síndrome de la UVI conectada del que hemos hablado al principio.

Este tipo de ataques también son muy peligrosos en el entorno aeronáutico, cuando los pilotos (decisores), están acostumbrados a la enorme fiabilidad del vuelo automático.

Si un malware logra engañar al piloto, por ejemplo, desconectando el piloto automático sin que él lo sepa, o desconectando inadvertidamente el sistema automático de control de potencia de los motores, hay muchas probabilidades de que el piloto no se cuestione ese hecho, y el vuelo acabe en desastre. Hay un caso documentado de este tipo de comportamiento de los pilotos, que aunque no fue provocado por malware, ilustra muy bien lo que puede pasar cuando el decisor es "engañado" y tiene una fe absoluta en la fiabilidad del sistema.

Se trata del vuelo 214 de Asiana Airlines, que se estrelló el 6 de julio de 2013 en la aproximación al aeropuerto internacional de San Francisco. La investigación de la NTSB demostró que el piloto había usado una secuencia de comandos inusual, que tuvo como consecuencia la desconexión del sistema que controla automáticamente la potencia de los motores. Dicho sistema mantiene una determinada velocidad del avión, a un determinado ángulo de ataque, haciendo que el piloto pueda volar por posiciones de morro y se pueda olvidar del mando de gases.

El piloto de Asiana, que había realizado la mayoría de sus horas de vuelo en modo automático, tenía fe absoluta en el sistema, y no fue consciente de que el avión no iba a corregir la potencia de los motores, hasta que fue demasiado tarde, y tocó el suelo de forma catastrófica antes de llegar a la pista.

Ese mismo efecto ocurría si un determinado malware desconecta el sistema de control automatico de potencia y además, como hizo Stuxnet 0.5, falsea la información visual del estado de los sistemas, para que el piloto no sea consciente de que se ha desconectado dicho sistema.

Para complicar las cosas, el malware podría forzar que dicha información no se refleje en las cajas negras, para que en la investigación parezca que el accidente ha sido un fallo del piloto.

Es evidente que tendrían que ocurrir varios accidentes similares, en un determinado tiempo, para que alguien sospechase que algo raro estaba pasando y se pusiera a investigar.

Por ello, es muy importante que los sistemas críticos estén debidamente actualizados, con todo el hardware y software con soporte de los fabricantes , que dispongan de los mecanismos de seguridad adecuados, y que sus usuarios sigan escrupulosamente los procedimientos operativos de seguridad, de forma que se minimice la posibilidad de ser afectados por una amenaza desconocida, especialmente dirigida a nuestro sistema y que no pueda ser detectada o neutralizada por los sistemas automáticos de seguridad.

También hay que tener en cuenta que un ataque al decisor que esté bien diseñado, es casi tan complicado de detectar para un equipo de ciberseguridad, como los sucesos aleatorios de corta duración. Por ejemplo, exfiltraciones de datos mediante peticiones DNS falsas. Por lo que es necesario arbitrar mecanismos de detección eficaces, que pongan en evidencia este tipo de anomalías en sistemas críticos.

Mi recomendación es mantener unas estadísticas precisas de la normalidad y e investigar a fondo, cualquier cosa que se desvíe de dicha situación de normalidad. Los valores simulados de normalidad, no se van a corresponder con valores reales de esa misma normalidad, lo que nos puede hacer sospechar.

En otra ocasión hablaré de la ley de Benford, o la Ley del primer dígito, que se puede extender a tercero, al cuarto, etc y que nos puede ayudar a encontrar este tipo de anomalías altamente escurridizas en nuestros sistemas de mando y control.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Cuando se gestionan eventos e incidentes de seguridad, lo peor que nos puede pasar es tener un falso negativo, es decir, una ciberataque con éxito, pero también hemos de temer los falsos positivos, puesto que nos hacen perder mucho tiempo de análisis y es necesario disponer de una adecuada capacidad para identificarlos y eliminarlos.

Cuando hablamos de falsos positivos, hemos de tener en cuenta la paradoja del falso positivo (https://es.wikipedia.org/wiki/Paradoja_del_falso_positivo).

Supongamos que tenemos que encontrar una aguja en un pajar, es decir, 1 aguja entre 10.000.000 de briznas de paja y alguien nos vende un sistema de detección de agujas entre la paja, con una fiabilidad del 99%, lo que a simple vista, y sin pensarlo demasiado, parece que es algo estupendo para lograr nuestro objetivo, en realidad es una pesadilla.

Lo cierto es que ese sistema nos proporcionará la no desdeñable cantidad de 99.999 falsos positivos, para encontrar la aguja en el pajar. Es decir, que entre los 100.000 positivos que nos proporcionará el sistema, la posibilidad de que falle la detección, es de un nada despreciable 99,9999 %. Dicho de otro modo, tendremos que revisar 100.000 muestras, una por una, para encontrar la aguja.

Pensemos ahora en el número de muestran que procesan diariamente nuestros sistemas de detección de malware. Aplicado lo anterior a la ciberseguridad, lo que quiere decir, es que nuestros sistemas de detección han de ser muy fiables, teniendo una tasa baja de falsos negativos y una tasa muy muy muy baja, de falsos positivos. Si no es así, sobrecargaremos nuestra capacidad de análisis de malware y forense, para poder discernir de forma fiable, lo que es un falso positivo y lo que es un positivo real.

Asimismo, si no podemos "adiestrar" nuestro sistema de seguridad para que sea capaz de ir aprendiendo lo que es un falso positivo y un falso negativo, estaremos condenados a tropezar con la misma piedra una y otra vez, entrando en un círculo vicioso del que es muy complicado salir. Dicho de otro modo, de nada nos sirve un sistema de detección de malware, si no tenemos una adecuada capacidad de gestión de los falsos negativos y de los falsos positivos.

Hace unos meses me mostraron un sistema con varios motores de detección de malware, en teoría muy fiables todos ellos. La idea era hacer un triaje inicial de las muestras sospechosas en el laboratorio forense. Pero ¿qué hago que uno de los motores con buena reputación me marca una muestra como positivo y los otros no?. Recordemos que el WannaCry solamente era detectado por unos pocos motores al principio. Cuando hice números con los datos que me proporcionaron, descubrí que dicho sistema iba a crearme más problemas que beneficios, y que era un ejemplo bastante claro de la paradoja del falso positivo.

Cuando usamos un sistema de detección para hacer triaje en el laboratorio forense, es necesario saber muchas cosas de él, como por ejemplo, los criterios utilizados para añadir las firmas nuevas y para eliminar las viejas, o los mecanismos usados para determinar que una muestra es un positivo, con los sistemas eurísticos o de sandbox que utiliza, algo que no siempre proporcionan de forma clara, estandarizada y consistente, los fabricantes de soluciones de detección de malware.

Si el sistema de detección funciona como un mero semáforo, y no nos proporciona información adicional, que nos ayude a decidir ante un positivo, no vamos a tener más remedio que recurrir a un análisis detallado de la muestra en el laboratorio forense, para estar seguros de que es un archivo malicioso, especialmente, si el positivo nos aparece en un archivo que consideramos que es necesario para el normal funcionamiento de nuestros sistemas.

Esto nos lleva a otro consejo importante. Hemos de ser muy cuidadosos a la hora de hacer cambios de configuración en nuestros sistemas de detección como por ejemplo, en los endpoint, especialmente, si observamos que los cambios introducidos provocan un aumento de los falsos positivos, o de los falsos negativos.

Cuanto mejor y fiable sea nuestro sistema de detección, menos nos tendremos que preocupar de la amenaza conocida y más nos podremos centrar en descubrir y eliminar la amenaza desconocida, tarea que es mucho más complicada, exigente y tediosa. Pero eso es algo que no podremos hacer adecuadamente, si tenemos a nuestros analistas y forenses buscando agujas en pajares, por tener una elevada tasa de falsos positivos, o por no poder "enseñar" a nuestro sistema a reconocerlos en el futuro.

Por este motivo, muchos fabricantes están añadiendo a sus sistemas de detección mecanismos de machine learning, o de deep learning, que mejoran la capacidad de eliminar los falsos negativos y los falsos positivos según aumenta la información fiable que maneja el sistema según lo utilizamos y le vamos "enseñando".

Sin duda, hay productos de detección de malware excelentes en el mercado. Principalmente, gracias a la enorme evolución que se ha producido en los mismos durante los últimos años. Pero también es cierto, que debemos tener en cuenta las matemáticas relativas al sistema, a la hora de tomar una decisión de compra.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
Algunos me preguntan por las métricas para valorar la gestión de eventos e incidentes de ciberseguridad y yo les digo que basta contestar cuatro preguntas:

a) ¿Hemos actuado a tiempo?

b) ¿Sabemos lo que ha pasado realmente?

c) ¿Hemos mejorado la seguridad tras el evento o incidente?

e) ¿Hemos evitado que se produzca un evento o incidente igual o similar en el futuro?

Evidentemente, en el mundo digital, la velocidad es importante, desde la detección, a la mitigación o la recuperación.

Asimismo, el conocer lo que ha pasado, contestando a preguntas como ¿quién?, ¿cuándo?, ¿dónde? ¿cómo?, ¿por qué? , nos permtirá aplicar la inteligencia a nuestras decisiones. Sin duda, la primera y la segunda pregunta, son las más complicadas y requieren disponer de capacidades, como monitorizacion, análisis forense, ciberinteligencia, o análisis de malware.

Finalmente, aunque es cierto que si contestamos afirmativamente la última, también hemos de contestar afirmativamente la penúltima, lo contrario no es cierto siempre y se produce ese caso, tenemos un serio problema.

Estas preguntas tambien sirven para descubrir procesos que no aportan nada a la seguridad. Yo recomiendo que todo aquello que aporta valor a la seguridad hay que sistematizarlo y lo que no aporta valor, hay que automatizarlo.
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Los principios básicos de la ciberseguridad son bastante sencillos y los podemos denominar ABCD, ordenados por orden de importancia. Pero lo que parece sencillo, muchas veces se vuelve casi imposible de llevar a la práctica, por ejemplo, por los condicionantes que nos impone la industria del software y del hardware, en el roadmap, o en el ciclo de vida de sus productos, que muchas veces no encajan con nuestras necesidades y provocan un efecto de avalancha, que acaba provocando que nuestros sistemas sean vulnerables y que casi no podamos hacer nada para evitarlo. Evidentemente, son principios sencillos y fáciles de entender, pero llevarlos a cabo, es tan complicado, que casi es un arte en muchos casos.

Veamos estos principios básicos, o actividades básicas de la ciberseguridad, una por una:

A -> Actualización. Debemos mantener los sistemas actualizados permanentemente y con soporte del fabricante del hardware y el software. Si no podemos actualizar nuestro sistema, aparecerán vulnerabilidades que no podremos parchear y por lo tanto, estaremos en riesgo permanente. Desgraciadamente, a pesar de la importancia de la detección y gestión de la obsolescencia, hay muy pocos expertos en esta materia, que además es muy compleja y ha de encararse de forma sistémica. Más adelante, dedicaré algunos artículos a hablar de la obsolescencia y de su estrecha relación con el ciclo de vida de los sistemas.

B -> Bastionado. De nada nos sirve un sistema actualizado, si no se aplican las configuraciones adecuadas, que permitan un funcionamiento seguro del mismo. El bastionado, o fortificación del sistema, implica, entre otras cosas, la aplicación de plantillas (configuraciones estándar) seguras, al hardware y al software. Aplicar plantillas no es sencillo, ya que implica encontrar un compromiso entre la seguridad y la funcionalidad. Entre las actividades relacionadas con el bastionado, nos podemos encontrar la aplicación de plantillas de seguridad, la realización de copias de seguridad, o el establecimiento de medidas de resiliencia avanzadas, que nos permitan seguir proporcionando los servicios críticos de nuestra organización, en un entorno altamente degradado.

C -> Concienciación / Ciberinteligencia. Al igual que en el caso anterior, aunque tengamos un sistema actualizado y bastionado, si el usuario, por desconocimiento, dejadez, o malicia, realiza algo que pone en riesgo nuestros sistemas, de nada nos sirven nuestros esfuerzos de actualización y bastionado de los sistemas. Hay que pensar que el enemigo puede estar dentro y así lo demuestran muchas fugas de datos e incidentes de seguridad recientes, por lo que es fundamental contar con mecanismos de detección de acciones anómalas, o maliciosas, de los usuarios y emprender actividades de concienciación que lleguen a la organización entera. Recordemos que la seguridad afecta por igual al Presidente de la empresa, como al último becario que ha llegado de la Universidad para realizar prácticas, aunque es cierto que el impacto de una brecha de seguridad que afecte al Presidente, no es el mismo que si afecta al becario. Asimismo, sin una ciberinteligencia adecuada, nos costará mucho adaptarnos a una amenaza cambiante y tomar las decisiones adecuadas, cuando llevemos a cabo el ciclo de gestión de eventos e incidentes de seguridad.

De nuevo, disponer de una ciberinteligencia táctica y estratégica adecuada a nuestras necesidades, no es algo sencillo ni barato, como tampoco es sencillo ni barato, el disponer de una capacidad interna de análisis forense y de malware, que nos permita convertir una amenaza desconocida en una conocida, o que nos permita realizar atribuciones, analizar tácticas, técnicas y procedimientos del atacante, o incluso, analizar artefactos o herramientas, que nos ayuden a desmantelar, o incluso anular, su infraestructura de ataque. Esa capacidad de análisis interno deberá tener entre sus objetivos, la obtención de unos indicadores de compromiso (IOC), e indicadores de ataque (IOA), que nos permitan detectar en el tiempo y en la forma adecuada, un posible compromiso de seguridad de nuestros sistemas, o mejor, el inicio de un ataque a los mismos, que nos permita adelantarnos al atacante.

D -> Defensa Activa. Los conceptos de seguridad lógica han evolucionado con la evolución de la amenaza y sobre todo, con la evolución de la percepción de dichas amenazas, a lo que colabora activamente, el disponer de una buena ciberinteligencia. Hace un tiempo, se consideraba que era prácticamente suficiente con la actualización y bastionado de los sistemas, sin embargo, en este momento, con amenazas como los APT, el malware sin archivo, o las capacidades avanzadas del malware para protegerse de la detección, análisis, o de su ejecución en una sandbox, es necesario ser mucho más proactivo, cambiar de estrategia sobre la marcha y adaptarse dinámicamente a esa amenaza cambiante y compleja, en el menor tiempo posible. Al principio, casi toda la amenaza era conocida y prácticamente nos bastaban las firmas de los antivirus para estar medianamente protegidos. Ahora la amenaza desconocida va ganando la batalla, es más compleja e inteligente y además, es muy numerosa y cambiante, por lo hay que buscar e implementar en nuestra organización otras estrategias de monitorización, detección, protección, mitigación y remediación, más efectivas y adaptadas a la amenaza en cada momento.

Si en nuestra organización no podemos llevar a cabo alguna de estas actividades básicas de ciberseguridad, con eficacia y garantías, no cabe duda de que tenemos un serio problema de seguridad lógica y si no hacemos algo rápidamente para solucionarlo, acabaremos siendo ciberatacados sin remedio.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Felicitación navideña

NAVIDADES_MATEMÁTICAS
Recibida por Whatsapp
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."








Mi hija María ha abierto un despacho de abogados especializado en accidentes de tráfico y con especial atención los ciclistas. Además, como no podía ser de otro modo, también se dedica a temas relacionados con las nuevas tecnologías.

http://abogadosespecialistasenaccidentesdetrafico.com


Acero Campillo es un despacho de abogados ubicado en Madrid con experiencia en reclamaciones de indemnizaciones, que intentamos desde la pasión y el trabajo en equipo para conseguir la máxima indemnización para nuestros clientes.


Nuestro principal objetivo es dar un
servicio personalizado a nuestros clientes, con un trato individual para ofrecer soluciones a los problemas de nuestro cliente y el apoyo en aquellos momentos que en ocasiones son bastantes difíciles.

La consulta inicial y asesoramiento puedes hacerla:


  • En nuestro despacho las realizamos de forma GRATUITA y sin compromiso alguno por tu parte.


  • O si lo prefieres por vía telefónica: 911 138 348


  • Atención a domicilio en todos los casos que el cliente lo necesite (área metropolitana de Madrid).


Resolveremos tus dudas y prepararemos la documentación para que tengas éxito en tu caso y consigas la mayor indemnización.

Evaluación


  • Podrán intervenir todos los profesionales y especialistas en función del siniestro de manera GRATUITA.


Propuesta de Servicios indicando honorarios

  • Se realizará un presupuesto ajustado a tus necesidades, transparente y cerrado.


Documentación

  • Tenemos al cliente informado en todo momento entregándoles la documentación que se va creando ya sea por correo eléctronico, WhatsApp, fax o a través de correo ordinario.


Forma de pago

  • Nuestros honorarios son los fijados por el Ilustrisimo Colegio de Abogados.

  • Posibilidad de pago mediante cuotas mensuales.

Dirección del despacho:

Plaza Condesa de Gavía, 5, bajo,

28020 - Madrid

Atencion permanente 24 horas:

911 138 348 o a través del siguiente formulario.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
No es la primera vez que hablo de Sinadura, en esta ocasión explicaré la forma de configurar el sistema para que Sinadura funcione correctamente en Ubuntu 14.04 y nos permita firmar archivos usando el DNIe o la tarjeta CERES, de la Fábrica Nacional de Moneda y Timbre.

Tal como se indica en la págína web de Sinadura, se trata de un proyecto opensource español liderado por la consultora TIC zylk.net ubicada en Erandio (Bizkaia), orientado a ofrecer productos y servicios para la identidad digital y firma electrónica, tanto para particulares como para empresas y AAPP.

Este proyecto ofrece herramientas de software, servicios y soporte a la comunidad. La herramienta más conocida del proyecto de llama Sinadura Desktop, que es una aplicación de escritorio basada en Java, por lo que es multiplataforma, líder en el mercado para la firma digital de cualquier tipo de archivo. El software de Sinadura garantiza la integridad, identidad y el no repudio en cualquier archivo, como pueden ser nóminas, contratos, facturas o certificaciones en archivos de texto, canciones en archivos de sonido o videoclips en archivos de vídeo.

Desde mi experiencia, disponer de una herramienta para firmar documentos en formato digital y con el mismo valor legal que una firma manuscrita y sello de tiempos, me ha facilitado mucho las cosas en mis relaciones con empresas y con las Administraciones Públicas. Basta con escribir un documento en Open Office, o Libre Office, guardarlo como PDF y luego usar Sinadura con nuestro DNIe, para firmar el documento antes de remitirlo por correo electrónico a su destino. De hecho, me gusta tanto este procedimiento y me ha funcionado tan bien cuando lo he usado, tanto con empresas como con las Administraciones Públicas, que es mi opción preferida cuando existe un correo electrónico de contacto.

Otro entorno en el que Sinadura es una aplicación casi imprescindible, es el de las PYMES ya que esta aplicación, que funciona prácticamente en cualquier sistema operativo, también nos permite firmar digitalmente nuestras facturas electrónicas, con solamente seleccionar dicha opción en la interfaz de usuario.

También considero muy útil, en un momento en el que no todo el mundo está acostumbrado a la firma electrónica de documentos, que Sinadura, a diferencia de otras aplicaciones similares, pueda mostrar en el documento una marca visible indicando que está firmado digitalmente. A pesar de ello, en el correo de remisión también añado siempre el siguiente texto al final, para que quede claro el estatus legal de los documentos remitidos adjuntos al mismo:




"NOTA LEGAL: Este correo y la documentación anexa al mismo, cuentan con firma electrónica reconocida del remitente realizada mediante su DNIe, por lo que según lo establecido en la Ley 59/2003, de 19 de diciembre, de firma electrónica, tanto el correo, como los documentos adjuntos al mismo, tienen la misma validez legal que la de documentos en papel con firma manuscrita."




Veamos el procedimiento para instalar y utilizar Sinadura en una distribución Ubuntu 14.04 LTS, que en mi caso usa el KDE como entorno gráfico, junto con el DNIe, o con la tarjeta CERES modelo "Kriptonita", en la que guardo mis certificados digitales de 2048 bits de CERES, CACERT y STARTCOM.

Como punto de partida consideraremos que tenemos un lector de tarjetas correctamente instalado en nuestro sistema, así como una máquina virtual JAVA, que en mi caso es Oracle versión 7.

Yo uso un lector de tarjetas inteligentes Castles Technologies EZ100PU, comprado en unos grandes almacenes de Madrid hace unos años. Este lector me gusta especialmente, aparte de por su excelente suporte para Linux de 32 y 64 bits (recomiendo bajar los controladores más actualizados para Linux de la página web del fabricante), por la información que proporciona su LED de funcionamiento. Dicho LED está en color verde cuando está alimentado, en color rojo cuando alguna aplicación está haciendo uso de la tarjeta inteligente insertada y parpadea en rojo, cuando dicha tarjeta está siendo utilizada por la aplicación.

De esta forma, evitaremos destruir nuestro DNIe por retirarlo del lector mientras está siendo utilizado, cosa, que por desgracia, suele se demasiado frecuente. El DNIe es relativamente lento y en algunas circunstancias, si el lector no proporciona información sobre el uso de la tarjeta, el usuario puede considerar que la aplicación o el DNIe se han bloqueado, retirando el DNIe antes de tiempo y provocando su destrucción. De hecho, yo voy un poco más lejos y tengo la precaución de salir de las aplicaciones que hacen uso del DNIe para que se ponga el LED del lector en verde, antes de extraer el DNIe.

Dicho lo anterior, considero imprescindible que el lector de tarjetas inteligentes que usemos, informe claramente de que la tarjeta está siendo utilizada por un programa, evitando así el tener que volver a la comisaría a renovar nuestro DNIe.

VERIFICANDO JAVA

En mi Ubuntu 14.04LTS, el archivo java del directorio /usr/bin es un enlace simbólico al archivo /etc/alternatives/java, que a su vez, es un enlace simbólico a la máquina virtual de java, que en mi caso, se encuentra instalada en /usr/lib/jvm/java-7-oracle/jre/bin/java.

Si ejecuto el mandato java -version obtengo lo siguiente:

java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode)

Ahora lo más importante, para que Sinadura funcione adecuadamente, es la correcta configuración de la variable de entorno JAVA_HOME. Para verificarlo, usaremos el mandato echo $JAVA_HOME, que en consonancia con lo anterior, nos debería devolver lo siguiente:

/usr/lib/jvm/java-7-oracle

Si no es así, podemos usar el mandato:

sudo apt-get install oracle-java7-set-default

NOTA: La instalación de oracle-java7-set-default, o oracle-java8-set-default, dependiendo de la versión de Java que tengamos instalada, funcionará si en el archivo /etc/profile no hay ninguna configuración relativa a JAVA_HOME. La instalación de oracle-javax-set-default, lo que hace es crear unos archivos en el directorio /etc/profile.d denominados jdk.sh y jdk.csh que configuran adecuadamente la variable de entorno JAVA_HOME.

Si se desea usar el archivo /etc/profile deberá contener en nuestro caso las lineas siguientes:

JAVA_HOME=/usr/lib/jvm/java-7-oracle/jre
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
export JAVA_HOMEexport PATH

Posteriormente, para evitar cualquier configuraciones erróneas, será necesario cualquier archivo java.sh, java.csh, jdk.sh o jdk.csh, que pudiera haber en el directorio /etc/profile.d

La siguiente vez que arranquemos el sistema, la variable JAVA_HOME debería apuntar al directorio adecuado.



INSTALAR EL CONTROLADOR DEL DNIe Y DE LA TARJETA CERES

Para ello iremos a la página de descarga de software de la Fábrica Nacional de Moneda y Timbre y descargaremos el archivo GNU/Linux Ubuntu 14.04 - 14.10 - 32 bits o GNU/Linux Ubuntu 14.04 - 14.10 - 64 bits, en función de nuestra distribución. Supongamos que la nuestra es de 32 bits. Para instalar el paquete usaremos el mandato:

sudo dpkg -i libpkcs11-fnmtdnie_1.2.2_Ubuntu_14.04_14.10_32bits.deb

Una vez que se abra el navegador Firefox, solamente habrá que seguir las instrucciones que aparecen en el mismo, que son las siguientes:

Para usar la tarjeta de la FNMT/DNIe en su navegador se requiere:

* Instalar el Módulo de Seguridad PKCS#11

Para instalar el módulo PCKS#11 debe ir a Editar/Preferencias/Avanzado/Cifrado/Dispositivos de seguridad

Seleccione "Cargar"

Dele un nombre al módulo. (Por ejemplo "FNMT-RCM Modulo PKCS # 11")

Indique manualmente la ruta del módulo: /usr/lib/libpkcs11-fnmtdnie.so

Pulse el botón "Aceptar"

* Instalar el Certificado Raíz de la Autoridad de Certificación de la FNMT-RCM

Para instalar el certificado raíz ir a Editar/Preferencias/Avanzado/Cifrado/Ver certificados

Seleccione "Importar".

Indique manualmente la ruta del certificado raíz: /usr/share/libpkcs11-fnmtdnie/FNMTClase2CA.crt

El asistente le pedirá que establezca la confianza para el certificado.

Marque las tres casillas de confianza.

Pulse el botón "Aceptar"

* Instalar el Certificado Raíz de la Autoridad de Certificación del DNIe

Para instalar el certificado raíz ir a Editar/Preferencias/Avanzado/Cifrado/Ver certificados

Seleccione "Importar".

Indique manualmente la ruta del certificado raíz: /usr/share/libpkcs11-fnmtdnie/ac_raiz_dnie.crt

El asistente le pedirá que establezca la confianza para el certificado.

Marque las tres casillas de confianza.

Pulse el botón "Aceptar"

Una vez realizado todo lo anterior y se cierre el navegador, finalizará la instalación del software necesario para que funcione la tarjeta CERES y el DNIe en Ubuntu 14.04 LTS.

INSTALACIÓN DE SINADURA

Para instalar Sinadura Desktop 4.2.0, accederemos a la página del proyecto y descargaremos la version de 32 o 64 bits, en función de la versión de nuestro Ubuntu 14.04. Como en el caso anterior, supondremos que nuestra versión es de 32 bits. Una vez descargado el archivo, usaremos el mandato.

sudo java -jar sinadura-ce-4.2.0-unix32-installer.jar

Pulsaremos "Next", luego aceptaremos la licencia y pulsaremos "Next", después dejaremos el directorio por defecto y pulsaremos "Next", luego aceptaremos la creación del directorio y cuando acabe la instalación de los archivos, volveremos a pulsar "Next". Seguidamente, seleccionaremos las opciones "Create shortcuts in the XDG-Menu", "Create additional shorcuts on the desktop" y "All users", dejaremos el "Program Group" por omisión y pulsaremos "Next". Cuando acabe el proceso, pulsaremos "Done" y con ello tendremos instalado Sinadura en nuestro sistema.

Sin embargo, las librerías gráficas SWT (Eclipse)que usa Sinadura, no se llevan especialmente bien con las librerías del entorno gráfico de Ubuntu, que en mi caso es el KDE. De hecho, cualquier intento de modificar la configuración de Sinadura provocará que Sinadura deje de funcionar y genere un "core". La solución, una vez identificado el problema, es sencilla, solamente hay que editar como root el archivo /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc, modificando la línea:

GtkComboBox::appears-as-list = 1

Para que muestre lo siguiente:

GtkComboBox::appears-as-list = 0

Una vez salvado el archivo, la próxima vez que ejecutemos Sinadura funcionará perfectamente y se acabarán los "core" de la aplicación.

USANDO EL CONTROLADOR DEL DNIe con SINADURA

En este punto Sinadura no funcionará con el DNIe ni con la tarjeta CERES ya que buscará el controlador en una ruta y con un nombre que no es adecuado para nuestra configuración. El software de la FNMT para Linux instala los controladores del DNIe en /us/lib con el nombre libpkcs11-fnmtdnie.so, mientras que Sinadura los busca en /usr/lib/opensc/ con el nombre opensc-pkcs11.so. Para solucionarlo, editaremos como root el archivo hardware-preferences.csv, que encontraremos en el directorio /usr/local/sinadura/resources/preferences, de forma que la segunda línea del archivo, en lugar de mostrar:

generic;Genérico (32-bit);/usr/lib/opensc/opensc-pkcs11.so;linux;

Muestre lo siguiente:

generic;Genérico (32-bit);/usr/lib/libpkcs11-fnmtdnie.so;linux;

Hecho esto ya podremos usar nuestro DNIe, o una tarjeta CERES, para firmar nuestros documentos o crear facturas electrónicas. Asimismo, Sinadura también puede usar un certificado software para firmar un documento, si se configura adecuadamente para ello, por lo que no es imprescindible disponer de una tarjeta inteligente para firmar documentos aunque en ese caso, los documentos firmados no tendrán el mismo valor legal que un documento con firma manuscrita.

En versiones anteriores de Sinadura este archivo se encontraba dentro de un contenedor "jar", por lo que era mucho más complicado de editar. Por ello, considero muy acertado que por parte de los responsables del proyecto se haya decidido facilitar esta tarea de forma que Sinadura se pueda utilizar con tarjetas, o en entornos, distintos a los considerados inicialmente por los desarrolladores, como ha sido nuestro caso.

Una vez configurado todo adecuadamente, no tendremos problemas para usar nuestro DNIe, o una tarjeta CERES con el navegador Firefox, o con el programa de correo electrónico Thunderbird. También podremos firmar documentos PDF con Sinadura, así como con Open Office o Libre Office, en formato Open Document Format (ODF) y en el caso de usar el DNIe, con la misma validez legal que un documento con firma manuscrita. Hay que señalar que Open Office y Libre Office usan el almacén de certificados de Firefox, por lo que si nuestro DNIe está correctamente configurado en Firefox, también nos funcionará sin problemas con Open Office, o con Libre Office.





"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."