Marco GEIT trabajando, Parte 5: Confirmando los resultados

Llega un momento en cualquier iniciativa a largo plazo cuando se identificaron los problemas, se desarrollaron los planes de mitigación, se definieron los productos de trabajo apropiados y se implementaron dichos productos y planes. Ahí es donde se encuentra el proceso descrito en esta serie de artículos. En la última entrega, el APO13 proceso de gestión de seguridad se implementó por completo y está listo para funcionar como siempre. A menudo es en esta etapa de un proyecto que los involucrados se felicitan, consideran que es un trabajo bien hecho y pasan a la siguiente iniciativa. Pero eso sería dejar el proyecto incompleto. A pesar de todos los esfuerzos, las cosas no siempre salen según lo planeado. Por lo tanto, el paso final, discutido en este artículo, es verificar que el proceso esté operando de manera efectiva, como lo demuestra el cumplimiento de los objetivos y métricas del proceso.

Los objetivos y métricas del proceso se encuentran en la parte frontal de cada proceso en COBIT 5: Procesos Catalizadores . No se les presenta un número de figura, pero, sin embargo, aparecen con cada proceso. Los objetivos y métricas del proceso para APO13 Gestión de seguridad se muestran en la figura 1.

Figura 1: APO13 - Objetivos y métricas del proceso

Cada objetivo tiene una serie de métricas relacionadas que especifican artefactos que se pueden evidenciar. Confirmar cada uno de los medios genera cada uno de estos artefactos y luego comparar estos resultados reales con el diseño previsto. La confirmación de los resultados se realiza comprobando la existencia y la efectividad operativa de cada objetivo del proceso. El personal que realiza los ejercicios de confirmación debe incluir la oficina de gestión del proyecto y, posiblemente, el personal de auditoría interna con las calificaciones y la experiencia laboral adecuadas.

Proceso de confirmación de objetivos

Cada proceso tiene una serie de objetivos y métricas relacionadas que se utilizan para determinar y medir si el proceso se está realizando y en qué medida. La medición del rendimiento de un proceso se habilitará mejor, o se facilitará, mediante la incorporación de estas métricas cuando los procesos se diseñan inicialmente. Cuando los diseñadores, o arquitectos, de la estructura de gobierno incorporen estos objetivos y métricas en el diseño, la medición del rendimiento que se realiza más adelante se facilitará y facilitará el seguimiento y los resultados serán más significativos. La medición del desempeño será realizada por los dueños del proceso y auditoría interna. Los resultados obtenidos de la medición interna se utilizan para refinar la mejora del proceso y para respaldar las afirmaciones de la administración con respecto a la efectividad del control interno.

