Gestión de proyectos de ciberseguridad: importancia y mejores herramientas para la gestión de proyectos

La gestión de proyectos de ciberseguridad es la disciplina que aplica un alcance, cronograma, presupuesto, riesgos, recursos y evidencias de gobernanza estructurados a la implementación de iniciativas de seguridad. Cierra la brecha entre lo que descubre el equipo de seguridad y lo que realmente se corrige, se gestiona y se demuestra ante los auditores.

No es lo mismo que proteger los datos de gestión de proyectos, aunque eso también es importante. Gestionar un proyecto de ciberseguridad implica tomar los resultados de las pruebas de penetración, los análisis de vulnerabilidades, las auditorías GRC y las revisiones de arquitectura, y convertirlos en un trabajo priorizado, programado, asignado y documentado, entregado a tiempo y con rendición de cuentas en cada etapa.

Un gestor de proyectos de ciberseguridad no sustituye a un CISO, un arquitecto de seguridad ni un especialista en pruebas de penetración. Son el pilar fundamental que garantiza que el trabajo de cada especialista se complete, documente y dé por finalizado el proyecto.

La mayoría de los gestores de proyectos que se incorporan a puestos de seguridad descubren rápidamente que los modelos de entrega estándar resultan ineficaces. En un proyecto de TI típico, "terminado" significa que la funcionalidad se ha lanzado y los usuarios la han aceptado. En un proyecto de ciberseguridad, "terminado" significa que el control se ha implementado, validado y documentado, y que el riesgo residual ha sido formalmente aceptado por la autoridad competente.

Una regla de firewall implementada sin validación, un despliegue de autenticación multifactor con cobertura no verificada o un parche aplicado sin pruebas de regresión pueden mostrar una finalización del 100 % en un diagrama de Gantt, pero sin que la organización sea más segura que antes. La labor del gerente de proyecto de seguridad consiste en cerrar el círculo entre la ejecución de las tareas y el resultado real en materia de seguridad.

El panorama de las partes interesadas también es fundamentalmente diferente. Mientras que un proyecto de TI estándar involucra a un patrocinador, un grupo de usuarios y un equipo de TI, un proyecto de seguridad involucra al CISO, responsables de riesgos, líderes de cumplimiento, asesores legales, auditores internos, reguladores externos y, a menudo, un comité de riesgos a nivel de junta directiva, cada uno con diferentes necesidades de información, diferentes niveles de tolerancia al riesgo y diferentes definiciones de éxito.

El cumplimiento rara vez es opcional. Las solicitudes de cambio en los proyectos de seguridad deben evaluarse no solo en función del impacto en el cronograma y el costo, sino también para determinar si abren una nueva superficie de ataque o modifican el nivel de riesgo. El monitoreo posterior al proyecto no termina con la puesta en marcha, sino que continúa mientras se siga utilizando el control. Estas diferencias requieren un enfoque de gestión deliberadamente distinto, razón por la cual las herramientas y los procesos diseñados para la entrega estándar de TI a menudo resultan insuficientes.

Los programas de seguridad fracasan no porque las organizaciones desconozcan lo que hay que hacer, sino porque el trabajo no se planifica, no se dota de recursos, no se supervisa ni se documenta con la suficiente disciplina como para completarse con éxito.

El cumplimiento normativo es una de las razones más inmediatas por las que la disciplina en la gestión de proyectos de seguridad da sus frutos. Marcos como ISO/IEC 27001:2022, SOC 2 Tipo II, NIST Cybersecurity Framework 2.0, PCI DSS 4.0, HIPAA y CMMC 2.0 exigen la implementación demostrable de controles específicos dentro de plazos definidos. En la práctica, cada requisito de control es un elemento de trabajo del proyecto con un responsable, una fecha límite y la obligación de aportar pruebas. Sin una gestión de proyectos estructurada, las organizaciones suelen incumplir los plazos de remediación, entregar pruebas de auditoría incompletas y repetir los mismos hallazgos auditoría tras auditoría.

La seguridad desde el diseño requiere que un gestor de proyectos esté presente en la planificación del programa, no solo al momento de la entrega. Tanto el Marco de Desarrollo de Software Seguro del NIST como el Anexo A de la norma ISO 27001 exigen que los requisitos de seguridad se identifiquen con anticipación. Un gestor de proyectos de seguridad garantiza que el modelado de amenazas, la revisión de la arquitectura, los requisitos de codificación segura y los controles de seguridad de lanzamiento sean actividades programadas con responsables confirmados, y no añadidos a posteriori una vez que el desarrollo ya está en marcha.

La coordinación interfuncional es donde con mayor frecuencia fracasan los proyectos de seguridad. El trabajo de seguridad involucra a equipos que rara vez comparten una línea jerárquica: ingeniería de seguridad, infraestructura, DevOps, cumplimiento normativo, legal, adquisiciones y gestión de proveedores. El gerente de proyecto de seguridad es el nexo que traduce los hallazgos técnicos en un lenguaje de riesgo empresarial que los ejecutivos puedan utilizar, y que traduce los requisitos de gobernanza en tareas concretas que los equipos de ingeniería puedan ejecutar.

