Vsipinfo A1 Caso Ejemplo Cobit

Volumen 1, enero de 2014
En este número:
• 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 Convocatoria para

de la información presentación de
artículos
Por Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO,
PRINCE2
¿Cómo utiliza COBIT®
Como consecuencia de una iniciativa por mejorar la seguridad de la información con la en su empresa actualmente?
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. Aceptamos artículos en los que
• Comunicar decisiones vinculadas al riesgo y crear conciencia sobre los riesgos. describa su experiencia con
• Mejorar la prevención, detección y recuperación. este marco. Plazos
• Reducir (el impacto de) los incidentes vinculados a la seguridad de la información. para la presentación de una
• Aumentar el soporte relacionado con la innovación y la competitividad. copia para el
• Mejorar la gestión de costos relacionados con la función de seguridad de la volumen 2, 2014:
información.
10 de marzo de 2014
• 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 Envíe artículos para
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
revisión a:
problema a la hora de implementar COBIT para definir los principios de seguridad de publication@isaca.org
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 Estudio de casos
enormemente.
La organización utiliza varios estándares y marcos, incluida la norma ISO 27001, el Visite las páginas
Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (Payment Card
COBIT Recognition
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 (Reconocimiento de COBIT) y
procesos y principios departamentales con un marco común, ampliamente flexible y Case Studies (Estudio de
adaptable, que tuviera controles y procesos en común con otros marcos de la Casos) para obtener más
información sobre los estudios
®
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 de casos relacionados con
ellos, las normas de la Organización Internacional para la Estandarización
(International Organization for Standardization, ISO), el Marco de Arquitectura del COBIT 5 y COBIT 4.1.
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 Garantizar que la Las personas que integran la comunidad de Implementado Estrategia de
en el negocio. seguridad de la seguridad de la información deben entablar seguridad de la
información esté relaciones con líderes de negocio y demostrar el información
integrada a las modo en que la seguridad de la información puede
actividades complementar negocios claves y procesos de
esenciales del gestión de riesgos. Ellas deberían adoptar un
negocio. 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.
Ofrecer Garantizar que la Las partes interesadas internas y externas deben Implementado Estrategia de
calidad y valor seguridad de la comprometerse a sostener una comunicación seguridad de la
a las partes información periódica de modo que se sigan cumpliendo sus información
interesadas. ofrezca valor y requerimientos cambiantes de seguridad de la
satisfaga los información. Promover el valor de la seguridad de
requerimientos la información (tanto financiera como no
del negocio. 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.
Volumen 1, enero de 2014 Página 2

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 Garantizar que Se deben identificar las obligaciones de Implementado Estado de
requerimientos se cumplan las cumplimiento, se las debe traducir en cumplimiento de
legales y obligaciones requerimientos específicos de seguridad de la PCI, estado de
regulatorios legales, que se información y comunicar a las personas que cumplimiento de
relevantes. gestionen las corresponda. Las sanciones asociadas al ISO 27001
expectativas de incumplimiento deben ser claramente
las partes comprendidas. Los controles deben ser
interesadas, y monitoreados, analizados y actualizados de modo
que se eviten que cumplan con los requerimientos legales y
sanciones civiles regulatorios nuevos o actualizados.
o penales.
Proporcionar Brindar apoyo a Los requerimientos para la entrega de datos sobre Implementado Informe mensual de
datos exactos los el desempeño de la seguridad de la información gestión de la
y oportunos requerimientos deben estar claramente definidos y sustentados seguridad de la
sobre el del negocio y con las métricas más relevantes y adecuadas (por información
desempeño de gestionar el ejemplo, cumplimiento, incidentes, estado de
la seguridad riesgo de la control y costos) y alineados con los objetivos del
de la información. negocio. La información debe obtenerse de
información. 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.
Evaluar las Analizar y Las tendencias más importantes y las amenazas Implementado Revisión y pruebas
amenazas evaluar las específicas a la seguridad de la información se periódicas a la
actuales y amenazas deben categorizar en un marco integral estándar seguridad.
futuras hacia emergentes de que abarque un amplio espectro de temas como,
la información. seguridad de la por ejemplo, aspectos políticos, legales,
información de económicos, socioculturales y técnicos. Las
modo que se personas deben compartir y profundizar sus
pueda adoptar conocimientos sobre las amenazas venideras a fin
acciones de abordar proactivamente sus causas, en lugar
oportunas e de sus síntomas.
informadas para
mitigar el riesgo.
Promover la Reducir los Los modelos de negocio organizacionales en Implementado Indicadores clave
mejora costos, mejorar constante cambio, junto con las amenazas en de desempeño;
continua en la eficacia y la evolución, exigen la adaptación de técnicas de informes mensuales
seguridad de eficiencia, y seguridad de la información y la mejora continua y anuales de
la información. promover una de su nivel de eficacia. Se debe mantener el gestión
cultura de conocimiento sobre las técnicas de seguridad de
mejora continua la información más recientes aprendiendo de los
en seguridad de incidentes y vinculándose con organizaciones de
la información. investigación independientes.

2. Defender el negocio.
Adoptar un Garantizar que el Se deben examinar las opciones para abordar el Implementado Sistema de gestión
enfoque riesgo sea riesgo vinculado con la información de modo que de seguridad de la
basado en el tratado de una se puedan tomar decisiones fundamentadas y información
riesgo. manera documentadas sobre el tratamiento del riesgo. El (information security
consistente y tratamiento del riesgo implica elegir una o más management
eficaz. opciones, que habitualmente incluyen: system, ISMS) y
• Aceptar el riesgo (un integrante de la dirección evaluación de
debe aprobar que ha aceptado el riesgo y que riesgos de
no se requiere ninguna otra acción). cumplimiento de
• Evitar el riesgo (p. ej., decidiendo que no se PCI.
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).
Proteger Evitar la La información se debe identificar y, a Implementado Políticas y
información divulgación de continuación, clasificar de acuerdo con su nivel de estándares de
clasificada. información confidencialidad (p. ej., secreta, restringida, seguridad de la
clasificada (p. interna, pública). La información confidencial se información
ej., confidencial debe proteger del mismo modo en todas las
o sensible) a etapas de su ciclo de vida —a partir de la creación
personas no y hasta su destrucción— empleando los controles
autorizadas. que correspondan, como la encriptación y las
restricciones de acceso.
Concentrarse Priorizar la Comprender el impacto en la empresa que Implementado Políticas y

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

Desarrollar Desarrollar La seguridad de la información debe ser integral Implementado Estándares de
sistemas sistemas de para las fases de alcance, diseño, desarrollo y seguridad de la
seguros. calidad y prueba del ciclo de vida de desarrollo de sistemas información
económicos en (system development life cycle, SDLC). Las
los cuales se buenas prácticas de seguridad de la información
pueda confiar (es (p. ej., la prueba rigurosa de debilidades en cuanto
decir, que sean a la seguridad de la información; la revisión entre
consistentemente pares; y la capacidad de lidiar con errores,
robustos, excepciones y condiciones de emergencia) deben
precisos y tener un rol fundamental en todas las etapas del
confiables). proceso de desarrollo.
3. Promover un comportamiento responsable respecto de la seguridad de la información.
Actuar de una Asegurarse de que las La seguridad de la información se basa Implementado Verificaciones de
manera actividades marcadamente en la capacidad de los antecedentes
profesional y relacionadas con la profesionales de una industria para
ética. seguridad de la desempeñar sus funciones con responsabilidad
información se realicen y con un claro entendimiento del modo en que
de manera confiable, su integridad impactará directamente sobre la
responsable y eficiente. 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).
Promover una Ejercer una influencia Se debe hacer énfasis en lograr que la Implementado Reuniones del
cultura positiva positiva respecto de la seguridad de la información sea una pieza comité de
respecto de la seguridad de la clave de la empresa y que los usuarios se gobierno de
seguridad de información sobre el concienticen cada vez más sobre la seguridad de la
la información. comportamiento de los seguridad de la información, y en garantizar información
usuarios finales, reducir que estos tengan las destrezas necesarias (information
la probabilidad de que para proteger la información clasificada o security
ocurran incidentes de crítica y los sistemas. Las personas deben governance
seguridad de la reconocer el riesgo que corre la información committee, ISGC).
información y limitar su que tienen en su poder y deben estar
posible impacto en la facultados para tomar las medidas que sean
empresa. necesarias para protegerla.
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.
Figura 1: Marco de gobierno de HDFC Bank
6. Los
servicios, la
infraestruct
ura y las
aplicacione
s incluyen la
infraestructur
a, la
tecnología y
las
aplicaciones
que brindan
a la empresa
servicios y
procesamien
tos de TI.
7. Las
personas,
habilidades
y
competenci
as están
vinculadas a
las personas
y son
requeridas Fuente: HDFC Bank. Reimpreso con autorización.
para la
finalización
exitosa de Figura 2: Roles y responsabilidades del ISG
todas las Tareas de seguridad de la Seguridad TI Operaciones Negocio Jurídico Auditoría RR. HH. Dirigentes
actividades y información de la Funcionales
para tomar información
decisiones Gobierno A/R C C C C R C
correctas y Políticas, procesos y
A/R C C I C C C
aplicar estándares
medidas Estrategia A/R C C C I C I
correctivas. Evaluación de riesgos -
A/R I I I C I
definición
Estructuras Evaluación de riesgo -
C R R R C A
ejecución
organizacional Gestión de seguridad de la
R/C R R R R R R A/R
es información
Las estructuras Arquitectura de seguridad A/R R C
organizacionales Tecnología de la seguridad C A/R C
son las entidades Ingeniería de la seguridad C A/R C
clave de toma de
Desarrollo seguro C A/R C
decisiones en
una empresa. Operaciones y entrega de
A R R C
servicios
La seguridad de Gestión de proyectos A/R R I I C
la información en
Auditoría, revisión y monitoreo R/C R I I I A/R I
HDFC Bank está
impulsada por su Respuesta a incidentes A/R R R I C C I
grupo de Entorno legal y normativo A/R I I I R R I
seguridad de la Conocimiento, educación y
información A/R I I I I C R
capacitación
(information Fuente: HDFC Bank. Reimpreso con autorización.

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 Figura 3: Gobierno para la implementación
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 Procedimientos, controles técnicos
Política, procesos, estándares
dirigentes funcionales.
En la figura 3, se
proporciona el marco
general de gobierno para
la implementación.
21 componentes
Los 21 componentes se
Seguridad de la aplicación, criptografía, monitoreo, gestión de incidentes, seguridad
monitorean
bancaria en línea, gestión de software malicioso (malware), protección de datos,
permanentemente hasta
ciclo de vida de desarrollo de software seguro, planificación de continuidad del
alcanzar un nivel de
madurez. La asignación negocio, privacidad, gestión de acceso y de identidad, gestión de riesgos...
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

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 Figura 4: Cascada de metas de COBIT 5
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 Fuente: ISACA, COBIT 5, EE. UU., 2012
individuales. Este enfoque hace que los equipos se mantengan

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.
Figura 5: Factores conductores de partes interesadas de HDFC Bank
Fuente: HDFC Bank. Reimpreso con autorización.
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

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.
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 Política publicada e Revisión y mejora continuas de la
definida y publicada implementada de manera política
uniforme
Roles y Roles y Roles parcialmente Roles y Roles y responsabilidades Roles y responsabilidades
responsabilidades responsabilidades definidos responsabilidades definidos y ejecutados revisados de manera continua
no definidos bien determinados y
definidos
Automatización Manual Semiautomatizada Automatizada Automatizada y Actualización permanente de la
completamente operativa 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 Sin seguimiento Visibilidad limitada Seguimiento de Seguimiento y cierre de RCA aplicado a todos los
incidentes incidentes críticos todos los incidentes incidentes y solucionados
Medición Sin medición Medición limitada Mediciones Medido y revisado de forma Criterios de medición revisados
integrales definidas periódica periódicamente
Informes Sin informes Informes limitados Informes definidos Informes enviados a la alta Requerimientos de informes
dirección y revisados periódicamente revisados y
actualizados
Fuente: HDFC Bank. Reimpreso con autorización.
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

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 Figura 7: Diez mandamientos de HDFC Bank
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

implementación.
Actualización de
Cultura, ética y comportamiento búsqueda
La cultura, la ética y el comportamiento de individuos y de la empresa son, a menudo, Materiales de COBIT 5
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.
recientemente publicados
COBIT® 5: Información
COBIT 5 ha identificado ocho clases de comportamientos que contribuyen con el desarrollo Habilitadora
de una cultura de seguridad en una organización. Varias iniciativas tomadas por HDFC Publicaciones de COBIT 5 del
primer trimestre de 2014 - Próxima
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 aparición
ejemplo, por medio de un certificado, y a través de mensajes contundentes a quienes no • Escenarios de riesgo para
demuestren tal conducta. El comportamiento seguro está fuertemente influenciado por la COBIT 5®
concientización.
Otras iniciativas de COBIT 5 en
Las ocho clases de comportamientos se indican a continuación a modo de referencia junto desarrollo
con las medidas específicas adoptadas por HDFC Bank para arraigar estas conductas a la
• COBIT® 5 en línea: Acceso
práctica diaria de los empleados del banco:
a las publicaciones de la
• La seguridad de la información se practica en las operaciones diarias. La dirección
familia de productos COBIT
de HDFC Bank ha transmitido sus expectativas hacia los empleados destacando el
principio de tolerancia cero en lo que respecta a comportamientos inaceptables
5 y a otro contenido de
relacionados con la seguridad de la información, premio al buen comportamiento,
ISACA no relacionado con
reconocimiento y recompensa para las personas que trabajan correctamente en la COBIT, y a material de GEIT
gestión de riesgos, y recordatorios permanentes del lema “Security is incomplete without actual y relevante
U” (La segUridad está incompleta sin Usted). De esta manera, se ha garantizado la (publicación tentativa
práctica de seguridad de la información en las operaciones diarias. segundo trimestre de 2014)
• Las personas respetan la importancia de las políticas y los principios de • COBIT® 5 para Sarbanes-
seguridad de la información. La cultura de la seguridad se ha gestado a través de Oxley (publicación
constantes esfuerzos por crear conciencia al respecto. Ahora los empleados tentativa segundo
comprenden la importancia de la seguridad de la información y toman las iniciativas trimestre de 2014)
afines con absoluta seriedad. La auditoría también ha tenido un rol importante para • Controles y aseguramiento
hacer cumplir las políticas y los principios de seguridad. en la nube: Utilizando
• Las personas reciben guías suficientes y pormenorizadas de seguridad de la COBIT® 5 (publicación
información y se les motiva a participar y retar la situación actual de la seguridad tentativa segundo
de la información. HDFC Bank cree que todas las partes interesadas deben trimestre de 2014)
comprometerse con los esfuerzos de seguridad. La introducción de cualquier proceso • COBIT 5 en línea:
nuevo implica asegurar una interacción abierta con todas las partes afectadas. Los Habilidad para
temas se debaten en talleres y la aprobación se obtiene por medio de un diálogo de dos personalizar a COBIT para
canales, de modo que todos tengan la posibilidad de aclarar las dudas que surjan. Se que se adapte a las
proporciona capacitación extensiva para cada iniciativa nueva de seguridad de la necesidades de su
información, no exclusivamente al grupo que trabaja con la seguridad de la información, empresa con acceso a
sino a todas las partes interesadas. varios usuarios
• Todos deben rendir cuentas sobre la protección de la información dentro de la (publicación tentativa
empresa. El grupo de seguridad de la información es responsable de identificar y tercer trimestre de 2014)
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 Si desea obtener más
analizada previamente. De esta forma, todas las partes interesadas se sienten información sobre las
responsables así como también sienten que deben rendir cuentas sobre la protección publicaciones de COBIT, visite
de la información dentro de la empresa. la página de COBIT 5 en el
• Las partes interesadas son conscientes de cómo identificar y responder a amenazas sitio web de ISACA.
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 Dispone de traducciones de
mensaje por correo electrónico al ISG sobre correo basura o mal intencionado (phishing) COBIT 5 en la página COBIT
que hayan recibido. La respuesta recibida a diario por el ISG da cuenta de la enorme Product family (Familia de
conciencia que todos han desarrollado para identificar y comunicar incidentes. Productos de COBIT).

• 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
1
el cumplimiento del PCI DSS. 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.
Figura 1: Tópicos y requerimientos de PCI DSS 3.0 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)
2
en relación con la cantidad de transacciones afectadas en un período de 12 meses. 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,
3
AOC).
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 2: Modelo de referencia de procesos de COBIT 5
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,
4
orientación y requerimientos avanzados. 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
5
recursos. 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
6
(figura 2).
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 APO01.08 Mantener el cumplimiento de políticas y procedimientos.
configuración de firewall para proteger APO03.02 Definir la arquitectura de referencia.
los datos de los titulares de tarjetas.
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.

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 APO01.08 Mantener el cumplimiento de políticas y procedimientos.
predeterminados (default) APO03.02 Definir la arquitectura de referencia.
suministrados por el proveedor en las
contraseñas del sistema y demás BAI03.03 Desarrollar los componentes de la solución.
parámetros de seguridad. BAI03.10 Mantener soluciones.
DSS04.08 Ejecutar revisiones post-reanudación.
DSS05.03 Gestionar la seguridad de los puntos de destino.
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
3. Protección de datos de titulares APO01.06 Definir la propiedad de la información (datos) y del sistema.
de tarjetas almacenados. 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.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 APO11.02 Definir y gestionar los estándares, procedimientos y prácticas de calidad.
de titulares de tarjetas por redes APO11.05 Integrar la gestión de la calidad en soluciones para el desarrollo y la
públicas abiertas. entrega de servicios.
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.
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
5. Usar y actualizar periódicamente los APO12.01 Recopilar datos.
programas o software antivirus. APO12.03 Mantener un perfil de riesgo.
6. Desarrollar y mantener sistemas y APO12.02 Analizar el riesgo.
aplicaciones seguras. APO12.04 Expresar el riesgo.
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).
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
7. Restringir el acceso a datos de titulares de DSS05.04 Gestionar la identidad del usuario y el acceso lógico.
tarjetas por medio de la necesidad de conocer
(need-to-know) del negocio.
8. Asignar una ID única a cada persona con acceso APO03.02 Definir la arquitectura de referencia.
a la computadora. APO07.01 Mantener una dotación de personal suficiente y adecuada.
9. Restringir el acceso físico a los datos de titulares APO01.06 Definir la propiedad de la información (datos) y del sistema.
de tarjetas. DSS05.04 Gestionar la identidad del usuario y el acceso lógico.
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
10. Hacer seguimiento y monitorear todos los DSS01.01 Ejecutar procedimientos operativos.
accesos a los recursos de red y datos de titulares DSS01.03 Monitorear la infraestructura de TI.
de tarjetas.
DSS04.08 Ejecutar revisiones post- reanudación.

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 APO03.02 Definir la arquitectura de referencia.
de seguridad. 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
12. Mantener una política que aborda la seguridad APO01.01 Definir la estructura organizativa.
de la información para todo el personal. 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
1
objetivos de la empresa".

