Banco de Medio Oriente mejora la seguridad de la … · • Mejorar la gestión de costos...

Volumen 1, enero de 2014

En este número:

Convocatoria para

presentación de artículos

¿Cómo utiliza COBIT®

en su empresa actualmente?

Aceptamos artículos en los que describa su experiencia con

este marco. Plazos para la presentación de una

copia para el volumen 2, 2014:

10 de marzo de 2014

Envíe artículos para revisión a:

[email protected]

Estudio de casos

Visite las páginas COBIT Recognition

(Reconocimiento de COBIT) y Case Studies (Estudio de Casos) para obtener más

información sobre los estudios de casos relacionados con

COBIT 5 y COBIT 4.1.

• Banco de Medio Oriente mejora la seguridad de la información • Gestión de seguridad de la información en HDFC Bank: Contribución de los siete facilitadores /

habilitadores • Soportando el cumplimiento de PCI DSS 3.0 con COBIT 5 • Desarrollo de un marco de gobierno para la organización de soporte mundial en GlaxoSmithKline,

utilizando COBIT

Banco de Medio Oriente mejora la seguridad de la información Por Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2 Como consecuencia de una iniciativa por mejorar la seguridad de la información con la ayuda de COBIT, una entidad bancaria de Medio Oriente obtuvo varios beneficios, entre ellos: • Mejorar la integración de la seguridad de la información dentro de la organización. • Comunicar decisiones vinculadas al riesgo y crear conciencia sobre los riesgos. • Mejorar la prevención, detección y recuperación. • Reducir (el impacto de) los incidentes vinculados a la seguridad de la información. • Aumentar el soporte relacionado con la innovación y la competitividad. • Mejorar la gestión de costos relacionados con la función de seguridad de la

información. • Adquirir un entendimiento más profundo sobre la seguridad de la información.

Obtener la aprobación de la alta dirección es una queja común entre los profesionales de seguridad de la información. Sin embargo, en un banco de Medio Oriente, más específicamente en Kuwait, el gerente de seguridad de la información no tuvo ese problema a la hora de implementar COBIT para definir los principios de seguridad de la información de la empresa porque la alta dirección del banco ya tenía pleno conocimiento del marco aceptado por la industria. En consecuencia, el informe de evaluación fue completado rápidamente, aceptado velozmente y agradecido enormemente.

La organización utiliza varios estándares y marcos, incluida la norma ISO 27001, el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (Payment Card Industry Data Security Standards, PCI DSS) y la Biblioteca de Infraestructura de Tecnología de la Información (IT Infrastructure Library, ITIL), y deseaba alinear sus procesos y principios departamentales con un marco común, ampliamente flexible y adaptable, que tuviera controles y procesos en común con otros marcos de la industria. La organización halló todo esto en COBIT®, que en su versión más actualizada —COBIT® 5— proporciona un detallado cruce con otros marcos, entre ellos, las normas de la Organización Internacional para la Estandarización (International Organization for Standardization, ISO), el Marco de Arquitectura del

mailto:[email protected]

http://www.isaca.org/COBIT/Pages/Recognition.aspx

http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Case-Studies.aspx

http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Case-Studies.aspx

Open Group (The Open Group Architecture Framework, TOGAF) y el Cuerpo de Conocimientos de Gestión de Proyectos (Project Management Body of Knowledge, PMBOK).

Ningún otro marco proporciona un cruce tan detallado con diversos estándares aceptados en la industria. El banco ha utilizado COBIT 5 y COBIT® 5 para la Seguridad de la Información en una amplia variedad de proyectos: • Se empleó el Kit de herramientas de COBIT 5 para identificar el enunciado de aplicabilidad (statement of applicability,

SOA) de cada dominio, junto con los 37 procesos y los 210 enunciados de práctica correspondientes. • Los principios de COBIT 5 han sido cruzados con los procesos actuales del departamento de seguridad de la información

con el objeto de identificar toda brecha posible (Consulte la columna Evidencia de Soporte en la figura 1 para conocer los resultados del cruce).

• Se abordaron todas las brechas identificadas durante la evaluación teniendo en cuenta las guías recomendadas para cada enunciado de práctica.

Principios de seguridad de la información Como se describió en COBIT 5 para la Seguridad de la Información, los principios de seguridad de la información comunican las reglas de la empresa que soportan los objetivos de gobierno y los valores empresariales, según la definición del Consejo y la dirección ejecutiva. Estos principios deben: • Ser limitados en cuanto a su número. • Estar expresados en un lenguaje sencillo y declarar, de la manera más clara posible, los valores fundamentales de la

empresa.

Estos principios (figura 1) son genéricos y se aplican a todas las empresas, y se pueden utilizar como base para el desarrollo de principios de seguridad de la información exclusivos de la empresa.

Figura 1: Principios de seguridad de la información del banco basados en COBIT 5

Principio Objetivo Descripción Estado Evidencia de Soporte

1. Soporte al negocio.

Concentrarse en el negocio.

Garantizar que la seguridad de la información esté integrada a las actividades esenciales del negocio.

Las personas que integran la comunidad de seguridad de la información deben entablar relaciones con líderes de negocio y demostrar el modo en que la seguridad de la información puede complementar negocios claves y procesos de gestión de riesgos. Ellas deberían adoptar un enfoque de consultoría respecto de la seguridad de la información brindando su respaldo a los objetivos del negocio por medio de la asignación de recursos, programas y proyectos. Se debe proporcionar consultoría de alto nivel, enfocada a la empresa, para proteger la información y ayudar a gestionar el riesgo de la información tanto ahora como en el futuro.

Implementado Estrategia de seguridad de la información

Ofrecer calidad y valor a las partes interesadas.

Garantizar que la seguridad de la información ofrezca valor y satisfaga los requerimientos del negocio.

Las partes interesadas internas y externas deben comprometerse a sostener una comunicación periódica de modo que se sigan cumpliendo sus requerimientos cambiantes de seguridad de la información. Promover el valor de la seguridad de la información (tanto financiera como no financiera) permite adquirir apoyo para la toma de decisiones que, a su vez, puede colaborar con el éxito de la visión para la seguridad de la información.

Implementado Estrategia de seguridad de la información

Volumen 1, enero de 2014 Página 2

http://www.isaca.org/COBIT/Pages/Information-Security-Product-Page.aspx

http://www.isaca.org/COBIT/Pages/Product-Family.aspx

Figura 1: Principios de seguridad de la información del banco basados en COBIT 5

Principio Objetivo Descripción Estado Evidencia de Soporte

Cumplir los requerimientos legales y regulatorios relevantes.

Garantizar que se cumplan las obligaciones legales, que se gestionen las expectativas de las partes interesadas, y que se eviten sanciones civiles o penales.

Se deben identificar las obligaciones de cumplimiento, se las debe traducir en requerimientos específicos de seguridad de la información y comunicar a las personas que corresponda. Las sanciones asociadas al incumplimiento deben ser claramente comprendidas. Los controles deben ser monitoreados, analizados y actualizados de modo que cumplan con los requerimientos legales y regulatorios nuevos o actualizados.

Implementado Estado de cumplimiento de PCI, estado de cumplimiento de ISO 27001

Proporcionar datos exactos y oportunos sobre el desempeño de la seguridad de la información.

Brindar apoyo a los requerimientos del negocio y gestionar el riesgo de la información.

Los requerimientos para la entrega de datos sobre el desempeño de la seguridad de la información deben estar claramente definidos y sustentados con las métricas más relevantes y adecuadas (por ejemplo, cumplimiento, incidentes, estado de control y costos) y alineados con los objetivos del negocio. La información debe obtenerse de manera periódica, uniforme y rigurosa para que continúe siendo precisa y los resultados puedan presentarse para cumplir los objetivos de las partes interesadas que correspondan.

Implementado Informe mensual de gestión de la seguridad de la información

Evaluar las amenazas actuales y futuras hacia la información.

Analizar y evaluar las amenazas emergentes de seguridad de la información de modo que se pueda adoptar acciones oportunas e informadas para mitigar el riesgo.

Las tendencias más importantes y las amenazas específicas a la seguridad de la información se deben categorizar en un marco integral estándar que abarque un amplio espectro de temas como, por ejemplo, aspectos políticos, legales, económicos, socioculturales y técnicos. Las personas deben compartir y profundizar sus conocimientos sobre las amenazas venideras a fin de abordar proactivamente sus causas, en lugar de sus síntomas.

Implementado Revisión y pruebas periódicas a la seguridad.

Promover la mejora continua en seguridad de la información.

Reducir los costos, mejorar la eficacia y la eficiencia, y promover una cultura de mejora continua en seguridad de la información.

Los modelos de negocio organizacionales en constante cambio, junto con las amenazas en evolución, exigen la adaptación de técnicas de seguridad de la información y la mejora continua de su nivel de eficacia. Se debe mantener el conocimiento sobre las técnicas de seguridad de la información más recientes aprendiendo de los incidentes y vinculándose con organizaciones de investigación independientes.

Implementado Indicadores clave de desempeño; informes mensuales y anuales de gestión


2. Defender el negocio.

Adoptar un enfoque basado en el riesgo.

Garantizar que el riesgo sea tratado de una manera consistente y eficaz.

Se deben examinar las opciones para abordar el riesgo vinculado con la información de modo que se puedan tomar decisiones fundamentadas y documentadas sobre el tratamiento del riesgo. El tratamiento del riesgo implica elegir una o más opciones, que habitualmente incluyen: • Aceptar el riesgo (un integrante de la dirección

debe aprobar que ha aceptado el riesgo y que no se requiere ninguna otra acción).