La preparación para la auditoría es resultado directo de una buena gestión de proyectos. Los registros de decisiones, los registros de aprobación, los registros de evidencia y las solicitudes de cambio conforman la pista de auditoría que las herramientas de seguridad independientes no pueden generar. Cuando un auditor pregunta por qué se aceptó un control específico como riesgo residual, la respuesta debe constar en un registro formalmente documentado y fechado, no reconstruido a partir de la memoria o de conversaciones de correo electrónico.

La priorización de recursos y presupuesto depende de la visibilidad a nivel de cartera que solo una gestión de proyectos estructurada puede proporcionar. Los ingenieros de seguridad son escasos. Los CISO que pueden demostrar, con datos, qué iniciativas consumen capacidad y cuál es el retorno en la reducción de riesgos están en una posición mucho mejor para justificar la asignación de presupuesto y personal.

El gestor de proyectos de seguridad es responsable de la gobernanza de la implementación de una o más iniciativas de seguridad. Comprender este rol es importante porque las organizaciones a menudo le asignan recursos insuficientes (esperando que un ingeniero de seguridad también gestione el proyecto) o lo definen erróneamente (esperando que el gestor de proyectos tome decisiones sobre riesgos que corresponden al CISO o al responsable de riesgos).

La gestión del alcance implica definir los límites del proyecto de seguridad y, fundamentalmente, los criterios de aceptación de seguridad junto con el CISO o el responsable de riesgos. No se trata solo de «implementar la herramienta», sino de «implementar la herramienta, validar la cobertura en todos los puntos finales de producción y generar un informe final revisado por el responsable de seguridad».

La gestión del cronograma en un contexto de seguridad incluye la incorporación de puntos de control de seguridad en el plan, así como puntos de revisión formal donde se confirman los criterios de aceptación de seguridad antes de que el proyecto avance. Estos no son hitos opcionales que puedan acortarse cuando se retrasa el cronograma.

La gestión de riesgos implica mantener un registro de riesgos actualizado durante todo el proceso de entrega, facilitar revisiones periódicas de riesgos y escalar los riesgos aceptados o no resueltos a la autoridad competente con la documentación adecuada. El director de proyecto no toma decisiones sobre la aceptación de riesgos, pero es responsable de garantizar que dichas decisiones sean tomadas por la persona correcta y registradas adecuadamente.

La gestión de la evidencia suele pasarse por alto en las definiciones de roles de gestión de proyectos, pero es fundamental para el éxito de un programa de seguridad. El gestor de proyectos debe asegurarse de que, al finalizar cada tarea, la evidencia correspondiente se recopile, revise y almacene de acuerdo con los requisitos de retención de la organización, y no se deje como una actividad de cierre.

La comunicación ejecutiva en los programas de seguridad requiere traducir los datos de riesgo y control a formatos que permitan a los consejos de administración y a los altos directivos tomar medidas: porcentaje de vulnerabilidades críticas vencidas, tasa de cumplimiento del SLA de remediación, antigüedad de la aceptación de riesgos y tasa de aprobación de las puertas de seguridad, no solo el estado RAG y los porcentajes de hitos.

El gerente de proyecto no realiza pruebas de penetración, revisiones de arquitectura, configuración de controles de seguridad ni toma decisiones sobre la aceptación de riesgos. Esas responsabilidades corresponden a los arquitectos de seguridad, ingenieros, analistas, el CISO y los responsables de riesgos, respectivamente.

El alcance del trabajo de un gerente de producto de seguridad es mayor de lo que la mayoría de las organizaciones esperan inicialmente. Las implementaciones de IAM y PAM implican una integración compleja de múltiples sistemas, una intensa coordinación con proveedores y requisitos de gobernanza por fases que se extienden durante meses. Las implementaciones de MFA son engañosamente intensivas en gestión del cambio; el seguimiento de excepciones y la verificación de la adopción requieren tanta disciplina de gestión de producto como la implementación técnica. Los programas de remediación de vulnerabilidades son esencialmente una gestión continua de la cartera de tareas pendientes con responsabilidad de SLA, evidencia de regresión y dependencia de los ciclos de lanzamiento de parches de terceros.

La remediación tras una prueba de penetración es un tipo de proyecto que a menudo se subestima. La prueba genera una lista de hallazgos, pero convertir esa lista en un proyecto de remediación planificado, con recursos asignados y evidencias, que incluya la coordinación de nuevas pruebas y el cierre formal, representa un esfuerzo significativo de gestión de proyectos en sí mismo.

