Revista de Ingeniera

ISSN: 0121-4993
reingeri@uniandes.edu.co
Universidad de Los Andes
Colombia

Gmez, Ricardo; Prez, Diego Hernn; Donoso, Yezid; Herrera, Andrea

Metodologa y gobierno de la gestin de riesgos de tecnologas de la informacin
Revista de Ingeniera, nm. 31, enero-junio, 2010, pp. 109-118
Universidad de Los Andes
Bogot, Colombia

Disponible en: http://www.redalyc.org/articulo.oa?id=121015012006

Cmo citar el artculo

Nmero completo
Sistema de Informacin Cientfica
Ms informacin del artculo Red de Revistas Cientficas de Amrica Latina, el Caribe, Espaa y Portugal
Pgina de la revista en redalyc.org Proyecto acadmico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto
 Metodologa y gobierno de la gestin de
riesgos de tecnologas de la informacin
10
Methodology and Governance of the IT Risk Management doss

Ricardo Gmeza, Diego Hernn Prezb, Yezid Donosoc, Andrea Herrerad

PALABRAS CLAVES KEY WORDS

Amenazas en TI, anlisis de riesgos, continuidad de Business continuity, IT governance, risk analysis,
negocios, gobernabilidad de TI, Vulnerabilidad. vulnerability and threat in IT.

RESUMEN
Las organizaciones cada vez son ms conscientes de los
impactos que les pueden generar los riesgos referen-
tes a las Tecnologas de Informacin (TI). Es frecuente
que empresas de diversos sectores econmicos reporten
 
ABSTRACT
The organizations are more interested in the impact
that can generate risk and in particular associated to
IT. Every day it is possible to see that different business
 

 
  

prdidas debido a fallas y/o ataques sobre sus servicios among others, they are reporting economical lost due
de TI, los cuales afectan seriamente su reputacin y su to fails or attacks over theirs IT services, which can affect


  
    - the reputation, relationships with the clients and their
damentales para realizar el anlisis de riesgos: los estn- 

      
dares y normas, de un lado, y las metodologas, de otro;
estos pilares por s solos no aseguran el xito si no se
articulan adecuadamente. En este artculo mostramos
qu tipo de estndares y normas se deben considerar al
realizar un anlisis de riesgos, posteriormente explica-
mos cmo utilizar una metodologa y cmo articularla
en el proceso de gobernabilidad de TI para desarrollar
en forma exitosa este tipo de iniciativas.
fundamental pillars for the risk analysis: standards and
norms and the other side the methodologies; with these
pillars along is impossible to assure the results without
the governability of this risk analysis. In this paper, we
show what kind of standards and legal documents must
be considered in a risk assessment process and after we
are going to explain how is possible to use a methodo-
logy and how to connect this methodology with the IT
governance process in a successful way.

a Ingeniero de Sistemas y Computacin. Ingeniero de Proyectos CIFI Informtica. Facultad de Ingeniera. Universidad de los Andes.
Bogot D.C., Colombia.

ricgomez@uniandes.edu.co
b Ingeniero industrial, Especialista en sistemas de informacin. Consultor en temas de estrategia y procesos de TI. Profesor catedrti-
co. Facultad de Ingeniera. Universidad de los Andes. Bogot D.C., Colombia.

perezdiegohernan@yahoo.com
c Ph.D. en Tecnologas de Informacin. Profesor Asociado, Departamento de Ingeniera de Sistemas y Computacin. Grupo COMIT.
Facultad de Ingeniera. Universidad de los Andes. Bogot D.C., Colombia.

ydonoso@uniandes.edu.co
d M.Sc. Magster en Ingeniera de Sistemas y Computacin. Instructora, Departamento de Ingeniera de Sistemas y Computacin.
Grupo TION. Facultad de Ingeniera. Universidad de los Andes. Bogot D.C., Colombia.