• Evitar el riesgo (p. ej., decidiendo que no se perseguirá una iniciativa en particular).

• Transferir el riesgo (p. ej.; tercerizando o tomando un seguro).

• Mitigar el riesgo (en general, si se aplican las medidas adecuadas de seguridad de la información, p. ej. controles de acceso, monitoreo de red y gestión de incidentes).

Implementado Sistema de gestión de seguridad de la información (information security management system, ISMS) y evaluación de riesgos de cumplimiento de PCI.

Proteger información clasificada.

Evitar la divulgación de información clasificada (p. ej., confidencial o sensible) a personas no autorizadas.

La información se debe identificar y, a continuación, clasificar de acuerdo con su nivel de confidencialidad (p. ej., secreta, restringida, interna, pública). La información confidencial se debe proteger del mismo modo en todas las etapas de su ciclo de vida —a partir de la creación y hasta su destrucción— empleando los controles que correspondan, como la encriptación y las restricciones de acceso.

Implementado Políticas y estándares de seguridad de la información

Concentrarse en aplicaciones críticas del negocio.

Priorizar la escasez de recursos de seguridad de la información protegiendo las aplicaciones de negocio sobre las que un incidente de seguridad de la información podría tener el mayor impacto en la empresa.

Comprender el impacto en la empresa que ocasionaría una falta de integridad o disponibilidad de información importante manipulada por las aplicaciones de negocio (procesada, almacenada o transmitida) ayudará a establecer el nivel de criticidad. Posteriormente, pueden determinarse los requerimientos de recursos de seguridad de la información y puede establecerse la prioridad de proteger las aplicaciones que son más críticas para el éxito de la organización.

Implementado Políticas y estándares de seguridad de la información


Desarrollar sistemas seguros.

Desarrollar sistemas de calidad y económicos en los cuales se pueda confiar (es decir, que sean consistentemente robustos, precisos y confiables).

La seguridad de la información debe ser integral para las fases de alcance, diseño, desarrollo y prueba del ciclo de vida de desarrollo de sistemas (system development life cycle, SDLC). Las buenas prácticas de seguridad de la información (p. ej., la prueba rigurosa de debilidades en cuanto a la seguridad de la información; la revisión entre pares; y la capacidad de lidiar con errores, excepciones y condiciones de emergencia) deben tener un rol fundamental en todas las etapas del proceso de desarrollo.

Implementado Estándares de seguridad de la información

3. Promover un comportamiento responsable respecto de la seguridad de la información.

Actuar de una manera profesional y ética.

Asegurarse de que las actividades relacionadas con la seguridad de la información se realicen de manera confiable, responsable y eficiente.

La seguridad de la información se basa marcadamente en la capacidad de los profesionales de una industria para desempeñar sus funciones con responsabilidad y con un claro entendimiento del modo en que su integridad impactará directamente sobre la información que se les encarga proteger. Los profesionales de seguridad de la información deben comprometerse con un alto nivel de calidad en su trabajo y demostrar, a la vez, un comportamiento uniforme y ético y respeto por las necesidades de la empresa, otras personas y la información confidencial (a menudo, personal).

Implementado Verificaciones de antecedentes

Promover una cultura positiva respecto de la seguridad de la información.

Ejercer una influencia positiva respecto de la seguridad de la información sobre el comportamiento de los usuarios finales, reducir la probabilidad de que ocurran incidentes de seguridad de la información y limitar su posible impacto en la empresa.

Se debe hacer énfasis en lograr que la seguridad de la información sea una pieza clave de la empresa y que los usuarios se concienticen cada vez más sobre la seguridad de la información, y en garantizar que estos tengan las destrezas necesarias para proteger la información clasificada o crítica y los sistemas. Las personas deben reconocer el riesgo que corre la información que tienen en su poder y deben estar facultados para tomar las medidas que sean necesarias para protegerla.

Implementado Reuniones del comité de gobierno de seguridad de la información (information security governance committee, ISGC).

Beneficios de la implementación de COBIT 5 El banco alcanzó sus objetivos en poco tiempo, solamente tres meses, y logró mejorar una gran cantidad de procesos, entre los que cabe mencionar: • Garantizar el establecimiento y el mantenimiento del marco de gobierno. • Garantizar la entrega de beneficios. • Garantizar la optimización del riesgo. • Garantizar la optimización de recursos. • Garantizar la transparencia de las partes interesadas. • Administrar el marco de gestión de TI. • Gestionar la estrategia. • Gestionar la arquitectura de la empresa. • Gestionar la innovación. • Gestionar la definición de requerimientos. • Gestionar los activos.


• Gestionar la continuidad.

Conclusión El banco planea seguir usando este marco de evaluación anualmente y con la frecuencia que otros proyectos exijan. La versión más reciente de COBIT es fácil de comprender e implementar, especialmente el kit de herramientas, que proporciona toda la información necesaria para aplicar COBIT en toda la organización.

Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2 Cuenta con más de 14 años de experiencia en sectores multifuncionales de seguridad y riesgo de la información. Se desempeña como gerente de seguridad de la información en un banco regional líder de Medio Oriente. Anteriormente, trabajó en Ernst & Young y KPMG. Es un buen conocedor de los marcos y los estándares de TI, como COBIT, ISO 27001, PCI DSS, TOGAF e ITIL.

Gestión de seguridad de la información en HDFC Bank: Contribución de los siete facilitadores / habilitadores Por Vishal Salvi, CISM y Avinash W. Kadam, CISA, CISM, CGEIT, CRISC, CBCP, CISSP, CSSLP HDFC Bank fue incorporado en agosto de 1994 y posee una red nacional de 3062 sucursales y 10 743 cajeros automáticos (automated teller machines, ATM) distribuidos en 1568 ciudades y poblaciones de India. HDFC Bank opera en un entorno altamente automatizado en términos de sistemas de TI y comunicación. Todas las sucursales de la entidad bancaria cuentan con conectividad en línea, que permite a sus clientes operar con transferencias de fondos sin demoras. También se proporciona acceso a múltiples sucursales a clientes minoristas a través de la red de sucursales y los ATM. El banco ha priorizado su compromiso con la tecnología e Internet como uno de sus objetivos más importantes y ha hecho avances significativos en habilitar su core de negocio en la web. En cada uno de sus negocios, el banco ha logrado aprovechar su posición en el mercado, su experiencia y su tecnología a fin de crear una ventaja competitiva y obtener participación en el mercado.

Uso de COBIT Como uno de los primeros en adoptar COBIT® 4.1, el HDFC Bank comenzó hace ya casi 6 años el recorrido de gobierno de TI cuando COBIT® 4.1 apenas había salido al mercado. Así fue como la entidad bancaria adoptó casi la totalidad de los 34 procesos de TI definidos en COBIT 4.1. Luego de la introducción de COBIT® 5 en abril de 2012, HDFC Bank se tomó un tiempo para considerar una migración. Debido a que la experiencia del banco con la implementación de COBIT 4.1 ha sido muy beneficiosa, no migrará inmediatamente a COBIT 5. Sin embargo, HDFC Bank adoptó de manera intuitiva los siete facilitadores /habilitadores introducidos por COBIT 5 incluso antes de que estos adquirieran notoriedad pública en COBIT 5. COBIT 5 describe siete facilitadores / habilitadores como factores que, de manera individual y colectiva, influyen en que algo funcione; en este caso, el gobierno y la gestión de TI de la empresa (governance and management of enterprise IT, GEIT): 1. Los principios, las políticas y los marcos son el vehículo para convertir el comportamiento deseado en orientación

práctica para la gestión diaria. 2. Los procesos describen un conjunto organizado de prácticas y actividades para lograr ciertos objetivos y producir un

conjunto de resultados que sustenten el logro de las metas generales relacionadas con TI. 3. Las estructuras organizacionales son las entidades claves de toma de decisiones en una empresa. 4. La cultura, la ética y el comportamiento de individuos y de la empresa son, a menudo, subestimados como un factor

de éxito en las actividades de gobierno y gestión. 5. La información es generalizada en cualquier organización e incluye toda la información producida y utilizada por la

empresa. Se requiere la información para mantener a la organización en funcionamiento y bien gobernada, pero a nivel operativo, la información es con frecuencia el producto clave de la misma empresa.

6. Los servicios, la infraestructura y las aplicaciones incluyen la infraestructura, la tecnología y las aplicaciones que brindan a la empresa servicios y procesamientos de TI.

7. Las personas, habilidades y competencias están vinculadas a las personas y son requeridas para la finalización exitosa de todas las actividades y para tomar decisiones correctas y aplicar medidas correctivas.

