0/23Evaluados
0Conformes
0No Conformes
0OM
Plan de remediación

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).

Acciones totales
20
20 NC + OM
Prioridad ALTA
15
atención inmediata
Quick wins disponibles
19
resolubles < 1 semana
Esfuerzo bajo
8
completar en <2 semanas
Filtrar:
PLANEAR

Planear

Contexto, partes interesadas y requisitos4 acciones
P-01
ISO 27001 Cláusula 5.2 / 5.3
No Conforme
Alta
Bajo · 1-2 semanas

🎯 Aprobar formalmente la Política de Seguridad de la Información, designar DPO mediante acto administrativo y conformar Comité SGSI con frecuencia trimestral.

Quick win: Firmar el borrador v0.3 existente en Comité de Gerencia y publicarlo como v1.0 en el sistema documental (acción de 1-2 días).
Ver pasos detallados (6) y criterios de cierre (4)
Pasos
  1. 1.Revisar y completar las secciones pendientes del borrador POL-SGSI-001 v0.3 (Compromiso de Dirección, DPO, Comité, sanciones).
  2. 2.Convocar Comité de Gerencia para aprobación formal con firma de María Elena Ramírez.
  3. 3.Emitir resolución/acto administrativo de designación del DPO (interno o asesor externo contratado).
  4. 4.Publicar la política en el sistema documental con identificador POL-SGSI-001 v1.0 y comunicar a todo el equipo.
  5. 5.Establecer el Comité SGSI con frecuencia trimestral mínima y agenda tipo (revisión de riesgos, KPIs, incidentes).
  6. 6.Documentar el acta de constitución del Comité y la primera revisión.
Criterios de cierre
  • 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).
Base normativa
ISO 27001:2022 Cláusula 5.2 (Política)ISO 27001:2022 Cláusula 5.3 (Roles)Ley 1581 de 2012 Art. 26 (Accountability)Decreto 1377 de 2013
Responsable sugerido: Gerencia + DPOVer control completo
P-04
A.8.1 ISO 27002:2022
No Conforme
Alta
Bajo · 1-2 semanas

🎯 Formalizar el inventario de activos: añadir propietario, criticidad y clasificación por cada entrada; completar los 7+ activos faltantes; establecer revisión trimestral.

Quick win: Añadir las 7 entradas faltantes detectadas durante la auditoría en la hoja existente (1-2 horas).
Ver pasos detallados (7) y criterios de cierre (5)
Pasos
  1. 1.Migrar inventario desde Google Sheets a una herramienta colaborativa con control de versiones (Notion, Confluence o repositorio Git en YAML).
  2. 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. 3.Realizar inventario completo con apoyo de AWS Resource Groups Tag Editor y GitHub Repos List.
  4. 4.Cruzar inventario con activos reales en AWS y GitHub mediante script periódico.
  5. 5.Designar propietario por activo (no todos al Desarrollador Fullstack).
  6. 6.Establecer revisión trimestral en agenda del Comité SGSI.
  7. 7.Vincular inventario con la Matriz de Riesgos y los Threat Models.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.1ISO 27001:2022 Cláusula 8.1
Responsable sugerido: Gerencia + DPOVer control completo
P-02
A.8.25 / A.5.8 ISO 27002:2022 + OWASP SAMM
No Conforme
Alta
Medio · 4-6 semanas

🎯 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.

Quick win: Adoptar plantilla STRIDE en la próxima sesión de planning y aplicar al módulo de aislamiento multi-tenant (4 horas).
Ver pasos detallados (7) y criterios de cierre (4)
Pasos
  1. 1.Adoptar plantilla STRIDE estándar (o usar herramienta como Microsoft Threat Modeling Tool / OWASP Threat Dragon).
  2. 2.Realizar sesión de modelado para módulo de aislamiento multi-tenant (prioridad por riesgo Catastrófico).
  3. 3.Replicar sesión para módulos DIAN (facturación electrónica) y RNDC (manifiestos).
  4. 4.Documentar telemetría GPS y módulo de nómina electrónica.
  5. 5.Para cada amenaza identificada, crear ticket en el backlog con prefijo 'SEC-' y criterio de aceptación de seguridad.
  6. 6.Definir como Definition of Done que las nuevas features pasen Threat Modeling antes de iniciar desarrollo.
  7. 7.Versionar los documentos de Threat Modeling en el repositorio safite-erp bajo /docs/security/.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.25OWASP SAMM (Design - Threat Assessment)NIST SP 800-218 PW 1.1