a-herrer@uniandes.edu.co
110 INTRODUCCIN
Las organizaciones son cada vez ms conscientes de
lo que significan los riesgos informticos y, sobre
todo, han aprendido que en la mayora de los casos
debern coexistir con ellos pero en forma contro-
lada. Debido a tantos efectos negativos que se han
visto en las organizaciones por las amenazas sobre
los servicios de TI, aqullas han comenzado a exigir,
dentro de sus funciones normales internas, un anlisis
de riesgo y un plan de mitigacin; as mismo, han en-
tendido que siempre quedar un riesgo remanente y
latente en sus procesos de misin crtica. Tambin es
importante mencionar que nuestras ciudades cada vez
hacen mayor uso de las tecnologas de la informacin
para ser ms eficaces y efectivas, con el fin de lograr
el cumplimiento de su desarrollo y de sus polticas de
seguridad; es por esta razn que el anlisis y entendi-
miento de los riesgos de TI involucran directamente
a las ciudades; adems, los riesgos de TI forman parte
de los riesgos que cualquier dirigente debe tener en
cuenta en su gobierno.
Es conocido por todos que el tratamiento del riesgo
puede estar enfocado de cuatro formas tradicional-
mente: establecer controles para mitigarlos, aceptar el
riesgo tal y como est porque es imposible establecer
controles, eliminar el riesgo quitando los procesos
del negocio que los generan y, finalmente, trasladar
el riesgo a un tercero; por ejemplo, a travs de se-
guros. Establecer controles significa la generacin de
polticas, normas y procedimientos que conlleven a la
mitigacin del riesgo; por supuesto, en el caso de TI,
generalmente conlleva al final a la configuracin de
estas polticas en diferentes procedimientos, equipos
de hardware, aplicaciones, sistemas operativos, entre
otros. Por su parte, aceptar el riesgo significa que la
empresa asume y conoce perfectamente cul sera el
impacto en el negocio si este riesgo se materializa.
Por otro lado, en la mayora de los casos, eliminar
los procesos que conllevan al riesgo significara cam-
biar el quehacer (negocio) de la organizacin y, por
supuesto, tradicionalmente la organizacin no permi-
tir que esto suceda. Por ltimo, est el traslado del
riesgo a travs de plizas, figura muy utilizada por las
compaas; en este caso, es necesario tener muy claro
cul sera la probabilidad de que este riesgo se lleve a
cabo, para realizar un balance entre el costo y el be-
neficio de tener ese seguro. Respecto a esta estrategia
hay que ser consciente de que est muy relacionada
con el cubrimiento econmico de la materializacin
de un riesgo, porque quien deber asumir el impacto
en trminos de imagen y de relacin con sus interesa-
dos ser la organizacin.
Para tomar la decisin sobre qu tipo de estrategia
utilizar, se hace necesario realizar un anlisis de cada
riesgo para conocer y cuantificar el impacto de que
el riesgo se lleve a cabo, as como su probabilidad
de ocurrencia. Ahora, estas decisiones de qu hacer
con los riesgos deben estar alineadas con el esque-
ma estratgico de la organizacin; esto significa que
el gobierno de TI es una pieza clave dentro de este
proceso, para asegurar la pertinencia y el xito de las
decisiones que se tomen respecto a los riesgos.
Observando las necesidades que las organizaciones tie-
nen hoy en da en cuanto a los riesgos de TI, es que
hemos decidido presentar este artculo, el cual se ha en-
focado primero en mostrar un marco de referencia en
cuanto a estndares, normas, reglamentaciones, entre
otros, relevantes al anlisis de riesgos. Como segundo
enfoque mostramos una metodologa comprobada con
casos de xitos a nivel internacional, sobre cmo llevar
a cabo un anlisis de riesgos. Finalizamos nuestro art-
culo mostrando los aspectos ms relevantes del gobier-
no de TI respecto a la gestin de los riesgos.
ORGENES DE LA REGULACIN Y SU PAPEL
EN LA FORMALIZACIN DE LA GESTIN DE
RIESGOS DE TI
El riesgo ha existido inherente a cada accin que rea-
liza el ser humano. Sin embargo, en la sociedad actual,
inmersa en un ambiente altamente tecnolgico y don-
de la informacin es el centro de las actividades, se
ha desarrollando una creciente dependencia de las TI
lo que las ha convertido en un gran factor de riesgo