La preparación para SOC 2 y la implementación de ISO 27001 son proyectos de cumplimiento que requieren la asignación de controles a evidencias en decenas o cientos de requisitos, la coordinación entre responsables multifuncionales y la gestión de la comunicación con los auditores. Las implementaciones de SIEM tienen fases distintas de infraestructura, integración y entrega de casos de uso que deben secuenciarse cuidadosamente. Los programas de Confianza Cero son iniciativas de cartera de varios años que requieren la planificación de flujos de trabajo en los dominios de identidad, red, dispositivo y datos, con importantes interdependencias.

Lo que todos estos sistemas tienen en común es que requieren más que un simple seguimiento de tareas. Requieren una planificación que tenga en cuenta los riesgos, una gestión basada en la evidencia, una gestión de dependencias, una rendición de cuentas interfuncional y la elaboración de informes para la alta dirección, y es precisamente ahí donde Celoxis aporta valor.

La mayoría de los programas de seguridad cuentan con marcos de gobernanza adecuados y herramientas técnicas razonables. El problema radica en no saber qué hacer, sino en la ejecución disciplinada de la transformación de los resultados de la gobernanza en proyectos planificados, con recursos asignados, documentados y cerrados. SECURE proporciona una estructura de seis etapas para lograr precisamente eso.

S

Definir el alcance del resultado de seguridad

La primera fase define no solo qué entregará el proyecto, sino también qué resultado de seguridad debe lograr. Esto implica documentar el objetivo de negocio, el objetivo de seguridad, los sistemas y datos afectados, los límites del proyecto y, sobre todo, los criterios de aceptación de seguridad. Estos criterios definen el estado mínimo de control que se considera finalizado y deben ser acordados con el CISO o el responsable de riesgos antes de que comience la planificación.

Documento clave: Acta Constitutiva del Proyecto de Ciberseguridad

Criterio de salida: Un estatuto aprobado por el patrocinador con criterios explícitos de aceptación de seguridad y una lista confirmada de activos incluidos en el alcance.

mi

Evaluar riesgos y obligaciones

Antes de elaborar el cronograma, es necesario analizar el panorama de amenazas. Esta etapa identifica amenazas, vulnerabilidades, obligaciones regulatorias, deficiencias en los controles, dependencias de terceros, riesgo inherente, riesgo residual y el nivel de riesgo aceptable de la organización. Los plazos regulatorios, como una auditoría de vigilancia ISO 27001, un período de evaluación CMMC y un análisis trimestral PCI DSS, deben confirmarse e incorporarse a la línea base del cronograma.

Artefacto clave: Registro de riesgos

Criterio de salida: Un registro de referencia con todos los riesgos altos y críticos asignados a un propietario y un plan de tratamiento.

do

Convertir controles en trabajo ejecutable

Esta es la etapa que la mayoría de los programas de seguridad pasan por alto. Los resultados de NIST, los controles del Anexo A de ISO 27001, los hallazgos de auditoría y los requisitos de arquitectura deben traducirse en tareas específicas, asignadas y programadas, en lugar de quedar como documentos de gobernanza en una plataforma GRC. Cada control se corresponde con una o más tareas, cada tarea tiene un responsable y una fecha límite, y cada tarea cuenta con criterios de aceptación y requisitos de evidencia definidos.

Artefacto clave: Matriz de control a trabajo

Criterio de salida: El 100% de los controles requeridos se han asignado a al menos un elemento de trabajo programado y de propiedad exclusiva.

U

Unificar propietarios, recursos y dependencias

Los proyectos de seguridad suelen fallar durante la transición entre equipos. Esta etapa confirma los recursos asignados y la capacidad de las áreas de seguridad, ingeniería, infraestructura, DevOps, cumplimiento normativo, asesoría legal, adquisiciones y proveedores. Además, crea el mapa de dependencias integrado y establece el protocolo de escalamiento antes de que surjan problemas.

Artefacto clave: Mapa de dependencias y RACI

Criterio de salida: Todos los responsables de los flujos de trabajo han confirmado su participación, el plan de recursos está definido como línea base y la ruta de escalamiento está documentada.

R

Revisar continuamente los riesgos, las evidencias y las medidas correctivas

La entrega no es una fase pasiva. Esta etapa incluye revisiones semanales de riesgo y estado, seguimiento del cumplimiento del SLA de remediación, gestión de solicitudes de cambio con evaluación de impacto en la seguridad, escalamiento de elementos vencidos y supervisión de la preparación de los controles de seguridad. La evidencia se recopila a medida que se completan las tareas, no como una actividad de cierre.

Artefactos clave: Registro de riesgos vivos y registro de evidencias

Criterio de salida: Se han superado todos los controles de seguridad con la documentación justificativa y no hay artículos críticos pendientes de devolución sin un riesgo formalmente aceptado.

mi

Evidencia, intensificación y evolución

El cierre de un proyecto en un contexto de seguridad requiere más que una simple aprobación. Esta etapa valida todos los criterios de aceptación de seguridad, confirma que el registro de evidencias esté completo y se conserve según la política establecida, obtiene la aceptación formal del riesgo para los elementos residuales, transfiere la responsabilidad del monitoreo operativo y documenta las lecciones aprendidas.

