Agencia de Gobierno Electrónico y Sociedad de la Información y del Conocimiento

Informes de versiones instaladas, registros de parches aplicados, reportes de herramientas de gestión de activos o tickets de actualización que evidencien que el software base y las aplicaciones críticas se encuentran actualizados sin vulnerabilidades críticas conocidas.  

Listados de activos con restricciones tecnológicas que no pueden ser actualizados, planillas justificadas, informes de excepción o documentación de controles alternativos aplicados (como aislamiento, monitoreo reforzado, limitación de accesos, etc.) que permitan verificar que estos casos están identificados y controlados. 

Plan formal aprobado, cronogramas de aplicación de parches, matrices de planificación o publicaciones internas que permitan constatar que existe un enfoque documentado para gestionar vulnerabilidades y aplicar parches.  

Correos electrónicos, registros de suscripción, herramientas de agregación de alertas, tickets de análisis o actas de reuniones que evidencien que se reciben y analizan notificaciones de vulnerabilidades relevantes provenientes del CERTuy u otros organismos. 

Planillas de análisis, matrices de criticidad, reportes de escaneo, criterios definidos o tickets de tratamiento que evidencien que las vulnerabilidades detectadas son evaluadas y priorizadas según su impacto y exposición.  

Procedimiento técnico vigente, aprobado y difundido internamente, que describa las actividades, plazos, responsables y mecanismos para la gestión y resolución de vulnerabilidades.  

Manuales de funciones, matrices de roles, procedimientos con responsables asignados o actas de designación que permitan verificar que hay personas o áreas responsables específicamente de la gestión de vulnerabilidades.  

Informes de escaneo, cronogramas de ejecución, logs de herramientas de análisis o tickets de cierre que permitan demostrar que se realizan escaneos de vulnerabilidades con una frecuencia mínima de seis meses. 

Informes de revisión interna, listas de verificación, hallazgos de auditoría o registros de cumplimiento que evidencien que se evalúa periódicamente la aplicación del plan de gestión de vulnerabilidades. 

Reportes finales, correos institucionales, presentaciones internas o actas de reunión que permitan verificar que los resultados de las revisiones fueron comunicados formalmente al RSI. 

Registros de análisis de vulnerabilidades tratadas, minutas de revisión, reportes de cierre de ciclo o versiones actualizadas de procedimientos que evidencien que las lecciones aprendidas son formalmente registradas y utilizadas para mejorar la respuesta frente a vulnerabilidades similares en el futuro. 

Correos institucionales, publicaciones en intranet, actas de reuniones, notificaciones en herramientas de gestión o tickets cerrados que permitan verificar que se comunican los cambios tecnológicos a las partes interesadas. 

Formularios de cambio, tickets de aprobación, actas internas o registros del sistema de gestión que evidencien que los cambios tecnológicos fueron previamente autorizados por los responsables de los activos involucrados.   

Manuales técnicos, procedimientos de desarrollo, flujos de gestión de cambios o repositorios internos que permitan verificar que está definido un mecanismo de control de versiones para los productos de software utilizados por la organización. 

Guías de configuración, instructivos de seguridad, plantillas de línea base o registros de aplicación de hardening que evidencien que se han establecido criterios de configuración segura y líneas base para los productos de software y sistemas utilizados. 

Evidencias de pruebas en entornos de desarrollo o preproducción, planes de pruebas, tickets con resultados o capturas de ambiente que permitan verificar que los cambios en infraestructura crítica se validan antes de ser aplicados en producción. 

Documento de política aprobado institucionalmente que regule la gestión de cambios tecnológicos y contemple explícitamente el tratamiento de cambios de emergencia. 

Procedimiento formal vigente, instructivos operativos, diagramas de flujo o manuales internos que detallen cómo se gestionan los cambios tecnológicos desde la solicitud hasta su cierre. 

Tickets, planillas, reportes del sistema o formularios de gestión de cambios que permitan verificar que cada cambio tiene un responsable asignado y una justificación documentada.  

Capturas de pantalla, licencias activas, manuales de uso o registros de operación en herramientas específicas (como Redmine, Jira, entre otras) que evidencien que se utilizan sistemas de soporte para la gestión de cambios. 

Informes de auditoría interna, listas de verificación, hallazgos documentados o registros de revisión que demuestren que se evalúa el cumplimiento del procedimiento de gestión de cambios. 

Correos, actas, presentaciones institucionales o informes de control que evidencien que los resultados de las revisiones de cambios son comunicados al RSI y a las áreas afectadas o interesadas. 