Estructuras organizacionales Las estructuras organizacionales son las entidades clave de toma de decisiones en una empresa. La seguridad de la información en HDFC Bank está impulsada por su grupo de seguridad de la información (information

Figura 2: Roles y responsabilidades del ISG Tareas de seguridad de la

información Seguridad

de la información

TI Operaciones Negocio Jurídico Auditoría RR. HH. Dirigentes Funcionales

Gobierno A/R C C C C R C Políticas, procesos y estándares A/R C C I C C C

Estrategia A/R C C C I C I Evaluación de riesgos - definición A/R I I I C I

Evaluación de riesgo - ejecución C R R R C A

Gestión de seguridad de la información R/C R R R R R R A/R

Arquitectura de seguridad A/R R C Tecnología de la seguridad C A/R C Ingeniería de la seguridad C A/R C Desarrollo seguro C A/R C Operaciones y entrega de servicios A R R C

Gestión de proyectos A/R R I I C Auditoría, revisión y monitoreo R/C R I I I A/R I Respuesta a incidentes A/R R R I C C I Entorno legal y normativo A/R I I I R R I Conocimiento, educación y capacitación A/R I I I I C R

Fuente: HDFC Bank. Reimpreso con autorización.

Figura 1: Marco de gobierno de HDFC Bank



security group, ISG). El grupo está liderado por el director general de seguridad de la información (chief information security officer, CISO), que reporta al director ejecutivo del banco. El ISG es principalmente responsable de identificar, evaluar y proponer la mitigación de cada riesgo relacionado con la seguridad de la información. Esta responsabilidad se lleva a cabo interactuando con diversos comités y partes interesadas y preparando planes, propuestas, políticas, procedimientos y guías. La implementación de estas directrices se asigna a los equipos de implementación de todo el banco. El marco de gobierno en HDFC Bank está impulsado por una gran cantidad de comités de alto nivel (figura 1). La importancia que se le da a la seguridad de la información es notoria puesto que una gran cantidad de comités de alto nivel han colocado a la seguridad de la información en sus agendas. La definición de responsabilidades para el ISG han sido bien definidas a través de una matriz RACI (figura 2). Uno de los puntos principales que se deben destacar es que, si bien la responsabilidad de la gestión de la seguridad de la información radica en el ISG, la rendición de cuentas recae marcadamente en los dirigentes funcionales. De igual modo, si bien es cierto que el ISG rinde cuentas por la definición de la evaluación de riesgos, los dirigentes funcionales lo son de la ejecución de esta evaluación. Esta división de responsabilidades y rendición de cuentas determina la propiedad de la mitigación del riesgo y la gestión de seguridad de la información en los dirigentes funcionales. En la figura 3, se proporciona el marco general de gobierno para la implementación. Los 21 componentes se monitorean permanentemente hasta alcanzar un nivel de madurez. La asignación de trabajo a los integrantes del ISG se basa en estos controles.

Principios, políticas y marcos Los principios, las políticas y los marcos son el vehículo para convertir el comportamiento deseado en guía práctica para la gestión diaria. HDFC Bank ha diseñado un documento de una política integral de unas 100 páginas. La versión actual es 3.x y se encuentra en proceso de revisión hasta diseñar la versión 4.0. Este documento abarca los 11 dominios de seguridad de la información, según se especifica en la norma ISO 27001 de una manera agnóstica considerando plataforma – y - tecnología, y está modelada sobre la Norma de Buenas Prácticas del Foro de Seguridad de la Información (Information Security Forum, ISF). Debido a que el banco emplea entre 30 y 40 tecnologías diferentes, se crean políticas más detalladas para cada tecnología. Se trata de políticas minuciosas específicas de las tecnologías para que el equipo técnico responsable de implementarlas las tenga a modo de referencia. Estas políticas se subdividen aún más en registros para cruzarlas con varios estándares/marcos rectores, por ejemplo, las normas

Figura 3: Gobierno para la implementación

Política, procesos, estándares Procedimientos, controles técnicos

21 componentes Seguridad de la aplicación, criptografía, monitoreo, gestión de incidentes, seguridad

bancaria en línea, gestión de software malicioso (malware), protección de datos, ciclo de vida de desarrollo de software seguro, planificación de continuidad del

negocio, privacidad, gestión de acceso y de identidad, gestión de riesgos...


ISO 27001, COBIT y las guías del Banco de Reservas de la India (Reserve Bank of India, RBI). Estos registros se introducen en una herramienta de gobierno, riesgo y cumplimiento (governance, risk and compliance, GRC) que proporciona el marco de control unificado (unified control framework, UCF) interno del banco. De esta manera, se logra identificar el nivel de cumplimiento adquirido de manera automática. La herramienta proporciona casi 40 fuentes autorizadas que ya se han cruzado a través del UCF. Por lo tanto, resulta fácil encontrar el cumplimiento con cualquier fuente. El equipo del ISG utiliza la metodología de Análisis por factores del riesgo de la información (Factored Analysis of Information Risk, FAIR) para calcular el riesgo probable mediante la captura de la frecuencia de eventos de amenazas y la frecuencia de eventos de pérdida, dando el peso adecuado a cada factor y la creación de una clasificación de riesgo para dar prioridad y tomar decisiones. El equipo del ISG también revisó la norma ISO 27005 y diseñó un enfoque sólido para la gestión de riesgos con la ayuda de estos estándares. Se ha creado una versión corta del documento de la política en una guía del usuario de 20 páginas sustentada por una lista de 10 reglas principales para la seguridad de la información. Hay una gran cantidad de proveedores que prestan servicio a HDFC Bank. La seguridad de la cadena de suministros queda garantizada por revisiones periódicas de terceros a los proveedores las cuales son llevadas a cabo por firmas de auditoría externa. HDFC Bank cuenta con las certificaciones ISO 27001 y BS 25999, planea obtener el certificado ISO 22301 y ha alcanzado el 92 % de cumplimiento de las guías RBI. En la actualidad, el ISG se centra en la creación de un sistema sólido de gestión de incidentes, proveer una protección adecuada de los datos, garantizar la implementación apropiada del BYOD - "trae tu propio dispositivo" (bring your own device) y detectar, contener y remover amenazas persistentes avanzadas oportunamente.

Procesos Los procesos describen un conjunto organizado de prácticas y actividades para lograr ciertos objetivos y producir un conjunto de resultados respaldando el logro de las metas generales relacionadas con TI. El ISG sigue un modelo de proceso de seguridad de la información basado en 21 componentes: 1. Seguridad de la aplicación 2. Criptografía 3. Monitoreo 4. Gestión de incidentes 5. Seguridad bancaria en línea 6. Gestión de software malicioso (malware) 7. Protección de datos 8. Ciclo de vida del desarrollo de software seguro 9. Gestión de proveedores (terceros) 10. Planificación de continuidad del negocio 11. Privacidad 12. Gestión de identidades y acceso 13. Gestión de riesgos 14. Seguridad física 15. Concientización 16. Gobierno 17. Política 18. Gestión del ciclo de vida de los activos 19. Rendición de cuentas y propiedad 20. Configuración del sistema 21. Seguridad de la red Se efectúa la planificación, diseño, implementación y monitoreo de la seguridad de la información para estos componentes individuales. Este enfoque hace que los equipos se mantengan

Figura 4: Cascada de metas de COBIT 5

Fuente: ISACA, COBIT 5, EE. UU., 2012


http://www.isaca.org/COBIT/Pages/default.aspx

centrados. Se desarrollan políticas, procedimientos, guías, estándares, tecnologías y herramientas para estos componentes. Este enfoque proporciona granularidad a la hora de gestionar cada área de enfoque y también conduce a una arquitectura de defensa en profundidad. Cada uno de los componentes contribuye con la creación de estándares y procedimientos de control que satisfacen los requerimientos de políticas de alto nivel. Este es un enfoque de abajo hacia arriba que permite mitigar las inquietudes de seguridad de nivel superior para procesos de negocio proporcionando seguridad adecuada para los activos que son utilizados por estos procesos. Actualmente, se está llevando a cabo la tarea de cruzar todos los procesos de negocio con los activos. Los procesos de negocio se están clasificando en función de la criticidad y el impacto que puedan tener en el negocio. Si un activo, por ejemplo un servidor, aloja múltiples procesos de TI que sustentan múltiples procesos de negocio, esto hace que la clasificación se atribuya al proceso de negocio más crítico. El enfoque que adoptó el ISG de HDFC Bank está íntimamente alineado con la cascada de metas de COBIT 5 (figura 4). En la figura 5, se muestran los motivadores o factores conductores de las partes interesadas que identificó HDFC Bank.

Niveles de madurez de la seguridad de la información El ISG ha creado un modelo de madurez de seguridad de la información. Este modelo ha definido cinco niveles de madurez, tal como se muestra en la figura 6. El ISG ha definido ocho atributos deseables para los componentes de la seguridad de la información. Estos se detallan en la columna 1. En las columnas subsiguientes, se definen los requerimientos necesarios para alcanzar el atributo de cada nivel. Por ejemplo, el atributo de política estará en el nivel 1 si no se ha definido una política para un componente en particular y en el nivel 5, es decir, en un nivel optimizado, si la política se revisa y mejora continuamente. El seguimiento de cada uno de los 21 componentes se basa en este modelo. HDFC Bank ha utilizado el modelo de madurez con muy buenos resultados para construir un concepto de benchmarking dentro de la organización. Este modelo permite

Figura 5: Factores conductores de partes interesadas de HDFC Bank



detectar áreas que requieren mejoras y los ejercicios de evaluación se realizan en el marco de un taller. Existe una comunicación saludable de dos canales que deriva en un sentido de participación y transparencia respecto de la estrategia y la visión de la empresa. El modelo se utiliza estrictamente para análisis de brechas internas y para identificar áreas de mejora. No ha sido pensado para proporcionar aseguramiento a un tercero. El modelo de madurez que se presenta a continuación fue creado por el ISG para satisfacer sus necesidades exclusivas de definición de planes de mejoras específicas. Este modelo de madurez se basa ligeramente en el modelo definido en COBIT 4.1. Una de las críticas al modelo de madurez de COBIT 4.1 fue que los criterios usados para definir los niveles eran subjetivos. En estos momentos, HDFC Bank está considerando la posibilidad de corresponder los procesos actuales con el modelo de evaluación de procesos (Process Assessment Model, PAM) de COBIT 5, que se basa en la norma ISO 15504.