y quizs, uno de los ms importantes de este siglo.
Por supuesto, las empresas no han sido ajenas a este
proceso porque, al apoyarse en TI para mejorar su
eficiencia y productividad, entregan a stas una buena
porcin de responsabilidades crticas para el negocio.
Pero, como es bien sabido, no existe tecnologa per-
fecta; todas presentan deficiencias, vulnerabilidades,
errores, entre otros. Adems, si los procesos de nego-
cio dependen de TI, el riesgo incrementa y ms an
si esta tecnologa es utilizada por personas en el desa-
rrollo de dichos procesos. Lo anterior genera lo que
se conoce como riesgo de TI; es necesario gestionar
estos riesgos porque no hacerlo puede generar altos
costos para la organizacin [1].
Algunas empresas han vivido experiencias realmente
complejas que han demostrado la necesidad de hacer
dicha gestin: el caso de Comair, una empresa subsi-
diaria de Delta Air Lines, resalta algunas consecuen-
cias de la materializacin del riesgo de TI. En diciem-
bre de 2004, Comair experiment un incidente con su
sistema de planeacin de horarios para tripulaciones
[2]. Este sistema, de misin crtica para la operacin
del negocio, dej de funcionar el 24 de diciembre y
caus una interrupcin total de sus vuelos, dejando
prdidas equivalentes a las utilidades operativas de
todo un trimestre. Otro caso es el de CardSystems
Solutions Inc., procesadora de tarjetas de crdito. A
mediados del 2005 report que individuos descono-
cidos obtuvieron acceso a las transacciones de 40 mi-
llones de tarjetahabientes. Visa y Mastercard, clientes
de CardSystems, cancelaron su negocio con la empre-
sa, que luego fue vendida [2]. Un caso colombiano
muy reciente, dado a finales de febrero de 2010, fue
el que afect a los clientes de un banco reconocido,
quienes tras una falla originada por la saturacin de
una de las aplicaciones visualizaron inconsistencias
en la actualizacin de sus saldos; afortunadamente,
en ningn momento se afectaron realmente los saldos
de las cuentas, sin embargo, la institucin financie-
ra tuvo que activar sus contingencias para minimizar
1 Large Hadron Collider (LHC) es el acelerador de partculas ms grande del mundo, ubicado en Conseil Europen pour la
Recherche Nuclaire (CERN).
dossier
# 31 revista de ingeniera
el impacto de la falla tecnolgica [3]. Finalmente, se 11
puede presentar el caso del LHC1 de CERN. Este ace-
lerador de partculas, catalogado como el ms grande
del mundo, intenta recrear condiciones similares a las
del Big-Bang mediante altas energas; por lo tanto,
sus experimentos deben ser minuciosamente contro-
lados. Sin embargo, el 10 de septiembre de 2008 un
grupo de hackers ingres a uno de los sistemas del
LHC y modific su sitio web. Favorablemente, el ata-
que no tuvo intenciones maliciosas y colabor con
identificar vulnerabilidades del sistema. La intrusin,
de haber sido mal intencionada, no slo pudo haber
causado daos en los modernos instrumentos del la-
boratorio sino que tambin pudo haber causando una
catstrofe. Ojal todos los negocios tuvieran la suer-
te de CERN! No obstante, ste es un caso muy poco
comn y la materializacin de los riesgos de TI suelen
terminar en un desastroso Big-Bang [4].
Estas organizaciones tuvieron algo en comn: la in-
apropiada gestin de riesgos de TI. Su efecto, no obs-
tante se extendi desde TI hasta afectar directamente
la operacin y la misin del negocio: se manifest el
riesgo de TI como riesgo corporativo, haciendo que su
inters sea igualmente corporativo y no un problema
limitado estrictamente al rea de TI. Pero, la creciente
dependencia en las TI no es slo un riesgo para los
negocios, tambin se est convirtiendo en una amenaza
para pases enteros. El caso de India, un pas que ha
desarrollado de manera notable su industria del soft-
ware, se encuentra en el dilema de la dependencia en
soluciones TI. Este pas ha implementado innume-
rables soluciones de TI para apoyar activos guberna-
mentales como (plantas nucleares, servicios pblicos
domiciliarios, grandes centros de manufactura y pro-
piedades pblicas y privadas, entre otros) lo cual con-
lleva a que exista un alto riesgo de ataques terroristas
a travs de vulnerabilidades de los sistemas de TI co-
rrespondientes. Tan es as, que el gobierno y muchas
empresas indias se encuentran en constantes discusio-
nes para tomar medidas preventivas [5]. Este riesgo no
112 ser un problema slo de la India; muchos otros pases
entrarn, en mayor o menor medida, en los niveles de
implementacin de soluciones de TI de los pases ms
desarrollados, por tanto, se presentar de igual manera
este grave riesgo para la seguridad nacional.
Debido a lo mencionado anteriormente, los gobier-
nos han establecido estrictas reglamentaciones y re-
gulaciones que buscan minimizar los riesgos opera-
tivos, muchos de stos asociados con las TI de las
compaas. Se han creado mecanismos que permiten
regular la actividad, fijar los criterios tcnicos y jur-
dicos que faciliten el cumplimiento de dichas leyes,
normas y circulares. Ejemplos de estas regulaciones
son abundantes y especificas por sector y no se pre-
tende ahondar en ellas; no obstante, queda claro que
adicionalmente a los beneficios que puede traer una
adecuada gestin de los riesgos de TI para una com-
paa, nace la necesidad del cumplimiento.
A raz de lo anterior, surge la necesidad de crear es-
tndares para el anlisis y gestin de riesgos; stos se
conocen comnmente como Frameworks o Marcos de
Trabajo [6]. Entre los marcos de gestin de riesgos de
TI ms conocidos se encuentran los siguientes: NIST
[7], IT Risk [2], Risk IT [8], Octave [9], Magerit [10],
entre otros. El objetivo de estos marcos es el de in-
tegrar buenas prcticas mundialmente reconocidas de
forma ordenada y sistemtica. Estos marcos estn di-
seados para facilitar el anlisis de riesgos y orientan
en la implantacin de un sistema de gestin de riesgos.
UNA METODOLOGA PARA EL ANLISIS DE
RIESGOS DE TI
El hecho de conocer los marcos de referencias para
el anlisis de riesgo no asegura que el proceso se lleve
a cabo en forma exitosa. Es por esto que se requie-
re adicionalmente de una metodologa que, en forma
eficaz y eficiente, aplique los marcos de referencias
exitosamente en la labor del anlisis de riesgos de TI.
2 El CERT es un centro de investigacin en seguridad en Internet del Software Engineering Institute (SEI) de la Universidad
de Carnegie Mellon.
Lo anterior conlleva a que se identifiquen y prioricen
exhaustivamente los diferentes riesgos para definir
planes de accin y de proteccin, acordes con cada
uno. La labor en general no es una tarea fcil, ya que
involucra un estudio detallado de todas las reas de
la organizacin y un anlisis crtico que garantice la
adecuada identificacin y priorizacin de los riesgos y
vulnerabilidades. Se hace necesario, entonces, contar
con metodologas que faciliten el logro de estos obje-
tivos de altos volmenes de informacin.
OCTAVE (Operationally Critical Threat, Asset and
Vulnerability Evaluation) [9] es una metodologa de-
sarrollada por el CERT/CC2 [11, 12] que tiene por
objeto facilitar la evaluacin de riesgos en una orga-
nizacin. En esta parte del artculo, presentaremos
una visin general de OCTAVE y mostraremos de
manera global el modo cmo se desarrolla.
PRINCIPALES CARACTERSTICAS
OCTAVE se centra en el estudio de riesgos organi-
zacionales [13] y se focaliza principalmente en los as-
pectos relacionados con el da a da de las empresas.
La evaluacin inicia a partir de la identificacin de los
activos relacionados con la informacin, definiendo
este concepto como los elementos de TI que repre-
sentan valor para la empresa (sistemas de informa-
cin, software, archivos fsicos o magnticos, perso-
nas, entre otros). De esta forma, OCTAVE estudia
la infraestructura de informacin y, ms importante
an, la manera como dicha infraestructura se usa en
el da a da. En OCTAVE se considera que, con el fin
de que una organizacin pueda cumplir su misin, los
empleados a todo nivel necesitan entender qu acti-
vos relacionados con la informacin son importantes
y cmo deben protegerlos; para ello, es fundamental
que en la evaluacin estn directamente involucradas
personas de diferente nivel de la organizacin.
OCTAVE es un estudio auto dirigido, desarrollado
por un equipo interdisciplinario llamado el equipo de

