Conceptos

Business Continuity Plan (BCP) and Business Impact Analysis (BIA)

#defense#governance#grc#risk

En ciberseguridad, BCP se activa cuando el incidente tiene severidad suficiente y la organización necesita “cambiar de modo” (priorizar continuidad sobre procesos normales), sin perder…

Definición

  • BCP (Business Continuity Plan / Plan de Continuidad de Negocio): plan para mantener o restaurar funciones críticas durante y después de un incidente, con foco en volver a BAU (Business as Usual).
  • BIA (Business Impact Analysis / Análisis de Impacto Empresarial): análisis para entender qué procesos/activos son críticos, cuál es el impacto de su caída y qué objetivos (tiempo/datos) deben cumplirse para recuperarlos.

En ciberseguridad, BCP se activa cuando el incidente tiene severidad suficiente y la organización necesita “cambiar de modo” (priorizar continuidad sobre procesos normales), sin perder control ni trazabilidad.

Contexto

El RAW plantea un punto clave: cuando se invoca BCP, a menudo se omiten pasos habituales (p.ej., gestión de cambios). Esto acelera la respuesta, pero eleva el riesgo de:

  • perder trazabilidad,
  • introducir cambios no reproducibles,
  • empeorar el alcance del incidente si nadie “es dueño” de una acción.

Por eso, BCP debe ir acompañado de documentación estricta y roles claros, y no debería invocarse antes de una contención razonable (ver Incident Response and Incident Management).

Desarrollo (MIT-style)

1) Cuándo invocar BCP (según RAW)

El RAW indica que BCP no se invoca siempre: típicamente solo cuando la gravedad es suficiente y hay necesidad de volver a BAU con acciones rápidas.

Puntos operativos (RAW):

  • Invocar BCP puede permitir saltarse procesos de cambio normales.
  • Por impacto, suele estar restringido a alta dirección o roles con autoridad explícita.
  • No debe invocarse antes de contención (si no se detuvo el acceso/propagación, “recuperar” es rehacer trabajo).

2) BCP vs DRP (Disaster Recovery Plan)

El RAW distingue entre:

  • DRP (Disaster Recovery Plan / Plan de Recuperación ante Desastres): foco en la recuperación técnica (servicios, infraestructura, datos).
  • BCP: más exhaustivo: además de recuperación técnica incluye comunicación, coordinación y continuidad operativa.

Regla práctica: el DRP suele estar contenido dentro del BCP (BCP orquesta; DRP ejecuta recuperación técnica).

3) Cómo crear un BCP (pasos del RAW)

  1. Realizar un BIA: planificar para escenarios severos; combinar medidas cualitativas y cuantitativas.
  2. Definir acciones de recuperación: alternativas por escenario (p.ej., failover a DR, restauración, rebuild).
  3. Planificar estructura del equipo BCP: quién documenta, quién comunica, quién aprueba y quién ejecuta.
  4. Probar el plan: formación + tabletop exercise.

Ampliación práctica:

  • Inventariar dependencias (identidad, red, DNS, proveedores, third parties) y “puntos únicos de fallo”.
  • Preparar runbooks de recuperación (pasos técnicos reproducibles) y validar accesos/credenciales de emergencia.
  • Probar no solo “si funciona”, sino si el equipo sabe ejecutarlo bajo estrés.

4) Métricas típicas (RAW) y cómo se relacionan

El RAW lista métricas usadas para cuantificar objetivos:

  • RPO (Recovery Point Objective / Objetivo de Punto de Recuperación): cuánta pérdida de datos es aceptable.
  • RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación): tiempo para recuperar hardware/servicio a un estado operativo.
  • WRT (Work Recovery Time / Tiempo de recuperación del trabajo): tiempo para recuperar software/datos y volver a operación efectiva.
  • MTD (Maximum Tolerable Downtime / Tiempo de Inactividad Máximo Tolerable): downtime máximo aceptable.
    • Regla del RAW: RTO + WRT no debería superar el MTD.
  • MTBF (Mean Time Between Failures / Tiempo medio entre fallos): tiempo promedio entre fallos/incidentess.
  • MTTR (Mean Time To Repair / Tiempo medio de reparación): tiempo promedio para recuperar.

Relacionado:

5) Documentación de acciones (según RAW)

El RAW insiste en que, al invocar BCP y saltarse procesos, la documentación es “lo que reemplaza” esos controles:

  • Permite rehacer pasos y entender decisiones.
  • Reduce el riesgo de “acciones discutidas pero no ejecutadas” por falta de owner.
  • Soporta handoff y lecciones aprendidas.

Plantilla mínima de action log (RAW):

Campo Descripción
requested_at_utc Hora en que se solicitó la acción (UTC)
action Qué se hizo (cambio/actualización)
rationale Por qué se hizo
approver Quién aprueba
owner Quién ejecuta
performed_at_utc Hora de ejecución (UTC)
observed_effect Qué cambió tras ejecutar

6) Lecciones aprendidas

El RAW conecta documentación con la revisión posterior:

  • identificar qué falló (control/proceso/tecnología),
  • definir acciones preventivas,
  • reducir probabilidad y/o impacto de futuros incidentes.

Ejemplos

Ejemplo 1 — Incidente severo con necesidad de continuidad (RAW, adaptado)

  1. Contener (evitar propagación/acceso del atacante).
  2. Activar BCP si severidad lo requiere.
  3. Ejecutar recuperación técnica (DRP) y comunicación (BCP).
  4. Documentar cada acción con aprobador/owner/efecto.
  5. Volver a BAU y capturar lecciones aprendidas.

Pitfalls / Errores comunes

  • Invocar BCP antes de contención: “recuperar” sin frenar el incidente suele fallar (RAW).
  • Tratar BCP como solo DR técnico: se pierde coordinación/comunicación.
  • Métricas irreales o no probadas: RTO/RPO “de papel”.
  • No tener roles/owners claros: acciones sin ejecución o duplicadas.
  • Documentación pobre: no hay trazabilidad ni post-mortem sólido.

Diagrama

flowchart TD
  BIA[BIA: impacto + criticidad + objetivos] --> MET[RTO/RPO/WRT/MTD]
  IR[Incidente] --> CON[Contención]
  CON --> DEC{¿Severidad\nrequiere BCP?}
  DEC -->|Sí| BCP[Invocar BCP]
  BCP --> DRP[Ejecutar DRP (recuperación técnica)]
  BCP --> COMMS[Comunicación + coordinación]
  DRP --> BAU[Volver a BAU]
  COMMS --> BAU
  BAU --> LL[Lecciones aprendidas]

Referencias

  1. TryHackMe — Intro IR/IM (prerrequisito citado en RAW): https://tryhackme.com/jr/introtoirandim
  2. IETF RFC 3227 — Guidelines for Evidence Collection and Archiving (referenciado en la misma entrada RAW): https://datatracker.ietf.org/doc/html/rfc3227#section-2.1