especificación por disciplinas de la guía de mejores

Especificación por Disciplinas de la Guía de mejores prácticas en gestión de riesgos de TI en el sector

bancario colombiano.

Documento presentado por:

Camilo Méndez Ayerbe y Gustavo Camargo Avendaño

Asesorado por:

Andrea Herrera

Presentado al:

Departamento de Ingeniería de Sistemas y Computación

Como requisito para la obtención del grado de

Ingeniero de Sistemas y Computación

Universidad de los Andes

Bogotá, Colombia

Noviembre 2009

2 Grupo de Investigación en Tecnologías de Información, Organizaciones y Negocios

A nuestros Padres y los miembros de nuestras fraternales familias…


AGRADECIMIENTOS

En el desarrollo de este proyecto de grado, existieron personas y entidades a las cuales les queremos

agradecer su colaboración. En primera instancia a Luis Carlos Figueroa, quien nos permitió trabajar en

el desarrollo de su tesis, la gran colaboración que nos presto en el desarrollo de la disciplina de gobierno

y su apoyo en todo lo relacionado con el banco. A nuestra asesora Andrea Herrera quien tuvo toda la

buena voluntad y la paciencia para guiarnos en el desarrollo del proyecto; también tuvimos el apoyo de

“San Vicente” en los momentos donde se necesito de él. A todas las personas que nos ayudaron en el

Banco de la República especialmente a Adela Garzón, Johanna Gutierrez, Ivan Reyes de la UROC,

Sandra Camacho, William Hallaby, Sandra Rodriguez, Elizabeth Carrillo y Francisco Rivas de la

Subgerencia de Informática y Alfonzo Luque de la Subgerencia de Operación Bancaria. Los miembros

del grupo TION que nos apoyaron de una u otra forma y a los compañeros que también colaboraron en

este proceso.


ÍNDICE GENERAL

Contenido

PARTE A ...................................................................................................................................................... 8

I. ARTÍCULO ......................................................................................................................................... 9

II. PRESENTACIÓN .............................................................................................................................. 15

PARTE B .................................................................................................................................................... 23

III. CAPÍTULO 1 - INTRODUCCIÓN ............................................................................................... 24

1.1 ANTECEDENTES ............................................................................................................................................ 24 1.2 JUSTIFICACIÓN ............................................................................................................................................. 25 1.3 OBJETIVO GENERAL Y ESPECÍFICOS ................................................................................................................... 25 1.4 ALCANCE ..................................................................................................................................................... 26 1.5 METODOLOGÍA ............................................................................................................................................ 26 1.6 RESULTADOS ESPERADOS ............................................................................................................................... 27

IV. CAPÍTULO 2- MARCO TEÓRICO ............................................................................................. 28

2.1 EL MARCO 4-A Y LOS TRABAJOS PREVIOS .......................................................................................................... 28 2.1.1 Marco de Gestión de Riesgos de TI 4-A ........................................................................................... 29 2.1.2 Trabajos previos realizados en la Universidad de los Andes. .......................................................... 34

2.2 LAS DISCIPLINAS ........................................................................................................................................... 35 2.2.1 Base tecnológica ............................................................................................................................. 35 2.2.2 Gobierno ......................................................................................................................................... 50 2.2.3 Cultura ............................................................................................................................................ 57

2.4 SÍNTESIS ...................................................................................................................................................... 62

V. CAPÍTULO 3 – LA GUIA DE GESTIÓN DE RIESGOS DE TI ....................................................... 63

3.1 DESCRIPCIÓN GENERAL .................................................................................................................................. 63 3.2 PASOS DE LA GUÍA ........................................................................................................................................ 64 3.3 PROFUNDIZACIÓN DEL PASO “PLANEACIÓN DETALLADA DE DESARROLLO DE CADA DISCIPLINA” ................................... 65

3.3.1 Base Tecnológica ............................................................................................................................ 66 3.3.2 Gobierno ......................................................................................................................................... 67 3.3.3 Cultura ............................................................................................................................................ 68

VI. CAPÍTULO 4 - EL CASO DE ESTUDIO ..................................................................................... 71

4.1 DESCRIPCIÓN DEL BANCO ............................................................................................................................... 71 4.2 MARCO DE GESTIÓN RIESGOS OPERATIVOS ........................................................................................................ 73 4.3 SUBGERENCIA DE INFORMÁTICA ...................................................................................................................... 75 4.4 PROCESO DE COMPENSACIÓN DE CHEQUES........................................................................................................ 76 4.5 VALIDACIÓN PASO 4 DE LA GUÍA ...................................................................................................................... 79

4.5.1 Base tecnológica ............................................................................................................................. 80 4.5.2 Gobierno ......................................................................................................................................... 86 4.5.3 Cultura ............................................................................................................................................ 93 4.5.4 Síntesis de los planes de acción .................................................................................................... 100

VII. CAPÍTULO 5 - CONCLUSIONES Y TRABAJOS FUTUROS ................................................... 105

5.1 CONCLUSIONES SOBRE EL CASO DE ESTUDIO ..................................................................................................... 105


5.2 CONCLUSIONES SOBRE LOS MODELOS ............................................................................................................. 105 5.3 SOBRE EL PROYECTO DE GRADO ..................................................................................................................... 106 5.4 TRABAJOS FUTUROS .................................................................................................................................... 107

VIII. ANEXOS ..................................................................................................................................... 109

6.1 CICLO DE VIDA PROGRAMA DE BCM: ............................................................................................................ 109 6.2 PLAN DE CONTINUIDAD DEL NEGOCIO (BCP): .................................................................................................. 110 6.3 TABLA PROBLEMAS TÍPICOS 4-A’S, BASE TECNOLÓGICA. .................................................................................... 112 6.4 LISTA DE CHEQUEO DISCIPLINA DE BASE TECNOLÓGICA ....................................................................................... 114 6.5 LISTA DE CHEQUEO DISCIPLINA DE GOBIERNO DE RIESGOS DE TI. .......................................................................... 125 6.6 CUADROS DE COMPORTAMIENTO DE CULTURA ................................................................................................. 126 6.7 ORGANIGRAMA BANCO DE LA REPÚBLICA ....................................................................................................... 128 6.8 DATOS DE LAS PETICIONES DE CAMBIOS (RFC – REQUEST FOR CHANGE) ............................................................. 129 6.9 DATOS INFORMACIÓN CONTENIDA EN EL SISTEMA DE ADMINISTRACIÓN DE CONFIGURACIONES (RFC – REQUEST FOR

CHANGE) ............................................................................................................................................................ 130 6.10 DATOS DE UN REGISTRO DE INCIDENTES ..................................................................................................... 131 6.11 DATOS DE UN REGISTRO DE PROBLEMAS..................................................................................................... 133 6.12 LISTA DE CHEQUEO CORRESPONDIENTE A LA VALIDACIÓN DEL PROCESO REALIZADA CON LA UNIDAD DE PROTECCIÓN Y

CONTINUIDAD INFORMÁTICA ................................................................................................................................. 134 6.13 VALIDACIÓN DISCIPLINA DE GOBIERNO EN BANCO DE LA REPÚBLICA. .............................................................. 146 6.14 VALIDACIÓN LISTA DE CHEQUEO DE CULTURA. ............................................................................................. 147

IX. BIBLIOGRAFÍA ......................................................................................................................... 150


ÍNDICE DE FIGURAS

Figura 1 - Pirámide riesgo TI .................................................................................................... 30

Figura 2 - Las disciplinas de gestión de riesgo de TI ................................................................ 31

Figura 3 - Factores de Riesgo de TI. ......................................................................................... 32

Figura 4 – Relación de las disciplinas con el negocio ............................................................... 33

Figura 5 - Mecanismos Administración TI ............................................................................... 38

Figura 6 - Base tecnológica sólida. ............................................................................................ 39

Figura 7 - Estructura Programa de BCM (Ciclo de Vida) – B.C.I ........................................... 42

Figura 8 - Pasos Clave plan de continuidad de TI. .................................................................... 43

Figura 9 - Controles base tecnológica ....................................................................................... 45

Figura 10 - Identificación y Reparación. ................................................................................... 45

Figura 11 - COBIT-Gobierno de TI .......................................................................................... 47

Figura 12 - Estructura ITIL ....................................................................................................... 48

Figura 13 - Pasos Reparación Base Tecnológica....................................................................... 48

Figura 14 - Complementos para el desarrollo del Marco 4-A, base tecnológica. ..................... 49

Figura 15 - Modelo de trabajo, Base Tecnológica..................................................................... 50

Figura 16 - Roles de Gobierno de Riesgos de TI ...................................................................... 52

Figura 17 - Procesos de Gobierno de TI. ................................................................................... 53

Figura 18 - Gobierno de Gestión de Riesgos de TI. .................................................................. 55

Figura 19 - Complemento de la disciplina de Gobierno ............................................................ 56

Figura 20 - Modelo E-M-C-R. ................................................................................................... 58

Figura 21 - Grupos en las organizaciones. ................................................................................ 59

Figura 22 - Pasos de la Guía de gestión de riesgos de TI .......................................................... 63

Figura 23 - Escudo Banco de la República. .............................................................................. 71

Figura 24 - Ubicación de áreas relacionadas con gestión de riesgos de TI dentro del organigrama del Banco. ............................................................................................................. 72

Figura 25 - Administración de riesgo operativo en Banco de la República. ............................. 74

Figura 26 - Modelo de gestión previa del riesgo operativo en Banco de la República ............. 74

Figura 27 - Organigrama de Subgerencia de Informática ......................................................... 76

Figura 28 – Diagrama del proceso de compensación de cheques en el Banco de la República 77

Figura 29 – Diagrama del proceso de devolución de cheques en el Banco de la República ..... 78

Figura 30 - Definición de roles dentro del Banco de la República. ........................................... 88

Figura 31 - Proceso actual de gestión de riesgos de TI subgerencia de informática (25). ........ 89

Figura 32 - Mejores prácticas de TI en la subgerencia de informática (23) .............................. 91

Figura 33 - Estructura del BCP (Business Continuity Plan) - BCM Institute. ....................... 110

Figura 34 - Estructura Programa de BCM. DRI International (32). ........................................ 111


INDICE DE CUADROS

Tabla 1 - Marco de evaluación cultural ..................................................................................... 61

Tabla 2 - Taxonomía para eventos relacionado con TI ............................................................. 75

Tabla 3 - Valoraciones numéricas por pasos de esta lista de chequeo. ..................................... 80

Tabla 4 - Actividades primordiales Base tecnológica ............................................................... 86

Tabla 5 - Actividades primordiales Gobierno ........................................................................... 93

Tabla 6 - Actividades primordiales Cultura ............................................................................ 100

Tabla 7 - Cuadro de relaciones interdisciplinarias .................................................................. 104

Tabla 8 - Fuentes de Riesgo Comunes. ................................................................................... 113

Tabla 9 – Continuidad de Negocio .......................................................................................... 117

Tabla 10 – Falencias y reparación de Infraestructura de TI. ................................................... 118

Tabla 11 – Gestión y monitoreo de TI ..................................................................................... 124

Tabla 12 - Lista de chequeo de actividades gobierno de riesgo de TI..................................... 126

Tabla 13 - Lista chequeo cultura organizacional ..................................................................... 126

Tabla 14 - Lista chequeo cultura social ................................................................................... 126

Tabla 15 - lista chequeo políticas y reglamentación ................................................................ 127

Tabla 16 - Lista chequeo entrenamiento y divulgación ........................................................... 127

Tabla 17 - Lista chequeo aceptación ....................................................................................... 127

Tabla 18 – Continuidad del negocio. ....................................................................................... 138

Tabla 19 – Identificación y reparación de Infraestructura. ...................................................... 138

Tabla 20 – Gestión y monitoreo de TI ..................................................................................... 145

Tabla 21 – Resultado valoración numérica, Base tecnológica. ............................................... 145

Tabla 22 - Lista de checheo de actividades de gobierno de TI ................................................ 147

Tabla 23 - Valores de evaluación ............................................................................................ 147

Tabla 24 - Lista de Chequeo de cultura Proceso compensación de cheques. .......................... 149


PARTE A


I. ARTÍCULO Este artículo es un borrador ya que la versión final será presentada en un congreso por definir.

Best practices guide for managing IT risk in banking specification by disciplines

Camilo Méndez Ayerbe Universidad de los Andes

[email protected]

Gustavo Camargo Avendaño Universidad de los Andes

[email protected]

Andrea Herrera Universidad de los Andes [email protected]

ABSTRACT In this paper, we describe the development and the findings obtained in the specification of the “Guía de mejores prácticas de gestión de

riesgo de TI en el sector bancario”1. Also we present a review of some important theories that exist in IT risk management2 to develop extend models that exploit the best attributes of the earlier ones. And finally, we show the application of the developed models as a validation case for the guide specification in the “Banco de la

República”3, over the cheque clearing process.

Keywords IT Risk Management, Models, Disciplines, Foundation, Governance, Culture, 4-A, Case of study, Bank.

1. INTRODUCTION Risk has been present in everything we encounter, from the beginning of time, but we have only started to think about it just recently. Thinking how to manage risk and be prepared is a relative new concept. And the firsts too start talking about it, and stated managing it was the financial sector (1).

The financial sector of a country is a main actor that allows an appropriate development of its economy. Furthermore, how rapidly the IT world is changing and the value of the information that manages for each organization in that sector, make important to have a good IT risk management. This will allow an adequate use of technological resources, a convenient information management and the potential opportunities of doing so.

Is fundamental to say that in Colombia the central bank, called “Banco de la República”, is a leader that trends on subjects such as continuity management and risk management, therefore the bank has to give example at implementing new initiatives. As well these are the motives for choosing it as the institution to study and as a result provide the “Best practices guide for IT risk management in Colombian banking sector” (2) specified.

1 Best practices guide for managing IT risk in Colombian banking 2 like the 4-A model of MIT 3 The central bank of Colombia

Therefore the main objective of this research is to build and develop a document of analysis, valuation and monitoring of IT risks, focusing on the cheque clearing process, starting from the results obtained at applying the “Best practices guide for managing IT risk in

banking”. It is important to state that the application of this guide is

going to be made after its respective specification has been done, which is finally the scope of this research.

2. INFORMATION GATHERING AND MODELS The models were elaborated according to the disciplines suggested by the 4-A (Foundations, Governance and Culture awareness) (3), also complemented for the framework “Risk IT” (4) created by the IT governance institute, and some other authors and documents related to the IT risk topic. This was done in order to complement the guide. The best practices guide for IT risk management, contain six steps (2): build the ideal profile of IT risk, define the actual IT risk profile, prioritization of discipline, detail and plan the development of the discipline, grade implemented actions, and feedback. In this paper we will show the construction, specification and validation of the fourth step; “Planeación detallada de desarrollo de cada disciplina”

(discipline detailing and planning).

Figure 1: guide for managing IT risk in Colombian banking (2)


For constructing the discipline detailing and planning step in the guide, we have to know a little more about the base framework for this project, the 4-A framework. This framework has in its core 4 business objective; Availability, Accuracy, Access and Agility, and 3 disciplines Foundation, Governance and Culture.(5) With this framework as base we started to build cohesive individual models for itch of the disciplines in the 4-A framework. 4-A is not the only model used for this study but is one that each of the disciplines uses. Here is a brief explanation of the enhanced models we have built.

2.1 Foundations Even though this is the first discipline to mention, it has to be told that the approach of the framework 4-A is built from a business perspective.

First of all, it is necessary to define what “the foundation” is, and that

is, according to Westerman and Hunter, “the collection of IT assets,

procedures, and people that support and enable business processes and decision making. A weak foundation is the perfect state for materialization of any kind of risk, especially IT risks. Inconsistent software updates and a complex interdependency between components allow systems to fail constantly, makes hard to recover it and even worst, impossible to change” (3). Secondly, a mature foundation is statistically the most important element to reduce risks and improve the IT performance.

Given the fact that IT is transversal to the whole organization, it is possible to say that its problems are also important to the entire organization; in addition IT is the responsible of the interactions between business units and among the business and the outside world. Reason why to identify future problems becomes pertinent in order to create methods and measures to avoid those system’s failures (4).

Now, it is necessary to stand out some of the benefits that are possible to develop through an adequate IT risk management guided by a foundation-driven approach, and those are (3): Immediately finding and fixing holes in the foundation corrects

immediate weaknesses, providing time to make other longer-term improvements.

Simplification is the most cost-effective risk management approach over the long term because it pays off in cost reduction as well as risk reduction.

Simplification reduces all four IT risks and makes the other two disciplines easier to master.

Issues with a foundation-driven approach: Initial efforts to find and fix holes can be substantial. It can be difficult and costly to go beyond simplifying the

infrastructure to simplify the applications. Simplification takes time. It is most often done incrementally.

In order to direct the foundation to a solid IT infrastructure that has a low risk incidence and a low probability of occurrence, it is necessary to have an IT system and a set of applications clearly structured, furthermore it is essential to implement enough controls and provide an excellent technical support service.

According to the framework it can be done following three fundamental steps, all of them visibly related to the strengthening of the foundation. Those steps are (see figure 1) (3):

1. First, address availability risk by managing business continuity to ensure that the organization can get up and running again quickly if a major incident occurs.

2. Concurrently, identify and plug holes in the foundation, using IT audit and the knowledge of the IT team as a guide, to address availability and access risks.

3. Then implement basic IT controls and industry best practices to monitor the status of the base and prevent future holes in the foundation.

Each one of these steps was strengthened by the incorporation of deeper theories. It was done as it follows: The continuity component was extended by introducing the industry best practices called BCM Programme (stands for Business Continuity Management Programme), set of guidelines developed by the Business Continuity Institute (5). The finding and fixing infrastructure failures element was built combining elements from both the first component and the third component. And the IT management component was specified by integrating the IT Infrastructure Library (ITIL) (6) and the governance framework called “Control Objectives for Information and Related

Technologies” (COBIT) (7) to the framework 4-A.

Figure 2: Foundation model

After doing the research, introducing and integrating all those theories and guidelines with the main model, it can be seen the entire discipline of foundation as a fortified set of steps and practices that will allow improving the infrastructure management and consequently the IT risk management. To get a full description of each step please read the entire document related to this paper (8) Section 2.1.1. This covers the basic information about the new foundation model. Next, the risk governance discipline.

Implement controls and audits based on standard frameworks

Strengthened by

IT Infrastructure Library (ITIL).

Control Objectives for Information and Related Technologies (COBIT)

Find and plug the holes in the dike.

Finding And Fixing the infrastructure failures,

Elements from ITIL, COBIT and BCM focused on infrastructure.

Build and test a business continuity plan.

Strengthened byBusiness Continuity Management

Programme (BCM Programme)


2.2 Risk Governance The Risk Governance Process is build from the two main frameworks of this research, starting from the comparative analysis that allowed selecting the framework 4-A as a main frame and the “Risk It”

framework as a complement for operative matters (9).

The 4-A IT Risk Governance consist of a cyclic process that defines which are the IT Risk within the organization, monitor the way how those risk evolve, prioritize those risks and develop standards and policies to manage them. Additionally the cycle process has roles, responsibilities and best practices defined.

This section shows and explains roles, process structure and practices to improve the process itself. The activities about this discipline to develop are directly related to the three components already mentioned.

The first component is: Definition of roles over different hierarchical levels:

Executive sponsor. Risk politics council. Implementation council. IT Risk management team. Local managers. IT Risk officer.

These roles are not necessarily to be exactly as its description says but each one of those need to have its own responsible person or team depending on the size and needs of the company.

Subsequently, the second component of governance is studied. This component is the IT risk governance process, and it is comprised of five phases: Defining politics and risk standards. Identifying and evaluating risks. Prioritizing roles and assigning responsibilities. Addressing risks. Monitoring and supervising risks.

Finally, the third component of this discipline is about those practices that improve the process operation, and those are: Assigning an only owner of the process. Identifying risk categories in a formal manner. Creating a risk register. Developing methods to evaluate every risk. Using specialized best practices.

As a result of the study of this discipline it can be told that it defines which of the risks are within the organization, it monitors them, prioritize them, and develop politics and methods to manage them through different roles and practices of process improvement.

The IT risk governance stipulated by the framework “Risk IT” is

based on three domains. These domains are: Risk governance, risk evaluation and risk answers. Each one of those domains has their own processes: IT risk governance:

Establish and maintain a common view of IT risk. Integrate itself with the risk management of the

organization.

Make decisions taken into account every business risk.

IT risk evaluation: Collecting data. Risk analysis. Maintain risk profiles.

IT risk Answer:

Risk clearly. Risk treatment. Opportune reaction to events.

These two frameworks (Risk IT, 4-A), can complement each other for the construction of this guide, as it can be seen on figure 2.

The advantage of merging these two frameworks that manage IT risk is that they have different perspective, 4-A sees risk from a business perspective and Risk IT sees it from an operative way. The first domain of Risk IT is IT governance and is objective is the defining an application of risk management rules. The second domain of IT Risk is inside the process of 4-A framework in risk identification and prioritization. The last domain of Risk IT is also presented in the 4-A sub process of deciding what to do with risk. With this model it’s

possible to attack risk from a broader perspective.

Figure 3: Governance model

This covers the basic information of the new model of governance.

2.3 Culture The original frameworks that we took as base; 4-A and risk IT, the approach to the discipline is not specific in terms of evaluation and development but they do establish an ideal state of what it´s desired for a risk culture. The desired behaviors are (3): It’s ok to talk about risk.

It’s ok to take risks. It’s ok to fail (if managed appropriately). Success and failures are tracked and analyzed. Continuous learning an improvement of key processes. Realistic budgets and timelines that are continuously monitored. Managers actively share risk and risk management. The enterprise is able to take on bigger risks.


To have these behaviors is what any enterprise will like to achieve in risk culture awareness. The difficulty is how to get there. First it’s

necessary to understand that culture is something that exists in every human being, it is transferred for the society the person is born and can be very different from one person to other (10). Knowing this makes the understanding of the way an organization culture behaves independent of the rules it has define and there is a different hierarchic structure. In this social hierarchy there are leaders and follower and the may be different of the organizationally selected. The question than now appears is, how to make the culture of an organization be align with its organizational rules and ideas? To do this it’s necessary to create effective communication channels

for broadcasting the way the organization wants its people to behave. Using a simple communication models it can be broadcasted (11) it is possible. The next step is defining how and what the organization wants to communicate. The how could be define by three practices that can develop risk culture. The first approach emphasizes the importance of instilling security behavior into daily work practices; the second suggests education and training processes to internalize security aspects and shape behavior; and the last focuses on social participation and motivation as a means of achieving compliance with formal mechanisms (12). The what in culture, is define by which information is public and which is private, which is spoke and which isn´t, and which is explicit or which is implicit (13). The defining of information in these terms allows the mapping way the culture in the organization behaves. And cross referencing it whit the practices presented earlier, we can value the acceptance of a risk element as the table 1 shows.

Cultural Analysis

Private Public

Not speak Speak Not speak Speak

Element to

evaluate practice:

impl

icit

expl

icit

impl

icit

expl

icit

Impl

icit

expl

icit

impl

icit

expl

icit

Element 1

1

2

3

Table 1: Cultural model

The way to use this is explained in the complete study (8). This new model gives a solid for of evaluating culture in an organization. The models were use for the construction of the check list needed to complete the fourth step of the “best practices guide for managing IT risk in banking” (2). We present the work done in the next chapter.

3. CASE OF STUDY To validate the models created for the specification of the guide, we took them and evaluated a single process. This was done in “Banco

de la República”; the Colombian central bank, and the selected

process was the cheque clearing process.

3.1 Bank and process description

This subsection describes the bank and the units that participated in this study. 3.1.1 Banco de la República The bank was created in 1923 to be the central Bank of Colombia. This entity has the responsibility to act as State Bank, to control the issue of legal tender, to receive allocations of credit and provide loans to commercial banks and the Government, to manage and direct the country’s monetary (inflation controls) and financial policy and to

carry out currency transfers with other countries of the world, amongst other functions (14). In the bank the responsible of managing IT risk are the “Unidad de de Riesgo Operativo y Continuidad (UROC)” (Operative risk and

continuity Unit) and the “Subgerencia Informática” (IT VP). The

UROC is the responsible of all the operative risks in the bank, and the IT VP is responsible for all the IT of the bank. This two units share the responsability of managing IT risk. The other unit that was involved in this study was the business area named “Subgerencia de operación bancaria” (banking operation VP),

this unit is the one responsible of the business process that will be explain next. 3.1.2 Cheque clearing process The cheque clearing process it’s the process in which all banks in the

nation cross the checks that arrive to them from other banks and change their accounts state. The process is depends of a system call “Compensación Electrónica de Cheques (CEDEC)” (electronic

cheque clearing) that does this transactions, other systems that are involve in the process are: “Sistemas Electrónicos del Banco de la República (SEBRA)” (Republic Bank electronic systems), “Cuentas

de Deposito (CUD)” (deposit accounts system), “Transmisión de

Archivos (HTRANS)” (secure file transmission). (8)

3.2 The specification by disciplines In the guide before developing the forth step, it necessary to identify the priority to develop each discipline, and as a result of it, the user of the guide decides which discipline it will develop first. In this case study this was done and the result was that the discipline with highest priority was governance, but each discipline was validated to make the guide whole. The detail and plan of the discipline step has two sections the first part is the development of a checklist based in the models previously developed, a validation with the units involved and develop an action plan that creates a roadmap to mature each discipline. The results of this will be summarize in the following section.

3.3 Findings and proposals Here are a brief explanation of the results obtained in the validation of each discipline and a small description of the respective action plan. 3.3.1 Foundation The largest part of this validation was carry out with the IT VP, more precisely with the informatics continuity and support unit; that business unit is the responsible of IT support and business continuity among the entire organization. However, the validation itself and the instrument created by the group were firstly adjusted with the UROC.


The results shown by the posterior analysis of the checklist were as follows: Build and test a business continuity plan: The continuity unit of

the Bank has been working on it during several years; it can be seen on the continuity plan that is already implemented. Even though not all the activities proposed by the checklist-model are been carried out, the majority of them are already been done. In fact, just two activities are in process of elaboration and those are the interdependencies between activities identification, and the identified threats prioritization. This is because the initiative for unifying the IT risk management at the bank started short time ago; it is still a newborn process. Now, it is important to say that even though there were business units already doing risk management, it was not done according to an organizational standard, so it is the reason why these two activities that involves more than one unit are still in developing process.

Finding and repairing IT failures: The complete set of activities planned on the checklist has been developed in the bank during several years, and the reason is a large proportion of those activities are related to operative tasks, for example identifying infrastructure failures are already part of the duties of operative units. According to the analysis carried out by implementing the checklist validation, this step is highly performed in the bank (as much in operative levels as executive levels), moreover the bank has an extensive experience at finding and repairing IT failures due to its multiple initiatives on embracing periodically cutting edge technologies and maintaining the mature ones.

Implementing controls and audits based on standard models: This last step of strengthening the foundation is the one that has been developed the less; a considerable amount of activities are still in process of implementation because the IT risk management is somehow a new model of IT administration for the bank. It is reasonable to stand out that there is no activity not been carried out in the bank, all of them are already developed or they are in developing stage. This part of fixing the foundation is more associated to executive process whereas the continuity part is more connected to operative process, for this reason one is at the moment more developed than the other. Looking at this step in detail: The service transition is the stage of IT management that

has more activities in process; this is because the infrastructure involved in the cheque clearing process does not change frequently.

The cheque clearing process is a static process that does not require constantly technology innovation, mainly because what has to be assured is the infrastructure availability.

To sum up, the business continuity management and the finding and fixing infrastructure failures are the most developed steps of fixing the foundation at the moment. The continuity plan of the bank is determined by the set of best practices created by the Disaster Recovery Institute International (DRII), and the foundations of this part of the guide are build based on good practices published by the Business Continuity Institute (BCI), however these guidelines of best practices were developed by different institutes, they are very similar and easy to compare each other. Also the IT VP of the bank is driven by two set of best practices called ITIL and COBIT, exactly the same set of best practices chosen to create this guide and complement the theory given by the framework 4-A.

3.3.2 Governance Process Discipline The validation of this discipline covers not only the cheque clearing process but the entire sets of process that involves any IT within the organization. It is for the reason that its components have a corporative reach. The following results of the validation were obtained through direct interviews to employees linked to the cheque clearing process. The interviewees were two consulting engineers from the quality area and an engineer from the UROC.

The component roles are well structured within the bank, and these roles apply to the entire organization. Although the roles names defined within the bank does not always match with those declared and proposed by the 4-A, its functions and responsibilities are very similar and sometimes equals to them.

Reviewing the IT risk management component it was found that a new unit (UROC) was created and consecutively its policies for risk management were conceived but it has not been checked again and nor have decided the periodicity of the task.

The process of IT risk identification is been carried out these days and it is been done by the UROC along with every business unit.

With regard to the collecting data model there is an IT risk taxonomy that is related to the general risk taxonomy. This taxonomy is still been revised reason why the IT risks have not been categorized neither prioritized.

Once that IT risks are clearly identified, the IT VP defines actions to take for each one of them. However, this methodology is been revised with the purpose of unifying it with the model built by the UROC. At the moment the methodology used by the informatics management covers the informatics security, availability and projects.

Business continuity plans have been created given the presence of IT incidents; all of those plans have clearly defined the amount of resources required to accomplish them.

Once the third component was validated it was found that the bank use the best practices of banking sector as “Basilea” for

example, as well IT management best practices such as COBIT, ITIL and project management professional (PMP). Those models are chosen according to the bank circumstances also it is important for the bank to evaluate the level of personalization of each model.

In conclusion, it can be seen that in the Bank of Republic the risk management in general has been implemented over several years and moreover, the IT risks management has become an important issue; making important to have an IT risks governance inside the bank. It is important to notice that at the moment this research was done several reconstruction activities for operative risk management were being carried out. 3.3.3 Culture From the culture model, we design five components that evaluate the most important behaviors in risk culture. These components are: Organizational culture. Social culture. Politics and rules. Training and awareness campaigns.


Cultural acceptance.

Each component contains a number of questions that allowed us to validate the component and know in what aspect the bank needed to work. The evaluation was done in all the units that in one way or another have a relation with the process. The results obtained show that from a cultural point of view, the two components that got the lower scores were the politics and rules and, training and awareness campaigns.

In each component a number of actions were proposed to the bank for implementation that will mature them.

Politics and rules: As the unit responsible of managing risk, it’s the UROC, this unit has

developed a set of norms, that are know thru all the process, but this politics and rules are to general and the process has different types of people involved. Also the information of each of the jobs thru the process doesn’t have specific rules for the job that generate

awareness and the definition of what of the information is public or what information is private.

Training and awareness campaigns: The UROC and the IT VP, have developed training programs and campaigns that take care of generating awareness but as the previous component they are very general. In the training, the jobs descriptions don’t have the information in risk control that is

necessary to give birth to cultural awareness behaviors.

These plans have been presented to the bank with more extensive description in the actions to develop. (8)

Because this project is the development of the detail and plan of the discipline step, after each of the disciplines were validated we developed a cross reference for the case of study showing how, working in an specific action in the governance plan can as well take effect in foundation or in culture (8) making this the final development of the project.

4. CONCLUSIONS There are three big components that make this paper, the construction of the models for each discipline, the detail and plan of the discipline step for the guide, and the validation of the step in the Bank process.

The process developed in the Bank, we observed that as the central Bank of Colombia they are aware of the necessity and value that IT risk management can bring to their environment, and are working to make risk management a general objective for them.

The construction of the models was a hard and long work of collecting information and searching for theories that support and extend the model already studied. As well as specified the guide by disciplines making it a better and much more complete tool for IT risks management. Each one of those disciplines (Foundation, Governance process, Culture awareness) is built as a unique model, making them strong and consecutively making the entire guide an accurate tool.

This work was made for IT risk management on banking sector but in the future it would be wise to generalize it for IT risk management in

any other sector or industry. Making possible to extend the IT risk management to places where it is needed.

5. References 1. Pérez, I. (2009). Riesgo Operativo. Semana del ROC (riego

operativo y continuidad). Bogota: Banco de la republica. 2. Figueroa, L. C. (2009). Guia de mejores prácticas de gestión de

riesgo de TI en el sector bancario Colombiano. Bogotá: Universidad de los Andes.

3. Westerman, G., & Hunter, R. (2007). IT Risk: Turning business threats into competitive advantage. Boston, Massachusetts: Harvard Business School Press.

4. Westerman, G. (2009). Strategic Management of IT Risk. In G. Westerman, P. Weill, & J.

5. Business Continuity Institute. (2008). Good Practices Guidelines. Reading, United Kingdom: Business Continuity Institute 2007.

6. it-processmaps. (2009). ITIL Process Maps. Recuperado el 28 de 10 de 2009, de http://en.it-processmaps.com/products/itil-process-map.html

7. ISACA. (2009). ISACA. Recuperado el 2009 de 09 de 16, de Serving IT Governance Professionals: http://www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/Obtain_COBIT/CobiT4.1_Brochure.pdf

8. Méndez, C., & Camargo, G. (2009). Especificación por Disciplinas de la Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano. Bogotá: Universidad de los Andes.