anlisis, el cual se compone de personas de las reas de
negocio y del rea de TI. Esta composicin se explica
con el hecho de que los funcionarios del negocio son
los ms indicados para identificar qu informacin es
importante en los procesos del da a da y cmo se usa
dicha informacin; por su parte, son las personas del
rea de TI las que conocen los detalles de configura-
cin de la infraestructura y las debilidades que puede
tener. Estos dos puntos de vista son importantes para
dossier
# 31 revista de ingeniera
equipo evala la informacin y selecciona los activos 11
ms importantes. A continuacin, se describen los re-
querimientos de seguridad y se crea un perfil de amenazas
para cada activo crtico.
La fase 1 se desarrolla en cuatro etapas. Las tres pri-
meras son talleres realizados a diferentes niveles de la
organizacin: directivo, gerencial, operativo y de TI.
En cada uno de estos talleres se desarrollan actividades
 
 

 
 -
tener una visin global de los riesgos de seguridad de

 
   
 
los servicios de TI.
sobre cada uno de ellos, el impacto que tienen dichas
El equipo de anlisis debe identificar los activos re- amenazas sobre los mismos y sobre la organizacin, y
lacionados con la informacin que son de importan- los requerimientos de seguridad de cada activo.
cia para la organizacin, entendiendo esta importan-
En la cuarta etapa se consolida la informacin reco-
cia en trminos de que se garantice la continuidad
lectada en las etapas 1 a 3, verificando aspectos como
de operacin. El anlisis se focaliza sobre los activos
la completitud, coherencia y diferencias de aprecia-
que se identifican como crticos y la identificacin del
cin en los diferentes niveles de la organizacin. La
modo en que se relacionan dichos activos entre s, las
informacin se analiza y se organiza segn las amena-
amenazas a las que estn expuestos y las vulnerabili-
zas que se presentan para cada activo. Los talleres que
dades (organizacionales y tecnolgicas). El estudio se
se desarrollan en estas fases giran en torno a discusio-
hace desde un punto de vista operacional, se verifica
nes dirigidas, a formatos preestablecidos que se dili-
cmo se usan los diferentes activos y cmo pueden
gencian durante cada taller y a encuestas de prcticas
estar en riesgo debido a amenazas de seguridad. Fi-
de seguridad en la organizacin; todos ellos con guas
nalmente, se define una estrategia basada en prcticas
de manejo que tiene la metodologa.
para el mejoramiento organizacional y un plan de mi-
tigacin para reducir el riesgo al que est expuesta la Como resultado de esta fase se tendrn, entre otros,
organizacin. los siguientes productos:

         -