Responsable sugerido: Gerencia + DPOVer control completo
P-03
Ley 1581/2012 Art. 23 / Decreto 1377/2013 Art. 23
No Conforme
Alta
Medio · 3-4 semanas

🎯 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.

Quick win: Añadir checkbox de consentimiento + enlace a política en formulario de nuevo conductor en menos de 1 día (no requiere módulo nuevo).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 1.Redactar Política de Tratamiento de Datos y Aviso de Privacidad (revisar con asesor legal).
  2. 2.Publicar la política en una URL pública estable (ej. omnicontrol.co/privacidad).
  3. 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. 4.Crear tabla `consentimientos` (titular_id, política_versión, fecha, IP, user_agent) y registrar al hacer submit.
  5. 5.Replicar en todos los formularios que capturan PII (clientes, empleados).
  6. 6.Diseñar módulo ARCO autoservicio en Configuración → Mis datos: ver datos, solicitar rectificación/eliminación.
  7. 7.Implementar workflow backend con plazos automáticos (10 días hábiles consultas, 15 días reclamos).
  8. 8.Documentar el proceso ARCO interno con responsable asignado.
Criterios de cierre
  • 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.
Base normativa
Ley 1581 de 2012 Art. 4(c), Art. 23Decreto 1377 de 2013 Art. 14, Art. 23
Responsable sugerido: Gerencia + DPOVer control completo
HACER

Hacer

Implementación de controles de desarrollo seguro8 acciones
H-01
A.8.25 / A.8.28 ISO 27002:2022 + OWASP SAMM
No Conforme
Alta
Medio · 2-3 semanas

🎯 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.

Quick win: Habilitar GitHub Secret Scanning + Push Protection desde Settings → Code security and analysis (5 min, gratis para repos privados con seats Pro).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 1.Habilitar Secret Scanning + Push Protection en Settings → Code security.
  2. 2.Habilitar Dependabot Security Updates (auto-PRs para CVEs).
  3. 3.Crear workflow .github/workflows/security.yml con stages: CodeQL (SAST), Snyk o npm audit (SCA).
  4. 4.Configurar política: build falla si hay hallazgos Critical/High sin mitigar.
  5. 5.Añadir stage de DAST (OWASP ZAP baseline scan) corriendo contra ambiente de staging.
  6. 6.Configurar Branch Protection en main: required status checks (CodeQL, Dependabot, tests), require PR review.
  7. 7.Actualizar Definition of Done con criterio 'Sin hallazgos High/Critical en SAST/SCA'.
  8. 8.Capacitar al equipo en la nueva política (sesión de 1h).
Criterios de cierre
  • 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).
Base normativa
ISO 27002:2022 A.8.25, A.8.28OWASP SAMM (Implementation - Secure Build)NIST SP 800-218 PW 8.2
Responsable sugerido: Equipo Dev + CloudVer control completo
H-02
A.8.25 / A.8.33 ISO 27002:2022 + NIST SP 800-218 + Ley 1581 Art. 4(f)
No Conforme
Alta
Medio · 3-4 semanas

🎯 Implementar rutina automatizada de Data Masking para poblar Staging con datos pseudonimizados; prohibir volcado directo desde producción mediante política técnica.

Quick win: Restringir inmediatamente el rol del Desarrollador para que no pueda ejecutar pg_dump contra producción (cambio en política IAM, 1 día).
Ver pasos detallados (7) y criterios de cierre (5)
Pasos
  1. 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. 2.Implementar script de masking (Python + Faker o pg_anonymizer extension de PostgreSQL).
  3. 3.Programar AWS Lambda + EventBridge: snapshot diario de prod → masking → restore en staging-rds-1.
  4. 4.Cifrar staging-rds-1 en reposo con KMS (control H-05 relacionado).
  5. 5.Aplicar política IAM que niegue acceso del Desarrollador a producción RDS.
  6. 6.Documentar la política de Data Masking y publicarla como POL-DM-001.
  7. 7.Validar: ejecutar queries en staging y confirmar que cédulas/nombres están enmascarados.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.25, A.8.33Ley 1581 de 2012 Art. 4(f)NIST SP 800-218 PW 6.1
