En muchos departamentos de TI, las semanas previas a una auditoría siguen el mismo ritual. Varias personas dejan de lado su trabajo habitual y reúnen pruebas. ¿Quién aprobó este cambio? ¿Por qué este usuario tenía derechos de administrador? ¿Cuándo cambió la configuración del firewall y quién la cambió? Las respuestas existen, pero están dispersas en correos electrónicos, chats, exportaciones de diferentes herramientas y en la memoria de las personas, algunas de las cuales ya han dejado la empresa.
Al mismo tiempo, la presión para proporcionar pruebas sigue aumentando. La regulación de ciberseguridad, como NIS2 y la legislación nacional que la implementa, generalmente pone énfasis en la gestión de riesgos, la responsabilidad de la gestión y la capacidad de demostrar que las medidas de seguridad realmente funcionan. Las obligaciones específicas difieren según el tipo de organización y se evalúan mejor con especialistas legales o de cumplimiento. Sin embargo, el hilo conductor es claro: hacer las cosas bien no es suficiente. Debe poder probarlo.
Por qué reunir pruebas después del hecho falla
El problema rara vez es que una organización no tenga procesos. El problema es que esos procesos no dejan un rastro por sí mismos.
- Las aprobaciones ocurren fuera del sistema. El consentimiento para un tiempo de inactividad llega por correo electrónico, el cambio se realiza en otro lugar y el vínculo entre ellos solo existe en la cabeza del gestor de cambios.
- El historial se sobrescribe. La herramienta muestra el estado actual, pero no cómo era antes.
- Las acciones automatizadas son invisibles. Los trabajos programados cambian los datos, pero nadie sabe exactamente cuándo ni qué hicieron.
- Las responsabilidades viven en papel. Una matriz RACI se encuentra en un documento y nadie verifica si coincide con los permisos reales.
El resultado es una auditoría que se ejecuta como un proyecto, en lugar de una auditoría como una revisión rutinaria de los registros.
Cómo abordar la probabilidad
La verdadera preparación para la auditoría es un subproducto del trabajo diario. Si cada acción ocurre en un sistema que la registra, la prueba existe en el momento en que suceden las cosas. Algunos principios:
- registrar no solo "quién y cuándo" sino también "qué cambió exactamente", es decir, el estado antes y después,
- auditar lo que hacen las máquinas, no solo lo que hacen las personas,
- mantener registros durante el tiempo suficiente,
- describir responsabilidades de una manera que pueda compararse con los permisos reales.
Cómo lo maneja Eywo Stratum
Eywo Stratum mantiene un registro de auditoría de todas las acciones, retenido durante cinco años. Para los cambios de configuración, registra el estado antes y después, para que pueda ver no solo que algo cambió sino exactamente qué. Las acciones del programador, los trabajos automatizados que se ejecutan sin intervención humana, también se auditan.
Los elementos de la CMDB tienen su propia historial de versiones. Para cada cambio, puede ver quién lo hizo, cuándo, qué cambió y de dónde vino: la API de descubrimiento, una importación, una edición manual o la sincronización con una CMDB primaria.
Las aprobaciones ocurren dentro del sistema. Los tiempos de inactividad en cambios, solicitudes y otros elementos que necesitan una decisión se unen en una sola cola de "Para aprobación". Una regla define quién es el propietario y un rechazo siempre viene con una razón. El registro de quién acordó qué se crea junto con el cambio.
Las responsabilidades se describen en una matriz RACI y Eywo Stratum verifica que sea consistente con los permisos. Si alguien está listado como responsable pero no tiene un rol que le permita aprobar o realizar la tarea, se muestra. Los roles están definidos (todo, cliente, equipo, elemento), por lo que está claro no solo qué puede hacer alguien sino también sobre qué.
Conclusión
Una auditoría no debe ser un proyecto. Cuando el registro de auditoría se crea automáticamente, las aprobaciones viven en el sistema y las responsabilidades están vinculadas a los permisos, la respuesta a una pregunta de un auditor está a unos pocos clics de distancia. El equipo sigue trabajando y la gerencia puede estar segura de que se puede demostrar la responsabilidad.
El registro de auditoría, el historial de la CMDB y la matriz RACI están incluidos en la edición Estándar.
Usted puede obtener más información en www.eywostratum.com. En caso de alguna duda, no dude en ponerse en contacto con nosotros a través de support@eywostratum.com.
Para obtener más información sobre cómo podemos ayudarlo a alcanzar sus objetivos, por favor consulte nuestra ficha técnica en www.eywostratum.com/datasheet.
Nuestros expertos están disponibles para responder a sus preguntas y ayudarlo a encontrar la solución adecuada para su empresa.
No dude en contactarnos para obtener más información o para programar una demostración de nuestro producto.
Agradecemos su interés en Eywo Stratum.
Para más información, por favor visite nuestro sitio web o contacte con nuestro equipo de ventas en sales@eywostratum.com.
También puede abrir un ticket de soporte en support@eywostratum.com o llamarnos al +1 123 456 789.
Nuestro horario de atención es de lunes a viernes de 9:00 a 18:00 horas.
Esperamos con interés escuchar de usted.
Atentamente, Nombre
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.