DESARROLLO DE LA EVALUACIN
nados con la informacin que son de mayor cri-
OCTAVE se desarrolla mediante una serie de talleres
ticidad para la operacin y subsistencia de la or-
en los que el equipo de anlisis y el personal clave de
ganizacin. As, por ejemplo, en el hipottico caso
los diferentes niveles de la organizacin adelantan el
de un hospital se podran identificar como activos
levantamiento y anlisis de la informacin. Este pro-
crticos el sistema de manejo de historias clnicas
ceso se divide en tres fases:
de los pacientes, los equipos de cmputo usados
Fase 1- Construir perfiles de amenazas basados en los activos por los mdicos para acceder al sistema de historias
Los diferentes miembros de la organizacin contri- clnicas y las historias clnicas en s mismas 3.
buyen con su visin sobre los activos que son crticos           -
para la empresa, la manera como se usan y lo que ticos: Se identifican los aspectos que son impor-
en la actualidad se est haciendo para protegerlos. El tantes de proteger para cada activo. Tpicamente se

3 Esto teniendo en cuenta que puede haber consideraciones de tipo legal que obliguen a garantizar la confidencialidad de
esta informacin
114 consideran aspectos de confidencialidad, integridad vulnerabilidades que pudieran facilitar las acciones
y disponibilidad. En el caso anterior, para el sistema no autorizadas sobre los activos crticos. Las salidas
de manejo de historias clnicas, se tendra la dispo- de esta fase son, entre otras:
nibilidad como principal requerimiento para poder
 $ 
   
 -
garantizar la atencin continua a los pacientes. En
nentes ms importantes que estn relacionados
el caso de las historias clnicas, la confidencialidad
con cada activo crtico como firewalls, servidores,
podra ser el principal requerimiento por garantizar
routers, sistemas de backup y almacenamiento de
y, en el caso de los equipos de los mdicos, la dis-
informacin, entre otros; a fin de visualizar todos
ponibilidad.
los caminos de acceso al activo crtico y elementos
 
   "
     que se puedan constituir en puntos de acceso no
manera estructurada de mostrar las diferentes ame- autorizado al activo evaluado.
nazas que se presentan sobre cada activo crtico.
 %
 &
  
  
 $   -
El perfil de amenazas identifica el actor que gene-
ponente es evaluado mediante diferentes tcnicas
ra la amenaza, el motivo u objetivo que perseguira
(herramientas de deteccin de vulnerabilidades,
el actor, la manera como podra acceder al activo
equipo tcnico de inspeccin) para identificar las
(fsicamente, a travs de la red) y el impacto que
debilidades que pueden llevar a accesos no auto-
generara sobre el activo y sobre la organizacin
rizados sobre los activos crticos. Es una actividad
(modificacin, destruccin, prdida, interrupcin,
muy tcnica que, incluso, puede ser subcontratada
vulnerabilidad de la confidencialidad, etc.). OCTA-
a terceros dentro de la valoracin de riesgos.
VE identifica cuatro perfiles principales: acceso a
travs de la red, acceso fsico, problemas del siste- Fase 3- Desarrollar estrategias y planes de seguridad
ma y otros problemas. '   
 #

 
-
 #  
      
 gos sobre los diferentes activos crticos y decide qu
prcticas de seguridad en la organizacin. Esta
identificacin es la base sobre la que se construir
ms adelante la estrategia de proteccin de la em-
presa. Para ello, OCTAVE incluye una serie de cat-
acciones tomar. El equipo crea entonces una estrategia
de proteccin y planes de mitigacin, basados en la
informacin recolectada. Las salidas de esta fase son:
 * +
 <  
logos de prcticas de seguridad que se evala en los
diferentes talleres, con una herramienta que facilita
a los participantes el entendimiento de lo que es
una prctica de seguridad y una vulnerabilidad. En
el caso del hospital, podran identificarse vulnerabi-
lidades como la no existencia de polticas claras de
seguridad, el manejo inadecuado de contraseas de
acceso a los sistemas y problemas de capacitacin y
entrenamiento.
Fase 2- Identificar vulnerabilidades en la infraestructura
El equipo de anlisis identifica los principales ele-
mentos de TI y los diferentes componentes que se
relacionan con cada activo crtico. Se evalan enton-
ces los diferentes componentes para identificar las
la informacin de las etapas anteriores y particu-
larmente en los perfiles de amenazas, se identifican
los riesgos y se evala el impacto en trminos de
una escala predefinida (alto, medio, bajo) de acuer-
do con los criterios que deben definirse durante las
fases anteriores. Estos criterios pueden basarse, a
su vez, en aspectos como: prdidas econmicas,
afectacin de la imagen, generacin de riesgo so-
bre vidas humanas, entre otros. Por ejemplo, en el
caso del hospital, una modificacin no autorizada
sobre una historia clnica puede considerarse como
de impacto alto, dado que genera riesgos a la vida
de los pacientes, expone al hospital a demandas y
puede afectar de manera muy negativa la imagen
del centro hospitalario.
 dossier