Servicios, infraestructura y aplicaciones Los servicios, la infraestructura y las aplicaciones incluyen la infraestructura, la tecnología y las aplicaciones que brindan a la empresa servicios y procesamientos de TI. HDFC Bank emplea casi 40 tecnologías diferentes. Alrededor de estas tecnologías se desarrollan distintos servicios, infraestructuras y aplicaciones. Como se describió en la sección sobre el facilitador / habilitador de procesos, cada uno de estos servicios está cruzado con el nivel de madurez de la seguridad de la información. Una actualización continua del nivel de madurez, que tenga en cuenta atributos tales como la automatización, la eficacia, la gestión de incidentes y la medición, garantiza un monitoreo muy pormenorizado de estos servicios. Todos los proyectos que pretenden mejorar los servicios se basan en el nivel de madurez pensado para cada servicio en particular.

Información La información es generalizada en cualquier organización e incluye toda la información producida y utilizada por la empresa. Se requiere la información para mantener a la organización en funcionamiento y bien gobernada, pero a nivel operativo, la información es con frecuencia el producto clave de la misma empresa. La información confiable es un factor clave para la gestión de la seguridad. Habitualmente, la información se presenta por medio de documentación del Consejo en términos de estrategia, presupuesto, plan y políticas. Los requerimientos de seguridad de la información se obtienen por medio de un formulario de aceptación de riesgos (risk acceptance form, RAF) y son sometidos a una revisión a cargo del comité de gestión de riesgos de la seguridad de la información (information security

Figura 6: Modelo de madurez de la seguridad de la información

Columna 1 Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5

Inicial En desarrollo Definido Gestionado Optimizado

Política Ausencia de política Política limitada Política integral definida y publicada

Política publicada e implementada de manera uniforme

Revisión y mejora continuas de la política

Roles y responsabilidades

Roles y responsabilidades no definidos

Roles parcialmente definidos

Roles y responsabilidades bien determinados y definidos

Roles y responsabilidades definidos y ejecutados

Roles y responsabilidades revisados de manera continua

Automatización Manual Semiautomatizada Automatizada Automatizada y completamente operativa

Actualización permanente de la automatización

Alcance No implementado Cobertura limitada Activos críticos Completo Revisión periódica del alcance para garantizar la cobertura total

Eficacia N/A Baja Media Alta Muy alta

Gestión de incidentes

Sin seguimiento Visibilidad limitada Seguimiento de incidentes críticos

Seguimiento y cierre de todos los incidentes

RCA aplicado a todos los incidentes y solucionados

Medición Sin medición Medición limitada Mediciones integrales definidas

Medido y revisado de forma periódica

Criterios de medición revisados periódicamente

Informes Sin informes Informes limitados Informes definidos Informes enviados a la alta dirección y revisados

Requerimientos de informes periódicamente revisados y actualizados



risk management committee, ISRMC). El ISG también prepara varios informes de revisión de seguridad de la información, que incluyen hallazgos de auditoría, informes de madurez, análisis de amenazas, informes de evaluación de vulnerabilidades, registros de riesgo de la información, informes de brechas y pérdidas, e informes de incidentes y problemas relacionados con la seguridad de la información. El modelo de madurez proporciona entradas adicionales para información de buena calidad. Se han creado varias métricas y mediciones de seguridad de la información basadas en el marco de la norma ISO 27004, que se presentan a modo de tablero de mando (dashboard). En la actualidad, se está trabajando para implementar una herramienta GRC de TI que permita captar toda la información en la fuente y demostrar cumplimiento de numerosos requerimientos, que incluyen las guías de RBI, PCI DSS y Basilea II. Además, la herramienta permite el cruce con diferentes controles de COBIT 4.1.

Personas, habilidades y competencias Las personas, habilidades y competencias están vinculadas a las personas y son requeridas para la finalización exitosa de todas las actividades y para tomar decisiones correctas y aplicar medidas correctivas.

HDFC Bank ha empleado una serie de técnicas para crear conciencia sobre la seguridad y desarrollar habilidades y competencias adecuadas. A continuación se incluye una lista de las iniciativas: • Película sobre la seguridad de

la información: Una película de 20 minutos de duración creada y presentada con todas las atracciones propias de una experiencia cinematográfica verdadera (p. ej., boletos y palomitas de maíz). La película ya ha adquirido una enorme notoriedad y, hasta el momento, la han visto 40 000 empleados. Cada programa de capacitación comienza con esta película.

• Tira cómica sobre seguridad de la información: Se creó una tira cómica con dos personajes: uno llamado Sloppy ("Descuidado") y el otro Sly ("Astucia"). Sus hazañas entretienen a los lectores y también transmiten un mensaje muy poderoso sobre la seguridad. Ahora, se está planeando imprimir esta tira cómica con formato de calendario.

• Red de seguridad: La red de seguridad (una Intranet) alberga todo el material relevante, como políticas, estándares, guías, listas de contactos, planes de continuidad del negocio y notas sobre el enfoque.

• Correo electrónico y campaña de imágenes: Se envían mensajes por correo electrónico advirtiendo a todos para que se mantengan alerta, por ejemplo, se envían mensajes a modo de recordatorio para evitar correos phishing después de que se haya producido un intento de ataque phishing exitoso.

• Diez mandamientos de seguridad: El documento sobre la política del usuario se ha resumido en reglas clave de seguridad de la información fáciles de leer y recordar (figura 7).

• Curso La seguridad primero: Todos los empleados deben participar en este curso de una hora de duración cada dos años. Es obligatorio tomar el curso y obtener buenas calificaciones. Todos los candidatos que hayan obtenido buenas calificaciones en el examen recibirán un certificado. El certificado es un reconocimiento de carácter oficial. Además del certificado, los mejores promedios serán reconocidos en comunicaciones globales enviadas a todos los empleados del banco, y también recibirán una compensación económica.

• Taller de un día: Se realiza periódicamente un taller de un día de duración destinado a la alta dirección, en el que el CISO explica la importancia de la seguridad de la información para el banco y las medidas específicas adoptadas para su

Figura 7: Diez mandamientos de HDFC Bank


Actualización de búsqueda

Materiales de COBIT 5 recientemente publicados

COBIT® 5: Información Habilitadora

Publicaciones de COBIT 5 del primer trimestre de 2014 - Próxima

aparición • Escenarios de riesgo para

COBIT 5® Otras iniciativas de COBIT 5 en

desarrollo • COBIT® 5 en línea: Acceso

a las publicaciones de la familia de productos COBIT 5 y a otro contenido de ISACA no relacionado con COBIT, y a material de GEIT actual y relevante (publicación tentativa segundo trimestre de 2014)

• COBIT® 5 para Sarbanes-Oxley (publicación tentativa segundo trimestre de 2014)

• Controles y aseguramiento en la nube: Utilizando COBIT® 5 (publicación tentativa segundo trimestre de 2014)

• COBIT 5 en línea: Habilidad para personalizar a COBIT para que se adapte a las necesidades de su empresa con acceso a varios usuarios (publicación tentativa tercer trimestre de 2014) Si desea obtener más información sobre las

publicaciones de COBIT, visite la página de COBIT 5 en el

sitio web de ISACA. Dispone de traducciones de COBIT 5 en la página COBIT Product family (Familia de

Productos de COBIT).

implementación.

Cultura, ética y comportamiento La cultura, la ética y el comportamiento de individuos y de la empresa son, a menudo, subestimados como un factor de éxito en las actividades de gobierno y gestión. No obstante, son factores importantes para el éxito de una empresa.

COBIT 5 ha identificado ocho clases de comportamientos que contribuyen con el desarrollo de una cultura de seguridad en una organización. Varias iniciativas tomadas por HDFC Bank dieron lugar a la creación del tipo correcto de comportamientos de seguridad. HDFC Bank ha utilizado muchos canales de comunicación, cumplimiento, políticas claras, reglas y normas. El comportamiento seguro también se fomenta a través del reconocimiento, por ejemplo, por medio de un certificado, y a través de mensajes contundentes a quienes no demuestren tal conducta. El comportamiento seguro está fuertemente influenciado por la concientización. Las ocho clases de comportamientos se indican a continuación a modo de referencia junto con las medidas específicas adoptadas por HDFC Bank para arraigar estas conductas a la práctica diaria de los empleados del banco: • La seguridad de la información se practica en las operaciones diarias. La dirección

de HDFC Bank ha transmitido sus expectativas hacia los empleados destacando el principio de tolerancia cero en lo que respecta a comportamientos inaceptables relacionados con la seguridad de la información, premio al buen comportamiento, reconocimiento y recompensa para las personas que trabajan correctamente en la gestión de riesgos, y recordatorios permanentes del lema “Security is incomplete without U” (La segUridad está incompleta sin Usted). De esta manera, se ha garantizado la práctica de seguridad de la información en las operaciones diarias.

• Las personas respetan la importancia de las políticas y los principios de seguridad de la información. La cultura de la seguridad se ha gestado a través de constantes esfuerzos por crear conciencia al respecto. Ahora los empleados comprenden la importancia de la seguridad de la información y toman las iniciativas afines con absoluta seriedad. La auditoría también ha tenido un rol importante para hacer cumplir las políticas y los principios de seguridad.

• Las personas reciben guías suficientes y pormenorizadas de seguridad de la información y se les motiva a participar y retar la situación actual de la seguridad de la información. HDFC Bank cree que todas las partes interesadas deben comprometerse con los esfuerzos de seguridad. La introducción de cualquier proceso nuevo implica asegurar una interacción abierta con todas las partes afectadas. Los temas se debaten en talleres y la aprobación se obtiene por medio de un diálogo de dos canales, de modo que todos tengan la posibilidad de aclarar las dudas que surjan. Se proporciona capacitación extensiva para cada iniciativa nueva de seguridad de la información, no exclusivamente al grupo que trabaja con la seguridad de la información, sino a todas las partes interesadas.

