Category

Auditoría

TCAB participa en el evento sobre el Reglamento de Ciberseguridad organizado por AMETIC

By | Acreditación, AMETIC, Auditoría, Centro Criptológico Nacional, Cyber-security, Cybersecurity, ENISA, EU Cybersecurity | No Comments

AMETIC, la patronal de la industria digital en España, ha organizado una jornada informativa sobre el nuevo reglamento europeo “Cybersecurity Act”, que a partir de junio regulará la puesta en marcha de un marco común europeo para la certificación de productos y servicios TIC “ciberseguros”, que fomenten la ciberseguridad de los servicios en línea y los dispositivos de consumo.

Este reglamento europeo no solo busca aumentar la confianza de los usuarios en relación al uso de dispositivos conectados, sino también fortalecer la industria europea de ciberseguridad y el Mercado Único Europeo, posicionándola como referente a nivel mundial, en línea con otros mercados como Estados Unidos o China. La European Union Agency for Network and Information Security (ENISA), que a través de este reglamento será nombrada como nueva Agencia Europea para la Ciberseguridad, coordinará y armonizará las políticas a nivel europeo, y dará soporte a los Estados Miembros en la implementación de planes y estrategias nacionales en la lucha contra las amenazas y los ataques de seguridad cibernética.

Antonio Cimorra, director de Tecnologías de la Información y Agenda Digital de AMETIC, ha destacado durante la apertura de la jornada los avances que la transformación digital ha introducido en la sociedad, así como la importancia de garantizar la ciberseguridad. Asimismo, ha comentado las medidas que, desde AMETIC, y muy particularmente desde la Comisión de Ciberseguridad donde se dan cita importantes proveedores de esta tecnología, se están desarrollando en este ámbito. Cimorra ha resaltado también el apoyo de la asociación a la nueva iniciativa europea.

Posteriormente, Ignacio Pina, director Técnico de la Entidad Nacional de Acreditación (ENAC), ha explicado que, “si bien el reglamento no será de obligado cumplimiento en sus inicios, en lo que a certificación se refiere, será previsiblemente el propio mercado quien regule la necesidad o no del mismo”. Pina ha añadido que “la certificación en sí misma no genera seguridad, sino que lo que busca es generar confianza entre los consumidores”. En este sentido, ha comentado que “la transición entre los esquemas de certificación nacionales actuales en vigor y el nuevo marco común europeo será paulatina”. Por otro lado, ha subrayado que “el papel de la industria en la definición de los esquemas de certificación que deriven de este reglamento, es esencial para que éstos estén alineados con las necesidades de mercado”.

Implicaciones de “Cybersecurity Act”

A continuación, ha tenido lugar la mesa ronda ¿Cómo impacta Cybersecurity Act en las empresas del sector digital?, moderada por David González, presidente de la Comisión de Ciberseguridad de  AMETIC y Jefe de Ventas Europa y África del Norte de G&D. Los participantes, Mariano José Benito, CISO de GMV; Jesús María Alonso, Head of Consulting Spain de ATOS; Ainhoa Inza, CEO de TCAB (Trust Conformity Assessment Body), y Miguel Bañón, director general de EPOCHE & ESPRI, donde han debatido sobre las implicaciones del reglamento para la actividad de las empresas del sector digital, y los siguientes pasos para abordar este nuevo escenario.

En líneas generales, los participantes han comentado que se trata de una iniciativa muy positiva ya que a pesar de ser de momento un reglamento de carácter voluntario, se espera que su impacto en el mercado incremente el número de productos TIC seguros certificados de forma importante. Asimismo, han destacado que, para España, es una oportunidad de consolidación a nivel europeo en materia de ciberseguridad aprovechando que el ecosistema de certificación español se encuentra entre los mejor valorados de Europa.  

Por otro lado, se ha destacado que, al no existir por el momento un marco sancionador dentro del reglamento, es importante que las empresas detecten el beneficio que les aporta la certificación, como por ejemplo el impacto sobre el consumidor en términos de confianza. También han comentado que el objetivo de esta iniciativa es que el consumidor se “acostumbre” a comprobar que aquellos productos o servicios TIC que compre o consuma, lleven el sello de certificación de seguridad.

Por último, se ha contado con la presencia del representante experto del Centro Criptológico Nacional (CCN), entidad que actualmente coordina la labor de certificación en ciberseguridad a nivel nacional. CCN ha coincidido en la gran oportunidad que “Cybersecurity Act” supone para la industria de la ciberseguridad europea y española a la hora de posicionar a Europa en línea con otros mercados.

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.