La sexta edición del seminario ENISA NCSS tendrá lugar el 18 de septiembre

By | NCSS | No Comments

El próximo 18 de septiembre de 2018 tendrá lugar la sexta edición del seminario “ENISA NCSS” sobre estrategias nacionales de ciberseguridad en Helsinki (Finlandia).

El evento, que ha sido organizado conjuntamente por la Autoridad Regulatoria Finlandesa de Telecomunicaciones (FICORA) y ENISA, tendrá como tema central el desarrollo, implementación y evaluación de las estrategias nacionales de ciberseguridad (NCSS, en sus siglas en inglés). También se abordará la creación de Centros de Intercambio de Información y Análisis de Información Nacional, Europea y Sectorial (ISACs). Además, tendrán lugar diversos foros de debate en los que representantes del sector público y privado podrán exponer sus ideas sobre las estrategias nacionales de ciberseguridad y compartirán las mejores prácticas para la creación de ISACs.

Audiencia en ENISA NCSS

La audiencia que acudirá a este seminario son, principalmente, aquellos actores implicados en el desarrollo e implementación de las estrategias nacionales de ciberseguridad y las personas implicadas en la creación de los ISACs tales como reguladores sectoriales y autoridades de supervisión nacionales; legisladores y autoridades nacionales; sector privado y universidades.

Actividades en ENISA NCSS

A primera hora, tendrá lugar la ceremonia de apertura a cargo del Secretario General del Comité de Seguridad finés, Vesa Valtonen. A continuación, hablará Pentti Olin, miembro del Comité de Seguridad, quien expondrá a los asistentes la estrategia nacional de seguridad implementada por Finlandia.

Seguidamente, tendrá lugar la primera sesión de trabajo con el foco puesto en la difusión de las actualizaciones en las estrategias nacionales recogidas en la norma técnica NIS. Varios países, entre ellos Luxemburgo, participarán en esta sesión, que se cerrará con un panel de discusión.

En la sesión 2, que tendrá lugar por la tarde, se analizarán los distintos Centros de Intercambio de Información y Análisis de Información Nacional, Europea y Sectorial (ISACs) que existen: europeos, nacionales y sectoriales. Al igual que en la sesión anterior, al finalizar las presentaciones tendrá lugar un panel de discusión.

Si desea consultar la agenda, haga click aquí.

Datos prácticos sobre ENISA NCSS

Fecha: 18 de septiembre de 2018

Lugar:Dynamicum, Erik Palménin aukio1, Helsinki (Finlandia).

Si desea más información sobre el evento, haga click aquí.

 

ENISA NCSS Workshop

ETSI publica normas técnicas para firma electrónica remota en borrador

By | ETSI, European Telecommunications Standards Institute | No Comments

ETSI

El pasado 2 de julio de 2018, el Instituto Europeo de Normas de Telecomunicaciones (ETSI) publicó una nueva versión en formato borrador de las siguientes normas de creación de firma digital, centradas en el desarrollo técnico de la firma remota cumpliendo con eIDAS: ETSI TS 119 431-1, TS 119 431-2 y ETSI 119 432.

 

ETSI TS 119 431-1: Firmas Electrónicas e Infraestructuras (ESI); Requisitos de política y seguridad para prestadores de servicios de confianza; Parte 1: componentes del servicio del PSC que operan un QSCD / SCDev remoto.

Esta norma se centra en los dispositivos de creación de firma digital, para crear un valor de firma digital en nombre de un firmante remoto.

En concreto, especifica los requisitos de política y seguridad generalmente aplicables a los prestadores de servicios de confianza (PSCs) que implementan un componente de servicio que opera una firma o dispositivo de creación de sello (como se define en el Reglamento (UE) no 910/2014), llamado QSCD / SCDev remoto.

Este componente contiene una aplicación de firma de servidor, que es el componente de servicio de aplicación de firma de servidor (SSASC). Además de ser la aplicación de firma del servidor, contiene los elementos de servicio y el dispositivo de creación de firma (SCDev).

Los requisitos de esta norma están alineados con los requisitos especificados en CEN EN 419 241-1.

ETSI TS 119 431-2: Firmas Electrónicas e Infraestructuras (ESI); Requisitos de política y seguridad para prestadores de servicios de confianza; Parte 2: componentes del servicio del PSC que admiten la creación de firmas digitales AdES.

ETSI TS 119 431-2 proporciona los requisitos de política y seguridad para el prestador de servicios de confianza (PSC) que implementa un componente de servicio que admite la creación de firmas digitales AdES. Este componente contiene una aplicación de creación de firma y, en resumen, se denomina componente de servicio de aplicación de creación de firma (SCASC). Sin embargo, es más que solo el SCA, ya que contiene los elementos de servicio gracias a los cuales se puede implementar una parte de la parte principal de la aplicación como se define en EN 319 102-1 [1] y TS 119 101.