• Todos deben rendir cuentas sobre la protección de la información dentro de la empresa. El grupo de seguridad de la información es responsable de identificar y gestionar el riesgo, mientras que los directores del negocio son quienes en última instancia deben rendir cuentas. Esto se ha documentado con claridad en la matriz RACI analizada previamente. De esta forma, todas las partes interesadas se sienten responsables así como también sienten que deben rendir cuentas sobre la protección de la información dentro de la empresa.

• Las partes interesadas son conscientes de cómo identificar y responder a amenazas a la empresa. La identificación de amenazas forma parte del entrenamiento que se les da a las partes interesadas. Se las alienta a comunicar incidentes, por ejemplo, enviar un mensaje por correo electrónico al ISG sobre correo basura o mal intencionado (phishing) que hayan recibido. La respuesta recibida a diario por el ISG da cuenta de la enorme conciencia que todos han desarrollado para identificar y comunicar incidentes.



http://www.isaca.org/COBIT/Pages/Product-Family.aspx

• La dirección respalda y anticipa proactivamente innovaciones en cuanto a seguridad de la información y comunica esto a la empresa. La empresa es receptiva para dar cuenta de los nuevos desafíos en materia de seguridad de la información y abordarlos. El ISG está permanentemente comprometido con la introducción de innovaciones para abordar los desafíos de seguridad de la información. La dirección brinda su respaldo completo para interactuar con la industria y compartir sus conocimientos y experiencia con una audiencia mayor, así como para aprender de otros. Este caso de estudio es un ejemplo de esta apertura.

• La dirección del negocio se compromete en una colaboración multifuncional continua a fin de fomentar la puesta en marcha de programas de seguridad de la información eficientes y eficaces. La estructura de varios comités es un ejemplo de colaboración multifuncional continua. Independizar a la seguridad de la información de la función de TI ha ampliado en mayor medida el alcance y el acceso directo a varios grupos de negocios en toda la organización.

• La dirección ejecutiva reconoce el valor de la seguridad de la información para el negocio. El CISO trabaja en un nivel estratégico y reporta a una persona del banco que tiene un cargo más jerárquico. Esto ha facultado al CISO a impulsar varias iniciativas de seguridad de la información con una gran cuota de libertad. Planteado de esta forma, es un buen indicador de reconocimiento de la dirección en lo que respecta al valor de la seguridad de la información para el negocio.

El liderazgo como factor influyente Además, el liderazgo en HDFC Bank tiene un rol preponderante en el desarrollo de la cultura de la seguridad. La participación activa de la dirección ejecutiva y la gestión de las unidades de negocio en los distintos comités de alto nivel, donde la seguridad de la información es un tema importante de la agenda, demuestra el compromiso en los niveles gerenciales. La participación de los dirigentes en los ejercicios de planificación de continuidad del negocio para analizar diferentes escenarios de desastre también demuestra un profundo compromiso.

Vishal Salvi, CISM Cuenta con más de 20 años de experiencia en la industria. Ha trabajado en Crompton Greaves, Development Credit Bank, Global Trust Bank y Standard Chartered Bank antes de desempeñarse en su puesto actual como director general de seguridad de la información y vicepresidente sénior de HDFC Bank. En HDFC Bank, dirige el grupo de seguridad de la información y es responsable de liderar el desarrollo y la implementación del programa de seguridad de la información en todo el banco.

Avinash W. Kadam, CISA, CISM, CGEIT, CRISC, CBCP, CISSP, CSSLP Es una autoridad líder en seguridad de la información. Cuenta con cuatro décadas de experiencia en gestión de TI, auditoría de sistemas de información, y consultoría y capacitación en seguridad de la información. Actualmente se desempeña como asesor del grupo de trabajo de ISACA en India. Antes, Kadam ocupó el cargo de vicepresidente internacional de ISACA de 2006 a 2008 y de presidente del capítulo de Bombay de ISACA de 1998 a 2000. Ha recibido el Premio Harold Weiss 2005 de ISACA.

Soportando el cumplimiento de PCI DSS 3.0 con COBIT 5 Por Stefan Beissel, Ph.D., CISA, CISSP El Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) tiene por objeto mejorar la seguridad de los datos de los titulares de tarjetas y es requerido cuando se almacenan, procesan o transmiten los datos de los titulares de tarjeta o los datos de autenticación. La implementación de procesos facilitadores / habilitadores de COBIT® 5 puede respaldar el cumplimiento del PCI DSS.1 COBIT 5 ayuda a las empresas en su gobierno y gestión de TI (GEIT) en términos generales y, al mismo tiempo, respalda la necesidad de cumplir los requerimientos de seguridad con procesos facilitadores / habilitadores y actividades de gestión. El cruce de los procesos facilitadores / habilitadores de COBIT 5 con los requerimientos de seguridad de PCI DSS 3.0 facilita la aplicación simultánea de COBIT 5 y PCI DSS 3.0 y ayuda a crear sinergias dentro de la empresa.

PCI DSS 3.0 El PCI DSS fue introducido por el consejo de estándares de seguridad de PCI (PCI SSC), un panel conformado por cinco marcas internacionales de pagos (American Express, Discover Financial Services, JCB International, MasterCard Worldwide y Visa Inc.). El PCI DSS también incluye requerimientos para la seguridad de los datos y métodos de auditoría relacionados.


En especial, el número de cuenta primario (primary account number, PAN) es el factor determinante en la aplicabilidad de los requerimientos de PCI DSS.

El objetivo del PCI DSS es básicamente proteger la confidencialidad de los datos de los titulares de tarjetas. La confidencialidad, como parte de la tríada de seguridad de la información que incluye integridad y disponibilidad, es uno de los objetivos principales de la protección y la seguridad de la información. La confidencialidad es la garantía de que los datos no serán vistos por personas no autorizadas ni divulgados a ellas y, en consecuencia, no se verán comprometidos. Las medidas que habitualmente se usan para proteger la confidencialidad también suelen proteger la integridad. Por ejemplo, si un atacante o software malicioso compromete los datos, por lo general también se verá afectada la integridad. La integridad es la garantía de que los datos continúan siendo exactos e íntegros y ningún medio no autorizado puede alterarlos o modificarlos. La disponibilidad significa que los sistemas o usuarios

autorizados pueden acceder a los datos en cualquier momento deseado. La disponibilidad está garantizada por los sistemas y la infraestructura, que están preparados para usar y tener capacidad suficiente para procesar todas las solicitudes tan pronto como sea necesario. Los atacantes pueden comprometer la disponibilidad de información inundando el sistema con solicitudes de servicio y, en consecuencia, provocando un ataque de negación del servicio, previniendo el acceso a información o datos críticos.

Es necesario que las compañías de procesamiento de tarjetas de crédito configuren un entorno que cumpla con PCI DSS porque sin él no alcanzarían una parte importante de su modelo de negocio e incurrirían en enormes pérdidas. Además, puede esperarse una pérdida de reputación y posibles multas de las compañías de tarjetas de crédito. Las compañías de procesamiento de tarjetas de crédito se clasifican en cuatro niveles de cumplimiento comercial (niveles/capas uno a cuatro) en relación con la cantidad de transacciones afectadas en un período de 12 meses.2 Cada nivel presenta requerimientos de cumplimiento del PCI DSS específicos. Las compañías clasificadas en los niveles dos a cuatro deben rellenar un cuestionario de autoevaluación (self-assessment questionnaire, SAQ) anual y completar un escaneo de red trimestralmente realizado por un proveedor de servicios de escaneo aprobado (approved scanning vendor, ASV). Las compañías con un número de transacciones anuales de seis millones o más se clasifican como de nivel uno y deben crear cada año un informe sobre cumplimiento (report on compliance, ROC) y ser auditadas por un evaluador de seguridad calificado (Qualified Security Assessor, QSA). El resultado de la auditoría se documenta con un testimonio de cumplimiento (attestation of compliance, AOC).3

El PCI DSS aborda 12 requerimientos importantes (figura 1) para medidas de control que se dividen por temas, entre ellos, red (requerimientos 1 y 2), protección de los datos de los titulares de tarjetas (requerimientos 3 y 4), programa de gestión de vulnerabilidades (requerimientos 5 y 6), medidas de control de acceso (requerimientos 7, 8 y 9), monitoreo y comprobación de redes (requerimientos 10 y 11), y política de seguridad de la información (requerimiento 12). A su vez, cada requerimiento está dividido en sub-requerimientos y procedimientos de prueba.

Figura 1: Tópicos y requerimientos de PCI DSS 3.0


En noviembre de 2013, se publicó la versión 3.0 del PCI DSS. Para 2015, el cumplimiento de esta nueva versión será vinculante para todas las compañías de procesamiento de tarjetas. Si se compara con la versión 2.0, la versión 3.0 contiene cambios a modo de aclaraciones adicionales, orientación y requerimientos avanzados.4 Los 20 requerimientos avanzados tienen por objeto alcanzar mejoras en las áreas de concientización, flexibilidad y responsabilidad hacia la seguridad.

COBIT 5 COBIT 5 proporciona un marco de referencia exhaustivo que asiste a las empresas a alcanzar sus objetivos de GEIT. Ayuda a las empresas a crear un valor óptimo de la TI manteniendo un equilibrio entre la obtención de beneficios y la optimización de los niveles de riesgo y el uso de recursos.5 La familia de productos COBIT 5 también incluye guías de facilitadores /