Tickets de corrección, planes de acción, minutas de seguimiento o documentación de mejora continua que permita verificar que, ante desviaciones detectadas en la gestión de cambios, se toman y documentan medidas correctivas. 

Informes de monitoreo, métricas de rendimiento, reportes de utilización o análisis de disponibilidad que evidencien que la capacidad actual instalada permite mantener operativos los servicios críticos. 

Tickets de soporte, registros técnicos, logs de eventos o minutas de intervención que permitan verificar que se toman acciones puntuales para restaurar la capacidad operativa ante incidentes de saturación. 

Informes de planificación, actas de reuniones interáreas, solicitudes de capacidad o análisis de demanda que evidencien que se contemplan los requerimientos del negocio al dimensionar servicios críticos. 

Tableros o dashboards de monitoreo, reportes automatizados, históricos de consumo de recursos o herramientas de observabilidad que permitan detectar tempranamente problemas de capacidad. 

Procedimiento formal, manual operativo o diagrama de procesos aprobado institucionalmente que defina cómo se gestiona la capacidad tecnológica en la organización.  

Matrices de asignación de funciones, manuales de rol, procedimientos con responsables identificados o resoluciones internas que evidencien quiénes son los encargados del proceso de gestión de capacidad. 

Acuerdos de nivel de servicio vigentes, cláusulas técnicas, anexos de servicios o compromisos formales que incluyan criterios de capacidad tecnológica dentro de su definición o seguimiento. 

Documento de planificación de capacidad aprobado y disponible, que incluya análisis actuales, proyecciones, riesgos identificados y acciones previstas para asegurar el desempeño futuro. 

Procedimientos técnicos, modelos de dimensionamiento, metodologías documentadas o herramientas utilizadas que evidencien cómo se realiza la estimación de capacidad dentro del marco del plan de gestión de la capacidad. 

Informes de actualización, versiones comparadas, actas de seguimiento o registros de revisión que permitan comprobar que el plan de capacidad es evaluado y ajustado regularmente. 

Minutas de reuniones técnicas, planes de acción, análisis de brechas o reportes de evolución que documenten acciones concretas propuestas para mejorar el proceso de gestión de capacidad. 

Diagramas de arquitectura, configuraciones de red, restricciones de acceso o documentación técnica que evidencien que el entorno de producción está efectivamente separado de los demás entornos.  

Listado de entornos, fichas técnicas, configuraciones de infraestructura o documentación de arquitectura que permita comprobar que existen plataformas adecuadas e independientes para las etapas de desarrollo, prueba y producción.  

Flujos de pasaje a producción, tickets de cambio, permisos de acceso o configuraciones de repositorios que evidencien que se aplican controles al momento de mover código, configuraciones o datos entre entornos. 

Políticas internas, registros de anonimización o seudonimización, controles de acceso o autorizaciones excepcionales que permitan verificar que el uso de datos reales en entornos de prueba está restringido o debidamente controlado.  

Documento de política vigente, aprobado por la dirección y difundido internamente, que establezca criterios formales para la separación lógica y física de entornos tecnológicos. 

Procedimiento operativo aprobado, instructivos técnicos o manuales de gestión que detallen cómo se administran los distintos entornos y cómo se realiza el pasaje entre ellos. 

Manuales de funciones, matrices de roles, asignaciones formales o procedimientos que identifiquen quiénes son los responsables de la gestión de entornos y del pasaje a producción. 

Planillas de pruebas, registros del sistema, bitácoras técnicas o capturas de herramientas que evidencien que durante las pruebas se registra información del entorno utilizado, incluyendo configuración y características de los datos de prueba. 

Informes de auditoría interna, listas de verificación, reportes de hallazgos o evidencias de control interno que permitan verificar el cumplimiento de la política de separación de entornos y sus procedimientos asociados. 

Informes de revisión, tickets de seguimiento, planes de acción o minutas de reuniones que evidencien que los resultados de las auditorías o controles son registrados y que se toman medidas correctivas cuando se detectan desvíos. 

Capturas de pantalla, reportes del sistema, inventarios de licencias o listados generados por la consola de administración que evidencien que todos los equipos del personal cuentan con protección antimalware instalada y activa.  

Tickets de soporte, registros de intervención, correos técnicos o minutas informales que permitan verificar que la resolución de infecciones o problemas vinculados a malware se realiza. 

Listados de servidores, reportes de instalación, capturas del sistema o registros del software de seguridad que evidencien que todos los servidores cuentan con soluciones antimalware activas. 

