Plan de remediación — OmniControl
Acciones correctivas y de mejora propuestas por el equipo auditor, organizadas por fase PHVA del SGSI. Cubre 20 controles con recomendación estructurada (Conformes excluidos).
Planear
Contexto, partes interesadas y requisitos4 acciones🎯 Aprobar formalmente la Política de Seguridad de la Información, designar DPO mediante acto administrativo y conformar Comité SGSI con frecuencia trimestral.
Ver pasos detallados (6) y criterios de cierre (4)
- 1.Revisar y completar las secciones pendientes del borrador POL-SGSI-001 v0.3 (Compromiso de Dirección, DPO, Comité, sanciones).
- 2.Convocar Comité de Gerencia para aprobación formal con firma de María Elena Ramírez.
- 3.Emitir resolución/acto administrativo de designación del DPO (interno o asesor externo contratado).
- 4.Publicar la política en el sistema documental con identificador POL-SGSI-001 v1.0 y comunicar a todo el equipo.
- 5.Establecer el Comité SGSI con frecuencia trimestral mínima y agenda tipo (revisión de riesgos, KPIs, incidentes).
- 6.Documentar el acta de constitución del Comité y la primera revisión.
- Documento POL-SGSI-001 v1.0 firmado por Gerencia en el sistema documental con fecha verificable.
- Acto administrativo de designación del DPO archivado.
- Acta del primer Comité SGSI realizado con asistencia y decisiones.
- Política comunicada y aceptada por todo el personal (registro firmado).
🎯 Formalizar el inventario de activos: añadir propietario, criticidad y clasificación por cada entrada; completar los 7+ activos faltantes; establecer revisión trimestral.
Ver pasos detallados (7) y criterios de cierre (5)
- 1.Migrar inventario desde Google Sheets a una herramienta colaborativa con control de versiones (Notion, Confluence o repositorio Git en YAML).
- 2.Definir esquema mínimo: nombre, tipo, ubicación, propietario, criticidad (B/M/A/Catastrófico), clasificación de información (Pública/Interna/Confidencial/Restringida).
- 3.Realizar inventario completo con apoyo de AWS Resource Groups Tag Editor y GitHub Repos List.
- 4.Cruzar inventario con activos reales en AWS y GitHub mediante script periódico.
- 5.Designar propietario por activo (no todos al Desarrollador Fullstack).
- 6.Establecer revisión trimestral en agenda del Comité SGSI.
- 7.Vincular inventario con la Matriz de Riesgos y los Threat Models.
- Inventario con ≥25 activos (cubriendo los 7 faltantes detectados).
- 100% de los activos con propietario asignado.
- 100% de los activos con clasificación de información.
- Acta de revisión trimestral programada.
- Script o procedimiento de validación contra AWS/GitHub.
🎯 Extender el Threat Modeling STRIDE a los módulos críticos (DIAN, RNDC, GPS, multi-tenant) y establecer trazabilidad con el backlog de desarrollo como criterio bloqueante.
Ver pasos detallados (7) y criterios de cierre (4)
- 1.Adoptar plantilla STRIDE estándar (o usar herramienta como Microsoft Threat Modeling Tool / OWASP Threat Dragon).
- 2.Realizar sesión de modelado para módulo de aislamiento multi-tenant (prioridad por riesgo Catastrófico).
- 3.Replicar sesión para módulos DIAN (facturación electrónica) y RNDC (manifiestos).
- 4.Documentar telemetría GPS y módulo de nómina electrónica.
- 5.Para cada amenaza identificada, crear ticket en el backlog con prefijo 'SEC-' y criterio de aceptación de seguridad.
- 6.Definir como Definition of Done que las nuevas features pasen Threat Modeling antes de iniciar desarrollo.
- 7.Versionar los documentos de Threat Modeling en el repositorio safite-erp bajo /docs/security/.
- 5 documentos de Threat Modeling publicados (auth, multi-tenant, DIAN, RNDC, GPS).
- Al menos 80% de las amenazas STRIDE con ticket en backlog con label 'SEC-'.
- Definition of Done actualizada e incluye criterios de seguridad.
- Acta de revisión técnica del Threat Modeling con el equipo.
🎯 Implementar módulo ARCO automatizado y añadir checkbox de consentimiento expreso + enlace a política de tratamiento en todos los formularios de captura de PII.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Redactar Política de Tratamiento de Datos y Aviso de Privacidad (revisar con asesor legal).
- 2.Publicar la política en una URL pública estable (ej. omnicontrol.co/privacidad).
- 3.Añadir checkbox obligatorio en formulario de registro de conductores con texto: 'Acepto el tratamiento de mis datos personales según la Política…' + enlace.
- 4.Crear tabla `consentimientos` (titular_id, política_versión, fecha, IP, user_agent) y registrar al hacer submit.
- 5.Replicar en todos los formularios que capturan PII (clientes, empleados).
- 6.Diseñar módulo ARCO autoservicio en Configuración → Mis datos: ver datos, solicitar rectificación/eliminación.
- 7.Implementar workflow backend con plazos automáticos (10 días hábiles consultas, 15 días reclamos).
- 8.Documentar el proceso ARCO interno con responsable asignado.
- Checkbox de consentimiento presente en todos los formularios con PII (verificable por inspección visual).
- Tabla `consentimientos` con registros de los últimos 30 días.
- Política de Tratamiento publicada en URL accesible.
- Módulo ARCO funcional con al menos un caso de prueba end-to-end.
- Procedimiento ARCO documentado con responsable y plazos.
Hacer
Implementación de controles de desarrollo seguro8 acciones🎯 Integrar SAST (CodeQL), SCA (Dependabot bloqueante) y DAST (OWASP ZAP) como stages obligatorios en GitHub Actions con configuración de required checks en branch protection.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Habilitar Secret Scanning + Push Protection en Settings → Code security.
- 2.Habilitar Dependabot Security Updates (auto-PRs para CVEs).
- 3.Crear workflow .github/workflows/security.yml con stages: CodeQL (SAST), Snyk o npm audit (SCA).
- 4.Configurar política: build falla si hay hallazgos Critical/High sin mitigar.
- 5.Añadir stage de DAST (OWASP ZAP baseline scan) corriendo contra ambiente de staging.
- 6.Configurar Branch Protection en main: required status checks (CodeQL, Dependabot, tests), require PR review.
- 7.Actualizar Definition of Done con criterio 'Sin hallazgos High/Critical en SAST/SCA'.
- 8.Capacitar al equipo en la nueva política (sesión de 1h).
- Workflow security.yml ejecutándose en cada PR a main.
- Branch Protection visible en Settings → Branches con required checks.
- Definition of Done actualizada y comunicada.
- Al menos 3 PRs recientes con resultado verde de los nuevos stages.
- Secret Scanning habilitado (visible en Security tab).
🎯 Implementar rutina automatizada de Data Masking para poblar Staging con datos pseudonimizados; prohibir volcado directo desde producción mediante política técnica.
Ver pasos detallados (7) y criterios de cierre (5)
- 1.Definir política de Data Masking por columna sensible: cédulas → hash determinístico, nombres → faker, teléfonos → patrón fijo, salarios → rangos categóricos.
- 2.Implementar script de masking (Python + Faker o pg_anonymizer extension de PostgreSQL).
- 3.Programar AWS Lambda + EventBridge: snapshot diario de prod → masking → restore en staging-rds-1.
- 4.Cifrar staging-rds-1 en reposo con KMS (control H-05 relacionado).
- 5.Aplicar política IAM que niegue acceso del Desarrollador a producción RDS.
- 6.Documentar la política de Data Masking y publicarla como POL-DM-001.
- 7.Validar: ejecutar queries en staging y confirmar que cédulas/nombres están enmascarados.
- Script de masking ejecutándose diariamente vía Lambda/EventBridge.
- Query SELECT * FROM conductores LIMIT 5 en staging muestra cédulas hash/sintéticas.
- Tabla pg_catalog.data_masking_policies con políticas activas.
- Política POL-DM-001 publicada y firmada.
- Acceso de Desarrollador a producción RDS denegado por IAM.
🎯 Implementar MFA en el ERP/TMS para todos los usuarios finales (TOTP como mínimo) y forzarlo en roles con acceso a facturación, nómina y GPS.
Ver pasos detallados (9) y criterios de cierre (5)
- 1.Diseñar flujo de enrolment de TOTP (Google Authenticator, Authy) con QR code en Configuración.
- 2.Implementar verificación TOTP con librería como otplib o speakeasy en backend.
- 3.Crear tabla `user_mfa` con secret cifrado en columna y backup codes.
- 4.Forzar enrolment en primer login para usuarios con rol admin de tenant.
- 5.Añadir paso de verificación TOTP en login después de validar usuario/contraseña.
- 6.Implementar rate limiting específico para intentos de TOTP (5 intentos/15 min).
- 7.Documentar el procedimiento de recuperación (backup codes + reset por admin).
- 8.Considerar opción de WebAuthn (FIDO2) para una segunda fase.
- 9.Comunicar a los 60 clientes el nuevo flujo con campaña previa.
- Login del ERP solicita TOTP después de credenciales.
- Configuración → Seguridad muestra opciones MFA activas (no 'Próximamente').
- Política técnica que impide deshabilitar MFA en roles admin.
- Al menos 80% de usuarios admin con MFA enrolado dentro de 30 días.
- Backup codes generables y verificables.
🎯 Habilitar AWS IAM Identity Center (SSO) con credenciales temporales, retirar Access Keys estáticas a usuarios humanos y documentar procedimiento de break-glass con cuenta dedicada.
Ver pasos detallados (9) y criterios de cierre (5)
- 1.Habilitar AWS IAM Identity Center (anteriormente AWS SSO) en la cuenta omnicontrol-prod.
- 2.Configurar conexión con Google Workspace o crear usuarios internos.
- 3.Definir permission sets: Admin, PowerUser, Developer, ReadOnly, Auditor.
- 4.Migrar los 3 usuarios humanos (Carlos, María Elena, Andrés) a SSO con credenciales temporales (1-8h).
- 5.Retirar Access Keys estáticas de usuarios humanos.
- 6.Para github-actions-deploy: migrar a OIDC (IAM role asumido desde GitHub Actions sin keys) usando aws-actions/configure-aws-credentials.
- 7.Crear cuenta break-glass dedicada con MFA hardware (YubiKey), credenciales en sobre sellado físico.
- 8.Documentar procedimiento de break-glass en POL-PAM-001 con responsable y registro obligatorio.
- 9.Configurar alertas en CloudWatch para uso de la cuenta break-glass.
- AWS IAM Identity Center habilitado y operativo.
- 0 Access Keys estáticas asignadas a usuarios humanos.
- github-actions-deploy migrado a OIDC (sin keys).
- Cuenta break-glass creada con MFA hardware y procedimiento documentado.
- Política POL-PAM-001 firmada.
🎯 Implementar gestión de endpoints mediante una solución MDM corporativa (Jamf/Intune) con políticas DLP básicas: cifrado obligatorio, bloqueo de USB, prohibición de sync a cuentas personales.
Ver pasos detallados (8) y criterios de cierre (6)
- 1.Redactar y firmar Política BYOD/DLP corporativa con cláusulas de aceptación.
- 2.Adquirir suscripción MDM (Jamf para macOS, Microsoft Intune para Windows, o JumpCloud multiplataforma).
- 3.Enrolar los 3 equipos del equipo en MDM (proceso voluntario en BYOD, contrato si rechazo).
- 4.Aplicar políticas: FileVault/BitLocker obligatorio, bloqueo de USB no autorizado, restricción de sync a cuentas personales.
- 5.Desplegar EDR (CrowdStrike, SentinelOne, o Microsoft Defender for Endpoint).
- 6.Configurar alertas DLP por descargas masivas, transferencias a dominios no corporativos.
- 7.Programar wipe remoto al desvincular colaboradores.
- 8.Considerar evolución a equipos corporativos para roles con acceso a PII (DPO, Líder técnico).
- Política BYOD firmada por 3/3 miembros.
- MDM enrolment de 3/3 equipos.
- EDR activo en 3/3 endpoints con telemetría.
- Compliance score ≥ 70% (5/7 controles activos).
- Cifrado de disco activo en 3/3.
- Procedimiento de wipe remoto documentado.
🎯 Endurecer rate limiting en /auth/login con backoff exponencial y sanear mensajes de error 5xx para no exponer el motor de base de datos ni stack traces.
Ver pasos detallados (7) y criterios de cierre (4)
- 1.Implementar rate limiting por usuario+IP en /auth/login: 5 intentos en 1 min, bloqueo de 15 min con backoff exponencial.
- 2.Añadir headers X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After en respuestas.
- 3.Configurar manejador global de errores Express que reemplace el campo 'detail' con mensaje genérico en producción.
- 4.Mantener detalle completo solo en logs internos (CloudWatch + Sentry).
- 5.Retirar X-Powered-By: Express con app.disable('x-powered-by') o helmet.hidePoweredBy().
- 6.Adoptar el formato application/problem+json (RFC 7807) para respuestas de error consistentes.
- 7.Validar con pruebas en API Tester: brute force debe retornar 429 después del límite.
- Burst de 100 req/min en login devuelve 429 a partir de la 6ª petición.
- Respuestas 5xx no contienen 'PostgreSQL', 'Express' ni stack traces en producción.
- Header X-Powered-By eliminado.
- Pruebas automáticas (Jest/Vitest) de rate limiting en CI.
🎯 Configurar Strict-Transport-Security con preload, cifrar la instancia staging-rds-1 con KMS y aplicar mínimo privilegio en la política IAM de la llave DIAN con rotación automática.
Ver pasos detallados (6) y criterios de cierre (4)
- 1.Configurar HSTS con max-age >= 1 año, includeSubDomains y preload en CloudFront/Nginx.
- 2.Registrar el dominio app.omnicontrol.co en hstspreload.org una vez configurado.
- 3.Cifrar staging-rds-1: crear snapshot, restaurar a nueva instancia con encryption-at-rest habilitado, migrar tráfico.
- 4.Revisar política IAM de la llave alias/dian-firma-electronica: retirar DeveloperRole y usuarios humanos, dejar solo DIANServiceRole y AdminRole con condiciones.
- 5.Habilitar rotación automática anual de la llave DIAN.
- 6.Documentar la política de gestión criptográfica como POL-CRYP-001.
- testssl.sh reporta HSTS presente con preload.
- Consola RDS muestra storageEncrypted=true para staging-rds-1.
- Política IAM de llave DIAN reducida a ≤2 principals.
- Rotación automática habilitada visible en KMS console.
🎯 Cerrar gaps de gobernanza Git: crear archivo CODEOWNERS, fijar expiración a todos los PATs, restringir política de forks y añadir un segundo Maintainer.
Ver pasos detallados (7) y criterios de cierre (5)
- 1.Crear .github/CODEOWNERS con asignaciones para /src/dian/, /src/rndc/, /src/auth/, /src/tenant/.
- 2.Auditar los 4 PATs activos: rotar los 2 sin expiración y asignar TTL de 90 días.
- 3.Establecer política de forks: cambiar a 'Allow forks: Members only' (Settings → Member privileges).
- 4.Designar a María Elena o al Especialista Cloud como segundo Admin para evitar bus-factor 1.
- 5.Endurecer branch protection: required status checks, require linear history, disallow force push, include administrators.
- 6.Documentar política de gestión de accesos al repo en POL-DEV-001.
- 7.Si el plan lo permite, evaluar GitHub Enterprise para audit log auditable.
- Archivo CODEOWNERS presente cubriendo ≥4 rutas críticas.
- 0 PATs sin fecha de expiración.
- Política de forks restringida a miembros.
- Al menos 2 personas con rol Admin.
- Branch protection con required checks y prohibición de force push.
Verificar
Evaluación y monitoreo de controles5 acciones🎯 Integrar OWASP ZAP como stage obligatorio del pipeline CI/CD con cadencia mínima por release; remediar los 14 hallazgos abiertos del único reporte existente con plan priorizado.
Ver pasos detallados (7) y criterios de cierre (4)
- 1.Re-ejecutar OWASP ZAP baseline scan contra staging para obtener reporte actualizado.
- 2.Crear plan de remediación para los 14 hallazgos abiertos (3 High, 8 Medium, 3 Low) con responsable y SLA.
- 3.Integrar ZAP en pipeline GitHub Actions con stage post-deploy a staging.
- 4.Configurar política: build falla si ZAP encuentra Critical/High nuevos.
- 5.Vincular hallazgos a tickets en el Vulnerability Tracker (control V-05).
- 6.Programar ejecución de ZAP full scan mensual (no solo baseline) con reporte al Comité SGSI.
- 7.Considerar adquisición de Burp Suite Professional para análisis profundo trimestral.
- Stage de ZAP visible en .github/workflows/security.yml ejecutándose en cada release.
- Reporte DAST con fecha <30 días publicado en el sistema.
- ≥3 hallazgos High de octubre 2025 marcados como Closed con verificación.
- Cadencia mensual establecida con primera ejecución programada.
🎯 Corregir la vulnerabilidad BOLA confirmada: aplicar middleware de autorización a nivel de objeto que valide tenant_id en TODOS los endpoints de detalle, no solo en listados.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Crear middleware tenantGuard que extraiga tenant_id del JWT y lo compare con el del recurso solicitado.
- 2.Aplicar tenantGuard a todos los endpoints de detalle: GET /api/conductores/:id, /api/manifiestos/:id, /api/facturas/:id, /api/nomina/:id, /api/gps/:id.
- 3.Hacer el chequeo a nivel de query SQL: WHERE id = :id AND tenant_id = :tenant_id (consistente, no en código JS).
- 4.Hacer auditoría completa del API: identificar TODOS los endpoints de detalle y verificar.
- 5.Añadir test automatizado en CI: cada endpoint de detalle prueba acceso cross-tenant y debe retornar 403/404.
- 6.Configurar WAF (AWS WAF + API Gateway) para registrar y alertar intentos sistemáticos cross-tenant.
- 7.Notificar a clientes afectados según protocolo IRP si se detecta evidencia de explotación previa (revisar logs).
- 8.Considerar Sentry custom alert para patrones de enumeración secuencial.
- Middleware tenantGuard aplicado en 100% de endpoints de detalle.
- Suite de tests de aislamiento multi-tenant con cobertura ≥80% de endpoints.
- API Tester confirma 403 al intentar acceder a recursos cross-tenant.
- Logs en WAF/API Gateway registran intentos cross-tenant.
- Acta de revisión técnica post-remediación firmada.
🎯 Definir RTO formal por servicio crítico, programar prueba de restauración trimestral automatizada y documentar procedimiento de recuperación end-to-end.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Definir RTO por servicio crítico: ERP backend, DIAN, RNDC, GPS, nómina.
- 2.Documentar procedimiento de restauración paso a paso para cada tipo de backup (RDS snapshot, S3 versioning, EBS).
- 3.Ejecutar primera prueba manual de restauración en ambiente aislado y medir tiempo vs RTO objetivo.
- 4.Automatizar prueba de restauración trimestral mediante Lambda + EventBridge.
- 5.Configurar prueba como tarea en AWS Backup con notificación al completar.
- 6.Documentar resultados en bitácora con timestamp, duración real y desviación vs RTO.
- 7.Vincular procedimiento al DRP/BCP (control A-01 relacionado).
- 8.Capacitar al equipo en el procedimiento de recuperación con simulacro tabletop.
- RTO documentado para 5 servicios críticos.
- Primera prueba de restauración ejecutada y registrada en bitácora.
- Job de prueba trimestral programado en AWS.
- Procedimiento POL-DR-001 publicado.
- Simulacro tabletop ejecutado con acta.
🎯 Formalizar el proceso A.8.8: política de gestión de vulnerabilidades con SLA por severidad CVSS, proceso de excepciones con reevaluación, y reporting mensual al Comité SGSI.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Definir política POL-VULN-001 con SLA por severidad: Crítica 7 días, Alta 30 días, Media 90 días, Baja 180 días.
- 2.Adoptar campo CVSS obligatorio en los issues de seguridad (template de GitHub Issue).
- 3.Migrar de GitHub Issues a una herramienta más robusta o estructurar Issues con projects v2 (con campos: severidad, CVSS, fecha detectada, fecha objetivo, asignado, estado).
- 4.Definir proceso de excepciones: requiere justificación, responsable, fecha de reevaluación y aprobación del Comité SGSI.
- 5.Triajear los 47 issues abiertos con label security: cerrar duplicados, asignar severidad y responsable.
- 6.Generar reporte mensual automatizado con: total abiertos por severidad, aging, cumplimiento SLA, hallazgos cerrados.
- 7.Programar revisión trimestral de las excepciones aceptadas.
- 8.Vincular hallazgos con SAST (H-01) y DAST (V-01) automáticamente vía CI/CD.
- Política POL-VULN-001 firmada y publicada.
- 0 tickets abiertos sin severidad o asignado.
- 0 excepciones sin fecha de reevaluación.
- Primer reporte mensual generado y presentado a Comité SGSI.
- Cumplimiento de SLA medible (al menos baseline establecido).
🎯 Reactivar el pipeline de ingesta de datos al dashboard Grafana, completar los paneles con NO DATA y establecer reportes mensuales formales al Comité SGSI.
Ver pasos detallados (7) y criterios de cierre (5)
- 1.Diagnosticar por qué los datos no llegan desde noviembre 2025: revisar logs del ingestor, credenciales caducadas, cambios en API.
- 2.Restaurar la ingesta de datos para los 3 paneles 'STALE' (MTTD, MTTR, Training).
- 3.Configurar los 3 paneles 'NO DATA' (Vulnerabilidades abiertas, SLA remediation, Deploys bloqueados) con queries reales contra GitHub Issues / SAST API.
- 4.Definir umbrales y alertas: si MTTD > 1h o vulnerabilidades High > 5 abiertas → notificar al Líder técnico.
- 5.Diseñar plantilla de reporte mensual de seguridad para Comité SGSI (1 página: KPIs + tendencias + decisiones).
- 6.Programar primera reunión mensual del Comité SGSI con presentación del dashboard.
- 7.Vincular este dashboard con el Vulnerability Tracker (V-05).
- 0 paneles 'NO DATA' en el dashboard Grafana.
- 0 paneles 'STALE' (todos con datos <7 días).
- Primer reporte mensual presentado al Comité SGSI con acta.
- Plantilla de reporte estandarizada y reutilizable.
- Alertas configuradas en al menos 3 paneles.
Actuar
Mejora continua y gobernanza3 acciones🎯 Eliminar el archivo .env del repositorio, migrar credenciales restantes a Secrets Manager, rotar credenciales expuestas históricamente y habilitar GitHub Secret Scanning + Push Protection.
Ver pasos detallados (8) y criterios de cierre (6)
- 1.Habilitar Secret Scanning, Push Protection y Dependabot Security Updates en GitHub.
- 2.Eliminar archivo .env del repositorio: git rm + commit + git filter-branch o BFG Repo-Cleaner para reescribir historia.
- 3.Asumir que todas las credenciales del .env están expuestas: rotar todas (DB staging password, GPS API key, JWT secret, AWS keys, Sentry DSN, Slack webhook).
- 4.Migrar credenciales restantes a AWS Secrets Manager con KMS.
- 5.Habilitar rotación automática para los 3 secretos en Secrets Manager (DB, DIAN, GPS).
- 6.Crear .env.example sin valores reales como referencia para desarrolladores.
- 7.Añadir hook pre-commit con detect-secrets/gitleaks como red de seguridad local.
- 8.Documentar política de gestión de secretos POL-SEC-001.
- Archivo .env eliminado del repo y de la historia git.
- GitHub Secret Scanning habilitado (Security tab muestra 'Enabled').
- Push Protection bloqueando commits con secretos detectados.
- Credenciales rotadas (verificable en Secrets Manager con lastRotated reciente).
- Rotación automática habilitada en los 3 secretos productivos.
- Política POL-SEC-001 publicada.
🎯 Documentar e implementar un Plan de Respuesta a Incidentes (IRP) formal con protocolo de notificación a clientes y autoridades en plazos de Ley 1581, separando el canal de incidentes del canal de soporte general.
Ver pasos detallados (9) y criterios de cierre (5)
- 1.Redactar IRP-001 cubriendo: roles (Comandante de Incidente, Comunicador, Técnico), tipologías de incidente, severidad, flujos de escalamiento.
- 2.Definir protocolo de notificación a clientes con plazos: confirmación inicial en 4h, primer informe en 24h, post-mortem en 7 días.
- 3.Definir protocolo de notificación a SIC: reporte dentro de 15 días hábiles para brechas de datos personales (Circular 02/2015 SIC).
- 4.Crear canal dedicado #incidentes-seguridad en Slack/Teams (no WhatsApp).
- 5.Establecer 3 plantillas de comunicación: (1) interna inicial, (2) cliente, (3) SIC.
- 6.Capacitar al equipo (Gerencia + Técnico) en el IRP con sesión de 2h.
- 7.Ejecutar primer simulacro tabletop con escenario realista (ej. exposición de manifiestos RNDC).
- 8.Documentar lecciones aprendidas y refinar IRP a v1.1.
- 9.Programar simulacros tabletop semestrales como mínimo.
- Documento IRP-001 v1.0 firmado por Gerencia.
- Canal de incidentes separado del soporte general.
- Acta del primer simulacro tabletop con todos los miembros.
- 3 plantillas de comunicación validadas.
- Calendario de simulacros futuros publicado.
🎯 Publicar política de Responsible Disclosure conforme a RFC 9116, crear email security@omnicontrol.co dedicado y desplegar /.well-known/security.txt en los dominios productivos.
Ver pasos detallados (8) y criterios de cierre (5)
- 1.Crear alias security@omnicontrol.co en Google Workspace (grupo con miembros del equipo técnico + DPO).
- 2.Redactar /.well-known/security.txt conforme a RFC 9116 con Contact, Expires, Encryption (PGP), Acknowledgments, Policy, Preferred-Languages.
- 3.Desplegar el archivo en app.omnicontrol.co y api.omnicontrol.co (vía CloudFront/Nginx).
- 4.Publicar página pública /security con la política completa: alcance, cómo reportar, compromisos, alcance prohibido, safe harbor.
- 5.Establecer procedimiento interno de triaje: acuse en 5 días hábiles, clasificación en 10, comunicación periódica hasta cierre.
- 6.Crear template de respuesta para investigadores (en español e inglés).
- 7.Documentar el procedimiento como POL-RD-001 firmado por Gerencia.
- 8.Considerar programa de bug bounty en fase 2 (HackerOne, Intigriti) con presupuesto pequeño.
- https://app.omnicontrol.co/.well-known/security.txt accesible y conforme a RFC 9116.
- Email security@omnicontrol.co recibiendo correctamente correos de prueba.
- Página pública /security publicada con política completa.
- Política POL-RD-001 firmada.
- Plantilla de respuesta creada (es/en).