Workflow: Penetration Test Scheduling (Anual)

Runbook de seguridad. Regula el proceso anual de penetration testing (pen test) de la infraestructura y aplicaciones de LAWRA, S.R.L., cumpliendo con las mejores prácticas de NIST SP 800-115, SOC 2 CC7.2 y los requisitos de seguridad de los clientes Enterprise. Aprobado por la Asamblea en [__]. Versión: 1.0.

1. Trigger

Cadencia anual: el pen test externo debe completarse una vez por año calendario. La planificación se inicia 3 meses antes del mes de ejecución objetivo.
Trigger extraordinario: adición de una nueva funcionalidad crítica (autenticación, procesamiento de pagos, integración con nuevos sub-procesadores).
Trigger post-incidente: si se produce un incidente P0/P1 que sugiere una vulnerabilidad sistémica no detectada previamente.
Requerimiento de cliente Enterprise: un cliente exige evidencia de pen test como condición para contratar o renovar.

2. Roles y Responsabilidades (RACI)

Tarea	Responsable	Aprobador	Consultado	Informado
Planificación y coordinación del pen test	Luishy Medina (CTO)	Carlos Miranda Levy	Tanya Mejía-Ricart	CCO
Selección del vendor de pen test	Luishy Medina	Carlos Miranda Levy	Tanya (contratos)	—
Definición del scope	Luishy Medina	Carlos Miranda Levy	Ingeniero senior	—
Coordinación logística con el vendor	Luishy Medina	—	—	Carlos
Ejecución del pen test	Vendor externo contratado	—	Luishy (soporte técnico)	—
Revisión del informe de hallazgos	Luishy Medina	Carlos Miranda Levy	Tanya (si hay implicaciones legales)	—
Plan de remediación	Luishy Medina	Carlos Miranda Levy	Ingeniero responsable	CCO
Ejecución de la remediación	Ingeniero asignado + Luishy	Luishy	—	Carlos
Re-test de hallazgos críticos	Vendor externo o Luishy (según severidad)	Carlos Miranda Levy	—	—
Reporte final a la Asamblea	Luishy Medina	Carlos Miranda Levy	—	Todos los socios

3. Tipos de Pen Test

Tipo	Frecuencia	Objetivo	Ejecutado por
Externo (black-box)	Anual obligatorio	Simular ataque externo real sin conocimiento previo de la arquitectura	Vendor externo independiente
Externo (gray-box)	Según necesidad o post-incidente	Ataque externo con conocimiento parcial de la arquitectura	Vendor externo
Interno / revisión de código	Anual recomendado (puede coincidir con el externo)	Revisión de vulnerabilidades en el código propio + configuraciones internas	Luishy + ingeniero senior, o vendor
Social engineering	Cada 2 años o bajo demanda	Phishing, vishing, pretexting contra el equipo	Vendor externo especializado

4. Pasos Numerados

Fase 1 — Planificación (Meses -3 a -2 antes del pen test)

Paso 1 — Inicio de la planificación: Luishy inicia el proceso de planificación 3 meses antes del mes objetivo de ejecución. El calendario anual estándar:

Planificación: meses de octubre–noviembre (para pen test en enero).
Ejecución: enero (evita los meses de release más intensos del roadmap).
Remediación: febrero–marzo.
Re-test: marzo.
Reporte a la Asamblea: Q1 (primer trimestre).

Si las necesidades del negocio lo requieren, el mes de ejecución puede desplazarse. Lo importante es que no transcurran más de 13 meses entre pen tests.

Paso 2 — Definición del scope: Luishy documenta el alcance del pen test, que incluye:

Dentro del scope (in-scope):

Aplicación web lawra.io (todas las rutas públicas y autenticadas).
APIs de Firebase y Cloud Functions expuestas.
Autenticación (Firebase Auth, flujos de Google OAuth, token management).
AI Suite endpoints (si están accesibles externamente).
Configuraciones de Firestore rules (revisión de lógica de acceso).
Infraestructura de GitHub Pages (limitada a la superficie expuesta).