Esta norma se basa en los requisitos de política general especificados en ETSI EN 319 401 [9] y tienen en cuenta los requisitos relacionados de ETSI TS 119 101.

ETSI TS 119 432: Firmas Electrónicas e Infraestructuras (ESI); Protocolos para la creación remota de firmas digitales.

Esta norma especifica los protocolos e interfaces aplicables cuando se lleva a cabo, por un solución distribuida compuesta de dos o más sistemas/servicios/componentes, el proceso de creación de firmas digitales AdES (según lo definido por ETSI EN 319 102-1 y/o los valores de firma digital), como resultado de las Firmas de Representación de Datos a ser firmados. Esta norma está limitada a la firma de servidor remoto.

Si lo desea, puede consultar la versión original de las normas y enviar sus opiniones a través del formulario de contacto haciendo click aquí.

Para obtener más información sobre ETSI, pinche aquí.

Auditorías de seguridad para proyectos con Blockchain y SmartContracts

By | Auditoría, Blockchain, Conformity Assessment | No Comments

Según algunas estimaciones, las empresas de tecnología de blockchain pueden esperar volúmenes de negocio de 6 mil millones de euros en 2020. Sin embargo, antes deben lidiar con las vulnerabilidades de seguridad de blockchain, que, a pesar de su relevancia se siguen minusvalorando cuando se trata de la  llamada tecnología de “contabilidad distribuida”.

Un inciso terminológico, para acotar el término “libro mayor distribuido” (distributed ledger technology, DLT) que cuenta con una traducción más afortunada como “contabilidad distribuida”.  En mi opinión se ajusta más a la realidad el término “RJT Replicated Journal Technology”  ya que el tipo de libro contable que registra los movimiientos en las blockchains es el llamado “libro diario”. Por ello, mi preferencia frente al término DLT es el de  RJP Replicated Journal Paradigm o RJT Replicated Journal Technology

Vulnerabilidades de seguridad en cadenas de bloques

Algunos aspectos de la seguridad tienen que ver con el uso de la criptografía, y dado que en los contextos de cadenas de bloques se usa intensivamente la criptografía, existe la creencia generalizada de que los sistemas de blockchain, son seguros de por sí.

Sin embargo en sistemas complejos aparecen continuamente diferentes vectores de ataque que hay que identificar y remediar, por lo que el exceso de confianza en la tecnología puede ser peligroso.

De hecho, la tecnología denominada DLT está sujeta a una serie de problemas que las bases de datos centralizadas no tienen.

Los riesgos de seguridad de Blockchain  existen, y deben ser reconocidos y mitigados para que  blockchain cumpla su promesa de transformar la manera en que se almacenan los datos y cómo afectan a los proyectos que las usan.

A medida que más sectores gubernamentales, industriales y comerciales adoptan la tecnología, la necesidad de abordar estos problemas más pronto que tarde se convierte en primordial.

Vulnerabilidades de Blockchain

Vulnerabilidades del sistema de interfaz

Una de las vulnerabilidades más probables con DLT se origina fuera de la propia blockchain.

El sistema de interfaz es el equipo que un usuario emplea para acceder a servicios basado en blockchain.

En ese sistema se introducen las credenciales, motivo suficiente para atraer atacantes que aprovechen vulnerabilidades. Otras veces, manipular el “clipboard” la zona de memoria usada para las funciones de copiar y pegar puede permitir a un atacante cambiar la cuenta de destino de una transacción.

La detección de malware es una funcionalidad deseable en las herramientas que prevean minimizar los ataques a sistema de interfaz.

Seguridad de la criptografía de clave pública

Quienes proponen transacciones para que formen pare de la cadena (por ejemplo, transferencias de valor en el caso de los criptoactivos y criptomonedas) las firman con una clave privada y dan información sobre su clave pública. La clave privada se archiva con la cartera o mecanismo equivalente. La protección del equipo es de nuevo, esencial. Pero existen ciertos riesgos (por ejemplo, en base a la computación cuántica) que en el futuro podría permitir obtener la clave privada a partir de la pública. Para minimizar el riesgo, hay técnicas asociadas a carteras de un solo uso que se pueden adoptar.

Los backups de claves no se deberían conservar en el sistema que se usa a diario. Y aún menos sin cifrar.

Plataformas de terceros

Conforme se popularizan las cibermonedas y las aplicaciones que emplean tecnologías afines (como DLT) el mercado de soluciones de terceros experimentará crecimiento. Algunos posibles servicios a ofertar por terceros son:

  • Plataformas de integración de Blockchain
  • Procesadores de pago
  • Carteras
  • Entidades Fintech
  • Plataformas de pago de criptomonedas
  • Contratos inteligentes