habilitadores, guías profesionales y un entorno de colaboración en línea. El cambio más importante al compararlo con COBIT® 4.1 es la reorganización del marco de un modelo de proceso de TI a un marco de gobierno de TI. El siguiente capítulo correlaciona los requerimientos de seguridad de PCI DSS 3.0 con los procesos facilitadores / habilitadores claves asociados de COBIT 5. El modelo de referencia de los procesos de COBIT 5 incluye procesos para GEIT (figura 2).6

Procesos facilitadores / habilitadores de COBIT por tópico de PCI DSS Red Se debe proteger a todos los sistemas sensibles contra el acceso no autorizado desde redes no confiables. Se emplean firewalls para separar redes de forma segura. Estos firewalls controlan el tráfico de la red y bloquean el acceso no deseado entre redes. Se los puede usar localmente o en estaciones de trabajo, o pueden ser sistemas dedicados dentro de la infraestructura de red.

El uso de configuraciones restrictivas puede minimizar el riesgo de acceso no autorizado desde el exterior de la red de la compañía. Los valores predeterminados (default) que están presentes en la entrega de sistemas y componentes representan un riesgo para la seguridad. Las contraseñas y demás configuraciones especificadas por el fabricante de los sistemas suelen estar ampliamente disponibles y pueden ser explotadas por personas no autorizadas. Además, se suele activar una serie de servicios innecesarios después de la instalación inicial de los sistemas operativos. Estos servicios también pueden ser explotados por personas no autorizadas. Los procesos facilitadores / habilitadores clave de COBIT 5 que pueden ayudar a mitigar el riesgo se detallan en la figura 3.

Figura 3: Procesos de red Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

1. Instalar y mantener una configuración de firewall para proteger los datos de los titulares de tarjetas.

APO01.08 Mantener el cumplimiento de políticas y procedimientos. APO03.02 Definir la arquitectura de referencia. APO12.01 Recopilar datos. BAI03.03 Desarrollar los componentes de la solución. BAI03.05 Construir soluciones. BAI03.10 Mantener soluciones. BAI06.01 Evaluar, priorizar y autorizar solicitudes de cambio. BAI07.03 Planificar pruebas de aceptación. BAI07.05 Ejecutar pruebas de aceptación.

Figura 2: Modelo de referencia de procesos de COBIT 5


BAI10.01 Establecer y mantener un modelo de configuración. BAI10.02 Establecer y mantener un repositorio de configuración y una línea base. BAI10.03 Mantener y controlar los elementos de configuración. DSS01.03 Monitorear la infraestructura de TI. DSS02.03 Verificar, aprobar y resolver solicitudes de servicio. DSS05.02 Gestionar la seguridad de la red y las conexiones. DSS05.04 Gestionar la identidad del usuario y el acceso lógico. DSS05.05 Gestionar el acceso físico a los activos de TI. DSS05.07 Monitorear la infraestructura para detectar eventos relacionados con la seguridad. DSS06.03 Gestionar roles, responsabilidades, privilegios de acceso y niveles de autorización.

2. No utilizar los valores predeterminados (default) suministrados por el proveedor en las contraseñas del sistema y demás parámetros de seguridad.

APO01.08 Mantener el cumplimiento de políticas y procedimientos. APO03.02 Definir la arquitectura de referencia. BAI03.03 Desarrollar los componentes de la solución. BAI03.10 Mantener soluciones. DSS04.08 Ejecutar revisiones post-reanudación. DSS05.03 Gestionar la seguridad de los puntos de destino. DSS05.05 Gestionar el acceso físico a los activos de TI. DSS05.07 Monitorear la infraestructura para detectar eventos relacionados con la seguridad.

Protección de datos de titulares de tarjetas Los datos de los titulares de tarjetas deben almacenarse y mostrarse únicamente en determinadas circunstancias. Los requerimientos relevantes abordan el almacenamiento, la eliminación, la encriptación y el enmascaramiento de datos (figura 4). El PCI DSS aborda la encriptación así como cuestiones específicas, por ejemplo, el manejo de llaves electrónicas / criptográficas. Cada vez que se transmiten datos de los titulares de tarjetas por redes públicas abiertas, se requerirá una encriptación. Si los datos se transmiten (p. ej., por Internet, redes inalámbricas, el sistema global para comunicaciones móviles [Global System for Mobile Communications, GSM], el servicio general de radiocomunicaciones por paquetes [General Packet Radio Service, GPRS]), existe un mayor riesgo de que un atacante pueda escuchar furtivamente y manipular los datos de los titulares de la tarjetas. La aplicación de encriptación, según se especificó, es uno de los tantos métodos sugeridos para minimizar este riesgo.

Figura 4: Procesos para la protección de datos de titulares de tarjetas Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

3. Protección de datos de titulares de tarjetas almacenados.

APO01.06 Definir la propiedad de la información (datos) y del sistema. APO01.08 Mantener el cumplimiento de políticas y procedimientos. APO13.01 Establecer y mantener un sistema de gestión de seguridad de la información (ISMS). APO13.03 Monitorear y revisar el ISMS. BAI08.02 Identificar y clasificar las fuentes de información. BAI08.05 Evaluar y retirar la información. BAI09.02 Gestionar activos críticos. BAI09.03 Gestionar el ciclo de vida de los activos. DSS01.01 Ejecutar procedimientos operativos. DSS04.08 Ejecutar revisiones post-reanudación.


DSS05.03 Gestionar la seguridad de los puntos de destino. DSS05.04 Gestionar la identidad del usuario y el acceso lógico. DSS05.05 Gestionar el acceso físico a los activos de TI. DSS05.06 Gestionar documentos sensibles y dispositivos de salida. DSS06.04 Gestionar errores y excepciones. DSS06.05 Asegurar la trazabilidad de los eventos de información y su rendición de cuentas.

4. Encriptar la transmisión de datos de titulares de tarjetas por redes públicas abiertas.

APO11.02 Definir y gestionar los estándares, procedimientos y prácticas de calidad. APO11.05 Integrar la gestión de la calidad en soluciones para el desarrollo y la entrega de servicios. BAI03.03 Desarrollar los componentes de la solución. DSS01.01 Ejecutar procedimientos operativos. DSS01.02 Gestionar servicios externalizados de TI. DSS01.04 Gestionar el entorno. DSS01.05 Gestionar las instalaciones. DSS05.01 Proteger contra software malicioso (malware). DSS05.02 Gestionar la seguridad de la red y las conexiones. DSS05.03 Gestionar la seguridad de los puntos de destino. DSS05.06 Gestionar documentos sensibles y dispositivos de salida. DSS06.05 Asegurar la trazabilidad de los eventos de información y su rendición de cuentas.

Gestión de vulnerabilidades El uso de un software antivirus es necesario para proteger los sistemas contra software malicioso. Este puede incluir técnicas de detección basadas en patrones y basadas en comportamientos. Las técnicas de detección basadas en patrones detectan virus solamente después de que el software antivirus se haya actualizado con los nuevos patrones de virus. Las técnicas de detección basadas en comportamientos permiten identificar software maliciosos (malware) sobre la base de patrones de comportamientos no convencionales, pero estas técnicas de detección pueden ser inexactas y producir resultados falso positivos y falso negativos. El desarrollo y el mantenimiento de sistemas y aplicaciones también deben ser seguros. Esto incluye la prevención o la eliminación de vulnerabilidades que puedan ser objeto de explotación por atacantes para comprometer o manipular los datos de los titulares de tarjetas. Se debe llevar a cabo la instalación periódica de parches en los sistemas operativos y las aplicaciones, y se requiere la programación segura de desarrollos. Pruebas cuidadosas garantizan la detección de vulnerabilidades. (Vea la figura 5).

Figura 5: Procesos para la gestión de vulnerabilidades Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

5. Usar y actualizar periódicamente los programas o software antivirus.

APO12.01 Recopilar datos. APO12.03 Mantener un perfil de riesgo. DSS05.01 Proteger contra software malicioso (malware).

6. Desarrollar y mantener sistemas y aplicaciones seguras.

APO12.02 Analizar el riesgo. APO12.04 Expresar el riesgo. BAI03.03 Desarrollar los componentes de la solución. BAI03.05 Construir soluciones. BAI03.07 Preparar pruebas de la solución. BAI03.08 Ejecutar pruebas de la solución. BAI03.10 Mantener soluciones.


BAI06.01 Evaluar, priorizar y autorizar solicitudes de cambio. BAI06.02 Gestionar cambios de emergencia. BAI06.03 Hacer seguimiento e informar cambios de estado. BAI06.04 Cerrar y documentar los cambios. BAI07.01 Establecer un plan de implementación. BAI07.04 Establecer un entorno de pruebas. BAI07.05 Ejecutar pruebas de aceptación. BAI07.06 Pasar a producción y gestionar los lanzamientos / liberaciones (releases). DSS05.01 Proteger contra software malicioso (malware).

Medidas de control de acceso El acceso a los datos de titulares de tarjetas debe estar restringido en función de los roles correspondientes, según se definen por la necesidad del negocio. De acuerdo con los principios de acceso mínimo y de la necesidad de conocer (need-to-know), solo las personas autorizadas a acceder los datos de titulares de tarjetas con objetivos comerciales deberían tener el acceso permitido. Esto exige la implementación de gestión de control y autorización, en la cual cada persona puede tener un rol asignado con los permisos correspondientes (control de acceso basado en roles [role-based access control, RBAC]) (figura 6). Para cada persona que tenga acceso al sistema, se requiere la asignación de una identificación (ID) única. Esto generalmente se implementa por medio de cuentas personales. Solo una persona que pueda ser autenticada con éxito utilizando una contraseña, un token u otro método de autenticación podrá acceder a una computadora o sistema. También se debe restringir el acceso físico a los datos de los titulares de tarjetas. Los intrusos que obtengan acceso a oficinas o centros de datos podrían hurtar, dañar o manipular medios o componentes de computadoras. Los medios pueden ser electrónicos (como disquetes, CD y discos duros) o documentos en papel. Con control de acceso físico y el uso visible de distintivos, será posible distinguir a una persona no autorizada de un usuario autorizado.