Fuera del scope (out-of-scope):

Infraestructura de Google / Firebase que no es gestionada por LAWRA (se acepta la responsabilidad de Google como proveedor).
Sistemas de terceros (proveedores de pago, AI providers) — estos tienen sus propios programas de seguridad.
Ataques de denegación de servicio (DoS/DDoS) — expresamente prohibidos en las reglas de engagement.
Ingeniería social contra clientes (solo contra el equipo de LAWRA, si se incluye en el scope).

Paso 3 — Reglas de engagement (Rules of Engagement): Luishy documenta y comparte con el vendor las reglas de engagement:

Período de prueba: fechas de inicio y fin autorizadas.
Horario autorizado (ej. lunes a viernes, 9 am–6 pm para minimizar impacto, o fuera de horas pico si se prefiere mayor realismo).
Restricciones: no DoS, no modificación de datos reales de clientes, no exfiltración de datos reales.
Punto de contacto de emergencia: Luishy Medina, teléfono y email, disponible 24/7 durante el período de prueba.
Procedimiento en caso de hallazgo crítico activo: el vendor notifica a Luishy de inmediato (no espera al informe final) si descubre una vulnerabilidad activamente explotable que exponga datos reales de clientes.

Fase 2 — Selección del Vendor (Meses -3 a -2)

Paso 4 — Identificación de vendors candidatos: Luishy identifica 2–3 vendors de pen test con:

Experiencia en aplicaciones web y APIs (SaaS, Firebase, cloud-native).
Certificaciones del equipo: OSCP, CEH, GPEN o equivalentes.
Experiencia previa en el sector legal tech o fintech (preferido).
Capacidad de emitir informe ejecutivo + informe técnico.
Confidencialidad: dispuestos a firmar NDA antes del engagement.

Paso 5 — Solicitud de propuestas y evaluación: Luishy envía a los vendors candidatos el scope documentado (Paso 2) y solicita propuesta con:

Metodología del pen test (OWASP Testing Guide, PTES, NIST SP 800-115, etc.).
Equipo asignado y certificaciones.
Entregables: informe ejecutivo + informe técnico + informe de re-test.
Precio.
Plazo de entrega del informe inicial (máximo 10 días hábiles post-ejecución).

Paso 6 — Selección y firma de NDA: Carlos Miranda Levy aprueba la selección del vendor. Tanya coordina la firma del NDA con el vendor antes de compartir cualquier información arquitectónica.

Paso 7 — Firma del contrato de pen test: Tanya prepara o revisa el contrato de servicios del vendor, asegurando que incluya:

Scope acordado.
Reglas de engagement.
Confidencialidad (NDA incorporado).
Obligación de entrega del informe en el plazo acordado.
Cláusula de no divulgación de hallazgos a terceros.
Procedimiento de notificación en hallazgo crítico activo (ver Paso 3).

Fase 3 — Preparación del Ambiente (Semana -1 antes del pen test)

Paso 8 — Habilitación técnica del vendor: Luishy prepara el ambiente para el pen test:

Para pen test black-box: no se comparte información adicional. El vendor actúa como un atacante externo.
Para pen test gray-box (si se acuerda): se comparte la arquitectura de alto nivel (diagrama), lista de endpoints principales, y las credenciales de una cuenta de prueba en cada nivel de acceso (Free, Basic, Premium, Enterprise).
Confirmar que el sistema de monitoreo de Lawra no bloqueará automáticamente las IPs del vendor (whitelisting durante el período acordado).
Documentar las IPs desde las que operará el vendor para no confundir el tráfico con un ataque real.

Paso 9 — Notificación interna: Luishy notifica al equipo de ingeniería que el pen test se realizará en las fechas acordadas. Esto evita falsas alarmas internas. Carlos Miranda Levy es notificado.