9. Santa, J. (Junio de 2009). Proyecto de grado. Análisis de marcos de gestión del riesgo de TI: Los marcos 4-A, Risk IT y la construccion de una herramienta de análisis. Bogotá, Colombia: Universidad de los Andes.

10. Rapaille, C. (2007). El Código Cultural. Editorial Norma. 11. Corella, M. A., & Reséndiz, C. R. (2008). El poder de la

comunicación en las organizaciones. Plaza y Valdes. 12. Garzon, A. (2007). Information security culture: the effect of

institutional factors and the mediating role of business continuity practices. London.

13. Hall, E. T. (1976). Más allá de la cultura. Barcelona: Editorial Gustavo Gili, SA.

14. Republica, B. d. (2009). history. Obtenido de Banco de la Republica Colombia: www.banrep.gov.co

15Grupo de Investigación en Tecnologías de Información, Organizaciones y Negocios

II. PRESENTACIÓN

Grupo de investigación: Tecnologías de Información, Organizaciones y Negocios

Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano.

Luis Carlos Figueroa Medina

Asesoras: Olga Lucia Giraldo y Andrea Herrera


Especificación por Disciplinas de la Guía de mejores prácticas en gestión de riesgos de TI en el sector

bancario colombiano.

Camilo Méndez

Gustavo Camargo

Asesor: Andrea Herrera


AGENDAqIntroducción

qMarco Teórico

qGuía de mejores prácticas de gestión de riesgo de TI

qEspecificación por disciplinas

qValidación de la guía en caso de estudio

qValidación por disciplinas

qConclusiones

qTrabajos futuros

qPreguntas


INTRODUCCIÓN

Tecnologías de Información

Riesgo para el negocio

Generación de Valor

Pérdidas


OBJETIVO GENERAL DE TESIS

BS 31100

Marco 4A

Circular 052 de SFC

Marco ITGI


Objetivo General proyecto de grado

• Construir y desarrollar un documento de análisis, valoración yseguimiento de los riesgos de TI para el proceso decompensación de cheques del Banco de la República a partir dela aplicación de la “Guía de mejores prácticas en gestión deriesgos de TI en el sector bancario colombiano” y su respectivaespecificación por disciplinas, basados en los documentosproducidos por las investigaciones realizadas en el grupo TIONdurante el año 2009, el Marco 4-A, el Marco Risk IT y el modelode riesgo de TI del Banco de la República.


MARCOS DE TRABAJO USADOS

Marco riesgode TI

Marco 4A

Marco BS 31100

Circular 052 de la SFC

Marco de gestión deriesgos del negocio

Marco de gestión deriesgos de TI

Reglamentación delsector bancariocolombiano

Marco de gestión deriesgos de TI (punto de vista de negocio)


ANÁLISIS COMPARATIVO DE MARCOS

Característica

Propósito y Definición 3,67 92% 2,78 70% 2,17 54%

Funcionamiento 2,72 68% 3,17 79% 2,45 61%

Medición y Autogestión 2,00 50% 1,83 46% 2,67 67%

Adaptación 3,33 83% 1,33 33% 3,67 92%

Integración 2,00 50% 4,00 100% 2,50 63%

TOTAL 2,74 69% 2,62 66% 2,69 67%

4A Risk IT

TOTAL

CALIFICACIÓN

BS31100



MARCO 4A

Gobernabilidad

CulturaBase Tecnológica

Objetivos de Negocio Disciplinas para mitigar el riesgo de TI


ANÁLISIS SEGÚN EL MARCO 4A DE LA CIRCULAR 052

16.58%

40.64%

38.50%

4.28%

Clasificación numerales 3-7 por objetivos de negocio del marco 4A

Total de Disponiblidad

Total de Acceso

Total de Precisión

Total de Agilidad

17%

83%

Clasificación numerales 3-7 por control a nivel ejecutivo y a nivel operativo

Total Nivel Ejecutivo

Total Nivel Operativo

74%

24%

2%

Clasificación numerales 3-7 por disciplinas

Total Base

Total Gobierno

Total Cultura


DESCRIPCIÓN DEL SECTOR BANCARIO COLOMBIANO

Bancos, Corporaciones

financieras, Cias de Financ. Cial

Personas, Empresas y Gobierno

PrestamosPersonas, Empresas y Gobierno

Ahorro

Superfinanciera(resoluciones, circulares)

Solvencia, Supervisión, cumplimiento, Sanciones

Congresos (Leyes)ViceministerioTécnico (Decretos)

Regulación Financiera, Tributaria y Cambiaria

Banco de la República(Circulares Reglamentarias)

liquidez, Omas, Préstamos

Banco de la República(Circulares Reglamentarias)

Encajes, Inversiones forzosas,Operaciones de cambio

Orden Economico Mundial, Mercados Financieros internacionales, Banco Mundial, Fondo Monetario internacional, etc.

Tomado de: Serrano, Rodriguez Javier. Mercados Financieros. Vision del sistema financiero

Colombiano y de los principales mercados financieros internacionales.


GUÍA DE MEJORES PRÁCTICAS DE GESTIÓN DE RIESGO DE TI

•Recolección de prácticas•Selección de las mejores•Construcción de la guía de mejores prácticas


RECOLECCIÓN DE PRÁCTICAS

Gestión de riesgos de TI centrada en las necesidades

del negocio

Bancos Mixtos

Banco Inversión

Banco de la

República

Bancos Mixtos

Inversión


SELECCIÓN DE PRÁCTICAS

• Prácticas implementadasen los casos de estudio

• Marco 4A • Marco Risk IT


GUÍA DE MEJORES PRÁCTICAS DE GESTIÓN RIESGOS DE TI


Paso 1 - Perfil de riesgos de TI Ideal

-0.1

6E-16

0.1

0.2

0.3

0.4

0.5

0.6

0.7Disponibilidad

Acceso

Precisión

Agilidad Banco A

Banco B

Banco C

BanRep



Paso 2 - Perfil de riesgosde TI Actual

-0.1

6E-16

0.1

0.2

0.3

0.4

0.5

0.6

0.7Disponibilidad

Acceso

Precisión

Agilidad

Banco A

Banco B

Banco C

BanRep


Paso 3 - Priorización delas disciplinas

Nivel de Madurez

Contexto Organizacional


Paso 4 - Planeación detalladade cada disciplina

Gobernabilidad



Marco Teórico



Base Tecnológica



Base Tecnológica


Crear y probar todo un plan de continuidad del negocio (BCP, Business Continuity Plan ).

Encontrar y reparar las falencias tecnológicas.

Implementar controles para monitorear el estado de TI basado en marcos estándar de la industria.


Base Tecnológica


Implementar controles y auditorias basados en estándares de la industria.

Fortalecido y complementado por ITIL y COBIT

Encontrar y reparar las falencias de la infraestructura de TI.

Reparación de la infraestructura de TI ITIL, COBIT y BCM.

Construir y probar el plan de continuidad del negocio.

Fortalecido y complementado por BCM Programme


Gobierno




Gobierno de gestión de riesgos de TI

Prácticas de

mejora

Proceso de

gobierno

Roles

Prácticas de

mejora

gobierno

Paso 4 - Planeación detalladade cada disciplinaGobierno


Gobierno


Roles

Proceso de Gobierno

Mejores Prácticas

•Gobierno del riesgo

•Evaluación del riesgo

•Respuesta del riesgo

•Gobierno del riesgo•Evaluación del riesgo




4A Risk IT


Cultura

• Fuentes

– IT risk y risk IT

– Estudios antropológicos

– Estudios cultura de riesgo

– Teorías de comunicación

– Teorías de mercadeo



Paso 4 - Planeación detalladade cada disciplinaCultura

Plantean comportamientos

Estudios antropológicos

Marcos

Formas deevaluación

Estudios culturalesDe riesgo

Define mejorespracticas

Marco de Evaluación cultural

entrenamiento comunicación

transmiten


Paso 4 - Planeación detalladade cada disciplinaCultura

Análisis cultural

Privado (secreto) Público (abierto)

No se habla Se Habla No se habla Se Habla

Elemento

a evaluar:Práctica: Implícito Explícito Implícito Explícito Implícito Explícito Implícito Explícito

Elemento

1

2

3

Practicas:1. Introducción de comportamientos en seguridad a las prácticas diarias.2. Procesos de educación y entrenamiento.3. Desarrollo de motivaciones y medios de participación, hacia la

aceptación como mecanismo formal.




Paso 5 - Medición de lasacciones de mejora

Indicadores de gestión de riesgo

estrategicos


tácticos


operativos


operativos


tácticos


operativos


Paso 6 - Retroalimentaciónde resultados

Acciones de

mejora

Revisión de

Perfiles



VALIDACIÓN DE LA GUIA CASO BANCO DE LA REPÚBLICA


BANCO DE LA REPÚBLICA

Es la institución que emite y administra la moneda legal y ejerce lafunción de banquero de bancos. Además, controla los sistemasmonetario (el dinero), crediticio (las tasas de interés) y cambiario (latasa de cambio) del país.

•Emisión de Moneda Legal.•Funciones de Crédito del Banco de la República.•Banquero de Bancos.•Funciones Cambiarias.•Administración de las Reservas Internacionales.•Banquero, Agente Fiscal y Fideicomisario del Gobierno.•Promotor del desarrollo Científico, Cultural y Social.•Informe de la Junta Directiva al Congreso de la República.


Áreas responsables de gestión de riesgos de TI en el Banco

Gerencia General

Gerencia Ejecutiva

Subgerencia de Operación Bancaria

Subgerencia Informática

Unidad de Riesgo Operativo

y Continuidad

Gerencia Tecnica


Marco de gestión de riesgosoperativos Banco de la República


Taxonomías de riesgo operativo

Categoría - Nivel 1 Categoría - Nivel 2

1,1 Servicios Externos

1,2 Servicios Internos

1,3 Productos

2,1 Apropiación indebida o malversación de activos

2,2 Conflicto de interés

2,3 Soborno

2,4 Gratificación Ilegal

2,5 Extorsión

2,6 Manipulación, falsificación o alteración de registros o documentos

2,7 Hurto o robo

3,1 Leyes y regulaciones

3,2 Políticas

3,3 Medidas cautelares

4 Accidentes Industriales

5 Lavado de activos

Clasificación de tipos de eventos de riesgo operativo (Banco República)

Fraude2

1

3 Incumplimiento

Incidencias en resultados esperados


Taxonomías de riesgo de TI


Ninguna

Intermitencia

Lentitud

Limitada

Autenticación

Autorización

Integridad

Confidencialidad

Repudiación

Clasificación de eventos para los servicios de TI

Seguridad

Acceso

Disponibilidad


DESCRIPCIÓN PROCESO COMPENSACIÓN DE CHEQUES

Entidad Presentadora

Presenta un archivo con el listado de los

cheques al cobro

CEDEC

Valida el archivo con los datos del cheque

Entidad Librada

Recibe el archivo consolidado de los

cheques de su entidad


Recibe el archivo con los cheques devueltos

CEDEC


Entidad Librada

Envía el archivo con los cheques devueltos a las entidades presentadoras

Compensación de cheques día t

Devolución de cheques día t + 1


Paso 1 - Perfil de riesgos de TI ideal Banco de la República

-0.1

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7Disponibilidad

Acceso

Precisión

Agilidad

Perfil de riesgos de TI Ideal de BanRep

Perfil de riesgos de TI Ideal de BanRep



Paso 2 - Perfil de riesgos de TIActual Banco de la República

-0.1

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7Disponibilidad

Acceso

Precisión

Agilidad

Perfil de Riesgos de TI Actual BanRep

Perfil de Riesgos Actual BanRep


Paso 3 – Priorizaciónde disciplinas

Nivel de Madurez

Contexto Organizacional

Gobierno=


Paso 4 - Planeación detallada por disciplinas

Gobernabilidad



Paso 4 - Planeación detallada (Base tecnológica).

Plan de continuidad

DRI

Marco 4A + BCM



Reparar falencias de TI

Reparaciones cotidianas. Inmediatez operativa.

Marco 4A + BCM + ITIL + COBIT.



Controles de monitoreo del estado de TI.

ITIL

Marco 4A + ITIL +

COBIT.


Paso 4 - Planeación detallada (Gobierno).

LÍDERES DE RIESGO DE CADA SUBGERENCIA

UROC Y LÍDERES DE RIESGO DE CADA

SUBGERENCIA

CONSEJO DE ADMINISTRACIÓN Y COMITÉ DE RIESGO

OPERATIVO Y CONTINUIDAD

UROC,

EQUIPO DE

INGENIEROS

Y LÍDERES

CONSEJO DE ADMINISTRACIÓN

VISIÓN

GLOBAL

EXPERTISE

LOCAL

CONSEJO DE ADMINIS

OPERATIVO

UROC,

EQUIPO DE

INGENIEROS

Y LÍDERES

LÍDER DE RIESGO

SGINF


Paso 4 - Planeación detallada (Gobierno).



Paso 4 - Planeación detallada (Cultura).

cultura organizacionalcultura social

políticas y reglamentaciónentrenamiento y divulgación

aceptación

Segmentación de Cultura


Paso 4 - Planeación detallada (Cultura).

cultura organizacional

cultura social

políticas y reglamentación

entrenamiento y divulgación aceptación

Proceso de compensación de cheques


Paso 5 – Medición de lasAcciones de mejora


Paso 6 – Retroalimentaciónde resultados


Conclusiones Preliminares


Caso de estudio:

• Se encontraron modelos de control de riesgo en TI, estosson implementados de forma diferente en las unidades denegocio. Aunque se esta trabajando para unificarlos, esteproyecto servirá como una herramienta para la unificaciónde los modelos existentes.

• Se ha encontrado que se han realizado trabajos y proyectossobre las tres disciplinas, pero unas se encuentran masdesarrolladas que otras.

Conclusiones Preliminares Proyecto de grado


Conclusiones PreliminaresConclusiones Preliminares Proyecto de grado

Proyecto:

• Fue posible detallar y especificar cada una de las tresdisciplinas, gracias a la ardua búsqueda de teorías y modelosde gestión de riesgos de TI existentes a nivel mundial.

• Los modelos desarrollados para cada una de las disciplinasson herramientas de valoración que logran cumplir con lasnecesidades para el análisis del caso de estudio.


Conclusiones Preliminares Tesis

Caso de estudio:

• El Banco de la República, ha desarrollado desde hace variosaños planes de continuidad de negocio lo cual redunda enuna plataforma tecnológica estandarizada y robusta

• La reciente creación dentro del Banco, de un área dedicadaexclusivamente al proceso de gestión de riesgos operativosda un impulso al tema de gestión de riesgos de TI dentro dela organización.



Conclusiones PreliminaresConclusiones Preliminares Tesis

Proyecto:

• La taxonomía de riesgos de TI, como una de las fuentes deriesgo operativo, definida por el Banco de la Republica facilitola aplicación de la guía de gestión de riesgos de TI propuestaen esta investigación al encontrarse similitudes entre dichataxonomía y el marco teórico propuesto.

• Los resultados obtenidos hasta el momento, con lacolaboración de estudiantes de pregrado del grupo deinvestigación ha permitido realizar un proyecto de tesis cabale integral.


Trabajos futuros Proyecto de GradoComo futuros proyectos de investigación de gestión de riesgos de TI sepueden considerar los siguientes.

• Agregar nuevas teorías a los marcos propuestos para enriquecerlos.

• Desarrollar trabajos independientes por cada una de las disciplinasbuscando teorías en áreas distintas a la ingeniería para consolidar lasprácticas existentes.

• Utilizar los marcos planteados en otras entidades para diversificarlos.


Trabajos futuros TesisComo futuros proyectos de investigación de gestión de riesgos de TI sepueden considerar los siguientes.

• Estudiar la gestión de riesgos de TI en diferentes procesos denegocio en los cuatro bancos en que se realizo la recolección deprácticas.

• Un proyecto en el cual se amplié el número de casos de estudio en elsector bancario para que ésta investigación sea mucha másrepresentativo.

• Diferentes proyectos en distintos sectores reales de la economía paraevaluar comparativamente cuales sectores tienen las mejores

prácticas de gestión de riesgos de TI.

• Complementar la guía con otros marcos de gestión de riesgos de TI.


BIBLIOGRAFÍA PROYECTO DE GRADO

• Economist Intelligence Unit. Getting smarter about IT Risk. s.l. : The Economist, The Economist - Hewlett Packard, 2008.• Westerman, George y Barnier, Brian. How Mature Is Your IT Mangement. MIT Sloan Management. Boston : CISR Research Briefings, 2008.• Westerman, George y Hunter, Richard. IT Risk: Turning business threats into competitive advantage. Boston, Massachusetts : Harvard

Business School Press, 2007. ISBN-13: 978-1-4221-0666-2.• Westerman, George. Strategic Management of IT Risk. [book auth.] George Westerman, Peter Weill and Joseph Antonellis. IT Risk and

Oversight. Boston : Center for Information Systems Research, 2009.• Figueroa, Luis Carlos. Tesis 1 Maestría. Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario. . Bogotá : s.n., 2009.• Cheng, Andres, Villa, Juan David y Pinilla, Santiago. Proyecto de grado. Gestión de riesgos de las tecnologías de la información (TI) en el

sector bancario colombianos, su implementación a través de la circular 052 de la superintendencia financiera colombiana y su estudio desde el

marco de gestión de riesgos de ti. Bogotá : s.n., 2009.• Santa, John. Proyecto de grado. Análisis de marcos de gestión del riesgo de TI: Los marcos 4A, Risk IT y la construcción de una herramienta

de análisis. Bogotá. : s.n., 2009.• Business Continuity Institute. Good Practices Guideline. Reading, UK : Business Continuity Institute, 2008.• Herrera, Andrea. BCM: Ciclo de Vida. [Notas de Clase] Bogotá : Universidad de los Andes, 2008.• ISACA. ISACA. Serving IT Governance Professionals. [En línea] 2009. [Citado el: 16 de 09 de 2009.]

http://www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/Obtain_COBIT/CobiT4.1_Brochure.pdf.• Enterprise Risk: Identify, Govern and Manage IT Risk. s.l. : IT Governance Institute, IT Risk Governance Institute, 2009.• Rapaille, Clotaire. El Código Cultural. s.l. : Editorial Norma, 2007. ISBN 978-958-45-0163-9.• Corella, María Antonieta Rebeil y Reséndiz, Celia RuizSandoval. El poder de la comunicación en las organizaciones. s.l. : Plaza y Valdes,

2008.• Hall, Edward T. Más allá de la cultura. Barcelona : Editorial Gustavo Gili, SA, 1976.• Bejarano, Adela Garzón. Information security culture: the effect of institutional factors and the mediating role of business continuity practices.

• Berry, Tim. The Plan-As-You-Go Business Plan. Canada : Entrepeneur Media Inc., 2008. 1-59918-190-08.• Banco de la Republica. La historia del Banco. Banco Central. [En línea] 2009. [Citado el: Septiembre de 28 de 2009.]

http://www.banrep.gov.co/documentos/el-banco/pdf/historia-banco-sept.pdf.• Presentación del Sistema Integral de Riesgo Operativo SIARO del Banco de la República marzo de 2009. 2009.• República., documento interno de la Subgerencia Informática del Banco de la. SGINF-PN 21 Subgerencia de Informática Dirección Estratégica

2008.

• República, documento interno de la Subgerencia Informática del Banco de la. SGINF-PN 27 Gobierno Tecnológico en la Subgerencia de

Informática.

• SGINF-PN 25 Gestión de riesgos para la Subgerencia de Informática 2008.

• SGINF-PN 18 Políticas de Seguridad de la información.

• Pagina web Banco de la República . http://www.banrep.gov.co/sistema-financiero/sip_ch_defini.htm#1. [En línea] 15 de 10 de 2009. • BCM Institute. Business Continuity Management (BCM). [En línea] MediaWiki, Marzo de 2009. [Citado el: 2 de Septiembre de 2009.]

http://en.bcmpedia.org/wiki/.• DRI International. DRII The institute For Continuity Management. [En línea] 2009. [Citado el: 12 de 09 de 2009.] https://www.drii.org.• it-processmaps. ITIL Process Maps. [En línea] 2009. [Citado el: 28 de 10 de 2009.] http://en.it-processmaps.com/products/itil-process-map.html.


BIBLIOGRAFÍA TESIS

• de Revista Windows TI Magazine No 135 septiembre de 2008 en línea disponible en http://www.windowstimag.com/N%C3%BAmerosanteriores/N%C3%BAmero119Abril2007/EntrevistaLagesti%C3%B3nderiesgosdeTI/tabid/167/Default.aspx.

• (Referencia de revista perspectivas Microsoft No 13 otoño de 2004 en línea disponible en) http://www.microsoft.com/spain/enterprise/perspectivas/numero_13/estrategia.mspx.

• (Referencia de revista Facultad de Ciencias Económicas Universidad Militar Nueva Granada en línea disponible en) http://www.umng.edu.co/revcieco/2004/DIC%202004/2%20EFICIENCIA.pdf

• BS31100: 2008 BSI British Standard “Risk Management- Code of Practice", 2008

• G Westerman, R Hunter. “IT RISK”. Boston : Harvard Business School Pres, 2007. pp.1-204

• (Referencia de artículo en línea de ISACA disponible en) http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=47643&TEMPLATE=/ContentManagement/ContentDisplay.cfm.

