Los primeros dos artículos de esta serie explican por qué las instituciones cripto necesitan pruebas de penetración blockchain (Parte 1) y en qué consiste esta disciplina (Parte 2). Este artículo aborda cómo se prepara y ejecuta de forma segura un proyecto institucional: las reglas de compromiso, las salvaguardas de seguridad en producción, y la remediación y reprueba que convierten los hallazgos en soluciones—el ciclo de vida del proyecto que se muestra a continuación.
Web3 eleva las apuestas de las pruebas en producción de una manera específica: las acciones en cadena suelen ser irreversibles, la actividad de prueba suele ser visible públicamente en la cadena, y los sistemas dentro del alcance pueden mover fondos reales. Por lo tanto, las salvaguardas descritas a continuación otorgan mayor peso a la elección del entorno, los límites de valor, el manejo de claves y la reconciliación que un proyecto convencional.
RoE como autoridad operativa
Según el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST), las RoE establecen las pautas y restricciones para las pruebas de seguridad [1]. Para un proyecto institucional, convierten la decisión de realizar pruebas en un mandato autorizado: un objetivo definido, un alcance definido y una autoridad designada para actuar.
Ese mandato importa porque un equipo de pruebas no puede inferir de forma segura la autoridad a partir de un contrato o una lista de activos. Sin una decisión compartida sobre el riesgo que se está evaluando, los sistemas involucrados y las personas responsables de ellos, el equipo podría probar la ruta equivocada, excluir una dependencia crítica o carecer de la autoridad para validar un hallazgo relevante.
El punto de partida es la decisión de negocio que la prueba pretende respaldar. Un objetivo puede referirse a la exposición pública antes del lanzamiento. Puede centrarse en la autorización de clientes y de la interfaz de programación de aplicaciones (API), o en la accesibilidad de sistemas privilegiados en la nube y operativos. También puede probar un flujo de trabajo de firma o retiro, o evaluar una integración de terceros. Ese objetivo identifica los sistemas que importan, el riesgo a reducir y el resultado que la dirección necesita para tomar una decisión.
El objetivo debe traducirse en un alcance que siga el modelo operativo. En una institución cripto, esto suele incluir servicios web, móviles y de interfaz de programación de aplicaciones (API) orientados al cliente; cuentas en la nube y gestión de identidad y acceso (IAM); sistemas y secretos de integración continua y entrega continua (CI/CD); consolas operativas; billeteras y flujos de aprobación; sistemas de firma; servicios de libro mayor y retiro; y los proveedores que los conectan. En conjunto, estos componentes rigen cómo los clientes y los equipos internos inician, aprueban, firman, liberan y reconcilian las acciones relacionadas con fondos. La institución y el equipo de pruebas también deben acordar la perspectiva relevante: un atacante externo, un usuario normal, un socio, un empleado con pocos privilegios o una identidad supuestamente comprometida.
Cada sistema, cuenta, interfaz y actividad dentro del alcance debe tener un propietario designado y una ruta de autorización clara. Lo mismo se aplica a las dependencias de terceros, incluidos los proveedores de custodia, interfaces de billetera, proveedores de llamadas a procedimientos remotos (RPC), plataformas de software como servicio (SaaS), proveedores de identidad, alojamiento de código y servicios gestionados. Probar un entorno propiedad de un proveedor requiere el permiso por escrito de ese proveedor; la autorización de la institución por sí sola puede no autorizar actividad contra los sistemas del proveedor.
En conjunto, el objetivo, el alcance y la ruta de autorización establecen lo que el equipo puede evaluar. El siguiente paso registra cómo el equipo puede llevar a cabo esa evaluación.
Límites operativos
Los límites operativos son las restricciones escritas que rigen la ejecución una vez acordado el mandato. Distinguen lo que está dentro del alcance de lo que está permitido: un servicio de retiro en producción puede estar dentro del alcance para la validación de la ruta de autorización, mientras que los retiros reales de clientes, la extracción de claves privadas, los cambios de persistencia y los ataques que generan carga permanecen prohibidos.
Esta distinción evita que la incertidumbre se convierta en riesgo operativo. Durante un proyecto en producción, la institución y el equipo de pruebas deben saber de antemano qué técnicas están permitidas, cuándo debe detenerse la actividad, quién puede tomar esa decisión y cómo se debe manejar la evidencia. De lo contrario, incluso una prueba autorizada puede generar un impacto evitable en el servicio o en los clientes.
Las RoE deben registrar esas decisiones antes de que comience la prueba. Además, el documento debe ser lo suficientemente preciso para que ambas partes puedan actuar sin tener que reabrir preguntas fundamentales durante el proyecto.
La siguiente tabla traduce el mandato de prueba establecido anteriormente en un registro práctico de RoE. Agrupa las decisiones que deben resolverse antes de la prueba: qué se está evaluando, quién está autorizado, qué actividades y límites se aplican, cómo coordinan las partes y cómo se maneja la evidencia. No es una lista de verificación genérica para copiar sin cambios; los valores registrados deben reflejar el modelo operativo de la institución, la perspectiva de la prueba y el riesgo de producción.
| Tema de RoE | Decisión a registrar antes de la prueba |
|---|---|
| Objetivo y alcance | La decisión de negocio, los sistemas e interfaces dentro del alcance, los propietarios y las perspectivas de atacante que se probarán. |
| Autorización | Autoridad por escrito, identidades de prueba, rutas de acceso aprobadas y aprobaciones del proveedor para entornos de terceros. |
| Método de prueba y finalización | Técnicas permitidas y el punto en el que el equipo debe detenerse, como acceso demostrado, escalamiento de privilegios o una simulación controlada de flujo de trabajo. |
| Límites operativos | Ventanas de prueba, límites de tasa de solicitudes y concurrencia, límites de operaciones de cuenta, límites de acceso a datos, períodos de congelación de cambios y, cuando un escenario aprobado utilice una transacción, la red permitida, las direcciones de prueba, los tipos de transacción, el valor máximo de prueba y el presupuesto de gas. |
| Actividad prohibida | Los ejemplos incluyen pruebas de denegación de servicio, ingeniería social, movimientos reales de activos de clientes, exportación de claves privadas, persistencia o cambios de producción no aprobados. |
| Flujos de trabajo sensibles | Billeteras y cuentas designadas, destinos en lista blanca, valor máximo de prueba, participantes en la aprobación, comportamiento esperado de la política, pasos de reconciliación y el punto más lejano en la cadena de control de transacciones al que puede llegar la validación. |
| Comunicaciones y pausa | Modelo de aviso rutinario, canal de seguridad protegido, contactos de escalamiento, umbral de hallazgo relevante, autoridad designada para pausar o reanudar la prueba, y la observabilidad y el manejo de alertas esperados para una difusión aprobada de transacción pública. |
| Manejo de evidencia | Evidencia mínima necesaria, minimización y redacción de datos, cifrado, destinatarios aprobados, período de retención, confirmación de destrucción, y hash de transacción y metadatos de red vinculados a la aprobación interna y la evidencia del libro mayor para una transacción de prueba aprobada. |
Con los límites de ejecución acordados, la institución puede preparar los sistemas desplegados y las condiciones operativas que la prueba encontrará.
Entorno operativo y protección de servicios en vivo
El entorno operativo es el sistema desplegado y la actividad de negocio que lo rodea: límites de confianza, flujos de fondos, dependencias de servicio, flujos de trabajo operativos y las personas responsables de cada componente. Es el contexto en el que un hallazgo de prueba adquiere su significado real.
Ese contexto importa porque la misma debilidad técnica puede tener consecuencias muy diferentes. Un problema de API, un permiso de nube o una debilidad en el flujo de aprobación pueden afectar los datos de los clientes, las operaciones internas, la autoridad de firma, los cambios de saldo o los retiros. Para un exchange, empresa de pagos, custodio o proveedor de billeteras en funcionamiento, las pruebas también deben coexistir con las operaciones de trading, pagos, depósitos, retiros, liquidación y soporte.
Una vista actual debe cubrir el inventario de activos y servicios, la arquitectura y los puntos de integración, el modelo de nube e identidad, los flujos de trabajo operativos y las dependencias de terceros. La planificación también debe identificar las ventanas de negocio relevantes, los lanzamientos planificados, las congelaciones de cambios, los períodos de alto volumen, la actividad de billeteras calientes y otros eventos operativos. Las señales de salud del servicio observadas durante la prueba deben incluir los volúmenes de transacciones y API, los tiempos de respuesta, las tasas de error, la profundidad de la cola, la salud del servicio de firma y la disponibilidad del servicio de billetera. El entorno operativo incluye los servicios de producción, las identidades, los flujos de trabajo operativos y las dependencias externas utilizadas para iniciar y controlar transacciones. Las RoE registran el entorno de prueba aprobado, las identidades de prueba, los pasos permitidos dentro de un flujo de trabajo de firma o retiro, y las salvaguardas que se aplican a cualquier escenario de validación controlado. Estos parámetros mantienen la evaluación centrada en los controles de la institución mientras protegen la actividad normal de clientes y operativa.
La Ley de Resiliencia Operativa Digital (DORA) de la Unión Europea proporciona un punto de referencia útil de alta regulación. Para las entidades financieras seleccionadas para pruebas de penetración dirigidas por amenazas, el artículo 26 exige que la prueba cubra las funciones críticas o importantes y se realice sobre los sistemas de producción que las respaldan, incluidos los servicios relevantes de tecnología de la información y la comunicación (TIC) subcontratados [2]. Esto no constituye una autorización general para pruebas en producción; cada institución sigue necesitando su propia autoridad, salvaguardas y las aprobaciones legales y contractuales aplicables.
Esta línea base de producción permite a la institución aplicar salvaguardas más específicas a los flujos de trabajo que pueden afectar directamente a los fondos o al acceso de los clientes.
Límites para flujos de trabajo sensibles
Los flujos de trabajo sensibles son los sistemas y acciones cuyo funcionamiento normal puede afectar directamente a los fondos, al acceso de los clientes o a la integridad de los registros. Incluyen los flujos de trabajo de firma y retiro, el acceso privilegiado a producción, el manejo de datos de clientes y las operaciones del libro mayor.
Estos flujos de trabajo necesitan límites más estrictos porque, de lo contrario, una prueba realista puede pasar de validar un control a modificar un resultado de cliente o financiero. El riesgo no es solo la interrupción técnica: puede incluir movimientos no autorizados de fondos, saldos incorrectos, exposición de datos sensibles o confusión entre la actividad de prueba y un incidente real. Cuando una falla de control puede afectar a los fondos, la reversión puede ser difícil o imposible, por lo que estos límites deben evitar que una prueba produzca cualquier movimiento de fondos no intencionado o no autorizado.
Los flujos de trabajo de firma y retiro requieren escenarios controlados que validen cómo la institución autentica una solicitud, aplica políticas, enruta las aprobaciones y reconcilia el resultado. Las RoE identifican las cuentas de prueba designadas, los participantes autorizados, el comportamiento esperado de la política, un límite superior para el escenario y la evidencia necesaria para validar el flujo de trabajo. Luego registran el paso más lejano permitido del flujo de trabajo: creación de la solicitud, decisión de política, visualización de la aprobación, solicitud de firma, decisión de liberación o reconciliación. Las identidades de prueba se aprovisionan, utilizan y retiran a través del proceso de acceso acordado. La misma disciplina se aplica al acceso privilegiado, a los datos de clientes y a las operaciones del libro mayor: el modelo de acceso, el comportamiento esperado del sistema y el límite de evidencia se acuerdan antes de que comience la prueba; se accede a los datos de clientes solo cuando es necesario, se minimizan y redactan en la evidencia, y se mantienen dentro del repositorio de evidencia aprobado.
Estos controles permiten probar rutas sensibles en producción sin tratarlas como funciones de aplicación ordinarias. También dan a las operaciones y al equipo de pruebas una base común para coordinar la actividad en vivo.
Pruebas y coordinación
Las pruebas y la coordinación son el modelo operativo en vivo del proyecto. Conectan al propietario del servicio, al equipo de operaciones de seguridad, a la función de respuesta a incidentes y al líder de pruebas mientras la prueba está en curso.
Este modelo es necesario porque la actividad de prueba esperada y un evento de seguridad genuino pueden parecerse. Si el monitoreo, las notificaciones o las decisiones de pausa no son claras, las pruebas pueden retrasar la respuesta a incidentes o generar incertidumbre sobre si se requiere una acción de producción.
El modelo de comunicaciones identifica quién conoce el plan completo de pruebas, quién recibe avisos urgentes y quién puede pausar o reanudar la actividad. Varía según el objetivo: algunas pruebas requieren una coordinación estrecha con el centro de operaciones de seguridad (SOC) en torno a sistemas sensibles, mientras que las pruebas de divulgación limitada evalúan si el monitoreo detecta la actividad y si el escalamiento llega a las personas adecuadas. Cuando un escenario controlado ejerce un flujo de trabajo relacionado con transacciones, el plan también cubre las notificaciones relevantes y las alertas esperadas de los proveedores de custodia, billetera, detección de transacciones y monitoreo. Un contacto de seguridad separado y una autoridad de pausa designada permanecen accesibles en todo momento. El propietario del servicio y el equipo de pruebas acuerdan criterios de detención medibles, como la desviación del presupuesto de error, aumentos inesperados en el tiempo de respuesta del percentil 95 (p95) o en la profundidad de la cola, actividad sospechosa de cuenta o billetera, discrepancias significativas de reconciliación, o una alerta de seguridad no planificada.
Esta preparación también fortalece la resiliencia operativa. La Comisión de Valores y Futuros de Hong Kong (SFC) espera que los operadores de plataformas de comercio de activos virtuales mantengan un monitoreo 24/7 y procedimientos de escalamiento documentados, y que realicen simulacros de emergencia y continuidad de negocio con terceros relevantes [3]. Estas referencias regulatorias son ilustrativas, no constituyen asesoría legal; la aplicabilidad depende de la jurisdicción y debe confirmarse con asesoría legal.
El diagrama muestra el bucle de control que se aplica mientras la prueba está en curso. Su punto central es que los límites de las RoE no terminan con la autorización: el monitoreo y el canal de seguridad convierten esos límites en decisiones de reanudar, pausar, contener o transferir un hallazgo verificado a la remediación. Aparece aquí porque estas decisiones pertenecen a la coordinación en vivo, en lugar de a la definición previa del alcance o a la preparación de producción.
El mismo modelo rige los hallazgos críticos: una ruta demostrada hacia un movimiento no autorizado de fondos, el compromiso de la autoridad de firma o de un plano de control de producción, la exposición de datos altamente sensibles de clientes, o un riesgo material para un servicio crítico. La ruta de respuesta debe identificar el umbral de escalamiento, las personas que clasifican el hallazgo, la autoridad para pausar la actividad relevante, y el proceso de contención, remediación y validación. El equipo de pruebas de penetración demuestra y reporta el problema; la institución conserva la autoridad para las decisiones de producción, las comunicaciones con los clientes y la remediación. Una notificación de hallazgo relevante debe utilizar primero el canal de seguridad protegido, seguido de un registro escrito acordado que no exponga detalles innecesarios de la explotación.
Una vez que un hallazgo se contiene y se asigna, el valor del proyecto depende de si la institución puede convertir ese resultado en una mejora de control verificada.
Remediación, reprueba y vuelta a la normalidad
La remediación y la reprueba son el proceso de cierre que convierte una debilidad demostrada en una mejora validada. Volver a la normalidad forma parte del mismo proceso: el acceso de prueba, los escenarios controlados y la evidencia recopilada no deben convertirse en un nuevo riesgo de larga duración.
Esta etapa final determina si el proyecto reduce el riesgo o solo produce un informe. Un hallazgo sin propietario, ruta de remediación y condición de validación puede permanecer abierto mientras la misma ruta de ataque persiste en producción.
Antes de que comiencen las pruebas, se debe identificar cómo ingresan los hallazgos a los flujos de trabajo de ingeniería, nube, operaciones de billetera o control de negocio; quién es el propietario de la remediación; y qué hallazgos requieren una reprueba. Al cierre, las identidades de prueba temporales, los permisos y los escenarios controlados vuelven a su configuración prevista, y los propietarios del servicio confirman que los indicadores de salud relevantes permanecen dentro de su rango esperado. El registro final vincula cada hallazgo con su evidencia, impacto, propietario, plan de remediación y condición de reprueba. Para un escenario controlado relacionado con transacciones, también vincula la referencia del flujo de trabajo, la identidad de prueba, la marca de tiempo, el registro de aprobación y el asiento resultante en el libro mayor; cualquier acceso, aprobación o configuración de prueba temporal creada para el escenario se retira. La evidencia se conserva solo durante el período acordado, y luego se destruye o devuelve de forma segura.
El resultado no es una lista de vulnerabilidades, sino un conjunto de controles probados, remediados y reprobados que pueden respaldar la próxima decisión operativa de la institución.
Conclusión
Prepararse para las pruebas de penetración blockchain es una tarea institucional. La institución define el objetivo, el contexto operativo, la autoridad, las restricciones de servicio y el modelo de respuesta; el equipo de pruebas aplica la validación adversarial a ese entorno preparado.
Con esos elementos en su lugar, un proyecto de pruebas de penetración se convierte en algo más que un ejercicio técnico. Se convierte en una forma controlada de entender cómo resisten los sistemas desplegados, las personas y los procesos de la institución bajo ataque.
BlockSec ayuda a las instituciones a preparar y ejecutar ese proceso: definir el alcance, mapear el entorno operativo, establecer las RoE y las salvaguardas de producción, y convertir los hallazgos en controles remediados y reprobados. Para planificar las reglas de compromiso y los controles de seguridad de producción para su próxima prueba, solicite una conversación de alcance; hay más información disponible bajo solicitud.
Continúe con la serie:
También en esta serie, próximamente:
- Parte 5: Seguridad de autorización y firma: web, dApps y
- Parte 6: Seguridad de nube y CI/CD: superficies de ataque de operaciones automatizadas
- Parte 7: Seguridad del plano de control de tesorería: aprobaciones de firma y retiro
- Parte 8: Seguridad del libro mayor de exchanges: rutas de robo y lógica del plano de datos
La página principal de Pruebas de Penetración Blockchain ofrece la vista a nivel de proyecto.
Referencias
Numeradas en orden de primera aparición.
- Instituto Nacional de Estándares y Tecnología, Reglas de Compromiso (ROE), Glosario CSRC.
- Unión Europea, Reglamento (UE) 2022/2554 — Ley de Resiliencia Operativa Digital (DORA), Artículo 26.
- Comisión de Valores y Futuros de Hong Kong, Circular a los Operadores de Plataformas de Comercio de Activos Virtuales Licenciados sobre la Custodia de Activos Virtuales (15 de agosto de 2025).