Capturas de configuración, políticas aplicadas por consola central, reportes de escaneo o planillas de verificación que permitan constatar que se realizan chequeos periódicos en los equipos del personal. 

Documento de política aprobado y difundido institucionalmente que establezca los lineamientos generales para la prevención, detección y tratamiento de software malicioso. 

Procedimiento formal vigente que describa los pasos a seguir ante la detección de malware, incluyendo responsables, plazos y registros asociados. 

Capturas de la consola central, registros de gestión, manuales de operación o reportes generados desde la plataforma que permitan verificar que la protección antimalware se gestiona de forma centralizada. 

Informes de gestión de activos y licenciamiento que verifiquen la correspondencia entre la cantidad de dispositivos en uso y las licencias de software antimalware adquiridas y asignadas, garantizando que no existan equipos sin cobertura. 

Listas de bloqueo, configuraciones de proxy, reportes de firewall o herramientas de filtrado web que evidencien que se han implementado controles para restringir el acceso a sitios maliciosos o no autorizados. 

Configuraciones de seguridad en móviles, manuales de MDM, capturas de aplicaciones de protección y versiones de la política de manejo de software malicioso donde se incluya explícitamente la protección contra software malicioso en dispositivos móviles.  

Procedimiento documentado, registros de escaneo, tickets de remediación o reportes técnicos que evidencien que se detectan equipos sin protección activa y se toman acciones correctivas para subsanar la situación.  

Bases de datos, reportes estadísticos, gráficos de tendencias o informes periódicos que documenten las infecciones detectadas, su análisis y la incorporación de esas lecciones en acciones de mejora continua. 

Registros de tareas programadas, reportes de ejecución de respaldos, cronogramas de respaldo o bitácoras de ejecución que evidencien que se realizan respaldos periódicos de aplicaciones, bases de datos y máquinas virtuales del centro de procesamiento de datos. 

Configuraciones de permisos, registros de acceso, ubicaciones físicas controladas, configuraciones de almacenamiento remoto o documentación técnica que evidencien que los respaldos se almacenan en lugares seguros y con acceso restringido. 

Procedimientos internos, configuraciones de las herramientas de respaldo, instructivos operativos o políticas técnicas donde se establezca el grado (completo, incremental, diferencial) y el período de retención de los respaldos.  

Reportes de prueba, registros de recuperación simulada, actas de ejercicios o tickets de verificación que demuestren que se realizan pruebas periódicas de recuperación a partir de respaldos.  

Configuraciones de almacenamiento, fichas técnicas de dispositivos, reportes de retención protegida o evidencias de uso de tecnologías que impidan la modificación posterior. 

Capturas de herramientas de respaldo, reportes de software de respaldo, configuraciones programadas o licencias activas que permitan verificar que se utilizan soluciones automatizadas para ejecutar respaldos. 

Documento de política vigente y aprobado, publicado internamente, que establezca los lineamientos generales para la ejecución, retención, almacenamiento y verificación de respaldos. 

Procedimientos técnicos detallados, manuales de recuperación, instructivos de ejecución de respaldos o versiones validadas de guías operativas que describan cómo se realizan y prueban los respaldos. 

Versiones comparadas del procedimiento, registros de revisión, tickets de actualización o actas de reuniones que permitan verificar que el procedimiento se actualiza cuando cambian los sistemas, infraestructura o requerimientos del negocio. 

Mapas de vinculación, anexos cruzados, referencias entre documentos o actas de coordinación que evidencien que la política y el procedimiento de respaldos están alineados con el plan de contingencia y el plan de recuperación de la organización. 

Cronogramas de revisión, informes de evaluación, registros de actualización o control de versiones que demuestren que tanto la política como el procedimiento de respaldos se revisan de manera periódica. 

Configuraciones del sistema, capturas de herramientas de logging, manuales técnicos o reportes de validación que evidencien que todos los sistemas definidos como críticos tienen habilitados los registros de auditoría y eventos.  

Reportes de análisis de incidentes, matrices de impacto, registros de evaluación posteriores al evento o minutas técnicas que permitan verificar que se analiza el impacto de los eventos sobre sistemas o servicios críticos. 

Manuales de funciones, asignación de turnos, matrices de roles o listas de responsables que evidencien que hay personal asignado para detectar eventos en sistemas base y dispositivos perimetrales. 

Capturas de sistemas, diagramas de arquitectura, licencias activas o registros de operación que evidencien el uso de herramientas que centralizan los logs de distintos activos tecnológicos.  

