INSTRUMENTO – IDENTIFICACIÓN

Evaluación del Nivel de Madurez – Dominio de Identificación

Bienvenido al cuestionario de evaluación del dominio de Identificación, correspondiente al INSTRUMENTO DE NIVEL DE MADUREZ DE CIBERSEGURIDAD. Este instrumento tiene como finalidad establecer el nivel de madurez de su Entidad en cuanto a la identificación y gestión de activos, personas, datos, sistemas y recursos que requieren protección.

Para cada afirmación presentada, se deberá seleccionar únicamente la opción que mejor refleje el estado actual de su Entidad. Las respuestas deben basarse en la realidad operativa, organizacional y documental vigente.

La información obtenida permitirá contar con un diagnóstico preciso que servirá como base para definir estrategias de fortalecimiento en ciberseguridad.

¿Cómo se gestiona y mantiene actualizado el inventario de activos de TI en la Entidad?

1. No existe un inventario formal de activos. La información sobre hardware, software, redes, usuarios o datos críticos es incompleta o dispersa.

2. Se comienza a documentar manualmente el inventario de activos, pero de forma parcial y sin un proceso establecido de actualización.

3. El inventario está documentado con procesos definidos para su mantenimiento. Se clasifica por tipo, confidencialidad, integridad y disponibilidad. Se incluyen herramientas automáticas de descubrimiento y etiquetado de activos.

4. El inventario se mantiene actualizado automáticamente mediante herramientas como sistemas de gestión de activos, integraciones SIEM, EDR/XDR o NAC. Existen dashboards con métricas de cobertura y actualización.

5. La gestión de activos está integrada a procesos de gobierno de TI y ciberseguridad. Se aplican análisis de riesgo automático por tipo de activo.

0. En la Entidad no se ha implementado un proceso formal para gestionar o mantener actualizado el inventario de activos de TI.

¿Cómo se relacionan los activos de TI con los propietarios y los controles de seguridad en la Entidad?

0. En la Entidad no existe ninguna relación entre los activos de TI y propietarios. Tampoco existe relación con los controles de seguridad.

1. No hay relación definida entre activos y propietarios. Los controles de seguridad son mínimos.

2. Se inicia la relación entre activos y propietarios, pero no existe una alineación clara con los procesos de negocio ni controles de seguridad.

3. Los activos están relacionados con sus propietarios y se identifican controles de seguridad básicos. El inventario se alinea con el Análisis de Impacto del Negocio (BIA).

4. Los activos están relacionados con controles de seguridad y procesos de negocio. La información se cruza con amenazas conocidas (por ejemplo, CISA KEVs).

5. Los activos están completamente integrados con controles de seguridad avanzados y procesos de negocio. Se identifican activos "Shadow IT" o no autorizados de forma proactiva.

¿Cómo se realiza la evaluación de riesgos en la Entidad?

0. En la Entidad no se ha implementado un proceso formal para realizar la evaluación de riesgos.

1. No existe una metodología formal de evaluación de riesgos. Las evaluaciones son puntuales, no documentadas y no están alineadas con estándares. Las decisiones se basan en intuición o respuesta reactiva ante incidentes.

2. Se implementa una metodología básica de evaluación de riesgos, generalmente basada en listas de chequeo. Las evaluaciones se realizan de forma anual o esporádica. El análisis de impacto en el negocio (BIA) aún no se integra.

3. La Entidad adopta una metodología estructurada de evaluación de riesgos basada en la Guía para la Administración del Riesgo y el diseño de controles en entidades públicas Versión 6 del DAFP o ISO 31000 o ISO 27005, alineada con ISO 27001. Se establecen criterios de impacto y probabilidad, se incluye el análisis de amenazas relevantes y se empieza a considerar el contexto operativo.

4. Las evaluaciones de riesgos son recurrentes y actualizadas dinámicamente mediante fuentes de inteligencia de amenazas, gestión de vulnerabilidades, telemetría del SIEM y herramientas automatizadas. Los resultados alimentan directamente la priorización de ciberseguridad.

5. El proceso de evaluación de riesgos es adaptativo, predictivo y contextualizado. Utiliza análisis de comportamiento, tendencias de amenazas específicas del sector y aprendizaje automático. Se correlacionan los riesgos con eventos reales del SOC, resultados del CSIRT y simulaciones tipo red teaming.

¿Cómo se mide y prioriza el riesgo en la Entidad?

0. En la Entidad no se identifican ni se gestionan riesgos.

1. No hay un proceso definido para medir o priorizar el riesgo. Las decisiones se toman de manera intuitiva o reactiva.

2. Se utiliza una escala básica de impacto y probabilidad, pero sin integrar factores contextuales ni herramientas avanzadas.

3. Se establecen criterios de impacto y probabilidad, y se incluyen indicadores clave de rendimiento (KPIs) relacionados con la seguridad. Se empieza a considerar el contexto operativo y la criticidad de los activos.