Responsable sugerido: Equipo Dev + CloudVer control completo
H-04
A.8.5 ISO 27002:2022 + OWASP ASVS 2.8 + Ley 1581 Art. 4(g)
No Conforme
Alta
Medio · 3-4 semanas

🎯 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)
Pasos
  1. 1.Diseñar flujo de enrolment de TOTP (Google Authenticator, Authy) con QR code en Configuración.
  2. 2.Implementar verificación TOTP con librería como otplib o speakeasy en backend.
  3. 3.Crear tabla `user_mfa` con secret cifrado en columna y backup codes.
  4. 4.Forzar enrolment en primer login para usuarios con rol admin de tenant.
  5. 5.Añadir paso de verificación TOTP en login después de validar usuario/contraseña.
  6. 6.Implementar rate limiting específico para intentos de TOTP (5 intentos/15 min).
  7. 7.Documentar el procedimiento de recuperación (backup codes + reset por admin).
  8. 8.Considerar opción de WebAuthn (FIDO2) para una segunda fase.
  9. 9.Comunicar a los 60 clientes el nuevo flujo con campaña previa.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.5OWASP ASVS 2.8 (Multi-Factor Authentication)Ley 1581 de 2012 Art. 4(g)
Responsable sugerido: Equipo Dev + CloudVer control completo
H-08
A.8.18 ISO 27002:2022
No Conforme
Alta
Medio · 3-4 semanas

🎯 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.

Quick win: Rotar las 3 Access Keys con más de 90 días sin rotación (incluye la de GitHub Actions de 873 días). Acción de 1 día con downtime planificado.
Ver pasos detallados (9) y criterios de cierre (5)
Pasos
  1. 1.Habilitar AWS IAM Identity Center (anteriormente AWS SSO) en la cuenta omnicontrol-prod.
  2. 2.Configurar conexión con Google Workspace o crear usuarios internos.
  3. 3.Definir permission sets: Admin, PowerUser, Developer, ReadOnly, Auditor.
  4. 4.Migrar los 3 usuarios humanos (Carlos, María Elena, Andrés) a SSO con credenciales temporales (1-8h).
  5. 5.Retirar Access Keys estáticas de usuarios humanos.
  6. 6.Para github-actions-deploy: migrar a OIDC (IAM role asumido desde GitHub Actions sin keys) usando aws-actions/configure-aws-credentials.
  7. 7.Crear cuenta break-glass dedicada con MFA hardware (YubiKey), credenciales en sobre sellado físico.
  8. 8.Documentar procedimiento de break-glass en POL-PAM-001 con responsable y registro obligatorio.
  9. 9.Configurar alertas en CloudWatch para uso de la cuenta break-glass.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.18 (Use of privileged utility programs)CIS AWS Foundations 1.x (IAM)AWS Well-Architected (Security Pillar)
Responsable sugerido: Equipo Dev + CloudVer control completo
H-07
A.8.12 ISO 27002:2022 + Ley 1581 Art. 4(g)
No Conforme
Alta
Alto · 8-12 semanas

🎯 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.