Artefacto clave: Lista de verificación para el cierre de la puerta de seguridad

Criterio de salida: Se cumplen o se aceptan formalmente todos los criterios de aceptación, el registro de evidencias está completo y se confirma la propiedad operativa.

La diferencia entre un programa de seguridad que supera la auditoría y uno que no, a menudo no radica en los controles de seguridad en sí, sino en la disciplina de documentación que los rodea. Estos son los elementos esenciales que un gestor de proyectos de seguridad debe mantener a lo largo de cada proyecto.

El acta constitutiva del proyecto de ciberseguridad es el documento fundamental. Define el alcance, los objetivos, los criterios de aceptación de seguridad, la autoridad del patrocinador y el procedimiento de escalamiento. Debe aprobarse antes de iniciar cualquier otra planificación y solo puede modificarse mediante un proceso formal de gestión de cambios.

El Registro de Riesgos es un documento dinámico, no un ejercicio puntual. Realiza un seguimiento de los riesgos identificados, su probabilidad, impacto, enfoque de tratamiento, responsable y riesgo residual durante todo el proceso de entrega. En Celoxis, los registros de riesgos e incidencias se pueden configurar como flujos de trabajo personalizados, lo que permite visualizar el riesgo junto con el cronograma del proyecto, en lugar de tenerlo en una hoja de cálculo aislada.

El registro RAID de riesgos, suposiciones, problemas y dependencias en un único registro gestionado garantiza que los obstáculos, las preguntas abiertas y las dependencias entre equipos se controlen, se les asigne un responsable y se les dé prioridad, en lugar de que se pierdan entre las actualizaciones de los equipos.

La Matriz de Controles y Tareas es el documento que transforma la gobernanza en ejecución. Asigna cada control requerido a las tareas que lo implementan, al responsable, la evidencia necesaria, la fecha límite y los criterios de aceptación. Este es el documento más importante que mantiene un gerente de proyecto de seguridad, y es el que con mayor frecuencia falta en programas inmaduros.

El de tareas pendientes de remediación de vulnerabilidades realiza un seguimiento de los hallazgos abiertos de los análisis de vulnerabilidades y las pruebas de penetración, priorizados por gravedad, con objetivos de SLA, asignación de responsable y estado. En Celoxis, esto se puede gestionar como un registro de tareas pendientes del proyecto con campos de gravedad personalizados, seguimiento de SLA e informes en el panel de control por nivel de riesgo.

El Registro de Evidencia documenta qué evidencia se ha recopilado para cada control, dónde se almacena, qué versión es y quién la revisó. Sin este registro, la preparación de la auditoría se convierte en una búsqueda frenética en unidades compartidas y archivos de correo electrónico.

El registro de aceptación de riesgos es el registro formal de cada riesgo aceptado en lugar de tratado, incluyendo la justificación, el aprobador, la fecha de vencimiento y cualquier condición asociada. Este es un registro de gobernanza, no una herramienta de gestión de proyectos, y debe conservarse de acuerdo con la política de retención de evidencia de la organización.

La lista de verificación de seguridad confirma, en cada etapa, que se han cumplido los criterios de aceptación de seguridad para esa fase antes de que el proyecto avance. En Celoxis, las etapas se pueden configurar como flujos de trabajo de aprobación que requieren que los aprobadores designados den su visto bueno antes de que se desbloquee la siguiente fase.

Notas de cada proveedor 

Celoxis

Celoxis se posiciona como una plataforma que combina la gobernanza de cartera, la programación Gantt con análisis de ruta crítica, el seguimiento de dependencias entre proyectos, la planificación de la capacidad de recursos y el seguimiento financiero de forma nativa en un solo sistema, con la flexibilidad añadida de la implementación local para las organizaciones que lo necesiten.

En lo que respecta a la gestión de proyectos de ciberseguridad, Celoxis actúa como la capa de ejecución y gobernanza de cartera que conecta los resultados de la gobernanza de seguridad con la rendición de cuentas en la entrega. Los flujos de trabajo de riesgo y RAID se configuran como flujos de trabajo personalizados estructurados, no como campos de texto libre, de modo que los registros de riesgo, los registros de evidencia y los registros de aceptación de riesgo forman parte del proceso normal de entrega del proyecto, en lugar de ser documentos administrativos paralelos. Las aprobaciones de las puertas de seguridad se crean como flujos de trabajo de aprobación enrutados con registros con marca de tiempo, lo que genera el registro de auditoría que requieren los programas de seguridad basados ​​en evidencia.

La integración de Jira y Azure DevOps es bidireccional, lo cual es fundamental en programas de seguridad donde los hallazgos se registran en Jira y la entrega se gestiona en Celoxis, permitiendo la comunicación entre ambas plataformas sin sincronización manual. Para organizaciones con requisitos de residencia de datos, la implementación local está disponible junto con la opción en la nube, lo que significa que las oficinas de gestión de proyectos de seguridad no tienen que elegir entre funcionalidad y cumplimiento normativo.

