Blockchain: Identificación del riesgo en el camino hacias los registros distribuidos

La tecnología blockchain, comúnmente esperada para impulsar la siguiente ola de infraestructura digital y la innovación de procesos, se está desarrollando rápidamente hacia la madurez. Cinco subdisciplinas de riesgo de TI son de gran interés al embarcarse en proyectos impulsados por blockchain: riesgo de cibernética y de información, riesgo de arquitectura y diseño, riesgo de cumplimiento de TI, riesgo de terceros y proveedores y riesgo de integración.

Blockchains permiten a múltiples entidades lograr un consenso sobre los datos de transacción, es decir, una versión única de la verdad, sin necesidad de una autoridad central de confianza o una función notarial. La tecnología es un nuevo paradigma de registro de datos que permite que múltiples entidades, potencialmente desconocidas o no confiables, se compartan y agreguen a los ledgers digitales. La integridad y confidencialidad de los datos en los ledgers digitales están garantizados criptográficamente.

Tres características principales— la inmutabilidad, la transparencia y la autonomía—impulsan la capacidad de la tecnología para interrumpir los productos, procesos y modelos de negocio actuales en una variedad de industrias. Como la única versión de la verdad (es decir, datos inmutables y actualizados) es disponible para todas las entidades en red, se reduce la asimetría de información entre las entidades y se pueden evitar costosas actividades de conciliación entre diferentes fuentes de información. Por ejemplo, una solución de blockchain podría proporcionar una visión completa de la historia médica de un paciente, dando como resultado ventajas significativas en caso de emergencias, en lugar de almacenar los registros entre las instituciones de salud múltiples como se hace ahora. La tecnología blockchain también asegura que el registro de los datos esté de acuerdo con condiciones mutuamente acordadas, permitiendo la desintermediación de las entidades centrales de validación.

Es difícil no estar fascinado por algo tan transformador. Dicho esto, las oportunidades impulsadas por la tecnología para mejorar la eficiencia y efectividad rara vez vienen sin retos y riesgos. Este artículo tiene como objetivo identificar el riesgo de TI que debe considerarse durante el desarrollo de una solución impulsada por Blockchain y proporciona estrategias para minimizar este riesgo.

Riesgo cibernético y de información

Los ataques cibernéticos pueden comprometer la confidencialidad, integridad y disponibilidad de los datos registrados en un blockchain. Vulnerabilidades técnicas que pueden ser explotadas por hackers para causar pérdida o daño siguen siendo omnipresentes. No hay evidencia que indique que esto sería diferente para implementación blockchain. Además, las estrategias de respuesta para hacer frente a los ciber incidentes suelen ser inadecuadas. Por ejemplo, en junio de 2016, la DAO, una organización autónoma descentralizada basada en la Ethereum blockchain, sufrió un ciberataque que desplegó una combinación de vulnerabilidades, lo que resultó en la pérdida de un tercio de sus fondos (aproximadamente US $50 millones).¹ Aunque se había propuesto un parche de seguridad días antes del ataque, no había equipos de seguridad ni procedimientos para actuar. En su lugar, el parche propuesto debía ser adoptado a través de un proceso formal de votación con 23.000 votantes elegibles, según se especifica en las condiciones mutuamente acordadas.

También pueden encontrarse debilidades de seguridad en los puntos finales que escriben en una aplicación de blockchain y almacenan de forma segura las claves criptográficas que se utilizan como firmas digitales. Los ciber incidentes en los intercambios Bitcoin Mt.Gox (US $450 millones perdidos) y Bitfinex (US $72 millones perdidos) son ejemplos notables de ciberataques que se centraban en comprometer las infraestructuras de TI en los puntos finales de la red.

Las medidas de seguridad cibernética que podrían ayudar a mitigar este riesgo incluyen:

• Realización de extensas pruebas de penetración en la aplicación de blockchain.
• Implementar una seguridad de punto final adecuada que incluya el diseño, implementación y mantenimiento de controles que aseguren una entrega segura de servicios (por ejemplo, controles preventivos tales como control de acceso y firewalls) y medidas para identificar la ocurrencia de un incidente (por ejemplo, monitorización de la red y del sistema). Una visión general de los controles adecuados se puede encontrar en COBIT 5,² la Organización Internacional de Normalización (ISO) ISO 27000 serie, y el Instituto Nacional de EE.UU. de Estándares y Tecnología (NIST) Marco de Seguridad Cibernética (CSF).
• Instauración de los procesos de respuesta a incidentes que se centran en el análisis de incidentes, contención, erradicación y recuperación. Al preparar estos procesos, las organizaciones también deben considerar las políticas y arreglos de comunicación con equipos especializados de respuesta a la ciber emergencia.

Los detalles sobre las estrategias efectivas de respuesta a incidentes se pueden encontrar en NIST Special Publication (SP) 800-61 Revisión 2.³

Arquitectura y diseño de riesgo

Durante el desarrollo de una solución de blockchain se debe tomar una amplia variedad de decisiones técnicas y de diseño organizativo. Estas opciones de diseño pueden tener un impacto significativo en el rendimiento de la solución y, en consecuencia, en el logro de los objetivos de negocio.

Los diseños técnicos para soluciones de blockchain pueden no estar alineados con los requisitos funcionales. La selección de un protocolo de consenso, utilizado para validar las adiciones propuestas a un ledger basado en blockchain, es una opción de diseño a menudo citada que afecta la capacidad operativa. Mientras que VISA puede procesar aproximadamente 56,000 transacciones por segundo (reportado en 2015),⁴ el protocolo de consenso de Bitcoin limita el sistema de pago a solo siete transacciones por segundo.⁵

En un entorno de “código es ley”, la integridad del conjunto de reglas codificadas es de importancia primordial. Los conjuntos de reglas incompletas pueden permitir un comportamiento de usuario indeseable, pero no prohibido. Los incentivos para la votación estratégica, que impide el voto basado en la preferencia sincera, han sido expuestos en el código de DAO y podrían tener un impacto significativo en las decisiones de inversión de la organización.⁶

Además, los diseños podrían resultar inadecuados debido a las evoluciones tecnológicas. Los avances en la computación cuántica pueden provocar una amenaza creíble a los sistemas criptográficos de última generación que se utilizan para garantizar la integridad y confidencialidad de los datos almacenados en blockchain. Estos sistemas criptográficos se basan en problemas matemáticos que son casi imposibles de resolver con la informática convencional actual.

Las decisiones de diseño organizacional incluyen restricciones de acceso y diferenciación de roles. Restringir el acceso a la solución de blockchain a un conjunto de nodos preestablecidos y confiables (es decir, blockchains permitidas) puede tener importantes ventajas tales como el funcionamiento con participantes de confianza, protocolos de consenso más eficientes y mayores niveles de privacidad. Las blockchains permitidas son más adecuadas para establecer estructuras y procedimientos de gobernanza formales para reaccionar en caso de incidentes y para gestionar activamente las reglas codificadas. Por el contrario, las blockchain públicas están abiertas a todos para participar y revisar las reglas codificadas. Por lo tanto, los blockchains públicos tienden a reducir la barrera a la participación y pueden proteger usuarios contra desarrolladores dispuestos a tomar el control.