Figura 6: Procesos para medidas de control de acceso Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

7. Restringir el acceso a datos de titulares de tarjetas por medio de la necesidad de conocer (need-to-know) del negocio.

DSS05.04 Gestionar la identidad del usuario y el acceso lógico.

8. Asignar una ID única a cada persona con acceso a la computadora.

APO03.02 Definir la arquitectura de referencia. APO07.01 Mantener una dotación de personal suficiente y adecuada.

9. Restringir el acceso físico a los datos de titulares de tarjetas.

APO01.06 Definir la propiedad de la información (datos) y del sistema. DSS05.04 Gestionar la identidad del usuario y el acceso lógico. DSS05.05 Gestionar el acceso físico a los activos de TI.

Monitoreo y comprobación / prueba de redes Se debe rastrear, monitorear y registrar todo acceso a los recursos de red y datos de titulares de tarjetas (figura 7). Con los protocolos correspondientes, es posible identificar y rastrear el acceso no autorizado. Además, los protocolos resultan útiles durante el análisis de fallas técnicas. El PCI DSS exige el registro de cada acceso a los datos de titulares de tarjetas. Es preciso probar periódicamente los sistemas y procesos de seguridad. Este procedimiento incluye el escaneo periódico para detectar vectores de vulnerabilidades y ataques a la seguridad. Amenazas como estas deben identificarse y eliminarse antes de que puedan ser explotados por posibles atacantes.

Figura 7: Procesos para el monitoreo y Prueba de las redes Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

10. Hacer seguimiento y monitorear todos los accesos a los recursos de red y datos de titulares de tarjetas.

DSS01.01 Ejecutar procedimientos operativos. DSS01.03 Monitorear la infraestructura de TI. DSS04.08 Ejecutar revisiones post- reanudación. DSS05.04 Gestionar la identidad del usuario y el acceso lógico.


DSS05.05 Gestionar el acceso físico a los activos de TI. DSS05.06 Gestionar documentos sensibles y dispositivos de salida. DSS05.07 Monitorear la infraestructura para detectar eventos relacionados con la seguridad. DSS06.04 Gestionar errores y excepciones. DSS06.05 Asegurar la trazabilidad de los eventos de información y su rendición de cuentas.

11. Probar periódicamente los sistemas y procesos de seguridad.

APO03.02 Definir la arquitectura de referencia. APO12.03 Mantener un perfil de riesgo. APO12.01 Recopilar datos. DSS02.01 Definir esquemas de clasificación de incidentes y solicitudes de servicio. DSS05.07 Monitorear la infraestructura para detectar eventos relacionados con la seguridad. MEA01.02 Establecer los objetivos de cumplimiento y rendimiento. MEA01.03 Recopilar y procesar los datos de cumplimiento y rendimiento. MEA01.04 Analizar e informar sobre el rendimiento. MEA02.01 Monitorear el control interno. MEA02.02 Revisar la eficacia de los controles sobre los procesos de negocio. MEA02.03 Realizar autoevaluaciones de control. MEA02.04 Identificar y comunicar las deficiencias de control.

Política de seguridad de la información Cada compañía debe diseñar y mantener una política de seguridad de la información, que debe ser comunicada y cumplida por todos los empleados (figura 8). La política debe contener los requerimientos propios de la seguridad de la información que deben cumplir todos los empleados. Los temas comprendidos dentro de una política de seguridad incluyen la comunicación de requerimientos del PCI DSS, la capacitación para crear conciencia sobre la importancia de la seguridad, la creación de un plan de respuesta ante incidentes y el monitoreo de una postura sobre seguridad de los proveedores de servicio.

Figura 8: Procesos para la política de seguridad de la información Requerimiento de PCI DSS 3.0 Proceso de COBIT 5 (Prácticas)

12. Mantener una política que aborda la seguridad de la información para todo el personal.

APO01.01 Definir la estructura organizativa. APO01.02 Establecer roles y responsabilidades. APO01.03 Mantener los facilitadores / habilitadores del sistema de gestión. APO01.05 Optimizar la ubicación de la función de TI. APO01.06 Definir la propiedad de la información (datos) y del sistema. APO13.01 Establecer y mantener un ISMS.

Conclusión Las compañías que almacenan, procesan o transmiten datos de titulares de tarjetas o datos de autenticación deben cumplir con los requerimientos de seguridad según el PCI DSS. Si estas compañías emplean COBIT 5, podrán abarcar los requerimientos de seguridad de PCI DSS 3.0 con los procesos facilitadores / habilitadores de COBIT 5. Desde otra óptica, pueden utilizar los requerimientos de seguridad de PCI DSS 3.0 para facilitar la implementación de COBIT 5 y alcanzar los objetivos de GEIT. De ambas maneras, estas sinergias permiten optimizar los niveles de riesgo y el uso de recursos.

Stefan Beissel, Ph.D., CISA, CISSP


Se desempeña como director de seguridad de TI, responsable de la gestión de proyectos relacionados con la seguridad y del cumplimiento del PCI DSS, en EVO Payments International.

Notas finales 1 El objetivo de este artículo es proporcionar una revisión general de las sinergias que existen entre COBIT 5: Procesos facilitadores / Habilitadores y PCI DSS 3.0. Conocer algunos aspectos

de PCI DSS, del consejo de estándares de seguridad de PCI (PCI SCC), de la familia de productos de COBIT 5 y de las guías habilitadoras disponibles será de gran ayuda. 2 Visa, “Detalles de validación de cumplimiento para comerciantes”, 2012 3 PCI SSC, Estándar de seguridad de datos de la industria de tarjetas de pagos (PCI): Requerimientos y procedimientos de evaluación de la seguridad, Versión 3.0, 2013 4 PCI SSC, “Estándar de seguridad de datos de la Industria de Tarjetas de Pagos (PCI): Resumen de cambios de la versión 2.0 del PCI DSS a la versión 3.0”, 2013 5 ISACA, COBIT 5, 2012 6 ISACA, COBIT 5: Procesos facilitadores / Habilitadores, 2012

Desarrollo de un marco de gobierno para la organización de soporte mundial en GlaxoSmithKline, utilizando COBIT Por Steve Williamson Al igual que la mayoría de las organizaciones impulsadas por la innovación, GlaxoSmithKline (GSK) depende ampliamente de la TI. Su numeroso grupo de soporte de TI centralizado ha utilizado COBIT® 4.1 como base para el desarrollo de un marco de gobierno de TI organizacional. GSK está iniciando su transición a COBIT® 5. La misión de GSK es "mejorar la calidad de la vida humana permitiendo a las personas hacer más, sentirse mejor y vivir más tiempo". En virtud de esta misión, GSK desarrolla y fabrica productos farmacéuticos para tratar una variedad de afecciones, que incluyen enfermedades respiratorias, cáncer, cardiopatías y epilepsia. GSK investiga y fabrica vacunas que nos protegen contra enfermedades infecciosas, que incluyen gripe, rotavirus, cáncer cervical, sarampión, paperas y rubéola. Fabrica además productos innovadores para el cuidado de la salud del consumidor general; su cartera de productos incluye marcas muy conocidas como Horlicks, Panadol y Sensodyne. GSK es una compañía internacional que opera en más de 115 países y cuenta con 100 000 empleados aproximadamente. Una de las prioridades estratégicas de GSK es simplificar su modelo operativo, lo que reduce la complejidad y, en consecuencia, la torna más eficiente. De este modo, se liberarán recursos para invertir en otras áreas más productivas del negocio. Uno de los resultados de esta estrategia es una organización de TI más centralizada, que proporcione servicios de soporte de TI estándar a todas las áreas de negocio. El grupo de soporte de la aplicación fue formado a partir de la fusión de varios grupos de TI autónomos, orientados al negocio, y es responsable de una cartera de más de 2000 aplicaciones compatibles con cada etapa de la cadena de valor (investigación, desarrollo, fabricación, y funciones comerciales y corporativas). Este departamento cuenta con cientos de empleados permanentes, situados en diferentes lugares del mundo. Dos socios comerciales en el extranjero proporcionan soporte técnico adicional. El departamento de soporte de aplicaciones ha desarrollado un marco de gobierno para GSK.

Gobierno para una función de soporte de TI Poco después de la creación del nuevo departamento de soporte global, se identificó la necesidad de evaluar los procesos de gobierno. El objetivo era verificar que la organización recientemente conformada tuviera las estructuras, los procesos y los controles correctos para habilitar la ejecución exitosa de su estrategia y para garantizar la alineación con la estrategia de la empresa. El gobierno organizacional es un término de gestión comúnmente aceptado, que no todos alcanzan a comprender profundamente. Sin embargo, intentar definir exactamente en qué consiste el gobierno de TI y cómo se aplica a una organización de TI es, en sí, todo un desafío. Por lo tanto, es útil recurrir a marcos de la industria que ya han sido comúnmente aceptados. En este caso, el departamento de soporte de aplicaciones de GSK utilizó COBIT® (para este ejercicio, se utilizó la versión 4.1). ISACA define el gobierno de TI como "La responsabilidad de los ejecutivos y del consejo de administración. Consiste en el liderazgo, las estructuras organizacionales y los procesos que aseguran que TI apoya y extiende las estrategias y los objetivos de la empresa".1