Quick win: Firmar política BYOD formal con los 3 miembros del equipo (que prohíba sync a cuentas personales y uso de USB) en 1 día. Es contractual, no técnica, pero deja constancia.
Ver pasos detallados (8) y criterios de cierre (6)
Pasos
  1. 1.Redactar y firmar Política BYOD/DLP corporativa con cláusulas de aceptación.
  2. 2.Adquirir suscripción MDM (Jamf para macOS, Microsoft Intune para Windows, o JumpCloud multiplataforma).
  3. 3.Enrolar los 3 equipos del equipo en MDM (proceso voluntario en BYOD, contrato si rechazo).
  4. 4.Aplicar políticas: FileVault/BitLocker obligatorio, bloqueo de USB no autorizado, restricción de sync a cuentas personales.
  5. 5.Desplegar EDR (CrowdStrike, SentinelOne, o Microsoft Defender for Endpoint).
  6. 6.Configurar alertas DLP por descargas masivas, transferencias a dominios no corporativos.
  7. 7.Programar wipe remoto al desvincular colaboradores.
  8. 8.Considerar evolución a equipos corporativos para roles con acceso a PII (DPO, Líder técnico).
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.12 (DLP), A.8.1 (Endpoint devices)Ley 1581 de 2012 Art. 4(g) (Seguridad)NIST SP 800-46 (Telework Security)
Responsable sugerido: Equipo Dev + CloudVer control completo
H-03
A.8.26 / A.8.29 ISO 27002:2022 + OWASP API Security Top 10
Oportunidad de Mejora
Media
Bajo · 1 semana

🎯 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.

Quick win: Añadir middleware express-rate-limit con 5 intentos/min por IP+usuario en endpoint de login (1-2 horas).
Ver pasos detallados (7) y criterios de cierre (4)
Pasos
  1. 1.Implementar rate limiting por usuario+IP en /auth/login: 5 intentos en 1 min, bloqueo de 15 min con backoff exponencial.
  2. 2.Añadir headers X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After en respuestas.
  3. 3.Configurar manejador global de errores Express que reemplace el campo 'detail' con mensaje genérico en producción.
  4. 4.Mantener detalle completo solo en logs internos (CloudWatch + Sentry).
  5. 5.Retirar X-Powered-By: Express con app.disable('x-powered-by') o helmet.hidePoweredBy().
  6. 6.Adoptar el formato application/problem+json (RFC 7807) para respuestas de error consistentes.
  7. 7.Validar con pruebas en API Tester: brute force debe retornar 429 después del límite.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.26, A.8.29OWASP API Security Top 10 API4 (Unrestricted Resource Consumption)RFC 7807 (Problem Details)
Responsable sugerido: Equipo Dev + CloudVer control completo
H-05
A.8.24 / A.8.28 ISO 27002:2022
Oportunidad de Mejora
Media
Bajo · 1 semana

🎯 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.

Quick win: Añadir header Strict-Transport-Security: max-age=63072000; includeSubDomains; preload en CloudFront/Nginx (30 min).
Ver pasos detallados (6) y criterios de cierre (4)
Pasos
  1. 1.Configurar HSTS con max-age >= 1 año, includeSubDomains y preload en CloudFront/Nginx.
  2. 2.Registrar el dominio app.omnicontrol.co en hstspreload.org una vez configurado.
  3. 3.Cifrar staging-rds-1: crear snapshot, restaurar a nueva instancia con encryption-at-rest habilitado, migrar tráfico.
  4. 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. 5.Habilitar rotación automática anual de la llave DIAN.
  6. 6.Documentar la política de gestión criptográfica como POL-CRYP-001.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.24, A.8.28CIS AWS Foundations 2.x (Cryptography)
Responsable sugerido: Equipo Dev + CloudVer control completo
H-06
A.8.4 ISO 27002:2022
Oportunidad de Mejora
Media
Bajo · 3-5 días

🎯 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.

Quick win: Crear archivo CODEOWNERS en la raíz del repo definiendo revisores obligatorios por carpeta (30 min).
Ver pasos detallados (7) y criterios de cierre (5)
Pasos
  1. 1.Crear .github/CODEOWNERS con asignaciones para /src/dian/, /src/rndc/, /src/auth/, /src/tenant/.
  2. 2.Auditar los 4 PATs activos: rotar los 2 sin expiración y asignar TTL de 90 días.
  3. 3.Establecer política de forks: cambiar a 'Allow forks: Members only' (Settings → Member privileges).
  4. 4.Designar a María Elena o al Especialista Cloud como segundo Admin para evitar bus-factor 1.
  5. 5.Endurecer branch protection: required status checks, require linear history, disallow force push, include administrators.
  6. 6.Documentar política de gestión de accesos al repo en POL-DEV-001.
  7. 7.Si el plan lo permite, evaluar GitHub Enterprise para audit log auditable.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.4OWASP SAMM (Implementation - Defect Management)
