Consejos y buenas prácticas
Cada dominio B.1-B.8 incluye bloques de buenas prácticas (32+ en total) y ejemplos. Se recopilan aquí en tres lentes: prácticas recomendadas por dominio, errores comunes (incluidas las banderas auto-FAIL) y cómo prepararse por función.
Cada dominio B.1-B.8 incluye bloques de buenas prácticas (32+ en total) y ejemplos. Se recopilan aquí en tres lentes: prácticas recomendadas por dominio, errores comunes (incluidas las banderas auto-FAIL) y cómo prepararse por función.
Buenas prácticas por dominio
B.1 — Inventario y clasificación
B.1 — Inventario y clasificación
Mantenga el inventario CCM en una herramienta CMDB o DevSecOps, no en una hoja de cálculo no administrada; cada entrada bajo control de versión con un revisor de seguridad obligatorio en caso de cambio.
Para L2/L3, agregue el descubrimiento automatizado de CCM en producción mediante escaneo de código e introspección en tiempo de ejecución: un inventario manual no escala.
Mantener diagramas CME como código (PlantUML, Mermaid, Structurizr) con validación automatizada contra la topología de red real; actualice el flujo de datos en la misma solicitud de extracción que el cambio de código.
Ejecute la revisión de inventario trimestral como un taller multifuncional con seguridad, operaciones y desarrollo: muestra cambios no documentados de manera más confiable que la tarea de un solo propietario.
B.2 — Generación
Utilice un grupo de entropía de varias fuentes independientes (hardware TRNG + OS DRBG + entropía de fluctuación) incluso en el nivel 1: defensa en profundidad.
Ejecutar monitoreo continuo del estado de la salida RNG en producción (pruebas de estado NIST SP 800-90B) con alertas sobre modos de falla; obligatorio para L2+.
Ejecute la ceremonia al estilo 'dos teclados', con comandos ingresados alternativamente por dos participantes independientes para que nadie pueda ejecutar el script unilateralmente.
Documente un ensayo previo a la ceremonia en un entorno de prueba dentro de los días 7 posteriores a la ceremonia de producción y las condiciones explícitas de interrupción para detenerlo.
B.3 — Almacenamiento
Utilice cifrado de sobre: el HSM contiene el MEK, que cifra el DEK, que cifra el CCM, por lo que puede rotar el MEK sin volver a cifrar todos los CCM.
Utilice bibliotecas AEAD de alto nivel (libsodium, AWS Encryption SDK, Google Tink), no API de bajo nivel; documente la respuesta a la manipulación si falla la verificación de la etiqueta AEAD.
Utilice el almacenamiento de respaldo WORM (Escribir una vez, leer muchas) para evidencia de manipulación; Revise los ratios de niveles trimestralmente a medida que crece AUM.
Haga una copia de seguridad no solo del CCM sino también de los metadatos (rutas de derivación, configuración de múltiples firmas, registros de ceremonias) para que la recuperación sea autónoma.
B.4 — Uso
Utilice un HSM cuya interfaz PKCS#11 no pueda exportar la clave privada por diseño (solo firmar, descifrar, verificar).
Haga que la aprobación UI sea una solicitud separada del inicio UI; esto reduce el riesgo de suplantación de identidad de UI; agregue una vista previa obligatoria de la dirección de destino con una diferencia con la lista blanca.
Prefiera OAuth 2.0 + DPoP (RFC 9449) a los tokens al portador; agregue detección de anomalías en los patrones de sesión (geovelocidad, cambio de dispositivo, hora del día).
Para PAM, admite rotura de cristales con revisión obligatoria posterior al evento; registrar la causa, el resultado esperado y la justificación en los metadatos de la sesión.
B.5 — Ciclo de vida
Utilice cifrado de sobre (B.3.2) para una rotación eficiente de MEK sin volver a cifrar todos los CCM; añadir una 'rotación defensiva' después de acontecimientos ambiguos.
Conciliación posterior a la rotación de documentos: confirme que el monitoreo de solo observación, la contabilidad y las copias de seguridad hayan cambiado a la nueva clave.
Generar previamente direcciones de respaldo para transferencias de emergencia en la ceremonia y almacenarlas aparte de las principales; Mantenga plantillas de comunicación en varios idiomas.
Para la recuperación, utilice Shamir's Secret Sharing con acciones m-of-n en todas las ubicaciones y jurisdicciones; verificar la accesibilidad física de los materiales de recuperación anualmente.
B.6 — Arquitectura de billetera
Para cadenas sin m-of-n nativo, utilice esquemas de umbral (MPC-CMP, GG18/20); para multi-firma nativa (Bitcoin, GnosisSafe), utilice solo implementaciones auditadas y probadas en batalla.
Incluir titulares de claves de respaldo predefinidos en la lista de titulares de claves, activados mediante un procedimiento documentado (B.5.3).
Utilice nodos de blockchain independientes para monitoreo de solo observación (no compartido con la infraestructura de firma) y verifique varios nodos para detectar una reorganización.
Aislar niveles en cuentas de nube separadas (SCP de organizaciones AWS); ejecute transiciones de frío a calor a una hora programada fija para que los observadores puedan distinguir lo normal de lo anómalo.
B.7 — Detección de compromiso
Utilice un SIEM con encadenamiento hash nativo (Splunk, Elastic con un nivel congelado); Ejecute una verificación de integridad de toda la cadena de registro mensualmente.
Para L3, ancle el hash de la cadena de registro a una cadena de bloques pública (por ejemplo, a través de OpenTimestamps).
Utilice nodos de blockchain independientes para la reconciliación; establezca una tolerancia de retraso de propagación (por ejemplo, +/-2 minutos), pero no mayor, para que la detección no se diluya.
Coloque previamente plantillas bilingües de comunicación de incidentes y una lista explícita de "no hacer" (sin declaraciones públicas antes de la divulgación coordinada, sin contacto con los medios sin aprobación legal).
B.8 — Personal y acceso
Utilizar proveedores de verificación de antecedentes autorizados con una metodología pública; Para L3 considere una evaluación psicológica para aquellos con acceso a las mayores explotaciones de almacenamiento en frío.
Utilice la gestión de identidades con análisis SoD integrado; hacer que la revisión de acceso trimestral pruebe escenarios de conflicto explícitos, no un sello de aprobación.
Documentar excepciones justificadas por el negocio con validez limitada en el tiempo, no acceso permanente.
Incluir escenarios de simulación realistas en la formación (phishing, ingeniería social); utilizar repetición espaciada (volver a entrenar en los meses 3 y 6) y un mentor durante el período de prueba.
Errores comunes
Error común
auto-FAILError común- B.1auto-FAIL
Un inventario CCM obsoleto que no se actualiza tras el cambio viola B.1.1, un requisito crítico totalmente prohibido: no se permite control de compensación, falla automática.
- B.3auto-FAIL
Intentar cerrar un Requisito Crítico con un control compensador donde está prohibido: para B.1.1, B.1.2, B.5.2, B.7.3 nunca se permite un CC; para B.2.1, B.3.1, B.4.1, B.8.1 solo en L1 con aprobación del Consejo.
- B.4auto-FAIL
Cuentas privilegiadas compartidas sin atribución individual y sin PAM para L2+ violan B.4.4; cada acción privilegiada debe estar ligada a una persona específica.
- B.8auto-FAIL
Ninguna separación de funciones o detección de conflictos viola B.8.1: un requisito crítico restringido: una persona no debe iniciar ni aprobar operaciones CCM.
- B.3auto-FAIL
El texto sin formato CCM en env vars, config, repos, logs o localStorage, y una clave privada que abandona su límite de confianza para firmar, viola directamente B.3.1/B.4.1.
- B.5auto-FAIL
Ningún procedimiento de revocación de clave viola B.5.2, un requisito crítico totalmente prohibido: sin revocación, la protección de CCM es imposible.
- B.7auto-FAIL
Ningún monitoreo de solo observación o conciliación de la actividad en cadena viola B.7.3, un requisito crítico totalmente prohibido y el principal mecanismo de detección de incidentes de seguridad.
- B.1Error común
Confiar en el traspaso para los requisitos críticos: sin línea de base (PCI DSS, ГОСТ 57580, CCSS, SOC 2, MiCA) renuncia a las pruebas completas de enfoque definido de los ocho requisitos críticos.
- Error común
Una narrativa ROC sin tamaños de muestra y notas de Examinar / Entrevistar / Observar / Seguimiento según el requisito no pasará la revisión del Consejo QA.
- Error común
Mostrar una insignia 'genérica' sin segmento, nivel y validez es engañoso: el resumen LVCS publicado siempre registra el segmento C.1-C.4, el nivel L1-L3 y el período de validez.
Cómo preparar
Comience con el tema principal (alcance, definición de CCM, metodología §0.7), luego lea su segmento en la Sección C y la Sección D para conocer el nivel objetivo y los índices locales requeridos.
Ejecute SAQ-C1 (Anexo 4, §A4.8) para una autoevaluación antes de invitar a un auditor; esto muestra los requisitos no vigentes y las marcas automáticas-FAIL con anticipación.
Reúna los certificados de referencia (PCI DSS, ГОСТ 57580, SOC 2) con anticipación: el traspaso acelera la auditoría de los requisitos de infraestructura compartida pero nunca cubre los ocho requisitos críticos.
Lea el estándar completo, luego use el Anexo 3 (Plantilla ROC), especialmente la Hoja de trabajo de evaluación de requisitos §A3.7 y la Validación de transferencia §A3.6.
Aplique la lista de verificación de criptografía del auditor (elementos del Anexo 2 §A2.8, 9) durante la revisión técnica y registre los tamaños de muestra según §0.14.2.
Confirmar el alcance de la acreditación CCSAC por segmento (C.1-C.4) y nivel (L1-L3) antes de aceptar un compromiso; para L2, un CC requiere la revisión por pares de otro CCSAC.
Mantener retención de documentos: hojas de trabajo ROC y CC — años 7 en CCSAC; AOC — 7 años; papeles de trabajo - años 7.
Lea el Portada y la Sección D (metodología y niveles), los párrafos de Propósito de los dominios B y el Anexo 5 (AOC): su resumen público es lo que llega al registro LVCS.
Sección B: Bloques de buenas prácticas + errores comunes
Cómo preparar
Cada dominio B.1-B.8 incluye bloques de buenas prácticas (32+ en total) y ejemplos. Se recopilan aquí en tres lentes: prácticas recomendadas por dominio, errores comunes (incluidas las banderas auto-FAIL) y cómo prepararse por función.