En G2, Celoxis tiene actualmente una calificación de 4.6 sobre 5 basada en más de 650 reseñas. Los usuarios de PMO de TI y seguridad citan con mayor frecuencia la combinación de planificación de recursos, gestión de dependencias entre proyectos e informes de cartera en una sola plataforma como la razón por la que optaron por no usar herramientas separadas. La desventaja más mencionada es que la profundidad de la configuración disponible puede generar una curva de configuración inicial más pronunciada que la de herramientas más sencillas como Wrike o Smartsheet. Sin embargo, los usuarios generalmente describen esta curva como algo que vale la pena una vez que la plataforma se configura según los requisitos del programa.

Celoxis es la opción correcta cuando su programa de seguridad gestiona múltiples iniciativas simultáneas que requieren gobernanza a nivel de cartera, gestión de la capacidad de recursos y flujos de trabajo formales de riesgo y aprobación, y cuando necesita una plataforma que pueda coexistir con GRC y Jira sin duplicar ninguna de ellas.

Jira (Atlassian)

Jira es el punto de partida más común para los equipos de seguridad que ya forman parte del ecosistema de Atlassian. Su flexibilidad y su amplio mercado la convierten en una opción fiable para la gestión de la corrección de vulnerabilidades, la administración de los sprints de DevSecOps y el seguimiento de los resultados de las pruebas de penetración, especialmente cuando el trabajo de seguridad se integra con la entrega de software en la misma herramienta.

La limitación se hace evidente a nivel de portafolio. Jira es un sistema de seguimiento de incidencias, no una plataforma PPM. La planificación de la capacidad de recursos a nivel de portafolio, la gobernanza financiera y los informes ejecutivos entre proyectos requieren hojas de ruta avanzadas o complementos de terceros, lo que añade complejidad y coste de configuración. Los registros de riesgos y los registros RAID son posibles en Jira, pero requieren una configuración personalizada en lugar de flujos de trabajo nativos, lo que significa que a menudo se vuelven inconsistentes entre equipos con el tiempo. Jira Government Cloud cuenta con la autorización FedRAMP para cargas de trabajo federales de EE. UU., pero, como con cualquier autorización, las organizaciones deben confirmar que su configuración específica y el manejo de datos cumplen con sus requisitos de cumplimiento, en lugar de asumir que la autorización a nivel de infraestructura se extiende a su uso.

Jira es la opción ideal cuando el trabajo de seguridad es inseparable del proceso de entrega de software y el equipo ya utiliza ampliamente la plataforma Atlassian. Resulta menos adecuada cuando la necesidad principal es la gobernanza del portafolio, la planificación de recursos y la gestión formal del flujo de trabajo de riesgos en múltiples programas de seguridad simultáneos.

Wrike

Wrike se sitúa en un punto intermedio idóneo entre la gestión de proyectos sencilla y la gestión integral de proyectos empresariales. Sus funciones de automatización de flujos de trabajo configurables y de colaboración interfuncional lo convierten en una opción razonable para equipos de seguridad que necesitan una estructura de gobernanza más sólida que la que ofrece Jira, pero que aún no gestionan una amplia cartera de múltiples programas.

Wrike cuenta con las certificaciones SOC 2 Tipo II e ISO 27001, admite SAML SSO, autenticación de dos factores y ofrece opciones de residencia de datos en la UE y EE. UU. Wrike Lock, que proporciona a las organizaciones claves de cifrado gestionadas por el cliente, está disponible en determinados niveles empresariales; verifique la disponibilidad actual y los requisitos del nivel antes de incluirlo en una evaluación.

La desventaja es que la gestión de recursos y la gobernanza financiera de Wrike a nivel de cartera son menos maduras que las plataformas PPM especializadas para organizaciones que ejecutan programas de seguridad grandes y complejos. Los registros de riesgos, los registros RAID y los flujos de trabajo de evidencia son configurables, pero no nativos, lo que significa que requieren una configuración y un mantenimiento rigurosos para que sigan siendo útiles. Actualmente, Wrike no ofrece la implementación local, lo que supone una limitación para los contratistas de defensa y los programas de seguridad gubernamentales con estrictos requisitos de residencia de datos.

Hoja inteligente

La interfaz basada en cuadrículas de Smartsheet la convierte en una de las herramientas más fáciles de adoptar para equipos que migran desde hojas de cálculo, lo que representa una ventaja real en organizaciones donde la gestión del cambio es tan importante como la funcionalidad. Su fortaleza reside en su flexibilidad estructurada: prácticamente cualquier flujo de trabajo se puede crear en Smartsheet con el esfuerzo de configuración necesario, y es una plataforma que tiende a difundirse de forma orgánica una vez que un equipo la adopta.