Estas plataformas usan diferentes tecnologías vulnerables, además de las específicas de blockchain. Son verdaderos Prestadores de Servicios de Confianza Digital y deberían cumplir la norma EN 319 401 que el Reglamento EIDAS impone a los Prestadores Cualificados.

Control del paso a producción

Cuando se inicia un proyecto o se evoluciona dentro de el, deben realizarse pruebas exhaustivas para detectar vulnerabilidades en el código antes de su paso a entorno final de ejecución. Eso es de especial relevancia en los smartcontracts. En los smarcontracts se usan con frecuencia lenguajes como Solidity, con “defectos” similares a los de Javascript. Un caso de especial relevancia puede ser incluir entre comillas las direcciones de las carteras. De no hacerlo, las direcciones se truncan y los montos remitidos pueden acabar en un limbo irrecuperable.

Tamaño de la cadena de bloques

Dependiendo del tipo de criptoactivo y de como se ha diseñado su sistema de gestión de transacciones para su anotación en la cadena de bloques, puede ser que sea necesario conservar toda la cadena de bloques desde sus orígenes. Algunas variantes permiten convertir el histórico de transacciones en una “foto de estado” a partir de la cual puede desecharse el histórico anterior. Sea como sea, cuantas más transacciones se hacen más crece la cadena, lo que puede crear problemas de dimensionamiento en los equipos en los que se gestionan.

Ataques del 51%

Algunos sistemas de criptoactivos con diferentes filosofías de confirmación de bloques (PoW, Proof of Work, PoS, Proof of Stake, …) podrían atacarse por colectivos que que superen el 51% de participación en el mecanismo de consenso. Por tanto convendría prever si es necesario contar con mecanismos de reversión, y la responsabilidad de ejecución de tales mecanismos.

Se han dado casos reales de este tipo de ataque sobre mecanismo Pow (teórico hasta hace poco tiempo) que se entiende sabiendo que un gran número de centros de acumulación de equipamiento de minería se construyen en países donde la energía eléctrica es barata y la supervisión escasa

Falta de madurez de la tecnología

En todas las tecnologías se aprenden lecciones esenciales conforme se adoptan y se generalizan. Se descubren problemas y se reselven. La tecnología blockchain todavía está en los estadios iniciales de desarrollo y no se comprenden todos los riesgos y sus efectos.

Riesgos por normalización insuficiente

Muchos de los sistemas de blockchain se despliegan con un “Whitepaper” y código fuente del proyecto disponible en Github. Aunque es un ejercicio de transparencia, a menudo se revela que los promotores de tales proyectos tienen escaso interés en conocer los estándares o en adoptarlos.

Es particularmente llamativo en el ámbito de la firma electrónica, cuyo mercado principal ha madurado a lo largo de los años dando lugar a diversas leyes y normas técnicas que crean presunciones legales a quienes adoptan la tecnología y que define los estándares que facilitan su interoperabilidad.

En cambio, el uso de la tecnología de firma electrónica en los proyectos de blockchain parece provenir de alumnos de grado que han leído lo básico de la teoría de firma electrónica y que ignoran el avance de los estándares. Parecen ejercicios académicos, en vez de responder  exigencias de un mercado que impone que los sistemas puedan interoperar y que sus desarrolladores conozcan las leyes y los estándares.

Afortunadamente UNE e ISO (entre otros organismos de estandarización) están comenzando a proponer estándares para el mundo de blockchain, que no deberían soslayar los avances producidos en las tecnologías comunes con cierto nivel de madurez.

Cabe recordar que la estandarización, contra lo que afirman sus críticos, no cercena  la innovación sino que abre nuevas posibilidades para ella. Y deja resueltos problemas que se acometieron en el pasado minimizando el riego a reinventar a rueda cada vez.

Vulnerabilidades sutiles

Existen vulnerabilidades difíciles de detectar que se hacen visibles tras incidentes de cierta magnitud. Conviene prever mecanismos de reversión antes del despliegue para poder gestionar los problemas que no se han podido identificar con anterioridad.

Un ejemplo nos lo enseña el caso de “The DAO”

Una”DAO” (Distributed autonomous organization) es una Organización Autónoma Descentralizada construida en algunos tipos de blockchain, con funcionalidad de ejecución de código para contratos inteligentes asociados a inversiones en el capital de empresas marcadamente digitales. Se podría decir que un DAO es un fondo de capital  riesgo de crowdsourcing que se gestiona en base a smartcontracts embebidos en una cadena de bloques. Hay muchos DAO, cada uno creado para alojar y ejecutar contratos inteligentes para organizaciones específicas.

Uno de esos DAO, conocido como “The DAO”, fue fundado en 2016 por miembros del equipo de Ethereum. Durante su período de creación, The DAO hizo historia en el ámbito del crowdfunding recaudando 150 millones de dólares. Poco después, The DAO hizo historia, una vez más, al ser el primer DAO en ser pirateado.