Responsable sugerido: Equipo Dev + CloudVer control completo
VERIFICAR

Verificar

Evaluación y monitoreo de controles5 acciones
V-01
A.8.29 ISO 27002:2022 + OWASP Testing Guide v4.2
No Conforme
Alta
Medio · 4-6 semanas

🎯 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.

Quick win: Re-ejecutar OWASP ZAP baseline scan manualmente contra staging para tener un reporte vigente (2 horas).
Ver pasos detallados (7) y criterios de cierre (4)
Pasos
  1. 1.Re-ejecutar OWASP ZAP baseline scan contra staging para obtener reporte actualizado.
  2. 2.Crear plan de remediación para los 14 hallazgos abiertos (3 High, 8 Medium, 3 Low) con responsable y SLA.
  3. 3.Integrar ZAP en pipeline GitHub Actions con stage post-deploy a staging.
  4. 4.Configurar política: build falla si ZAP encuentra Critical/High nuevos.
  5. 5.Vincular hallazgos a tickets en el Vulnerability Tracker (control V-05).
  6. 6.Programar ejecución de ZAP full scan mensual (no solo baseline) con reporte al Comité SGSI.
  7. 7.Considerar adquisición de Burp Suite Professional para análisis profundo trimestral.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.29OWASP Testing Guide v4.2NIST SP 800-218 PW 8.2
Responsable sugerido: Equipo Dev + CloudVer control completo
V-02
A.8.29 ISO 27002:2022 + OWASP API Security Top 10 (2023)
No Conforme
Alta
Medio · 3-4 semanas (auditoría completa del API)

🎯 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.

Quick win: Patch inmediato en GET /api/conductores/{id}, /api/manifiestos/{id}, /api/facturas/{id} con validación de tenant_id en el handler (2-4 horas).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 1.Crear middleware tenantGuard que extraiga tenant_id del JWT y lo compare con el del recurso solicitado.
  2. 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. 3.Hacer el chequeo a nivel de query SQL: WHERE id = :id AND tenant_id = :tenant_id (consistente, no en código JS).
  4. 4.Hacer auditoría completa del API: identificar TODOS los endpoints de detalle y verificar.
  5. 5.Añadir test automatizado en CI: cada endpoint de detalle prueba acceso cross-tenant y debe retornar 403/404.
  6. 6.Configurar WAF (AWS WAF + API Gateway) para registrar y alertar intentos sistemáticos cross-tenant.
  7. 7.Notificar a clientes afectados según protocolo IRP si se detecta evidencia de explotación previa (revisar logs).
  8. 8.Considerar Sentry custom alert para patrones de enumeración secuencial.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.29OWASP API Security Top 10 API1:2023 (BOLA)OWASP ASVS V4 (Access Control)
Responsable sugerido: Equipo Dev + CloudVer control completo
V-03
A.8.13 ISO 27002:2022
No Conforme
Alta
Medio · 3-4 semanas

🎯 Definir RTO formal por servicio crítico, programar prueba de restauración trimestral automatizada y documentar procedimiento de recuperación end-to-end.

Quick win: Ejecutar manualmente una prueba de restauración de safite-prod-1 en ambiente aislado y medir tiempo real (1 día).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 1.Definir RTO por servicio crítico: ERP backend, DIAN, RNDC, GPS, nómina.
  2. 2.Documentar procedimiento de restauración paso a paso para cada tipo de backup (RDS snapshot, S3 versioning, EBS).
  3. 3.Ejecutar primera prueba manual de restauración en ambiente aislado y medir tiempo vs RTO objetivo.
  4. 4.Automatizar prueba de restauración trimestral mediante Lambda + EventBridge.
  5. 5.Configurar prueba como tarea en AWS Backup con notificación al completar.
  6. 6.Documentar resultados en bitácora con timestamp, duración real y desviación vs RTO.
  7. 7.Vincular procedimiento al DRP/BCP (control A-01 relacionado).
  8. 8.Capacitar al equipo en el procedimiento de recuperación con simulacro tabletop.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.13 (Information backup)ISO 27002:2022 A.5.30 (ICT readiness)ISO 27001:2022 Cláusula 8.1