Para las cargas de trabajo del gobierno estadounidense, Smartsheet Gov cuenta con la autorización FedRAMP, una credencial importante para los programas de seguridad federales. Dispone de las certificaciones SOC 2 Tipo II e ISO 27001, y ofrece inicio de sesión único SAML, aprovisionamiento SCIM y autenticación multifactor.

La limitación para la gestión de programas de seguridad complejos es estructural. Smartsheet se basa en cuadrículas y hojas, lo que facilita el seguimiento mediante listas, pero genera dificultades para la programación compleja de predecesores y sucesores en grandes planes de proyectos integrados. La planificación de la capacidad de recursos a nivel de cartera y el seguimiento financiero suelen requerir planes de nivel superior y un mayor esfuerzo en la creación de paneles de control, en comparación con las plataformas diseñadas desde el principio para la gobernanza de PPM. Los flujos de trabajo de aceptación de riesgos y RAID son posibles, pero requieren una configuración específica para mantener registros con calidad de auditoría.

Proyecto abierto

OpenProject es la plataforma más relevante para organizaciones donde la soberanía de los datos es el criterio de selección principal. Como plataforma de código abierto y autogestionada, ofrece a las organizaciones un control total sobre dónde se almacenan los datos de sus proyectos, cómo se cifran y quién puede acceder a ellos, lo que supone un factor diferenciador clave para contratistas de defensa, agencias gubernamentales e instituciones financieras altamente reguladas que no pueden alojar los datos de sus proyectos en una nube comercial.

Admite autenticación LDAP y SAML, control de acceso basado en roles y seguimiento de paquetes de trabajo adaptable que se puede configurar para la gestión de riesgos e incidencias. Su planificación mediante diagramas de Gantt y el seguimiento de dependencias entre proyectos ofrecen una mayor profundidad de planificación nativa que la mayoría de las herramientas de gestión de trabajo.

La limitación radica en la madurez de la gestión de cartera de proyectos (PPM) a nivel empresarial. El análisis de cartera, la planificación de la capacidad de recursos en equipos grandes y la gobernanza financiera están menos desarrollados que en las plataformas PPM comerciales. Los acuerdos de nivel de servicio (SLA) de soporte y los compromisos de mantenimiento dependen de la edición elegida y del alojamiento. Para organizaciones donde la implementación autogestionada es un requisito indispensable y la complejidad de la gobernanza de cartera es moderada, OpenProject es una opción sólida. Para organizaciones que necesitan una gobernanza financiera de cartera profunda junto con un control total de los datos, es necesario evaluar cuidadosamente las ventajas y desventajas.

Los informes de los programas de seguridad deben distinguir entre las métricas de entrega y las métricas de resultados de seguridad. Un programa puede estar dentro del 95 % del cronograma previsto, pero las vulnerabilidades críticas pueden permanecer sin corregir y los controles clave pueden no estar documentados.

Los KPI que importan a un CISO son las métricas de resultados de seguridad: el número de vulnerabilidades críticas que superan su objetivo de SLA, el porcentaje de hallazgos corregidos dentro del SLA acordado, la tasa de finalización de controles de seguridad en cada fecha de control, la tasa de completitud de la evidencia antes de una auditoría, la tasa de aprobación de la seguridad en la primera revisión y si alguna aceptación de riesgo ha superado su fecha de revisión. Estos deben ser monitoreados e informados por separado, pero junto con las métricas de entrega estándar, como la variación del cronograma, la variación de los hitos, la variación del presupuesto y la utilización de recursos.

En Celoxis, se pueden crear paneles personalizados para mostrar ambas categorías simultáneamente, lo que proporciona a los responsables de la PMO de seguridad y a los CISO una visión unificada del estado del programa que refleja tanto la disciplina de ejecución como el progreso en los resultados de seguridad.

Los proyectos de seguridad gubernamentales y de la industria regulada operan bajo requisitos de gobernanza que difieren sustancialmente de los estándares del sector comercial, y la elección de la plataforma de gestión de proyectos debe reflejar esos requisitos.

Las normas de soberanía de datos pueden restringir el lugar donde se pueden almacenar los datos del proyecto, incluidos los registros de riesgos, los registros de vulnerabilidades y la evidencia de auditoría. Los proveedores deben comprometerse con ubicaciones específicas de centros de datos, no solo con disponibilidad regional general. Es posible que la política o el contrato exijan la implementación en las instalaciones o en una nube certificada por el gobierno, y las organizaciones deben verificar cualquier estado de autorización declarado directamente en el registro autorizado. El uso por parte de un proveedor de un proveedor de nube que admita cargas de trabajo FedRAMP no convierte el producto de ese proveedor en FedRAMP Authorized. La autorización se aplica al producto, no a la infraestructura subyacente.