Durante el crowdsale, muchos miembros de la comunidad de Ethereum expresaron su preocupación de que el código DAO fuera susceptible de ser atacado. Posteriormente, un miembro del equipo de la DAO encontró un “error recursivo” pero erróneamente creyó que no había fondos de la DAO en riesgo. Un hacker demostró que estaba equivocado.

El ataque se produjo cuando el atacante explotó dos vulnerabilidades en el código DAO. El hacker sabía que el código estaba diseñado para permitir tanto una división como una transferencia de tokens entre cuentas. El hacker también se dio cuenta de que el código no actualizaría los saldos de las cuentas lo suficientemente rápido como para evitar la transferencia de los mismos tokens más de una vez.

El hacker ejecutó una función de escisión, creando una cuenta “child DAO” y realizó repetidas solicitudes de transferencia desde su primera cuenta en rápida sucesión. Como el código no disminuía los saldos de cuenta originales después de cada transferencia, no había nada que impidiera que los mismos tokens se repitieran unas 40 veces cada uno, sin que se destruyeran los tokens originales.

Después de transferir $ 55 millones en Ether, el hacker dio por terminado el ataque y algunos hechos adicionales se sucedieron, por lo que invito a investigar sobre este asunto del que se extraen grandes eseñanzas.

A quien acudir.

Cuando se plantean proyectos serios de blockchain, sus impulsores invierten en los desarrolladres de tecnología que ayudan a definir los tipos de transacción, los modelos de gestión de identidad, los mecanismos de confirmación de bloques, los ritmos de producción de bloques y el límite de transacciones por bloque. Hay muchos aspectos que hacen diferencial cada proyecto.

Uno de que deberá empezar a tenerse en cuenta es el de la auditoría de proyecto. Quizá no detecte todos los problemas, pero descubrirá los principales. hay que empezar a poner en valor lo que ya se conoce y evitar cometer errores que ya se cometieron.

Contacte con Trust Conformity Assessment Body (TCAB) si necesita auditar un proyecto de blockchain.

24-28/09: Cita con NIS Summer School en Grecia

By | Ciberseguridad, Cybersecurity | No Comments

La quinta edición de NIS Summer School sobre Seguridad de Redes e Información (NIS’18) tendrá lugar del 24 al 28 de septiembre en Heraklion (Grecia).

NIS Summer School, organizado por la Agencia de Seguridad de las Redes y de la Información de la Unión Europea (ENISA) y la Fundación para la Investigación y la Tecnología (Hellas), reunirá durante cuatro días  a distintos players del sector tales como la Administración Pública, empresas del sector privado y organizaciones sin ánimo de lucro.

La temática de esta edición es “El desafío de un panorama de riesgos en constante cambio”. En un sistema como el actual el sector IT vive en constante evolución, lo que plantea importantes desafíos. Para ello, los actores implicados deben acelerar su tiempo de reacción y fomentar el intercambio de colaboración e información para lograr dar respuestas adecuadas y efectivas a los desafíos que se plantean.

Con estas jornadas, ENISA busca promover la cultura de la ciberseguridad en la UE, que servirá para mejorar la capacidad de los Estados Miembros a la hora de responder a ciberataques. ENISA sigue una estrategia de mitigación de riesgos mediante la concienciación y la publicación de estudios e informes sobre temas actuales NIS.

Dando a conocer trabajos sobre Inteligencia de Amenazas de ciberseguridad

Las organizaciones sin ánimo de lucro en el área de Inteligencia de Ciberamenazas tendrán la oportunidad de presentar sus trabajos durante el evento, que pueden estar relacionados con proyectos de Horizon 2020, investigaciones académicas nacionales, proyectos de desarrollo y comunidades open source.

Ponencias en NIS Summer School

A lo largo de NIS Summer School habrá un gran número de ponentes procedentes tanto del sector público como del privado y del ámbito universitario. En concreto, destacan los siguientes:

  • Nektarios Tavernarakis (Presidente de FORTH)
  • Udo Helmbrecht (Director Ejecutivo de ENISA)
  • Damien Cauquil (Jefe de I+D en Seguridad Digital – Econocom)
  • Piotr Kijewski (Jefe de Programas Estratégicos en The Shadowserver Foundation)
  • Prof. Dr. Ir. Bart Preneel (Profesor de la Universidad Católica de Lovaina)

Datos del evento

Fecha: 24-28 de septiembre de 2018
Lugar: Galaxy Hotel Iraklio – Leof. Dimokratias 75, Iraklio 713 06, Grecia
URL: https://nis-summer-school.enisa.europa.eu/

Para ver el programa de NIS Summer School 2018, haga click aquí.