Responsable sugerido: Equipo Dev + CloudVer control completo
V-05
A.8.8 ISO 27002:2022
No Conforme
Alta
Medio · 4-6 semanas

🎯 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.

Quick win: Cerrar o triarjear los 5 tickets más antiguos (>180 días) de GitHub Issues con label security: asignar responsable, severidad CVSS y fecha objetivo (4 horas).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 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. 2.Adoptar campo CVSS obligatorio en los issues de seguridad (template de GitHub Issue).
  3. 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. 4.Definir proceso de excepciones: requiere justificación, responsable, fecha de reevaluación y aprobación del Comité SGSI.
  5. 5.Triajear los 47 issues abiertos con label security: cerrar duplicados, asignar severidad y responsable.
  6. 6.Generar reporte mensual automatizado con: total abiertos por severidad, aging, cumplimiento SLA, hallazgos cerrados.
  7. 7.Programar revisión trimestral de las excepciones aceptadas.
  8. 8.Vincular hallazgos con SAST (H-01) y DAST (V-01) automáticamente vía CI/CD.
Criterios de cierre
  • 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).
Base normativa
ISO 27002:2022 A.8.8NIST SP 800-218 RV 1.1OWASP SAMM (Operations - Incident Management)
Responsable sugerido: Equipo Dev + CloudVer control completo
V-04
ISO 27001 Cláusula 9.1 + A.8.16
No Conforme
Media
Bajo · 2-3 semanas

🎯 Reactivar el pipeline de ingesta de datos al dashboard Grafana, completar los paneles con NO DATA y establecer reportes mensuales formales al Comité SGSI.

Quick win: Revisar y restaurar el pipeline de ingesta de datos a Grafana (probable problema simple de cron/credenciales). 2-4 horas.
Ver pasos detallados (7) y criterios de cierre (5)
Pasos
  1. 1.Diagnosticar por qué los datos no llegan desde noviembre 2025: revisar logs del ingestor, credenciales caducadas, cambios en API.
  2. 2.Restaurar la ingesta de datos para los 3 paneles 'STALE' (MTTD, MTTR, Training).
  3. 3.Configurar los 3 paneles 'NO DATA' (Vulnerabilidades abiertas, SLA remediation, Deploys bloqueados) con queries reales contra GitHub Issues / SAST API.
  4. 4.Definir umbrales y alertas: si MTTD > 1h o vulnerabilidades High > 5 abiertas → notificar al Líder técnico.
  5. 5.Diseñar plantilla de reporte mensual de seguridad para Comité SGSI (1 página: KPIs + tendencias + decisiones).
  6. 6.Programar primera reunión mensual del Comité SGSI con presentación del dashboard.
  7. 7.Vincular este dashboard con el Vulnerability Tracker (V-05).
Criterios de cierre
  • 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.
Base normativa
ISO 27001:2022 Cláusula 9.1 (Monitoring, measurement)ISO 27002:2022 A.8.16
Responsable sugerido: Equipo Dev + CloudVer control completo
ACTUAR

Actuar

Mejora continua y gobernanza3 acciones
A-02
A.8.24 ISO 27002:2022 + Complementario gestión de secretos
Oportunidad de Mejora
Alta
Bajo · 1-2 semanas

🎯 Eliminar el archivo .env del repositorio, migrar credenciales restantes a Secrets Manager, rotar credenciales expuestas históricamente y habilitar GitHub Secret Scanning + Push Protection.