Fase 4 — Ejecución del Pen Test (Período acordado, típicamente 1–2 semanas)

Paso 10 — Ejecución por el vendor: El vendor ejecuta el pen test según la metodología acordada. Durante este período:

Luishy está disponible como punto de contacto para preguntas técnicas o si el vendor necesita acceso adicional previamente acordado.
Si el vendor descubre un hallazgo crítico activo (ej. acceso a datos reales de clientes), notifica a Luishy inmediatamente y Luishy activa el Plan de Respuesta a Incidentes.
El equipo de LAWRA no contraataca ni bloquea las pruebas del vendor durante el período autorizado.

Paso 11 — Monitoreo pasivo durante el pen test: Luishy monitorea pasivamente los sistemas durante el pen test para:

Confirmar que el vendor opera dentro del scope.
Detectar si hay actividad anómala adicional (ataque real que coincide con el pen test — aunque improbable, es posible).
Verificar que el ambiente de producción no esté siendo afectado de manera no controlada.

Fase 5 — Informe y Priorización de Hallazgos (Day 1–10 post-ejecución)

Paso 12 — Recepción del informe: El vendor entrega el informe dentro de los 10 días hábiles post-ejecución. El informe debe contener:

Resumen ejecutivo: nivel de riesgo general, hallazgos críticos en lenguaje no técnico.
Informe técnico: lista completa de hallazgos con clasificación de severidad (Crítico / Alto / Medio / Bajo / Informativo), descripción técnica detallada, pasos de reproducción, evidencia (capturas, payloads), y recomendación de remediación.
CVSS score para cada hallazgo (o equivalente).
Hallazgos positivos: áreas donde la seguridad es sólida (para motivación del equipo y evidencia de controles existentes).

Paso 13 — Revisión del informe con el vendor: Luishy y Carlos Miranda Levy revisan el informe con el vendor en una sesión de walkthrough (60–90 minutos). Preguntas sobre hallazgos específicos, contexto y posibles falsos positivos.

Paso 14 — Clasificación de hallazgos en el tracker: Luishy crea issues en el repositorio de GitHub (o sistema de tickets) para cada hallazgo con severidad Alta o Crítica, y un issue consolidado para hallazgos de severidad menor. Cada issue incluye: descripción, CVSS, link al informe, y asignación de responsable.

Fase 6 — Plan de Remediación (Day 10–25 post-ejecución)

Paso 15 — Priorización de la remediación:

Severidad	SLA de remediación	Acción
Crítico	< 7 días	Hotfix inmediato; notificar a Carlos; si hay datos de clientes expuestos → activar IRP
Alto	< 30 días	Incluir en el sprint inmediato siguiente
Medio	< 90 días	Priorizar en el roadmap
Bajo	< 180 días (o próxima revisión anual)	Documentar y priorizar según disponibilidad
Informativo	A discreción	Documentar como mejora futura

Paso 16 — Plan de remediación documentado: Luishy prepara el plan de remediación con: hallazgo, severidad, descripción del fix, responsable, fecha de remediación comprometida. Carlos Miranda Levy aprueba el plan.

Paso 17 — Ejecución de la remediación: Los ingenieros ejecutan los fixes siguiendo el Workflow: Code Deployment (orden 56). Los fixes de severidad Crítica/Alta se tratan como hotfixes o prioridades del sprint.

Fase 7 — Re-test y Cierre (Day 30–45 post-ejecución)

Paso 18 — Re-test: Una vez remediados los hallazgos Críticos y Altos, Luishy solicita al vendor un re-test de esos hallazgos específicos. El re-test confirma que los fixes son efectivos y los hallazgos están cerrados.

Para hallazgos Medios y Bajos, el re-test puede realizarse en el pen test del año siguiente (si están en el scope).

Paso 19 — Informe de re-test y cierre: El vendor emite un informe de re-test confirmando el estado de cada hallazgo (cerrado / parcialmente cerrado / abierto con justificación). Este informe es evidencia de SOC 2.

