• Bookmark

Marco GEIT trabajando, Parte 4: Esquema de los productos de trabajo

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

COBIT Focus | 17 de septiembre del 2018 English

No se puede llevar a cabo ninguna iniciativa de gobierno de TI empresarial (GEIT) sin una cuidadosa atención a los productos de trabajo y al plan del proyecto. Son los elementos que entregan resultados tangibles de GEIT. Este artículo, el cuarto de una serie de 6 partes que analiza la aplicación práctica de un marco GEIT, describe el trabajo que se requiere para crear los productos de trabajo definidos y ejecutar el plan del proyecto de manera eficiente, efectiva y exitosa.

Dentro de las 3 prácticas del APO13 proceso de gestión de seguridad, hay 6 productos de trabajo definidos. El plan del proyecto detalla cómo se llevarán a cabo y quién será responsable de ellos. En este punto, los productos de trabajo en sí deben definirse y los recursos deben ponerse en marcha para garantizar que se produzcan de manera adecuada y de manera oportuna (figura 1).


Figura 1 — APO13 Salidas del producto de trabajo

Producto de trabajo

Descripción

Política del sistema de gestión de seguridad de la información (SGSI)

Una política, norma o práctica operativa que formará parte del SGSI.

Declaración de alcance del SGSI

Parte de la estrategia de la SGSI y la documentación

Plan de tratamiento de riesgos de seguridad de la información.

Parte del proceso de evaluación de riesgos del SGSI basado en el perfil de riesgo

Casos de negocio de seguridad de la información.

Explicación formal del contexto y las actividades dentro del entorno SGSI que se verán afectadas por los cambios propuestos. El caso de negocio proporciona una justificación para perseguir el proyecto SGSI que apoya.

Solo se utiliza si es necesario para un proyecto o programa de seguridad de la información.

Informes de auditoría del SGSI

Parte de los informes de auditoría interna o informes mensuales de seguridad de la información, que también se integrarán en un sistema de informes y respuesta de incidentes de seguridad.

Recomendaciones para mejorar el
SGSI.

Parte del monitoreo y reporte normal del SGSI. Los asesores buscan o piden esto.


Para cada uno de los productos de trabajo definidos, el propietario de un proceso de negocio y cualquier otra parte relevante deben identificarse para definir y crear el producto. El siguiente paso es elaborar cada producto de trabajo e involucrar a las partes necesarias para crearlos.


Política de SGSI

La política de SGSI describe el contexto dentro del cual opera la seguridad de la información y señala qué estándares se necesitan para respaldarla. También puede especificar políticas relacionadas dentro de la empresa. La política proporciona la base que permite a la empresa asegurar que está protegiendo sus activos electrónicos y que se logran los niveles de seguridad necesarios.

La organización de la política de SGSI puede seguir los formatos establecidos, como Planear, Construir, Ejecutar, Monitorear o Planificar, Hacer, Verificar, Actuar, o la empresa puede usar un formato desarrollado internamente. El punto importante es identificar todos los recursos de seguridad relevantes que son necesarios para realizar la función de seguridad.

El principal recurso para la creación y aprobación de la política de SGSI es el director de seguridad de la información (CISO) y sus delegados. Los procesos existentes de creación, revisión y aprobación de políticas se pueden aprovechar para crear la política de SGSI. Los recursos adicionales pueden incluir el director de información (CIO), el jefe de administración de TI y los gerentes de seguridad de la información.


Declaración del alcance del SGSI

La declaración de alcance SGSI define qué servicios existen dentro del sistema de seguridad y los recursos relacionados. Estos incluyen activos de recursos físicos y humanos. La declaración de alcance del SGSI debe incluir todos los sistemas identificados como centrales para lograr la estrategia de seguridad de la empresa. Puede haber múltiples sistemas ISMS dentro de una empresa, por lo que es importante establecer claramente qué área se está atendiendo y qué servicios están incluidos. También es importante describir qué recursos no están incluidos en la declaración de alcance para mantener al equipo del proyecto enfocado.

La declaración de alcance SGSI es parte de la política SGSI y se generará como parte del proceso de creación de la política. Es importante asegurarse de que este producto de trabajo esté incluido en el cronograma del proyecto para la política de SGSI.