Configuraciones de permisos, controles de integridad, cifrado de registros o reportes de hardening que permitan verificar que los logs están protegidos contra accesos indebidos o alteraciones. 

Documentación técnica, matrices de criticidad, planes de continuidad o configuraciones del sistema que evidencien que se han establecido valores umbral (por ejemplo, respuesta máxima tolerable, carga aceptable, latencia crítica) para activos relevantes.  

Configuraciones de sistemas, políticas internas, ejemplos de alertas generadas o reportes de monitoreo que permitan verificar que los sistemas críticos emiten alertas conforme al apetito de riesgo definido por la organización. 

Capturas de herramientas de monitoreo, logs de eventos generados automáticamente, scripts de detección o reportes configurados que evidencien que se generan alertas automáticas ante eventos como conexiones externas, instalaciones no autorizadas, etc. 

Matrices de responsabilidades, manuales de funciones o procedimientos técnicos que indiquen qué áreas o perfiles participan en actividades de monitoreo, incluyendo aquellas gestionadas mediante herramientas automatizadas. 

Políticas de seguridad, procedimientos de archivo, configuraciones del sistema o documentos técnicos que establezcan los tiempos de conservación y eliminación de registros de auditoría. 

Configuraciones de sincronización, capturas del servicio NTP, registros de monitoreo o informes de revisión que permitan verificar que todos los sistemas tienen relojes sincronizados. 

Políticas de privacidad, cláusulas en la política de auditoría, instructivos internos o restricciones de acceso que evidencien que se protegen los datos personales contenidos en los registros. 

Documento de política vigente y aprobado que establezca lineamientos para el registro, tratamiento y revisión de eventos, incluyendo sistemas de red, WAF y configuraciones críticas. 

Procedimientos operativos, flujos de revisión, instructivos técnicos o versiones controladas que describan cómo se auditan y registran los eventos. 

Capturas de herramientas SIEM, informes de correlación, reportes de incidentes agrupados o diagramas de arquitectura que demuestren el uso de soluciones que integran múltiples fuentes para correlacionar eventos. 

Procedimientos documentados con actividades específicas para la detección y monitoreo de eventos, incluyendo configuraciones de alertas, responsables y frecuencia de revisión. 

Procedimientos formales donde consten los umbrales de alerta y los criterios de impacto, ya sea en anexos, secciones técnicas o plantillas utilizadas en el monitoreo. 

Informes de simulacros, registros de pruebas de detección, minutas de validación o tickets de mejora que evidencien que el procedimiento de monitoreo se prueba regularmente. 

Reportes de auditoría, registros de sesión, configuraciones de control de privilegios o herramientas de monitoreo que permitan revisar específicamente la actividad realizada por usuarios con privilegios elevados. 

Configuraciones de respuesta automática, reglas definidas en SIEM/SOAR, scripts ejecutados ante incidentes o ejemplos de acciones generadas automáticamente ante eventos de seguridad. 

Informes de auditoría, listas de verificación, actas de revisión o resultados documentados de controles internos que verifiquen el cumplimiento de la política y los procedimientos de monitoreo y auditoría. 

Informes finales, actas de reunión, correos institucionales o presentaciones que evidencien que los resultados de las revisiones fueron compartidos con el RSI y otras partes relevantes de la organización. 

Instructivos internos, manuales de operación, procedimientos técnicos o publicaciones institucionales que establezcan las reglas y condiciones bajo las cuales se permite la instalación de software en los equipos de la organización. 

Correos institucionales, registros de capacitación, publicaciones en intranet o actas de comunicación que evidencien que las pautas de instalación de software fueron comunicadas al personal.  

Configuraciones de control de privilegios, políticas de grupo, registros de roles o tickets de solicitud que demuestren que únicamente los usuarios autorizados pueden instalar software en los equipos. 

Configuraciones de sistemas operativos, manuales técnicos, controles de acceso o políticas internas que permitan verificar que existe una separación clara entre utilidades del sistema y software de aplicación, limitando el acceso a componentes críticos.  

Listados de software admitido, actas de aprobación, versiones controladas o planillas firmadas que evidencien que existe una lista oficial de software autorizado y que esta ha sido revisada y aprobada por el RSI. 

Informes de revisión, escaneos de inventario, herramientas de detección o reportes técnicos que evidencien que se realizan controles para verificar que el software instalado cumple con la lista autorizada. 

Informes de control, correos institucionales, presentaciones o actas de reunión que demuestren que los resultados de las revisiones sobre software instalado fueron comunicados al RSI y a las áreas correspondientes.