Los requisitos de identidad en entornos gubernamentales suelen exigir la autenticación mediante PIV/CAC o la integración SAML con proveedores de identidad gubernamentales, junto con una estricta aplicación del principio de mínimo privilegio. Los periodos de retención de los registros de auditoría y los formatos de evidencia deben cumplir con los requisitos específicos del gobierno, y los registros deben poder exportarse en formatos auditables.

La opción de implementación local de Celoxis es directamente relevante en este caso. Las organizaciones que no pueden alojar los datos de sus proyectos en una nube comercial pueden implementar Celoxis en su propia infraestructura, manteniendo un control total sobre la ubicación, el acceso y la retención de los datos, al tiempo que se benefician de las capacidades de gestión de proyectos y carteras de nivel empresarial.

Este es un escenario representativo basado en patrones comunes en los programas de seguridad empresarial. No representa a un cliente específico de Celoxis, sino que refleja los desafíos reales que enfrentan los gerentes de proyecto de seguridad al gestionar la certificación de cumplimiento junto con el trabajo de remediación activa.

La situación

Una empresa mediana de servicios financieros se ha comprometido a obtener la certificación ISO/IEC 27001:2022. El consejo de administración ha fijado un plazo estricto: la auditoría externa está prevista para dentro de 22 semanas. Dos semanas antes de la incorporación del gestor de proyectos de seguridad, una prueba de penetración interna arroja resultados que no pueden ignorarse: cuatro hallazgos críticos y once de alta gravedad, todos los cuales requieren una subsanación documentada antes de que se abra el plazo de auditoría.

Esta es una situación que muchos gerentes de producto de seguridad conocen bien. No se parte de cero, pero tampoco se parte de una base sólida. Hay un programa de cumplimiento que implementar, una acumulación de correcciones pendientes que resolver, un equipo multifuncional que aún no se ha alineado formalmente y una fecha límite de auditoría que no se puede modificar.

El primer instinto del responsable de seguridad suele ser crear una hoja de cálculo y empezar a asignar tareas. Este instinto es comprensible, pero también es donde muchos programas empiezan a perder el control. A continuación, se explica cómo se desarrolla este escenario de forma diferente cuando se aplica el marco SECURE dentro de Celoxis.

Definición del alcance y elaboración de los estatutos

La primera acción del gestor de proyectos de seguridad no es abrir una lista de tareas, sino definir qué significa realmente "terminado" para este programa. En colaboración con el CISO y el responsable de riesgos designado, el gestor de proyectos elabora un acta constitutiva del proyecto en Celoxis que define el alcance del SGSI (sistemas de procesamiento de datos de clientes, infraestructura en la nube y procesos centrales de RR. HH.), los criterios de aceptación de seguridad para la preparación de auditorías, los requisitos de evidencia por control y la fecha límite de auditoría innegociable.

Este estatuto no es un documento que se archiva y se olvida. En Celoxis, se convierte en la referencia principal para cada debate sobre el alcance, solicitud de cambio y decisión sobre la asignación de recursos. Cuando el equipo de infraestructura pregunta si un servidor heredado debe incluirse en el alcance del SGSI, la respuesta se encuentra en el estatuto acordado, fechado y firmado por el patrocinador.

Conversión de 93 controles en un cronograma de entregables

Un análisis de brechas con respecto al Anexo A de la norma ISO/IEC 27001:2022 identifica 17 áreas de brechas de control donde la organización no cuenta con ningún control o tiene uno que actualmente no puede generar evidencia de calidad para auditoría. Cada brecha se convierte en un paquete de trabajo en el plan del proyecto Celoxis, vinculado a su control específico del Anexo A mediante un campo personalizado. Esta vinculación es lo que transforma un documento de gobernanza en un cronograma de entregables.

Los cuatro hallazgos críticos de las pruebas de penetración se convierten en tareas de remediación con acuerdos de nivel de servicio (SLA) de dos semanas. Los once hallazgos de alta gravedad tienen SLA de cuatro semanas. Cada tarea tiene un responsable designado según el plan de recursos, un requisito de evidencia definido y un criterio de aceptación que especifica qué significa realmente "remediado", no solo "corrección aplicada", sino "corrección aplicada, prueba de regresión realizada y confirmación de ausencia de vulnerabilidades mediante un nuevo análisis DAST"

En este punto, el gerente de proyecto de seguridad no solo tiene una lista de tareas, sino una línea base completa del proyecto: 93 controles contabilizados, brechas asignadas a paquetes de trabajo, hallazgos de pruebas de penetración en la lista de tareas de remediación, responsables confirmados y el plazo de auditoría de 22 semanas visible como el hito principal en el diagrama de Gantt.

Donde las dependencias crean un riesgo real

En la práctica, las implementaciones de la norma ISO 27001 casi siempre revelan dependencias que no se previeron al inicio. En este caso, la más significativa aparece a las cuatro semanas.

La actualización del acuerdo con el proveedor, necesaria para cumplir con la norma ISO 27001 A.5.20, que rige la seguridad de la información en las relaciones con proveedores, depende de que el equipo legal complete una revisión de todos los contratos con terceros. Dicha revisión, que se estimaba en dos semanas, ya lleva tres semanas sin fecha de finalización confirmada.