4. El riesgo se mide de forma cuantitativa con indicadores de riesgo clave (KRIs). Se utilizan herramientas automatizadas para priorizar acciones de ciberseguridad.

5. Se emplea una combinación de KRIs y análisis predictivos basados en datos históricos y simulaciones. Los resultados se retroalimentan continuamente con lecciones aprendidas y escenarios de crisis.

¿Cómo se identifican y documentan los procesos críticos del negocio en la Entidad?

0. La Entidad no ha determinado la existencia de procesos críticos que impacten el negocio.

1. No existe un proceso formal para identificar procesos críticos. La Entidad reconoce algunos procesos críticos de manera informal, pero no se sabe si son del todo críticos ni cuáles son las prioridades operativas. La Entidad no ha realizado un análisis de impacto en el negocio (BIA).

2. Se ha iniciado la identificación de algunos procesos críticos, pero de forma básica y sin metodología documentada. El BIA se realiza de manera informal, con participación limitada del negocio y tecnología. No se incluyen métricas como RTO/RPO ni se vinculan claramente con activos tecnológicos.

3. Se implementa un proceso formal de BIA alineado con ISO 22301 (control 8.2.2), con participación transversal del negocio y tecnología. Se definen RTO, RPO, impacto financiero, reputacional y legal. Se vinculan procesos con activos tecnológicos, aplicaciones, proveedores y sitios críticos.

4. El BIA es actualizado regularmente (mínimo anual o ante cambios significativos) mediante herramientas especializadas (GRC o BCM). Se integra con arquitectura empresarial y sistemas de gestión de riesgos. Se utilizan esta información para definir niveles de alerta, ANSs y planes de respuesta diferenciada por criticidad.

5. El BIA es dinámico, automatizado y contextualizado. Se actualiza en función de amenazas emergentes, cambios operacionales y escenarios simulados. Se integra con simulaciones de continuidad, ejercicios de ciberresiliencia y priorización dinámica en SIEM/SOAR.

¿Cómo se utiliza el mapa de procesos críticos del negocio para priorizar acciones de ciberseguridad?

0. En la Entidad no se cuenta con un mapa de procesos críticos del negocio, por lo que no se utiliza para priorizar acciones de ciberseguridad.

1. No se utiliza ningún mapa de procesos críticos. Se actúa de manera reactiva sin conocimiento de prioridades ni alineación con funciones clave del negocio.

2. Se tienen criterios básicos sobre qué procesos proteger, pero sin una metodología estructurada ni métricas claras. La priorización es inconsistente y basada en supuestos generales.

3. El mapa de procesos alimenta la priorización del monitoreo y respuesta. Se consideran resultados del análisis en decisiones estratégicas, como niveles de alerta y planes de respuesta diferenciada por criticidad.

4. Se utiliza el mapa de procesos críticos para definir ANSs, niveles de alerta y planes de respuesta diferenciada por criticidad. Incluye interdependencias entre procesos y se integra con la estretegia de recuperación de datos.

5. El mapa de procesos críticos guía directamente la inversión y arquitectura de ciberseguridad. Se utiliza como entrada en ejercicios de simulaciones de ciberataques y crisis, integrándose con simulaciones de continuidad, inteligencia de amenazas y priorización dinámica en SIEM/SOAR.

¿Existen políticas de seguridad de la información en la Entidad?

0. En la Entidad no existe una política de seguridad de la información.

1. No existe una política formal de seguridad de la información. Se realizan prácticas de seguridad sin un proceso establecido, son reactivas y dependen del conocimiento individual. No hay respaldo directivo ni alineación con marcos normativos.

2. Se ha redactado un primer borrador de política de seguridad, generalmente reactivo a auditorías o incidentes. La política está centrada en controles técnicos y carece de visión estratégica. No está aprobada formalmente por la alta dirección ni comunicada.

3. La política está formalmente documentada, aprobada por la alta dirección y alineada con la estrategia de la Entidad. Define claramente el alcance, roles, responsabilidades, objetivos de seguridad y principios orientadores. Incluye referencia a marcos como ISO 27001, NIST CSF y controles de CIS. Es comunicada a todo el personal y se revisa anualmente o tras eventos relevantes.

4. La política está plenamente integrada en el Sistema de Gestión de Seguridad de la Información (SGSI). Existen politicas especificas de seguridad de la información. Su cumplimiento se mide mediante KPIs y KRIs definidos. Se vincula directamente con procedimientos de ciberseguridad, incluyendo monitoreo, clasificación de incidentes y comunicación.

5. Las políticas son un instrumento estratégico dinámico que guía la toma de decisiones de inversión y arquitectura de seguridad. Se actualiza proactivamente con base en inteligencia de amenazas, lecciones aprendidas de incidentes, simulacros y cambios regulatorios. Está enlazada con capacidades automatizadas de ciberseguridad (SIEM/SOAR).

¿Cómo se define y comunica la política de seguridad de la información en la Entidad?

0. En la Entidad no se ha definido ni comunicado una política formal de seguridad de la información.

