Los dos primeros artículos de esta serie explicaron por qué las instituciones cripto necesitan pruebas de penetración blockchain (Parte 1) y qué es esta disciplina (Parte 2). Este artículo aborda cómo se prepara y ejecuta de forma segura un compromiso 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 compromiso que se muestra a continuación.
Web3 eleva la exigencia de las pruebas en producción de una manera específica: las acciones on-chain suelen ser irreversibles, la actividad de prueba a menudo es visible públicamente on-chain, y los sistemas dentro del alcance pueden mover fondos reales. Por ello, las salvaguardas siguientes otorgan mayor peso a la elección del entorno, los límites de valor, el manejo de claves y la conciliación que un compromiso convencional.
Blockchain Penetration Testing
Encuentre la vía de entrada, a través de contratos, nodos, API y nube
Las RoE como autoridad operativa
Según el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST), las RoE (Rules of Engagement, reglas de compromiso) establecen las directrices y restricciones para las pruebas de seguridad [1]. En un compromiso 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 con seguridad su 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 material.
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 firma o retiro, o evaluar una integración con 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 normalmente incluye servicios web, móviles y de interfaz de programación de aplicaciones (API) orientados al cliente; cuentas en la nube y gestión de identidades y accesos (IAM); sistemas y secretos de integración y entrega continuas (CI/CD); consolas operativas; wallets y flujos de aprobación; sistemas de firma; servicios de ledger y de 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 concilian 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 bajos privilegios o una identidad presuntamente comprometida.
Cada sistema, cuenta, interfaz y actividad dentro del alcance debe tener un propietario designado y una vía de autorización clara. Lo mismo se aplica a las dependencias de terceros, incluidos los proveedores de custodia, las interfaces de wallet, los proveedores de llamada a procedimiento remoto (RPC), las plataformas de software como servicio (SaaS), los proveedores de identidad, los alojadores de código y los servicios administrados. 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 la actividad contra los sistemas del proveedor.
En conjunto, el objetivo, el alcance y la vía de autorización establecen lo que el equipo puede evaluar. El siguiente paso registra cómo el equipo puede realizar esa evaluación.
Límites operativos
Los límites operativos son las restricciones por escrito que rigen la ejecución una vez acordado el mandato. Distinguen lo que está dentro del alcance de lo que la actividad permite: un servicio de retiro en producción puede estar dentro del alcance para validar la vía 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 compromiso en producción, la institución y el equipo de pruebas necesitan 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 puede 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 cuestiones fundamentales durante el compromiso.
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 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 las 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 van a probar. |
| Autorización | Autoridad por escrito, identidades de prueba, vías de acceso aprobadas y aprobaciones de proveedores 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 el acceso demostrado, la escalada de privilegios o la simulación controlada de un 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, periodos 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 | Wallets y cuentas designadas, destinos incluidos en lista blanca, valor máximo de prueba, participantes en la aprobación, comportamiento esperado de la política, pasos de conciliación y el punto más avanzado de 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 material, autoridad designada para pausar o reanudar la prueba, y la observabilidad y el manejo de alertas esperados para una transmisión de transacción pública aprobada. |
| Manejo de la evidencia | Evidencia mínima necesaria, minimización y redacción de datos, cifrado, destinatarios aprobados, periodo de retención, confirmación de destrucción, y el hash de transacción y los metadatos de red vinculados a la aprobación interna y a la evidencia del ledger 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 del servicio en vivo
El entorno operativo es el sistema desplegado y la actividad de negocio a su alrededor: los límites de confianza, los flujos de fondos, las dependencias de servicio, los flujos de trabajo operativos y las personas responsables de cada componente. Es el contexto en el que un hallazgo de la 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 en la nube o una debilidad en el flujo de aprobación pueden afectar los datos de 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 wallets en funcionamiento, la prueba también debe coexistir con las operaciones de trading, pagos, depósitos, retiros, liquidación y soporte.
Una visión actualizada 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 periodos de alto volumen, la actividad de hot wallets y otros eventos operativos. Las señales de salud del servicio observadas durante la prueba deben incluir los volúmenes de transacciones y de API, los tiempos de respuesta, las tasas de error, la profundidad de las colas, la salud del servicio de firma y la disponibilidad del servicio de wallet. 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 las transacciones. Las RoE registran el entorno de prueba aprobado, las identidades de prueba, los pasos permitidos dentro de un flujo de firma o retiro, y las salvaguardas que se aplican a cualquier escenario de validación controlada. Estos parámetros mantienen la evaluación centrada en los controles de la institución mientras protegen la actividad normal de clientes y operaciones.
La Ley de Resiliencia Operativa Digital (DORA) de la Unión Europea ofrece un punto de referencia útil de alta regulación. Para las entidades financieras seleccionadas para pruebas de penetración basadas en amenazas, el artículo 26 exige que la prueba cubra funciones críticas o importantes y se realice sobre los sistemas de producción que las soportan, 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 realizar pruebas en producción; cada institución sigue necesitando su propia autoridad, salvaguardas y las aprobaciones legales y contractuales aplicables.
Esta 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 firma y retiro, el acceso privilegiado en producción, el manejo de datos de clientes y las operaciones de ledger.
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 financiero o de un cliente. El riesgo no es solo la interrupción técnica: puede incluir el movimiento no autorizado de fondos, saldos incorrectos, la exposición de datos sensibles o la confusión entre la actividad de prueba y un incidente real. Cuando un fallo de control puede afectar a los fondos, la reversión puede ser difícil o imposible, por lo que estos límites deben impedir que una prueba produzca cualquier movimiento de fondos no intencionado o no autorizado.
Los flujos de firma y retiro requieren escenarios controlados que validen cómo la institución autentica una solicitud, aplica la política, enruta las aprobaciones y concilia 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 avanzado permitido del flujo de trabajo: creación de la solicitud, decisión de política, presentación de la aprobación, solicitud de firma, decisión de liberación o conciliació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 de ledger: 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, y se minimizan y redactan en la evidencia, que se mantiene 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 proporcionan 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 constituyen el modelo operativo en vivo del compromiso. Conectan al propietario del servicio, al equipo de operaciones de seguridad, a la función de respuesta a incidentes y al líder de la prueba mientras esta está en curso.
Este modelo es necesario porque la actividad de prueba esperada y un evento de seguridad genuino pueden parecer similares. Si el monitoreo, las notificaciones o las decisiones de pausa no están claros, las pruebas pueden retrasar la respuesta a incidentes o generar incertidumbre sobre si se requiere una acción en producción.
El modelo de comunicaciones identifica quién conoce el plan de prueba completo, quién recibe avisos sensibles al tiempo 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 correctas. Cuando un escenario controlado ejercita un flujo de trabajo relacionado con transacciones, el plan también cubre las notificaciones relevantes y las alertas esperadas de los proveedores de custodia, wallet, cribado de transacciones y monitoreo. Un contacto de seguridad separado y una autoridad de pausa designada permanecen localizables 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 errores, aumentos inesperados en el tiempo de respuesta del percentil 95 (p95) o en la profundidad de la cola, actividad sospechosa de cuenta o wallet, discrepancias materiales de conciliació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 negociación de activos virtuales mantengan un monitoreo 24/7 y procedimientos de escalamiento documentados, y que realicen simulacros de emergencia y de continuidad del negocio con terceros relevantes [3]. Estas referencias regulatorias son ilustrativas, no asesoría legal; la aplicabilidad es específica de cada 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 trasladar un hallazgo verificado a remediación. Aparece aquí porque estas decisiones pertenecen a la coordinación en vivo, y no a la definición previa del alcance o a la preparación de producción.
El mismo modelo rige los hallazgos críticos: una vía demostrada hacia el 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 vía 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 e informa 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 material debe utilizar primero el canal de seguridad protegido, seguido de un registro escrito acordado que no exponga detalles innecesarios de explotación.
Una vez que un hallazgo se ha contenido y asignado, el valor del compromiso depende de si la institución puede convertir ese resultado en una mejora de control verificada.
Remediación, reprueba y regreso 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 compromiso reduce el riesgo o solo produce un informe. Un hallazgo sin propietario, vía de remediación y condición de validación puede permanecer abierto mientras la misma vía de ataque persiste en producción.
Antes de que comience la prueba, se debe identificar cómo entran los hallazgos en los flujos de trabajo de ingeniería, nube, operaciones de wallet 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 una transacción, 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 ledger; cualquier acceso, aprobación o configuración de prueba temporal creados para el escenario se retiran. La evidencia se conserva solo durante el periodo acordado, y luego se destruye de forma segura o se devuelve.
El resultado no es una lista de vulnerabilidades, sino un conjunto de controles probados, remediados y reprobados que puede respaldar la siguiente 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 compromiso de pruebas de penetración se convierte en algo más que un ejercicio técnico. Se convierte en una manera controlada de comprender 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 definició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 Móvil
- Parte 6: Seguridad en la Nube y CI/CD: Superficies de Ataque de las Operaciones Automatizadas
- Parte 7: Seguridad del Plano de Control de Tesorería: Aprobaciones de Firma y Retiro
- Parte 8: Seguridad del Ledger del Exchange: Vías de Robo y Lógica del Plano de Datos
La página principal de Pruebas de Penetración Blockchain ofrece la visión a nivel de compromiso.
Best Security Auditor for Web3
Valide el diseño, el código y la lógica de negocio antes del lanzamiento
Referencias
Numeradas en orden de primera aparición.
- Instituto Nacional de Estándares y Tecnología, Rules of Engagement (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 Negociación de Activos Virtuales Autorizados sobre la Custodia de Activos Virtuales (15 de agosto de 2025).