http://usa.visa.com/merchants/risk_management/cisp_merchants.html

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_Summary_of_Changes.pdf



¿Por qué COBIT? Una de las ventajas de COBIT 4.1 es que se presenta como un marco fuertemente centrado en el control, en lugar de la ejecución. Abarca una amplia gama de áreas de gobierno (por ejemplo, recursos humanos, finanzas, alineación estratégica, gestión de riesgos, gestión de servicios) y se puede cruzar con otros estándares de la industria, tales como la norma ISO 27001 para seguridad e ITIL para la gestión de servicios, lo cual se adaptó muy bien a la situación de GSK.

Cómo GSK utilizó COBIT 4.1 COBIT 4.1 es integral, aunque cuenta con una estructura simple, y cada área de proceso está subdividida en descripción del proceso, objetivos de control, guías para la gestión y modelos de madurez. Esto facilita la selección de procesos que se aplican mejor a las metas de la organización e ignora aquellos que no son relevantes o que tienen menor importancia. Por ejemplo, los procesos de COBIT denominados PO2 Definir la arquitectura de la información y PO3 Determinar la dirección tecnológica son la principal responsabilidad de otro departamento dentro de la empresa, de modo que estos se excluyeron del marco del departamento de soporte de aplicaciones, mientras que otros procesos de COBIT 4.1 solo se aplicaron parcialmente. El departamento de soporte de aplicaciones siguió los siguientes pasos para crear su marco de gobierno: 1. Identificar las áreas de procesos aplicables de COBIT 4.1. 2. Identificar los objetivos de control aplicables dentro de cada área de proceso. 3. Realizar la evaluación de riesgos, es decir, determinar el impacto que tendrían las fallas de control de cada proceso en la

organización. 4. Identificar qué procesos, procedimientos o prácticas de trabajo existentes abordan esta área de proceso, y evaluarlos

teniendo en cuenta los objetivos de control. 5. Efectuar revisiones con expertos en la materia y la alta dirección, incluyendo los responsables de implementar los

controles. 6. Documentar toda brecha o control débil, explicando el riesgo e introduciendo esta información en el flujo de trabajo

relevante para la mejora del proceso. Cuando se identifican debilidades de control, habitualmente implica que una política no se está implementando de manera eficaz. Esto determina la necesidad de recurrir a una acción correctiva, que es responsabilidad de la dirección. Esta clase de análisis podría revelar un problema más fundamental, como un riesgo no reconocido anteriormente o inadecuadamente mitigado. En una situación como esa, la acción correctiva implicaría efectuar cambios en el marco de la política. La dirección no debería abordar tales acciones, sino la junta de cumplimiento. Esto podría dar lugar a una política nueva o enmendada o a decisiones relacionadas con la tolerancia al riesgo.

El marco de gobierno está estructurado por medio de las áreas de enfoque de gobierno de TI (cruzadas con las áreas de proceso de COBIT) e incluyen las siguientes: • Gobierno de relaciones y organización de TI. • La alineación estratégica de los objetivos de negocio y de TI. • Marco de las políticas de calidad, riesgo y control. • Gestión de comunicaciones, capacitación y conocimiento. • Cartera de inversiones, gestión financiera y gobierno de entrega de valor. • Desarrollo, implementación y mantenimiento de sistemas. • Gestión de prestación de servicios de terceros/proveedores. Para cada área de enfoque de gobierno, se definieron objetivos de control, factores de riesgo claves y la implementación (figura 1).


Figura 1: Estructura de las áreas de enfoque de gobierno

Sección Descripción

Objetivos de control Estos se extrajeron directamente de COBIT 4.1. Se seleccionaron objetivos de control aplicables (se excluyeron los que solo estaban ligeramente asociados).

Factores de riesgo clave Supone el análisis de los impactos organizacionales a partir de fracasos para cumplir los objetivos de control eficazmente. Los ejemplos de impactos de riesgo incluyen ineficiencias operativas, aumento de la probabilidad de brechas a la seguridad, falla normativa y sanciones de índole legal.

Implementación Esta sección describe los procedimientos, controles y estructuras organizacionales que estaban en uso en ese momento y abordaban los objetivos de control. Esto reveló brechas y debilidades.

Uno podría preguntarse: ¿de qué sirve complicarse para crear un documento separado en lugar de usar el material de COBIT directamente? La razón es que si se tiene un marco con un contexto empresarial conocido, COBIT se vuelve más intuitivo para quienes necesitan usarlo. Su finalidad es evaluar los procesos de GSK teniendo en cuenta un estándar comúnmente aceptado para el gobierno, en lugar de redefinir la métrica o introducir nuevas formas de trabajo. Esto aseguró que el documento fuera muy útil para una amplia variedad de personas, la mayoría de las cuales tiene escasa o ninguna experiencia en el uso de COBIT.

Hallazgos y valor derivado Los objetivos de control se pueden cumplir con un procedimiento (por ejemplo, proceso de control de cambios) o a través de estructuras organizacionales eficaces (por ejemplo, la representación en equipos de liderazgo), que demostraron claramente control y rendición de cuentas. Sin embargo, durante el análisis, el departamento de soporte de aplicaciones detectó que algunos objetivos de control se cumplían de manera eficaz a través de métodos que no implicaban ningún procedimiento. Si bien es menos formal que un procedimiento aprobado por la dirección, muchos de estos métodos estaban documentados o implícitos como parte de descripciones de trabajos, demostrando rendición de cuentas. Es relativamente fácil determinar si un procedimiento aborda o no las necesidades del objetivo de control. Juzgar la eficacia general de un procedimiento en un departamento de TI recientemente consolidado es más difícil sin una auditoría o recopilación extensiva de datos. Para ocuparnos de este tema, se utilizaron actividades de monitoreo recientemente implementadas para evaluar la eficacia de las técnicas de mitigación, y fueron la fuente clave de información, haciendo posible la mejora del programa en curso. En 2013, se efectuó una auditoría de gobierno en todo el departamento. Este documento de marco de referencia fue la base para la preparación de la auditoría. No cubrió todo lo que los auditores evaluaron, pero ayudó a demostrar lo adecuado de las estructuras de control en uso.

Próximos pasos El marco proporciona una evaluación en un momento específico de los controles del departamento de soporte de aplicaciones y da lugar a la identificación de amenazas, vulnerabilidades e ineficacias, factores de riesgo y problemas (que, de otro modo, no se hubieran detectado). Se mantendrá alineado con los cambios organizacionales (por ejemplo, si la organización comienza a ofrecer una variedad más amplia de servicios de TI, el marco podrá expandirse fácilmente). La siguiente evolución de este modelo de gobierno incluirá modelos de evaluación de capacidades de procesos para áreas de proceso claves. El modelo de evaluación de procesos de COBIT 5 constituirá la base para el diseño y la implementación de estos modelos. Esto también marca la transición a COBIT 5. Las áreas de proceso seleccionadas para evaluaciones de capacidades son las que presentarían el mayor impacto de riesgo si no operaran con eficacia. Como antes, los modelos se basarán en COBIT, pero referenciarán a las métricas y a los procesos de GSK. El primer paso es realizar una evaluación de línea base para determinar los niveles actuales de madurez y luego establecer los objetivos de mejora a largo plazo para garantizar la mejora continua del proceso durante los próximos cinco años.

Steve Williamson Es director de gestión de riesgos de TI en GlaxoSmithKline y es responsable de la seguridad de la información, el cumplimiento normativo y la gestión de calidad. Williamson comenzó su carrera en TI hace 25 años como probador de software en la industria bancaria. Williamson ha trabajado en GSK durante los últimos 16 años en varias funciones relacionadas con gerenciamiento de proyectos y gobierno, riesgo y cumplimiento.


Comité de marco Steven A. Babb, CGEIT, CRISC, ITIL, UK, Director David Cau, ITIL, MSP, Prince2, Francia Sushil Chatterji, CGEIT, Singapur Frank Cindrich, CGEIT, CIPP, CIPP/G, EE. UU. Joanne De Vito De Palma, EE. UU. Jimmy Heschl, CISA, CISM, CGEIT, ITIL, Austria Katherine McIntosh, CISA, EE. UU. Andre Pitkowski, CGEIT, CRISC, OCTAVE, Brasil Paras Shah, CISA, CGEIT, CRISC, CA, Australia

Contenido editorial Los comentarios relacionados con el contenido editorial pueden remitirse a Jennifer Hajigeorgiou, gerente sénior de redacción, al correo electrónico [email protected].

COBIT Focus es una publicación de ISACA. Las opiniones expresadas en COBIT Focus representan los puntos de vista de los autores. Pueden diferir de las políticas y declaraciones oficiales de ISACA y sus comités, y de las opiniones refrendadas por autores, empleados o editores de COBIT Focus. COBIT Focus no avala la originalidad del contenido de los autores.

© ISACA. Todos los derechos reservados.

Los instructores pueden fotocopiar artículos aislados sin cargo para uso no comercial en las aulas de clase. Para otras copias, reimpresiones o nuevas publicaciones, se debe obtener el permiso por escrito de la asociación. Comuníquese con Julia Fullerton por correo electrónico a [email protected].

Notas finales1 ISACA, Glosario

©2014 ISACA. Todos los derechos reservados.




http://www.isaca.org/Pages/Glossary.aspx

Banco de Medio Oriente mejora la seguridad de la … · • Mejorar la gestión de costos...

Documents

Transcript of Banco de Medio Oriente mejora la seguridad de la … · • Mejorar la gestión de costos...