# 31 revista de ingeniera
 '  +
 
 la organizacin puede incurrir en gastos elevados sin
riesgo: Se desarrollan los planes de mejora y los
prximos pasos para proteger los activos crticos.
Se determina qu se va a hacer para implementar
los resultados de la evaluacin. Esta estrategia se
desarrolla a partir de las vulnerabilidades y prcti-
cas de seguridad identificadas durante la fase 1 y 2
de la metodologa.
REFLEXIONES ACERCA DE OCTAVE
Existen muchas metodologas para hacer una evalua-
cin de riesgos informticos. El principal problema al
que se est expuesto al hacer una evaluacin de este
tipo es que no se identifiquen oportunamente riesgos
importantes a los que, eventualmente, la organizacin
sea vulnerable. Metodologas como OCTAVE mini-
mizan este problema. Es importante que el anlisis
se realiza desde la perspectiva del uso que se hace de
los sistemas, debido a que la gran parte de los riesgos
provienen de las costumbres internas de la organiza-
cin. Esta visin se complementa al crear los perfiles
de amenazas en los que la metodologa lleva al grupo
a contemplar otros riesgos no identificados en el pri-
mer anlisis. Es evidente tambin que una evaluacin
de riesgos es muy particular para cada organizacin y
que no es sano desarrollar una evaluacin de riesgos
de una empresa a partir de los resultados obtenidos
por una organizacin diferente.
Es importante mencionar que la evaluacin de riesgos
se debe aplicar de manera peridica y que parte del
xito de la misma radica en el dominio y habilidades
del grupo de anlisis para llevarla a cabo. Por esto, es
importante que este anlisis se desarrolle siguiendo
metodologas como OCTAVE, que garanticen una
aplicacin consistente cada vez que se adelante, as
como contar con herramientas, catlogos actualiza-
dos y mecanismos de evaluacin y seguimiento apro-
piados. Al respecto podemos mencionar que, antes de
pensar en comprar cualquier tipo de equipos o soft-
ware asociados a seguridad, es necesario haber apli-
cado alguna metodologa de anlisis de riesgos para
ser efectivos en el control de stos; de otra forma,
11
realmente establecer mecanismos de seguridad contra
los riesgos del negocio.
OCTAVE es un muy buen complemento para imple-
mentaciones de metodologas como ITIL o COBIT,
en las que la evaluacin de riesgos es un componente
importante, sin que en ellas sea explcita la manera de
adelantar dicha evaluacin.
GOBIERNO DE LOS RIESGOS DE TI
Dentro del proceso que se quiere realizar para el an-
lisis de riesgos, una vez que se tiene claro el marco
de referencia y la metodologa a aplicar para llevar
este proceso, es necesario tener unas directrices claras
orientadas hacia los procesos de misin crtica dentro
de la organizacin. Es por esta razn que, unido a
lo anterior, se hace necesario entender cmo se en-
marcan estos estndares y metodologas dentro del
gobierno de TI.
Ahora, el impacto de las TI en el mundo empresa-
rial ha concitado un creciente inters por parte de
la alta gerencia como un elemento que debe ser ges-
tionado eficientemente para sostener y aumentar la
ventaja estratgica de las empresas. Este inters se ha
originado fundamentalmente por el rol cada vez ms
protagnico que estn jugando las TI en los procesos
misionales de las organizaciones. En este contexto de
los negocios, el gobierno de TI se ve enfrentado al
reto de desarrollar una gestin que integre diferentes
enfoques, prcticas y estndares, de tal manera que el
gobierno de TI no sea slo la aplicacin de unos es-
tndares sino que de su aplicacin armnica se derive
una ventaja estratgica y una continuidad del negocio
en forma adecuada.
Bajo esta consideracin, el gobierno de TI no es
una disciplina aislada sino que forma parte integral
del gobierno de la empresa; este ltimo se basa en
la aplicacin de tres dimensiones clsicas del gobier-
no corporativo: el cumplimiento legal y regulatorio,
el desempeo empresarial y la responsabilidad con
116 terceros (que en nuestro medio se han denomina-
do prcticas de Buen gobierno corporativo). Para
mencionar un solo caso como ejemplo, bastara refe-
rirse el sector financiero que, en el cumplimiento de
la circular externa 052 de la Superfinanciera (la cual
hace referencia a la seguridad de la informacin bajo
criterios de confidencialidad, integridad, disponibili-
dad, eficiencia, confiabilidad y cumplimiento bajo el
estndar ISO 27000 y los 4 dominios de COBIT, en-
fatizando en 16 de sus procesos) ha llevado a que la
seguridad de la informacin sea un tema central de
las juntas directivas, para los administradores y fun-
cionarios. Esto debido a las responsabilidades que se
derivan de su aplicacin y por las implicaciones que
Herramientas
Componente principales
Objetivo del
del gobierno que apoyan el
componente
de TI componente
tiene a nivel de la nacin, ya que la salud del sistema
financiero depende en gran medida de la gestin de
TI y en particular a la de riesgos.
Bajo los anteriores preceptos, el objetivo fundamen-
tal del gobierno de TI es generar una ventaja estrat-
gica sostenible al negocio con el propsito de generar
valor a sus grupos de inters (accionistas, clientes, en-
tre otros). Dentro de este marco se han identificado
cinco grandes focos de accin: Desarrollar e innovar
modelos de negocios que transformen la organiza-
cin; facilitar el desarrollo y crecimiento de la em-
presa; aumentar el valor de la empresa; optimizar la
operacin empresarial; y minimizar los riesgos en la
Manifestaciones de
Prcticas ms difundidas en la
buen uso a nivel
utilizacin de las herramientas
empresarial