Dado que esta tarea está mapeada en Celoxis como un paso previo al hito de presentación de evidencia de auditoría, el retraso se detecta de inmediato y no la semana anterior a la auditoría. El gerente de proyecto de seguridad informa al CISO sobre la dependencia documentada, el impacto en el cronograma cuantificado y dos opciones: acelerar la revisión legal con recursos adicionales o aceptar formalmente que la evidencia A.5.20 se presentará de forma parcial y preparar un argumento de control compensatorio para el auditor.

Se trata de una decisión de gobernanza, no de gestión de proyectos. Pero solo puede tomarse en el momento oportuno, con la información adecuada, porque la dependencia se gestionó en lugar de darse por sentada.

Puertas de seguridad como puntos de control reales

Cuatro semanas antes de que se abra el período de auditoría, se activa el primer control de seguridad importante en Celoxis. Antes de que pueda proceder la fase de revisión de evidencias, el responsable de seguridad y el CISO deben aprobar formalmente la integridad del registro de evidencias, confirmando que cada control incluido en el alcance tiene un elemento de evidencia asociado, que cada elemento ha sido revisado por un aprobador designado y que no quedan deficiencias sin abordar o sin aceptar.

No se trata de una reunión seguida de un correo electrónico. En Celoxis, el proceso de aprobación se basa en un flujo de trabajo: el responsable de seguridad revisa y aprueba, luego el CISO revisa y aprueba, y el registro se marca con la fecha y hora y se conserva como parte del registro de auditoría del proyecto. Si alguno de los aprobadores detecta un control incompleto, el proceso no avanza y la tarea se devuelve al responsable con la deficiencia específica señalada.

Este es precisamente el tipo de control que requiere la evidencia lista para auditoría y el tipo de control que se omite cuando los programas de seguridad se administran en hojas de cálculo bajo la presión de los plazos de entrega.

Cómo finaliza el programa

En la semana 22, el programa llega a su fin. Los 93 controles del Anexo A se registran en el registro de evidencias de Celoxis, cada uno con su ubicación de almacenamiento, estado de revisión y registro del aprobador. Tres áreas de riesgo residual que la organización optó por aceptar en lugar de remediar se procesaron formalmente a través del flujo de trabajo de aceptación de riesgos de Celoxis, con la justificación documentada, el responsable del riesgo designado, la fecha de vencimiento y la aprobación de la junta directiva adjuntas al registro.

Durante las 22 semanas, el CISO ha tenido acceso en tiempo real al índice de finalización de controles, al cumplimiento de los SLA y a los riesgos pendientes en su panel de control de Celoxis. No ha habido informes manuales semanales que elaborar, ni reuniones de estado donde se pierde la mitad del tiempo intentando determinar la realidad, ni prisas de última hora para encontrar pruebas recopiladas pero archivadas correctamente.

Lo que ilustra este escenario

En este caso, la empresa de servicios financieros no tuvo éxito por tener mejores conocimientos de seguridad o un equipo más capacitado que las organizaciones que fracasan en su primera auditoría ISO 27001. Su éxito se debió a una ejecución estructurada, ya que la brecha entre los requisitos de gobernanza y la evidencia entregada se superó mediante una gestión de proyectos disciplinada, respaldada por una plataforma que integró los flujos de trabajo de riesgo, dependencia, evidencia y aprobación en el proceso normal de entrega del proyecto, en lugar de convertirlos en cargas administrativas paralelas.

Esa es la contribución de Celoxis a la gestión de proyectos de ciberseguridad. No se trata de la experiencia en seguridad que aporta su equipo, sino de la estructura que garantiza que dicha experiencia genere resultados.

La gobernanza de la seguridad indica a las organizaciones qué se debe hacer. Las herramientas técnicas de seguridad detectan las deficiencias. Las plataformas GRC organizan los controles, los riesgos y las pruebas en un marco de cumplimiento. Ninguna de estas capas, por sí sola, garantiza que el trabajo correcto se realice, por las personas adecuadas, en el plazo previsto y con las pruebas que lo demuestren.

Ese es el problema de ejecución, y es donde fallan la mayoría de los programas de seguridad.

Celoxis proporciona a las PMO de seguridad la estructura necesaria para resolver este problema. Desde la visibilidad a nivel de cartera en múltiples iniciativas de seguridad simultáneas, hasta la programación de diagramas de Gantt con puntos de control de seguridad, pasando por flujos de trabajo RAID configurables, planificación de capacidad de recursos, puertas de aprobación con registros de auditoría y paneles ejecutivos en tiempo real, Celoxis está diseñado para conectar los requisitos de gobernanza de seguridad con los resultados de la entrega.

Los sistemas de seguridad detectan qué necesita reparación. Las plataformas GRC definen qué se requiere. Celoxis se asegura de que se haga.