La diferenciación de las funciones y responsabilidades de los participantes (por ejemplo, sólo permitiendo que una autoridad de confianza realice el registro inicial de bienes raíces en un registro de tierras basado en blockchain, podría ser deseable. Varios autores también indicaron que blockchain podría no ser la tecnología más apropiada para una instalación en la que todos los participantes son sistemas de TI operados por la misma entidad del mundo real.⁷

Los enfoques que podrían mitigar parcialmente la arquitectura y el riesgo de diseño incluyen:

• Establecer requisitos y procesos de ingeniería que comprendan la obtención efectiva, el análisis y la priorización de los requisitos funcionales, técnicos y de cumplimiento del negocio. La confirmación formal y una actualización oportuna de las especificaciones de los requisitos se consideran las mejores prácticas. Se puede encontrar orientación en las especificaciones COBIT 5 para el dominio (BAI) Construir, Adquirir e Implementar y el de Gestión del proceso de definición de requisitos BAI02.
• Adoptar un enfoque de seguridad por diseño en el desarrollo de la solución de blockchain. Las medidas técnicas incluyen restringir el acceso a la blockchain (es decir, crear una blockchain autorizada) y establecer la diferenciación de roles (por ejemplo, soportar el uso de validadores de registros de confianza o registradores de activos). Las medidas empresariales podrían incluir estrictos procesos de integración y asegurar la extensión geográfica.
• Realización de rigurosas revisiones de código y pruebas de aceptación de las soluciones de blockchain
• Evaluar las evoluciones tecnológicas que podrían apoyar o afectar el logro de los objetivos de negocio
• Establecer estructuras y procedimientos formales de gobernanza para hacer frente a la evolución estratégica a largo plazo (por ejemplo, renovación tecnológica o revisión de las normas codificadas) e incidentes que deben resolverse a corto plazo

Riesgo de cumplimiento de TI

A medida que proliferan las regulaciones y aumentan las expectativas de las partes interesadas, existe un mayor riesgo de violar las regulaciones y los estándares de la industria que podrían afectar directamente la posición financiera, organización y reputación de los participantes. Ya se han identificado los desafíos de cumplimiento de los mecanismos de consenso y la seguridad de la información. La industria financiera tiene requisitos estrictos para la finalidad absoluta de una transacción, tal como se especifica en la Directiva de Finalidad de Liquidación (SFD). Los protocolos de consenso distribuidos que se basan en el trabajo computacional, como el protocolo de prueba de trabajo que subyace a bitcoin, típicamente proporcionan sólo finalidad probabilística. Técnicamente, las transacciones nunca son verdaderamente definitivas, ya que siempre existe la posibilidad de que se cree una cadena más larga que no incluya el bloque de la transacción. Sin embargo, a medida que se agregan más bloques, se vuelve menos económicamente viable y/o computacionalmente posible. Queda por probarse si la finalidad probabilística cumple con los requisitos de SFD.

Se ha establecido una amplia variedad de reglamentos específicos de la industria y generalmente aplicables con respecto a la confidencialidad, integridad y disponibilidad de los datos. En Estados Unidos, las soluciones de blockchain para compartir y registrar los registros de pacientes están sujetas a la Ley de Portabilidad y Responsabilidad de los Seguros de Salud (HIPAA por sus siglas en inglés), mientras que en Europa los requisitos de datos personales son fortalecidos y unificados por el GDPR. El GDPR incluye, entre otros, requisitos para la exportación de datos personales fuera de la Unión Europea.

La variedad de reglamentos puede dificultar la determinación de las regulaciones apropiadas para la solución de blockchain, ya que los participantes y las copias de los ledger de datos potencialmente sensibles pueden dispersarse en múltiples jurisdicciones con variaciones objetivos normativos.

Las medidas para hacer frente al riesgo de cumplimiento de TI como se aplica al blockchain incluyen:

• Revisión de los requisitos y estándares regulatorios más amplios, incluyendo tanto las normas específicas de la industria como las aplicables en general
• Seguimiento de la evolución de la reglamentación y la evolución de los procesos normativos
• Colaborar con los reguladores pertinentes, preferentemente en una fase temprana de la fase de diseño, para asegurar el cumplimiento de los objetivos políticos. Algunas autoridades han establecido marcos específicos (por ejemplo, los bancos de pruebas reguladores de la Autoridad de Conducta Financiera del Reino Unido) que permiten a los innovadores del sector financiero probar sus ideas sin incurrir inmediatamente en todas las consecuencias normativas normales.
• Definición de restricciones sobre el acceso a la solución de blockchain (por ejemplo, sólo permitiendo a socios identificados y revisados para cumplir con las regulaciones contra el lavado de dinero) y restringiendo las ubicaciones permitidas para los participantes que mantienen copias de los ledgers para evitar el incumplimiento en jurisdicciones específicas

Riesgo de terceros y proveedores

Mientras que el sistema bitcoin de dinero electrónico peer-to-peer ha sido diseñado para operar sin terceros de confianza, la mayoría de los proyectos blockchain se desarrollan en el contexto de una asociación estratégica con un proveedor de software blockchain. Asociado a estas asociaciones estratégicas es otro tipo de riesgo de terceros: el riesgo de que el proveedor no pueda ofrecer servicios seguros y confiables.

No es raro que el proveedor de software de blockchain sea una organización de puesta en marcha o ampliación de escala. Aunque las empresas en ciernes pueden ser exitosas, muchas empresas emergentes pueden tener problemas de evolución estratégica, problemas de cumplimiento normativo, condiciones financieras inestables y/o falta de recursos humanos adecuados. Por ejemplo, a mediados de 2015, Ripple, un proveedor de software emergente de blockchain, anunció que suspendería el desarrollo de su plataforma Codius.⁸ En el mismo año, el Departamento del Tesoro de Estados Unidos multó a Ripple por violar varios requisitos reglamentarios, entre ellos el no implementar programas adecuados contra el lavado de dinero en sus productos.⁹ Ripple ha acordado desde entonces acciones correctivas. El riesgo financiero también es una preocupación frecuente. Muchas empresas emergentes de blockchain fallan debido a la falta de fondos.¹⁰ Por último, atraer a expertos en blockchain y evitar el desgaste puede ser un desafío para las emergentes.¹¹

Las acciones para gestionar el riesgo asociado con los vendedores de software blockchain incluyen:

• Implementar estrategias de gestión de riesgos que cubran el ciclo de vida continuo de las relaciones de terceros, incluyendo la planificación, la diligencia debida, la selección de terceros y las fases de terminación. Los boletines 2013-29 y 2017—7 de la Oficina del Contralor de la Moneda (OCC, por sus siglas en inglés) proporcionan orientación sobre las relaciones de terceros en el sector financiero, mientras que la Ley de Tecnología de la Salud para la Salud Económica y Clínica (HITECH) explícitamente especifica lo requisitos para “socios comerciales” en la industria del cuidado de la salud.
• Realización de evaluaciones de cumplimiento postcontrato y programas de monitoreo continuo
• Gestionar activamente las relaciones de terceros para adquirir una visión de los objetivos estratégicos a largo plazo del tercero y establecer líneas de comunicación formales que pueden utilizarse en caso de que se materialice un riesgo importante para el proveedor
• Solicitar la auditoría interna y externa sobre el estado actual del tercero, sus controles y sus servicios, por ejemplo, Normas Internacionales de Aseguramiento (ISAE) 3402, Informes de Garantía sobre Controles en una Organización de Servicio.¹²

Integración de riesgo

Cuando las organizaciones se enfrentan a cambios tecnológicos que podrían perturbar sus productos, procesos y modelos de negocio, sus gerentes pueden sentirse tentados a reaccionar apresuradamente e impulsar una renovación tecnológica prematura. Estas organizaciones corren el riesgo de que su estrategia de renovación tecnológica sea inadecuada, ya sea por falta de integración con los sistemas existentes (perspectiva tecnológica) o procesos de negocio que no están adecuadamente adaptados (perspectiva de negocio). Un analista de Deutsche Bank concluyó que la lucha de los bancos tradicionales con los sistemas legados es un importante inhibidor de la innovación tecnológica.¹³ Las interfaces para integrar nuevas tecnologías en los sistemas existentes no pueden desarrollarse en un plazo aceptable. Otras propuestas (por ejemplo, la propuesta sueca de Lantmäteriet para un sistema de transacciones inmobiliarias) amplían los requisitos de integración incluso más allá de los sistemas internos.¹⁴

Además, pueden surgir problemas de integración cuando es necesaria la reconciliación entre varios sistemas de ledger basados en blockchain. Por ejemplo, en su visión utópica de los mercados de capitales que usan blockchain, Euroclear señala la necesidad de sincronización entre los ledger que poseen diferentes tipos de activos (por ejemplo, efectivo y derivados).¹⁵ En el mismo informe, Euroclear sostiene que algunos participantes en el mercado de capitales podrían ser desintermediados, lo que afectaría las actividades y los procesos de negocio de las restantes instituciones financieras.

Para mitigar el riesgo de integración, una organización puede:

• Centrarse en el desarrollo de procedimientos de prueba repetibles y extensos planes de pruebas, además de destacar la importancia de la ingeniería de requisitos
• Administre la habilitación del cambio organizacional como se detalla en BAI05 COBIT Manage proceso de habilitación del cambio organizacional para preparar y comprometer a las partes interesadas para un cambio de negocio
• Optar, siempre que sea posible, por la tecnología de blockchain generalmente aceptada y las normas de interfaz

Conclusión

Un análisis del riesgo de desarrollo de la solución de blockchain revela los beneficios potenciales de establecer estructuras y procedimientos formales de gobierno. Si bien este hallazgo contradice la premisa de base para blockchain que fue pionera en una cripto-moneda, puede resultar invaluable para la prevención de riesgos y la recuperación.

Al igual que con la tecnología blockchain, el marco regulador que la rodea aún no ha madurado completamente, lo que eleva la probabilidad de materialización del riesgo de cumplimiento. Además, blockchains permitidas con estricto acceso y gestión de acceso efectivo podría ser más apropiada para satisfacer los requerimientos de negocios, técnicos, de seguridad y cumplimiento de las soluciones de ledger contemporáneo.

Notas finales

¹ Finley, K.; “A $50 Million Hack Just Showed That the DAO Was All Too Human,” Wired, 19 June 2016, https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human
² ISACA, COBIT 5, USA, 2012
³ National Institute of Standards and Technology, Computer Security Incident Handling Guide Revision 2, NIST Special Publication 800-61, USA, 2012, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
⁴ Visa, “Visa Inc. at a Glance,” USA, 2015
⁵ Croman, K., et al.; On Scaling Decentralized Blockchains, 2016, http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf
⁶ Mark, D.; V. Zamfir; E. G. Gun Sirer; A Call for a Temporary Moratorium on “The DAO,” 26 May 2016, https://docs.google.com/document/d/10kTyCmGPhvZy94F7VWyS-dQ4lsBacR2dUgGTtV98C40/edit#
⁷ Buterin, V.; “On Public and Private Blockchains,” Ethereum blog, 7 August 2015, https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/
⁸ Glatz, F.; “The Quiet Death of Ripple’s Codius Project: Why Decentralized Infrastructure Has Still a Long Way to Go,” Medium, 13 June 2015, https://medium.com/@heckerhut/the-quiet-death-of-ripple-s-codiu-project-782c11a17c02
⁹ Department of the Treasury Financial Crimes Enforcement Network, “FinCEN Fines Ripple Labs Inc. in First Civil Enforcement Action Against a Virtual Currency Exchanger,” USA, 5 May 2015, https://www.fincen.gov/sites/default/files/shared/20150505.pdf
¹⁰ CB Insights, “Startup Failure Post-Mortems,” blog post, 10 February 2017, https://www.cbinsights.com/blog/startup-failure-post-mortem/
¹¹ Nash, K.; “Blockchain Experts, a Rare Breed, May Demand Big Bucks,” The Wall Street Journal, 12 May 2016
¹² International Standard on Assurance Engagements (ISAE) 3402, Assurance Reports on Controls and a Service Organization, 15 June 2011, www.ifac.org/system/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf
¹³ Allison, I.; “Deutsche Bank Mulls the Potential of Blockchain and the Problem of Legacy Systems,” International Business Times, 24 August 2015, www.ibtimes.co.uk/deutsche-bank-mulls-potential-blockchain-problem-legacy-systems-1516686
¹⁴ Lantmäteriet (The Swedish mapping, cadastre and land registration authority), Telia Company, ChromaWay, Kairos Future, “The Land Registry in the Bockchain,” July 2016, http://ica-it.org/pdf/Blockchain_Landregistry_Report.pdf
¹⁵ Wyman, Oliver; Blockchain in Capital Markets: The Prize and the Journey, Euroclear, February 2016, https://www.euroclear.com/dam/Brochures/BlockchainInCapitalMarkets-ThePrizeAndTheJourney.pdf