Parte: 14 — GRC, riesgo y cumplimiento · Fuente: How to Measure Anything in Cybersecurity Risk (Hubbard & Seiersen) ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Aprender a evaluar el riesgo de seguridad de forma rigurosa, tanto con métodos cualitativos (matrices de probabilidad × impacto) como cuantitativos (SLE, ARO, ALE y modelos probabilísticos). Al terminar sabrás calcular la pérdida anual esperada de un escenario, decidir si un control se justifica económicamente y comunicar riesgo en términos que la dirección entiende: dinero y probabilidad, no colores.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Vocabulario: amenaza, vulnerabilidad, riesgo | Base común para razonar |
| 2 | Análisis cualitativo (matriz P×I) | Rápido para priorizar, útil como triaje |
| 3 | Análisis cuantitativo (SLE/ARO/ALE) | Traduce riesgo a euros |
| 4 | ROSI (retorno de la inversión en seguridad) | Justifica presupuesto |
| 5 | Estimación calibrada y rangos | Supera la falacia de la "medición imposible" |
| 6 | Simulación de Montecarlo | Modela incertidumbre realista |
| 7 | Tratamiento del riesgo | Del análisis a la decisión |
| 8 | Taxonomía y frontera del escenario | Evita tratar toda pérdida digital como vulnerabilidad o ataque |
| 9 | Promotor, liquidez y rug pull | El mecanismo de pérdida determina evidencia, dueño y tratamiento |
El riesgo combina escenarios, frecuencia y magnitud de pérdida bajo incertidumbre. Una matriz cualitativa facilita conversación, pero multiplicar ordinales no crea dinero ni probabilidad. El análisis cuantitativo explicita distribuciones y supuestos; tampoco elimina incertidumbre. Se selecciona método según decisión, datos y coste del análisis.
Dos riesgos quedan «altos» en una matriz. Uno puede interrumpir ventas por horas; otro generar daño regulatorio de cola larga. Rangos y escenarios separan decisiones. El resultado se presenta como distribución y sensibilidad, no como cifra exacta inventada.
TerraUSD (UST) es un contraste útil porque su colapso no debe reescribirse como «hackeo». La SEC describió UST como una supuesta stablecoin algorítmica y, después de un veredicto unánime por fraude de valores, informó en 2024 del acuerdo y de las declaraciones falsas sobre la estabilidad de UST y el uso de la blockchain de Terraform para liquidar transacciones. Esa fuente establece el resultado del litigio que documenta; no identifica por sí misma una CVE, malware, credencial robada o intrusión como causa del de-peg.
Antes de calcular frecuencia e impacto hay que nombrar el escenario sin mezclar mecanismos:
| Pregunta | Categoría posible | Evidencia mínima | Control que sí corresponde |
|---|---|---|---|
| ¿El mecanismo mantiene la paridad bajo ventas y contracción? | modelo, mercado y liquidez | reglas, reservas, profundidad, escenarios de estrés | límites, reservas, pruebas de estrés, gatillos de suspensión |
| ¿Una clave o cuenta puede cambiar parámetros críticos? | ciberseguridad y privilegios | IAM, aprobaciones, historial de cambios, firmas | mínimo privilegio, quórum, control de cambios, alertas |
| ¿La comunicación representa fielmente el mecanismo y sus intervenciones? | cumplimiento y conducta | versiones publicadas, evidencia independiente, aprobaciones | revisión legal, trazabilidad, divulgación y escalamiento |
| ¿Existe una discrepancia entre registro interno y estado externo? | integridad y conciliación | fuentes con semántica y fecha compatibles | conciliación independiente y gestión de excepciones |
Las categorías pueden coexistir, pero no son intercambiables. Ver un precio alejarse de la paridad demuestra la desviación en ese mercado y momento; no demuestra cómo se produjo, quién fue responsable ni si existió una intrusión. Del mismo modo, auditar código puede encontrar defectos técnicos, pero no valida por sí solo reservas, liquidez, incentivos o veracidad comercial.
Que una persona pierda valor no define el riesgo. Un fake token imita nombre o símbolo pero usa otro identificador; el control inicial es verificar red y contrato/mint. Un wallet drainer obtiene capacidad de gasto mediante una firma, permiso o secreto; el control se centra en autorización, custodia y respuesta. Un rug pull se refiere a promotores que retiran liquidez, venden posiciones controladas o abandonan el proyecto en contradicción con lo comunicado. El activo puede ser el correcto y la compra exactamente la pretendida.
| Escenario | Hecho inicial | Evidencia discriminante | Tratamientos posibles |
|---|---|---|---|
| token imitador | mismo ticker/logo, distinto ID | red, contrato/mint y canal canónico | allowlist, verificación de origen, bloqueo de suplantación |
| drainer | movimiento tras interacción | petición decodificada, firma/approval, spender, secreto y TXID | límites, revocación/migración, wallet separada, respuesta |
| rug pull de liquidez | profundidad desaparece tras promesa de lock | control de LP/admin, lock real, retiros y comunicaciones versionadas | due diligence, límites de exposición, gobierno y acción legal aplicable |
| caída de mercado | precio/volumen cambian | profundidad, concentración, noticias y flujos sin control demostrado | tolerancia, diversificación, stress y aceptación/evitación |
La alegación «liquidez bloqueada» debe traducirse en una propiedad verificable: qué activo o derecho controla el retiro, quién lo posee, hasta cuándo y bajo qué mecanismo puede cambiar. La SEC ha descrito en litigio cómo el control de LP tokens no bloqueados puede permitir retirar liquidez; esa fuente explica un mecanismo alegado, no autoriza a etiquetar cualquier proyecto o caída como fraude. En un análisis de riesgo se modelan frecuencia, magnitud, detectabilidad y dependencia de terceros; una investigación jurídica decide responsabilidad bajo la ley aplicable.
| Término | Definición |
|---|---|
| Escenario de pérdida | Cadena concreta que conecta amenaza, activo y consecuencia. |
| Incertidumbre | Falta de conocimiento representada y comunicada explícitamente. |
| Sensibilidad | Cambio del resultado al variar un supuesto. |
| Riesgo de modelo | Pérdida por supuestos, relaciones o implementación inadecuados para la decisión modelada. |
| Evento observable | Hecho medido; requiere análisis adicional antes de atribuir causa, intención o categoría de riesgo. |
| Riesgo de promotor | Pérdida por privilegios, concentración o conducta de quienes controlan el proyecto. |
| Riesgo de liquidez | Incapacidad de comprar o vender al tamaño/precio esperado sin impacto material. |
| LP token | Representación del aporte a un pool que puede otorgar derecho a retirar liquidez según el protocolo. |
Hay dominio cuando el alumno formula escenarios, evita falsa precisión, justifica método y compara tratamientos mediante riesgo residual.
SLE = Valor del activo (AV) × Factor de exposición (EF).ALE = SLE × ARO.ROSI = (ALE_antes − ALE_después − coste_control) / coste_control.numpy para una simulación de Montecarlo (pip install numpy).Escenario: ransomware contra la plataforma de e-commerce de "Ferretería del Sur S.A.".
Delimita el escenario: registra activo, actor o fuente de incertidumbre, evento, efecto, horizonte y evidencia. No uses «riesgo tecnológico» como categoría única: este caso modela indisponibilidad por ransomware, no fraude, liquidez ni un fallo de modelo financiero.
Valora el activo (AV): estima el valor de la plataforma en 500.000 €.
SLE = 500.000 × 0,6 = 300.000 €.ALE = 300.000 × 0,2 = 60.000 €/año.ALE_después = 300.000 × 0,05 = 15.000 €.(60.000 − 15.000 − 25.000) / 25.000 = 0,8 → 80% de retorno. El control se justifica.import numpy as np
n = 100000
av = 500000
ef = np.random.triangular(0.4, 0.6, 0.8, n)
aro = np.random.triangular(0.1, 0.2, 0.4, n)
ale = av * ef * aro
print(f"ALE medio: {ale.mean():,.0f} € P90: {np.percentile(ale, 90):,.0f} €")
SUR cotiza a 0,82 durante dos horas». Propón por separado hipótesis de liquidez, modelo,
operación, ciberseguridad y datos. Para cada una indica evidencia que la apoyaría y la
refutaría. La desviación de precio es el único hecho inicial.liquidity_case del laboratorio OrbitPup. Construye dos escenarios cuantitativos separados: pérdida por drainer y pérdida por retiro de liquidez. No mezcles frecuencias, controles ni evidencias.Entrega una hoja de cálculo de análisis de riesgo cuantitativo para tres escenarios (ransomware, brecha de datos, caída de disponibilidad) con SLE, ARO, ALE, control propuesto, ALE residual y ROSI de cada uno, más una matriz cualitativa 5×5 que los ubique.
Criterio de aceptación: las fórmulas están enlazadas (no números pegados), cada control muestra un ROSI calculado, y la recomendación de tratamiento (mitigar/transferir/aceptar) es coherente con el ROSI y la posición en la matriz.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| ALE ridículamente preciso (60.000,00 €) | Falsa precisión; usa rangos con intervalos de confianza |
| Matriz de colores sin acción | La matriz es triaje, no decisión final; complementa con cuantitativo |
| ROSI negativo pero se compra el control | Decisión emocional; revisa si hay factor regulatorio o reputacional no modelado |
| "El riesgo no se puede medir" | Falacia; toda reducción de incertidumbre es medición (Hubbard) |
| Ignorar el riesgo residual | Documenta y acepta formalmente lo que queda |
| Clasificar un de-peg como «hackeo» sin evidencia | Se confundió el efecto con la causa; abre hipótesis separadas y exige artefactos específicos |
| Usar «blockchain» como garantía de estabilidad | La integridad de ciertas transacciones no elimina riesgo de mercado, liquidez, modelo o gobierno |
| Llamar rug pull a cualquier pérdida | El efecto no identifica el mecanismo; verifica control, retiro/venta/abandono y promesas relevantes. |
| Tratar auditoría de código como due diligence completa | Código no prueba identidad, distribución, liquidez, claves administrativas ni veracidad comercial. |
❓ ¿Cuantitativo o cualitativo? Ambos. El cualitativo prioriza rápido; el cuantitativo justifica inversiones y se comunica con la dirección. Empieza cualitativo, profundiza cuantitativo en los riesgos top.
❓ ¿De dónde saco el ARO si no tengo datos? De informes del sector (Verizon DBIR), datos históricos internos y estimación calibrada por expertos. La incertidumbre se modela, no se elimina.
❓ ¿Qué es FAIR? Un marco cuantitativo estándar que descompone el riesgo en frecuencia y magnitud de pérdida. Complementa muy bien SLE/ARO/ALE.
❓ ¿La matriz 5×5 tiene problemas? Sí: distorsiona por rangos arbitrarios y "colores". Úsala como triaje, no como única base de decisión (crítica de Hubbard).
❓ ¿Terra/UST pertenece a una clase de ciberseguridad? Solo como ejercicio de límites y gobierno del riesgo. El caso ayuda a no inventar una causa técnica: la pérdida económica, el diseño de estabilización, las afirmaciones comerciales y un incidente de seguridad requieren preguntas y evidencias distintas.
❓ ¿Un proyecto con contrato verificado no puede hacer rug pull? La verificación de código responde qué fuente corresponde al bytecode publicado bajo cierto alcance. No elimina claves de administración, control de liquidez, concentración, actualizaciones, frontends ni afirmaciones falsas. Es una evidencia útil dentro de un escenario, no una garantía del proyecto.
Clase 276 — Gobernanza de la seguridad de la información