1. Confirmar que existe un sistema que considera y aborda efectivamente los requisitos de seguridad de la información de la empresa.
   • Métrica—número de roles clave de seguridad claramente definidos
     Al principio del proyecto, se elaboraron cuadros (RACI; responsables, accountable, consultados e informados y los roles descritos para cada práctica se asignaron a la estructura organizativa, o al menos se confirmó que ya existían. Este es el primer lugar para determinar y confirmar que los roles de seguridad apropiados existen y están operativos. La política del sistema de gestión de seguridad de la información (SGSI) también debe estipular que el personal de seguridad esté calificado y mantenga su conocimiento.
     Obtenga diagramas de organización que muestren los roles de seguridad y los nombres de los empleados actuales que ocupan esos roles. Solicite de recursos humanos (HR) evidencia que existen requisitos de conocimiento que representan habilidades técnicas mínimamente aceptables para cada función. Los planes de capacitación para cada rol se considerarían como un nivel más alto de capacidad y se evaluarían favorablemente.
   • Métrica—número de incidentes relacionados con la seguridad
     Tan pronto como estén disponibles, solicite a un administrador de servicios que proporcione copias de los registros de incidentes de servicio recientes. Asegúrese de que los incidentes se registren de manera oportuna, que el problema se describa adecuadamente y que los controles relacionados estén detallados y tengan planes de resolución adjuntos. Cada incidente debe tener un propietario que pueda proporcionar recursos y el estado de los incidentes de su propiedad.
2. Confirmar que se ha establecido, aceptado y comunicado un plan de seguridad en toda la empresa.
   • Métrica—nivel de satisfacción de las partes interesadas con el plan de seguridad en toda la empresa
     El proceso de resolución de incidentes debe tener una función de satisfacción del cliente. Además, las estadísticas de resolución de incidentes se deben informar en paneles periódicos que brinden transparencia a todas las partes interesadas.
     Los conceptos e informes de satisfacción del cliente deben ser revisados y aprobados por el director de seguridad de la información (CISO). Los informes periódicos probablemente provienen de un administrador de servicios. Obtenga ejemplos de encuestas recientes o encuestas que demuestren la medición de la satisfacción de resolución de incidentes.
   • Métrica—número de soluciones de seguridad que se desvían del plan
     Una solución de seguridad adecuada puede desviarse del plan de seguridad, pero cuando eso sucede, debe haber suficiente documentación que proporcione un caso de uso comercial razonable y razón de ser. Las desviaciones deben ocurrir con poca frecuencia y deben ser revisadas y aprobadas por la parte relevante, CISO, el director de información (CIO) u otro miembro de la empresa C-suite o sus delegados.
     Solicite todos los casos de desviaciones del plan y confirme la revisión y aprobación apropiadas. Las desviaciones del plan pueden ser proporcionadas por la parte que aprueba o por los administradores de seguridad de información o servicios.
   • Métrica—número de soluciones de seguridad que se desvían de la arquitectura empresarial
     Al igual que con las desviaciones del plan, debe haber pocas desviaciones de la arquitectura. Cualquier cosa que provoque desviaciones en la arquitectura debe contemplarse cuidadosamente, ya que los efectos en cadena de la arquitectura empresarial pueden provocar consecuencias no deseadas que generen un aumento importante en el riesgo.
     Solicite todas las instancias de desviaciones de arquitectura y confirme la revisión y aprobación apropiadas. Las desviaciones de la arquitectura pueden ser proporcionadas por la parte que aprueba o por los gerentes de seguridad de la información o servicio.
3. Confirmar que las soluciones de seguridad de la información se implementan y operan de manera consistente en toda la empresa
   • Métrica—número de servicios con alineación confirmada al plan de seguridad
     La alineación con el plan de seguridad debe estar bien documentada en el proceso de implementación de un servicio. El ciclo de vida de entrega de software de una empresa (SDLC) proporciona los mecanismos y estándares de documentación para esta evidencia. Además, las partes interesadas clave de un servicio mantendrán la documentación actualizada relacionada con la alineación del plan de seguridad.
     Solicite pruebas de los servicios a auditoría interna, a los propietarios de los procesos, a los gerentes de servicios y a los gerentes de seguridad de la información. Los catálogos de servicio, o inventarios, deben describir completamente la alineación del plan de seguridad.
   • Métrica—número de incidentes de seguridad causados por la no adherencia al plan de seguridad
     El sistema de gestión de incidentes aplicará el análisis de causa raíz (RCA) a la investigación de incidentes y la determinación de la resolución. La causa de un incidente debe incluir si el incumplimiento es un factor contribuyente.
     Solicite registros recientes de cualquier incidente en el que RCA haya indicado incumplimiento. Los administradores de seguridad de la información pueden proporcionar registros de incidentes.

La evaluación general del cumplimiento de los objetivos del proceso debe ser evaluada en su totalidad. Toda la evidencia recolectada debe tomarse como un todo y debe derivarse una opinión basada en una visión comprensiva.

Conclusión

La próxima entrega de esta serie discutirá la recopilación de evidencia de las prácticas operativas y el uso de los resultados para medir el desempeño del sistema de gobierno e identificar áreas para mejoras potenciales.

Peter C. Tessin, CISA, CRISC, CISM, CGEIT

Es gerente senior de Discover Financial Services. Lidera el grupo de gobierno dentro del riesgo de tecnología empresarial (BT). En esta función, él es responsable de garantizar que la política, los estándares y los procedimientos se alineen con los objetivos corporativos. Se desempeña como parte interna responsable de la gestión de exámenes regulatorios y es el enlace interno con la gestión de riesgos corporativos. Antes de este cargo, Tessin fue gerente de investigación técnica en ISACA, donde fue gerente de proyectos para COBIT 5 y dirigió el desarrollo de otras publicaciones relacionadas con COBIT 5, informes y artículos. Tessin también tuvo un papel central en el diseño de COBIT Online, el sitio web de ISACA que ofrece un acceso conveniente a la familia de productos COBIT 5 e incluye herramientas digitales interactivas para ayudar en el uso de COBIT. Antes de unirse a ISACA, Tessin era gerente senior de una firma de auditoría interna, donde dirigía los compromisos con los clientes y era responsable de los equipos de auditoría financiera y de TI. Anteriormente, trabajó en varias funciones de la industria, como personal contable, desarrollador de aplicaciones, consultor y consultor de sistemas contables, analista de negocios, gerente de proyectos y auditor. Ha trabajado en muchos países fuera de su país natal, incluidos Australia, Canadá, Francia, Alemania, Italia, Jordania, México y el Reino Unido.