Paso 20 — Archivo de los informes: Luishy archiva en /security/pen-tests/{año}/:

Informe del pen test.
Informe del re-test.
Plan de remediación.
Tracker de hallazgos cerrados.

Paso 21 — Reporte a la Asamblea: Luishy presenta en la siguiente reunión de Asamblea:

Resumen del pen test: número de hallazgos por severidad.
Estado de la remediación.
Tendencia año a año (¿estamos mejorando?).
Inversión realizada en el pen test.
Fecha del próximo pen test.

5. Puntos de Decisión

Decisión	Opciones
A — ¿Hallazgo crítico activo durante el pen test?	Activar IRP inmediatamente; contener antes de continuar el pen test
B — ¿Hallazgo Crítico/Alto requiere hotfix inmediato?	Sí → tratarlo como P0/P1 en el Workflow Bug/Incident Triage
C — ¿Hallazgo confirmado en el re-test como no remediado?	Escalar plazo; Carlos evalúa si requiere acción extraordinaria o riesgo aceptado documentado

6. Outputs / Artifacts

Scope y reglas de engagement documentados.
Contrato con el vendor de pen test firmado.
Informe de pen test (ejecutivo + técnico).
Tracker de hallazgos con responsables y fechas.
Plan de remediación aprobado.
Informe de re-test.
Reporte de resultados a la Asamblea.

7. Checklist Final

8. Métricas / KPIs

Métrica	Objetivo
Pen tests anuales completados	1 (mínimo) por año
Hallazgos Críticos remediados en < 7 días	100 %
Hallazgos Altos remediados en < 30 días	100 %
Reducción de hallazgos año a año (misma severidad)	Tendencia decreciente
Hallazgos que se repiten en el pen test siguiente	0 (Críticos)

9. Referencias

Plan de Respuesta a Incidentes (orden 31) — activar si se descubre brecha durante el pen test
Workflow: Code Deployment (orden 56) — para el proceso de deploy de fixes
Workflow: Policy Review (orden 63) — el informe del pen test puede requerir actualizaciones de políticas
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
OWASP Testing Guide v4.2
SOC 2 CC7.2 — Evaluation and monitoring of security controls
ISO 27001 A.18.2.3 — Technical compliance review

10. Auditoría

Registro	Retención	Evidencia SOC 2
Scope y rules of engagement	5 años	CC7.2
Informe de pen test (ejecutivo + técnico)	5 años	CC7.2
Tracker de hallazgos + fechas de remediación	5 años	CC7.2
Informe de re-test	5 años	CC7.2
Contrato con el vendor de pen test	Vigencia + 3 años	CC9.2

Adoptado por la Asamblea General de Socios en fecha [__]. Próxima revisión: [fecha + 12 meses]. Próximo pen test programado: [mes del año siguiente].

Por LAWRA, S.R.L. — Gerente

Workflow: Penetration Test Scheduling (Anual)

Workflow: Penetration Test Scheduling (Anual)

1. Trigger

2. Roles y Responsabilidades (RACI)

3. Tipos de Pen Test

4. Pasos Numerados

Fase 1 — Planificación (Meses -3 a -2 antes del pen test)

Fase 2 — Selección del Vendor (Meses -3 a -2)

Fase 3 — Preparación del Ambiente (Semana -1 antes del pen test)

Fase 4 — Ejecución del Pen Test (Período acordado, típicamente 1–2 semanas)

Fase 5 — Informe y Priorización de Hallazgos (Day 1–10 post-ejecución)

Fase 6 — Plan de Remediación (Day 10–25 post-ejecución)

Fase 7 — Re-test y Cierre (Day 30–45 post-ejecución)

5. Puntos de Decisión

6. Outputs / Artifacts

7. Checklist Final

8. Métricas / KPIs

9. Referencias

10. Auditoría

Comments