¿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.

Notas finales
1 ISACA, Glosario
COBIT Focus es una publicación de ISACA. Las Comité de marco

opiniones expresadas en COBIT Focus
Steven A. Babb, CGEIT, CRISC, ITIL, UK, Director
representan los puntos de vista de los autores.
David Cau, ITIL, MSP, Prince2, Francia
Pueden diferir de las políticas y declaraciones
Sushil Chatterji, CGEIT, Singapur
oficiales de ISACA y sus comités, y de las
Frank Cindrich, CGEIT, CIPP, CIPP/G, EE. UU.
opiniones refrendadas por autores, empleados o Joanne De Vito De Palma, EE. UU.
editores de COBIT Focus. COBIT Focus no
Jimmy Heschl, CISA, CISM, CGEIT, ITIL, Austria
avala la originalidad del contenido de los
Katherine McIntosh, CISA, EE. UU.
autores.
Andre Pitkowski, CGEIT, CRISC, OCTAVE, Brasil
© ISACA. Todos los derechos reservados. Paras Shah, CISA, CGEIT, CRISC, CA, Australia
Los instructores pueden fotocopiar artículos Contenido editorial

aislados sin cargo para uso no comercial en las Los comentarios relacionados con el contenido editorial pueden
aulas de clase. Para otras copias, reimpresiones o remitirse a Jennifer Hajigeorgiou, gerente sénior de redacción, al
nuevas publicaciones, se debe obtener el permiso correo electrónico jhajigeorgiou@isaca.org.
por escrito de la asociación. Comuníquese con
Julia Fullerton por correo electrónico a
jfullerton@isaca.org.
©2014 ISACA. Todos los derechos reservados.

