109dossier

#31 revista de ingeniera. Universidad de los Andes. Bogot, Colombia. rev.ing. ISSN. 0121-4993. Enero - Junio de 2010, pp. 109-118.

Metodologa y gobierno de la gestin de riesgos de tecnologas de la informacinMethodology and Governance of the IT Risk ManagementRicardo Gmeza, Diego Hernn Prezb, Yezid Donosoc, Andrea Herrerad

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.cob 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.comc 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.cod 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

P A L A B R A S C L A V E S

Amenazas en TI, anlisis de riesgos, continuidad de

negocios, gobernabilidad de TI, Vulnerabilidad.

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

prdidas debido a fallas y/o ataques sobre sus servicios

de TI, los cuales afectan seriamente su reputacin y su

-

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.

K E Y W O R D S

Business continuity, IT governance, risk analysis,

vulnerability and threat in IT.

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

among others, they are reporting economical lost due

to fails or attacks over theirs IT services, which can affect

the reputation, relationships with the clients and their

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.

110 I N T R O D U C C I N

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.

O R G E N E S D E L A R E G U L A C I N Y S U P A P E L

E N L A F O R M A L I Z A C I N D E L A G E S T I N D E

R I E S G O S D E T I

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

111

#31

re

vist

a d

e i

ng

en

ier

adossier

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

el impacto de la falla tecnolgica [3]. Finalmente, se 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

1 Large Hadron Collider (LHC) es el acelerador de partculas ms grande del mundo, ubicado en Conseil Europen pour la

Recherche Nuclaire (CERN).

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.

U N A M E T O D O L O G A P A R A E L A N L I S I S D E

R I E S G O S D E T I

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.

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.

P R I N C I P A L E S C A R A C T E R S T I C A S

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

2 El CERT es un centro de investigacin en seguridad en Internet del Software Engineering Institute (SEI) de la Universidad

de Carnegie Mellon.

113

#31

re

vist

a d

e i

ng

en

ier

adossier

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 tener una visin global de los riesgos de seguridad de los servicios de TI.

El equipo de anlisis debe identificar los activos re-lacionados con la informacin que son de importan-cia para la organizacin, entendiendo esta importan-cia en trminos de que se garantice la continuidad de operacin. El anlisis se focaliza sobre los activos que se identifican como crticos y la identificacin del modo en que se relacionan dichos activos entre s, las amenazas a las que estn expuestos y las vulnerabili-dades (organizacionales y tecnolgicas). El estudio se hace desde un punto de vista operacional, se verifica cmo se usan los diferentes activos y cmo pueden estar en riesgo debido a amenazas de seguridad. Fi-nalmente, se define una estrategia basada en prcticas para el mejoramiento organizacional y un plan de mi-tigacin para reducir el riesgo al que est expuesta la organizacin.

D E S A R R O L L O D E L A E V A L U A C I N

OCTAVE se desarrolla mediante una serie de talleres en los que el equipo de anlisis y el personal clave de los diferentes niveles de la organizacin adelantan el levantamiento y anlisis de la informacin. Este pro-ceso se divide en tres fases:

Fase 1- Construir perfiles de amenazas basados en los activos

Los diferentes miembros de la organizacin contri-buyen con su visin sobre los activos que son crticos para la empresa, la manera como se usan y lo que en la actualidad se est haciendo para protegerlos. El

equipo evala la informacin y selecciona los activos 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 -sobre cada uno de ellos, el impacto que tienen dichas amenazas sobre los mismos y sobre la organizacin, y los requerimientos de seguridad de cada activo.

En la cuarta etapa se consolida la informacin reco-lectada en las etapas 1 a 3, verificando aspectos como la completitud, coherencia y diferencias de aprecia-cin en los diferentes niveles de la organizacin. La informacin se analiza y se organiza segn las amena-zas que se presentan para cada activo. Los talleres que se desarrollan en estas fases giran en torno a discusio-nes dirigidas, a formatos preestablecidos que se dili-gencian durante cada taller y a encuestas de prcticas de seguridad en la organizacin; todos ellos con guas de manejo que tiene la metodologa.

Como resultado de esta fase se tendrn, entre otros, los siguientes productos:

-nados con la informacin que son de mayor cri-ticidad para la operacin y subsistencia de la or-ganizacin. As, por ejemplo, en el hipottico caso de un hospital se podran identificar como activos crticos el sistema de manejo de historias clnicas de los pacientes, los equipos de cmputo usados por los mdicos para acceder al sistema de historias clnicas y las historias clnicas en s mismas3.

-ticos: Se identifican los aspectos que son impor-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 y disponibilidad. En el caso anterior, para el sistema de manejo de historias clnicas, se tendra la dispo-nibilidad como principal requerimiento para poder garantizar la atencin continua a los pacientes. En el caso de las historias clnicas, la confidencialidad podra ser el principal requerimiento por garantizar y, en el caso de los equipos de los mdicos, la dis-ponibilidad.

"manera estructurada de mostrar las diferentes ame-nazas que se presentan sobre cada activo crtico. El perfil de amenazas identifica el actor que gene-ra la amenaza, el motivo u objetivo que perseguira el actor, la manera como podra acceder al activo (fsicamente, a travs de la red) y el impacto que generara sobre el activo y sobre la organizacin (modificacin, destruccin, prdida, interrupcin, vulnerabilidad de la confidencialidad, etc.). OCTA-VE identifica cuatro perfiles principales: acceso a travs de la red, acceso fsico, problemas del siste-ma y otros problemas.

# 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-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

vulnerabilidades que pudieran facilitar las acciones no autorizadas sobre los activos crticos. Las salidas de esta fase son, entre otras:

$ -nentes ms importantes que estn relacionados con cada activo crtico como firewalls, servidores, routers, sistemas de backup y almacenamiento de informacin, entre otros; a fin de visualizar todos los caminos de acceso al activo crtico y elementos que se puedan constituir en puntos de acceso no autorizado al activo evaluado.

%& $-ponente es evaluado mediante diferentes tcnicas (herramientas de deteccin de vulnerabilidades, equipo tcnico de inspeccin) para identificar las debilidades que pueden llevar a accesos no auto-rizados sobre los activos crticos. Es una actividad muy tcnica que, incluso, puede ser subcontratada a terceros dentro de la valoracin de riesgos.

Fase 3- Desarrollar estrategias y planes de seguridad

'#-gos sobre los diferentes activos crticos y decide qu 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:

*+