1. Desarrollar e innovar con modelos

de negocios que transformen la
organizacin.
IT-BSC (Balance 2. Facilitar el desarrollo y crecimiento de
Alineacin Alinear estrategia de la empresa. Aumento de la ventaja
scorecard de tecnologas
estratgica TI con la corporativa competitiva
de informacin) 3. Aumentar el valor de la empresa.
4. Optimizar la operacin empresarial.
5. Minimizar los riesgos en la operacin
de la empresa.
Diferenciacin de
Mapas estratgicos soluciones productos y
Es la oferta que Productos servicios.
se hace al cliente IT-BSC
sobre los beneficios Servicios Menor costo.
Promesa de valor CMMI (Capability
que ste recibe de Maturity Model Oportunidad de entrega Mejor satisfaccin del
la relacin con la Integration) en calidad de cliente.
organizacin Calidad de los productos y servicios
software Mejora en el retorno de la
inversin.
COBIT (Control
Salvaguardar los Objectives for
Information and Coadyuvar a la continuidad
activos de TI y la Mitigar, transferir, eliminar
Gestin del riesgo relatedTechnology) de la operacin.
recuperacin de y aceptar el riesgo
desastres ISO 27000 Minimizar los siniestros
Octave
Optimizar el
conocimiento, Mejorar procesos y sincronizar la Sincronizacin de la
infraestructura, ITIL
Gestin de operacin operacin.
personas, procesos, CMMI
recursos Mejorar los Ciclos de vida de Hw, Sw y Mejora en los Acuerdos de
aplicaciones,
instalaciones, datos, servicios niveles de servicio.
informacin
Mejora de los indicadores
de:
Factores claves de xito
Evaluacin de Seguir los proyectos y CobiT (KSF)
desempeo monitorear el servicio
de TI BSC Indicadores de
rendimiento claves (KPI)
Indicadores de logro
claves (KGI)

Tabla 1. Resumen de componente, objetivos y herramientas ms difundidas de gobierno de TI