Vsipinfo A1 Caso Ejemplo Cobit

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Vsipinfo A1 Caso Ejemplo Cobit

Cargado por

Copyright:

Formatos disponibles

Volumen 1, enero de 2014

Banco de Medio Oriente mejora la seguridad Convocatoria para

Principios de seguridad de la información

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

Volumen 1, enero de 2014 Página 2

Volumen 1, enero de 2014 Página 3

Concentrarse Priorizar la Comprender el impacto en la empresa que Implementado Políticas y

Volumen 1, enero de 2014 Página 4

Beneficios de la implementación de COBIT 5

Volumen 1, enero de 2014 Página 5

Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2

Gestión de seguridad de la información en HDFC Bank:

Volumen 1, enero de 2014 Página 7

Principios, políticas y marcos

Volumen 1, enero de 2014 Página 8

Volumen 1, enero de 2014 Página 9

Figura 5: Factores conductores de partes interesadas de HDFC Bank

Fuente: HDFC Bank. Reimpreso con autorización.

Niveles de madurez de la seguridad de la información

Volumen 1, enero de 2014 Página 10

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

Inicial En desarrollo Definido Gestionado Optimizado

Fuente: HDFC Bank. Reimpreso con autorización.

Servicios, infraestructura y aplicaciones

Volumen 1, enero de 2014 Página 11

Personas, habilidades y competencias

Volumen 1, enero de 2014 Página 12

Volumen 1, enero de 2014 Página 13

Soportando el cumplimiento de PCI DSS 3.0 con COBIT 5

PCI DSS 3.0

Volumen 1, enero de 2014 Página 14

Volumen 1, enero de 2014 Página 15

Figura 3: Procesos de red

Volumen 1, enero de 2014 Página 16

Volumen 1, enero de 2014 Página 17

Volumen 1, enero de 2014 Página 18

Volumen 1, enero de 2014 Página 19

Volumen 1, enero de 2014 Página 20

Desarrollo de un marco de gobierno para la organización de soporte

Volumen 1, enero de 2014 Página 21

Volumen 1, enero de 2014 Página 22

Volumen 1, enero de 2014 Página 23

COBIT Focus es una publicación de ISACA. Las Comité de marco

Los instructores pueden fotocopiar artículos Contenido editorial

©2014 ISACA. Todos los derechos reservados.

Volumen 1, enero de 2014 Página 24

También podría gustarte