Quick win: Habilitar GitHub Secret Scanning + Push Protection en Settings → Code security and analysis (5 min). Rotar inmediatamente la GPS API key sin rotar desde 2022 (1 hora).
Ver pasos detallados (8) y criterios de cierre (6)
Pasos
  1. 1.Habilitar Secret Scanning, Push Protection y Dependabot Security Updates en GitHub.
  2. 2.Eliminar archivo .env del repositorio: git rm + commit + git filter-branch o BFG Repo-Cleaner para reescribir historia.
  3. 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. 4.Migrar credenciales restantes a AWS Secrets Manager con KMS.
  5. 5.Habilitar rotación automática para los 3 secretos en Secrets Manager (DB, DIAN, GPS).
  6. 6.Crear .env.example sin valores reales como referencia para desarrolladores.
  7. 7.Añadir hook pre-commit con detect-secrets/gitleaks como red de seguridad local.
  8. 8.Documentar política de gestión de secretos POL-SEC-001.
Criterios de cierre
  • 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.
Base normativa
ISO 27002:2022 A.8.24 (Cryptography)OWASP Top 10 A02 (Cryptographic Failures)CIS AWS Foundations 1.x
Responsable sugerido: Gerencia + Equipo DevVer control completo
A-01
Ley 1581 Art. 17 / ISO 27001 Cláusula 6.1.3
No Conforme
Alta
Medio · 4-6 semanas

🎯 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.

Quick win: Crear canal Slack/Teams dedicado a incidentes #incidentes-seguridad separado del WhatsApp de soporte (1 hora).
Ver pasos detallados (9) y criterios de cierre (5)
Pasos
  1. 1.Redactar IRP-001 cubriendo: roles (Comandante de Incidente, Comunicador, Técnico), tipologías de incidente, severidad, flujos de escalamiento.
  2. 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. 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. 4.Crear canal dedicado #incidentes-seguridad en Slack/Teams (no WhatsApp).
  5. 5.Establecer 3 plantillas de comunicación: (1) interna inicial, (2) cliente, (3) SIC.
  6. 6.Capacitar al equipo (Gerencia + Técnico) en el IRP con sesión de 2h.
  7. 7.Ejecutar primer simulacro tabletop con escenario realista (ej. exposición de manifiestos RNDC).
  8. 8.Documentar lecciones aprendidas y refinar IRP a v1.1.
  9. 9.Programar simulacros tabletop semestrales como mínimo.
Criterios de cierre
  • 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.
Base normativa
Ley 1581 de 2012 Art. 17Circular 02 de 2015 SICISO 27002:2022 A.5.24 (Incident management planning)ISO 27001:2022 Cláusula 6.1.3NIST SP 800-61 (Computer Security Incident Handling Guide)
Responsable sugerido: Gerencia + Equipo DevVer control completo
A-03
A.5.24 / A.5.5 ISO 27002:2022
No Conforme
Media
Bajo · 1 semana

🎯 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.

Quick win: Crear el alias security@omnicontrol.co en Google Workspace con redirección al equipo técnico (15 min) y publicar /.well-known/security.txt con datos mínimos (30 min).
Ver pasos detallados (8) y criterios de cierre (5)
Pasos
  1. 1.Crear alias security@omnicontrol.co en Google Workspace (grupo con miembros del equipo técnico + DPO).
  2. 2.Redactar /.well-known/security.txt conforme a RFC 9116 con Contact, Expires, Encryption (PGP), Acknowledgments, Policy, Preferred-Languages.
  3. 3.Desplegar el archivo en app.omnicontrol.co y api.omnicontrol.co (vía CloudFront/Nginx).
  4. 4.Publicar página pública /security con la política completa: alcance, cómo reportar, compromisos, alcance prohibido, safe harbor.
  5. 5.Establecer procedimiento interno de triaje: acuse en 5 días hábiles, clasificación en 10, comunicación periódica hasta cierre.
  6. 6.Crear template de respuesta para investigadores (en español e inglés).
  7. 7.Documentar el procedimiento como POL-RD-001 firmado por Gerencia.
  8. 8.Considerar programa de bug bounty en fase 2 (HackerOne, Intigriti) con presupuesto pequeño.
Criterios de cierre
  • 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).
Base normativa
ISO 27002:2022 A.5.24 (Incident management planning)RFC 9116 (security.txt)Ley 1581 de 2012 Art. 17
Responsable sugerido: Gerencia + Equipo DevVer control completo