operacin de la empresa. Estos cinco objetivos se ven
desarrollados por los siguientes componentes sobre
los cuales se centra el gobierno de TI: alineacin es-
tratgica, promesa de valor, gestin del riesgo, gestin
de recursos y evaluacin de desempeo, los cuales no
deben ser gestionados independientemente sino ar-
mnicamente como se ilustra en la Tabla 1.
Como recomendacin, mencionamos que la aplica-
cin de estndares o mtodos sin una visin estra-
tgica clara es el gran riesgo que se corre al aplicar
de forma independiente o en forma desarticulada,
los diferentes modelos o metodologas, los cuales se
vuelven un fin en s mismos y que no tengan un foco
estratgico claro. La visin del riesgo, los estndares y
la metodologa OCTAVE, enmarcados dentro de una
visin comn y relacionados con los modelos que se
han ilustrado anteriormente, son esfuerzos que deben
ir en la direccin correcta. En particular, la identifi-
cacin de activos crticos y la forma de mitigar los
riesgos no son independientes, sino que depende de
la forma en que construyen valor a la organizacin y
determinan el rol de las TI.
CONCLUSIONES
Es claro que las organizaciones hoy en da son cons-
cientes de la necesidad de identificar los riesgos aso-
ciados a TI, pero tambin es claro que al tener esta
preocupacin y no aplicar una metodologa adecuada
para cada negocio (es decir, entendiendo su cultura
organizacional, sus procesos, sus operaciones de mi-
sin crtica) es imposible lograr que estas metodo-
logas alcancen sus metas de minimizar los riesgos.
Es por esta razn que, adicionalmente a conocer los
estndares, normas, regulaciones y metodologas de
anlisis de riesgos, es necesario contar con un gobier-
no de TI que establezca en forma clara las directrices
estratgicas para llevar en forma exitosa estos proce-
sos de anlisis de riesgos. Lo anterior significa que
para lograr un proceso exitoso se requiere de la siner-
gia del conocimiento de los estndares y normas, con
dossier
# 31 revista de ingeniera
las metodologas a aplicar y con un gobierno de TI 11
que lidere, organice y defina los lineamientos a seguir,
con miras a sostener sus procesos de misin crtica
bajo una cultura organizacional.
REFERENCIAS BIBLIOGRFICAS
[1] Getting smarter about IT Risk: The Economist.
Economist Intelligence Unit. The Economist - Hewlett
Packard, 2008.
[2] G. Westerman and R. Hunter,
IT Risk: Turning Business Threats into Competitive Advantage.
Boston: Harvard Business School Press, 2007.
[3] Direccin de Comunicaciones Corporativas Ban-
colombia.
Sala de prensa. Grupo Bancolombia. Fecha de
consulta 1 de abril de 2010. Disponible en: http://
www.grupobancolombia.com/home/saladeprensa/
noticias/2010/2010-infoSaldos.asp, 2010
[4] J. Santa.
Anlisis de marcos de gestin del riesgo de TI: Los marcos 4A,
Risk IT y la construccin de una herramienta de anlisis. Bogot:
s.n., 2009.
[5] D. Murali.
Create a risk-aware IT behaviour. The Hindu Business
Line. The Hindu, 2008. Fecha de consulta: 1 de abril
de 2010. Disponible en: http://www.blonnet.com/
ew/2008/12/15/stories/2008121550190400.htm.
[6] J. Pinzn.
Acercamiento a la Gestin de Riesgos con Magerit y las 4A.
Bogot: s.n., 2009.
[7] G. Stoneburner, A. Goguen and A. Feringa.
Risk Management Guide for Information Technolog y Systems.
NIST SP 800-30. Department of Commerce, Unite States
of America. July 2002. Fecha de consulta: 1 de abril de
2010. Disponible en: http://csrc.nist.gov/publications/
nistpubs/800-30/sp800-30.pdf.
118 [8] Enterprise Risk: Identify, Govern and Manage IT Risk. 2009.
Risk IT. IT Governance Institute. Fecha de consulta: 1
de abril de 2010. Disponible en:
http://www.isaca.org/AMTemplate.cfm?Section=Deliver
ables&Template=/ContentManagement/ContentDisplay.
cfm&ContentID=47967.
[9] CERT.
OCTAVE (Operationally Critical Threat, Asset, and
Vulnerability Evaluation). CERT - Software Engineering
Institute - Carnegie Mellon University. September 17,
2008. Fecha de consulta: 1 de abril de 2010. Disponible
en: http://www.cert.org/octave/.
[10]. Consejo Superior de Administracin Electrnica.
MAGERIT. Metodologa de Anlisis y Gestin de Riesgos
de los Sistemas de Informacin. - Espaa. Fecha de
consulta: 1 de abril de 2010. Disponible en:
http://www.csae.map.es/csi/pg5m20.htm.
[11] A. Christopher and D. Autrey.
Managing Information Security Risks. The OCTAVE
Approach. S.L.: Addison-Wesley, 2003.
[12] A. Christopher and D. Autrey.
OCTAVE Criteria Versin 2.0. Pittsburgh: Carniege
Mellon Software Engineering Institute. December 2001.
[13] B. Miroslav.
The risk assessment of information system security. University
of Zagreb, Faculty of Organization and Informatics,
Varadin, Croatia. Fecha de consulta: 1 de abril de 2010.
Disponible en: http://www.carnet.hr/CUC/cuc2004/
program/radovi/a5_baca/a5_full.pdf.
Recibido 30 de Abril de 2010, modificado 20 de Agosto de 2010, aprobado 23 de Agosto de 2010.
BIBLIOGRAFA
D. Prez.
De la Administracin al Gobierno de TI, Revista
Sistemas. No. 96, Asics. 2008, pp. 65-72.
F. Scalone.
Estudio comparativo de los modelos y estndares de calidad del
software. Tesis de Magister. Buenos Aires: Universidad
Tecnolgica Nacional, Facultad Regional, 2006.
Hoestra A, Conradie N.
How to use them in conjunction,
PricewaterhouseCoopers.
ISACA
North America 2005 Msc Carlos Zamora Sotelo, Cisa,
CISM, CobIT, ITIL, and ISO 17799
ISACA.
COBIT 4.1. Fecha de consulta: 1 de abril de 2010.
Disponible en: http://www.isaca.org/Content/
NavigationMenu/Members_and_Leaders1/COBIT6/
Obtain_COBIT/Obtain_COBIT.htm
IT Governance Institute.
Board briefing on IT governance. 2nd Edition. USA: 2003.
J. Raggio.
Desarrollo de procesos de gestin de servicios de explotacin
siguiendo el modelo CMMI. Madrid: Universidad Politcnica
de Madrid, Facultad de Informtica, Estudios de
Doctorado,
M. Biegstraaten.
IT governance para la gestin de servicios: Cobit en
la prctica. AC Forum-BMC. Fecha de consulta: 1 de
abril de 2010. Disponible en: http://www.bmc.com/
es_ES/presentations/Presentacion_CobiT_vs_ITIL _
BMC_020306.pdf