1. No hay una política definida. Se realizan algunas prácticas de seguridad pero no están documentadas.

2. La política es un documento básico, centrado en controles técnicos, pero no está aprobada ni comunicada adecuadamente. Carece de visión estratégica y no incluye elementos clave como roles, priorización de activos críticos o procesos de escalado.

3. La política está bien definida y aprobada por la alta dirección. Incluye roles, responsabilidades, umbrales de actuación ante incidentes, priorización de activos críticos y coordinación con stakeholders internos y externos. Se comunica a todo el personal y se revisa regularmente.

4. La política está completamente integrada en los procesos operativos de ciberseguridad. Se vincula con procedimientos específicos de monitoreo, clasificación de incidentes y respuesta. Se miden indicadores de rendimiento (KPIs/KRIs) para asegurar su cumplimiento.

5. La política es dinámica y se actualiza continuamente basada en inteligencia de amenazas, lecciones aprendidas y cambios regulatorios. Incluye versiones específicas por área funcional y está enlazada con herramientas automatizadas (SIEM/SOAR) y protocolos del CSIRT.

¿Cómo se estructura y ejecuta el gobierno de seguridad en la Entidad?

0. En la Entidad no se ha establecido un gobierno de seguridad de la información.

1. No existe un marco formal de gobierno de seguridad. Las decisiones relacionadas con la seguridad no siguen un proceso establecido y dependen del conocimiento individual o de áreas específicas sin coordinación centralizada.

2. Se han definido algunos roles básicos relacionados con la seguridad, pero no están documentados ni alineados con estándares reconocidos como ISO 27001 o NIST CSF. La alta dirección no participa activamente en la toma de decisiones sobre ciberseguridad.

3. Existe un comité de gobierno de seguridad formalizado, con roles y responsabilidades claramente definidos. Se revisan métricas clave (KPIs/KRIs) y se realizan reuniones periódicas para evaluar el estado de la seguridad.

4. El gobierno de seguridad está integrado con otros procesos estratégicos de la organización. Se utilizan herramientas automatizadas para monitorear el cumplimiento de políticas y se reporta regularmente a la alta dirección.

5. El gobierno de seguridad es dinámico y adaptativo, con decisiones basadas en inteligencia de amenazas, simulaciones y análisis predictivos. La alta dirección lidera iniciativas de seguridad como parte integral de la estrategia organizacional.

¿Cómo se ha diseñado y documentado la arquitectura de red de la Entidad?

0. En la Entidad no se ha diseñado ni documentado formalmente la arquitectura de red.

1. La arquitectura de red es funcional pero no fue diseñada con principios de seguridad planeada. No se aplican segmentaciones ni principios de defensa en profundidad. No existen políticas de red ni documentación técnica.

2. Existe documentación básica de la arquitectura de red, aunque desactualizada. Se han implementado controles de seguridad elementales (ej. firewalls, NAT), pero no bajo una estrategia coherente de seguridad.

3. La arquitectura de red está formalmente documentada, incluye segmentación lógica (zonas de confianza), DMZ, y controles de acceso entre zonas. Se han aplicado principios de seguridad por diseño (confianza cero - Zero Trust y el principio de mínimo privilegio - Least Privilege).

4. Se gestionan activamente los cambios a la arquitectura mediante procesos controlados (ej. CAB, DevSecOps). Se utilizan herramientas de gestión de arquitectura (ej. RedSeal, Tufin) y se automatizan evaluaciones de exposición.

5. La arquitectura de red está totalmente alineada con una estrategia de resiliencia cibernética. Se integra con herramientas de análisis de ataque a la superficie (ASM), detección de anomalías por IA/ML, y se evalúa continuamente su exposición mediante ataques simulados (BAS, purple teaming).

¿Cómo se define y actualiza el modelo de amenazas y el perfil de riesgo en la Entidad?

0. En la Entidad no se ha definido ni actualizado formalmente el modelo de amenazas ni el perfil de riesgo.

1. Se ha intentado identificar algunas amenazas internas y externas. No existe un modelo de amenazas ni un perfil de riesgo formal.

2. Existe una definición inicial no formal del modelo de amenazas, pero sin aplicar frameworks formales. Se empieza a construir un perfil de riesgo técnico con soporte parcial de TI.

3. Se ha desarrollado un modelo de amenazas estructurado y se mantiene actualizado. El perfil de riesgo considera la exposición externa (ej. sistemas en nube, IoT), análisis de vulnerabilidades y evaluaciones de impacto (BIA).

4. El modelo de amenazas se alimenta de inteligencia externa y se vincula al monitoreo de seguridad (SIEM, SOAR) para detección basada en tácticas, técnicas y procedimientos. El perfil de riesgo es revisado periódicamente e incluye métricas de amenazas emergentes.

5. El modelo de amenazas es dinámico, basado en amenazas contextuales (industria, geopolítica) y se actualiza en tiempo real. El perfil de riesgo guía decisiones tácticas y estratégicas (inversión, proveedores, cambios de arquitectura).