• (Referencia en línea disponible en http://www.superfinanciera.gov.co/NormativaFinanciera/Archivos/ ce052_07.rtf

• J Santa. “Análisis de marcos de gestión del riesgo de TI: los marcos 4A, Risk IT y la construcción de una herramienta de análisis”. Proyecto de

grado Ingeniería de Sistemas. Universidad de los Andes, 2009. pp 72 - 111

• (Referencia a página web disponible en http://www.superfinanciera.gov.co/ nuestra superintendencia/misión

• Ley 45 de 1990 Diario oficial No 39.607 de 19 de diciembre de 1990 en línea disponible en http://www.superservicios.gov.co/basedoc/docs/leyes/l0045_90.html

• J Serrano. “Mercados Financieros. Visión del sistema financiero Colombiano y de los principales mercados financieros internacionales.”. pp 17-54

• Fabozzi, Frank J & Modigliani, Franco. Capital Markets: Institutions and Instruments. s.l. : Prentice Hall 3ª Edición.

• (Referencia Revista Dinero. en línea 28 de 03 de 2008, disponible en. http://www.dinero.com/wf_InfoArticulo.aspx?IdArt=46088

• A Cheng, S Pinilla, y J Villa. “Gestión de riesgos de las tecnologías de la información (TI) en el sector bancario colombiano, su implementación a través de la circular 052 de la superintendencia financiera colombiana y su estudio desde el marco de gestión de riesgos de TI 4A”. Proyecto

de grado Ingeniería de Sistemas. Universidad de los Andes, 2009.

• G Westerman. B Barnier. How Mature is your IT Risk Management?. Center for Information Systems Research, Sloan School for Management MIT. December 2008.

• G Westerman. Building IT Risk Management Effectiveness. Center for Information Systems Research, Sloan School for Management MIT. July 2004.

• Pagina WEB Definicion.de. [Online] http://definicion.de/plan-de-accion/.

• C Méndez, y G Camargo “Especificación por Disciplinas de la Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano.” Proyecto de grado Ingeniería de Sistemas. Universidad de los Andes, en desarrollo.

• Pagina web Banco de la República [En línea] citado mayo de 2009 http://www.banrep.gov.co

• Presentación del Sistema Integral de Riesgo Operativo SIARO del Banco de la República marzo de 2009.

• Pagina web Banco de la República [En línea] citado mayo de 2009 http://www.banrep.gov.co/sistema-financiero/sip_ch_defini.htm#1

• G Westerman, R Hunter. IT Risk Management: From IT Necessity to Strategic Business Value. 2006. p3


Preguntas


PARTE B


III. CAPÍTULO 1 - INTRODUCCIÓN

1.1 Antecedentes

Una de las definiciones de riesgo según la real academia de la lengua es “Contingencia o proximidad

de un daño”4; contingencia entendida como la “Posibilidad de que algo suceda o no suceda.”5, y daño

como “Causar detrimento, perjuicio, menoscabo, dolor o molestia”6. Teniendo en cuenta esta

definición se podría preguntar, ¿a qué hace referencia esto con respecto a Tecnologías de Información

(TI)?, pues bien en el campo informático es posible identificar todos estos elementos en la definición

de riesgo de TI que presenta George Westerman en su libro de IT Risk como “potencial que un evento

no planeado que involucra una falla o un mal uso de TI amenace un objetivo empresarial”7. Esta

definición genera una perspectiva de riesgo que, para el interés de este proyecto de grado, enmarca de

forma global el medio en donde este trabajo es desarrollado ya que incluye los posibles casos donde TI

y riesgo, se encuentran. A demás delimita el alcance y campo de acción del proyecto.

¿Pero qué conlleva a pensar en riesgo de TI? y ¿Cuál es la razón para evaluarlo y controlarlo?

“Las empresas se han apoyado en TI para mejorar su eficiencia y productividad. Entregándole a éstas

una buena proporción de responsabilidades críticas para el negocio. Pero como es bien sabido no existe

tecnología perfecta, éstas presentan deficiencias, vulnerabilidades, errores, etc. Además si los procesos

de negocio dependen de TI el riesgo incrementa y más aun si ésta, es utilizada por personas en el

desarrollo de dichos procesos; generando lo que se conoce como riesgo de TI. Y es necesario

gestionarlo porque el no hacerlo, puede generar altos costos para la organización”.8

4 Tomado de: Diccionario de la real academia de la lengua, definición riesgo. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=riesgo 5 Tomado de: Diccionario de la real academia de la lengua, definición contingencia. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=contingencia 6 Tomado de: Diccionario de la real academia de la lengua, definición dañar. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=da%F1ar 7 Tomado de: IT Risk Turning business threats into competitive advantage; Westerman, George and Hunter, Richard. 8 Tomado de: Getting smarter about IT Risk.


Por esta razón se han presentado estudios que desarrollan marcos y herramientas como el del

Massachusetts Institute of Technology (MIT) denominado Marco de gestión de riesgos de TI 4-A

(Marco 4-A), cuyo objetivo es gestionar el riesgo existente de TI, mediante una evaluación de riesgos

desde un enfoque de negocios. Siguiendo esta tendencia en la Universidad de los Andes se están

llevando a cabo estudios sobre el manejo de riesgo de TI y en los últimos trabajos se han enfocado los

esfuerzos en generar modelos para el sector bancario colombiano.

1.2 Justificación

El sector financiero de un país y en general a nivel mundial es el que mueve y permite el desarrollo

adecuado de las economías, ya sea de países industrializados o en desarrollo, como es el caso

Colombiano. De acuerdo con esto, a la velocidad con la que las TI evolucionan y la importancia que

tiene la información, para todas y cada una de las organizaciones del sector, se hace más que

importante realizar una adecuada Gestión de Riesgos de TI, que permita hacer un uso adecuado de

recursos tecnológicos y un manejo conveniente de la información.

Es válido resaltar, que quien marca la pauta en el ámbito Nacional, es el Banco de la República, ya que

es el banco central del país y como tal, es quien debería ser líder en procesos como Gestión de

Continuidad y de Riesgo. Motivo principal para que sea el Banco de la República sobre el cual y para

el cual se harán los análisis, estudios y se darán las valoraciones correspondientes, para la generación

detallada de la “Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario

colombiano” en cada una de las disciplinas que propone el Marco 4-A del MIT, complementadas por el

marco Risk IT del IT Governance Institute y otros autores que fortalecerán la guía.

La elaboración de la Guía, herramienta fundamental en la gestión de riesgos de TI, es finalmente la

unión de esfuerzos, tanto del Banco como de la Universidad de los Andes, en un proceso que ha

involucrado varios proyectos de pregrado y tesis de maestría surgidas de iniciativas del Grupo de

investigación del departamento de Ingeniería de Sistemas denominado TION.

1.3 Objetivo General y Específicos

El Objetivo General de ésta investigación es:


- Construir y desarrollar un documento de análisis, valoración y seguimiento de los riesgos

de TI para el proceso de compensación de cheques del Banco de la República a partir de

la aplicación de la “Guía de mejores prácticas en gestión de riesgos de TI en el sector

bancario colombiano” (1) y su respectiva especificación por disciplinas, basados en los

documentos producidos por las investigaciones realizadas en el grupo TION durante el

año 2009, el Marco 4-A (2), el Marco Risk IT (3) y el modelo de riesgo de TI del Banco

de la República.

Los objetivos específicos son:

- Detallar las tres disciplinas dadas por el Marco 4-A, Base tecnológica, Gobierno y

Cultura para complementar la “Guía de mejores prácticas en gestión de riesgos de TI en

el sector bancario colombiano”.

- Aplicar en el proceso de compensación de cheques del Banco de la República la Guía

complementada para obtener resultados que permitan un análisis de la herramienta, y su

respectiva retroalimentación.

- Consolidar la información obtenida en la evaluación de la herramienta para validar y

retroalimentar la “Guía de mejores prácticas en gestión de riesgos de TI en el sector

bancario colombiano”.

1.4 Alcance

En este proyecto de grado se especifica la “Guía de mejores prácticas en gestión de riesgos de TI en el

sector bancario colombiano” (1) en cada una de las disciplinas propuestas en el Marco 4-A base de

construcción de la guía. Para cada disciplina del marco 4-A se desarrollan modelos complementados a

partir de la integración de buenas prácticas en los temas claves de cada disciplina. Estas

investigaciones dan como fruto modelos expandidos que facilitan la evaluación de cada disciplina

propuesta y que justamente se convierten en la especificación de la guía mencionada. Los modelos se

aplican en el proceso de compensación de cheques del Banco de la República, validando la cohesión de

los mismos. Por último se desarrolla el análisis de los resultados obtenidos.

1.5 Metodología


Tomando bibliografía especializada en el Marco 4-A, las tesis y proyectos de grado previos a este

documento y las investigaciones hechas en cada una de las disciplinas específicas del marco, se

detallará la guía desarrollada en la tesis 1 de Maestría de Luis Carlos Figueroa ("Guía de mejores

prácticas en gestión de riesgos de TI en el sector bancario colombiano"), puntualizando en cada una de

las disciplinas existentes en el Marco 4-A de dicho trabajo, con los complementos obtenidos para éstas.

Para lograr esto se buscará mejorar, actualizar y profundizar en dichas disciplinas, mediante nuevos

conocimientos y resultados encontrados en el campo de Gestión de Riesgos en TI.

Con esta herramienta ya detallada por disciplinas se procederá a valorar el proceso de compensación de

cheques del Banco de la República, con el fin de estudiar la integridad, coherencia y validez de la Guía

para cualquier otro proceso que involucre activos de TI del Banco. Esta valoración permitirá retro

alimentar y auto evaluar la Guía, con lo que se cumplirá el primer ciclo de recursión de la

administración de la herramienta en el que tanto la herramienta como el proceso son actualizados y

mejorados constantemente, en otras palabras madurando en términos prácticos la Guía.

1.6 Resultados esperados

Al final de este proceso se espera obtener los insumos necesarios, que permitan especificar la "Guía de

mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano", gracias a los

resultados del trabajo desarrollado en este proyecto de grado.

Para que esto ocurra es necesario haber obtenido marcos expandidos para cada una de las disciplinas

planteadas en el Marco 4-A. Desarrollar una evaluación del proceso de compensación de cheques del

Banco de la República con los marcos previamente construidos. Obtener resultados en el análisis y

valoración del proceso sobre la gestión en el riesgo de TI y que los resultados que entregue sean

comparables y medibles para su posterior uso.


IV. CAPÍTULO 2- MARCO TEÓRICO

2.1 El marco 4-A y los trabajos previos

Los riesgos generados por la implementación y puesta en servicio de cualquier TI son y deben ser

administrados no sólo por el departamento de TI sino por la administración de la organización en

general. Pensar lo contrario y dejar la responsabilidad netamente a la unidad de TI, cuyas funciones

principales son todas aquellas relacionadas con elementos de TI, es un error común en las

organizaciones de hoy en día; aunque son ya muchas las organizaciones que tienen una visión mucho

mas sistémica de los riesgos de TI, aun la mayoría siguen manejando y gerenciando el tema de forma

operativa (4). Pero la razón es simple, la alta gerencia de las empresas, los denominados Chief

Executive Officers (CEO’s), consideran por lo general que todas las TI de la compañía que no están

“directamente” relacionadas con el “core” del negocio, no son en sí relevantes y esto sumado a la falta

de conocimientos técnicos, hace que la falta de interés sea el principal factor del problema actual (3).

Existen otros factores como por ejemplo la gestión de TI del Chief Information Officer (CIO), quién

debe liderar el cambio de mentalidad y de paradigmas tecnológicos al interior de la empresa (5). Pero,

sin importar la causa, es necesario que todas y cada una de las organizaciones vean a TI como un

elemento transversal en los procesos de negocio y, como tal involucrarla de forma directa y efectiva

con el resto de unidades de negocio y viceversa, de esta forma todas las TI involucradas en los

procesos de la empresa estarán alineadas con los objetivos de cada proceso y sucesivamente con los de

la empresa.

Cada uno de los procesos debe “conocer” las fuentes y los soportes de TI en los que se apoya, o sobre

los que se ejecuta para su óptimo funcionamiento, y de esta forma tener claro qué parte de la base

tecnológica usa cotidianamente. Es claro que no todos los miembros de la organización deben tener

suficiencia técnica sobre TI, pero si deben entender cómo ésta afecta el negocio y deben saber (no de

forma detallada) que herramientas se usan en el negocio a diario y poder concienciar de las

repercusiones organizacionales que tiene el mal uso o el simple mal funcionamiento de éstas (6). En

otras palabras, ser totalmente conscientes de los riesgos de TI y hacer estos relevantes para la

organización. También es necesario que los responsables de TI entiendan cuál es el negocio, cuál es su

participación en la cadena de valor de la organización, cuál es la responsabilidad de TI en los procesos


y los riesgos que esta responsabilidad genera al negocio (4). Dando como resultado una mejor

participación y mejoramiento de TI para el manejo de riesgo.

Una gestión de riesgos de TI basada en los anteriores conceptos no sólo permite que dicha gestión sea

más efectiva sino que, tal como se encontró en investigaciones recientes realizadas por el MIT, además

ayuda a mejorar la cultura de la unidad de TI y la forma en que los activos de TI son estructurados. (7)

Teniendo en cuenta lo anterior en conjunto con lo planteado en el primer capítulo, es necesario explicar

de forma más específica la información pertinente ya existente para el desarrollo de este estudio. Por lo

tanto, a continuación se explican las teorías y los antecedentes propios de ésta investigación.

2.1.1 Marco de Gestión de Riesgos de TI 4-A (Marco 4-A)

Es uno de los Marcos de trabajo para la administración y gestión de riesgos de TI, fue desarrollado

por el MIT, más precisamente por los investigadores George Westerman y Richard Hunter, y fue a

su vez el resultado de múltiples investigaciones llevadas a cabo por el CISR (Center for

Information Systems Research).

El Marco 4-A (2) busca darle una visión holística a la gestión de riesgos, la cual hasta el día de

hoy se ha enfocado en administrar riesgos operativos en el área de TI en la mayoría de

organizaciones. Dando un giro completo a la forma en cómo se deben enfrentar estos riesgos

potenciales, pero no solo al interior de los departamentos de TI sino de toda la organización, ya

que propone ver cada uno de estos, no como simples cuestiones técnicas sino como parte de

procesos de una o varias unidades de negocio de la empresa. De esta forma se hace evidente, que

todas las TI involucradas en el negocio son de vital importancia para poder llevar a cabo todos y

cada uno de los procesos de la organización. En otras palabras las TI se convierten en objetos

transversales a toda la organización y como tales deben ser “gobernadas” de una forma más

consciente por cada miembro involucrado de forma directa o indirecta. Por lo tanto, se hace

necesario culturizar y concientizar a todos los niveles organizacionales de la importancia,

relevancia y dependencia de las TI usadas diariamente en la organización.

De acuerdo con el Marco, es posible dar inicio a esta visión sistémica al evidenciar la existencia

de cuatro objetivos de negocio que son: Disponibilidad (Availability), Acceso (Access), Precisión


(Accuracy) y Agilidad (Agility) (conocido como 4 A por sus siglas en inglés o DAPA por sus

siglas en español), cada uno de éstos se relaciona con funciones específicas de todos los servicios

de TI en la organización.

Una definición puntual de estos objetivos de negocio es la siguiente:

- Disponibilidad: mantener los procesos del negocio funcionando.

- Acceso: proveer la información a las personas correctas.

- Precisión: asegurarse que la información es precisa, oportuna y está completa.

- Agilidad: capacidad del sistema para cambiar a un costo y velocidad aceptables.

Estos objetivos son representados en una pirámide denominada “IT risk piramid” o pirámide de

riesgo de TI, en donde se muestra la dependencia entre estos.

Figura 1 - Pirámide riesgo TI

Además de dichos objetivos organizacionales existen tres disciplinas o “core disciplines” en la

Gestión de Riesgos de TI que son Base Tecnológica (Foundations), Gobierno de TI (Governance)

y Cultura (Culture), definidas así:

- Base Tecnológica: una base de infraestructura tecnológica, aplicaciones y personal de

soporte que está bien estructurada, bien administrada, y tiene el nivel de complejidad

adecuado para el tamaño de la organización y sus respectivas soluciones basadas en

tecnología.


- Gobierno de TI: procedimientos y políticas que proveen una vista a nivel organizacional

de los riesgos de TI.

- Cultura: cada miembro de la organización tiene conocimiento y es consciente de los

riesgos, además de sus posibles tratamientos.

La relación de estos objetivos se representa en la gestión de riesgos de TI de la siguiente forma:

Figura 2 - Las disciplinas de gestión de riesgo de TI9

La ubicación de las disciplinas no necesariamente indica que una es más importante o relevante

que las otras dos. El realizar control de riesgo de TI desde estas disciplinas da un punto de vista

más sistémico del riesgo y el poder manejarlo, define su relación con el valor del negocio

(Business Value). La disciplina de gobierno es la que especifica las normas y pautas a seguir tanto

en cuestiones culturales como tecnológicas. Pero son finalmente la Base Tecnológica y la Cultura

las disciplinas que deben apropiarse de los riesgos existentes de TI. La gestión de riesgos de TI

debe ser la armónica conjunción de la administración eficaz y eficiente de las tres disciplinas.

Finalmente, cada disciplina estará expuesta a riesgos particulares de acuerdo con su naturaleza, sin

embargo, la materialización de éstos podría afectar a todas y cada una de las partes. Lo que en

general marca la diferencia entre disciplinas son los factores de riesgo de cada una, a continuación

se presenta la lista expuesta por Westerman (8).

9 Tomado de: Strategic Management of IT Risk, Westerman, George; Weill, Peter; Antonellis, Joseph, pg. 10


Figura 3 - Factores de Riesgo de TI.10

Factores de Riesgo de TI (Traducción):

- Infraestructura y tecnología:

- Eficacia en la administración de la infraestructura.

- Grado de estandarización.

- Edad de la tecnología existente.

- Aplicaciones e Información:

- Complejidad de la arquitectura.

- Redundancia.

- Consistencia de los datos.

- Acoplamientos entre los procesos de negocio.

- Habilidades de las personas:

- Habilidades de planeación.

- Reclutamiento/Entrenamiento.

- Relación entre TI y las demás unidades de negocio.

- Proveedores y demás socios:

10 Strategic Management of IT Risk, Westerman, George; Weill, Peter; Antonellis, Joseph


- SLA´s (service level agreements).

- Uso de métodos de la firma/Estándares.

- Fuente Única.

- Tolerancia a riesgos del cliente.

- Políticas y procesos:

- Controles de arquitectura.

- Políticas de uso de TI.

- Procesos de Gobierno de TI.

- Requerimientos regulatorios.

- Organizacional:

- Reducción de costos.

- Complejidad organizacional.

- Procesos de financiación.

- Historia de riesgos.

De acuerdo a los factores mencionados, cada una de las disciplinas se relaciona de forma directa

con la organización, afectando a su vez las demás disciplinas de manera directa o indirecta pero,

entre sí tienen un orden estructurado de relacionamiento (Figura 4).

Figura 4 – Relación de las disciplinas con el negocio11

11 Traducción: Strategic Management of IT Risk, Westerman, George; Weill, Peter; Antonellis, Joseph; pg 11.


La relación que se da entre las disciplinas con la organización como se presento en la figura 4, es

el punto de partida en el desarrollo de este proyecto de grado. Y por esta relación es posible

comenzar a profundizar en cada una de las disciplinas de forma teórica. Pero antes de esto se

deben revisar los estudios realizados en la Universidad de los Andes sobre dicho tema.

2.1.2 Trabajos previos realizados en la Universidad de los Andes.

Además del Marco 4-A desarrollado por el MIT, los principales insumos de este proyecto de

grado son los trabajos ya realizados en el tema de gestión de riesgos de TI, al interior del grupo de

investigación TION de la Universidad de los Andes; específicamente son dos proyectos de grado y

una tesis de maestría. Estos documentos complementan mediante sus respectivos resultados y

conclusiones este proyecto de grado.

Los primeros trabajos son: el desarrollado por Luis Carlos Figueroa en su trabajo de tesis 1 de

nombre: “Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano”

(1) y el proyecto de grado realizado por Juan David Villa, Andres Cheng y Santiago Pinilla (9),

estos dos trabajos se complementan ya que recolectan información acerca de las prácticas actuales

en gestión de riesgo de TI en bancos con operaciones en Colombia. El proyecto de grado utiliza

como referencia el marco 4-A y la reglamentación existente para el sector bancario, y el estudio de

maestría varia principalmente en el enfoque ya que utiliza un marco de gestión de riesgos

corporativos BS 31100, el marco 4-A, el marco Risk IT y la normatividad nacional del sector

bancario para hacer su análisis. Es necesario resaltar, que este trabajo continúa en desarrollo y su

autor, ha colaborado en la construcción de este documento, especialmente con la información

correspondiente a la disciplina de gobierno. Se espera que los resultados obtenidos en este

documento sirvan de insumo para la conclusión de su tesis.

También es necesario nombrar el proyecto de grado de John Santa (10), el cual es finalmente un

documento que mediante el estudio de marcos de gestión de riesgos de TI, más específicamente

los marcos “4-A” y “Risk IT” (creado por el IT Governance Institute (ITGI)), crea una

herramienta o guía de análisis mediante la cual complementa la teoría y las posibles oportunidades

de mejora de uno con la teoría y fortalezas del otro, guía que será usada para consolidar toda la

especificación de la guía, ya que complementa y alimenta eficazmente el marco 4-A con el marco

Risk IT.


Si el lector desea conocer mejor estos documentos se encuentran enunciados dentro de la

bibliografía; todos hacen parte de los documentos de las investigaciones realizadas por el grupo

TION de la Universidad de los Andes.

2.2 Las disciplinas

En este numeral del capítulo se profundiza de manera independiente en cada una de las disciplinas

buscando integrar buenas prácticas reconocidas en los temas claves de cada una con el fin de tener un

mayor entendimiento de los campos de acción del trabajo y un conocimiento teórico que permita

construir los modelos bases de la especificación de la guía para su posterior validación en el caso de

estudio planteado.

Esta profundización se hace de acuerdo al orden en el que se encuentran las disciplinas en la pirámide

de la figura 1, que es de la forma en cómo lo exponen Westerman y Hunter (2) en el desarrollo de la

teoría del marco 4-A, iniciando con Base tecnológica, seguido de Gobierno de riesgos de TI y

terminando con Cultura. Cada disciplina se describe, dando su definición con respecto a TI y se

detallan las actividades a desarrollar para realizar una gestión de TI adecuada sobre la disciplina.

También se menciona, para cada una, el conjunto de guías y de mejores prácticas relacionadas con

dicha gestión de riesgos, refiriendo cada punto de ser necesario con el marco Risk IT.

2.2.1 Base tecnológica

Aunque esta es la primera disciplina a tratar, debe hacerse la aclaración que el enfoque del

Marco es top-down (el enfoque se hace desde Gobierno), pero debe apoyarse en una buena

administración de TI para cumplir a cabalidad todos sus objetivos de mejores prácticas.

Partiendo de esa premisa, en este numeral de las disciplinas, se definirá que es Base

Tecnológica, sus implicaciones en la organización, y se darán los pasos a seguir para

encaminar la organización hacia una gestión de riesgos de TI adecuada, desde la re-invención

de una base tecnológica sólida.

Primero es necesario definir que es Base Tecnológica: “Es el conjunto integrado por

infraestructura, aplicaciones, tecnología de soporte y personas que permiten que los procesos

de negocio funcionen apropiadamente. Una base tecnológica inmadura – administrada


pobremente o de estructura muy compleja - es la receta perfecta para la materialización de

cualquier tipo de riesgo. Actualizaciones inconsistentes de software y una compleja

interdependencia permite que el sistema falle constantemente, sea difícil de recuperar y aun

peor que sea imposible de cambiar. Por otro lado una base tecnológica madura es

estadísticamente el elemento más importante para reducir riesgos y mejorar el desempeño de

TI”12.

Tal como se había mencionado, TI es transversal a la organización, y de la misma forma cada

problema hace parte de todo el sistema, adicionalmente, TI es responsable de algunas de las

interacciones entre una o todas las unidades del negocio, y del negocio con el exterior. Por lo

que es conveniente identificar la mayoría de las fuentes de futuros problemas y así poder tomar

medidas con respecto a estas posibles falencias. A continuación se mencionan las fuentes

principales de dichos problemas de TI (8).

Disponibilidad:

- Nivel alto de deserción del staff de TI.

- Infraestructura poco o nada estandarizada.

- Administración de las actualizaciones ineficiente.

- Uso de tecnología vieja y obsoleta.

- Gestión pobre de recuperación y de copias de seguridad.

- Entendimiento pobre de la relación entre las aplicaciones y los procesos.

- Pérdida de habilidades de la unidad para poner en marcha nuevas iniciativas.

- Regulaciones ineficientes.

Acceso:

- Datos no ordenados categóricamente.

- Urgencia de estandarización de las aplicaciones.

- Red no confiable hacia todos los puntos.

- Falta de controles internos en las aplicaciones.

Precisión:

- Las aplicaciones no son compatibles o sencillamente no abarcan los requerimientos

necesarios del negocio.

- No existe manual alguno de integración de datos.

12 IT Risk Turning business threats into competitive advantage; Westerman, George and Hunter, Richard; Pg 36.


- Implementaciones significativas recientemente terminadas o que se están llevando

aún a cabo.

Agilidad:

- Relación pobre entre TI y las demás unidades de negocio.

- Inadecuada planeación de proyectos (no pueden ser completados por falta de

presupuesto o son terminados en tiempo mucho más largo del estimado).

Aunque los problemas y sus fuentes parecieran presentarse de forma singular en las disciplinas

sus consecuencias afectan de igual forma a todos, ya sea como consecuencia inmediata o

secundaria, por lo tanto no se debe olvidar que como sistema toda situación particular afecta

“sistémicamente” a la organización, y así se verán también reflejadas las consecuencias de una

u otra solución propuesta; factor importante para realizar una gestión de riesgos adecuada,

eficaz y eficiente, prevista desde del negocio y llevada a cabo desde la base tecnológica.

Ahora bien vale la pena resaltar algunos de los beneficios desarrollados mediante la gestión de

riesgos de TI dirigida por la base tecnológica, los cuales son (2):

- Al encontrar y reparar las vulnerabilidades evidenciadas en la estructura tecnológica

existente se corrigen de forma inmediata las debilidades del sistema, dándole tiempo

adicional a la organización para realizar mejoras a largo plazo en otros campos.

- La simplificación de TI es a largo plazo una de las mejores decisiones en la

administración de la base tecnológica ya que se reducirán los costos así como los

riesgos intrínsecos del sistema.

- La simplificación además reduce los riesgos de los 4 objetivos de la organización y

hace más fácil la gestión con relación a las otras dos disciplinas.

Es necesario también tener en cuenta las siguientes consideraciones al hacer una buena gestión

de riesgos de la base tecnológica (8):

- Los esfuerzos iníciales para encontrar y reparar las vulnerabilidades que hay en TI

pueden ser substanciales.

- Puede ser difícil y costoso ir detrás de la simplificación de la infraestructura para

simplificar las aplicaciones.


- La simplificación toma tiempo considerable y se hace por lo general de forma

incremental.

Es válido pero errado pensar que en muchas ocasiones es mejor dejar las cosas como se

encuentran actualmente ya que parecieran funcionar de forma correcta pero las peticiones de

cambio, que consciente o inconscientemente exige un entorno globalizado, junto con la

velocidad de innovación y mejora de todas las TI, harán que tarde o temprano se tengan que

hacer cambios sustanciales relacionados con las mismas TI, al interior de la organización.

Algunas técnicas administrativas que permiten realizar dichos cambios, dando prioridad a la

gestión de riesgos enfocándose en la base tecnológica, proporcionando herramientas a la

organización para tener una mejor Administración de TI, pueden verse en la figura 5

presentada a continuación:

Figura 5 - Mecanismos Administración TI

Para encaminar la base tecnológica de la organización hacia una TI sólida que además tenga

riesgos de baja incidencia y baja probabilidad de ocurrencia es necesario tener un sistema de TI

y de aplicaciones claramente estructurado que sea bien administrado, esté provisto de controles

suficientes y, además tenga el soporte adecuado. Las características generales de dicha

estructura se pueden ver en la figura 6.

Disponibilidad

•Configuración de controles.

•Reuniones regulares CIO con ejecutivos.

•Creacion BCP y pruebas respectivas

Acceso

•Administración de identificación y acceso

•Arquitectura empresarial adecuada.

•Administración de acceso y RH deben trabajar unidos.

•Administración de proveedores de TI.

Precisión

•Auditoría interna.

•Revisión de proyectos para la definición de estándares de la información.

Agilidad

•Administración de un portafolio de proyectos.

•Metodología espécifica para el desarrollo de proyectos.

•Relación estrecha entre TI y los demás gerentes. (Reuniones CIO - CXO's)

•Arquitectura empresarial adecuada.


Figura 6 - Base tecnológica sólida.

De acuerdo al marco, las medidas a tomar para hacer el cambio adecuado, y encaminar toda la

organización hacia una adecuada gestión de riesgos de TI, deben ser establecidas de tal forma

que la re-configuración y la re-creación de la base tecnológica se haga en el orden correcto, y

este orden es el relacionado con la pirámide de riesgos de TI (Figura 1). En otros términos debe

iniciarse con los riesgos relacionados con la Disponibilidad y terminar con los que afectan la

Agilidad del sistema y en general de la organización.

La razón principal es que cada falencia resuelta en alguno de los niveles de la pirámide,

eventualmente afectará de una u otra forma los riesgos ubicados en niveles superiores, y tal

como lo expone el Marco 4-A la mejor aproximación a la reducción de riesgos de TI en

términos de impacto organizacional es la que se hace desde la visión de Gobierno de TI (Figura

1); sin embargo, en términos generales cada tema organizacional asociado con gestión de

riesgos de TI siempre llevará intrínsecos riesgos exclusivos de la base tecnológica. Así que

realizando una buena gestión en esta disciplina, se fortalecerá de inmediato las otras dos y, para

hacer esto es necesario analizar y si es necesario, rediseñar la infraestructura de las TI con las

que se cuenta para fortalecer sus falencias. El marco es explicito en el tema y da tres pasos

fundamentales para iniciar toda la administración de la gestión de riesgos de TI, pasos que en

general van encaminados a iniciar una administración adecuada de la unidad de TI y sus

activos.

Los tres pasos a seguir

Estandarización de la infraestructura.

Base de aplicaciones bien

integrada.

Control de acceso a datos y

aplicaciones.

Staff de soporte con conocimientos

adecuados.

Tecnología está siempre

actualizada. (parches de

seguridad, etc.)

Estructuras de datos y

definiciones de procesos

documentados.


La mejor forma para llevar la base de la pirámide a un nivel competitivo incluye tres pasos que

son (2):

1. Crear y probar todo un plan de continuidad del negocio (BCP, Business Continuity Plan ).

2. Encontrar y reparar las falencias de TI.

3. Implementar controles para monitorear el estado de TI basado en marcos estándar en la

industria.

Después de completados estos tres pasos la organización podrá centrar esfuerzos en la tarea de

la simplificación de TI. Hay que tener en cuenta que tanto los tres pasos como la simplificación

son tareas que llevan tiempo y hacen uso de recursos de toda la organización. A continuación

se describen en detalle cada uno de los pasos:

Crear y probar un plan de continuidad del negocio (BCP (2)):

Este primer paso busca crear en la organización un nivel avanzado de concientización de la

importancia de las TI mediante la interiorización organizacional de su valor en la actividad

diaria, permitiendo que se creen planes de acción emergentes en caso de presentarse cualquier

eventualidad que interrumpa la normal evolución y realización de los procesos al interior de la

organización. Una descripción más formal de lo que significa BCM (administración de la

continuidad del negocio) en términos teóricos y prácticos es la siguiente: BCM es una

disciplina organizacional y un conjunto completo de procesos que identifica los impactos

potenciales que amenazan a una organización, y provee a la organización la capacidad de crear

respuestas efectivas que permitan salvaguardar los intereses de los Stakeholders, así como la

reputación de la organización misma (2). BCM es además tal como Westerman expone en su

teoría “un potente motor que jala un tren considerablemente largo”13, ya que permite ver las

debilidades y los riesgos más importantes que hay en la base de la pirámide (Disponibilidad),

ayuda a mitigar de forma adecuada y eficiente la mayoría de los riesgos más inmediatos e

importantes que la organización pueda enfrentar, y crea las bases sobre las que se cimentará la

nueva y sólida gestión de riesgos de TI de cada uno de los objetivos del negocio. Además,

cambia la forma en cómo la unidad de TI y el resto de unidades trabajan en conjunto para

manejar las crisis a las que a veces se enfrentan las organizaciones, pues ayuda a que las

personas involucradas con TI puedan ver la importancia de su adecuado funcionamiento para el

13 Traducción: IT Risk Turning business threats into competitive advantage; Westerman, George and Hunter, Richard.


negocio, además de las repercusiones y consecuencias que tienen los riesgos de TI en el resto

de la organización. Como beneficio principal de un buen BCM está el concerniente a los

CXO`s quienes mediante una buena gestión del CIO, estarán en la capacidad de entender la

importancia que tiene la unidad de TI para el negocio y el rol que ésta cumple al interior de la

organización, integrando de una manera menos drástica una visión más real del valor que

tienen las TI en todos los procesos que se llevan a cabo en la organización a diario. Sin

embargo, el desarrollo de un plan sólido de BCP de TI que no esté integrado al plan de BCM

organizacional, no estará alineado con las demás unidades de negocio ni con la organización

como tal y su impacto será difícilmente reconocible o evidenciable.

Las mejores prácticas referentes al tema son promovidas por instituciones tales como el BCM

Institute, el BCI (The Business Continuity Institute) y el DRI (Disaster Recovery Institute),

quienes constantemente están investigando y profundizando en el tema. Y aunque sus

recomendaciones y teorías difieren en algunos puntos, son similares,( como se puede ver en las

figuras en las que está la estructura de los planes de Continuidad en los Anexos 6.1 y 6.2),

todos tienen ciclos que están en constante desarrollo y aprendizaje, empezando con el

entendimiento de la organización, creando una estrategia, luego generando los planes de

recuperación y de acción ante la materialización de un riesgo y, por último realizando

constantemente a lo largo de todo el ciclo labores de administración y, mantenimiento del ciclo

o plan de continuidad del negocio. Los ciclos de dichos programas de BCM se exponen a

continuación:

Ciclo de Vida Programa de BCM (11) (12):

Esta guía fue creada por el BCI para proveer una descripción y ayuda guiada de buenas

prácticas cubriendo en su totalidad la administración de continuidad del negocio.

El ciclo de vida va desde el reconocimiento inicial de la organización de la necesidad de

desarrollar el programa de BCM, hasta el mantenimiento del programa para la madurez

evolutiva del mismo (Ver anexo 6.1 para una descripción más amplia del ciclo).

Plan de continuidad del negocio (BCP):


Es a grandes rasgos similar al programa desarrollado por el Business Continuity Management

Institute (BCM Institute), este contempla todas y cada una de las medidas de contingencia y

recuperación ante cualquier evento que afecte al negocio. Todo de acuerdo al análisis de

riesgos y de impacto (BIA) realizado como parte esencial del plan de BCM. Este plan está en

constate actualización, debe ser probado con una determinada regularidad, además de estar en

permanente alerta ante cualquier cambio al interior o exterior de la organización (Ver anexo

6.2 para una descripción más amplia del ciclo).

Figura 7 - Estructura Programa de BCM (Ciclo de Vida) – B.C.I 14

BCM Program, DRI International:

Creado por el DRI International, este programa de BCM presenta una serie de ideas para

mejores prácticas que a diferencia de otros marcos no están definidas bajo una estricta

secuencia, incluso propone que varios de los puntos sean considerados y tratados de forma

paralela, en caso de ser necesario. Al igual que los dos primeros estándares uno de los

principales insumos de este programa es el BIA, y es a partir de este que se crean las

estrategias de continuidad de negocio. (Ver anexo 6.3 para una descripción más amplia)

Todos estos marcos de mejores prácticas de BCM, abordan y tratan el tema de forma similar,

con constante verificación y actualización de cada una de las partes de sus procesos o ciclos. Y 14 Tomado de: Good Practices Guideline; Business Continuity Institute.


es cuestión finalmente de los expertos de la organización, escoger el marco con el que se va a

trabajar, marco que permita el fortalecimiento de la gestión de riesgos desde la base

tecnológica, tarea que será completada y complementada con los esfuerzos del área de TI para

obtener los resultados esperados.

Además de los programas de continuidad expuestos, el marco 4-A de MIT estipula unos pasos

básicos a tener en cuenta para realizar una gestión de continuidad efectiva que son:

Figura 8 - Pasos Clave plan de continuidad de TI.15

Iniciar con un Plan de BCM puede ser el primer paso lógico para la implementación de una

gestión de riesgos de TI eficiente y efectiva, ya que además de guiar a la organización hacia

una mejor administración de TI, permite que se reduzca el impacto de los incidentes

identificados en los procesos que se apoyan en las TI existentes. Una vez construido todo el

Plan de Continuidad de Negocio es necesario fortalecer las debilidades que existan en la TI con

la que se cuenta, lo que lleva al siguiente paso.

Identificar y reparar las fallas en la estructura de TI (2).

15 Tomado de: IT Risk Turning business threats into competitive advantage; Westerman, George and Hunter, Richard; Pgs. 62-63.

• Creación del BIA(Análisis de Impacto en el negocio).

• Desarrollo de inventario de los activos de TI.

• Relacionar inventario con procesos de negocio.

Encontrar riesgos existentes en cada uno

de los activos de TI.

• Creación de plan de administracion de incidentes. Documentación específica.

• Establecimiento de la clasificación del nivel de servicio(gold, silver, bronze).

• Desarrollo planes de contingencia para escenarios "expandidos".

Crear el Plan específico. • Construir la continuidad del negocio y

relacionarla con los proyectos de TI y del negocio.

• Definición de desarrollo estándar, infraestructura y operaciones arquitecturales.

• Entrenar a los empleados (interiorización del BCP).

• Probar anualmente.

Implementar y probar el plan de continuidad.


Generalmente cuando se presentan fallas en TI, ya sea debido a errores humanos o de TI, que

no ponen en riesgo contundentemente la continuidad del negocio, son consideradas como fallas

menores. Además si con el tiempo los afectados y los responsables se acostumbran a dichas

interrupciones, éstas pasan a un segundo plano y dejan de verse como problemas, aunque de

una u otra forma las soluciones temporales son válidas en la medida en que se garantice la

continuidad del negocio, no es lo más recomendable restarle importancia a estos, así como

tampoco ignorarlos ya que la suma de varios de estos problemas “menores”, puede traer

consecuencias nefastas para la base tecnológica afectando a toda la organización,

interrumpiendo los procesos y actividades que normalmente se llevan a cabo. Tal como dicen

Westerman y Hunter cuando abordan el tema (2), “con el tiempo es mucho más costoso no

poner atención a estos problemas, que solucionarlos”.

Lo primero que se debe hacer para reparar dichas fallas es encontrarlas e identificarlas. Primero

redescubriendo y analizando situaciones que se hayan presentado recientemente, que hayan

afectado a TI de forma considerable, e incluso aquellas que aunque no hayan sido realmente

significativas se hayan materializado, interrumpiendo cualquier actividad de la organización.

Es también apropiado mirar que le ha sucedido a otras compañías, que acciones han tomado y

en general tomar nota de que se ha hecho y que se puede hacer en la organización. Este análisis

previo de eventos (riesgos materializados), busca además tener efectos en aspectos Culturales y

de Gobierno, ya que proporciona una visión más clara y efectiva a toda la organización de los

beneficios de anticipar posibles escenarios de materialización de riesgos. En especial porque se

puede comprobar de una forma menos teórica que: “más vale prevenir que curar”, además

permite sentar algunas de las bases sobre las que se apoyará la gestión de riesgos de TI (Figura

9).

Al terminar toda esta identificación de escenarios y situaciones de riesgo lo más conveniente es

realizar una auditoría de todos y cada uno de los procesos de TI. Dicha auditoría puede ser

interna o externa, cada una tiene sus pros y sus contras, sin embargo, según las entrevistas

realizadas por el MIT en los estudios hechos para la creación del marco 4-A, las auditorías

internas son mucho más efectivas ya que el nivel de confianza de los auditores les permite ser

mucho más proactivos en la búsqueda de riesgos, además conocen de antemano la historia de

la organización, su estrategia, las prácticas y las políticas, etc., conocimiento que le tomaría

tiempo adquirir a los auditores externos.


Figura 9 - Controles base tecnológica

Mediante dichas investigaciones se encontraron datos muy importantes que tenían en común

las empresas que ya habían tomado la decisión de realizar algún tipo de auditoría en seguridad

y riesgos de TI; entre los resultados del análisis de las investigaciones se encontró que la

mayoría de problemas están en los objetivos de negocio de Acceso y Disponibilidad, siendo los

de Acceso los más frecuentes y en ocasiones los de posible mayor impacto en la organización.

En términos generales el proceso lógico para identificar y reparar las fallas de la estructura

tecnológica es el siguiente (figura 10):

Figura 10 - Identificación y Reparación.

Bases Gestión de

Riesgos Base

Tecnológica

La organización conozca toda la infraestructura tecnológica que

tiene.

Que tanto Hw como Sw tengan

las actualizaciones y parches, rápida y efectivamente.

Hayan mecanismos de seguimiento de

las medidas tomadas.

Haya monitoreo y mantenimiento de todas partes

de la Infraestructura.

Análisis de eventos recientes al interior de la organización.

Estudio de situaciones que

afectaron a otras empresas.

Auditoría de procesos de TI.

(Interna o Externa)

Identificar y reparar

las fallas en la

estructura

tecnológica.


Luego de crear el Plan de continuidad y, de reparar y fortalecer las falencias encontradas en la

infraestructura de las TI, es preciso administrar dichos cambios en la organización mediante

algún mecanismo interno de control. De aquí parte el tercer paso de la “reparación” de la base

tecnológica, que está enfocado hacia la utilización de estándares para controlar y auditar dicha

administración de la gestión de riesgos de TI.

Implementación de controles y de auditorías basados en marcos de trabajo estándares (2).

Los temas relacionados con control de operaciones son tarea difícil para toda organización,

especialmente si se carece de mecanismos internos que permitan hacerlo o que los existentes

no sean los adecuados. Aunque es un trabajo arduo y toma tiempo es fundamental hacerlo dado

que es finalmente uno de los pilares para una adecuada Gestión de Riesgos de TI.

Actualmente existen varios estándares para la gestión y gobierno de TI, unos más populares

que otros y aunque los controles deben ser diseñados y construidos desde el interior de la

empresa existen varias razones para que estos sean cimentados a partir de dichos estándares,

principalmente porque si son creados e implementados de una forma deficiente, pueden

convertirse en otro problema y no en una solución. Además al hacer uso de las buenas prácticas

de la industria se está haciendo uso directo de la experiencia y del conocimiento de

especialistas y expertos en el tema, lo que permite que la organización no cometa errores que

otros ya cometieron y de esta forma minimiza en cierto grado el uso indebido de recursos. (En

el anexo 6.3, se puede ver la tabla de problemas más frecuentes encontrados en las auditorías

realizadas las compañías entrevistadas por el MIT en la construcción del marco 4-A).

Igualmente al adoptar alguna de estas buenas prácticas se tiene la gran posibilidad de hacer un

benchmarking adecuado dado que similares empresas harán uso de los mismos estándares,

identificando de esta forma puntos válidos de comparación. Y por último y muy importante,

los auditores externos estarán en capacidad de realizar su trabajo con una precisión y una

eficiencia más adecuada dado que conocerán de antemano las bases de la gestión de TI de la

organización.

Algunos de los estándares existentes son:

COBIT (Control Objectives for Information and related Technology): Creado por

ISACA (Information Systems Audit and Control Association) junto al ITGI (IT Governance


Institute), actualmente se cuenta con la versión 4.1 que fue publicada en el año 2007. (13). La

estructura de su funcionalidad para dar soporte al Gobierno de TI es la siguiente (figura 11):

Figura 11 - COBIT-Gobierno de TI16

El enfoque de este marco es hacia procesos, y divide a TI en 34 procesos fundamentales,

organizados de acuerdo al área de responsabilidad al que pertenece cada proceso (planear,

construir, ejecutar y monitorear). Lo que finalmente busca el Marco es alinear las metas del

negocio con las de TI, identificando responsabilidades asociadas entre los dueños de los

procesos y los dueños de las TI en las que se apoya cada uno de los procesos.

ITIL (Biblioteca de Infraestructura de Tecnologías de Información):

Se encuentra actualmente en la versión número 3, publicada en el año 2007 por la OGC, que es

la “Oficina de Comercio Gubernamental” del Reino Unido. Este marco de trabajo de buenas

prácticas esta divido en 5 tomos en su versión 3, especializándose cada uno en un tema

determinado, y estos son:

Estrategia del Servicio.

Diseño del Servicio.

Transición del Servicio.

Operación del Servicio.

Mejoramiento Continuo del Servicio.

Complementándose unos a otros, formando así uno de los marcos más grandes y completos

que hay en el mercado. Este en general define conjuntos de procedimientos que permiten

16 Tomado de: COBIT 4.1 (versión en Español); IT Governance Institute.


mejorar la calidad de los servicios prestados por TI tanto al interior de la organización como al

exterior (con el cliente). La estructura de interacción del marco es la siguiente (figura 12):

Figura 12 - Estructura ITIL17

Basando la gestión de control y auditoría en alguno de estos estándares o de algún otro

conocido, será más fácil complementar eficazmente la puesta en marcha de los tres pasos de re-

creación de la base tecnológica. Pasos que pueden verse en un orden lógico y de acuerdo a

como fueron tratados en el capítulo en la figura 13.

Figura 13 - Pasos Reparación Base Tecnológica.

Estos tres pilares de la gestión de riesgos de TI enfocados en la base tecnológica, no son

excluyentes el uno del otro y por el contrario pueden llevarse a cabo de forma simultánea,

incluso dada la estructura de cada uno de estos, habrán actividades que afecten a más de uno al

17 Imagen tomada de: www.bit-consulting.org/ITIL/ITILMasivo/itil.htm

Crear y probar todo un plan de continuidad del negocio (BCP, Business Continuity Plan ).

Encontrar y reparar las falencias tecnológicas.

Implementar controles para monitorear el estado de TI basado en marcos estándar de la industria.


mismo tiempo, y que inclusive hagan parte del desarrollo de alguna de las otras dos disciplinas.

Pero lo más importante es que mediante la ejecución adecuada de cada una de estas actividades

se logra mejorar, mantener y enfocar hacia el continuo mejoramiento cada uno de los objetivos

de negocio; empezando por el plan de BCM y llegando a la implementación de alguno de los

estándares de calidad de Gestión de TI, se va escalando adecuadamente por la pirámide de

riesgos de TI (remitirse a la figura 1), por ejemplo el tener y mantener un plan de BCM permite

proveer a la organización de medidas y acciones encaminadas a mantener la disponibilidad de

los procesos de TI especialmente los que involucran actividades críticas de la organización, y

de esta forma permite la continuidad y disponibilidad del negocio de la organización tanto

interna como externamente.

El marco 4-A, principal referencia e insumo teórico de este estudio, se complementa en el caso

específico de la disciplina de base tecnológica con los estándares descritos anteriormente, estos

son: en el primer paso el programa de continuidad del negocio propuesto por el BCI,

centrándose en los puntos en los que se tratan temas netamente de infraestructura tecnológica,

y en el tercer paso el conjunto de buenas prácticas desarrollado por la OGC (ITIL), del cual

también se toman los puntos que mejor complementan al Marco 4-A y que están igualmente

relacionados con la base tecnológica; ambos fueron escogidos debido a sus principios

sistémicos y enfoques organizacionales, además de que juntos integran una fuente teórico-

práctica que permite profundizar y reforzar temas de infraestructura expuestos por el marco 4-

A. Estas dos son guías que están respaldadas por años de experiencia y que nacieron de

iniciativas de reconocidas organizaciones a nivel mundial. Con esto termina por configurarse el

modelo con el que se especifica la disciplina de base tecnológica (ver figura 14).

Figura 14 - Complementos para el desarrollo del Marco 4-A, base tecnológica.

• Desarrollo del plan de continuidad del negocio de acuerdo al plan de BCM desarrollado por el BCI, tomando unicamente las actividades que involucran directamente a TI.

Gestion de continuidad de la base

tecnológica.

• Encontrar las falencias de TI.

• Reparar falencias de cualquier tipo, críticas y no críticas.

Reparar falencias de la infraestructura de

TI. • Gestion de TI

• Conjunto de buenas practicas de ITIL. (Se tomaron las actividades relacionadas directamente con TI de todas las etapas del ciclo de vida).

Monitoreo del estado y de los servicios prestado por TI.


En la figura 15 podemos ver cómo queda el modelo final, complementado con las demás teorías y

guías de buenas prácticas comentadas anteriormente.

Figura 15 - Modelo de trabajo, Base Tecnológica.

Una vez explicado el modelo construido para trabajar la disciplina de base tecnológica se da

paso a la explicación concerniente al modelo de la disciplina de Gobierno de gestión de riesgos

de TI.

2.2.2 Gobierno

El gobierno de riesgos de TI se revisa desde los dos marcos de gestión de riesgos que hacen

parte de este estudio y la circular 052, partiendo del análisis comparativo (4) que permitió

seleccionar el marco 4-A como el referente principal de este estudio y el Risk IT como

complemento en la parte operativa. La circular 052 fue analizada desde la perspectiva del

marco 4-A (9) y por lo tanto sus numerales están incluidos dentro de dicho marco.

El gobierno de riesgos de TI en el marco 4-A consta de un proceso cíclico que define cuáles

son los riesgos de TI en toda la organización, continuamente monitorea la forma cómo

evolucionan, los prioriza y desarrolla políticas y estándares para controlarlos, adicionalmente

cuenta también con unos roles claramente definidos y unas mejores prácticas. En esta sección

Implementar controles y auditorias basados en estándares de la industria.

Fortalecido y complementado por ITIL y COBIT

Encontrar y reparar las falencias de la infraestructura de TI.

Reparación de la infraestructura de TI ITIL, COBIT y BCM.

Construir y probar el plan de continuidad del negocio.

Fortalecido y complementado por BCM Programme


se muestran primero los roles, después la estructura del proceso y finalmente las prácticas que

mejoran el proceso.

El primer componente es la definición de roles en diferentes niveles de la jerarquía

organizacional, estos roles son:

o Patrocinador ejecutivo: es la persona que tiene la visión integral del manejo de riesgos

en toda la organización, monitorea que se cumpla la cultura de riesgos de TI y que todas

las estructuras cumplan su papel. Esta persona también suele participar en el consejo de

políticas de riesgo. Este rol depende de cada organización algunos ejemplos de quien

puede desarrollarlo son CXO.

o Consejo de políticas de riesgo: es un consejo de alto nivel en donde se definen las

prioridades que tienen los riesgos específicos a nivel de la organización, se aprueban

presupuestos para las actividades enfocadas a disminuirlos y se revisan excepciones que

no fueron resueltas en los niveles inferiores. Dentro de este consejo debe tener

participación el CIO.

o Consejo de implementación: responsables de implementar una política de riesgos por

medio de la creación de estándares del negocio y técnicos. Normalmente está

constituido por gerentes de las unidades de negocio y gerentes de TI. Este consejo

reporta al Consejo de Políticas de Riesgo y al Oficial de Riesgos de TI.

o Equipo de manejo del riesgo de TI: son los encargados de desarrollar los procesos para

el control de riesgos, generar reportes y monitorear a los gerentes locales. Este equipo

reporta directamente al oficial de riesgos de TI. Según el tamaño de la organización este

equipo puede ser con personal de dedicación exclusiva o con personal de dedicación

parcial.

o Gerentes locales: identifican, evalúan, priorizan y controlan los riesgos en sus

respectivas áreas de negocio. Los riesgos de baja prioridad son administrados

localmente en cada área de negocio y los riesgos de alta prioridad son reportados a los

niveles superiores y al Oficial de riesgos de TI.

Y un sexto rol que es transversal a los cinco anteriores:


o Oficial de riesgos de TI: quien es finalmente el responsable de administrar los riesgos

de TI dentro de la organización y algunas de sus funciones principales son: negociar,

planear y ejecutar en conjunto con el CIO el plan operacional de TI; trabajar de la mano

con las unidades de negocio para ayudar a identificar riesgos de TI; ejecutar

investigaciones especiales o auditorías; coordinar los esfuerzos de toda la organización

en cuanto a gestión de riesgos de TI; reportar al CIO o al Oficial de riesgos Corporativo

cuando sea necesario.

Esta descripción de roles puede entenderse mejor en la figura 16.

Figura 16 - Roles de Gobierno de Riesgos de TI18

Dependiendo del tamaño de la compañía y de la disponibilidad de recursos estos roles no

necesariamente deben existir tal como se describen sino que se debe tener un responsable del

rol el cual puede ser de tiempo parcial.

A continuación se estudia el siguiente componente de gobierno.

El segundo componente es el proceso de gobierno de riesgos de TI. Consta de cinco

etapas, las cuales son descritas a continuación y pueden verse en la figura 17:

o Definir las Políticas y Estándares de Riesgo: las políticas normalmente definen que es y

que no es permitido o requerido y que acciones y actividades son necesarias para

asegurar que lo que es requerido sea realizado y lo que no es permitido sea prohibido.

Las políticas suelen ser más amplias que los estándares, estos últimos son más

específicos porque están diseñados para orientar la implementación de procesos,

18Tomado de: J. Santa. “Análisis de marcos de gestión del riesgo de TI: los marcos 4-A, risk it y la construcción de una herramienta de análisis”. Proyecto de grado Ingeniería de Sistemas. Universidad de los Andes, 2009.pp 42


procedimientos y configuraciones de hardware o software. Las políticas y estándares

pueden ser definidos de acuerdo a lineamientos reconocidos según la industria ó a

mejores prácticas.

o Identificar y Evaluar los Riesgos: este paso es el centro de una efectiva gestión de

riesgos de TI. Inicialmente los gerentes locales y expertos identifican y evalúan los

riesgos que están dentro de sus áreas para posteriormente reunirse y consolidar los

riesgos de la compañía junto con la alta gerencia. Hay dos factores importantes en la

identificación y evaluación de riesgos que son el potencial impacto en el negocio y su

probabilidad de ocurrencia, lo cual permite crear un mapa de riesgos.

Figura 17 - Procesos de Gobierno de TI.

o Priorizar los Riesgos y Asignar Responsabilidades: para poder priorizar los riesgos de

TI es necesario tener en cuenta el impacto en el negocio de alguna amenaza y su

probabilidad de materialización, muy seguramente una amenaza con un alto impacto y

una alta probabilidad tendrá una prioridad alta. El impacto y la probabilidad de

materialización de una amenaza solo puede definirlo cada empresa de acuerdo con su

entorno, sus herramientas y recursos para poder asignar una prioridad a cada riesgo.

Una vez se han priorizado los riesgos de TI es necesario asignar las responsabilidad a

alguien del manejo de los mismos y su acción de tratamiento, ya sea mediante

mitigación, anulación, aceptación o transferencia.

Inicio

Definir una política y

estándares de riesgos de TI.

Identificar los riesgos de TI y

definir la probabilidad de

que se materialicen.

Priorizar los riesgos y asignar

responsables para su control.

Decidir si reducir / evitar /

transferir / aceptar cada

riesgo.

Monitorear y llevar historia de

cada uno de los riesgos.

Políticas y estándares

Alcance de los riesgos definido

Documentación de

las acciones tomadas

Riesgos Priorizados

Medidas continuas

y estados de

riesgos

actualizados


La priorización es responsabilidad de la alta gerencia, la responsabilidad para gestionar

los riesgos de TI puede ser delegada, pero la responsabilidad de priorizarlos no. Esta es

una de las razones por la que los riesgos de TI deben ser descritos en términos de

consecuencias en el negocio.

o Manejar los Riesgos: cada riesgo debe ser manejado de una de las siguientes maneras,

o de una combinación de ellas: reducción, anulación, aceptación y transferencia. En la

mayoría de los casos se maneja el riesgo tratando de reducir su probabilidad mejorando

la base tecnológica o su impacto a través de planes de recuperación en el plan de

continuidad del negocio.

Es importante mencionar que no sólo deben tenerse en cuenta las amenazas sino

también las vulnerabilidades ya que son otra fuente importante de riesgos de TI.

o Monitorear y Supervisar los Riesgos: es necesario observar y llevar un registro tanto de

la eficacia de planes y políticas de la gestión de riesgos de TI así como de los efectos

de los cambios internos y las circunstancias externas. Esto significa contar con

indicadores de riesgo para poder monitorearlos y evaluar su comportamiento en el

tiempo. El monitoreo de los riesgos de TI proporciona una importante

retroalimentación en la medida que se puede determinar si las políticas y estándares

son los adecuados para la organización.

Finalmente se estudia el último componente de gobierno.

El tercer componente de la disciplina son prácticas que mejoran el funcionamiento del

proceso, estas prácticas son:

o Asignar un Único Dueño del Proceso: al ser el oficial de riesgos de TI el líder del

equipo de gestión de riesgos de TI, todas las personas de la empresa saben a quién

acudir cuando se presenta una inquietud respecto a este tema.

o Identificar Formalmente Categorías de Riesgo: las categorías sirven para tener una lista

de chequeo que permite a los administradores locales a identificar y evaluar los riesgos

y también permite a la alta gerencia a priorizar y monitorear los riesgos agrupados en

dichas categorías.


o Crear un Registro de Riesgos: el tener un registro de riesgos con sus potenciales

impactos, sus probabilidades y las personas responsables de los mismos permite tener

un plan de seguimiento y control para poder enfrentarlos adecuadamente y con

suficiente información.

o Desarrollar Métodos Consistentes para Evaluar el Riesgo: el tener métodos consistentes

de evaluación de los riesgos y su posible impacto a lo largo de toda la organización,

permite comparar y priorizar riesgos de una manera global.

o Utilizar Mejores Prácticas Especializadas: utilizar las mejores prácticas de la industria y

las recomendaciones de los proveedores ayuda a construir una base de protección contra

los riesgos.

Como conclusión de esta disciplina en el marco 4-A, se puede decir que define cuáles son los

riesgos de TI en toda la organización, monitorea la forma cómo evolucionan, los prioriza y

desarrolla políticas y estándares para controlarlos a través de los diferentes roles y las prácticas

de mejora del proceso, como puede verse en la figura 18.

Figura 18 - Gobierno de Gestión de Riesgos de TI.

El gobierno de riesgos de TI visto desde el marco Risk IT está basado en tres dominios, que lo

modelan. Estos dominios son: Gobierno del riesgo, Evaluación del riesgo y Respuesta al

riesgo, que a su vez tienen varios procesos.

Gobierno del riesgo de TI:

o Establecer y mantener una vista común del riesgo.

Gobierno de gestión de riesgos de TI

Prácticas de

mejora

Proceso de

gobierno

Roles

Prácticas de

mejora

gobierno


o Integrarse con la gestión de riesgos de la empresa.

o Tomar decisiones conscientes del riesgo de negocio.

Evaluación del riesgo de TI:

o Recolectar datos.

o Analizar el riesgo.

o Mantener el perfil del riesgo.

Respuesta del riesgo de TI:

o Riesgo claro.

o Manejo del riesgo.

o Reacción oportuna a eventos.

A pesar que uno de los dominios recibe el nombre de gobierno de riesgo, los otros dos

dominios también se encuentran enmarcados dentro de la descripción dada de la disciplina por

el marco 4-A, que es el marco de referencia para esta investigación, en la disciplina de

gobierno de riesgos de TI, lo cual hace que estos dos marcos puedan complementarse para la

construcción de la guía. Tal como puede verse en la figura 19.

Figura 19 - Complemento de la disciplina de Gobierno

Esta figura muestra como los dominios del marco Risk IT complementan la disciplina de

gobierno del marco 4-A.

A continuación se describe la disciplina de Cultura de conciencia del riesgo.

Roles

Proceso de Gobierno

Mejores Prácticas

•Gobierno del riesgo

•Evaluación del riesgo






4A Risk IT


2.2.3 Cultura

Cuando se habla de cultura el concepto general es pensar en “conjunto de modos de vida y

costumbres, conocimientos y grado de desarrollo artístico, científico, industrial, en una época,

grupo social, etc.”19 Un tema bastante amplio, de un nivel de complejidad que no es posible

evaluar y comprender en su totalidad, en un estudio como este; por lo que se debe puntualizar.

Dado que en el marco 4-A, existe la disciplina de cultura esta es una frontera con la que se

puede empezar a delimitar el tema. Pero ¿Qué tiene que ver riesgo con cultura? Como se

mencionó anteriormente en la descripción del marco, se entiende por cultura que cada miembro

de la organización tiene conocimiento y es consciente de los riesgos, además de sus posibles

tratamientos. “Las personas que no conocen una amenaza o un riesgo cuando lo ven, como se

les puede pedir que se protejan y protejan la empresa”20, hay que crear conocimiento y hay que

crear conciencia de riesgo; hay que crear cultura de riesgo.

Una cultura con conciencia de riesgo debe presentar según Westerman en su comportamiento

los siguientes puntos (2):

- Es bueno hablar de riesgos.

- Es bueno tomar riesgos.

- Si se gerencia bien, es posible errar.

- Los éxitos y fracasos se documentan y se analizan.

- Hay un continuo aprendizaje y mejoramiento de los procesos clave.

- Existen presupuestos y cronogramas alcanzables que son continuamente

monitoreados.

- Los altos mandos activamente comparten riesgo y el manejo del riesgo.

- La empresa es capaz de tomar riesgos más grandes.

Para poder llegar a que se presenten estos comportamientos, dentro de los principios del Risk

IT (14) y lo planteado en el marco 4-A (2) se encuentran pautas que facilitan llegar a esto.

Antes que todo es necesario entender dos puntos. El primero es que la cultura se propaga de

19 Tomado de: Diccionario de la real academia de la lengua, definición cultura. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=cultura 20 Traducción: IT Risk: Turning Business Threats into Competitive Advantage, George Westerman, Hunter, Richard. Página 140


arriba hacia abajo, y es necesario diferenciar a que persona se le está hablando y hablar

constantemente.

Si se quiere que exista una cultura de riesgo en una empresa, es necesario entender que esto

solo ocurrirá si el mando alto, muestra ese comportamiento a sus subalternos. La razón de esto

está dada por la forma como el ser humano interioriza su comportamiento. En una sociedad, las

personas de edad o de poder, les muestran y les inculcan el comportamiento a los integrantes

más jóvenes de la sociedad. Estas enseñanzas, sean verbales o de comportamiento, forman y

permiten interiorizar el comportamiento a sus nuevos miembros (15). Las empresas en sí, son

sociedades y las mismas se rigen por estos mismos comportamientos. Si una persona de un

cargo alto muestra interés en compartir, proponer, encontrar y difundir comportamientos e

iniciativas positivas frente al riesgo, sus subordinados empezarán a comportase de la misma

forma. Si esto ocurre, se está generando conciencia de riesgo.

El primer interrogante que puede surgir en este momento es ¿Cómo se pueden propagar estos

comportamientos? Ya se habló de las pautas que propone el marco en cultura y las dos

dependen de un elemento no puntualizado, que exista un alto nivel de comunicación. El

modelo clásico de comunicación, Emisor, mensaje, canal y receptor, conocido por las siglas E-

M-C-R presentado en la figura 20, muestra los componentes básicos para que exista

comunicación. (16) El emisor es quien desea comunicar, el mensaje es lo que desea comunicar,

el canal es el medio por el que se transporta el mensaje y el receptor es a quien va dirigido el

mensaje. Esta estructura es bien conocida, y permite ver que componentes son necesarios para

que exista una comunicación. Se identifica el primer componente; los altos mandos quienes

quieren transmitir información a la organización y se puede identificar como receptores a otros

miembros de la organización. Pero antes hay que establecer un hecho de los emisores y

receptores presentes en el modelo. No existe una persona igual a otra en una organización.

Figura 20 - Modelo E-M-C-R.


Dentro de una sociedad existen jerarquías creadas desde el marco organizacional, pero también

existen sub grupos dentro de las sociedades. Un ejemplo de esto, son los grupos y las

divisiones existentes en un colegio; los deportistas, los estudiosos, los músicos, los populares,

etc. Estos aunque todos pertenecen a una misma sociedad denominada colegio, tienen

conocimientos, comportamientos y jerarquías propias, y dentro del colegio cada grupo tiene un

nivel jerárquico diferente. Estos niveles no son los mismos impuestos desde las directivas del

colegio (que podría ser considerada como estructura organizacional), como el grado en el que

se encuentra una persona, sino divisiones que se dan dentro de la sociedad de forma natural.

Aplicando esta segmentación a una organización, puede verse como el grupo que maneja el

negocio, el que controla el entorno, los que dan soporte, los auxiliares, etc., pueden presentar

agrupaciones como la planteada como ejemplo en la figura 21. Ellos por la formación que

tienen, no poseen los mismos conocimientos, por consiguiente, la forma de ver el entorno es

diferente. Por lo mismo, para generar comunicación entre ellos, es necesario construir un

lenguaje común para que se logre interacción entre estos distintos grupos; empezando por el

líder de cada grupo como se mencionó anteriormente. Si se logra esto, se puede esperar que se

genere cooperación, y por ésta cooperación y comunicación, se propicie la propagación de la

conciencia de riesgo.

Figura 21 - Grupos en las organizaciones.


Luego de presentar cómo propagar cultura de riesgo, es necesario intentar nombrar las

prácticas para generar esta cultura. “Tres aproximaciones surgen como cruciales para construir

una cultura de riesgo en una organización. La primera aproximación enfatiza en la importancia

de introducir comportamientos en seguridad a las prácticas diarias; la segunda propone que

mediante procesos de educación y entrenamiento, se logra internalizar los aspectos de

seguridad y de conducta; y la última se enfoca en desarrollar motivación y participación como

medio para lograr aceptación de mecanismos formales”21. Estas aproximaciones

independientemente pueden ser solo ideas sueltas y es necesario introducirlas a la teoría

anteriormente presentada. Se tienen dos grandes formas de lograr una cultura de riesgo, una

propagación de arriba hacia abajo en la organización, y una segmentación por niveles ya sean

organizacionales o culturales. Las prácticas son los instrumentos que le permiten a las

directivas difundir sus ideas. Es decir, son el canal que lleva el mensaje a la organización. Solo

falta definir mediante las prácticas el mensaje que se quiere llevar. Es el mensaje el que debe

ser construido cuidadosamente. Es necesario definir quién es el receptor de la práctica, y

construirlo especialmente para este público objetivo.

Hasta este punto ya se ha definido qué es cultura, que fragmento de cultura es sobre el que se

va a particularizar, los resultados que se quieren obtener mediante una cultura de riesgo, las

formas de lograr una propagación cultural, las prácticas que se deben ejecutar y las diferencias

que hay que tener en cuenta en el momento de ejecutar las prácticas. Pero todo lo dicho sigue

siendo cualitativo y no cuantitativo. Es difícil lograr medir un progreso o definir un estado. Es

necesario recurrir a otra teoría para consolidar el modelo construido hasta este punto.

Para construir modelos culturales, los antropólogos tienen en cuenta que existen distintos

niveles de comportamiento: abierto y secreto, implícito y explicito, y lo que se habla y lo que

no se habla (17). Siendo abierto y secreto, los límites más grandes, luego si es un

comportamiento explicito o implícito y por último si se habla o no se habla del

comportamiento; estos límites ofrecen una estructura concreta, que de situar una política dentro

de éstos permite saber qué estado cultural tiene. Estos modelos agregan valor a lo presentado

anteriormente. Si se utiliza este marco para evaluar las aproximaciones existentes, dentro de los

distintos niveles organizacionales y grupos sociales, se puede generar un marco que permite

21 Traducción: Information security culture: the effect of institutional factors and the mediating role of business continuity practices. Adela Garzón Bejarano página 7


una evaluación más tangible de la madurez de cultura de riesgo de TI de la organización. El

marco presentado a continuación, es un bosquejo de cómo se podría utilizar en conjunto la

recopilación de estas teorías. Hay que tener en cuenta que este marco se debe aplicar en cada

uno de los grupos y segmentaciones organizacionales existentes, tomando como elemento a

evaluar la política, comportamiento o norma que se quiere evaluar. Las prácticas son las

mencionadas anteriormente identificadas como comportamientos.

Análisis cultural

Privado (secreto) Público (abierto)

No se habla Se Habla No se habla Se Habla

Elemento a evaluar: Práctica: Implícito Explícito Implícito Explícito Implícito Explícito Implícito Explícito

Elemento 1

1

2

3

Tabla 1 - Marco de evaluación cultural

En la tabla 1, se denomina “elemento 1” al punto del riesgo que se quiere evaluar como el

conocer una política o un comportamiento. Las “practicas” son (18):

1. Introducción de comportamientos en seguridad a las prácticas diarias.

2. Procesos de educación y entrenamiento.

3. Desarrollo de motivaciones y medios de participación, hacia la aceptación como

mecanismo formal.

Se debe en primera instancia identificar los grupos organizacionales y los grupos sociales que

van a ser evaluados y escoger qué elementos serán evaluados dentro de estos grupos. Luego

definir cómo se quiere que sea el elemento, marcando el campo en el que se desea estar para

cada práctica en su correspondiente recuadro. Al tener esto, se hace una evaluación marcando

el estado actual del elemento en la práctica que se está evaluando. La diferencia de espacios

entre lo que se quiere y se tiene da un valor por práctica, y la suma de estos valores da su

evaluación. El elemento se encontrará en el nivel deseado cuando la diferencia entre el actual y

el deseado sea cero.


Este marco de evaluación cultural es la última herramienta, para hacer un análisis del estado

cultural de la organización. Necesidad que faltaba por suplir para tener una forma de evaluar

cultura. Es necesario recordarle al lector que está sesgada por las políticas y marcos

presentados anteriormente y es posible desarrollar otras aproximaciones. Pero para el caso de

estudio de este proyecto de grado, estas herramientas cumplen con las necesidades del mismo.

2.4 Síntesis

Hasta este momento se ha explicado, el marco 4-A con sus objetivos de negocio y sus disciplinas, los

trabajos que sirven de insumos para este escrito, y una descripción de cada una de las disciplinas con

una profundización independiente; fusionándolas con algunas de las teorías existentes que enriquecen

la especificación de este marco. En este momento se espera que el lector haya obtenido los

conocimientos pertinentes para comprender el estudio que se presenta más adelante. En el próximo

capítulo se presenta la guía y el proceso sobre cual se aplican los modelos construidos en este capítulo.


V. CAPÍTULO 3 – LA GUIA DE GESTIÓN DE RIESGOS DE TI

3.1 Descripción general

La guía de gestión de riesgos de TI es una guía que mediante su aplicación permite planear, evaluar y

ejecutar acciones para mejorar los niveles de riesgo en TI. Esta guía es un trabajo desarrollado por el

grupo de investigación TION de la Universidad de los Andes. La guía es la descripción de un proceso

cíclico, como se muestra en la figura 22 y consta de 6 pasos. Cinco de estos pasos se encuentran

definidos en el documento “Guía de mejores prácticas en gestión de riesgos de TI en el sector

bancario colombiano” pero el paso denominado “planeación detallada de cada disciplina”, es

presentado en profundidad en este capítulo ya que este fue separado del documento original para poder

plantear cada disciplina independientemente.

Figura 22 - Pasos de la Guía de gestión de riesgos de TI22

22 Imagen tomada de: “Guía de mejores prácticas en gestión de riesgos de TI en el sector bancario colombiano”. Luis Carlos Figueroa Medina. Página 65


Si se desea conocer más a fondo el estudio realizado para la construcción de esta guía se

recomienda al lector ver el documento donde esta se encuentra desarrollada (1). A continuación se

tendrá una breve descripción de los pasos con nos que cuenta la guía.

3.2 Pasos de la guía (1)

Como se dijo anteriormente la guía cuenta con seis de pasos necesarios para la valoración del

riesgo de TI, a continuación se dará una breve explicación de estos.

1. Construcción de un perfil ideal de riesgos de TI

El objetivo de este primer paso es definir, de acuerdo con las políticas de gobierno, el perfil de

riesgo de TI al que se desearía llegar en cada proceso de negocio o de la organización.

2. Construcción de un perfil actual de riesgos de TI

El objetivo de este paso es encontrar la situación actual de riesgos de TI en cada proceso de

negocio, para poder determinar que tan lejos se está del perfil ideal y así poder tomar acciones

tanto preventivas como correctivas en el proceso de gestión de riesgos de TI.

3. Priorización de las disciplinas

El objetivo de este paso es determinar cuál o cuáles son las disciplinas por las que se debe

iniciar el proceso para acercarse cada vez más al perfil ideal.

4. Planeación detallada de desarrollo de cada disciplina

El objetivo de este paso es describir las actividades a desarrollar en cada una de las disciplinas

según sea su priorización. Sobre este paso se profundizará en la próxima sección del capítulo.

5. Medición de las acciones de mejora implementadas

El objetivo de este paso es estimar el impacto de las acciones tomadas en cada una de las

disciplinas que se estén desarrollando.

6. Retroalimentación de resultados

Con los resultados del paso anterior sumados a los cambios del contexto organizacional, su

objetivo es evaluar la necesidad de ajustar el perfil de riesgos de TI construido para continuar

madurando la gestión de riesgos de la compañía.


3.3 Profundización del paso “planeación detallada de desarrollo de cada

disciplina”

Este paso de la guía se desarrolla mediante una evaluación detallada de las disciplinas utilizando

como herramienta una lista de chequeo propia; una vez que se ha hecho esta evaluación se debe

proceder con la construcción del plan de acción de acuerdo con los resultados obtenidos.

Lista de Chequeo: como se mencionó, para cada una de las disciplinas se ha desarrollado un

instrumento de evaluación a partir de los modelos construidos y del marco teórico de la guía de

mejores prácticas de gestión de riesgos de TI el cual es el complemento de los marcos 4-A y

Risk IT.

Estos instrumentos de evaluación son construidos independientemente de los instrumentos

usados en los pasos anteriores de la guía dado que el objetivo principal es proveer herramientas

específicas por disciplinas de acuerdo con los modelos construidos anteriormente, que

permitan realizar un análisis adecuado, incluyendo las acciones para mejorar su gestión de

riesgos de TI.

Plan de acción: un plan de acción es una forma de sintetizar el qué, el cuándo y el quién, va a

realizar una acción determinada. El construir este plan, permite identificar acciones específicas

para monitorear y administrar lo que se desea (19). Es importante tener presente que el plan es

independiente para cada disciplina. Es relevante mencionar, que luego de verificar la existencia

de prácticas mediante las listas de chequeo, en cada punto en el que se evidencie que no se

realiza alguna actividad específica, se invitará a llevar a cabo dicha actividad organizacional

para poder cumplir a cabalidad las recomendaciones dictadas por la guía. El incumplimiento y

la no corrección de los puntos faltantes de la lista de chequeo pueden a largo plazo traer como

consecuencia la replicación de las fallas en varias partes de la estructura de la gestión de

riesgos de TI, (dado su principio sistémico), las cuales finalmente afectarán la adecuada

funcionalidad de las tres disciplinas.

Se presentan a continuación los instrumentos y planes de acción de cada una de las disciplinas.


3.3.1 Base Tecnológica

Si la disciplina seleccionada a desarrollar es Base tecnológica, a continuación se presenta una

lista de chequeo de cada uno de los componentes de esta disciplina y un plan de acción

genérico sobre estas actividades:

Lista de Chequeo

Esta lista de chequeo se desarrolló teniendo en cuenta los tres pasos de la reparación de

la base tecnológica, primero se consideran los puntos relacionados con la continuidad

del negocio, en los que se tienen en cuenta las partes fundamentales del plan de BCM

relacionadas directamente con TI, seguido de las consideraciones más importantes en

cuanto al fortalecimiento de la infraestructura de TI, por último considera el tema de la

Gestión de TI.

Cada paso está divido de acuerdo con los temas centrales que lo componen, definiendo

así roles, responsabilidades y actividades a revisar en la organización de acuerdo al paso

escogido. La lista de chequeo completa y algunos anexos más que la complementan se

encuentra en el anexo 6.4.

Plan de acción

Todo el plan de acción de esta disciplina busca principalmente fortalecer la

infraestructura de TI de tal forma que todos los servicios prestados a la organización a

la que pertenece y en la cual reside sean entregados y soportados de la mejor forma

posible, corrigiendo posibles errores, reparando los ya existentes o sencillamente

fundando e implementando una base tecnológica adecuada, eficiente y eficaz de

acuerdo a las necesidades del negocio.

Ahora bien, lo más adecuado y lógico de acuerdo al marco teórico y sus distintos

componentes, es primero definir los roles y de esta forma entregar las

responsabilidades a quienes correspondan dentro de la organización. Cabe aclarar que

las responsabilidades de quienes hacen parte de la consecución de un sólido plan de

BCM son en ocasiones distintas a las de quienes están encargados de la Gestión de TI,

pero son fuertemente complementarias entre sí. De esta forma los tres pasos y sus

actividades son la conjunción adecuada para la parte de la Gestión de Riesgos de TI


que está relacionada con la base tecnológica. Una vez definidos los roles y sus

responsabilidades deben fijarse cronogramas de actividades a desarrollar para llevar a

cabo la totalidad de las tareas y acciones expuestas en la lista de chequeo.

3.3.2 Gobierno

Si la disciplina seleccionada a desarrollar es Gobierno a continuación se presenta una lista de

chequeo de cada uno de los componentes de esta disciplina y un plan de acción genérico sobre

estas actividades:

Lista de Chequeo

Esta lista de chequeo es realizada sobre la base del modelo teórico construido en esta

investigación. La lista de chequeo del anexo 6.5 se divide en tres partes, una por cada uno

de los componentes de la disciplina: definición de roles, proceso de gestión de riesgos de

TI y mejores prácticas.

Para cada uno de los componentes de la disciplina se presenta un listado de actividades a

evaluar y que permiten la construcción del plan de acción.

Plan de acción

El objetivo del plan de acción de la disciplina de gobierno es lograr acercar el perfil de

riesgos de TI de la organización cada vez más al perfil de riesgos de TI ideal en conjunto

con los planes de acción de las otras disciplinas.

Una vez ha sido evaluada la lista de chequeo, se debe elaborar un plan de acción para la

disciplina de gobierno, para lo cual primero se deben priorizar las actividades que se

requieren desarrollar.

De acuerdo con los componentes de la disciplina se deben definir inicialmente los distintos

roles, posteriormente, es necesario realizar un documento con las actividades del proceso

de gestión de riesgos de TI y de mejores prácticas que se deben desarrollar, el cual debe

incluir por cada actividad su prioridad, su responsable o responsables y las fechas en las

cuales se debe realizar dicha actividad. El plan de acción depende de las necesidades de


cada organización según su entorno y el nivel de madurez que haya alcanzado en esta

disciplina.

A continuación se presenta el plan detallado de la disciplina de cultura.

3.3.3 Cultura

Si la disciplina seleccionada a desarrollar es Cultura a continuación se presenta una lista de

chequeo de cada uno de los componentes de esta disciplina y un plan de acción genérico sobre

estas actividades:

Lista de Chequeo

Esta lista de chequeo consta de cinco componentes, las cuales permiten evaluar el estado

actual de la cultura de riesgo la explicación de sus componentes se encuentra a

continuación y sus respectivas listas se encuentran en el anexo 6.6.

Cultura organizacional de riesgo de TI: En este componente, se evalúan los

comportamientos culturales oficiales presentes en la organización.

Cultura social de riesgo: en este componente se evalúan los comportamientos sociales

presentes en la organización.

Políticas y Reglamentación: en este componente se evalúan los comportamientos

culturales existentes frente a las políticas y normas de la organización.

Entrenamiento y campañas de sensibilización: en este componente se evalúan los

comportamientos que se dan con respecto al entrenamiento en la organización y las

campañas desarrolladas.

Aceptación cultural: Este componente evaluar la recepción de la organización a los

planteamientos culturales.

Plan de acción


En el momento de haber evaluado la lista de chequeo por componentes en cada una de las

unidades de negocio, es necesario que se desarrollen acciones para que los

comportamientos no existentes se propicien, ya que son estos los requeridos para tener

una conciencia de riesgo de TI.

Es necesario determinar los responsables de la cultura de riesgo de TI, esta

responsabilidad debe ser asignada a quien ya tenga como responsabilidad el control del

riesgo operacional. Es responsabilidad de éste, que se generen campañas y jornadas

educativas para los miembros de la organización, así como que existan y mantengan las

políticas y reglamentos de la organización frente al riesgo. Es también responsabilidad de

éste identificar los líderes organizacionales y culturales, para capacitarlos y

concientizarlos sobre riesgo de TI, además de hacerles entender la necesidad de

convertirse en voceros para generar conciencia.

Luego de haber logrado esto, se les debe dar como responsabilidad a estos líderes el

promulgar y concientizar a sus distintos grupos de la organización. Mientras que en

paralelo el responsable continua con planes educativos y campañas informativas para que

se promueva de forma eficiente lo que se desea transmitir.

Adicionalmente, es necesario recolectar los comportamientos espontáneos y

transformarlos en políticas y reglamentos para así tener un mejor control de los riesgos

que existen en la organización.

Aunque esta no es la única forma para lograr una buena cultura de riesgo de TI en la

organización, es la forma como se recomienda basada en el modelo construido durante

este proyecto. Es importante tener en cuenta que a diferencia de las otras disciplinas,

estimar resultados, plantear tiempos para su evaluación y ver resultados; puede no ser una

tarea puntual dada la naturaleza de la cultura, y es necesario aceptar que toman tiempo y

dedicación. Por esto es viable que el encargado de cultura con los líderes de la

organización paulatinamente evalúen sus acciones y si no encuentran cambios favorables,

desarrollen nuevas formas de llevar el mensaje a la organización, hasta lograr el objetivo.


Se ha presentado la profundización y especificación para cada una disciplina, estas pautas generales

permiten la construcción de los planes de acción para mejorar en cada una. Ahora es necesario

validarlas dentro de un caso de estudio, el cual se presenta a continuación.


VI. CAPÍTULO 4 - EL CASO DE ESTUDIO

Este capítulo se enfoca en validar lo propuesto en el capítulo anterior mediante la especificación de

la guía. Para esto se aplican los modelos previamente desarrollados, sobre el proceso de

compensación de cheques del Banco de la República de Colombia. Pero para poder hacer esto

primero es necesario entender el entorno en el que se está trabajando.

4.1 Descripción del Banco (20)

Figura 23 - Escudo Banco de la República23.

En el año de 1923, mediante la Ley 25 se creó la entidad pública que hoy se conoce como el Banco

de la República, el cual es desde entonces el banco central del país. Su razón social desde dicho

año ha sido sociedad anónima y el capital inicial fue de $10 millones oro del año, este oro estuvo

conformado de la siguiente forma, 50% lo aportó el Gobierno (dinero que ingreso al país

proveniente de la indemnización de Panamá) y la parte restante fue dada por los bancos

comerciales nacionales, extranjeros y algunos particulares.

Al Banco se le confió, en forma exclusiva, la facultad de emitir la moneda legal del país, motivo

por el cual en el momento de su creación deciden recoger todos los billetes de diferentes emisiones

existentes, circulando en el país y cambiarlos en su totalidad por los nuevos billetes emitidos por el

Banco de la República. Se le autorizó para actuar como prestamista de última instancia, administrar

las reservas internacionales del país, y actuar como banquero del Gobierno. Se decidió que la Junta

Directiva del Banco estaría conformada por 10 miembros, unos representantes del sector privado y

otros del Gobierno (organización que cambiaria con la ejecución de varias reformas a lo largo del

siglo XX), esta junta directiva se encargó y aun hoy en día se encarga de ejercer funciones de

23 Tomado de: http://www.banrep.gov.co/el-banco/images/escudo.jpg


regulación y control monetario, bajo estrictos parámetros de integridad financiera. Se le

encomendó, además, fijar la tasa de descuento y la intervención para controlar las tasas de interés.

La última gran reforma que tuvo el Banco vino con la materialización del Constitución política de

1991, en ésta se estipuló que la principal función del banco es reducir la inflación y mantenerla en

niveles bajos.

“Actualmente el Banco de la República es quien emite y administra la moneda legal y ejerce la

función de banquero de bancos. Además, controla los sistemas monetario (el dinero), crediticio (las

tasas de interés) y cambiario (la tasa de cambio) del país”24. Sus funciones son:

Emisión de Moneda Legal.

Funciones de Crédito del Banco de la República.

Banquero de Bancos.

Funciones Cambiarias.

Administración de las Reservas Internacionales.

Banquero, Agente Fiscal y Fideicomisario del Gobierno.

Promotor del desarrollo Científico, Cultural y Social.

Informe de la Junta Directiva al Congreso de la República.

En el anexo 6.7 se encuentra el detalle el organigrama del Banco. Para efectos del caso, en la figura

24 puede verse el organigrama de las áreas responsables de la gestión de riesgos operativos en el

Banco.

Figura 24 - Ubicación de áreas relacionadas con gestión de riesgos de TI dentro del organigrama del Banco.

24 Tomado de: Banco de la República, página web: http://www.banrep.gov.co/el-banco/hs_1.htm

Gerencia General

Gerencia Ejecutiva


Unidad de Riesgo

Operativo y Continuidad

Gerencia Técnica


Dentro de la Gerencia Ejecutiva se encuentran dos áreas relacionadas con la gestión de riesgos de

TI, la Unidad de Riesgo Operativo y Continuidad (UROC) y la Subgerencia Informática. La

UROC es la encargada de administrar los riesgos operativos dentro de los cuales se encuentran los

riesgos de TI y la Subgerencia Informática define las políticas y administra toda la infraestructura,

seguridad y aplicaciones de TI. Estas dos unidades trabajan unificadamente para el control de

riesgo de TI.

El Banco de la República es una entidad de gran tamaño que consta de un número significativo de

procesos. De todos los procesos existentes en el Banco, se ha escogido como proceso para ser

analizado, el proceso de compensación de cheques, ya que es uno de los procesos del banco que

depende en su mayoría de TI para su ejecución. A continuación el marco de gestión de riesgo

operativo y sus responsables.

4.2 Marco de gestión riesgos operativos (21)

Con la creación de la Unidad de Riesgo Operativo y Continuidad (UROC) el Banco está trabajando

en el proceso de estandarizar sobre un mismo modelo todos los riesgos operativos dentro de los

cuales están incluidos los riesgos de TI.

Dicho modelo se llama SIARO (Sistema Integral de Administración de Riesgo Operativo del

Banco), el cual consta inicialmente de una gestión previa del riesgo operativo en donde se analizan,

identifican, valoran los eventos potenciales de riesgo, adicionalmente se crean los perfiles de riesgo

operativo para posteriormente tener una gestión de eventos de riesgo operativo donde se

identifican, registran y gestionan eventos de riesgo y donde también se responde al riesgo

materializado permitiendo una retroalimentación con la gestión previa del riesgo como puede verse

en la figura 25.


Figura 25 - Administración de riesgo operativo en Banco de la República.

Dentro del modelo de gestión previa se consideran las posibles fuentes del riesgo, las amenazas y

vulnerabilidades, así como las causales, consecuencias e impactos de los potenciales riesgos y las

acciones de control para mitigar dichos riesgos y una de las fuentes del riesgo operativo son las TI

como puede observarse en la figura 26.

Figura 26 - Modelo de gestión previa del riesgo operativo en Banco de la República

Para el control de riesgos, el Banco ha desarrollado una taxonomía que denomina los sucesos que

se presentan como eventos, y con estos eventos mapea todos los casos de riesgo que han


identificado. Dentro de estos eventos, ha identificado un número de niveles de lo general a lo

específico para un mejor control. En la tabla 2 vemos los eventos definidos con respecto a TI.

Tabla 2 - Taxonomía para eventos relacionado con TI

Con esta taxonomía el Banco identifica los distintos eventos que tienen que ver con TI generando

así un lenguaje común al hablar de los riesgos. A continuación se presenta la subgerencia en la que

recae la mayor responsabilidad del control de riesgo de TI; la Subgerencia de Informática.

4.3 Subgerencia de Informática (1)

Es el área responsable por toda la gestión de TI dentro del Banco de la República, cuya misión es

“proveer soluciones informáticas que generen oportunidades al negocio del Banco y apoyen

estratégicamente a sus áreas. La subgerencia de informática entiende: por soluciones informáticas,

el conjunto de productos y servicios tecnológicos utilizados para satisfacer adecuadamente las

necesidades de administración de información del Banco, y entiende por generar oportunidades al

negocio, contribuir de manera proactiva en la búsqueda de alternativas viables que generen valor y

que permitan mejorar la gestión de la información, facilitando el cumplimiento de la misión de

cada una de las áreas del Banco”. La visión de la subgerencia es en el 2009, “seremos reconocidos

por nuestros clientes como socios estratégicos, resultado de una gestión que integra personas,

procesos y tecnología” (22). La subgerencia de informática incluye dentro de sus documentos de

gobierno tecnológico (23) y de políticas de la seguridad de la información (24) la gestión de

riesgos de TI.

Clasificación de eventos para los servicios de TI


Disponibilidad

Ninguna

Intermitencia

Lentitud

Limitada

Acceso Autenticación

Autorización

Seguridad

Integridad

Confidencialidad

Repudiación


La subgerencia de informática venía trabajando con una metodología de gestión de riesgos (25)

propuesta por el área de control interno, así como de mejores prácticas en informática a nivel

internacional, sin embargo, en este momento se encuentra trabajando en conjunto con la UROC en

la definición de una metodología integrada a la gestión de riesgo operativo del Banco.

El organigrama de la subgerencia de informática puede verse en la figura 27.

Figura 27 - Organigrama de Subgerencia de Informática

A continuación se describe el proceso denominado Compensación de cheques que fue el escogido

dentro del Banco para la validación de la guía de mejores prácticas de gestión de riesgo de TI.

4.4 Proceso de Compensación de cheques (26)

El proceso de compensación de cheques fue el seleccionado junto con el personal de la Unidad de

Riesgo Operativo y Continuidad (UROC) del Banco, debido a que es uno de los procesos de

negocio que ya han iniciado la gestión de riesgos operativos, dentro de los cuales se incluyen los

riesgos de TI, y el personal del área de negocio y de TI que ya ha recibido capacitación sobre el

modelo de gestión de riesgos operativos del Banco.

La compensación de cheques es un servicio prestado a nivel nacional en forma única por el Banco

de la República a través del CEDEC (Sistema de compensación electrónica de cheques) y Cámaras

de Compensación, que son los recintos donde se realiza el intercambio físico de los documentos.

Participan de este servicio los bancos comerciales, así como el propio Banco de la República quien

además administra el proceso.

Subgerencia de Informática

Departamento de Tecnología Informática

Departamento de Gestión Informática

Departamento de Seguridad

Informática

Unidad de Soporte y Continuidad

Informática

Organización de la Calidad

Coordinación Administrativa


Para la consolidación nacional de la información de los documentos presentados al cobro y en

devolución en las plazas donde el Banco de la República administra este servicio en forma directa

o a través de otra entidad participante, se utilizan tres mecanismos, en donde el principal se

describe a continuación:

En las seis principales ciudades del país, Bogotá, Medellín, Cali, Barranquilla, Bucaramanga y

Cartagena (donde se efectúa cerca del 90 por ciento del valor y el volumen total del canje a nivel

nacional) opera desde agosto de 1999 el CEDEC, que es una aplicación automatizada para la

presentación electrónica de los cheques en la cual se graba y transmite electrónicamente al Banco

de la República la información correspondiente a cada uno de los documentos presentados al

cobro en la respectiva ciudad.

El intercambio físico de los documentos se realiza en las cámaras de compensación del Banco de

la República, pero el cálculo de las posiciones netas se efectúa con base en los registros

electrónicos transmitidos por cada entidad al sistema en donde la entidad presentadora es el banco

que presenta un archivo con el listado de los cheques al cobro, para su pago por parte de las

entidades libradas a través del sistema CEDEC, como se puede observar en la figura 28.

Figura 28 – Diagrama del proceso de compensación de cheques en el Banco de la República

De igual forma, se procesan electrónicamente a través del CEDEC las devoluciones

correspondientes al primer canje de las citadas ciudades. El proceso se puede ver en la figura 29.

Una vez que se han validado los archivos con los datos de los cheques se procede al proceso de

devoluciones en el cual las entidades libradas envían el archivo con los cheques devueltos a las

respectivas entidades presentadoras.


Presenta un archivo con el listado de los cheques al cobro

CEDEC


Entidad Librada

Recibe el archivo consolidado de los cheques de su entidad


Figura 29 – Diagrama del proceso de devolución de cheques en el Banco de la República

Este proceso es automatizado y realizado de manera electrónica, el cual depende en casi un 95%

de los sistemas de información, y en el cual la operación humana es prácticamente nula,

limitándose al monitoreo de los estados del sistema.

4.4.1 Los sistemas más importantes para el proceso.

El proceso de compensación de cheques requiere de varios sistemas de información para su

funcionamiento, tales como Compensación Electrónica de Cheques (CEDEC), SEBRA

(Sistemas Electrónicos del Banco de la República), CUD (Cuentas de Deposito), HTRANS

(Transmisión de Archivos). El CEDEC es el sistema más importante ya que es el centro de

todo el proceso de compensación y liquidación de cheques.

El CEDEC funciona bajo las siguientes características generales:

Es un sistema diseñado para procesar la información relacionada con la totalidad de los

cheques y otros instrumentos de pago autorizados presentados al cobro y en

devolución diariamente, mediante un proceso centralizado en el Banco de la

República. El centro consolidador de cada entidad autorizada está conectado a este

sistema, para el envío y recepción de la información requerida.

Permite clasificar y totalizar la información recibida de cada una de las entidades

autorizadas participantes, con el fin de obtener las posiciones multilaterales netas a

favor o cargo de las mismas. Con el resultado multilateral neto obtenido se afectan en

forma definitiva las Cuentas de Depósito de las entidades, con lo cual se efectúa la

Liquidación.


Recibe el archivo con los cheques devueltos

CEDEC


Entidad Librada

Envía el archivo con los cheques devueltos a las entidades

presentadoras


El proceso se efectúa integralmente con información recibida electrónicamente, sin

perjuicio de que los documentos físicos continúen circulando en forma independiente a

la información.

El intercambio físico de los instrumentos de pago entre las entidades autorizadas se

realiza en las instalaciones de las Cámaras de Compensación y/o de las compañías de

procesamiento de cheques autorizadas por el Banco, y se sujeta al procedimiento

previsto para tal efecto en el Manual del Departamento de Servicios Electrónicos y

Pagos del Banco de la República.

Las entidades autorizadas, bajo su responsabilidad, podrán contratar con terceros

especializados la realización de todos o algunos de los procesos o actividades

necesarios para su participación en el CEDEC.

A los servicios del CEDEC pueden acceder los bancos autorizados para operar en Colombia,

siempre y cuando cumplan con la totalidad de condiciones y requisitos. Así mismo, podrán

vincularse a este sistema los otros establecimientos de crédito que en el futuro sean

expresamente autorizados por el Banco de la República - Subgerencia de Operación Bancaria.

Esta es la descripción de manera general del proceso de compensación de cheques, ahora se

procede a ver los resultados obtenidos con las listas de chequeo construidas en el capítulo 3.

4.5 Validación paso 4 de la guía

En esta sección se muestran los resultados obtenidos al hacer la validación de cada una de las listas

de chequeo que fueron construidas con base en los marcos de cada disciplina, y se definen los

planes de acción como propuestas para mejorar en cada una de éstas. Los otros pasos de la guía son

validados en el documento de tesis (1).

Respecto al criterio de selección de actividades para el plan de acción, éste consistió en tomar las

actividades que no ha desarrollado el Banco o que están en proceso de desarrollo en cada

disciplina. A continuación se presenta el análisis de los resultados obtenidos por disciplina, al

validar la guía en el Banco con el proceso de compensación de cheques.


4.5.1 Base tecnológica

La mayor parte de esta validación (anexo 1346.12) se llevo a cabo con la Subgerencia de

Informática más precisamente con la Unidad de Soporte y Continuidad Informática, que es la

directamente encargada de la Gestión de TI y de la Continuidad del negocio, aunque

previamente se revisaron los respectivos puntos de la lista de chequeo con la UROC.

Nombre Resultado Resultado máx.

posible Media (1 - 3) Actividades

evaluadas Plan de continuidad Entendiendo la organización

34 36

2.84 12

Determinando la estrategia de BCM

36

36 3

12

Desarrollando e implementando estrategias

12 12 3 4

Probando, manteniendo y revisando

9 9 3 3

Administrando BCM

9 9 3 3

Total 100 102 2.968 34 Encontrar y reparar falencias de TI Total 18 18 3 6 Gestión de TI Estrategia de servicio

33 33 3 11

Diseño de servicio 70 75 2.8 25 Transición de servicio

24 27 2.67 9

Operación de servicio

52 54 2.8 18

Total 179 189 2.84 63 Tabla 3 - Valoraciones numéricas por pasos de esta lista de chequeo.

Los resultados de la evaluación realizada mediante la lista de chequeo, son los siguientes (en

orden de los tres pasos de fortalecimiento de la base tecnológica):

De acuerdo con el primer paso, crear y probar todo un plan de continuidad del negocio, los

resultados muestran que el Banco tiene ya un trabajo fuerte de varios años de ejecución con

respecto a la continuidad del negocio y esto se refleja en el número de actividades que ya se

realizan como parte de las tareas organizacionales diarias y operacionales con respecto a la


compensación de cheques. Solo dos de estas se encuentran en proceso de elaboración, que son

la identificación de interdependencias entre actividades y la priorización de todas las amenazas

identificadas en la organización. Esto se debe a que las iniciativas para unificar toda la gestión

de riesgos de TI en el Banco no datan de mucho tiempo atrás y por el contrario es un proyecto

que está iniciando al interior de la organización. Esto permite ver que aunque ya existían

trabajos fuertes de gestión de continuidad en algunas unidades de negocio no era un estándar

para la organización, y de aquí que estas dos actividades que involucran a más de una unidad

de negocio están en proceso de realización.

En el segundo paso, encontrar y reparar las falencias de TI, no existen actividades propuestas

por la lista de chequeo que no estén siendo ya realizadas por el Banco y esto se debe a la

naturaleza de dichas actividades que son en un gran porcentaje operacionales como son la

identificación de falencias de la infraestructura y las respectivas ejecuciones de los planes de

solución de los problemas que estas causen, así como las mejoras definidas en pro de la

reparación de dichas debilidades estructurales de TI. Puede afirmarse de acuerdo con el análisis

realizado de acuerdo a la lista de chequeo que este paso es en el que más trabajo y experiencia

tiene el Banco (tanto en niveles operacionales como directivos), más puntualmente el proceso

de compensación de cheques. Cabe resaltar, sin embargo, que estas no son las únicas

actividades que involucran de forma directa la infraestructura de TI, sino que tanto en el paso

anterior como en el siguiente existen tareas y procedimientos que también lo hacen.

Finalmente, en el tercer paso, implementar controles para monitorear el estado de TI basado en

marcos estándar en la industria, se puede ver que es el paso que, dada su naturaleza

organizacional y de estrategia, es del que menos hay actividades ya implementadas en su

totalidad, muchas aun están en proceso de realización en su primer ciclo. Lo anterior, debido a

que la gestión de TI es un modelo de gestión que se empezó a implementar más recientemente

comparado con la gestión de continuidad y además debido a la diferencia de enfoques que en

un principio existía entre uno y otro; la gestión de continuidad hacía referencia a actividades de

carácter más operativo y por lo tanto ya había sido desarrollada con anterioridad al interior del

Banco. Actualmente, al hacer parte de un mismo modelo de gestión de riesgos de TI enfocado

desde y hacia la parte estratégica organizacional ambos tienen características tanto operativas

como administrativas y de gestión.


Mirando detalladamente los datos de la lista de chequeo se observa además que es la transición

de servicio la que más actividades y elementos tiene en proceso, debido a la poca frecuencia de

cambios en el servicio de compensación de cheques. Es un proceso estático que además no

necesita de innovación tecnológica constante, principalmente se necesita garantizar la

disponibilidad de la infraestructura ya existente para la prestación de dicho servicio y es por

esto que tanto la continuidad como la reparación de la infraestructura son los dos pasos más

completos al día de hoy.

Plan de acción para la disciplina de base tecnológica.

Luego de revisados los datos obtenidos mediante la validación del proceso mediante la lista de

chequeo, es conveniente diseñar el plan de acción cuyo objetivo principal es promover la

realización de las actividades que no estén siendo realizadas o la culminación en su primera

recursión de las que se encuentran en proceso de elaboración.

Para esto se van a enunciar en un cuadro dichas actividades, empezando con las que se

encuentren en grupos cuyas medidas sean las más bajas (Tabla valoraciones numéricas por

pasos de esta lista de chequeo), y así sucesivamente hasta llegar a las actividades que tuvieron

la media más alta en la tabla 3. Dicha clasificación o distribución se hizo dado que se conoce

de antemano que ninguna de dichas actividades es más crítica que las otras y además teniendo

en cuenta que los tres pasos del fortalecimiento de la base tecnológica son igualmente

fundamentales. Por lo cual es adecuado primero fortalecer los puntos más débiles y

consecutivamente continuar trabajando con los más sólidos actualmente.

Cuadro de actividades primordiales:

Actividad / Sugerencias Responsable

Etapa de Transición de servicio (ITIL)

Crear el Sistema de Administración de Configuraciones. Administrador de Cambios de TI.

Sugerencia: ITIL recomienda crear una base de datos de administración de configuraciones conocida

como CMDB. Esta base de datos debe contener la información de cada elemento de la infraestructura

y la relación existente entre estos. (Por elemento se entiende, hardware, software, documentos, etc.).


La CMDB busca ayudar a la organización a entender las relaciones entre todos los componentes, y

mantener el seguimiento de sus respectivas configuraciones.

Para obtener información más detallada y especializada remitirse al libro titulado “Service

Transition” de ITIL versión 3. ISBN: 9780113310913 (27)

Cabe anotar que actualmente el Banco cuenta con un CMDB auto descubrible en etapa de desarrollo.

El sistema de administración de configuraciones que se haya

construido debe contar con una estructura estándar que

permita definir claramente la configuración de cada ítem de la

infraestructura.

Administrador de Cambios de TI.

Sugerencia: El sistema de administración de configuraciones según ITIL y de acuerdo a los ítems

configurables debe contar con una estructura estándar de documentación. Para conocer dicha lista de

chequeo de la documentación completa según ITIL v.3 remitirse al Anexo 6.8.

Crear la documentación respectiva que describa cómo es

manejada y modificada la Información por medio de los

activos de TI y sus servicios.

Administrador de Cambios de TI.

Sugerencia: Dicha documentación debe contar con información básica, tal como: Qué información

maneja, qué tipo de información, cómo se transporta de un componente a otro, quién es responsable

de cada segmento de la información, dónde se almacena finalmente dicha información. Para obtener

información más detallada y especializada remitirse al libro titulado “Service Transition” de ITIL

versión 3. ISBN: 9780113310913 (27)

Etapa de Diseño de servicio (ITIL)

Determinar y documentar los requerimientos legales de cada

servicio.

Administrador de seguridad de TI.

Sugerencia: El objetivo principal de documentar los requerimientos legales de cada servicio es

determinar cómo se alinearán estas consideraciones legales con las del proceso involucrado y con las

de la organización en general. Por lo tanto es adecuado y necesario considerar los siguientes puntos

al momento de determinar dichos requerimientos:

Disponibilidad del servicio y de la información que éste maneja.

Confidencialidad de la información creada, modificada o salvada por y durante la ejecución del

proceso.

Integridad de la infraestructura en pro de la adecuada ejecución del proceso.

Consideraciones de integridad de la información.

Consideraciones de autenticidad de la información recibida y enviada.

Todas estas consideraciones deben estar alineadas con las políticas y estrategias de seguridad de la

organización. (28)

Crear métodos de supervisión y monitoreo de los servicios de Administrador de nivel de


acuerdo a los SLA’s concertados. servicio.

Sugerencia: Los SLA´s deben definirse para cada servicio y por lo tanto debe tenerse una forma clara

de los métodos de supervisión y monitoreo, sobre el mismo. Por lo tanto, lo más adecuado es dar

algunos principios básicos que permitan escoger las métricas y de la misma forma los métodos de

obtención de dichas métricas (29):

Escoger medidas que motiven un comportamiento adecuado de las TI.

Asegurarse que las medidas reflejan factores controlables por el proveedor específico del servicio.

Escoger medidas que son fácilmente obtenibles.

No escoger una cantidad incontrolable de medidas.

Conservar información histórica de las medidas escogidas.

Escoger métodos de medición flexibles y de fácil modificación o cambio.

Para conocer más a fondo las especificaciones de ITIL versión 3 con respecto a los SLA´s, revisar la

librería desarrollada directamente por la OGC relacionada con diseño de servicio. ISBN:

978011331090 (27).

Analizar y documentar los estados óptimos de capacidad y de

desempeño de los servicios y recursos entregados por TI.

Administrador de Capacidad de

TI.

Sugerencia (30): Para poder analizar y conocer dichos estados es necesario primero obtener datos

del rendimiento actual de TI.

Los KPI (Indicadores claves de rendimiento) recomendados por ITIL v.3 para la administración de

capacidad, son (31):

Número de incidentes debido a falta de capacidad.

Pronostico de capacidad.

Número de ajustes de mejora en la capacidad.

Número de ajustes no planeados en la capacidad debido a embotellamientos.

Tiempo de resolución de cada embotellamiento.

Porcentajes de reservas de la capacidad en condiciones de demanda máxima y normal.

Porcentaje de elementos de la infraestructura que son monitoreados, relevantes para la capacidad del

sistema.

Comparar los estados óptimos con los actuales y planear los

estados futuros, mediante las actualizaciones respectivas a la

infraestructura o la modificación de la misma.

Administrador de cambios de TI.

Sugerencia: Una vez creados los indicadores y los métodos de medición, esta actividad será cuestión

de comparar datos y estadísticas para planear modificaciones y actualizaciones de elementos

configurables propios de la infraestructura.

Documentar los estados futuros de rendimiento y capacidad

de la infraestructura de TI.

Administrador de cambios de TI.


Sugerencia: Consiste en documentar adecuadamente los resultados obtenidos de la actividad

inmediatamente anterior.

Etapa de Operación de servicio (ITIL)

Realizar administración de eventos. Administrador de operaciones de

TI. Operadores de TI.

Sugerencia: De acuerdo a ITIL v.3 la administración de eventos consta de los siguientes sub-procesos

(31). Por lo tanto una adecuada administración de eventos debe contar con::

Mecanismos y reglas de monitoreo de eventos.

Filtrado y categorización de eventos.

Selección de correlaciones y respuestas a eventos.

Revisión y cierre de eventos.

Para conocer más a fondo las especificaciones de ITIL versión 3 con respecto a la administración de

eventos, revisar la librería desarrollada directamente por la OGC relacionada con operación de

servicio. ITIL – Service Operation. ISBN: 9780113310920 (27).

Crear métodos adecuados (probados exitosamente) de

comunicación de eventos internos. (email, sms, llamada).

Administrador de operaciones de

TI. Operadores de TI.

Sugerencia: Crear métodos de comunicación de eventos en caso de que dicho evento necesite de

intervención oportuna alguna (dado que no todos los eventos necesitan de intervención, lo más

importante de estos es documentarlos y ponerlos en la bitácora correspondiente). Dichos métodos o

medios pueden ser los mismos usados para la comunicación de incidentes o de problemas utilizados

actualmente. (Intranet del banco)

Entendiendo la organización (BCM)

Identificar interdependencias entre actividades críticas. Grupo administrador de la

creación del BIA.

Sugerencia: El principal motivo de identificar estas interdependencias es crear documentación

precisa que permita construir un BIA (Análisis de impacto del negocio), completo y detallado. Y para

tal actividad los guías del programa de BCM recomiendan realizar:

Talleres grupales.

Cuestionarios (mediante: papel, software especializado).

Entrevistas (estructuradas, no estructuradas, formales e informales).

La combinación adecuada de estas técnicas para la obtención de información, pueden proveer los

resultados exactos y detallados que permitirán llevar a cabo el BIA completo.

Para conocer más a fondo talleres y, cuestionarios para la recolección de datos, revisar las guías del

BCM Programme creadas y expuestas por el BCI. (11) Sección 2.1 – Understanding the organization.

BCI website: http://www.thebcicertificate.org/bci_gpg.html.


Crear la lista de priorización de amenazas de la organización. Grupo administrador del análisis

de riesgos.

Sugerencia: Al terminar el BIA y teniendo el resultado del análisis, será posible encontrar las

amenazas mediante los siguientes métodos y técnicas:

Árbol de análisis de eventos.

Árbol de análisis de fallas.

Y se priorizarán las amenazas de acuerdo a fórmulas matemáticas creadas que estarán generadas de

acuerdo a los intereses de la organización. En la mayoría de ocasiones se calcula el impacto que

podría tener dicha amenaza en el negocio, y de esta forma se calcula el riesgo como la multiplicación

del impacto de la amenaza por la probabilidad de ocurrencia. También en algunos se casos se

prioriza de acuerdo al riesgo por la habilidad de controlar dicho riesgo.

Para conocer más a fondo talleres y, cuestionarios para la recolección de datos, revisar las guías del

BCM Programme creadas y expuestas por el BCI. (11) Sección 2.3 – Understanding the organization.

BCI website: http://www.thebcicertificate.org/bci_gpg.html.

Revisar de nuevo todas las actividades que se

consideraron ya realizadas (marcadas con SI en la lista de

chequeo); hacerlo de forma periódica

Responsable de cada una de las

actividades de la lista de chequeo.

(responsabilidades definidas de

acuerdo a los roles respectivos)

Tabla 4 - Actividades primordiales Base tecnológica

Al finalizar la construcción de este cuadro se vuelve a hacer la respectiva validación del

proceso mediante la lista de chequeo y se reconsidera el desarrollo de cada una de las

actividades de forma periódica, estos ciclos de recursión periódicos están asociados a cada

actividad.

4.5.2 Gobierno

La validación de esta disciplina no cubre únicamente el proceso de compensación de cheques,

ya que sus componentes no se limitan a un único proceso, sino que tiene un alcance

corporativo.

Al validar con dos ingenieros consultores del área de la calidad de la subgerencia de

informática y con una ingeniera de la UROC se obtuvieron los resultados mostrados en el

anexo 6.13.


El componente de roles se encuentra muy bien estructurado dentro del Banco, estos roles

aplican para toda la organización. Si bien los nombres de los roles existentes dentro del Banco

no siempre coinciden, si existen funciones similares que permiten asociarlos con los propuestos

por esta investigación.

El rol de Patrocinador ejecutivo, lo cumple el Consejo de Administración que es la máxima

autoridad en materia de gestión del riesgo en el Banco y es el ente responsable de fijar políticas

generales que orienten la gestión particular del riesgo operativo dentro del cual se encuentra el

riesgo de TI.

El rol de Consejo de políticas de riesgo, lo cumple el Consejo de Administración en conjunto

con el Comité de Riesgo Operativo y Continuidad (CROC) ya que son los entes encargados de

fijar políticas de riesgo y monitorear, evaluar y reportar al Consejo de Administración la

efectividad del SIARO.

El rol de Consejo de implementación, lo cumple la UROC junto con los líderes de riesgo de

cada subgerencia dentro del Banco, ya que la UROC es la responsable de estructurar,

mantener, liderar, asesorar y monitorear la implementación y desarrollo del SIARO dentro del

Banco y los líderes de riesgo de cada subgerencia son los responsables de liderar y asesorar a

cada área de negocio en la implementación el SIARO dentro de sus respectivas áreas.

El rol de Equipo de manejo de riesgos de TI, se cumple uniendo los esfuerzos de la UROC, el

líder de riesgos de cada subgerencia incluido el líder de riesgos de la subgerencia de

informática y un equipo interdisciplinario de ingenieros de la subgerencia de informática que

tienen el conocimiento técnico necesario sobre la base tecnológica.

Los Gerentes locales son representados por los líderes de riesgo de cada subgerencia junto con

los jefes de cada área de negocio quienes son los responsables de la implementación del

SIARO dentro de sus respectivas áreas, lo cual incluye las actividades relacionadas con la

identificación, valoración, tratamiento, registro y gestión de los eventos de riesgo operativo,

con el apoyo de la UROC y el equipo interdisciplinario de ingenieros antes mencionado.


Finalmente, el Oficial de riesgo de TI se puede asociar al líder de riesgo de la SGINF quien es

el responsable de la gestión del riesgo de TI dentro del Banco.

A continuación, en la figura 30, se pueden observar estos roles dentro del Banco.

Figura 30 - Definición de roles dentro del Banco de la República.

Al revisar el componente de proceso de gestión de riesgos de TI de la disciplina, se encontró

que no obstante el Banco venía haciendo el proceso de acuerdo a los lineamientos dados por el

departamento de control interno, se tomó la determinación de crear recientemente un área

exclusivamente para la gestión de riesgos operativos y por lo tanto dentro de este cambio hay

muchas actividades que se encuentran en proceso y otras que aun no han iniciado, sin embargo,

si se tiene planeado realizarlas.

Dado la reciente creación de la UROC, un poco más de un año, y por lo tanto de las políticas

de gestión de riesgo éstas no se han revisado nuevamente ni se ha definido claramente con que

periodicidad se deben revisar.

A pesar que existe un inventario de procesos de negocio con sus recursos de TI, no se ha

identificado plenamente cuáles de éstos son fuertemente dependientes de TI.

El proceso de identificación de riesgos de TI descentralizado se está llevando a cabo en estos

momentos, porque a pesar que las áreas de negocio son las responsables de dicha

identificación, requieren el apoyo de la UROC y del grupo de ingenieros. Dicho proceso inició

por las áreas de negocio de mayor impacto y la UROC no ha cubierto el requerimiento de

LÍDERES DE RIESGO DE CADA SUBGERENCIA

UROC Y LÍDERES DE RIESGO DE CADA SUBGERENCIA

CONSEJO DE ADMINISTRACIÓN Y COMITÉ DE RIESGO OPERATIVO Y CONTINUIDAD

UROC, EQUIPO DE

INGENIEROS Y LÍDERES

CONSEJO DE ADMINISTRACIÓN VISIÓN

GLOBAL

EXPERTISE LOCAL

CONSEJO DE AOPOPOP

UROC, EQUIPO DE

INGENIEROS Y LÍDERES

LÍDER DE RIESGO SGINF


asesoría a la totalidad de áreas del Banco, por lo tanto a pesar que se han hecho campañas

corporativas todavía no se ha logrado llegar a toda la organización y no todo el personal sabe

cómo reaccionar ante un evento de riesgo de TI.

En cuanto al modelo del proceso de recolección de datos relacionados con riesgos de TI, existe

una taxonomía de riesgos de TI la cual está relacionada con la taxonomía de riesgos general,

sin embargo, la taxonomía de riesgos de TI se encuentra todavía en revisión lo cual hace que

no se haya definido una categorización y priorización definitiva de los riesgos de TI.

Una vez que los riesgos de TI son identificados la subgerencia de informática ya tiene definido

el tratamiento que se debe dar a cada uno de ellos. Sin embargo, esta metodología se está

revisando para unificarla con el marco propuesto por la UROC. La actual metodología usada

por la subgerencia informática cubre los riesgos de seguridad informática, disponibilidad y

proyectos como puede verse en la figura 31 (25).

Figura 31 - Proceso actual de gestión de riesgos de TI subgerencia de informática (25).

Respecto al historial y monitoreo de los riesgos de TI la subgerencia de informática desarrolló

desde hace varios años un proceso de monitoreo automático de la base tecnológica y un

registro de incidentes y problemas técnicos de los diferentes servicios de TI ofrecidos, sin

embargo, este monitoreo y registro es interno dentro de la subgerencia de informática y no se

ha extendido a los ejecutivos de las áreas de negocio salvo incidentes con un gran impacto en

el negocio. En cuanto al proceso de revisión “post-mortem” la subgerencia de informática ha


definido reuniones periódicas para la revisión de dichos incidentes y el planteamiento de

posibles soluciones para evitar que se presenten nuevamente los mismos incidentes.

Ante la presencia de incidentes de TI se han creado planes de continuidad de negocio los

cuales tienen implícitos los recursos de TI necesarios, adicionalmente algunos procesos de

negocio tiene planes de continuidad que excluyen los recursos de TI con los cuales se opera

normalmente y ante la presencia del incidente se puede operar con diferentes recursos como

por ejemplo reemplazar el correo electrónico por envíos vía fax.

Al validar el tercer componente de la disciplina de gobierno se encontró que también está

bastante desarrollado dentro del Banco, ya que siempre se están revisando las mejores prácticas

tanto del sector financiero, como de Banca Central, así como las mejores prácticas de TI.

Dado que la UROC tiene como objetivo la gestión del riesgo operativo el cual es mas general

que el riesgo de TI, el proceso de gestión de riesgos de TI se encuentra en el proceso de

alineación con la gestión de riesgos empresariales y sus prácticas están siendo estandarizadas

con los objetivos organizacionales.

Adicionalmente el Banco aplica las mejores prácticas del sector como por ejemplo Basilea, y

las mejores prácticas de TI como por ejemplo COBIT, ITIL, PMI. Como puede observarse en

la figura 32. Donde COBIT es el marco global y para cada uno de los objetivos de este modelo

el Banco establece otros modelos de referencia que son complementarios, se seleccionan

modelos que se puedan personalizar a las necesidades del Banco y de la SGINF (23).

Como conclusión se puede observar que el Banco de la República es una entidad que ha

prestado atención a la gestión de riesgos en general y que la gestión de riesgos de TI ha tomado

gran importancia ya que desde hace varios años se ha preocupado por tener definido un

gobierno de riesgos de TI. En el momento de la realización de esta investigación se dio una

situación coyuntural en la cual hay muchas actividades en desarrollo debido a la

reestructuración interna de la gestión de riesgo operativo.


Figura 32 - Mejores prácticas de TI en la subgerencia de informática (23)

Plan de acción para la disciplina de gobierno.

De acuerdo con la validación realizada para esta disciplina se propone el siguiente plan de

acción para continuar desarrollando el gobierno de riesgo de TI dentro del Banco de la

República.

Actividad / Sugerencias Responsable.

Proceso para el control de riesgo de TI.

Actualizar regularmente la política de riesgos de TI UROC – SGINF

Sugerencia: Revisar y actualizar, si es necesario, las políticas una vez se cuente con

retroalimentación. (8).

El proceso de identificación de riesgos de TI es

descentralizado y recae sobre los jefes de cada área de

negocio.

UROC – SGINF- Líderes de

riesgo en cada Subgerencia

Sugerencia: Realizar el proceso de gestión de riesgos operativos con cada una de las áreas

de negocio y asignar un responsable por cada área respecto al tema de riesgo operativo.

Existe un modelo para el proceso de recolección de

datos relacionados con riesgos de TI.

UROC – SGINF

Sugerencia: Definir modelo y herramienta de recolección de datos relacionados con riesgos

de TI.

Se ha creado una definición formal de categorías de

riesgo de TI. (14)

UROC – SGINF


Sugerencia: Definir la taxonomía definitiva de riesgos de TI. e integrarla en la taxonomía de

riesgos operativos.

Se han definido categorías de riesgos de TI por orden de

importancia. (14)

UROC – SGINF

Sugerencia: Priorizar riesgos de TI según las necesidades de cada área de negocio, de

acuerdo a las amenazas a las que se encuentre expuesta el proceso de negocio y a un

historial de eventos que permita evaluar cuales son los más repetitivos.

Se ha definido el nivel de riesgo que la organización

está dispuesta a tomar "apetito al riesgo". (8).

Consejo de Administración

Sugerencia: Definir el nivel de riesgo de la organización

Evaluar si el "apetito al riesgo" está alineado con las

políticas y estándares definidos por la organización.

Consejo de Administración –

UROC

Sugerencia: Definir el nivel de riesgo de la organización y evaluar si se encuentra alineado

con las políticas y estándares

Se han definido claramente indicadores de riesgo de TI

(14)

UROC – SGINF

Sugerencia: Definir indicadores jerárquicos de riesgo de TI, acorde a los niveles actuales de

indicadores de las SGINF.

Se lleva un historial de los riesgos de TI para

monitorear su evolución y asegurarse que dichos riesgos

sean mitigados teniendo en consideración los puntos de

vista de los ejecutivos de todas las áreas

UROC – SGINF

Sugerencia: Adquirir herramienta de monitoreo para poder registrar eventos de riesgo de TI

que permita llevar un historial y así mismo poder tomar acciones tanto preventivas como

correctivas.

Definición de roles, políticas y funciones para controlar riesgos de TI.

Existe un monitoreo de los riesgos de TI para que

cumpla con las políticas y estándares definidos por los

Consejos de políticas e implementación.

UROC -SGINF

Sugerencia: Adquirir herramienta de monitoreo que permita evaluar periódicamente si las

políticas generadas son las adecuadas o deben revisarse.

Las personas responsables de la gestión de riesgos de TI

promueven una comunicación efectiva sobre el tema.

UROC – SGINF- Líderes de

riesgo en cada Subgerencia


Sugerencia: Realizar el proceso de gestión de riesgos operativos con cada una de las áreas

de negocio y asignar un responsable por cada una de las áreas.

Mejores prácticas.

Se proveen los recursos adecuados para la gestión de

riesgos de TI

UROC -SGINF

Sugerencia: Definir y adquirir la herramienta de monitoreo de riesgos para tener un

historial de los mismos y de esta manera poder gestionarlos adecuada y oportunamente.

Tabla 5 - Actividades primordiales Gobierno

El anterior plan de acción son recomendaciones realizadas en este estudio a partir de la

información obtenida con la UROC y la SGINF para la disciplina de gobierno, sobre la

situación actual de gestión de riesgos de TI no solo para el proceso de compensación de

cheques sino a nivel general de la organización.

4.5.3 Cultura

Para desarrollar el análisis cultural sobre el proceso de compensación de cheques, se

identificaron los departamentos que se encuentran involucrados, estos son:

La unidad de riesgo operacional y continuidad

La subgerencia Informática

Subgerencia de operación bancaria

A cada uno de ellos se aplicó la lista de checheo planteada en el capítulo anterior. A

continuación se presentan los resultados obtenidos los que se pueden ver en el anexo 6.14.

UROC

Se realizó la evaluación con la unidad confrontando la lista de chequeo con el área, se

valoraron los puntos de la guía y se obtuvieron los siguientes resultados:

Cultura social de riesgo

En este componente podemos ver que en el área están presentes los 5 comportamientos

consultados, ya que siendo la unidad encargada de los comportamientos sociales son parte

de la razón de ser de esta área.

Políticas y Reglamentación

En este componente se empiezan a ver oportunidades de mejora en los comportamientos

ya que solamente se cumple el tener una normatividad general, pero no se tienen


diferenciado lo público de lo privado, no hay una especificación para los diferentes tipos

de miembros de la organización y por ende estos no tienen una diferenciación pública o

privada. El lograr esto permitirá un fortalecimiento en la cultura de riesgo de TI.

Entrenamiento y campañas de sensibilización

En este componente se encuentra solo un comportamiento, que es desarrollo de campañas

de concientización, pero no existe diferenciación de público en éstas. A demás no se

encuentra desarrollado un modelo de entrenamiento formal para la divulgación de la

normatividad.

Aceptación cultural

Dentro del área, se ve un gran nivel de aceptación cultural, ya que en la evaluación se

presentan los cinco comportamientos de aceptación. Esto también es esperado del área por

su misma razón de ser.


En la valoración de la subgerencia se evaluaron comportamientos en dos de sus sub-

departamentos, la unidad de soporte y continuidad informática y el departamento de

seguridad informática. De cada uno se aplicó la lista de chequeo de cultura en su totalidad.

A continuación se presentan los resultados de cada una de ellas.

o Unidad de soporte y continuidad informática

Cultura organizacional de riesgo de TI

Según lo validado con esta área, dentro de si misma se presentan todos los

comportamientos deseados con respecto a la cultura organizacional. Siendo desde

mucho tiempo atrás fuente empírica de ellos.


Este componente luego de la validación, da como resultado que se presentan todos los

comportamientos deseados en cultura social de riesgo, siendo esta área la encargada de

riesgo antes de la creación de la UROC la encargada del control de riesgo, tienen estos

comportamientos bien asimilados.



La normatividad es bien asimilada y conocida por el área, es necesario hacer énfasis

que no existe la diferenciación por cargo, pero sobre esto se está trabajando, y se tiene

planteado la diferenciación entre público y privado pero esto aun no se ha comenzado a

planear.


En el área se presentan campañas de sensibilización, el desarrollo de entrenamientos al

igual que la diferenciación en las campañas se están desarrollando. Por ende el

entrenamiento activo, aun no se presenta.


La aceptación es alta en la mayoría de comportamientos deseados, exceptuando en la

participación activa de los miembros del área, aunque sobre esto se está trabajando.

o Departamento de seguridad informática


Al igual que la unidad de soporte y continuidad esta área ha venido trabajando el tema

de cultura organizacional por un tiempo el desarrollar cultura organizacional, se ve en

la lista de chequeo que presentan los comportamientos deseados para este componente.


En este componente se identifica un nivel aceptable en con respecto a los

comportamientos sugeridos con respecto a el área presenta comportamientos

espontáneos y se generan normas de estos, están en proceso de identificar los líderes y

aunque todo el personal del área conocen las normas existentes hasta no tener estos

líderes identificados no es posible generar la comunicación que se quiere.


La normatividad se encuentra bien definida y existe conciencia entre lo público y

privado con respecto a la normatividad. Se tiene una normatividad especializada, mas

no presenta una diferenciación entre lo público y lo privado.



Dentro del área se presentan todos los comportamientos sugeridos para tener un nivel

cultural en este componente.


El área considera que en los comportamientos de aceptación cultural, desarrolla todos

los comportamientos propuestos, ya que siendo fin la seguridad, valoran mucho la

retroalimentación sobre el conocimiento y valoración del riesgo de TI.

Subgerencia de operación bancaria

Dentro de la subgerencia de operación bancaria, se encuentra el área de negocio encargada

de la compensación de cheques. Siendo el área en estudio la cultura, era necesario validar

con esta área ya que la cultura sobre el proceso incluye a todos los involucrados. Los

resultados obtenidos en son:


Los comportamientos que se buscan en la organización se encuentran en su mayoría dentro

del área, aunque es baja la interacción con respecto al riesgo de TI de los altos mandos

hacia los subalternos, principalmente porque el personal con el que se cuenta es escaso y el

día a día no permite este tipo de interacciones.


En este componente lo más notorio es que dentro del área no se tiene identificado a ningún

líder social, la falta de este, o mejor el no tenerlo identificado disminuye la posibilidad de

entregarle las responsabilidades que se desean para la propagación cultural. Pero es

necesario también denotar que los comportamientos espontáneos de control de riesgo han

sido de gran ayuda y desde el área de negocio se han generado comportamientos que han

forjado el control de riesgo de TI.


Es el componente más débil en el área, porque aunque se conoce la normatividad general,

no se presentan los demás comportamientos, es necesario enfatizar que, como se


encuentran designadas lar responsabilidades al interior del Banco, que éstas no se

conozcan no es un error del área.


En el área si se han ejecutado campañas y entrenamientos, pero éstas aun no tienen forma

dinámica ni especializada, es puntual rescatar la intención de los miembros del área de

tener por lo menos un miembro presente en las capacitaciones que se presenten, para luego

compartir el conocimiento con el resto del área.


La aceptación que se presenta de los comportamientos promulgado dentro del Banco es

alta en el área, aunque es necesario resaltar que ellos consideran que la aplicación de las

mismas, es baja ya que con el día a día el trabajo no permite una aplicación satisfactoria de

los controles de riesgo.

Luego de tabular y comprar los resultados obtenidos en las validaciones, se puede dar la

siguiente valoración con respecto al nivel cultural existente en el proceso.


Dentro del proceso se puede encontrar que la cultura organizacional en cada una de las

áreas está presente y las áreas desde sus directivos se preocupan por desarrollarla y

consolidarla dentro de sus áreas y por ende el proceso se ve fortalecido. Este componente

fue el que obtuvo el mejor puntaje durante la validación.


Este componente en el proceso se ve en un porcentaje un poco más bajo que el anterior,

pero aun tiene un puntaje aceptable. Se presenta en el proceso los comportamientos

espontáneos y la formalización de controles, pero no se les saca provecho a los líderes

sociales y en algunos casos no se tienen identificados. Este componente obtuvo el mismo

puntaje que el componente de aceptación, pero en este componente en algunas de las áreas

los comportamientos no se dan. Por esto obtiene el tercer puntaje de la validación.



El proceso con respecto a las políticas y divulgación de las mismas, se presenta que en

todos los casos se tiene una normativa general, pero no existen normatividades

especializadas a cada cargo ni la diferenciación entre lo público y lo privado que permita

el crecimiento cultural hacia ellas. Este componente es el que tiene menor puntaje de en la

validación.


Este componente en el proceso presenta que se presentan comportamientos de

entrenamiento y campañas con respecto a la concientización del riesgo, pero ni los

entrenamientos son dinámicos, ni las campañas diferencian público. Por esto este

componente se ubica en menor puntaje en la validación.


El proceso desde el componente de aceptación presenta algunos de los comportamientos

deseados como la valoración de la importancia de las campañas y el surgimiento de

sugerencias para el mejoramiento de las normas, y se encuentran en proceso los otros

comportamientos deseados. Por esta razón aunque en puntaje obtiene el mismo que el

componente social, este obtiene el segundo mejor puntaje de la validación.

De acuerdo con los resultados obtenidos durante la validación se puede recomendar que se

desarrolle el siguiente plan de acción para mejorar el nivel cultural del proceso.

El plan de acción

Luego de ver el estado del proceso de compensación de cheques, mediante la validación de los

componentes el puntaje obtenido en orden descendente, cultura organizacional, aceptación

cultural, cultura social, entrenamiento y campañas de sensibilización y por último políticas y

reglamentación. Sobre los tres últimos componentes se plantea en siguiente plan de acción

presentado dentro de la Tabla 6.

Actividad / Sugerencias Responsable.


Diferenciar lo que es público y lo privado en la normatividad UROC


general existente.

Sugerencia: En las normas existentes sobre el control de riesgo, se debe diferenciar que es público y por

ende se pueden divulgar sin discreción y que es privado, haciendo referencia a temas de seguridad que se le

debe dar un tratamiento especial.

Construir normas específicas para los distintos tipos de cargos

que se encuentran involucrados en el proceso.

UROC

Sugerencia: Dentro de los cargos que tienen responsabilidades en el proceso es necesario desarrollar

normatividad que sea específica para cada uno de ellos. Esto se desarrolla tomando cada cargo

independientemente, evaluando los riesgos propios de TI en éste plasmándolo en un lenguaje que sea claro

para quién ejerce ese cargo.

Definir para cada cargo qué información es pública y privada. UROC

Sugerencia: En las normas sobre el control de riesgo específicas para cada cargo, diferenciar que

información es pública y por ende se pueden divulgar sin discreción y que información es privada, haciendo

referencia a temas de seguridad especiales para su tratamiento.


Incluir dentro de los planes de capacitación los controles de

riesgo.

UROC

Sugerencia: Dentro de los planes de capacitación de cada uno de los nuevos empleados, incluir la

normatividad general y si existe la específica con respecto a control de riesgo.

Utilizar los medios de comunicación existentes para divulgar

la normatividad que a sido complementada en el segmento

anterior.

UROC

Sugerencia: Con los canales de comunicación que posee el banco divulgar los cambios realizados en la

normatividad para dar a conocer su existencia a los miembros de la organización

Con la normatividad por tipo de cargo diferenciada,

desarrollar campañas y entrenamientos acordes con éstas.

UROC

Sugerencia: Desarrollar capacitaciones para los cargos en que se hayan hecho cambios específicos en la

normatividad, haciendo que la persona que ocupa el cargo sea consciente de la existencia.


Identificar los líderes sociales dentro del proceso. UROC – Recursos humanos

Sugerencia: utilizar los medios existentes en el departamento de recursos humanos, para la

identificación de líderes.

Inculcar en los líderes sociales las normas establecidas en el

componente de normatividad.

UROC – Recursos humanos

Sugerencia: a los líderes encontrados en la acción anterior capacitarlos en el conocimiento de las


Tabla 6 - Actividades primordiales Cultura

Si se logran desarrollar todas las acciones propuestas hasta este punto, es recomendable

reevaluar el proceso para ver el impacto obtenido, ya que el completar el fortalecimiento de

estos tres componentes puede llevar en tiempo alrededor de un año. A continuación le se

presenta la síntesis de los planes de acción.

4.5.4 Síntesis de los planes de acción

Para concluir la validación de la guía, es necesario presentar el porqué, el punto anterior de

priorización de disciplinas es el correcto y como la disciplina seleccionada influye en las otras

dos.

En la Guía de mejores prácticas de gestión de riesgo TI en el sector bancario Colombiano (1),

se obtuvo como resultado que la disciplina que se va a trabajar es gobierno. Como se explicó

anteriormente las disciplinas no son independientes y los avances que se hagan en una pueden

de manera indirecta fortalecer aspectos de otra disciplina. Con el plan de acción presentado

para gobierno, a continuación se presenta cómo influye en las otras disciplinas en la tabla 7.

Componente/Actividad Base Tecnológica Cultura

Componente: Proceso para el control de riesgo de TI.

1. Actualizar

regularmente la

política de riesgos

de TI.

La constante actualización de las

políticas de riesgo impacta directamente

los planes de continuidad, primer paso

del fortalecimiento de la base

tecnológica, dado que dentro del ciclo de

BCM una etapa especifica es el análisis

de riesgos encaminado a identificar las

estrategias que garanticen la continuidad

El desarrollar esta acción de gobierno,

influye en el componente de

normatividad de cultura, ya que el

desarrollarlo permite que se tengan

unas políticas más diferenciadas

mejorando la madurez de la

normatividad.

normas existentes en el control de riesgo.

Preparar a los líderes sociales en formas de comunicación

para que propaguen las normas entre sus compañeros.

UROC – Recursos humanos

Sugerencia: definir medios y formas de comunicación para que los líderes sociales sepan como

transmitir los conocimientos que han adquiridos en la acción anterior. Apoyándose en los canales

de comunicación existentes en el banco o creando nuevos de ser necesario.


y disponibilidad de los componentes de

la infraestructura de TI asociados al

negocio.

2. El proceso de

identificación de

riesgos de TI es

descentralizado y

recae sobre los jefes

de cada área de

negocio.

La ventaja de distribuir estas

responsabilidades por áreas es que

permite que los dueños de cada uno de

los “negocios”, que son los conocedores

mas expertos, comuniquen de manera

efectiva a los demás miembros de la

organización, en particular a los

directivos, cuáles son los riesgos más

relevantes para el negocio y la

organización en general, y

consecutivamente su impacto para la

organización.

Al entregar esta responsabilidad de

identificación, mejora los componentes

de cultura organizacional y el de

aceptación cultural, ya que dentro de

ellos los jefes de área cumplen un papel

importante y se les da la

responsabilidad del riesgo

3. Existe un modelo

para el proceso de

recolección de datos

relacionados con

riesgos de TI.

La información recogida por medio de

este modelo, será un insumo importante

tanto para la gestión de continuidad

como la gestión de TI. Tanto en uno

como en otro se requiere la recopilación

de datos históricos para la toma de

decisiones y la planeación y creación de

nuevos proyectos. Por ejemplo, datos de

vulnerabilidades, puntos de falla, etc.

El desarrollar este modelo permite que

el componente de aceptación social

mejore ya que incluye la prevención del

riesgo dentro del día a día de la

organización.

4. Se ha creado una

definición formal de

categorías de riesgo

de TI.

Esta definición permite estandarizar la

gestión de riesgos y al hacer registro de

los incidentes en cada categoría definida,

se puede mejorar la certidumbre del

cálculo de riesgos tanto para creación e

estrategias de continuidad como para su

mantenimiento.

El crear esta definición formal permite

mejoras en el componente de políticas y

reglamentación, ya que las definen los

riesgos y permite la diferenciación de la

normatividad en los aspectos que se

desean en el componente.

5. Se han definido

categorías de riesgos

de TI por orden de

importancia.

Esta categorización ayuda de forma

efectiva a la realización y creación

adecuada del plan de continuidad, dado

que permite saber cuáles son los riesgos

más críticos que afectan a la

El que se tenga esta acción, permite que

el conocimiento de la normatividad y la

aceptación del control de riesgo, se

logre en el día a día ya que será más

visible para la organización.


organización. Además permite hacer una

Gestión de TI eficiente más precisamente

una Gestión de cambios en la

infraestructura, adecuada y acorde a las

necesidades del negocio. Permitirá saber

cuáles riesgos deben abordarse primero,

o con cierta prioridad.

6. Se ha definido el

nivel de riesgo que

la organización está

dispuesta a tomar

"apetito al riesgo".

El tener adecuadamente definido el

apetito al riesgo, permitirá definir

políticas afines a los niveles de riesgo,

que encajen coherentemente con la

infraestructura que se tiene o que se

planea tener. Además de permitir,

basados en estos niveles de riesgo, la

adecuada planeación y creación de

proyectos que involucren actualizaciones

o renovaciones de la infraestructura.

Esta acción permite a los miembros de

la organización lograr uno de los

objetivos principales de la cultura de

riesgo, que es el asumirlo sabiendo su

alcance (7).

7. Evaluar si el

"apetito al riesgo"

está alineado con las

políticas y

estándares definidos

por la organización.

Esta evaluación hace parte fundamental

de la creación del plan de continuidad de

toda organización ya que toda nueva

iniciativa o proyecto que involucre parte

alguna de la organización debe estar

perfectamente alineado con las políticas

de ésta.

Esta acción da como resultado medir el

alcance que tiene la cultura de riesgo y

como ésta se encuentra alineada con las

políticas de la organización.

8. Se han definido

claramente

indicadores de

riesgo de TI.

Permite definir acciones preventivas y

correctivas. Además, ayuda en la

identificación y reparación de las fallas

que existen en la infraestructura de TI.

El tener esta acción desarrollada influye

en los componentes de políticas y

reglamentaciones, y de entrenamiento y

campañas de sensibilización, ya que el

tener los indicadores les aumenta el

valor a las acciones de estos

componentes.

Componente: Definición de roles, políticas y funciones para controlar riesgos de TI.

1. Se lleva un historial

de los riesgos de TI

para monitorear su

evolución y

Este historial es insumo primordial para

la construcción de los planes de

continuidad de todas y cada una de las

unidades de negocio. Mediante el análisis

El tener este historial permite mejoras

en el componente de aceptación cultural

ya que a través del mismo se puede

generar un nivel de conciencia de riesgo


asegurarse que

dichos riesgos sean

mitigados teniendo

en consideración los

puntos de vista de

los ejecutivos de

todas las áreas.

de esta bitácora histórica se podrá

conocer la evolución de los riesgos y

generar las medidas de actualización de

dichos planes de continuidad. Es también

un punto importante para la

identificación de falencias de TI y la

creación de los respectivos proyectos de

reparación de dichos errores. Es por

último, relevante mencionar que este

historial de riesgos es muy importante en

la administración de TI más precisamente

en el diseño y transición de servicio dado

que esta información permite basados en

datos reales históricos, crear, diseñar o

reestructurar componentes de la

infraestructura con el fin de mejorar o

reparar la base tecnológica basados en

prácticas estándar.

mayor al aprender de situaciones

previas.

2. Existe un monitoreo

de los riesgos de TI

para que cumpla

con las políticas y

estándares definidos

por los Consejos de

políticas e

implementación.

Al igual que en el componente anterior

en una de sus actividades, este monitoreo

hace parte fundamental de la creación del

plan de continuidad de toda organización

ya que toda nueva iniciativa o proyecto

que involucre parte alguna de la

organización debe estar perfectamente

alineado con las políticas de esta.

Además de permitir, gracias a toda la

información obtenida mediante el

monitoreo, hacer una gestión y

administración de cambios en la

infraestructura adecuada y acorde a las

necesidades de TI y del negocio.

Esto mejora la madurez del componente

de cultura organizacional al interiorizar

el seguimiento de las acciones definidas

en la cotidianidad de la organización.

3. Las personas

responsables de la

gestión de riesgos de

TI promueven una

El hacer consientes a todos los

individuos involucrados con elementos

de TI de los riesgos internos y externos

que trae consigo el uso de estas

Esto impacta positivamente casi todos

los componentes de cultura, dado que la

comunicación es fundamental en su

fortalecimiento en una organización.


comunicación

efectiva sobre el

tema.

herramientas, permite dar un uso más

adecuado a dichos recursos de TI. Esta

concientización se hace principalmente

mediante comunicación efectiva, entre

las partes directamente involucradas.

Componente: Mejores prácticas.

1. Se proveen los

recursos adecuados

para la gestión de

riesgos de TI.

Parte principal de la construcción de un

plan de BCM es la estimación de

recursos y la aprobación de estos por

parte de los directivos respectivos. Esta

actividad es el pilar de todo el

fortalecimiento de la base tecnológica en

especial de plan de BCM y

administración de TI, dado que si no hay

recursos suficientes, la gestión de riesgos

de TI estará incompleta y muy

probablemente acarreará problemas a

corto y largo plazo al interior de la

organización. Además, de no tener

recursos suficientes para llevar a cabo los

distintos proyectos de administración de

TI que están relacionados con la gestión

de riesgos, será muy difícil completar

con éxito ambos pasos. Administración

de TI y construcción de planes de

continuidad.

Este numeral influye en cultura ya que

el crecimiento cultural de la

organización depende de los espacios

que esta tenga para comunicarse, y para

que estos se den la carga laboral de los

individuos debe ser adecuada. Ya que si

no se tienen los recursos adecuados, el

tiempo del empleado ni el ambiente en

el que se desarrolla su labor no

generarán un entorno positivo.

Tabla 7 - Cuadro de relaciones interdisciplinarias

Esto demuestra que el desarrollo de la disciplina de gobierno efectivamente contribuye al

desarrollo integral de la gestión de riesgos de TI por la forma como las otras disciplinas se ven

influenciadas dando cierre al caso de estudio. A continuación se presentan las conclusiones del

desarrollo de este proyecto de grado.


VII. CAPÍTULO 5 - CONCLUSIONES Y TRABAJOS FUTUROS

A continuación se presentan las conclusiones y los trabajos futuros luego del desarrollo de esta

investigación. Las conclusiones se dividen en conclusiones sobre el caso de estudio, sobre el desarrollo

del proyecto y sobre problemática planteada. Luego se presentan los posibles trabajos a desarrollar

tomando como fuente este proyecto.

5.1 Conclusiones sobre el caso de estudio

Sobre el proceso de compensación de cheques del Banco de la República, caso de estudio utilizado

para validar los modelos que conforman la especificación de la guía, las principales conclusiones

parciales25 obtenidas sobre los resultados son:

Se encontraron modelos de control de riesgo de TI utilizados al interior del Banco y se

evidenció que estos son implementados de forma diferente en cada una de las unidades de

negocio. La reciente creación de la UROC y su plan de trabajo sumado a este proyecto piloto

con la Subgerencia de Informática, buscan utilizarse como una herramienta para la unificación

de los modelos existentes.

También se encontró que el Banco ha realizado trabajos y proyectos sobre las tres disciplinas,

pero unas se encuentran más desarrolladas que otras. Es necesario que se priorice el camino

que se quiere y utilizar este estudio para el mejoramiento de la gestión riesgo de TI. Es

importante mencionar que lo anterior se realizó a manera de piloto con el caso de la validación

completa de la guía con el proceso de compensación de cheques (32).

Se puede concluir que para el Banco, los beneficios que se obtienen de la gestión de los riesgos

de TI son numerosos y fundamentales, gracias a las nuevas iniciativas de estandarización de la

gestión de riesgos. Son puntos básicos para la incorporación de los modelos construidos en los

proyectos adelantados al interior del banco y que necesitan de unas bases teóricas sólidas que

permitan enfocar los diferentes esfuerzos en el fortalecimiento de cada una de las disciplinas.

25 Las conclusiones son parciales dado que la aplicación completa de la guía para el caso de estudio se encuentra en (32), dado el alcance de este documento.


5.2 Conclusiones sobre los modelos

La elaboración de la guía y la construcción inicial de las listas de chequeo, fue un trabajo extenso de

recolección de información relacionada con el marco teórico, apoyando en teorías que complementaron

al Marco 4-A, de ese proceso se puede concluir:

Se logró crear una relación armónica entre marcos, buenas prácticas, teorías y estudios que

permitieron cimentar unas bases sólidas para el desarrollo de cada una de las disciplinas

obteniendo unas herramientas aplicables. Siendo finalmente la tarea más importante y en la

que se basa la especificación de la guía, la creación de modelos que se enfocan en la gestión de

TI teniendo en cuenta siempre las implicaciones operativas de dicha gestión.

Los modelos construidos, son herramientas que permiten evaluar estados del riesgo de TI en

principio para el sector bancario colombiano, es posible que éstos sirvan en todo tipo de

empresas, aunque hayan sido desarrollados para un sector específico dado que los modelos dan

una vista global de las disciplinas. Sin embargo, es necesario volver a revisarlos y

complementarlos y de esta forma enriquecerlos, convirtiéndolos en herramientas de uso

primario en el control de riesgos de TI.

Los modelos desarrollados para cada una de las disciplinas son herramientas de valoración que

para el análisis del caso de estudio lograron satisfacer las necesidades. La construcción de estos

modelos, es el mayor aporte de este proyecto de grado a la “Guía de mejores prácticas en

gestión de riesgos de TI en el sector bancario colombiano”.

Fue posible detallar y especificar cada una de las tres disciplinas, gracias a la búsqueda de

teorías y modelos de gestión de riesgos de TI existentes a nivel mundial. Tomando algunos de

ellos y complementándolos con conocimientos variados específicos para cada disciplina.

5.3 Sobre el proyecto de grado


Sobre el desarrollo del proyecto es posible concluir que:

La investigación de estándares y mejores prácticas que complementaron la teoría dada por el

marco 4-A, aportaron ideas que contribuyen a la operatividad del mismo ya que lo pone en

planos prácticos y adecuados a la industria en la que se necesita aplicar.

Es importante mencionar que en el desarrollo de todo el proyecto se logró demostrar como los

riesgos de TI realmente tienen un impacto importante en el negocio y el administrarlos

mediante herramientas adecuadas tales como el uso de estándares existentes en la industria,

trae beneficios tangibles a la organización tanto interna como externamente.

Durante el desarrollo del proyecto se observó que la gestión de riesgos de TI a pesar de tener

modelos teóricos generales es recomendable que se especifique de acuerdo a la industria en la

que se vaya a aplicar dado que las consideraciones legales, políticas, sociales y económicas son

específicas y particulares a cada una de éstas.

El desarrollo de todo el proyecto es el resultado del trabajo directo e indirecto de un número

considerable de personas que dieron sus aportes para lograr un trabajo de calidad, funcional y

que cumple con los objetivos propuestos en el inicio del mismo.

La suma de esfuerzos especialmente de los miembros del grupo TION que hicieron parte de la

construcción y especificación de la guía permitieron que el producto final sea tanto al interior

del grupo como para el Banco una herramienta valiosa que se espera permita el inicio de

nuevos proyectos y complemento de proyectos ya existentes.

5.4 Trabajos futuros

Durante el desarrollo del proyecto se han identificado posibilidades para profundizar y mejorar las

propuestas, a continuación se enumeran algunas opciones en las que se puede continuar trabajando:

Evaluar los modelos en otras entidades financieras y con un mayor número de procesos o si es

posible la entidad completa para evaluar la consistencia de los mismos. Sería deseable que los

procesos seleccionados impacten objetivos de negocio propuestos en el marco 4-A.


Desarrollar proyectos para cada disciplina de forma independiente enriqueciendo los modelos

con conocimientos multidisciplinarios buscando madurar cada vez los mismos buscando un

mayor aporte para las organizaciones que los utilicen.

Valorar en el transcurso del tiempo si las teorías planteadas en este proyecto pueden ser

complementadas con nuevas ideas provenientes de nuevos trabajos realizados para su

fortalecimiento.

Por último, se presenta al lector una analogía planteada por Westerman que cierra acertadamente está

investigación y que sugiere la importancia del tema de gestión de riesgos de TI en las organizaciones:

No hay que esperar a ser golpeado por un piano cayendo para saber que son peligrosos; existen tres

tipos de organizaciones, las que les ha caído un piano encima y saben que son peligrosos, las que han

visto caer pianos sobre otras organizaciones y saben que son peligrosos, y las que aunque ven que los

pianos caen, no son consientes que un piano cayendo es peligroso (2). Se recomienda no ser parte del

tercer grupo.


VIII. ANEXOS

6. Anexos

6.1 Ciclo de Vida Programa de BCM (11) y (12):

Esta guía fue creada por el BCI para proveer una descripción y ayuda guiada de buenas prácticas

cubriendo en su totalidad la Administración de Continuidad del negocio

El ciclo de vida va desde el reconocimiento inicial de la organización de la necesidad de desarrollar

el programa de BCM, hasta el mantenimiento del programa para la madurez evolutiva del mismo.

o Entendiendo el negocio:

§ Se hace un análisis del negocio y del impacto de los riesgos en el mismo (BIA Business

Impact Analysis), así como una evaluación de las amenazas.

§ Es necesario hacer una estimación de los requerimientos de continuidad.

§ Remitirse a los Guidelines dados por el BCI(Capitulo 2):

http://www.thebci.org/gpg/GPG2008-2Section2FINAL.pdf

o Determinando la estrategia.

§ Dado el BIA que se creó en la etapa anterior, se crean las estrategias de continuidad

apropiadas que van alineadas con los objetivos del negocio.

§ Remitirse a los Guidelines dados por el BCI(Capítulo 3):


o Desarrollando e implementando las respuestas.

§ Se desarrollan de planes de acción detallados para asegurar la continuidad de las

actividades y la administración efectiva de cualquier incidente previsto.



o Probando, manteniendo y revisando.

§ Se asegura que las estrategias, planes y arreglos contractuales de BCM escogidos por la

organización son validos, probándolos, revisándolos y manteniéndolos actualizados.




o Administrando el programa.

§ Se establece y se mantiene adecuadamente el programa de acuerdo a las necesidades del

negocio.

§ Actualizaciones constantes del contenido.



6.2 Plan de continuidad del negocio (BCP) (33):

Figura 33 - Estructura del BCP (Business Continuity Plan) - BCM Institute. 26

Es a grandes rasgos similar al BCM Program, contempla todas y cada una de las medidas de

contingencia y recuperación ante cualquier evento que afecte al negocio. Todo de acuerdo al

análisis de Riesgos y de Impacto (BIA) realizado como parte esencial del proceso mostrado en

la Figura 33, y está en constate actualización, dado que además debe estar siendo probado con

una determinada regularidad, además de estar en permanente alerta ante cualquier cambio al

interior o exterior de la organización.

Objetivos de cada etapa.

o Preparación.

§ Pasos preparatorios para proveer bases fuertes sobre las que se va a construir rodo

plan de continuidad.

o Prevención.

26 Tomado de: Business Continuity. Guideline; BCM Institute.


§ Prestar mayor atención a las áreas en las que una buena planeación permitirán que

la organización evite, prevenga o limite el impacto de la ocurrencia de una o varias

crisis.

o Respuesta.

§ Desarrollo de los pasos que serán requeridos para responder efectiva y

apropiadamente, en el tiempo preciso en caso de presentarse alguna crisis.

o Recuperación y reinicio.

§ Desarrollo de políticas, procedimientos y planes que permitan solventar

satisfactoriamente crisis alguna dentro de la organización, recuperando y

restaurando procesos críticos y finalmente retornando cada operación a la

normalidad.

o Prueba y entrenamiento. Evaluar y mantener.

§ Entrenar y educar a todos los miembros de la organización para la interiorización y

validación del BCP.

Figura 34 - Estructura Programa de BCM. DRI International (34).

Auditoría y Mantenimiento.

Ejercicios de testing del BCP.

Evaluación de Riesgo y

Control

BIA

Estrategias de

Continuidad

Respuesta a Emergencias

Planes de Continuidad de Negocio

Programa de entrenamieto

y alerta

Comunicación durante crisis.

Coordinación Agentes Externos


6.3 Tabla Problemas típicos 4-A’s, base tecnológica.

La tabla 1 muestra los problemas típicos en Acceso, Disponibilidad y Precisión, encontrados

por medio de las auditorias:

Riesgos Acceso

Hecho Típico Descripción Recomendación

1. Contratos con terceros

y socios no especifican

requerimientos de

protección de datos.

(Controles internos).

Socios y terceros son fuentes de

riesgo ante la ausencia de controles.

Requerir que socios y terceros

presenten evidencia de controles

y que hagan revisiones anuales de

dichas políticas.

2. Empleados han leído y

entendido sus

responsabilidades en la

protección de datos.

Falta de conocimiento deja abiertas

las puertas a cientos de intrusos.

Formalizar un programa de

entrenamiento, con ayuda

profesional e instrucción formal.

3. Muchas cuentas

administrativas, no

especificas por

individuos.

Las cuentas no corresponden a

individuos, de esta forma

controlarlas y monitorearlas es muy

difícil.

Reducir el numero de cuentas

altamente privilegiadas y de

administrador. Crearlas por

individuo.

4. Imposible determinar

que privilegios

corresponden a que

usuarios.

No hay control de quien accede a

que información. Ni de quien

aprueba dichos privilegios de las

cuentas.

Crear automatización de

privilegios de usuarios y, algún

método formal de revisión de los

privilegios de los usuarios.

5. Imposible hacer

seguimiento de las

actividades de cada

usuario en el sistema.

Inhabilidad para monitorear quien

ha accedido a recursos específicos.

Implementar un registro central

automatizado y de análisis.

6. Imposible producir un

inventario de los

activos de información

No se sabe que información se

tiene, ni como debería ser

protegida.

Crear y administrar un proyecto

para la clasificación e inventario

de los activos.


de TI.

7. No existe control de

acceso al Data Center.

No existe control de acceso al Data

Center.

Crear políticas y normas de

acceso al Data Center. Métodos

de autenticación, candados en las

puertas, cámaras de video, claves

de acceso, etc.

Riesgos Disponibilidad


1. No existe Plan de

Continuidad Alguno, o

evidencia alguna de

existencia de controles

internos.

La planeación de Continuidad del

Negocio es deficiente o inexistente.

Escribir un plan formal de

Continuidad del Negocio, basado

en algunas de las buenas

prácticas existentes. Probar el

plan

Riesgos Precisión


1. No existe evidencia de

cambio de

administración en

material del sistema

No hay control de los cambios, por

lo tanto es imposible encontrar que

modificaciones han introducido

errores de precisión al sistema.

Implementar algún tipo de

procesos para la administración

de cambios y de mejores

prácticas en el tema.

2. No existen métodos

para controlar la

separación de tareas

relacionadas a reportes

financieros.

Alguien podría modificar

información financiera vital, a

través del uso de permisos

conflictivos de acceso.

Automatizar procesos de

detección y recuperación, así

como el flujo de trabajo de

cualquier proceso de

aprovisionamiento que permitan

evitar ediciones no autorizadas de

cualquier ERP (Enterprise

Resource Plannning)

Tabla 8 - Fuentes de Riesgo Comunes.


6.4 Lista de chequeo disciplina de base tecnológica

Lista de Chequeo(definida de acuerdo a los 3 pasos fundamentales)

1. Continuidad del negocio (Basado en el programa de BCM del BCI ).

Actividad Llevado a

cabo(si/no)

Valoración

Entendiendo la organización

Se crea el BIA, documento de análisis de

impacto del negocio.

Se definen los MTPD de cada proceso.

(Maximun Time Process of Disruption)

Se define el RPO (Recovery Point

Objective) de cada uno de los procesos.

Se crea el CRA (Continuity Requirements

Analysis).

Se crea un estimado de los recursos

mínimos necesarios para la reanudación y

la continuidad de cada actividad.

Se identifican interdependencias entre

actividades.

Se realiza la evaluación de amenazas

(valoración de riesgos).

Se identifican los puntos únicos de falla.

Se crea la lista de priorización de amenazas

de la organización.

Se crean estrategias para la administración

del control de riesgos.

Se establecen los planes de acción a llevar

a cabo por cada riesgo a tratar.

Se crea documentación de los riesgos

identificados que no serán tratados.


Se define el RTO de cada proceso.

Se define la relación RTO – MTPD por

proceso. (Ej: RTO menor que MTPD)

Se analizan nuevamente las estrategias


existentes para acortar las brechas que

puedan haber de acuerdo al RTO y MTPD.

Se identifican posibles tácticas que

permitan cumplir los RTO específicos.

Identificar los criterios con los que se

seleccionará la táctica adecuada (Ej: costos,

beneficios adicionales, etc.)

Se seleccionan las tácticas más apropiadas

de acuerdo a los criterios escogidos.

Se crea un plan para la puesta en práctica

de las medidas seleccionadas.

Se crea un proceso interno que permita

hacer seguimiento de las actividades de

cada táctica de BCM escogida.

De esta forma se generará la documentación adecuada y se formalizará de acuerdo a los puntos

anteriores, para cada uno de los procesos. Además se creara todo el plan de implementación de las

estrategias.

Se consolidan los recursos requeridos a

incluir dentro del plan, de acuerdo a las

tácticas seleccionadas.

Se evalúa la relación costo-beneficio para

cada opción de tal forma que se cumplan

los RTO y RPO estipulados por proceso.

Es necesario informar a la parte Gerencial de la organización mediante una evaluación estratégica

de todas las consideraciones y decisiones tomadas hasta el momento. Principalmente las

relacionadas con las tácticas y los recursos a emplear para la consecución de las mismas.

Se crea el proyecto de implementación del

programa y de los planes de acción.

Se aplica la estrategia acordada para la

implementación del proyecto.

Se implementa un proceso de seguimiento

de la planeación de recursos.

De esta forma los recursos y servicios para la recuperación serán administrados por medio del BCP

(Business Continuity Plan). Todo de acuerdo a los RTO y RPO ya definidos.


Existe una estructura de respuesta a


incidentes. (Gold, Silver, Bronze)

Existe un plan de administración de

incidentes (Nivel Gerencial - Estratégico)

El plan de administración de incidentes o IMP (Incident Management Plan), debe incluir:

Roles y responsabilidades de cada uno de los individuos.

Instrucciones de movilización.

Planes de Acción.

Locaciones físicas de reunión.

Lista de recursos necesarios y disponibles para cada plan.

Actividades de cada individuo.

Servicios de comunicación disponibles durante la emergencia.

Plan de comunicación durante incidentes.

Existe un plan de continuidad del negocio.

(Nivel Táctico)

El plan de continuidad del negocio debe contener:

Lista de tareas y de planes de acción para la continuidad.

Lista de recursos necesarios y disponibles.

Documentos y anexos tales como listas de chequeo, etc.

Documentos de respaldo de la información vital para el reinicio de cada actividad (ej.

Información de clientes, documentos legales, detalles de contacto)

Plan de reinicio de las actividades (Nivel

Operacional)

Cada unidad de negocio debe tener un plan operacional de respuesta a incidentes. Además de tener

definidos los roles específicos de administración de continuidad del negocio al interior de la unidad

o departamento.


Existe un calendario de pruebas del

programa de BCM.

Existe evidencia de realización de pruebas

y de arreglos a los planes de continuidad

debido a la retroalimentación de cada una

de las pruebas.

Existe evidencia de arreglos a los planes de

continuidad debido a cambios al interior de

la organización, que así lo exijan.


Administrando el programa de BCM

Existe un documento que especifique las

políticas de administración de la


Este documento debe determinar el alcance y los términos bajo los que se realiza el análisis de

impacto del negocio. Además de:

Definición de BCM para la organización.

Definición del alcance del programa de BCM.

Marco operacional de BCM.

Documentación de los principios de BCM. (Guía y estándares mínimos).

Plan de implementación y de mantenimiento para las políticas.

Especificación de las responsabilidades asignadas a cada individuo involucrado en el

programa de BCM.

Especificación documentada de las relaciones contractuales con terceros que aseguren la

continuidad adecuada de los servicios concertados (SLA, contratos, etc).

Se realizan actividades propias de la

implementación del programa de BCM.

(Ejercicios con la alta gerencia,

presentaciones del programa a los

empleados de la organización, reuniones

que permitan definir adecuadamente las

políticas que rigen al programa)

Se realizan actividades relacionadas con el

proyecto de administración del programa

de BCM. (proyectos internos que permitan

realizar la implementación del programa en

su primera iteración principalmente)

Tabla 9 – Continuidad de Negocio


Actividad Llevado a

cabo(si/no)

Valoración

Identificar todos y cada uno de los activos

que hacen parte de la infraestructura de TI.

Identificar todas las fallas de la

infraestructura de acuerdo a datos


históricos.

Identificar interrelaciones entre los activos


Levantamiento de información de

organizaciones similares, en especial de

casos de falla excepcionales de la

infraestructura. (Benchmarking fallas de la

infraestructura tecnológica)

Creación de un grupo auditor de los

procesos de TI.

Creación de planes de reparación de cada

falla encontrada en la infraestructura.

Tabla 10 – Falencias y reparación de Infraestructura de TI.


industria (Basado en el conjunto de buenas prácticas ITIL v.3).

Estrategia de servicio

Se realizan todas las actividades

correspondientes a identificar y reparar las

fallas de la infraestructura de TI. (Paso 2 de

la reparación de la base tecnológica)

Se tiene definido un portafolio de los

servicios entregados por TI.

Se caracterizan los servicios de acuerdo a

si son de tipo interno o externo.

Se hallan las relaciones entre los distintos

servicios entregados por TI a sus clientes

respectivos.

Se priorizan los servicios (Demanda,

relevancia, etc).

Se categorizan los servicios.

Se realiza el BIA (el mismo documento

generado en la gestión de continuidad del

negocio – Paso 1).

Se conoce exactamente a quien se presta

cada uno de los servicios.


Se desarrollan métodos de

retroalimentación de los servicios con

respecto a los clientes internos y externos.

(Evaluación de la satisfacción) (Utilidad y

Calidad de cada servicio).

Se lleva a cabo análisis financiero de

acuerdo a las consideraciones de los puntos

anteriores de la tabla (Servicios críticos,

relaciones entre servicios, BIA, clientes de

TI).

Se priorizan los recursos de TI de acuerdo

al análisis hecho.

Diseño de servicio

Se definen los servicios de acuerdo a los

análisis realizados en la etapa de estrategia

de servicios.

Se crea el portafolio de servicios con

información precisa y estándar para toda la

organización (vocabulario, proveedores,

clientes, etc).

Se crean SLA’s (Service level agreement)

con cada uno de los clientes, para cada

servicio entregado por TI.

Se determinan y se documentan los

requerimientos propios de cada servicio

entregado por TI.


requerimientos legales de cada servicio.

Se crean métodos de supervisión y

monitoreo de los servicios de acuerdo a los

SLA’s concertados.

Se analizan posibles fallas en los servicios.

Se crea todo un plan de continuidad del

negocio. (Paso 1 de la reparación de la

base tecnológica)


La creación del plan de continuidad busca garantizar la disponibilidad de los recursos y servicios

prestados y entregados por TI.

Se analizan y se documentan los estados

óptimos de capacidad y de desempeño de

los servicios y recursos entregados por TI.

Se comparan los estados óptimos con los

actuales y se planean los estados futuros,

mediante las actualizaciones respectivas a

la infraestructura o la modificación de la

misma.

Se realizan estudios, mediante proyectos,

de nuevas tendencias tecnológicas que

permitan mejorar los servicios de TI.

Se documentan los estados futuros de

rendimiento y capacidad de la

infraestructura de TI.

Se documentan los estudios y análisis

realizados de nuevas tecnologías y de

actualizaciones de la infraestructura

existente.

Dicha documentación será la base de proyectos de actualización y mejora de la infraestructura de

TI.

Se documentan las políticas de seguridad

de la información que existen en la

organización.

Se definen, priorizan y categorizan todos y

cada uno de los activos de información que

son manipulados mediante las servicios y

recursos entregados por TI.

Se analiza el manejo de los activos de

información y se estudian las posibles

fallas encontradas en el proceso de

manipulación de dicha información (Existe

documentación del análisis).

Se tiene un documento que especifica y

describe cada uno de los incidentes


relacionados con seguridad ocurridos en la

organización. (Histórico de incidentes).

Se implementan los controles de seguridad

respectivos. (Existe documentación de cada

uno de los métodos de control

implementados).

Se documentan los procedimientos

estipulados para garantizar la seguridad de

la información dada su manipulación

mediante los servicios entregados por TI.

Se realizan y se documentan las pruebas de

seguridad (software y hardware) que deben

llevarse a cabo periódicamente.

Se hacen cambios periódicamente en las

políticas y procedimientos de seguridad

dados los datos obtenidos mediante las

pruebas.

Se analizan y evalúan periódicamente los

contratos existentes con terceros y

proveedores de bienes y servicios de TI.

(Implicaciones legales, SLA, etc.)

Se documentan todos y cada uno de los

acuerdos firmados con cada uno de los

terceros y proveedores.

Se tiene la información específica de

posibles nuevos proveedores de bienes y

servicios existentes en el mercado.

(Documentación explicita).

Se analizan y evalúan los contratos

existentes con terceros y proveedores de

bienes y servicios de TI, al término de los

mismos. (Implicaciones legales, SLA, etc.)

Estos análisis y evaluaciones constantes permiten asegurar que los servicios entregados por los

proveedores están administrados de tal forma que sean en todo momento un apoyo para la

consecución de los objetivos de TI.

Transición de servicio



servicios de la organización en los que

interviene TI. (Utilidad (resultado),

garantías estipuladas (disponibilidad,

precisión)). Servicios internos y externos.

La administración de cambios es el proceso que asegura que cada uno de los cambios al interior de

TI será llevado a cabo de acuerdo a un método estándar adecuado, de tal forma que garantizan una

optimización de los riesgos encontrados.

Se tiene el inventario de activos de TI que

interviene en cada uno de los servicios

internos y externos de la organización y

como se relacionan entre sí.

Cada cambio en la infraestructura

propuesto, cuenta con la documentación

suficiente para su aprobación y ejecución.

(ver Anexo 6.8 para la documentación

completa según ITIL v.3)

Existe un plan detallado de cómo será

realizado cada cambio en la infraestructura.

(Implementación, pruebas).

Se realizan actividades de prueba de todos

y cada uno de los procesos en los que se

realizaron cambios.

Se crean reportes que resumen los

resultados de las actividades de prueba de

cada uno de los cambios realizados.

(exitosas, no exitosas)

Administración de activos y configuraciones.

(En caso de tener una infraestructura

grande y compleja). Se tiene un Sistema de

Administración de Configuraciones.

El sistema de Administración de

configuraciones cuenta con una estructura

definida para la configuración de cada ítem

de la infraestructura. (ver Anexo 6.9 para la

lista de chequeo de la documentación



Existe documentación que describe cómo

es manejada y modificada la Información

por medio los activos de TI y sus servicios.

(Que información, que tipo de información,

como se transporta de un componente a

otro, quien es responsable de cada

segmento de la información.)

Operación del servicio

Se realiza administración de eventos.

Existen métodos adecuados (probados

exitosamente) de comunicación de eventos

internos. (e-mail, sms, llamada).

Existe documentación acerca de quién y

como se debe solucionar los eventos

conocidos. (Información histórica de

eventos).

Evento: cambio de estado significante para la administración de la configuración de algún

componente o servicio de TI. (Ej. Impresora sin tinta).

Se realiza administración de incidentes.

Se tiene una herramienta de administración

de incidentes que permita tener

conocimiento histórico de cada uno de los

incidentes. (ver anexo 6.10 para la

documentación completa de reportes de

incidentes.)


exitosamente) de comunicación y

retroalimentación de incidentes tanto

internos como externos. (email, sms,

llamada, service desk).

Existen métodos de priorización de

incidentes (urgencia, impacto en el

negocio).

Hay documentación clara de quienes y que

deben hacer de acuerdo al incidente que se


presente. (Definición de roles y

responsabilidades).

Incidente: Interrupción no planeada de un servicio de TI, o reducción en la calidad de un servicio

de TI. Falla de algún componente de la infraestructura de TI.

Se realiza administración de acceso.

Existe documentación que especifica quien

debe acceder a la información por medio

de los servicios entregados por TI y de que

forma debe hacerlo en circunstancias

normales y extraordinarias.


se debe acceder y manipular la Información

por medio de los servicios entregados por

TI.

Se realiza administración de problemas.

Existe documentación histórica de

resolución de problemas e información de

problemas considerados y sus posibles

soluciones. (ver anexo 6.11 para la

documentación completa de reporte de

problemas.)

Existen métodos de categorización y

tipificación de problemas.

Existen grupos de análisis de problemas de

acuerdo a su categoría y tipo.

Se documenta adecuadamente las

soluciones encontradas por los grupos de

análisis.

Problema: es la causa de uno o más incidentes. La causa del mismo no siempre se conoce en el

momento de la detección sino después de un análisis detallado de la situación.

Existen canales de comunicación

retroalimentación directos con los clientes.

Se tienen registros categorizados de las

interacciones con los clientes (reclamos,

consideraciones del servicio, etc.)

Tabla 11 – Gestión y monitoreo de TI


6.5 Lista de chequeo disciplina de gobierno de riesgos de TI.

Lista de chequeo de actividades gobierno de riesgo de TI

1 Definición de roles y funciones para controlar riesgos de TI

1.1 Existe un Oficial de riesgos responsable directo del control de los riesgos de TI.

1.2 Hay un Consejo de políticas de riesgo compuesto por ejecutivos del negocio y de tecnología, que define la política para el control de riesgos de TI y le asigna prioridades a los riesgos específicos.

1.3 Hay un Consejo de implementación encargado de llevar a cabo las políticas definidas por el Consejo de políticas de riesgo, a través de la definición de estándares y procedimientos

1.4 Está definido un rol en cada área de negocio que vele porque se cumpla la política para el control de riesgos de TI definida por la organización.

1.5 Hay un equipo para el manejo de riesgos de TI que asiste a los responsables de los procesos de negocio en la identificación y control de riesgos de TI.

1.6 Existe un monitoreo de los riesgos de TI para que cumpla con las políticas y estándares definidos por los Consejos de políticas e implementación.

1.7 La alta gerencia promueve la cultura de conciencia del riesgo de TI.

1.8 Las personas responsables de la gestión de riesgos de TI promueve una comunicación efectiva sobre el tema.

2 Proceso para el control de riesgos de TI

2.1 La política de riesgos de TI es actualizada regularmente

2.2 Evalué cuales procesos de negocio son fuertemente soportados por TI.

2.3 Existe un inventario de procesos de negocio con sus recursos de TI necesarios.

2.4 El proceso de identificación de riesgos de TI es descentralizado y recae sobre los jefes de cada área de negocio.

2.5 Existe un modelo para el proceso de recolección de datos relacionados con riesgos de TI.

2.6 Se ha creado una definición formal de categorías de riesgo de TI.

2.7 Se han definido categorías de riesgos de TI por orden de importancia

2.8 Se ha definido el nivel de riesgo que la organización está dispuesta a tomar "apetito al riesgo"

2.9 Evaluar si el "apetito al riesgo" está alineado con las políticas y estándares definidos por la organización.


2.10 Una vez identificados clasificados y priorizado los riesgos de TI, se decide cuales reducir/evitar/transferir/aceptar

2.11 Se ha definido como debe reaccionar la organización a todos sus niveles ante la materialización de un riesgo

2.12 Se han definido claramente indicadores de riesgo de TI

2.13 Se lleva un historial de los riesgos de TI para monitorear su evolución y asegurarse que dichos riesgos sean mitigados teniendo en consideración los puntos de vista de los ejecutivos de todas las áreas.

2.14 Existen planes de respuesta ante la presencia de incidentes de TI.

2.15 Existe un procedimiento de revisión "post-mortem" sobre los incidentes relacionados con TI.

3 Mejores Prácticas

3.1 El método para evaluar los riesgos de TI es consistente con el método para evaluar todo tipo de riesgos, es decir se encuentra integrado con el ERM (Enterprise Risk Management)

3.2 Las prácticas de gestión de riesgo de TI se adaptan a las prácticas de gestión de riesgo organizacional.

3.3 Se proveen los recursos adecuados para la gestión de riesgos de TI.

3.4 Se usan mejores prácticas del sector o industria.

3.5 Se usan estándares nacionales o internacionales.

Tabla 12 - Lista de chequeo de actividades gobierno de riesgo de TI

6.6 Cuadros de comportamiento de cultura

Preguntas Marcar X si se cumple ¿La cabeza de la organización dirección o departamento conoce las políticas y reglamentaciones de riesgo de TI?

¿La cabeza de la organización dirección o departamento divulga las políticas y reglamentaciones de riesgo de TI?

¿Hace que sus subalternos se preocupen por la aplicación de estas políticas y reglamentaciones de riesgo de TI?

¿Consulta a sus subalternos sobre su opinión respecto al riesgo de TI? Tabla 13 - Lista chequeo cultura organizacional

Preguntas Marcar X si se cumple ¿Se presentan comportamientos espontáneos para controlar el riesgo? ¿Han surgido desde los comportamientos de la organización, normas de control de riesgo?

¿Se tienen identificados los líderes sociales en la organización? ¿Conocen las políticas y reglamentaciones de riesgo de TI? ¿Divulgan entre sus compañeros este conocimiento?

Tabla 14 - Lista chequeo cultura social

Preguntas Marcar X si se cumple ¿Existe una normatividad general para todos los miembros de la organización?


¿Se ha definido en la normatividad que es público y que es privado en contexto general?

¿Existe normatividad especializada para cada tipo de miembro en la organización?

¿La normatividad especializada tiene definido que es público y que es privado?

Tabla 15 - lista chequeo políticas y reglamentación

Preguntas Marcar X si se cumple ¿Se tiene definido un modelo de entrenamiento para la normatividad de la empresa?

¿El modelo de entrenamiento es dinámico? ¿Se desarrollan campañas de concientización? ¿Las campañas diferencian entre público general y publico específico?

Tabla 16 - Lista chequeo entrenamiento y divulgación

Pregunta Marcar X si se cumple ¿Los miembros de la organización participan activamente de los procesos educativos?

¿Los miembros de la organización le dan importancia las campañas? ¿Los miembros de la organización aplican lo divulgado en las campañas?

¿De la organización surgen sugerencias para el mejoramiento de la normatividad?

¿Se ve el uso de la normatividad en el día a día? Tabla 17 - Lista chequeo aceptación


6.7 Organigrama Banco de la República

1.


6.8 Datos de las Peticiones de Cambios (RFC – Request for Change) (35)

Cada petición de cambio de contar con los siguientes puntos y documentos de respaldo, de tal

forma que la administración de cambios sea consistente, efectiva y eficiente. De esta forma cada

RFC debe contar con:

1. D único.

2. Fecha de petición.

3. Dueño de la petición de cambio.

4. Quien realiza la petición (en caso de que sea distinto al dueño).

5. Prioridad del cambio (ej. Urgente, Alto, Normal, Bajo, etc.)

6. Descripción del cambio a realizar.

1. Descripción del cambio (Resumen).

2. Descripción desde el negocio:

1. Razones para implementar el cambio.

2. Costos.

3. Beneficios

4. Consecuencias de no realizar la implementación.

5. Referencias (Problemas documentados que hayan motivado este RFC)

3. Áreas de negocio afectadas por el cambio.

4. Servicios afectados por el cambio.

5. Componentes de la infraestructura de TI afectados por el cambio.

6. Consideraciones tecnológicas del cambio.

7. Riesgos posibles durante la implementación del cambio.

1. Riesgos identificados.

2. Medidas a tomar para evitarlos.

3. Estrategias de reinicio y soporte en caso de fallas del cambio.

8. Tiempo sugerido para la implementación del cambio.

9. Estimación de recursos para la implementación.

1. Personal requerido.

2. Cargas de trabajo estimadas para el personal requerido.

3. Costo total.

10. Estimación final del presupuesto necesario para la implementación del cambio.

11. Anexos, Documentos adicionales.


12. Aprobación o rechazo.

1. Fecha.

2. Persona encargada de la aprobación.

3. Revisores del cambio.

4. Prioridad asignada por el Administrador de cambios.

5. Restricciones.

6. Dado el caso, razones del rechazo de la petición.

6.9 Datos información contenida en el sistema de administración de configuraciones (RFC – Request for Change) (35)

En este se guarda la información de todos y cada uno de los elementos propios de la infraestructura

de TI, bajo el control de la administración de configuraciones. (Esta lista de chequeo puede variar

de acuerdo a consideraciones particulares de cada organización)

1. Identificador único

2. Nombre.

3. Descripción.

4. Persona a cargo del componente o ítem.

5. Clasificación.

1. Categoría (ej. Servicio, Hardware, Software, Documento, etc.)

2. Tipo (ej. Servidor, Impresora, Base de Datos, etc.)

6. Información manufactura.

1. Nombre compañía manufacturera

2. Numero serial.

3. Numero de licencia (contrato)

7. Versión.

8. Historial de modificaciones en la configuración.

1. Fecha de creación.

2. Modificaciones.

3. Descripción de cada modificación.

4. Fechas.

5. Persona encargada.

9. Ubicación.


1. Ubicación física. (si aplica)

2. Ubicación lógica. (si aplica)

10. Historial del estado. (en pruebas, active, inactive, etc.)

1. Estado actual. Versión actual.

2. Historial versiones y cambios de estado.

1. Fecha.

2. Cambios de estado.

3. Descripción.

11. Relación con los servicios de TI.

12. Relación con otros componentes de la infraestructura.

1. Es componente de.

2. Está asociado con.

3. Usos.

4. Es una característica de.

5. Es una nueva versión de.

6. Será en un futuro remplazado por.

13. Relaciones con otros objetos de datos de acuerdo a la administración de servicios.

1. Record de incidentes.

2. Record de problemas.

3. Errores conocidos.

4. Record de cambios.

14. Detalles de la licencia.

15. Documentos referencia.

1. Documentación contractual.

2. Documentación de la operación.

3. Documentación de los usuarios.

4. Documentación relevante durante emergencias.

5. Documentación adicional.

6.10 Datos de un registro de incidentes (35)

1. Identificador Único.

2. Fecha y hora del reporte del incidente.


3. Responsable del reporte del incidente.

4. Método de notificación

5. Datos de quien reporto el incidente (usuario, cliente, etc.)

6. Método de callback.

7. Descripción del incidente (síntomas).

8. Usuarios o áreas de negocio afectadas.

9. Servicios involucrados.

10. Priorización.

1. Urgencia (tiempo disponible para dar solución).

1. Hasta 30 mins.

2. Hasta 2 horas.

3. Hasta 6 horas.

2. Grado de severidad (daño causado al negocio)

1. Alto.

2. Normal.

3. Bajo.

3. Prioridad. (1,2,3)

11. Relación con componentes de la infraestructura.

12. Categoría del producto. ()

1. PC del cliente

1. Configuración.

2. …

2. Impresora

1. Manufactura.

2. …

13. Categoría del incidente

1. Error de hardware.

2. Error de software.

3. ...

14. Vínculos con otros incidentes registrados.

15. Vínculos con problemas ya registrados.

16. Bitácora de actividad.

1. Fecha y hora.


2. Persona encargada.

3. Descripción de actividades

17. Descripción resolución problema y datos de cierre.

1. Fecha y hora de resolución.

2. Fecha y hora de cierre.

3. Categorías de cierre (de ser necesario)

6.11 Datos de un registro de problemas (35)

1. Identificador Único.

2. Fecha y hora de la detección.

3. Responsable del problema.

4. Descripción del incidente (síntomas).

5. Usuarios o áreas de negocio afectadas.

6. Servicios involucrados.

7. Priorización.

1. Urgencia (tiempo disponible para dar solución).

1. Hasta 5 días hábiles.

2. Hasta 2 semanas.

3. Hasta 4 semanas.

2. Grado de severidad (daño causado al negocio)

1. Alto.

2. Normal.

3. Bajo.

3. Prioridad. (1,2,3)

8. Relación con componentes de la infraestructura.

9. Categoría de los productos afectados.

1. PC del cliente

1. Configuración.

2. …

2. Impresora

1. Manufactura.

2. …


10. Categoría del problema.

1. Error de hardware.

2. Error de software.

3. ...

11. Vínculos con otros problemas registrados.

12. Vínculos con incidentes registrados.

13. Bitácora de actividad y estado del problema.

14. Descripción resolución del problema y datos de cierre.

2. Fecha y hora de resolución.

3. Fecha y hora de cierre.

Categorías de cierre (de ser necesario)

6.12 Lista de Chequeo correspondiente a la validación del proceso realizada con la

Unidad de Protección y Continuidad Informática

1. Continuidad del negocio (Basado en el programa de BCM del BCI).

Actividad Llevado a

cabo(si/no)

Valoración

Entendiendo la organización

Se crea el BIA, documento de análisis de

impacto del negocio.

SI

Se definen los MTPD de cada proceso.

(Maximun Time Process of Disruption)

SI

Se define el RPO (Recovery Point

Objective) de cada uno de los procesos.

SI

Se crea el CRA (Continuity Requirements

Analysis).

SI

Se crea un estimado de los recursos

mínimos necesarios para la reanudación y

la continuidad de cada actividad.

SI

Se identifican interdependencias entre

actividades.

EN

PROCESO

Se realiza la evaluación de amenazas

(valoración de riesgos).

SI


Se identifican los puntos únicos de falla. SI

Se crea la lista de priorización de amenazas

de la organización.

EN

PROCESO

Se crean estrategias para la administración

del control de riesgos.

SI

Se establecen los planes de acción a llevar

a cabo por cada riesgo a tratar.

SI

Se crea documentación de los riesgos

identificados que no serán tratados.

SI


Se define el RTO de cada proceso. SI

Se define la relación RTO – MTPD por

proceso. (Ej: RTO menor que MTPD)

SI

Se analizan nuevamente las estrategias

existentes para acortar las brechas que

puedan haber de acuerdo al RTO y MTPD.

SI

Se identifican posibles tácticas que

permitan cumplir los RTO específicos.

SI

Identificar los criterios con los que se

seleccionará la táctica adecuada (Ej: costos,

beneficios adicionales, etc.)

SI

Se seleccionan las tácticas más apropiadas

de acuerdo a los criterios escogidos.

SI

Se crea un plan para la puesta en práctica

de las medidas seleccionadas.

SI

Se crea un proceso interno que permita

hacer seguimiento de las actividades de

cada táctica de BCM escogida.

SI

De esta forma se generará la documentación adecuada y se formalizará de acuerdo a los puntos

anteriores, para cada uno de los procesos. Además se creara todo el plan de implementación de las

estrategias.

Se consolidan los recursos requeridos a

incluir dentro del plan, de acuerdo a las

tácticas seleccionadas.

SI

Se evalúa la relación costo-beneficio para

cada opción de tal forma que se cumplan

SI


los RTO y RPO estipulados por proceso.

Es necesario informar a la parte Gerencial de la organización mediante una evaluación estratégica

de todas las consideraciones y decisiones tomadas hasta el momento. Principalmente las

relacionadas con las tácticas y los recursos a emplear para la consecución de las mismas.

Se crea el proyecto de implementación del

programa de BCM y de los planes de

acción.

Se implementa un proceso de seguimiento

de la planeación de recursos.

De esta forma los recursos y servicios para la recuperación serán administrados por medio del BCP

(Business Continuity Plan). Todo de acuerdo a los RTO y RPO ya definidos.


Existe una estructura de respuesta a

incidentes. (Gold, Silver, Bronze)

SI Las categorías son IMPORTANTE,

URGENTE, CRÍTICO

Existe un plan de administración de

incidentes (Nivel Gerencial - Estratégico)

SI

El plan de administración de incidentes o IMP (Incident Management Plan), debe incluir:

Roles y responsabilidades de cada uno de los individuos.

Instrucciones de movilización.

Planes de Acción.

Locaciones físicas de reunión.

Lista de recursos necesarios y disponibles para cada plan.

Actividades de cada individuo.

Servicios de comunicación disponibles durante la emergencia.

Plan de comunicación durante incidentes.

Existe un plan de continuidad del negocio.

(Nivel Tactico)

SI

El plan de continuidad del negocio debe contener:

Lista de tareas y de planes de acción para la continuidad.

Lista de recursos necesarios y disponibles.

Documentos y anexos tales como listas de chequeo, etc.

Documentos de respaldo de la información vital para el reinicio de cada actividad (ej.

Información de clientes, documentos legales, detalles de contacto)

Plan de reinicio de las actividades (Nivel

Operacional)

SI


Cada unidad de negocio debe tener un plan operacional de respuesta a incidentes. Además de tener

definidos los roles específicos de administración de continuidad del negocio al interior de la unidad

o departamento.


Existe un calendario de pruebas del

programa de BCM.

SI

Existe evidencia de realización de pruebas

y de arreglos a los planes de continuidad

debido a la retroalimentación de cada una

de las pruebas.

SI

Existe evidencia de arreglos a los planes de

continuidad debido a cambios al interior de

la organización, que así lo exijan.

SI

Administrando el programa de BCM

Existe un documento que especifique las

políticas de administración de la


SI

Este documento debe determinar el alcance y los términos bajo los que se realiza el análisis de

impacto del negocio. Además de:

Definición de BCM para la organización.

Definición del alcance del programa de BCM.

Marco operacional de BCM.

Documentación de los principios de BCM. (Guía y estándares mínimos).

Plan de implementación y de mantenimiento para las políticas.

Especificación de las responsabilidades asignadas a cada individuo involucrado en el

programa de BCM.

Especificación documentada de las relaciones contractuales con terceros que aseguren la

continuidad adecuada de los servicios concertados (SLA, contratos, etc).

Se realizan actividades propias de la

implementación del programa de BCM.

(Ejercicios con la alta gerencia,

presentaciones del programa a los

empleados de la organización, reuniones

que permitan definir adecuadamente las

políticas que rigen al programa)

SI

Se realizan actividades relacionadas con el SI


proyecto de administración del programa

de BCM. (proyectos internos que permitan

realizar la implementación del programa en

su primera iteración principalmente)

Tabla 18 – Continuidad del negocio.


Actividad Llevado a

cabo(si/no)

Valoración

Identificar todos y cada uno de los activos

que hacen parte de la infraestructura de TI.

SI

Identificar todas las fallas de la

infraestructura de acuerdo a datos

históricos.

SI

Identificar interrelaciones entre los activos


SI

Levantamiento de información de

organizaciones similares, en especial de

casos de falla excepcionales de la

infraestructura. (Benchmarking fallas de la

infraestructura tecnológica)

SI

Creación de un grupo auditor de los

procesos de TI.

SI DPTO. DE AUDITORÍA

(INDEPENDIENTE DE

INFORMÁTICA)

Creación de planes de reparación de cada

falla encontrada en la infraestructura.

SI BASE DE DATOS DE

CONOCIMIENTO

Tabla 19 – Identificación y reparación de Infraestructura.


industria (Basado en el conjunto de buenas prácticas ITIL v.3).

Estrategia de servicio

Se realizan todas las actividades

correspondientes a identificar y reparar las

fallas de la infraestructura de TI. (Paso 2 de

la reparación de la base tecnológica)

SI

Se tiene definido un portafolio de los

servicios entregados por TI.

SI


Se caracterizan los servicios de acuerdo a

si son de tipo interno o externo.

SI

Se hallan las relaciones entre los distintos

servicios entregados por TI a sus clientes

respectivos.

SI

Se priorizan los servicios (Demanda,

relevancia, etc).

SI

Se categorizan los servicios. SI

Se realiza el BIA (el mismo documento

generado en la gestión de continuidad del

negocio – Paso 1).

SI

Se conoce exactamente a quien se presta

cada uno de los servicios.

SI

Se desarrollan métodos de

retroalimentación de los servicios con

respecto a los clientes internos y externos.

(Evaluación de la satisfacción) (Utilidad y

Calidad de cada servicio).

SI

Se lleva a cabo análisis financiero de

acuerdo a las consideraciones de los puntos

anteriores de la tabla (Servicios críticos,

relaciones entre servicios, BIA, clientes de

TI).

SI

Se priorizan los recursos de TI de acuerdo

al análisis hecho.

SI

Diseño de servicio

Se definen los servicios de acuerdo a los

análisis realizados en la etapa de estrategia

de servicios.

SI

Se crea el portafolio de servicios con

información precisa y estándar para toda la

organización (vocabulario, proveedores,

clientes, etc).

SI

Se crean SLA’s (Service level agreement)

con cada uno de los clientes, para cada

servicio entregado por TI.

SI EN PROCESO DE

ACTUALIZACIÓN



requerimientos propios de cada servicio

entregado por TI.

SI


requerimientos legales de cada servicio.

EN

PROCESO

Se crean métodos de supervisión y

monitoreo de los servicios de acuerdo a los

SLA’s concertados.

EN

PROCESO

Se analizan posibles fallas en los servicios. SI

Se crea todo un plan de continuidad del

negocio. (Paso 1 de la reparación de la

base tecnológica)

SI

La creación del plan de continuidad busca garantizar la disponibilidad de los recursos y servicios

prestados y entregados por TI.

Se analizan y se documentan los estados

óptimos de capacidad y de desempeño de

los servicios y recursos entregados por TI.

EN

PROCESO

Se comparan los estados óptimos con los

actuales y se planean los estados futuros,

mediante las actualizaciones respectivas a

la infraestructura o la modificación de la

misma.

EN

PROCESO

Se realizan estudios, mediante proyectos,

de nuevas tendencias tecnológicas que

permitan mejorar los servicios de TI.

SI

Se documentan los estados futuros de

rendimiento y capacidad de la

infraestructura de TI.

EN

PROCESO

Se documentan los estudios y análisis

realizados de nuevas tecnologías y de

actualizaciones de la infraestructura

existente.

SI DOCUMENTO DE VISIÓN

TECNOLÓGICA

Dicha documentación será la base de proyectos de actualización y mejora de la infraestructura de

TI.

Se documentan las políticas de seguridad

de la información que existen en la

SI


organización.

Se definen, priorizan y categorizan todos y

cada uno de los activos de información que

son manipulados mediante las servicios y

recursos entregados por TI.

SI

Se analiza el manejo de los activos de

información y se estudian las posibles

fallas encontradas en el proceso de

manipulación de dicha información (Existe

documentación del análisis).

SI

Se tiene un documento que especifica y

describe cada uno de los incidentes

relacionados con seguridad ocurridos en la

organización. (Histórico de incidentes).

SI

Se implementan los controles de seguridad

respectivos. (Existe documentación de cada

uno de los métodos de control

implementados).

SI

Se documentan los procedimientos

estipulados para garantizar la seguridad de

la información dada su manipulación

mediante los servicios entregados por TI.

SI

Se realizan y se documentan las pruebas de

seguridad (software y hardware) que deben

llevarse a cabo periódicamente.

SI

Se hacen cambios periódicamente en las

políticas y procedimientos de seguridad

dados los datos obtenidos mediante las

pruebas.

SI

Se analizan y evalúan periódicamente los

contratos existentes con terceros y

proveedores de bienes y servicios de TI.

(Implicaciones legales, SLA, etc.)

SI


acuerdos firmados con cada uno de los

terceros y proveedores.

SI


Se tiene la información específica de

posibles nuevos proveedores de bienes y

servicios existentes en el mercado.

(Documentación explicita).

SI

Se analizan y evalúan los contratos

existentes con terceros y proveedores de

bienes y servicios de TI, al término de los

mismos. (Implicaciones legales, SLA, etc.)

SI

Estos análisis y evaluaciones constantes permiten asegurar que los servicios entregados por los

proveedores están administrados de tal forma que sean en todo momento un apoyo para la

consecución de los objetivos de TI.

Transición de servicio


servicios de la organización en los que

interviene TI. (Utilidad (resultado),

garantías estipuladas (disponibilidad,

precisión)). Servicios internos y externos.

SI

La administración de cambios es el proceso que asegura que cada uno de los cambios al interior de

TI será llevado a cabo de acuerdo a un método estándar adecuado, de tal forma que garantizan una

optimización de los riesgos encontrados.

Se tiene el inventario de activos de TI que

interviene en cada uno de los servicios

internos y externos de la organización y

como se relacionan entre sí.

SI

Cada cambio en la infraestructura

propuesto, cuenta con la documentación

suficiente para su aprobación y ejecución.

(ver Anexo 6.8 para la documentación


SI

Existe un plan detallado de cómo será

realizado cada cambio en la infraestructura.

(Implementación, pruebas).

SI

Se realizan actividades de prueba de todos

y cada uno de los procesos en los que se

realizaron cambios.

SI

Se crean reportes que resumen los SI


resultados de las actividades de prueba de

cada uno de los cambios realizados.

(exitosas, no exitosas)

Administración de activos y configuraciones.

(En caso de tener una infraestructura

grande y compleja). Se tiene un Sistema de

Administración de Configuraciones.

EN

PROCESO

YA CONTAMOS CON UNA

CMDB CON

AUTODESCUBRIMIENTO

El sistema de Administración de

configuraciones cuenta con una estructura

definida para la configuración de cada ítem

de la infraestructura. (ver Anexo 6.8 para la

lista de chequeo de la documentación


EN

PROCESO


es manejada y modificada la Información

por medio los activos de TI y sus servicios.

(Que información, que tipo de información,

como se transporta de un componente a

otro, quien es responsable de cada

segmento de la información.)

EN

PROCESO

Operación del servicio

Se realiza administración de eventos. EN

PROCESO


exitosamente) de comunicación de eventos

internos. (email, sms, llamada).

EN

PROCESO

SE CUENTA CON

HERRAMIENTAS DE

CORRELACIÓN DE EVENTOS

Existe documentación acerca de quien y

como se debe solucionar los eventos

conocidos. (Información histórica de

eventos).

SI

Evento: cambio de estado significante para la administración de la configuración de algún

componente o servicio de TI. (Ej. Impresora sin tinta).

Se realiza administración de incidentes. SI

Se tiene una herramienta de administración

de incidentes que permita tener

conocimiento histórico de cada uno de los

SI


incidentes. (ver anexo 6.10 para la

documentación completa de reportes de

incidentes.)


exitosamente) de comunicación y

retroalimentación de incidentes tanto

internos como externos. (email, sms,

llamada, service desk).

SI

Existen métodos de priorización de

incidentes (urgencia, impacto en el

negocio).

SI

Hay documentación clara de quienes y que

deben hacer de acuerdo al incidente que se

presente. (Definición de roles y

responsabilidades).

SI

Incidente: Interrupción no planeada de un servicio de TI, o reducción en la calidad de un servicio

de TI. Falla de algún componente de la infraestructura de TI.

Se realiza administración de acceso. SI

Existe documentación que especifica quien

debe acceder a la información por medio

de los servicios entregados por TI y de que

forma debe hacerlo en circunstancias

normales y extraordinarias.

SI


se debe acceder y manipular la Información

por medio de los servicios entregados por

TI.

SI

Se realiza administración de problemas. SI

Existe documentación histórica de

resolución de problemas e información de

problemas considerados y sus posibles

soluciones. (ver anexo 6.11 para la

documentación completa de reporte de

problemas.)

SI

Existen métodos de categorización y

tipificación de problemas.

SI


Existen grupos de análisis de problemas de

acuerdo a su categoría y tipo.

SI

Se documenta adecuadamente las

soluciones encontradas por los grupos de

análisis.

SI

Problema: es la causa de uno o más incidentes. La causa del mismo no siempre se conoce en el

momento de la detección sino después de un análisis detallado de la situación.

Existen canales de comunicación

retroalimentación directos con los clientes.

SI

Se tienen registros categorizados de las

interacciones con los clientes (reclamos,

consideraciones del servicio, etc.)

SI

Tabla 20 – Gestión y monitoreo de TI

Valoraciones numéricas por pasos de esta lista de chequeo. Nombre Resultado Resultado máx.

posible Media (1 - 3) Actividades

evaluadas Plan de continuidad Entendiendo la organización

34 36

2.84 12


32

36 2.66

12


12 12 3 4


9 9 3 3

Administrando BCM

9 9 3 3

Total 94 102 2.9 34 Encontrar y reparar falencias de TI Total 18 18 3 6 Gestión de TI Estrategia de servicio

33 33 3 11

Diseño de servicio 70 75 2.8 25 Transición de servicio

24 27 2.67 9

Operación de servicio

52 54 2.8 18

Total 179 189 2.84 63 Tabla 21 – Resultado valoración numérica, Base tecnológica.


6.13 Validación disciplina de Gobierno en Banco de la República.

Lista de chequeo de actividades gobierno de riesgo de TI 1 Definición de roles y funciones para controlar riesgos de TI SGINF UROC SGINF UROC Total 1.1 Existe un Oficial de riesgos responsable directo del control de los riesgos de TI. x x 3 3 3

1.2 Hay un Consejo de políticas de riesgo compuesto por ejecutivos del negocio y de tecnología, que define la política para el control de riesgos de TI y le asigna prioridades a los riesgos específicos.

x x 3 3 3

1.3 Hay un Consejo de implementación encargado de llevar a cabo las políticas definidas por el Consejo de políticas de riesgo, a través de la definición de estándares y procedimientos

x x 3 3 3

1.4 Está definido un rol en cada área de negocio que vele porque se cumpla la política para el control de riesgos de TI definida por la organización.

x x 3 3 3

1.5 Hay un equipo para el manejo de riesgos de TI que asiste a los responsables de los procesos de negocio en la identificación y control de riesgos de TI.

x x 3 3 3

1.6 Existe un monitoreo de los riesgos de TI para que cumpla con las políticas y estándares definidos por los Consejos de políticas e implementación.

proceso 2 1 1,5

1.7 La alta gerencia promueve la cultura de conciencia del riesgo de TI. x x 3 3 3

1.8 Las personas responsables de la gestión de riesgos de TI promueve una comunicación efectiva sobre el tema. x 3 1 2

2 Proceso para el control de riesgos de TI 2.1 La política de riesgos de TI es actualizada regularmente x 3 1 2 2.2 Evalúe cuales procesos de negocio son fuertemente soportados por TI. x proceso 3 2 2,5

2.3 Existe un inventario de procesos de negocio con sus recursos de TI necesarios. x x 3 3 3

2.4 El proceso de identificación de riesgos de TI es descentralizado y recae sobre los jefes de cada área de negocio. x proceso 3 2 2,5

2.5 Existe un modelo para el proceso de recolección de datos relacionados con riesgos de TI. x proceso 3 2 2,5

2.6 Se ha creado una definición formal de categorías de riesgo de TI. x proceso 3 2 2,5

2.7 Se han definido categorías de riesgos de TI por orden de importancia x proceso 3 2 2,5

2.8 Se ha definido el nivel de riesgo que la organización está dispuesta a tomar "apetito al riesgo" 1 1 1

2.9 Evaluar si el "apetito al riesgo" esta alineado con las políticas y estándares definidos por la organización. 1 1 1

2.10 Una vez identificados clasificados y priorizado los riesgos de TI, se decide cuales reducir/evitar/transferir/aceptar x x 3 3 3


2.11 Se ha definido como debe reaccionar la organización a todos sus niveles ante la materialización de un riesgo x proceso 3 2 2,5

2.12 Se han definido claramente indicadores de riesgo de TI proceso 2 1 1,5 2.13 Se lleva un historial de los riesgos de TI para monitorear su evolución y asegurarse que dichos riesgos sean mitigados teniendo en consideración los puntos de vista de los ejecutivos de todas las áreas.

proceso 2 1 1,5

2.14 Existen planes de respuesta ante la presencia de incidentes. x x 3 3 3 2.15 Existe un procedimiento de revisión "post-mortem" sobre los incidentes relacionados con TI. x x 3 3 3

3 Mejores Prácticas 3.1 El método para evaluar los riesgos de TI es consistente con el método para evaluar todo tipo de riesgos, es decir se encuentra integrado con el ERM (Enterprise Risk Management)

x x 3 3 3

3.2 Las prácticas de gestión de riesgo de TI se adaptan a las prácticas de gestión de riesgo organizacional. x x 3 3 3

3.3 Se proveen los recursos adecuados para la gestión de riesgos de TI. x 3 1 2

3.4 Se usan mejores prácticas del sector o industria. x x 3 3 3 3.5 Se usan estándares nacionales o internacionales. x x 3 3 3

Tabla 22 - Lista de checheo de actividades de gobierno de TI

6.14 Validación lista de chequeo de Cultura. Tabla de referencias

Opciones Valor

Existe 3

Ocasionalmente 2

No existe 1

Tabla 23 - Valores de evaluación Resultados de evaluación del proceso del compensación de cheques.


Preguntas:

UR

OC

subgerencia informática

Sub

gere

nci

a d

e o

per

ació

n b

anca

ria

Pro

ceso

Un

idad

de

sop

ort

e y

con

tin

uid

ad

info

rmát

ica

Dep

arta

men

to

de

segu

rid

ad

info

rmát

ica

Cultura organizacional ¿La cabeza de la organización dirección o departamento conoce las políticas y reglamentaciones de riesgo de TI? 3 3 3 3 3

¿La cabeza de la organización dirección o departamento divulga las políticas y reglamentaciones de riesgo de TI? 3 3 3 3 3

¿Hace que sus subalternos se preocupen por la aplicación de estas políticas y reglamentaciones de riesgo de TI?

3 3 3 3 3

¿Consulta a sus subalternos sobre su opinión respecto al riesgo de TI? 3 3 3 2 2

Cultura Social Total: 2

¿Se presentan comportamientos espontáneos para controlar el riesgo? 3 3 3 3 3

¿Han surgido desde los comportamientos de la organización, normas de control de riesgo? 3 3 3 3 3

¿Se tienen identificados los líderes sociales en la organización? 3 3 2 1 2

¿Conocen las políticas y reglamentaciones de riesgo de TI? 3 3 3 1 2

¿Divulgan entre sus compañeros este conocimiento? 3 3 2 1 2

Políticas y Reglamentación Total: 2

¿Existe una normatividad general para todos los miembros de la organización? 3 3 3 3 3

¿Se ha definido en la normatividad que es público y que es privado en contexto general? 1 1 3 1 1

¿Existe normatividad especializada para cada tipo de miembro en la organización? 1 2 3 1 1

¿La normatividad especializada tiene definido que es público y que es privado? 1 1 1 1 1

Entrenamiento y divulgación Total: 1

¿Se tiene definido un modelo de entrenamiento para la normatividad de la empresa? 1 2 3 3 2


¿El modelo de entrenamiento es dinámico? 1 1 3 1 1 ¿Se desarrollan campañas de concientización? 3 3 3 3 3 ¿Las campañas diferencian entre público general y publico específico? 1 2 3 1 1

Retroalimentación Total: 1

¿Los miembros de la organización participan activamente de los procesos educativos? 2 1 3 3 2

¿Los miembros de la organización le dan importancia las campañas? 3 3 3 3 3

¿Los miembros de la organización aplican lo divulgado en las campañas? 3 3 3 2 2

¿De la organización surgen sugerencias para el mejoramiento de la normatividad? 3 3 3 3 3

¿Se ve el uso de la normatividad en el día a día? 3 3 3 2 2

Total: 2

Tabla 24 - Lista de Chequeo de cultura Proceso compensación de cheques


IX. BIBLIOGRAFÍA

1. Figueroa, Luis Carlos. Tesis Maestria. Guía de mejores prácticas en gestión de riesgos de

TI en el sector bancario. Bogotá : s.n., 2009. 2. Westerman, George y Hunter, Richard. IT Risk: Turning business threats into

competitive advantage. Boston, Massachusetts : Harvard Business School Press, 2007. ISBN-13: 978-1-4221-0666-2.

3. Economist Intelligence Unit. Getting smarter about IT Risk. s.l. : The Economist, The Economist - Hewlett Packard, 2008.

4. Weil, Peter, y otros. Research Briefings - Center for Information Systems Research. [En línea] July de 2004. [Citado el: 26 de 11 de 2009.] http://web.mit.edu/cisr/resbrfgs/2004_07_2A_ITGovStratDrvrs.pdf.

5. Weill, Peter y Woerner, Stephanie. Research Briefings. Center for Information Systems Research CISR. [En línea] January de 2009. [Citado el: 20 de 11 de 2009.] http://mitsloan.mit.edu/cisr/rbconfirm.php.

6. Westerman, George. Research Briefings - Center for Information Systems Research. CISR. [En línea] March de 2004. [Citado el: 11 de 11 de 2009.] http://web.mit.edu/cisr/resbrfgs/2004_03_1C_EntITRiskPrfl.pdf.

7. Westerman, George y Barnier, Brian. How Mature Is Your IT Mangement. MIT Sloan Management. Boston : CISR Research Briefings, 2008.

8. Westerman, George. Strategic Management of IT Risk. [book auth.] George Westerman, Peter Weill and Joseph Antonellis. IT Risk and Oversight. Boston : Center for Information Systems Research, 2009.

9. Cheng, Andres, Villa, Juan David y Pinilla, Santiago. Proyecto de grado. Gestión de riesgos de las tecnologias de la información (TI) en el sector bancario colombianos, su implementacion a través de la circular 052 de la superintendencia financiera colombiana y su estudio desde el marco de gestión de riesgos de ti. Bogotá : s.n., 2009.

10. Santa, John. Proyecto de grado. Análisis de marcos de gestión del riesgo de TI: Los marcos 4-A, Risk IT y la construccion de una herramienta de análisis. Bogotá. : s.n., 2009.

11. Business Continuity Institute. Good Practices Guideline. Reading, UK : Business Continuity Institute, 2008.

12. Herrera, Andrea. BCM: Ciclo de Vida. [Notas de Clase] Bogotá : Universidad de los Andes, 2008.

13. ISACA. ISACA. Serving IT Governance Professionals. [En línea] 2009. [Citado el: 16 de 09 de 2009.] http://www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/Obtain_COBIT/CobiT4.1_Brochure.pdf.

14. Enterprise Risk: Identify, Govern and Manage IT Risk. s.l. : IT Governance Institute, IT Risk Governance Institute, 2009.

15. Rapaille, Clotaire. El Código Cultural. s.l. : Editorial Norma, 2007. ISBN 978-958-45-0163-9.


16. Corella, María Antonieta Rebeil y Reséndiz, Celia RuizSandoval. El poder de la comunicación en las organizaciones. s.l. : Plaza y Valdes, 2008.

17. Hall, Edward T. Más allá de la cultura. Barcelona : Editorial Gustavo Gili, SA, 1976. 18. Garzón Bejarano, Adela. Information security culture: the effect of institutional factors

and the mediating role of business continuity practices. 19. Berry, Tim. The Plan-As-You-Go Business Plan. Canada : Entrepeneur Media Inc., 2008.

1-59918-190-08. 20. Banco de la Republica. La historia del Banco. Banco Central. [En línea] 2009. [Citado el:

Septiembre de 28 de 2009.] http://www.banrep.gov.co/documentos/el-banco/pdf/historia-banco-sept.pdf.

21. Presentación del Sistema Integral de Riesgo Operativo SIARO del Banco de la República marzo de 2009. 2009.

22. República., documento interno de la Subgerencia Informática del Banco de la. SGINF-PN 21 Subgerencia de Informática Dirección Estrategica 2008.

23. República, documento interno de la Subgerencia Informática del Banco de la. SGINF-PN 27 Gobierno Tecnologíco en la Subgerencia de Informática.

24. —. SGINF-PN 25 Gestión de riesgos para la Subgerencia de Informática 2008. 25. —. SGINF-PN 18 Politicas de Seguridad de la información. 26. Pagina web Banco de la República . http://www.banrep.gov.co/sistema-

financiero/sip_ch_defini.htm#1. [En línea] 15 de 10 de 2009. 27. OGC. Best Management Practice. [En línea] 2009. [Citado el: 9 de Diciembre de 2009.]

http://www.best-management-practice.com/Publications-Library/IT-Service-Management-ITIL/?DI=603118#GEMS6415426.

28. Herrera, Andrea. Notas de Clase. Gestion de Continuidad de TI. Bogotá DC, Coombia : Universidad de los Andes, 2008.

29. Hayes, Ian S. Five principles for selecting SLA metrics. [En línea] 2007. [Citado el: 11 de 12 de 2009.] http://www.clarity-consulting.com/five_principles.htm.

30. OGC. Best Managemente Practice. ITIL. [En línea] 2009. [Citado el: 17 de 11 de 2009.] http://www.best-management-practice.com/gempdf/itSMF_An_Introductory_Overview_of_ITIL_V3.pdf.

31. IT Process Maps. The ITIL Wiki. [En línea] IT Process Maps GbR, 1 de 2009. [Citado el: 10 de 10 de 2009.] http://wiki.en.it-processmaps.com/index.php/Main_Page.

32. Figueroa, Luis Carlos. Guia de mejores practicas de gestión de riesgo de TI en el sector basncario Colombiano. Bogotá : Universidad de los Andes, 2009.

33. BCM Institute. Business Continuity Management (BCM). [En línea] MediaWiki, Marzo de 2009. [Citado el: 2 de Septiembre de 2009.] http://en.bcmpedia.org/wiki/.

34. DRI International. DRII The institute For Continuity Management. [En línea] 2009. [Citado el: 12 de 09 de 2009.] https://www.drii.org.

35. it-processmaps. ITIL Process Maps. [En línea] 2009. [Citado el: 28 de 10 de 2009.] http://en.it-processmaps.com/products/itil-process-map.html.

36. Republica, Banco de la. history. Banco de la Republica Colombia. [En línea] 2009. www.banrep.gov.co.

especificación por disciplinas de la guía de mejores

Documents