Plan de tratamiento de riesgos de seguridad de la información

Una evaluación de riesgos informa sobre varios aspectos de una estructura de gobierno. El SGSI es uno de esos elementos. Los factores de riesgo identificados se describen en términos de las vulnerabilidades a las que se enfrentan, los actores de amenazas a los que se enfrentan y la posible gravedad e impacto en caso de que esos factores de riesgo se materialicen en incidentes o eventos. Un plan de tratamiento de riesgos define si el riesgo debe aceptarse, evitarse, transferirse o mitigarse.

El recurso principal para la creación y aprobación del plan de tratamiento de riesgos es el CISO y sus delegados. La evaluación de riesgos existente y la creación de una respuesta al riesgo, procesos de revisión y aprobación se pueden aprovechar para crear el plan de tratamiento de riesgos. Los recursos adicionales pueden incluir el CIO, el jefe de administración de TI y los gerentes de seguridad de la información.


Casos Empresariales de Seguridad de la Información

El uso de casos de negocios es muy específico de la empresa. Los casos de negocios generalmente se usan para crear una razón para avanzar con un proyecto. Estos no son necesarios para los procesos que se han convertido en negocios como de costumbre, sino para establecer los motivos de la empresa para invertir en inversiones habilitadas para TI.

Los casos de negocios también pueden contribuir a la selección de estrategias de tratamiento de riesgo y pueden considerarse parte de la creación del plan de tratamiento de riesgo. El análisis de un proceso debe incluir una descripción general de los posibles agentes de amenaza y las vulnerabilidades que enfrentan los sistemas en consideración. Esta es la base para la selección de la estrategia de tratamiento de riesgos y estimula la reflexión sobre qué escenarios son más realistas y merecen actividades de preparación.


Informes de auditoría del SGSI

La auditoría interna debe ser informada de los nuevos productos de trabajo que se están creando. Esto proporcionará a los auditores expectativas más claras con respecto a lo que está disponible para respaldar el entorno de control interno y les dará la oportunidad de hacer sugerencias para iniciativas de mejora continua. Hay otro beneficio de trabajar con la auditoría interna desde el principio en la creación o modificación de prácticas de administración: cualquier tipo de panel de control o informes de rendimiento que se generan pueden diseñarse teniendo en cuenta las necesidades de la auditoría interna. Esto contribuye a un lenguaje común y entendimiento común internamente.

Cuando se crean en colaboración, los informes de auditoría son supervisados por el CISO, pero muchos otros recursos pueden participar en el trabajo detallado. Estos incluyen: propietarios de procesos de negocios, la oficina de administración de proyectos, el CIO, arquitectura empresarial, desarrollo, operaciones de TI, administración de sistemas, servicios, seguridad de la información, continuidad de negocios y gerentes de privacidad.


Recomendaciones para mejorar el SGSI

Las mejoras al SGSI pueden venir de muchas direcciones. Los recursos que llevan este conocimiento incluyen los mismos roles detallados en la creación de los informes de auditoría. Mecánicamente, los objetivos y métricas del proceso construyen informes y rutas de monitoreo en este producto de trabajo. Aquí es donde se encontrarán oportunidades de mejora. Los indicadores adelantados y rezagados o los indicadores de riesgo clave (KRI, por sus siglas en inglés) pueden proporcionar información anticipada sobre los cambios de SGSI. El uso de los informes de monitoreo para identificar dichas oportunidades también proporciona la información necesaria para crear nuevos casos de negocios para justificar la necesidad de cambio y ayudar en el proceso de preparación para el cambio.

Con todos los productos de trabajo contabilizados y establecidos, el SGSI está listo para funcionar. El proceso de creación de productos de trabajo garantiza la alineación entre los productos de trabajo y su proceso relacionado y los objetivos comerciales.


Confirmando los resultados

La próxima entrega de esta serie analizará cómo confirmar que los componentes necesarios del proceso APO13 Gestión de seguridad se crearon e implementaron con éxito. Esto se convertirá en la base para las operaciones y el desarrollo de métricas posteriores y el informe de rendimiento.


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.