Embed Size (px)
Citation preview
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
PROPUESTA PARA EL MEJORAMIENTO DEL NIVEL DE SEGURIDAD INFORMÁTICA BASADA EN EL CONOCIMIENTO EN LOS PROYECTOS DE LA
UEN PYSA.
WILLIAM ROBERTO MADRIGAL ZÚÑIGA
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIÓN
DE PROYECTOS
San José, Costa Rica
Noviembre 2006
ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos
DIRECTOR DEL PROYECTO
LECTOR
LECTOR
William Roberto Madrigal Zúñiga
SUSTENTANTE
iii
Derechos de propiedad intelectual
Este trabajo está bajo la protección de los
derechos de autor otorgados por la ley.
Para toda reproducción del mismo, total o
parcial, debe contar con la respectiva
autorización del autor.
iv
Dedicatoria
A Dios Todopoderoso, por guiarme y fortalecerme en todo momento
A mi esposa Sandra, por estar en todo momento a mi lado
A mis hijos Paula y Saúl, por dar inspiración a mi vida
A mi padre y a mi madre, por su permanente apoyo
v
Agradecimientos Deseo hacer un especial agradecimiento a los siguientes compañeros del
Proyecto Hidroeléctrico Pirrís, Centro de Apoyo a Proyectos, Proyecto
Hidroeléctrico Cariblanco, Proyectos de Transmisión Regiones Huetar y Brunca y
el Proyecto Geotérmico las Pailas, por el apoyo, aporte y disposición que siempre
demostraron para mi trabajo.
Lic. Alvaro Castillo Quesada Jefe Administrativo, P.H. Pirrís
Ing. Oscar Luis Vega Antonini Director del P.H. Pirrís y Profesor de la
Maestría
Ing. Alexander Solís Barboza Coordinador General de Proyectos de la
UEN PySA
Grupo MAP 32 de la UCI Compañeros de la Maestría
Dr. Franklin Marín Vargas Director de Carrera de MAP.
Tec. Juan Carlos Cordero C. Coordinador de Tecnologías de
Información del Centro de Apoyo a
Proyectos.
Tec. Alfredo Méndez Q. Coordinador de Tecnologías de
Información de Proyectos de Transmisión
Regiones Huetar y Brunca.
Ing. Alexis Castillo García Coordinador de Tecnologías de
Información del Proyecto Hidroeléctrico
Cariblanco.
Bach. Andrea Blanco Flores Coordinadora de Tecnologías de
Información del Proyecto Geotérmico las
Pailas.
vi
INDICE
INDICE DE ILUSTRACIONES-----------------------------------------------------------------------------IX INDICE DE CUADROS -------------------------------------------------------------------------------------- X RESUMEN ------------------------------------------------------------------------------------------------------XI 1 INTRODUCCIÓN ------------------------------------------------------------------------------------------1
1.1 ANTECEDENTES------------------------------------------------------------------------------------------ 1 1.2 JUSTIFICACIÓN DEL PROBLEMA ----------------------------------------------------------------------- 2 1.3 OBJETIVO GENERAL------------------------------------------------------------------------------------- 3
1.3.1 Objetivos Específicos ---------------------------------------------------------------------------- 3
2 MARCO TEÓRICO----------------------------------------------------------------------------------------5 2.1 MARCO REFERENCIAL ---------------------------------------------------------------------------------- 5
2.1.1 Antecedentes de la Organización------------------------------------------------------------- 5 2.1.1.1 Generalidades del ICE-----------------------------------------------------------------------5 2.1.1.2 Generalidades de las Plantas Hidroeléctricas construidas por el ICE-----------6 2.1.1.3 Otras plantas generadoras de energía --------------------------------------------------6 2.1.1.4 Generalidades de la Unidad Estratégica de Negocios Proyectos y Servicios
Asociados (UEN PySA)----------------------------------------------------------------------7 2.1.1.5 Generalidades del los Proyectos con mayor importancia desde el punto de
vista Tecnológico ------------------------------------------------------------------------------9 2.1.1.5.1 Proyecto Hidroeléctrico Cariblanco --------------------------------------------------9 2.1.1.5.2 Generalidades del Centro de Apoyo a Proyectos--------------------------------9 2.1.1.5.3 Generalidades de Proyectos de Transmisión Regiones Huetar y Brunca.
---------------------------------------------------------------------------------------------- 10 2.1.1.5.4 Generalidades del Proyecto Hidroeléctrico Pirrís ------------------------------ 10
2.2 ASPECTOS DE LA SEGURIDAD INFORMÁTICA ------------------------------------------------------13 2.2.1 Que es Seguridad Informática ----------------------------------------------------------------13 2.2.2 La Seguridad Física -----------------------------------------------------------------------------14 2.2.3 La Seguridad Lógica ----------------------------------------------------------------------------16 2.2.4 Los Intrusos----------------------------------------------------------------------------------------17 2.2.5 Amenazas Humanas ----------------------------------------------------------------------------17
2.3 GENERALIDADES SOBRE LA ADMINISTRACIÓN DE PROYECTOS--------------------------------20 2.3.1 Administración de Proyectos ------------------------------------------------------------------23 2.3.2 Áreas de Conocimiento de la Administración de Proyectos---------------------------24 2.3.3 Gestión de los Recursos Humanos del Proyecto ----------------------------------------26 2.3.4 Gestión de las Comunicaciones del Proyecto --------------------------------------------28 2.3.5 Gestión de los Riesgos -------------------------------------------------------------------------30
2.4 ANTECEDENTES DEL PROBLEMA---------------------------------------------------------------------36
3 MARCO METODOLÓGICO -------------------------------------------------------------------------- 38 3.1 DEFINICIÓN DEL TIPO DE ESTUDIO-------------------------------------------------------------------38 3.2 FUENTES DE INFORMACIÓN ---------------------------------------------------------------------------39 3.3 SUJETOS DE LA INVESTIGACIÓN----------------------------------------------------------------------39
vii
3.4 ETAPAS DE LA APLICACIÓN----------------------------------------------------------------------------39 3.4.1 Descripción y uso de las Herramientas de Campo--------------------------------------40
3.4.1.1 Entrevista Cualitativa ----------------------------------------------------------------------- 40 3.4.1.1.1 Requerimientos para el ejercicio --------------------------------------------------- 41 3.4.1.1.2 Procedimiento para el ejercicio ----------------------------------------------------- 43
3.4.1.2 Encuesta--------------------------------------------------------------------------------------- 44 3.4.1.2.1 Requerimientos para el ejercicio --------------------------------------------------- 46 3.4.1.2.2 Procedimiento para el ejercicio ----------------------------------------------------- 47
3.4.2 Desarrollo de Métodos de Gestión ----------------------------------------------------------48 3.4.2.1 Método para la planificación del Recurso Humano--------------------------------- 48 3.4.2.2 Método para la Planificación de las Comunicaciones ----------------------------- 49 3.4.2.3 Método para la Planificación de los Riesgos----------------------------------------- 50
4 DIAGNÓSTICO DE LA SIBC EN PROYECTOS------------------------------------------------ 52 4.1 MECANISMO DE VALORACIÓN DE LAS HERRAMIENTAS APLICADAS ----------------------------52 4.2 RESULTADO DEL ESTUDIO DESARROLLADO.-------------------------------------------------------54
4.2.1 Conclusiones del estudio-----------------------------------------------------------------------61
5 DESARROLLO DE MÉTODOS DE GESTIÓN -------------------------------------------------- 64 5.1 MÉTODO PARA LA GESTIÓN DEL RECURSO HUMANO --------------------------------------------64
5.1.1 Planificación del Recurso Humano ----------------------------------------------------------64 5.1.2 Desarrollo de la Matriz de Roles y Responsabilidades para el proceso de
selección y formación de los usuarios ------------------------------------------------------68 5.1.3 Adquisición del Equipo de Trabajo.----------------------------------------------------------70 5.1.4 Desarrollo del Recurso Humano. ------------------------------------------------------------72
5.2 MÉTODO PARA LA PLANIFICACIÓN DE LAS COMUNICACIONES.---------------------------------73 5.3 MÉTODO PARA LA PLANIFICACIÓN DE LOS RIESGOS. --------------------------------------------76
5.3.1 Identificación de Riesgos.----------------------------------------------------------------------76 5.3.2 Análisis Cualitativo del Riesgo. ---------------------------------------------------------------81 5.3.3 Proceso de respuesta al Riesgo.-------------------------------------------------------------84
5.3.3.1 Estrategias y acciones. -------------------------------------------------------------------- 84 5.3.3.2 Contingencias y respaldos. --------------------------------------------------------------- 86 5.3.3.3 Disparadores del Riesgo. ----------------------------------------------------------------- 87 5.3.3.4 Fecha y responsable. ---------------------------------------------------------------------- 87 5.3.3.5 Matriz de respuesta al Riesgo ----------------------------------------------------------- 87
5.3.4 Seguimiento y Control de los Riesgos ------------------------------------------------------90 5.4 GUÍA DE APLICACIÓN.----------------------------------------------------------------------------------91
6 CONCLUSIONES --------------------------------------------------------------------------------------- 93 7 RECOMENDACIONES -------------------------------------------------------------------------------- 95 8 GLOSARIO ----------------------------------------------------------------------------------------------- 98 9 BIBLIOGRAFÍA---------------------------------------------------------------------------------------- 104 10 ANEXOS------------------------------------------------------------------------------------------------- 106
ANEXO 1: PLANTILLA DE ACTA (CHARTER) DEL PFG.----------------------------------------------- 107 ANEXO 2: DECLARACIÓN DEL ALCANCE DEL PROYECTO.------------------------------------------ 111 ANEXO 3: ESTRUCTURA DE DIVISIÓN DEL TRABAJO. ----------------------------------------------- 115
viii
ANEXO 4: CRONOGRAMA DEL PROYECTO. ----------------------------------------------------------- 117 ANEXO 5: MAPA DEL PROYECTO FINAL DE GRADUACIÓN.----------------------------------------- 120 ANEXO 6: LICENCIA CREATIVE COMMONS. ----------------------------------------------------------- 122 ANEXO 7: ESTRUCTURA DEL CONTENIDO DEL PFG. ----------------------------------------------- 124 ANEXO 8: INSTRUMENTO ENTREVISTA.---------------------------------------------------------------- 126 ANEXO 9: INSTRUMENTO ENCUESTA.------------------------------------------------------------------ 137 ANEXO 10: LA SEGURIDAD INFORMÁTICA HOY DÍA, “TERRORISMO DIGITAL”. ------------------ 145
ix
INDICE DE ILUSTRACIONES
Figura 1: Organigrama de la UEN PySA.............................................................................. 8 Figura 2: Organización del P.H. Pirrís................................................................................ 11 Figura 3: Intrusiones. (A.S.S. Borghello, 2001).................................................................. 19 Figura 4: Planificación de los Recursos Humanos: Entradas, Herramientas y
Técnicas y Salidas (PMI, 2004).......................................................................... 27 Figura 5: Adquirir el Equipo del Proyecto: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004)............................................................................................ 27 Figura 6: Desarrollar el Equipo del Proyecto: Entradas, Herramientas y Técnicas,
y Salidas (PMI, 2004). ......................................................................................... 28 Figura 7: Planificación de las Comunicaciones: Entradas, Herramientas y
Técnicas, y Salidas (PMI, 2004).......................................................................... 29 Figura 8: Distribución de la Información: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004)............................................................................................. 29 Figura 9: Planificación de la Gestión de Riesgos: Entradas, Herramientas y
Técnicas, y Salidas (PMI, 2004).......................................................................... 31 Figura 10: Identificación de Riesgos: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004)............................................................................................. 32 Figura 11: Análisis Cualitativo de Riesgos: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004)............................................................................................. 33 Figura 12: Planificación de la Respuesta a los Riesgos: Entradas, Herramientas
y Técnicas y Salidas (PMI, 2004)........................................................................ 34 Figura 13: Seguimiento y Control de Riesgos: Entradas, Herramientas y
Técnicas y Salidas (PMI, 2004)........................................................................... 36 Figura 14: Comparación de la SIBC de las Entrevistas, en los Proyectos
Evaluados............................................................................................................ 55 Figura 15: Comparación de la SIBC de las Encuestas, en los Proyectos
Evaluados............................................................................................................ 57 Figura 16: Comparación de la SIBC entre las Entrevistas y las Encuestas...................... 58 Figura 17: Comparación de la SIBC por área y por Proyecto............................................ 59 Figura 18: Concepto de SIBC por área, en los Proyectos de la UEN PySA...................... 60 Figura 19: Ejemplo de utilización del Mind Manager en la Tormenta de Ideas. ................ 77 Figura 20: Categorización del resultado de la Tormenta de Ideas. ................................... 78 Figura 21: EDT del PFG .................................................................................................. 116 Figura 22: Cronograma del PFG...................................................................................... 118 Figura 23: Mapa del PFG................................................................................................. 121
x
INDICE DE CUADROS
Cuadro 1: Procesos de Dirección de Proyectos y su correspondencia(PMI, 2004) .......... 22 Cuadro 2: Tabla de valoración de las Entrevistas. ............................................................ 52 Cuadro 3: Tabla de valoración de las Encuestas. ............................................................. 53 Cuadro 4: Puestos de trabajo y sus conocimientos mínimos en TI. .................................. 66 Cuadro 5: Matriz de Roles y Funciones. ............................................................................ 69 Cuadro 6: Matriz de Comunicación.................................................................................... 75 Cuadro 7: Plantilla de Identificación del Riesgo................................................................. 79 Cuadro 8: Escala de Calificación de la Probabilidad. ........................................................ 81 Cuadro 9: Escala de Calificación del Impacto.................................................................... 82 Cuadro 10: Evaluación del impacto de los Riesgos........................................................... 82 Cuadro 11: Matriz de valoración de un riesgo específico (P*I). ......................................... 83 Cuadro 12: Matriz de Evaluación del Riesgo, priorizada descendentemente.................... 83 Cuadro 13: Estrategias de Riesgos Negativos o Amenazas. ............................................ 85 Cuadro 14: Estrategia de Riesgos Positivos u Oportunidades. ......................................... 86 Cuadro 15: Plantilla de Planificación a la Respuesta de los Riesgos. ............................... 88 Cuadro 16: Plantilla de Planificación a la Respuesta de los Riesgos................................ 90
xi
Resumen
A pesar de la gran inversión que el ICE ha realizado en equipo de protección de las Tecnologías de Información, se mantiene un portillo grande por medio del cual es totalmente vulnerable: “los usuarios finales de las Tecnologías de Información”. Estos a falta de conocimiento podrían permitir a terceras personas acceder a la red haciendo uso de los diferentes servicios que la Tecnología facilita. Por la debilidad que el usuario muestra en el conocimiento de ésta, es que se debe crear una propuesta que logre concienciar a dichos usuarios de Tecnologías de Información (TI), logrando reducir la posibilidad de que la Organización se vea afectada seriamente por accesos no autorizados de personas internas o externas a la misma. La aplicación de esta propuesta beneficiará a todos los usuarios de la Organización, generando un conocimiento que reforzará una adecuada conducta cuando se utilicen TI en los Proyectos de la UEN PySA.
El presente trabajo tiene como objetivo elaborar una propuesta
metodológica que sirva de guía para mejorar la Seguridad Informática basada en el conocimiento de los usuarios de las Tecnologías de Información, en los Proyectos de la UEN PySA; además de evaluar la situación actual de los Proyectos, en aspectos de Seguridad Informática basada en el Conocimiento e identificar cuales son las principales debilidades o carencias existentes en los mismos. Se elaboran métodos para realizar una adecuada planificación del Recurso Humano y Comunicación, incluyendo la metodología para establecer un control y seguimiento de los riesgos, los cuales dependiendo del caso serán: eliminarlos, transferirlos, mitigados o aceptarlos, todo esto en pro del mejoramiento de la Seguridad Informática. Se diseñan técnicas y herramientas de la Administración de Proyectos aplicando un fundamento científico a la propuesta.
Inicialmente se desarrolla un diagnóstico y análisis de la información, esto
por medio de la aplicación de dos metodologías: la Entrevista y la Encuesta, las cuales están dirigidas al personal de Tecnologías de Información y a los usuarios en general. La aplicación varía dependiendo de la metodología. Para el caso de las entrevistas, se realizaron personalmente y en forma individual; para el caso de la encuesta, se realizó por medio del correo electrónico con la colaboración de los encargados de TI de cada Proyecto. El resumen de hallazgos como salida del proceso de la investigación o diagnóstico será la entrada para la planificación de los métodos propuestos en los objetivos del trabajo; luego de esto se procede a desarrollar los tres métodos que serán el aporte al conocimiento que el presente trabajo entrega. Finalmente, en las recomendaciones y conclusiones producto de lo encontrado y desarrollado en el presente trabajo, se valora la labor realizada y la forma en que a futuro este debe ser implementado y mejorado. Se realiza una evaluación de los conceptos de Administración de Proyectos aplicados y de la metodología establecida por el PMI.
xii
Como resultado del estudio realizado se obtienen datos interesantes del estado de la SIBC en los proyectos de la UEN PySA, los cuales en términos generales reflejan un nivel intermedio de la SIBC; sin embargo no es suficiente para superar la meta propuesta de un 80% lo cual daría tranquilidad. Esto no significa que se descartaría un seguimiento y control de la SIBC, pero como la meta no fue superada, se justifica la creación y la aplicación la metodología propuesta en el presente PFG, la cual asegura un mejoramiento de la SIBC tomando en consideración los conceptos de Administración de Proyectos adquiridos a lo largo de la MAP.
En cuanto a la metodología para la gestión de recursos humanos, esta
incluye los procesos necesarios para optimizar el recurso involucrado en la implementación de la SIBC en los Proyectos, y se detallan las guías que permitirán establecer los procesos de planificación, adquisición de personal y desarrollo del equipo de acuerdo a los requerimientos necesarios.
Considerando que la gestión de las comunicaciones del proyecto incluye los procesos requeridos para asegurar la generación oportuna y apropiada, la recolección, la distribución, el almacenamiento y la disposición final de la información del proyecto, este trabajo estableció una plantilla para una buena planificación y distribución de la comunicación la cual se podrá mejorar de acuerdo a las necesidades que se presenten en la ejecución de las presentes metodologías.
Para definir la metodología o guía para la gestión del riesgo se desarrollaron los elementos necesarios que permitieran la identificación del riesgo. Esto incluye la determinación de tipos, técnicas de búsqueda y un listado de riegos típicos. Se desarrolla una guía para el análisis cualitativo de los riegos y las formas en que estos podrían llegarse a manejar. Todo lo anterior nuevamente basado en el PMBOK.
Además se desarrolla una guía para que el Administrador de TI en cada
Proyecto tenga una idea que cómo arrancar el proceso y llevarlo por buen camino para la obtención exitosa de un nivel adecuado de SIBC en su respectivo Proyecto.
En las conclusiones y recomendaciones se valora el trabajo realizado y la
forma en que la SIBC a futuro debe ser implementada y mejorada. Se realiza una evaluación de los conceptos de Administración de Proyectos aplicados y de la metodología establecida por el PMI.
1
1 Introducción
1.1 Antecedentes
El presente trabajo corresponde al Proyecto Final de Graduación para
optar por el grado de Master en Administración de Proyectos. El tema elegido es
“Propuesta para el mejoramiento del nivel de Seguridad Informática basada en el
Conocimiento en los Proyectos de la UEN PySA.”.
Este tema tiene una gran importancia para los Proyectos de la UEN PySA y
el resto de la Institución (ICE). Actualmente el ICE ha invertido una cantidad
millonaria en la adquisición tanto de Hardware como de Software especializado en
seguridad informática, tal es el caso de los “Firewall” o “Murallas de Fuego”, que
impiden el acceso de personas malintencionadas que podrían ocasionar serios
daños a los Sistemas Informáticos de la Institución; de igual forma se han creado
áreas con un buen nivel de seguridad física. Sin embargo, una acción
malintencionada no necesariamente vendrá de fuera de la Institución (p.e.
Internet), si no por el contrario, normalmente son ataques que se generan desde
el interior de las mismas organizaciones (empleados o ex empleados con cierto
nivel de resentimiento), en este punto no hay inversión que valga y finalmente se
está a merced de los usuarios. Este es un problema que puede ser generado por
cualquier persona consiente o inconcientemente, ya que como funcionaria suele
dar información importante que eventualmente será utilizada en contra de la
organización. No se debe olvidar que los Sistemas Informáticos hoy en día son
considerados un activo invaluable que deben ser protegidos y preservarlos.
El presente trabajo busca conocer si efectivamente por el proceder como
usuarios de Tecnologías de Información (TI), se crean vulnerabilidades o se abren
portillos, de forma tal que cualquier persona mal intencionada podría generar un
2
daño de magnitudes significativas en los Sistemas Informáticos medulares de la
Organización (p.e. Sistemas de Planillas), o bien en los equipos donde se sirven
día a día los usuarios, como es el caso del Servicio de Correo Electrónico, y a
partir de esto proponer una forma de contrarrestar este efecto negativo en la
organización, la propuesta metodológica a desarrollarse pretende mejorar el nivel
de Seguridad Informática basada en el Conocimiento (SIBC) en los Proyectos de
la UEN PySA, tomando en cuenta tres enfoques principales: los Recursos
Humanos, la Comunicación y los Riesgos (una metodología en cada caso como
aporte al conocimiento), además del diagnóstico y análisis de la información
obtenida de la investigación de campo con sus respectivas recomendaciones y
conclusiones producto de lo encontrado y desarrollado en la investigación. Esto
generará una mejora y un aumento del nivel de seguridad por parte de los
usuarios, esto como producto del conocimiento adquirido. En síntesis, generando
un aumento progresivo de malicia informática en todos los usuarios, se dejará a un
lado la confianza que actualmente nos impera y domina.
1.2 Justificación del problema
Sin importar cuántas advertencias se indiquen al usuario de equipos
informáticos en una organización, es probable que un importante porcentaje de
ellos se atenga a unas mínimas normas de seguridad y ponga en riesgo toda una
red corporativa por descuido o ignorancia. Actualmente la seguridad informática no
es una prioridad para los empleados o usuarios de una red. Se desconoce el nivel
de seguridad y el peligro que ellos representan en la cadena de seguridad de
cualquier empresa. Es de suponer que tienen un alto riesgo de seguridad, por la
confianza intrínseca depositada en ellos y los derechos inherentes que deben
poseer sobre la red. Si no son correctamente formados, pueden representar un
riesgo para cualquier red corporativa, ya sea consciente o inconscientemente, y
provocar un incidente de seguridad importante en el sistema.
3
Este tipo de comportamientos en los sistemas corporativos donde se
ejecutan programas de dudosa procedencia y donde se advierte explícitamente
sobre su potencial peligro, indica que existe mucho camino por recorrer en este
sentido. Es importante analizar en materia de recurso humano lo que sería
necesario implementar para empezar a contrarrestar este comportamiento tan
común en todos los usuarios de equipos informáticos. Por otro lado en materia de
comunicación, es importante establecer los mecanismos necesarios para
garantizar una adecuada divulgación de este tipo de información y finalmente
tener un verdadero control y seguimiento de los riesgos que corre la organización
en materia de SIBC (Ver Anexo #10, “Terrorismo Digital”).
Por esta razón, nace la idea de proponer una Metodología que permita
crear una verdadera conciencia de seguridad informática en los usuarios
aumentando el nivel de malicia, de forma tal que se pueda como un todo mejorar
el nivel de Seguridad informática en los Proyectos de la UEN PySA.
1.3 Objetivo General
Elaborar una propuesta metodológica que sirva de guía para mejorar la
Seguridad Informática basada en el conocimiento (SIBC) de los usuarios de las TI,
en los Proyectos de la UEN PySA.
1.3.1 Objetivos Específicos
1. Evaluar la situación actual de los Proyectos de la UEN PySA, en aspectos
de Seguridad Informática basada en el Conocimiento, e identificar cuales
son las principales debilidades o carencias existentes en los mismos.
2. Elaborar un método para realizar un adecuado entrenamiento, capacitación
y escogencia del Recurso Humano, que utilizan TI en los Proyectos de la
4
UEN PySA.
3. Elaborar un método para realizar una adecuada planificación de las
Comunicaciones para nivelar conocimientos en los usuarios de TI, en los
Proyectos de la UEN PySA.
4. Elaborar un método para realizar una adecuada Gestión de los Riesgos, de
manera que se pueda aumentar la probabilidad y el impacto de los eventos
positivos, y disminuir la probabilidad y el impacto de los eventos adversos al
mejoramiento de la SIBC en los Proyectos de la UEN PySA, estableciendo
como respuesta a los estos, que puedan ser eliminados, transferirlos,
mitigados o aceptarlos.
5. Determinar o diagnosticar el nivel de Seguridad Informática basada en el
Conocimiento, en los Proyectos de la UEN PySA.
6. Crear conciencia en la Coordinación General de Proyectos y en los
Directores de Proyectos, acerca de la importancia que tiene la formación de
los empleados, en materia de Seguridad Informática.
7. Desarrollar en el empleado un mayor nivel de compromiso con la Seguridad
Informática basada en el Conocimiento.
8. Aplicar técnicas y herramientas de la Administración de Proyectos de
manera que se desarrolle un fundamento científico a la presente Propuesta.
9. Nivelar conocimiento en los usuarios de TI, en materia de Seguridad
Informática en los diferentes Proyectos de la UEN PySA.
5
2 Marco Teórico
2.1 Marco Referencial
2.1.1 Antecedentes de la Organización
2.1.1.1 Generalidades del ICE “El Instituto Costarricense de Electricidad (ICE) fue creado el 8 de abril de
1949 mediante el Decreto de Ley Nº 449, como resultado de una larga lucha
librada por varias generaciones de costarricenses en procura de una solución
definitiva al problema de escasez de energía, y en apego de la soberanía nacional
en el campo de la explotación de los recursos hidroeléctricos del país (ICE, 1997).
El ICE se creó como una institución autónoma encargada del desarrollo de
las fuentes productoras de energía eléctrica del país. Algunas de las funciones
que se encomendaron fueron (ICE, 1997):
1. Solucionar el problema de escasez de energía eléctrica del país, mediante la
construcción y puesta en servicio de más plantas de energía hidroeléctrica, con
sus correspondientes redes de distribución.
2. Promover el desarrollo del país mediante el uso de la energía eléctrica como
fuente de fuerza motriz.
3. Procurar la utilización racional de los recursos naturales y terminar con su
explotación destructiva e indiscriminada.
4. Conservar y defender los recursos hidráulicos del país, mediante la protección
de las cuencas, las fuentes, los cauces de los ríos y las corrientes de agua.
5. Hacer de los procedimientos técnicos, administrativos y financieros, modelos
6
de eficiencia, capaces de garantizar el buen funcionamiento del Instituto, que
sirvan de norma a otras actividades costarricenses.
Cabe mencionar que el ICE no absorbió a la empresa extranjera desde un
principio; ambos sistemas coexistieron hasta 1967 (ICE, 1997). Pero es claro que
a partir de la creación del ICE, con la puesta en operación de sus plantas
generadoras de energía, el país pudo dirigir su desarrollo eléctrico de acuerdo con
sus propias necesidades sociales y económicas.”
Estratégicamente, gran parte del desarrollo del país en el área de
electrificación y telecomunicación ha estado en manos del ICE, una institución
que, a través del tiempo, ha demostrado ser altamente eficiente, con un gran peso
en la economía nacional, brindando, reiteramos, sus dos servicios esenciales:
energía eléctrica y telecomunicaciones (ICE, 1997).
2.1.1.2 Generalidades de las Plantas Hidroeléctricas construidas por el ICE Este tipo de plantas toma la energía potencial del agua para transformarla
en energía eléctrica. Desde el año 1950 hasta el año 2006 se han construido las
siguientes plantas: Planta Garita, Río Macho, Cachí, Tapantí, Planta Arenal,
Corobicí, Ventanas Garita, Alberto Echandi, Sandillal, Toro I, Toro II, Angostura,
Peñas Blancas. En proceso de construcción se encuentran el Proyecto Pirrís y
Proyecto Cariblanco (Grupo ICE, 2005).
2.1.1.3 Otras plantas generadoras de energía El ICE ha construido también plantas que aprovechan otras fuentes, como
las plantas térmicas alimentadas por diesel y búnker; las plantas geotérmicas que
utilizan la energía almacenada bajo la superficie de la tierra y la planta eólica que
usa la fuerza del viento. Estas plantas son: Térmica San Antonio, Térmica Colima,
Térmica San Antonio II, Térmica Barranca, Térmica Moín, Térmica Puerto
7
Jiménez, Geotérmica Miravalles I, Eólica Tejona, Geotérmica Miravalles II,
Geotérmica Miravalles III y Borinquen Las Pailas.
Adicionalmente en lugares alejados de los centros de población, como la
Isla del Coco y Chirripó, se han instalado paneles solares que utilizan la luz del sol
como fuente energética (Grupo ICE, 2005).
2.1.1.4 Generalidades de la Unidad Estratégica de Negocios Proyectos y Servicios Asociados (UEN PySA)
Esta es una Unidad de Negocios que trabaja por el desarrollo del país, en la
construcción de proyectos y servicios asociados a la industria eléctrica,
satisfaciendo las necesidades y expectativas de los clientes y demás interesados.
A lo largo de los años ha forjado la realización de gran cantidad de proyectos en
diferentes partes del territorio nacional, optimizando los recursos con que cuenta,
poniendo a disposición de la sociedad costarricense nuestras capacidades,
brindando así soluciones efectivas en el desarrollo eléctrico nacional,
fundamentando los esfuerzos en el principio de desarrollo sostenible,
considerando las variables ambientales, sociales y económicas como elementos
claves de su quehacer (Grupo ICE, 2005).
8
Figura 1: Organigrama de la UEN PySA
Entre muchas obras y proyectos que destacan el quehacer de la Unidad de
Negocio, se pueden mencionar:
Túneles.
Perforación Profunda (Plantas Geotérmicas).
Líneas de Transmisión y de Distribución.
Montajes Electromecánicos.
Subestaciones.
Presas.
Obras Metalmecánicas.
Innovación Tecnológica.
Casa de Máquinas.
Estudios Preliminares, de Factibilidad y diseños de Proyectos.
9
Actualmente ejecuta la construcción varios Proyectos, a decir Proyecto
Hidroeléctrico Pirrís, Proyecto Hidroeléctrico Cariblanco, Proyecto Geotérmico las
Pailas y otros proyectos de menor envergadura (Grupo ICE, 2005)
2.1.1.5 Generalidades del los Proyectos con mayor importancia desde el punto de vista Tecnológico
2.1.1.5.1 Proyecto Hidroeléctrico Cariblanco
El Proyecto Hidroeléctrico Cariblanco se ubica en el distrito 14 (Sarapiquí)
del Cantón Central de la Provincia de Alajuela y aprovecha las aguas del río
Sarapiquí. Se contará con dos turbinas tipo Francis, cuya capacidad de
generación es de 80 MW. Su objetivo general es: aportar al Sistema Nacional
Interconectado una capacidad de generación de 80 MW. Actualmente se
encuentra desarrollando obras subterráneas, excavación del embalse, obra civil
casa de máquinas, captación Sarapiquí y tanque de oscilación y en etapa de
finalización de la construcción de caminos. El proyecto entrará a operar en dos
etapas: Unidad #1 el 06/08/2007 y la unidad #2 el 26/09/2007. El Proyecto
Cariblanco está financiado mediante un esquema de fideicomiso. Al 25 de julio del
2006 el avance real de las obras era de un 77,81% (PySA, 2006).
En cuanto al recurso de Tecnologías de Información, se puede indicar que
el P.H. Cariblanco representa más de un 20% del equipo existente en los
Proyectos, lo cual lo convierte en el tercer Proyecto de importancia, a los que se
aplicarán de las herramientas de campo en la etapa de diagnóstico.
2.1.1.5.2 Generalidades del Centro de Apoyo a Proyectos
En cuanto al recurso de Tecnologías de Información, se puede indicar que
el CAP (Centro de Apoyo a Proyectos), representa más de un 30% del equipo
existente en los Proyectos, lo cual lo convierte en el segundo sitio de importancia,
a los que se aplicarán de las herramientas de campo en la etapa de diagnóstico.
10
2.1.1.5.3 Generalidades de Proyectos de Transmisión Regiones Huetar y
Brunca.
En cuanto al recurso de Tecnologías de Información, se puede indicar que
la LTA (Línea de Transmisión Atlántica), representa más de un 7% del equipo
existente en los Proyectos, lo cual lo convierte en el cuarto sitio de importancia, a
los que se aplicarán de las herramientas de campo en la etapa de diagnóstico.
2.1.1.5.4 Generalidades del Proyecto Hidroeléctrico Pirrís
El Proyecto Hidroeléctrico Pirrís se localiza en la cuenca del río Pirrís
(Vertiente del Pacífico) en las cercanías de las ciudades de San Marcos de
Tarrazú y San Pablo de León Cortés, en la provincia de San José. La Casa de
Máquinas se ubica en las cercanías del caserío de Bijagual (distrito de La Legua)
de Aserrí.
Tendrá una potencia instalada de 128 MW y una generación media anual
de 560 GWh. Consiste en una presa de Concreto Compactado con Rodillo (CCR)
de 113 m de alto que formará un embalse útil de 30 hm³ que le da capacidad de
regulación mensual. Una conducción subterránea de aproximadamente 11 Km
permitirá aprovechar una caída bruta de 874 metros. La Casa de Máquinas
albergará dos unidades pelton de 64 MW cada una. La línea de transmisión, de
72 Km y 230 kV, conectará la nueva planta con el centro de carga metropolitano.
Este sistema de transmisión es parte de las obras de interconexión del SIEPAC
(P.H. Pirrís, 2006).
Para la construcción de este Proyecto existe una organización claramente
definida, la cual cuenta con un Director, cinco áreas de apoyo que incluyen
Planeamiento y Control, Control de la Calidad, Gestión de la Calidad, Suministros
11
y Relaciones con la Comunidad. Existen otras cinco áreas operativas que incluyen
Obras por Contrato, Gestión Ambiental, Ingeniería, Construcción y Administración
(P.H. Pirrís, 2006).
Figura 2: Organización del P.H. Pirrís
Dadas las evidentes ventajas del Proyecto, en 1994 el Sector de Desarrollo
del ICE tomó la determinación de impulsar su ejecución y asegurar su
financiamiento por lo que se buscó la autorización de MIDEPLAN para tal fin. En
consideración se tomó su tamaño, que es lo suficientemente grande para
satisfacer el crecimiento de la demanda y a la vez de un costo manejable por la
mayoría de las agencias financieras de desarrollo (P.H. Pirrís, 2006).
12
En 1996, durante la visita del Presidente de la República a Japón, en
compañía del Ministro de Relaciones Exteriores, Dr. Fernando Naranjo y del Dr.
Roberto Dobles, Presidente Ejecutivo del ICE, el Gobierno de Costa Rica solicitó
en Tokio al Gobierno de Japón financiamiento para el Proyecto Hidroeléctrico
Pirrís. Este crédito concesional cubre hasta el 75% de la inversión total, con una
tasa de interés al 3%, un período de gracia de 10 años y un plazo de amortización
de 30 años.
El crédito del JBIC es un financiamiento en condiciones excepcionalmente
favorables para Costa Rica. Este crédito concesional cubrirá aproximadamente el
54% de la inversión total, con una tasa de interés al 2.2%, un período de gracia de
7 años y un plazo de amortización de 30 años (P.H. Pirrís, 2006).
En cuanto al recurso de Tecnologías de Información, se puede indicar que
el P.H. Pirrís representa más de un 30% del equipo existente en los Proyectos
(mas de 230 computadores), lo cual lo convierte en el Proyecto con mayor número
de usuarios hoy en día. El desarrollo de las TI en P.H. Pirrís involucra una red
compuesta por varios tipos de tecnología como lo es la Satelital, Fibra Óptica,
Inalámbrica y la convencional de cable UTP categoría 5, además ha desarrollado
significativamente la Intranet con tres grandes áreas: Información General,
Biblioteca de archivos multimedia (centro de documentación de fotografías, videos,
planos y presentaciones) y el desarrollo de un sitio de colaboración, en el cual se
crean grupos de usuarios que conforman equipos de trabajo los cuales necesitan
interactuar entre si; hablamos además de servicios de Internet, Correo Electrónico,
Sistemas de Información, Telefonía Digital (IP), servicio FTP, Sistemas de
Información Geográfica, servicio de Fax, e impresión de calidad entre otros.
13
2.2 Aspectos de la Seguridad Informática
“La seguridad absoluta tendría un costo infinito”
Anónimo
2.2.1 Que es Seguridad Informática
Los primeros conceptos de seguridad se evidencia en los inicios de la
escritura (3000 AC) donde varios autores (A.S.S. Borghello, 2001) evidencian
ciertos rasgos de la seguridad en la guerra y el gobierno.
Se puede indicar que la seguridad es una necesidad básica en la
preservación de la vida y posesiones, esta ha evolucionado dentro de las
organizaciones sociales, como por ejemplo la familia, hasta llegar a un nivel de
especialización estableciéndose inicialmente dos tipos de seguridad: La Interna y
la Externa. La Seguridad Interna es aquella que se preocupa por amenazas de
organización con la misma organización y la Seguridad Externa es aquella que se
preocupa de las amenazas de entes externos de la organización (A.S.S.
Borghello, 2001).
La seguridad moderna se originó en la Revolución Industrial para combatir
los delitos y movimientos laborales. Finalmente un teórico y pionero de la
Administración “Henry Fayol” en 1919, establece un concepto más amplio de la
seguridad, en este, Fayol se refería solo a lo físico de la instalación, ya que en
aquel momento era considerado el activo de mayor valor en la organización,
superando en valor al mismo empleado.
Hoy en día la seguridad desde el punto de vista legislativo está en manos
de políticos, quienes deciden acerca de su importancia, los tipos de delitos y su
respectivo castigo, en caso de corresponder. Desde el punto de vista técnico, la
14
seguridad está en manos de la Dirección de las Organizaciones y en última
instancia en cada uno de los usuarios, y en el grado de conocimiento y conciencia
que se tenga de la importancia de la Información en las Organizaciones. En la
actualidad existe conciencia de que los conceptos iniciales de seguridad no han
cambiado a través de la historia, mas si se han perfeccionado logrando un nivel
mayor de especialización (A.S.S. Borghello, 2001).
La seguridad es hoy en día una profesión compleja con funciones
especializadas, donde existe una interacción dinámica entre el agresor y el
protector de un valor tratado; resulta ser un problema de antagonismo y
competencia, ya que si no existe un competidor – amenaza, el problema no es de
seguridad. Lo que es definitivo es que hoy en día la seguridad se presenta por la
combinación de tres actores principalmente: Hardware, Software y las personas
donde todos interactúan y se relacionan (Ver Anexo #10, “Terrorismo Digital”).
2.2.2 La Seguridad Física
Este es una de los aspectos mas olvidados de la Seguridad Informática. En
la mayoría de los casos existe la preocupación por extremar medidas para retener
un ataque externo, como podría ser un Hacker o un virus informático. Sin
embargo, de nada valdrá todo este esfuerzo si no se toman las medidas
necesarias para prevenir o en su defecto combatir un incendio, por lo que la
seguridad integra una serie de condiciones que normalmente no se consideran o
bien, no tienen al parecer un impacto y una frecuencia alta (A.S.S. Borghello,
2001).
Esto puede implicar que eventualmente será mas sencillo para el atacante
tomar una de las cintas de respaldo de la sala de servidores, que intentar acceder
la misma información vía lógica desde la red.
15
La Seguridad Física consiste en aplicar barreras físicas y procedimientos de
control, como medidas preventivas ante amenazas de uso desautorizado de la
información de carácter confidencial. Está referida a los controles y mecanismos
de seguridad dentro y alrededor del centro de cómputo y cuartos de comunicación
o lugares donde existan equipos de infocomunicación, así como los medios de
acceso a estos sitios, implementados para proteger el Hardware y los medios de
almacenamiento de datos (A.S.S. Borghello, 2001).
Tipos de desastres que pueden implicar un no aseguramiento físico:
Incendios.
Inundaciones.
Condiciones Climatológicas.
Terremotos.
Señales de Radar.
Instalación Eléctrica y Cableado Estructurado.
Las acciones hostiles que se pueden ver desarrolladas son (A.S.S. Borghello,
2001):
Robo.
Fraude
Sabotaje
Medidas de prevención o de control de accesos:
Utilización de guardias.
Detector de metales.
Utilización de sistemas biométricos.
Seguridad con animales.
Protección electrónica.
16
2.2.3 La Seguridad Lógica
Como se sabe que el activo más importante que se posee de un sistema
informático es la misma Información, es por tanto que deben existir técnicas más
allá de la seguridad física que la aseguren. La seguridad lógica se basa en la
aplicación de barreras y procedimientos que resguardan el acceso a los datos,
donde solo se permite acceder a los datos a aquellas personas debidamente
autorizadas para hacerlo (A.S.S. Borghello, 2001).
La seguridad lógica debe impedir el acceso a todo aquello que no está
permitido y se plantea los siguientes objetivos:
Restringir el acceso a los programas y archivos.
Asegurar que los operadores puedan trabajar sin una supervisión
minuciosa y no puedan modificar los programas ni los archivos que no
correspondan.
Asegura que estén utilizados los datos, archivos y programas correctos.
Que la información transmitida sea recibida solo por el destinatario al
cual ha sido enviada y no a otro.
Que la información recibida sea la misma que ha sido transmitida.
Que existan sistemas alternativos de transmisión entre diferentes
puntos.
Que se dispongan de pasos alternativos de emergencia para la
transmisión de la información.
Medidas de prevención o de control de accesos (A.S.S. Borghello, 2001):
Identificación y Autentificación.
Definición roles.
Transacciones.
Limitación a los servicios (Internet, Correo Electrónico, FTP, entre otros).
Modalidad de acceso (lectura, escritura, ejecución, borrado, creación,
17
búsqueda o todas las anteriores).
Ubicación y horario.
Palabras clave o etiquetas de seguridad.
Control de acceso externo: Dispositivos de control de puertos, Firewall,
Contratistas o terceros.
Administración del personal y usuarios.
2.2.4 Los Intrusos
Cuando se habla de “Acceso” y “Hacer Uso”, no representan el mismo
concepto cuando son estudiados desde el punto de visto de un usuario y de un
intruso, de manera que cuando el usuario tiene acceso autorizado, implica que
tiene autorizado el uso del recurso. Sin embargo, cuando el atacante hace un uso
desautorizado, esto implica que el acceso fue autorizado (se logró el acceso y el
sistema lo permitió) (A.S.S. Borghello, 2001).
Los ataques son considerados intentos de acceso a los sistemas
informáticos. Para detectar este tipo de usos desautorizados existen una gran
variedad de herramientas las cuales en su mayoría se pueden obtener fácil y
gratuitamente en el Internet, más por otro lado de igual forma se pueden obtener
las herramientas para realizar o intentar un uso desautorizado. De un estudio
realizado en 1996 por Dan Farmer se determinó que 2/3 partes de los sistemas
existentes en Internet (Web Sites) dedicados a comercio tenían serios problemas
de seguridad (A.S.S. Borghello, 2001).
2.2.5 Amenazas Humanas
"Nadie será objeto de injerencias arbitrarias en su vida privada, su familia,
su domicilio o su correspondencia, ni de ataques a su honra o a su reputación.
Toda persona tiene derecho a la protección de la ley contra tales injerencias o
ataques." (Naciones Unidas, 1948)
18
Este apartado trata sobre cada uno de los personajes que pueden ser
potenciales atacantes de los sistemas: el mundo oculto y el personal perteneciente
a la organización.
Desde los primeros albores del hacking siempre se ha mantenido una
extraña relación entre estos particulares personajes, lo legal, lo ético y lo moral,
siendo estas características, las que sobresalen para esclarecer la diferencia entre
cada uno de los clanes existentes en la red (A.S.S. Borghello, 2001).
En el presente sólo se tratará de exponer el perfil de la persona encargada
de una de las principales amenazas, si bien no la mayor que asecha los Sistemas
Informáticos; para luego sí entrar en las formas de ataques propiamente dichos.
Hasta aquí se ha presentado al personal como víctima de atacantes
externos; sin embargo, de los robos, sabotajes o accidentes relacionados con los
Sistemas Informáticos, son un 70% causados por el propio personal de la
organización propietaria de dichos sistemas ("Inside Factor") o ex-empleados
(A.S.S. Borghello, 2001).
El siguiente gráfico detalla los porcentajes de intrusiones clasificando a los
atacantes en internos y externos.
19
Figura 3: Intrusiones. (A.S.S. Borghello, 2001).
Esto es realmente preocupante, ya que una persona que trabaje como el
administrador, el programador o el encargado de una máquina conoce
perfectamente el sistema, sus puntos fuertes y débiles; de manera que un ataque
realizado por esa persona podrá ser más directo, difícil de detectar y más efectivo
que el que un atacante externo pueda realizar (A.S.S. Borghello, 2001).
Existen diversos estudios que tratan sobre los motivos que llevan a una
persona a cometer delitos informáticos contra su organización, pero sean cuales
sean, estos motivos existen y deben prevenirse y evitarse. Suele decirse que
todos tienen un precio (dinero, chantaje, factores psicológicos, etc.), por lo que se
pueden arrastrar a robar y vender información o simplemente proporcionar acceso
a terceros.
Como ya se ha mencionado los ataques pueden ser del tipo pasivos o
activos, y el personal realiza ambos indistintamente dependiendo de la situación
concreta. Los sujetos del tipo pasivo son aquellos que cometen los delitos
informáticos, además poseen ciertas características que no evidencian el común
20
denominador del delincuente, tiene habilidades para el manejo de los Sistemas
Informáticos y generalmente por su situación laboral se encuentran en lugares
estratégicos donde se maneja la información de carácter sensible de la
Organización. Los sujetos del tipo pasivo por lo general son la victimas del delito,
normalmente es sobre este que recae la conducta de acción u omisión que realiza
el sujeto activo, estos pueden ser individuos, organizaciones, instituciones, el
gobierno, entre otros (A.S.S. Borghello, 2001).
Dentro de este espectro se pueden encontrar:
Personal Interno.
Ex-Empleado.
Curiosos.
Terroristas.
Intrusos Remunerados.
Por recomendaciones.
2.3 Generalidades sobre la Administración de Proyectos
Basándose en la Guía de Fundamentos de la Dirección de Proyectos
(PMI, 2004), se presentarán en este apartado los conceptos más relevantes sobre
la administración de proyectos que sustentan la aplicación de los mismos en el
presente trabajo. En primera instancia se realizará una descripción de cada uno de
los cinco grupos de procesos de la dirección de proyectos, y posteriormente se
realizará una descripción de las áreas de conocimiento de la Dirección de
Proyectos y se detallarán las Áreas de Gestión del Recurso Humano,
Comunicación y Riesgos, debido a que son las que se enfocarán en el PFG.
Seguidamente se refleja la correspondencia de los 44 procesos de dirección
de proyectos en los cinco Grupos de Procesos de Dirección de Proyectos y las
21
nueve Áreas de Conocimiento de la Dirección de Proyectos. Cada uno de los
procesos de dirección de proyectos requeridos se muestra en el Grupo de
Procesos en el cual se lleva a cabo la mayor parte de la actividad.
Los Grupos de Procesos de Dirección de Proyectos están relacionados por
los resultados que producen. La salida de un proceso, por lo general, se convierte
en una entrada a otro proceso o es un producto entregable del proyecto
(PMI, 2004).
Los Grupos de Procesos pocas veces son eventos discretos o que ocurren
una única vez; son actividades superpuestas que se producen con distintos
niveles de intensidad a lo largo del proyecto.
22
Cuadro 1: Procesos de Dirección de Proyectos y su correspondencia (PMI, 2004)
23
2.3.1 Administración de Proyectos
De acuerdo con lo establecido en la Guía a los Fundamentos de la
Dirección de Proyectos (PMBOK® Guide), en su apartado 1.2, un proyecto se
define como “… emprendimiento temporario realizado para crear un producto o
servicio único. Temporario significa que cada proyecto tiene un comienzo definido
y un final definido. Único significa que el producto ó servicio es diferente de alguna
manera que lo distingue de otros productos ó servicios…” (PMI, 2004).
Los procesos de la dirección de proyectos se pueden organizar en cinco grupos
principales que se detallan a continuación:
• Procesos de Iniciación, consisten en autorizar la realización del proyecto
o de alguna fase del mismo. La gestión del alcance del proyecto es el
único proceso que se incluye dentro de la planificación.
• Procesos de Planificación, consisten en la definición de los objetivos del
proyecto, y de cual será la mejor alternativa a poner en acción para
alcanzar los objetivos del proyecto (PMI, 2004).
• Procesos de Ejecución, consisten en la coordinación del personal y los
recursos necesarios para cumplir exitosamente con el plan del proyecto.
En este proceso se debe lograr desarrollar el plan de proyecto ejecutando
las actividades incluidas en el mismo. Se realizará una evaluación del
desempeño del proyecto, de modo que satisfaga los estándares de
calidad relevantes.
• Procesos de Control, consisten en asegurar el cumplimiento de los
objetivos del proyecto mediante la supervisión y medición del avance para
identificar variaciones respecto al plan y tomar las acciones correctivas
24
necesarias.
• Procesos de Cierre, consisten en formalizar la aceptación del proyecto y
la organización de un final ordenado, incluyendo la resolución de los
puntos pendientes. Y finalmente el cierre administrativo que incluye la
generación, recolección y distribución de la información para la formal
conclusión del proyecto. Se debe incluir una evaluación del proyecto y la
recopilación de las lecciones aprendidas que servirán en la planificación
de futuros proyectos (PMI, 2004).
El concepto de administración de proyectos es por lo tanto, la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades de un
proyecto para satisfacer los requisitos del mismo. La dirección de proyectos se
logra mediante la aplicación e integración de los procesos de dirección de
proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre
(PMI, 2004).
Se puede entonces hablar de un proyecto, cuando se ha identificado una
necesidad y se tiene dispuesta la fuente de fondos para satisfacer esa necesidad.
Para la administración de proyectos se debe establecer un plan, para luego
ponerlo en práctica en busca del objetivo. Pero el concepto de establecer un plan,
implica la responsabilidad de tomar todo el tiempo necesario para analizar con
detalle y precisión lo que se hará, pues esto es fundamental para el éxito del
proyecto. La administración del proyecto implica una cuidadosa supervisión para
garantizar que se avanza de acuerdo a lo planeado, haciendo todos los ajustes
necesarios oportunamente (Castillo, 2004).
2.3.2 Áreas de Conocimiento de la Administración de Proyectos
Existen nueve Áreas de Conocimiento las cuales describen los
25
conocimientos y las prácticas de la Administración de Proyectos. Estas nueve
áreas de conocimiento se describen brevemente a continuación (PMI, 2004):
Gestión de la Integración del Proyecto: permite asegurar que todos los
diferentes elementos del proyecto estén coordinados de manera apropiada.
Gestión del Alcance del Proyecto: incluye todo el trabajo necesario,
detallando qué se hace y qué no se hace, con el fin de completar en forma exitosa
el proyecto.
Gestión de Tiempo del Proyecto: contiene todos los procesos requeridos
para garantizar que el proyecto se terminará en el tiempo fijado. Existe una gran
interacción con otras áreas de conocimiento (PMI, 2004).
Gestión de Costos del proyecto: es la planificación de los recursos,
estimación de costos, asignación de presupuestos y control de costos, de tal forma
que se garantice que el proyecto se complete dentro del presupuesto aprobado.
Gestión de la Calidad del Proyecto: descripción de los procesos
requeridos para garantizar la satisfacción de las necesidades que dieron origen al
proyecto (PMI, 2004).
Gestión de los Recursos Humanos del Proyecto: descripción de todos
los procesos requeridos para garantizar un uso efectivo del personal involucrado
en el proyecto.
Gestión de las Comunicaciones del Proyecto: describe todos los
procesos requeridos para asegurar que la generación, recolección, distribución,
almacenamiento y destino final de la información se realice en tiempo y forma.
26
Gestión de Riesgos del Proyecto: describe procesos de identificación,
análisis y respuesta a los riesgos del proyecto (PMI, 2004).
Gestión de las Adquisiciones del Proyecto: procesos requeridos para la
adquisición de bienes y servicios para el proyecto.
Seguidamente se detallarán las Áreas de Conocimiento que se desarrollarán en el
PFG y que serán el aporte al conocimiento.
2.3.3 Gestión de los Recursos Humanos del Proyecto
La Gestión de los Recursos Humanos del Proyecto incluye los procesos
que organizan y dirigen el equipo del proyecto. El equipo del proyecto está
compuesto por las personas a quienes se les han asignado roles y
responsabilidades para concluir el proyecto. Si bien es común hablar de
asignación de roles y responsabilidades, los miembros del equipo deberían
participar en gran parte de la planificación y toma de decisiones del proyecto. La
participación temprana de los miembros del equipo aporta experiencia durante el
proceso de planificación y fortalece el compromiso con el proyecto. El equipo de
dirección del proyecto es un subgrupo del equipo del proyecto y es responsable de
las actividades de dirección de proyectos, tales como la planificación, el control y
el cierre (PMI, 2004).
Los procesos de Gestión de los Recursos Humanos del Proyecto incluyen lo
siguiente:
27
Planificación de los Recursos Humanos: identificar y documentar los
roles del proyecto, las responsabilidades y las relaciones de informe, así
como crear el plan de gestión de personal. Sus componentes son:
Figura 4: Planificación de los Recursos Humanos: Entradas, Herramientas y
Técnicas y Salidas (PMI, 2004).
Adquirir el Equipo del Proyecto: obtener los recursos humanos
necesarios para concluir el proyecto. Sus componentes son:
Figura 5: Adquirir el Equipo del Proyecto: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004).
Desarrollar el Equipo del Proyecto: mejorar las competencias y la
interacción de los miembros del equipo para lograr un mejor rendimiento del
proyecto. Sus componentes son:
28
Figura 6: Desarrollar el Equipo del Proyecto: Entradas, Herramientas y Técnicas,
y Salidas (PMI, 2004). 2.3.4 Gestión de las Comunicaciones del Proyecto
La Gestión de las Comunicaciones del Proyecto es el Área de Conocimiento
que incluye los procesos necesarios para asegurar la generación, recolección,
distribución, almacenamiento, recuperación y destino final de la información del
proyecto en tiempo y forma. Los procesos de Gestión de las Comunicaciones del
Proyecto proporcionan los enlaces cruciales entre las personas y la información,
necesarios para unas comunicaciones exitosas. Los directores de proyectos
pueden invertir una cantidad excesiva de tiempo comunicándose con el equipo del
proyecto, los interesados, el cliente y el patrocinador. Todas las personas
involucradas en el proyecto deben comprender cómo afectan las comunicaciones
al proyecto como un todo (PMI, 2004). Los procesos de Gestión de las
Comunicaciones del Proyecto incluyen lo siguiente:
29
Planificación de las Comunicaciones: determinar las necesidades de
información y comunicaciones de los interesados en el proyecto. Sus
componentes son:
Figura 7: Planificación de las Comunicaciones: Entradas, Herramientas y
Técnicas, y Salidas (PMI, 2004).
Distribución de la Información: poner la información necesaria a
disposición de los interesados en el proyecto cuando corresponda. Sus
componentes son:
Figura 8: Distribución de la Información: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004).
30
2.3.5 Gestión de los Riesgos
La Gestión de los Riesgos aumentan la probabilidad y el impacto de los
eventos positivos, y disminuye la probabilidad y el impacto de los eventos
adversos para el proyecto. Un riesgo de un proyecto es un evento o condición
inciertos que, si se produce, tiene un efecto positivo o negativo sobre al menos un
objetivo del proyecto, como tiempo, costo, alcance o calidad (es decir, cuando el
objetivo de tiempo de un proyecto es cumplir con el cronograma acordado; cuando
el objetivo de costo del proyecto es cumplir con el costo acordado; etc.). Un riesgo
puede tener una o más causas y, si se produce, uno o más impactos. Las
condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la
organización que pueden contribuir al riesgo del proyecto, tales como prácticas
deficientes de dirección de proyectos, la falta de sistemas de gestión integrados,
múltiples proyectos concurrentes o la dependencia de participantes externos que
no pueden ser controlados (PMI, 2004).
El riesgo del proyecto tiene su origen en la incertidumbre que está presente
en todos los proyectos. Riesgos conocidos son aquellos que han sido identificados
y analizados. Los riesgos desconocidos no pueden gestionarse de forma
proactiva, y una respuesta prudente del equipo del proyecto puede ser asignar una
contingencia general contra dichos riesgos, así como contra los riesgos conocidos
para los cuales quizás no sea rentable o posible desarrollar respuestas proactivas.
Los riesgos que son amenazas para el proyecto pueden ser aceptados si el
riesgo está en equilibrio con el beneficio que puede ser obtenido al tomarlo. Para
cada proyecto, se debe desarrollar un enfoque consistente hacia riesgo que
cumpla con los requisitos de la organización, y la comunicación acerca del riesgo y
su tratamiento deben ser abiertos y honestos. Las respuestas a los riesgos reflejan
el equilibrio percibido de una organización entre tomar y evitar los riesgos
(PMI, 2004).
31
Para tener éxito, la organización debe estar comprometida a tratar la
gestión de riesgos de forma proactiva y consistente durante todo el proyecto.
Planificación de la Gestión de Riesgos: es el proceso de decidir cómo
abordar y llevar a cabo las actividades de gestión de riesgos de un
proyecto. Es importante para garantizar que el nivel, el tipo y la visibilidad
de la gestión de riesgos sean acordes con el riesgo y la importancia del
proyecto para la organización, a fin de proporcionar recursos y tiempo
suficientes para las actividades de gestión de riesgos, y para establecer una
base acordada para evaluar los riesgos. Este proceso debe completarse en
las fases tempranas de la planificación del proyecto, dado que es crucial
para realizar con éxito los demás procesos (PMI, 2004). Sus componentes
son:
Figura 9: Planificación de la Gestión de Riesgos: Entradas, Herramientas y
Técnicas, y Salidas (PMI, 2004).
Identificación de Riesgos: determina qué riesgos pueden afectar al
proyecto y documenta sus características. Entre las personas que
participan en actividades de identificación de riesgos se pueden incluir,
según corresponda, las siguientes: el director del proyecto, los miembros
del equipo del proyecto, el equipo de gestión de riesgos (si se asigna uno),
32
expertos en la materia ajenos al equipo del proyecto, clientes, usuarios
finales, otros directores de proyectos, interesados y expertos en gestión de
riesgos. Si bien estos miembros del personal son a menudo participantes
clave de la identificación de riesgos, se debería fomentar la identificación de
riesgos por parte de todo el personal del proyecto (PMI, 2004).
La Identificación de Riesgos es un proceso iterativo porque se
pueden descubrir nuevos riesgos a medida que el proyecto avanza a lo
largo de su ciclo de vida. La frecuencia de la iteración y quién participará en
cada ciclo variará de un caso a otro. El equipo del proyecto debe participar
en el proceso para poder desarrollar y mantener un sentido de pertenencia
y responsabilidad por los riesgos y las acciones asociadas con la respuesta
a los riesgos (PMI, 2004). Sus componentes son:
Figura 10: Identificación de Riesgos: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004).
Análisis Cualitativo de Riesgos: El Análisis Cualitativo de Riesgos incluye
los métodos para priorizar los riesgos identificados para realizar otras
acciones, como lo es la Planificación de la Respuesta a los Riesgos. Las
organizaciones pueden mejorar el rendimiento del proyecto de manera
efectiva centrándose en los riesgos de alta prioridad. El Análisis Cualitativo
de Riesgos evalúa la prioridad de los riesgos identificados usando la
33
probabilidad de ocurrencia, el impacto correspondiente sobre los objetivos
del proyecto si los riesgos efectivamente ocurren, así como otros factores
como el plazo y la tolerancia al riesgo de las restricciones del proyecto
como costo, cronograma, alcance y calidad (PMI, 2004).
Las definiciones de los niveles de probabilidad e impacto, así como
las entrevistas a expertos, pueden ayudar a corregir los sesgos que a
menudo están presentes en los datos usados en este proceso. La criticidad
temporal de acciones relacionadas con riesgos puede magnificar la
importancia de un riesgo. Una evaluación de la calidad de la información
disponible sobre los riesgos del proyecto también ayuda a comprender la
evaluación de la importancia del riesgo para el proyecto (PMI, 2004). Sus
componentes son:
Figura 11: Análisis Cualitativo de Riesgos: Entradas, Herramientas y Técnicas, y
Salidas (PMI, 2004).
Planificación de la Respuesta a los Riesgos: Es el proceso de
desarrollar opciones y determinar acciones para mejorar las oportunidades
y reducir las amenazas a los objetivos del proyecto. Incluye la identificación
y asignación de una o más personas (el “propietario de la respuesta a los
riesgos”) para que asuma la responsabilidad de cada respuesta a los
riesgos acordada y financiada (PMI, 2004).
34
La Planificación de la Respuesta a los Riesgos aborda los riesgos en
función de su prioridad, introduciendo recursos y actividades en el
presupuesto, cronograma y plan de gestión del proyecto, según sea
necesario.
Las respuestas a los riesgos planificadas deben ser congruentes con
la importancia del riesgo, tener un coste efectivo en relación al desafío, ser
aplicadas a su debido tiempo, ser realistas dentro del contexto del proyecto,
estar acordadas por todas las partes implicadas, y a cargo de una persona
responsable. A menudo, es necesario seleccionar la mejor respuesta a los
riesgos entre varias opciones (PMI, 2004).
La sección Planificación de la Respuesta a los Riesgos presenta los
enfoques comúnmente usados para planificar las respuestas a los riesgos.
Los riesgos incluyen las amenazas y las oportunidades que pueden afectar
al éxito del proyecto, y se discuten las respuestas para cada una de ellas
(PMI, 2004). Sus componentes son:
Figura 12: Planificación de la Respuesta a los Riesgos: Entradas, Herramientas y
Técnicas y Salidas (PMI, 2004).
35
Seguimiento y Control de Riesgos: El Seguimiento y Control de Riesgos
es el proceso de identificar, analizar y planificar nuevos riesgos, realizar el
seguimiento de los riesgos identificados y los que se encuentran en la lista
de supervisión, volver a analizar los riesgos existentes, realizar el
seguimiento de las condiciones que disparan los planes para contingencias,
realizar el seguimiento de los riesgos residuales y revisar la ejecución de
las respuestas a los riesgos mientras se evalúa su efectividad. El proceso
Seguimiento y Control de Riesgos aplica técnicas, como el análisis de
variación y de tendencias, que requieren el uso de datos de rendimiento
generados durante la ejecución. El proceso Seguimiento y Control de
Riesgos, así como los demás procesos de gestión de riesgos, es un
proceso continuo que se realiza durante la ejecución (PMI, 2004). Otras
finalidades del proceso Seguimiento y Control de Riesgos son determinar
si:
Las asunciones del proyecto aún son válidas.
El riesgo, según fue evaluado, ha cambiado de su estado anterior, a
través del análisis de tendencias.
Se están siguiendo políticas y procedimientos de gestión de riesgos
correctos.
Las reservas para contingencias de coste o cronograma deben
modificarse para alinearlas con los riesgos del proyecto.
.
36
Figura 13: Seguimiento y Control de Riesgos: Entradas, Herramientas y Técnicas
y Salidas (PMI, 2004).
2.4 Antecedentes del problema
El ICE, como institución estatal, ha demostrado ser altamente eficiente en la
investigación, desarrollo y aplicación de nuevas tecnologías en sus objetivos
estratégicos. Las grandes necesidades en el campo de energía del país son
atendidas por medio de la Unidad Estratégica de Negocios Proyectos y Servicios
Asociados (UEN – P y SA), la cual se encarga de desarrollar las investigaciones
necesarias para la explotación de los recursos hidráulicos que posee el país, como
actividad principal, desarrollando otras explotaciones en fuentes no tradicionales.
Para esto se cuenta por ejemplo con una serie de Proyectos de Generación que
luego se convertirán en Plantas Eléctricas conectadas al sistema nacional de
electrificación.
Es en estos procesos constructivos donde se aplican los avances
tecnológicos existentes los cuales permiten desarrollar construcciones de tales
magnitudes. Sin embargo, muchas actividades consideradas como parte de la
tecnología blanda, no han recibido el apoyo e impulso necesario, y aun tratándose
de actividades constantemente repetitivas, no se han dedicado los recursos y la
atención suficientes, para lograr capitalizar lo aprendido en cada una de ellas.
37
Como parte de la tecnología blanda comentada anteriormente se tiene a la
administración del recurso humano, el cual inicia el proceso con una solicitud de
requerimientos. Esta solicitud es recibida por TI, en donde se realizan todos los
trámites necesarios para establecer el perfil del respectivo usuario. Seguido de
este proceso, el trámite se traslada a diferentes dependencias (Dirección,
Recurso Humano, Jefaturas de Área), hasta consolidar una estructura de servicios
requeridos en algún momento por los usuarios de TI en el Proyecto.
Para ninguno de los procesos realizados existen expedientes, debidamente
documentados, a los cuales se pueda recurrir para aprender y mejorar en futuros
sucesos, por lo que proponer una metodología que mejore el conocimiento,
registro y conducta del usuario en aspectos de seguridad informática, es una
necesidad que tienen los Proyectos actualmente.
38
3 Marco Metodológico
Para conseguir una prevención efectiva del uso desautorizado de la
información se requiere en primer lugar un análisis objetivo de las necesidades de
protección y de las fuentes de peligro junto con las debilidades que podrían estar
presentes en materia de Recurso Humano y Comunicaciones.
Basados en lo expuesto en el marco teórico, se debe usar métodos de
investigación adecuados, que permitan obtener resultados que se conviertan en
una solución viable y factible de los diversos procesos de la SIBC. Por esta razón,
en el siguiente apartado se definen los métodos que se han elegido para ser
utilizados en la recopilación y análisis de la información, y la forma en que se
aplicarán.
3.1 Definición del tipo de estudio
La investigación se fundamentó en un estudio de campo, con el fin de
recoger la información existente sobre el procedimiento seguido en la actualidad
por los Proyectos de la UEN PySA, para llevar a cabo una adecuada SIBC. La
totalidad de la información será recopilada de los involucrados directos del
presente trabajo, particularmente de los encargados y colaboradores cercanos de
TI de los Proyectos y una muestra representativa por área de los usuarios del
equipo informático en los mismos Proyectos.
Con este panorama, se ha definido colectar la información con parte de los
involucrados directos, para determinar la condición actual, y luego realizar una
propuesta de optimización por medio de Métodos de Planificación, considerando
las tres áreas de conocimiento a desarrollar (Gestión de Recursos Humanos,
Comunicaciones y Riesgos). El resto de los involucrados no serán sujeto de
estudio, pues no están dentro del alcance definido para esta investigación.
39
3.2 Fuentes de información
Toda la información será colectada de fuentes primarias, compuestas por
los involucrados directos en el proceso, más investigación bibliográfica.
3.3 Sujetos de la investigación
El presente trabajo se desarrollará con cinco proyectos meta: Proyecto
Hidroeléctrico Pirrís, Proyecto Hidroeléctrico Cariblanco, Proyectos de Transmisión
Regiones Huetar y Brunca, Proyecto Geotérmico las Pailas y Centro de Apoyo a
Proyectos (con sus Proyectos adscritos). Estos son los proyectos de mayor
importancia de la UEN PySA, en cada uno de ellos se ha seleccionado a
miembros del área de Tecnologías de información para ser entrevistados, de cada
TI se ha seleccionado a su Jefatura, a un programador y un técnico en soporte,
en total 3 personas de TI por Proyecto para aplicar una entrevista; por otro lado
se aplicará una encuesta a 30% de los usuarios de TI en cada proyecto, este 30%
es relativo al peso de usuarios que tiene cada área dentro del proyecto, la
selección del mismo no fue selectiva, por el contrario fue al azar, aplicando una
fórmula a una lista de usuarios en Microsoft Excel llamada Aleatorio(), la misma
establece un valor para cada uno de los usuarios, la cual luego fue ordenada de
mayor a menor, seleccionando el 30% del total de la lista, de esa manera se
garantizará que la muestra es lo suficientemente representativa e imparcial de los
usuarios del Proyecto, en la misma se encontrará a profesionales, administrativos,
técnicos y personal operativo (inspectores, secretarias, asistentes).
3.4 Etapas de la aplicación
Inicialmente se realizará una investigación de campo (Muñoz, 1998), para lo
cual se seleccionaron dos herramientas para la consecución de la información, las
cuales son la entrevista cualitativa y la encuesta. Posteriormente se desarrollarán
los Métodos para la Gestión de Recursos Humanos, Comunicaciones y Riesgos,
40
esto será parte del producto final a entregar junto con el análisis de la
investigación de campo.
3.4.1 Descripción y uso de las Herramientas de Campo
3.4.1.1 Entrevista Cualitativa
Es la recopilación de información en forma directa, cara a cara, es decir, el
entrevistador obtiene datos del entrevistado siguiendo una serie de preguntas
preconcebidas y adaptándose a las circunstancias que las respuestas del
entrevistado le presenten (Muñoz, 1998).
El proceso involucra al menos cuatro etapas: Apertura: Es donde se inicia la entrevista a través de una presentación
breve explicando el objetivo de la misma y solicitando la
cooperación del entrevistado para que proporcione la información
requerida.
Iniciación: Conocida como el inicio de la entrevista y es donde el
entrevistador comienza el interrogatorio con preguntas breves,
simples y de sondeo, a fin de obtener posibles respuestas que den
estructura a la conversación (Muñoz, 1998).
Cima: Es la parte de la entrevista donde se obtiene información medular
para la investigación, la cual se va propiciando con forme se gana
interés en el tema objeto de la entrevista.
Cierre: Finalización de la entrevista, en este punto se debe agradecer la
participación del entrevistado y se da la libertad de agregar algo
41
que pueda complementar los datos recabados. También en esta
etapa es posible obtener información de utilidad (Muñoz, 1998).
Respecto al tipo de preguntas que se pueden plantear: Preguntas abiertas: es donde el entrevistado tiene libertad absoluta de
expresar su opinión con respecto a la pregunta que se le formula.
Preguntas de tipo cerrado: Son preguntas que limitan, concentran y
dirigen las respuestas del entrevistado hacia el tema básico
(Muñoz, 1998).
Preguntas de sondeo: Preguntas que sirven para determinar el medio en
que se desenvuelve el entrevistador, el entrevistado, las preguntas
y toda la entrevista.
Preguntas de cierre: Poco antes de concluir la entrevista es importante
realizar las llamadas preguntas de cierre, las cuales se formulan
para terminar el cuestionamiento (Muñoz, 1998).
Preguntas mixtas: Es la combinación de dos o más formas anteriores
tratando de hacer más ágil y eficiente la entrevista.
3.4.1.1.1 Requerimientos para el ejercicio
1. Hacer una selección de los participantes a estas entrevistas, será el
primer paso del proceso. Todos estos entrevistados serán miembros de
las TI de cada Proyecto de la UEN PySA, pues se busca un panorama
completo de los procesos involucrados en la presente investigación y
42
detallados en el PMBOK (PMI, 2004); desde el punto de vista de
usuarios avanzados de equipo informático, se realizará un cuestionario
para cada tema en específico (Recursos Humanos, Comunicaciones y
Riesgos), con el objetivo de profundizar en forma separada en cada uno
de ellos. La intención de conocer el escenario completo, se debe a que
es difícil lograr una total comprensión del concepto de SIBC, si no se
tienen claro las actividades, involucrados, normativas y un adecuado
nivel de conocimiento en referencia al tema.
2. Establecer una comunicación con cada entrevistado, con el fin de
explicar los alcances del ejercicio y lograr la empatía requerida de los
involucrados con la investigación, y desde luego con el producto final.
3. Desarrollar un formulario con preguntas que abarquen todos los
procesos de cada área a desarrollar en la investigación, este formulario
debe contener la lista de preguntas y de acuerdo a estas se debe
establecer un mecanismo de valoración de la entrevista de manera que
permita ubicar a la misma en una escala de 0 a 100 por ciento, siendo el
puntaje meta establecido no menor a un 80%, ya que se estima que
este nivel es alcanzable por todos los proyectos utilizando los recursos
con los que actualmente cuenta, sin que este represente una inversión
adicional que impacte en el presupuesto del Proyecto. Los proyectos
que de su promedio de entrevistas obtengan un porcentaje menor al
50%, serán considerados casos críticos y deberán emplear a fondo la
metodología a desarrollar en el presente trabajo, en estos casos se
estima que el personal es sumamente riesgoso para la organización e
institución, ya que con un mínimo esfuerzo han desarrollado la SIBC en
sus Proyectos, encontrándose sumamente expuestos a desastres
informáticos en cualquier momento.
43
4. Asegurarse que las los entrevistados representen a las áreas de TI de la
siguiente manera: El Administrador de TI, Soporte Técnico y Desarrollo
de Sistema de Información (un representante en cada caso), la cantidad
final de entrevistados por Proyecto será de tres personas.
5. Concertar las citas y realizar las entrevistas.
3.4.1.1.2 Procedimiento para el ejercicio
1. Se debe programar con al menos 8 días de anticipación la cita de la
entrevista.
2. Se deberá coordinar una sala adecuada para la realización de la
entrevista, en el lugar de trabajo del entrevistado.
3. La entrevista será desarrollada de manera individual.
4. Procurar que la misma no se extienda por más de una hora.
5. Una vez realizadas todas las entrevistas, se procederá a tabular y
estructurar toda la información colectada, esto se hará en Microsoft
Excel, dada la facilidad que presenta este software para el análisis
estadístico de información, permitiendo la graficación de los datos y
resultados obtenidos en forma sencilla y dinámica; además de la
integración con Microsoft Word y el mismo Microsoft Power Point,
6. Con el puntaje final obtenido, analizar la información y documentar.
44
3.4.1.2 Encuesta
Otras de las técnicas utilizadas en el desarrollo de la investigación, es el
levantamiento de información mediante encuestas, donde estas pueden ser de
opinión, comportamiento, de actuación o de cualquier otro razonamiento digno de
evaluar. La encuesta es una recopilación de datos concretos, dentro de un tópico
de opinión específico, mediante el uso de cuestionarios o entrevistas, con
preguntas y respuestas precisas que permiten hacer una rápida tabulación y
análisis de dicha información (Muñoz, 1998).
No existen reglas para el uso de las encuestas, estas deben ser ágiles y
sencillas en sus preguntas para que las respuestas sean concretas y centradas
sobre el tópico en cuestión, esto hará que la tabulación de la información sea más
sencilla y por consecuencia su análisis e interpretación resulten más fáciles
(Muñoz, 1998).
Las encuestas se clasifican de la siguiente manera:
Por la forma de capturar la información:
Escritas: La información se recopila mediante algún cuestionario y el
encuestado anota sus respuestas con puño y letra.
Verbales: La información se obtiene mediante la opinión verbal
(Muñoz, 1998).
Grabadas: Las opiniones verbales son registradas en algún medio
electromagnético o digital para posteriormente se reproducidas.
45
Por la forma de realizarlas: Dirigidas: Es donde se induce la opinión del entrevistado al tema en
concreto.
No dirigidas: La encuesta se conduce libremente (Muñoz, 1998).
Por el universo que abarcan:
Individuales: Se realiza de uno en uno de los entrevistados.
Grupales: Son aquellas que se aplican a un grupo específico de individuos
(Muñoz, 1998).
Por la forma de tratar la obtención de los datos:
Unidas: Interrogatorio que liga una a una las posibles respuestas a fin de
obtener una secuencia de aportación.
Transversales: Las preguntas se cruzan entre sí para obtener la veracidad
en las respuestas (Muñoz, 1998).
Por el manejo de la información:
De panel: Permiten ir centrando la opinión sobre un tópico en especial.
De análisis: Permiten comprobar con un análisis previo, las opiniones de
supuestos expertos contra las aportaciones de los
encuestados (Muñoz, 1998).
46
3.4.1.2.1 Requerimientos para el ejercicio
1. Hacer una selección de los participantes a esta encuesta, será el
primer paso del proceso. Todos estos encuestados serán usuarios
finales de equipo informático de cada Proyecto, se realizará un
cuestionario para cada tema en específico (Recursos Humanos,
Comunicación y Riesgos), con el objetivo de profundizar en forma
separada en cada uno de ellos. Con la intención de conocer una
situación cercana a la realidad, la muestra por cada Proyecto será
proporcional a una cantidad de personas que tengan como usuarios
de equipos informáticos.
2. Establecer una comunicación con cada Administrador de TI de cada
Proyecto, con el fin de explicar los alcances del ejercicio y lograr la
empatía requerida para la aplicación de la encuesta en cada
Proyecto; además de lograr la capacidad del Administrador de TI,
para atender cualquier interrogante respecto a la encuesta que
pueda surgir por parte de los encuestados, esto permitirá una
adecuada atención y seguimiento de la misma.
3. Desarrollar un formulario con preguntas que abarquen todos los
procesos de cada área a desarrollar en la investigación, este
formulario debe contener la lista de preguntas y de acuerdo a estas
se debe establecer un mecanismo de valoración de la encuesta de
manera que permita ubicar a la misma en una escala de 0 a 100 por
ciento, siendo el puntaje meta establecido no menor a un 80%, los
proyectos que de su promedio de encuestas obtengan un porcentaje
menor al 50%, serán considerados casos críticos y deberán emplear
47
a fondo la metodología a desarrollar en el presente trabajo.
4. Asegurarse que los encuestados representen a todas las áreas del
Proyecto.
5. La cantidad de usuarios a encuestar no superará el 30% del total de
usuarios existentes en cada Proyecto.
6. El porcentaje que represente la cantidad de usuarios por área del
total del Proyecto, será al que se aplicará el 30% de la muestra meta
del presente estudio.
7. Concertar las citas y aplicar las encuestas.
3.4.1.2.2 Procedimiento para el ejercicio
1. Se debe programar con al menos 8 días de anticipación la cita de la
encuesta.
2. La encuesta se hará vía Correo Electrónico, se dará un seguimiento
riguroso a la atención de la misma por parte de los encuestados y
además se será enérgico con la fecha de entrega de la misma.
3. La encuesta será desarrollada de manera individual.
4. Procurar que la misma le tome a lo sumo 15 minutos en ser llenada a
cada encuestado.
5. Una vez llenas todas las encuestas, se procederá su recopilación,
tabulación y estructuración de toda la información colectada.
48
6. Con el puntaje final obtenido, analizar la información y documentar.
3.4.2 Desarrollo de Métodos de Gestión
Los métodos a desarrollar seguidamente toman como base herramientas de
Administración de Proyectos propuestas en los Libros de: Chamoun (2002) y el
PMI (2004).
3.4.2.1 Método para la planificación del Recurso Humano
Tiene como objetivo lograr el mayor desempeño de las personas
participantes en el proyecto. Con la aplicación de esta metodología, el Gerente del
Proyecto tiene la autoridad y responsabilidad requeridas para administrar el
proyecto, lo que facilita la atención de clientes así como la solución de problemas.
La Matriz de Roles y Funciones es una de las herramientas que ayudan a Integrar
al Recurso Humano, ya que es frecuente encontrar colaboradores en las
empresas que participan continuamente en los proyectos, sin lograr una
integración adecuada de sus funciones para el bien del equipo y de la empresa. Al
momento de presentarse los problemas, no existe la rendición de cuentas en el
proyecto, nadie asume el compromiso y la responsabilidad que finalmente recae
en la Dirección del Proyecto. La Matriz de Roles y Funciones es una herramienta
que ayuda a planear y lograr una adecuada integración, esta permite confirmar
con los involucrados dónde es requerido que se apliquen sus conocimientos y
habilidades con el fin de lograr el mejor aprovechamiento del equipo (Chamoun,
2002).
La Matriz de Roles y Funciones logra integrar a los involucrados en el
Proyecto y asegura la distribución adecuada de roles (¿quien hace que?) y
funciones (¿quien decide qué?). Además incluye todo el trabajo expuesto en la
49
EDT y las personas clave, sus roles y funciones. Se desarrolla elaborando una
matriz donde en la columna de la izquierda se incluyen todos los entregables de la
EDT y en el encabezado de la matriz los nombres de los involucrados, en cada
una de las celdas se incorpora el rol o la responsabilidad, la definición de roles se
puede adaptar a los requerimientos personales o de la empresa, siempre que se
logre una efectiva comunicación. Esta técnica se puede emplear durante el
desarrollo de Plan de Gestión y se debe actualizar a lo largo del Proyecto
(Chamoun, 2002).
El uso de esta técnica demanda de la utilización del Microsoft Excel, como
medio para lograr documentar la matriz de roles y funciones, además de ser un
mecanismo de actualización eficiente y sencillo de utilizar.
3.4.2.2 Método para la Planificación de las Comunicaciones
La administración de las comunicaciones tiene como objetivo el lograr una
efectiva comunicación entre los involucrados asegurando la oportuna y apropiada
generación, recolección, distribución, archivo y disposición final de la información
del Proyecto. La cantidad de información que se transmite dependerá en gran
medida de los clientes o de la naturaleza de cada Proyecto, por lo que es
necesario planear tanto los contenidos y la frecuencia, como considerar las
personas involucradas en las comunicaciones del Proyecto (Chamoun, 2002).
La matriz de Comunicación sirve para mantener informados a los
involucrados y asegurar una comunicación efectiva. Facilita la toma oportuna de
decisiones y la tranquilidad de los involucrados clave. Incluye las lista de reportes
de avance y contenidos, documentos de planeación relevantes y contenidos, lista
de distribución, periodicidad de la distribución, medio de distribución y el
responsable de emitir el reporte. Se desarrolla colocando en la primera columna
50
de la izquierda, a los involucrados relevantes por empresa y departamento, y en la
segunda columna su rol, luego se debe incluir en el encabezado restante el tipo de
reporte y su periodicidad, se debe definir una simbología a emplear para facilitar
la interpretación de la matriz y de esta manera se señala quien genera la
información. Esta herramienta puede ser utilizada durante la planeación siendo
actualizada a lo largo del Proyecto (Chamoun, 2002).
El uso de esta técnica demanda de la utilización del Microsoft Excel, como
medio para lograr documentar la matriz de roles y funciones, además de ser un
mecanismo de actualización eficiente y sencillo de utilizar.
3.4.2.3 Método para la Planificación de los Riesgos
La administración del riesgo pretende reducir la repercusión negativa de
riesgos en los proyectos, identificando las oportunidades por lograr y las
amenazas por controlar, se puede establecer un plan de manejo de riesgos, con
sus respectivos responsables. La esencia de la administración del riesgo está en
prever continuamente posibles problemas para llevar a cabo acciones a tiempo, en
lugar de improvisar y buscar soluciones tardías (reactivos). Considerando que el
riesgo se determina por la probabilidad de que un hecho ocurra, por el impacto
que este genera, es que se debe identificar y cuantificar riesgos definiendo que
amenazas controlar y que oportunidades hay que aprovechar. (Chamoun, 2002).
Se deben incluir la identificación de los riesgos, las oportunidades a
aprovechar, las cuantificaciones o la valoración del riesgo y una definición de las
amenazas por aprovechar. Se debe desarrollar un mapa por medio del apoyo de
expertos, utilizando un mapa mental para documentar la información, además se
debe asignar a cada riesgo un valor de 1 a 5 en función de la probabilidad de que
51
suceda (1 = poco probable, 5 = es muy probable), de igual forma asignar al riesgo
un valor de 1 a 5 en función del impacto que tendría en caso de presentarse (1 =
bajo y 5 = alto), luego de esto se debe multiplicar el impacto por la probabilidad
para definir las actividades que tendrán prioridad en la atención y seguimiento,
para lo cual se elabora la Matriz de Administración de Riesgos, esta matriz
ayudará a desarrollar respuestas y asignar responsables para el manejo de
riesgos, la misma contiene las posibles repuestas, un plan de acción y una
identificación del responsable de administrar el riesgo (Chamoun, 2002).
El uso de esta técnica demanda de la utilización del Mind Manager, como
medio para lograr documentar el mapa de riesgos y el Microsoft Excel, como
medio para lograr documentar la probabilidad y el impacto de cada uno de los
riegos identificados, además de ser un mecanismo de actualización eficiente y
sencilla de utilizar.
52
4 Diagnóstico de la SIBC en Proyectos
4.1 Mecanismo de valoración de las herramientas aplicadas
Se ha definido una metodología o mecanismo de valoración para las
herramientas aplicadas en la presente investigación, en dicho mecanismo se
destaca el valor deseable que por respuesta se debería tener en cada una de las
herramientas, dependiendo del área de conocimiento que fue evaluada, y se
detalla para el caso de las entrevistas (Anexo 8) de la siguiente manera:
Cuadro 2: Tabla de valoración de las Entrevistas.
Tabla de valoración para las Entrevistas Respuesta Deseable # de Pregunta
Area de Rec. Humano Area de Comunicación Area de Riesgo 1 SI SI NUNCA 2 NO SI NUNCA 3 SI POSITIVO + SI 4 NO SEGURIDAD NUNCA 5 NO SI SI 6 SI SI SI 7 SI SIEMPRE SIEMPRE 8 NO SI 9 NO
10 SI 11 SI 12 SI 13 SI 14 NO 15 NO 16 SI
SubTotal 16 7 8
TOTAL 31
La entrevista plantea las preguntas a un nivel donde se presume que
cualquier funcionario de TI podrá entenderlas, estas pueden ampliarse en su
53
definición o interpretación con la explicación que cada pregunta solicita a la hora
de ser planteada, lo que permite que el entrevistado complete su respuesta.
En el siguiente cuadro se presenta un detalle del mismo mecanismo de
valoración empleado en las entrevistas, con la variante de que se aplica a la
herramienta de la encuesta (Anexo 9), con el correspondiente valor deseable que
por respuesta se debería tener ahora para el caso de la encuesta:
Cuadro 3: Tabla de valoración de las Encuestas.
Tabla de valoración para las Encuestas Respuesta Deseable # de Pregunta
Area de Rec. Humano Area de Comunicación Area de Riesgo 1 SI SI NO 2 NO NO NO 3 SIEMPRE NUNCA SI 4 NO SI NO 5 NO NO SI 6 SI SI 7 SI 8 NO 9 NO
10 SI 11 SI 12 SI 13 SI 14 NO
SubTotal 14 6 5
TOTAL 25
Al igual que para las entrevistas, se debe acotar que se consideró el detalle,
comentario o explicación brindada en cada unos de los espacios definidos para
este fin dentro de la herramienta, esto necesariamente influenció en la calificación
final de cada una de las respuestas brindadas. La encuesta se presenta en un
lenguaje más simple de manera que sea de fácil interpretación por parte de los
usuarios o encuestados, consta de 6 preguntas menos que la entrevista, esto
54
porque algunas preguntas fueron eliminadas ya que no son del dominio o
conocimiento del usuario, mas si del funcionario de TI.
4.2 Resultado del estudio desarrollado.
Luego de la calificación o evaluación de cada una de las herramientas, de
acuerdo a las tablas de valoración de resultados deseables en las respuestas
dadas, se obtiene la siguiente situación:
La entrevista, como primer método de colecta de información, se basó en
un sencillo formulario, presentado en el Anexo 8, el cual se aplicó de manera
individual a cada uno de los integrantes del grupo seleccionado, compuesto por
tres personas que pertenecen al departamento de TI (Encargado, Soportista y
Desarrollador), con el objetivo de establecer un nivel de conocimiento de las
personas que se presume, son las llamadas a desarrollar el concepto y el
conocimiento en el resto de los usuarios del Proyecto, la meta fue desarrollar la
entrevista en cinco Proyectos, a decir: Proyecto Hidroeléctrico Pirrís, Proyecto
Hidroeléctrico Cariblanco, Proyecto de Transmisión Huetar Brunca, Proyecto
Geotérmico las Pailas y Centro de Apoyo a Proyectos (con sus Proyectos
adscritos).
La entrevista se desarrolló tomando como base las tres áreas de
conocimiento a estudiar: Recurso Humano, Comunicación y Riesgo, para cada
una de estas áreas se plantearon una serie de preguntas, 31 en total, las cuales
permitirán obtener un estado de la SIBC de cada uno de los proyectos donde se
aplicó, es importante aclarar que la población meta de aplicación varió en dos
Proyectos, ya que el personal de TI de los mismo es reducido, en dicho caso
solamente fue posible aplicarlo a dos miembros de TI (caso de P. G. Pailas y
PTRHB), por esta razón se toma la decisión de aumentar la cantidad de muestras
55
para el caso de P.H. Pirrís, llegando a realizar 5 entrevistas en este Proyecto.
La aplicación de las entrevistas generó como resultado una interesante
situación en los Proyectos donde fue aplicada, y para esto es necesario observar
el siguiente gráfico:
Figura 14: Comparación de la SIBC de las Entrevistas, en los Proyectos
Evaluados.
Se debe recordar que la meta propuesta para la evaluación es de un
mínimo de 80% y aquellos que califiquen menores a 50% se consideran casos
críticos; de la gráfica se puede obtener que las TI de los diferentes Proyectos en
términos generales manejan un nivel relativamente bajo de la SIBC, esto es
preocupante ya que es TI la dependencia llamada a difundir y educar al resto del
personal en la SIBC, sin embargo no podemos esperar una adecuado formación
56
de los usuarios que el formador (TI) no se encuentra identificado con este
concepto.
En promedio se identifica que el PTRHB es el proyecto a nivel de TI que
mejor maneja el concepto de SIBC y el P.H. Cariblanco es el de menor nivel muy
cercano al 50% (53%) que establece un nivel preocupante en el conocimiento que
maneja esta TI de la SIBC.
El caso de la encuesta, como segundo método de colecta de información,
se basó en un sencillo formulario, presentado en el Anexo 9, el cual se entregó de
manera individual a cada uno de los integrantes del grupo seleccionado en cada
Proyecto, el cual estuvo compuesto por el 30% de los usuarios de equipos de
cómputo, con el objetivo de establecer un nivel de conocimiento de las personas
que utilizan día a día los equipos como parte de su quehacer y sus funciones
(usuarios finales) dentro del Proyecto, la meta fue desarrollar la encuesta en cinco
Proyectos, a decir: Proyecto Hidroeléctrico Pirrís, Proyecto Hidroeléctrico
Cariblanco, Proyectos de Transmisión Huetar Brunca, Proyecto Geotérmico las
Pailas y Centro de Apoyo a Proyectos (con sus Proyectos adscritos).
La encuesta se desarrolló tomando como base las tres áreas de
conocimiento a estudiar: Recurso Humano, Comunicación y Riesgo, para cada
una de estas áreas se plantearon una serie de preguntas, 25 en total, las cuales
permitirán obtener un estado de la SIBC de cada uno de los proyectos donde se
aplicó, es importante aclarar que la población meta de aplicación varió en algunos
proyectos no obteniéndose el total de las encuestas llenas por parte del usuario;
sin embargo el porcentaje de encuestas no entregados no es significativo para
efectos de los resultados obtenidos, además esta situación desde un inicio se
sabía que se podía presentar, para combatir esto, el papel que desempeñaron los
encargados de TI de cada uno de los Proyectos fue crucial para que este hecho
no impactara los resultados del presente estudio.
57
La aplicación de las encuestas generó como resultado una interesante
situación en los Proyectos donde fue aplicada, y para esto es necesario observar
el siguiente gráfico:
Figura 15: Comparación de la SIBC de las Encuestas, en los Proyectos
Evaluados.
De la gráfica se puede obtener que los usuarios de equipo informático de
los diferentes Proyectos, en términos generales manejan un nivel relativamente
bajo de la SIBC, esto es igualmente preocupante ya que, éste es el primer y más
sencillo paso para poder ingresar a la red Institucional del ICE, y al existir un bajo
conocimiento e identificación con la SIBC se puede pensar que la red de datos de
la organización se encuentra en un alto riesgo de sufrir un ataque.
58
En promedio se identifica que el PTRHB es el proyecto que tiene mayores
problemas de SIBC de los Proyectos evaluados y el P.H. Pirrís es el de mayor
nivel muy cercano al 80% (77%) que establece un nivel adecuado en el
conocimiento que deben manejar los usuarios acerca de la SIBC, es evidente que
cuando se habla del tema de seguridad entre los usuarios, se crea un ambiente un
poco tenso, mas la herramienta presenta una ventaja evidente, donde se permite
la expresión de situaciones reales, por lo que los resultados obtenidos de la
aplicación de la herramienta son de gran valor en la presente investigación.
Ahora se puede apreciar una comparación del nivel obtenido de la SIBC,
entre los empleados de los departamentos de TI y el resto de usuarios de los
equipos de cómputo de los Proyectos:
Figura 16: Comparación de la SIBC entre las Entrevistas y las Encuestas.
59
Desde esta perspectiva, es interesante saber que los usuarios de equipos
de cómputo tienen un mayor nivel de SIBC que los mismos empleados de TI, esto
es poco lógico que se presente ya que es suponer que TI es el llamado a divulgar
y promover un adecuado conocimiento y capacitación en el tema de Seguridad
Informática, esto revela que la capacitación debe empezar por el mismo TI antes
de proceder con la capacitación del resto de los usuarios.
Ahora analizaremos los resultados obtenidos en términos generales, se
promediarán los resultados de las entrevistas y las encuestas, esto evidenciará
otra serie de resultados interesantes, como lo muestra la siguiente gráfica:
Figura 17: Comparación de la SIBC por área y por Proyecto.
60
De lo anterior se observa que ningún proyecto superó la meta propuesta al
inicio de esta investigación, lo que confirma la preocupación existente hasta el
momento de que existe un bajo nivel de Seguridad Informática en los Proyectos de
la UEN PySA, esto justifica la creación e implementación de metodologías que
fortalezcan este concepto en todos los usuarios de equipos informáticos, es
importante también tener presente que ningún Proyecto se encuentra en peligro
extremo (inferior al 50%) por lo que los casos no merecen ser tratados en un
estado de emergencia o de alta prioridad.
Finalmente, tenemos otro gráfico que promedia los resultados de todos los
proyectos por área, lo que genera la siguiente situación:
Figura 18: Concepto de SIBC por área, en los Proyectos de la UEN PySA.
61
En términos generales los Proyectos de la UEN PySA, manejan un nivel de
SIBC bajo, ya que lo menos esperado debió ser un 80%, esto definitivamente
justifica la implementación de una estrategia (metodologías) que mejoren en un
mediano plazo el conocimiento de los usuarios en términos del seguridad
informática, la acción no merece ser desarrollada en un corto plazo ya que los
niveles obtenidos no son inferiores al 50%, lo que indica que la situación que en la
actualidad se presenta no es crítica. Al permitir la situación actual desarrollar
planes de mediano y largo plazo, se generará un mecanismo de mayor impacto y
durabilidad, con un carácter de permanencia en los usuarios que conozcan y
participen de estas metodologías.
4.2.1 Conclusiones del estudio
Como resultado de la aplicación del las herramientas se obtuvieron un total
de 10 ideas, las cuales, para efecto de un máximo aprovechamiento, se resumen
de la siguiente manera:
1. En los Proyectos de la UEN PySA existe un bajo nivel de conocimiento acerca
de las Seguridad Informática, tanto para los empleados de Tecnologías de
Información como para los usuarios en general de equipos informáticos.
2. Los empleados de Tecnologías de Información de los Proyectos fueron los que
mas bajos salieron en la evaluación del conocimiento en cada una de las áreas
meta del presente estudio, y dado que en la actualidad son las personas
llamadas a difundir y fortalecer el concepto de seguridad informática en los
Proyectos, son los que primeramente deben atender y conocer la metodología
que se desarrolla en los capítulos siguientes del presente trabajo. Ahora esto
refleja un exceso de confianza basado en el conocimiento que cada uno de los
empleados tiene del tema, lo cual no sucede con quienes son usuarios, pues
62
generalmente ante algún incidente el usuario desconoce la mayoría de lo que
está detrás del software y hardware.
3. A falta de una adecuada estructuración y orden en los procesos de formación
de los usuarios, existe en términos generales un bajo nivel de conocimiento
respecto a la seguridad informática en los Proyectos.
4. Se justifica la creación de metodologías que permitan una adecuada
estructuración de los procesos formadores de manera que el usuario asuma
una conducta deseable de seguridad informática, producto del conocimiento
adquirido.
5. No está clara la existencia de un verdadero responsable del proceso formador
del conocimiento de seguridad informática en los Proyectos.
6. No existe un proceso de seguimiento y control del conocimiento que los
usuarios tienen acerca de la seguridad, de forma que se garantice una
formación constante, escalada y reforzada periódicamente en los Proyectos.
7. La idea es lograr una verdadera identificación del usuario con el concepto de
seguridad, producto del conocimiento adquirido el cual se debe respaldar en
las diferentes políticas o normativas que a través de la participación del mismo
usuario promuevan una conducta deseable.
8. La idea es que la formación de los usuarios en el concepto de seguridad
informática sea llevado a cabo por un equipo de trabajo el cual se encargará de
desarrollar las metodologías propuestas en el presente trabajo.
9. El área de conocimiento de Recurso Humano es la que mas baja puntuación
63
obtuvo en el estudio, esto confirma el hecho de que la seguridad informática es
un concepto que debe estar arraigado en cada persona y no simplemente
documentado en una política o manual de uso de equipo informático.
64
5 Desarrollo de Métodos de Gestión Estas metodologías tienen como finalidad convertirse en una opción para el
mejoramiento de la SIBC en los Proyectos de la UEN PySA, la cual pretende
solucionar el bajo nivel de conocimiento en aspectos de seguridad informática que
hoy en día se tiene en los Proyectos.
En la actualidad, existe una ausencia de procedimientos que permitan una
adecuada formación de los usuarios de equipos informáticos, así como un
adecuado seguimiento de la formación brindada, con el respectivo expediente, de
manera que se permita documentar las lecciones aprendidas, en el que se incluya
una calificación, con el fin de ser considerados en eventos futuros.
La participación activa de todos los involucrados a lo interno del proyecto,
en la aplicación de las metodologías, permitirá cumplir con uno de los objetivos
propuestos, de tal manera que siempre se busque fortalecer el concepto de
seguridad informática en los usuarios de los Proyectos.
5.1 Método para la gestión del Recurso Humano
Esta metodología incluye los procesos que organizan y dirigen a los
usuarios de equipo informático en los Proyectos e involucrados en el proceso,
dichas personas son a quienes se les asignarán roles y responsabilidades para
garantizar el uso deseado del equipo informático. Se debe recordar que la
participación temprana de estas personas fortalece el compromiso con el
mejoramiento de la seguridad.
5.1.1 Planificación del Recurso Humano
Dentro de este proceso se han identificado actividades que son elementales
65
para definir e iniciar la integración de los usuarios e involucrados en el proceso de
mejoramiento de la seguridad informática, y son:
1. Confección de un manual o procedimiento en que se respaldará el concepto
de SIBC: Se debe trabajar en la elaboración de un manual, procedimiento,
normativa o política que establezca las bases sobre las cuales se
fundamentará el concepto de Seguridad Informática en los Proyectos, el
mismo deberá ser desarrollado por los encargados de TI de los Proyectos
existentes y aprobado por la Coordinación General de Proyectos.
2. Establecimiento de puestos de trabajo y sus conocimientos mínimos de TI
requeridos: Es importante que el Proyecto tenga claramente definida la
matriz de puestos en las que se podría estar necesitando personal que
manipule equipo informático y el tipo de conocimientos que se necesitarán
para desarrollarse en dicho puesto, esto ayudará a definir desde un inicio el
tipo de persona que será requerida; además, esta definición deberá
acoplarse al manual de puestos que actualmente se está desarrollando, el
cual sigue los lineamientos establecidos por la CGP, finalmente esto será
un complemento del documento final de manual de puestos. En la
actualidad la ausencia de dicha matriz produce nombramientos de personas
que ni siquiera han manipulado un computador alguna vez en su vida, y que
por una expectativa de trabajo se aventuran a aprender sobre la marcha el
funcionamiento del mismo; esta situación limita aún mas el hecho de que
asimilen el concepto de seguridad informática que se pretende dar a
conocer, esto por cuanto están concentrados en asimilar el funcionamiento
básico del equipo, para esto se recomienda la utilización de la siguiente
tabla:
66
Cuadro 4: Puestos de trabajo y sus conocimientos mínimos en TI.
Código Puesto Puesto de Trabajo Conocimientos mínimos
de TI requeridos
3. Preselección del personal: se deberá hacer una valoración de las ofertas de
trabajo que existan, en las que se ofrezcan servicios afines a los puestos
definidos en la tabla anterior, de esta manera, considerando el grado
académico y la experiencia acumulada en puestos similares en otras
empresas, de esta manera la oficina de Recursos Humanos establecerá
una calificación de la respectiva oferta a uno o varios puestos de trabajo por
medio del código respectivo, establecido en la tabla anterior. Esto facilitará
el filtrado de ofertas a la hora de seleccionar candidatos para un puesto
específico.
4. Confección de pruebas y evaluación del personal: A falta de un proceso de
confirmación de conocimientos en materia de TI, de acuerdo a los
requerimientos mínimos establecidos, nos encontramos ante el hecho de
creer en lo que el candidato seleccionado nos diga, o lo que podamos
extraer de una posible entrevista; desde este punto de vista cuando se
requiera este tipo de mano de obra, Recursos Humanos en conjunto con TI
deberán de realizarán una prueba de idoneidad, la cual puede desarrollarse
de forma escrita o práctica, de manera que se garantice que efectivamente
el candidato cuenta con esos conocimientos mínimos y que se encuentra
en capacidad de desempeñar el puesto requerido partiendo de ese nivel
67
mínimo y que no viene al Proyecto a aprender. Es de todos conocido que la
curva de aprendizaje implica un atraso en la productividad del personal y
que esto solo se puede aceptar cuando no hay opciones o alternativas, en
cuyo caso se recomienda una contratación anticipada del personal con el
objetivo de capacitarlo previamente, de manera que cuando el recurso se
requiera, se encuentre debidamente formado y presto a producir desde el
primer día de trabajo. La capacitación en estos casos puede ser impartida
por el personal experto del mismo proyecto o bien debe ser dada por
alguna empresa externa. Además dicha situación dependerá del caso
particular que se presente, de manera que cuando se requiera contratar
varias personas para un mismo puesto, si dos de ellas aprueban la
evaluación y otra no, se deberá contratar en forma anticipada a la persona
que reprobó con el objetivo de capacitarla, eso si no hay opciones o
alternativas (como se mencionó anteriormente) en el proceso de selección.
5. Ya en materia de seguridad se debe dar una clara orientación tanto al
usuario como a los involucrados, creando una visión del resultado exitoso
del conocimiento a adquirir, además de los beneficios que esto brindará al
Proyecto; si la meta y objetivos que se pretenden alcanzar no están del
todo claros, será muy difícil que los usuarios e involucrados puedan
alcanzarlos e interiorizarlos, para esto el líder del proceso o persona
llamada a desarrollar la metodología en el Proyecto, debe ser conocedora
del tema de Seguridad Informática y fiel practicante del mismo. Siempre se
debe tener presente que exista una clara compresión del objetivo, todo
debe estar orientado a resultados, debe existir un alto nivel de cooperación
y colaboración, al igual que una alto nivel de confianza.
68
5.1.2 Desarrollo de la Matriz de Roles y Responsabilidades para el proceso
de selección y formación de los usuarios
Esta herramienta nos servirá para integrar los trabajos que comúnmente
dependen de varias personas, la idea es que se establezca la función que cada
una de estas personas desempeñará en el proceso formador de usuarios con un
adecuado nivel de SIBC, inicialmente se propone la siguiente matriz:
69
Cuadro 5: Matriz de Roles y Funciones.
70
5.1.3 Adquisición del Equipo de Trabajo.
Esta herramienta nos ayudará a establecer el proceso de obtener los
recursos humanos necesarios para desarrollar la metodología propuesta:
1. Implementación de las metodologías: debe ser ejecutada por el
Administrador de TI de cada Proyecto, para esto se debe estar facultado
por la máxima autoridad del Proyecto, de manera que no haya ningún tipo
de impedimento desde el punto de vista administrativo.
2. Creación de un manual o procedimiento de SIBC: esto debe ser realizado
con la participación de todos los administradores informáticos de los
Proyectos, ya que son estos los que en un inicio deberán coordinar la
ejecución de las presentes metodologías; además, se parte del supuesto
que son las personas que a nivel de SIBC, manejan el mas alto nivel en el
Proyecto.
3. Establecimiento de puestos de trabajo y sus conocimientos mínimos de TI
requeridos: La revisión de los puestos debe ser coordinada y ejecutada por
la jefatura de Recursos Humanos del CAP o un profesional competente en
el campo que sea definido por dicha jefatura (Recursos Humanos) y con la
participación de la CTIP.
4. Preselección del personal: La revisión de las ofertas debe ser desarrollada
por la jefatura de Recursos Humanos del Proyecto o un profesional
competente en el campo que sea definido por dicha jefatura (Rec.
Humanos) y el Administrador de TI.
5. Confección de Pruebas: La confección de las pruebas de evaluación estará
a cargo de Recursos Humanos del CAP, en coordinación con la CTIP,
71
dichas pruebas deberán ser normalizadas, de manera que sean las mismas
en todos los proyectos (mismo nivel de complejidad).
6. Evaluación del personal: La evaluación será desarrollada por cada jefatura
contratante en coordinación con la jefatura de Recursos Humanos, y
eventualmente dependiendo del caso será necesaria la presencia del
Administrador de TI, esto si la jefatura contratante lo considera pertinente,
ya sea para revisar la prueba y ahondar un poco más en algún tema
específico.
7. Para la formación de los usuarios el proceso se debe hacer en dos etapas,
correspondiendo en cada etapa a un grupo de usuarios a formar. El primer
grupo deben ser los miembros del departamento de TI, ya que como se
evidenció en el estudio estos tuvieron una puntuación mas baja que los
usuarios generales del equipo, y el segundo grupo (segunda etapa) será a
los usuarios generales de TI. Se recomienda preparar bien a los
colaboradores de TI ya que estos son en potencia instructores o
capacitadores de la metodología (manual o procedimiento de SIBC) en el
Proyecto, con dicho personal capacitado e identificado con el proceso se
procede a capacitar a los usuarios generales. Desde este punto de vista es
importante que todas las capacitaciones sean coordinadas con al menos
una persona de Gestión del Sistema, esto con el objetivo de documentar en
los formatos establecidos toda esta capacitación. Existen usuarios que al
haber sido capacitados también pueden impartir la capacitación a otros
usuarios y colaboradores que la requieran, lo cual definitivamente va a
consolidar la conducta deseada en la totalidad del Proyecto. Se recomienda
que todos los miembros de TI estén involucrados en el proceso de
capacitación a usuarios generales y esto ayudará en un futuro cercano a
tener personal identificado que facilitará el fortalecimiento de una conducta
deseada en los usuarios en general.
72
8. El papel de la Auditoria Interna dentro del proceso es verificar que el
entrenamiento se encuentre ajustado a las políticas de la Institución (ICE) y
las leyes aplicables.
5.1.4 Desarrollo del Recurso Humano.
Existen varias herramientas que se utilizarán en el desarrollo del Recurso
Humano, sean los capacitadores o capacitados los involucrados en el proceso, por
lo que se debe tener en cuenta lo siguiente:
1. Se debe considerar una adecuada apertura a nuevas ideas o
inquietudes que puedan surgir con la implantación de una SIBC. En
este sentido el equipo debe ser abierto a estas ideas o comentarios,
de manera que se saque el mayor provecho a las mismas. Si se debe
procurar establecer los mecanismos necesarios para permitir a los
usuarios transmitir dichas ideas o comentarios. En este sentido se
debe crear como mínimo un buzón de sugerencias tanto físico como
virtual (a través de una página en la intranet). Se deben estimar
habilidades como la empatía, la influencia y la creatividad, los cuales
son activos valiosos al gestionar y desarrollar el concepto de SIBC.
2. Para el caso de la formación de los usuarios se pueden utilizar varias
herramientas que los Proyectos tienen a mano, como aulas para
grupos de considerable tamaño, la Intranet para formación virtual, las
pizarras informativas, documentos de distribución masiva como el
caso de “Libreta de Campo”, tutorías y entrenamientos.
3. Las reuniones periódicas que las jefaturas desarrollan con sus
73
colaboradores son una buena oportunidad para reforzar algún aspecto
importante que se encuentre debilitado. Esto mejorará las relaciones
interpersonales de los usuarios en general y llevará a los mismos a
identificarse con el SIBC.
4. Con la normativa o procedimiento de la SIBC debidamente
formalizado se establecerán expectativas claras acerca del
comportamiento deseado, si esto se logra desde las primeras etapas
del proceso se reducirán los malos entendidos al mismo tiempo que
se lograrán los objetivos propuestos.
5. Es importante determinar el rendimiento que se ha tenido conforme
pasa el tiempo para lo cual se debe medir periódicamente el avance
en SIBC que tengan los Proyectos y de esta manera se tomarán
medidas que buscarán fortalecer aún mas el nivel de SIBC.
5.2 Método para la Planificación de las Comunicaciones.
Analizando los requisitos de comunicación se obtiene como resultado la
suma de necesidades de información para poder desarrollar las metodologías en
los diferentes Proyectos. La Matriz de Comunicaciones puede ser utilizada y
actualizada durante la ejecución, ya que procura que los recursos se utilicen solo
para comunicar información que contribuya al éxito del proceso de ejecución. Se
debe comunicar tanto lo malo como lo bueno, adquiriendo una política del “cero
secretos”, para evitar las sorpresas, además de evitar abrumar a los interesados
con información intrascendente.
Adicionalmente se han considerado tres canales oficiales de comunicación:
el medio escrito, el correo electrónico e Intranet. Las conversaciones informales
74
parten del supuesto que se darán, más no se documentarán y para efectos de la
Matriz no se controlarán; sin embargo se sabe de la importancia que este tipo de
comunicación tiene en cualquier proceso.
Se aconseja que para el cliente la información sea concisa, relevante y
gráfica. Para el caso del patrocinador y el equipo, debe ser detallada para fines de
control. No se debe asumir que la persona que recibe la información la ha
entendido, por lo que se debe asegurar el entendimiento de la misma haciendo
todos los ajustes necesarios para lograr que la persona los comprenda y pueda
explicar.
75
Cuadro 6: Matriz de Comunicación
Matriz de Comunicación
Esta
tus
Bis
eman
al
Rep
orte
Men
sual
Min
utas
de
reun
ione
s En
cues
ta d
e C
apac
itaci
ón
Mej
oras
in
form
átic
as
Info
rme
resu
men
es
tado
Pro
ceso
Involucrado Rol que desempeña Bis. Men. Bis. Jefatura de T.I. Implementa la Metodología ۩ ۩ @ @ ۩ ۩ Staff Interno Asistente @ ۩ @
Jefatura de Recursos Humanos Proyectos
Preselección del Personal, confección de pruebas de evaluación. Evaluación del personal.
۩ @ @ ۩
Director del Proyecto Cliente @ @ Jefatura de Gestión del Sistema
Seguimiento y control de la formación a los usuarios. ۩ @ @ @ @
Auditor Interno Revisión y auditorías @ ۩ Otras Jefaturas Reclutamiento de personal ۩ Usuarios Concepto de SIBC ۩
Jefatura Administrativa Patrocinador @ Jefaturas Funcionales Aporte de Recurso Humano @ CGP Cliente
Recursos Humanos CAP Establecimiento de puestos de trabajo y conocimientos mínimos.
۩
Encargado del SIPP Desarrollo de mejoras en SIPP para gestión del Recurso Humano
@
El estatus bisemanal sirve para confirmar prioridades, teniendo de esta
manera informado a los involucrados. Esto permitirá que el equipo cierre el ciclo
de capacitación o formación, ya que es en este período de tiempo en que el
76
personal es contratado. Cuando la información es confiable y oportuna es muy
difícil que el proceso se salga de control. Además en este período de tiempo será
sencillo implementar las acciones correctivas necesarias para garantizar el éxito
de la ejecución, y también ayudará a confirmar y dirigir los esfuerzos del equipo
hacia la obtención de las metas propuestas.
5.3 Método para la planificación de los Riesgos.
El riesgo tiene su origen en la incertidumbre que está presente en la
ejecución y desarrollo de un plan para el mejoramiento de la SIBC en los
Proyectos. Con el objetivo de reducir la repercusión negativa, es importante
realizar una adecuada gestión del riesgo inherente, identificando las oportunidades
a desarrollar y las amenazas por controlar, con sus respectivos responsables. De
esta forma se estará realizando una adecuada gestión del riesgo a la hora de
desarrollar el tema de SIBC en los Proyectos. Se debe considerar que para la
mayoría de los procesos en la planificación de riesgos, estos se deben actualizar
periódicamente durante la ejecución, de esta manera se tendrá conocimiento
permanentemente de los problemas llevando a cabo acciones preventivas
oportunas, en lugar de improvisar o reaccionar tardíamente.
5.3.1 Identificación de Riesgos.
Para la Identificación de Riesgos en el tema de la SIBC, se recomienda
usar la Técnica para recopilación de Información conocida como Tormenta de
Ideas. Las mismas pueden ser representadas gráficamente mediante la
herramienta del Mind Manager (software de administración de ideas), el cual
permite recopilar todas las ideas expuestas por un grupo multidisciplinario de
expertos, con gran facilidad y elegancia, un ejemplo de la utilización de la
77
herramienta es la siguiente imagen:
Figura 19: Ejemplo de utilización del Mind Manager en la Tormenta de Ideas.
Existen algunas recomendaciones a tener en cuenta a la hora de utilizar la
Tormenta de Ideas, son aspectos sumamente importantes para quien desarrolle la
herramienta, y ayudarán a obtener objetivamente información para establecer los
riesgos que enfrenta el Proyecto en determinado momento, y son:
1. Palabras claves débiles: es muy común que los empleados utilicen
palabras claves en blanco o comunes, por ejemplo temas religiosos o
nombres de seres queridos, esta conducta debe detectarse y
modificarse a través de una adecuada información al usuario.
2. Ausencia de parches de seguridad: no son instalados los últimos
parches de seguridad en los sistemas, en este sentido es frecuente
que los usuarios y los encargados de TI olviden actualizar los
sistemas, ambos deben vigilar por que los mismos se actualicen
periódicamente, para de esta forma reducir los riesgos.
78
3. Mala configuración de los servicios: un ejemplo de esto sería que los
servicios corran bajo una cuenta de alto privilegio en el sistema.
4. Ingeniería social: el técnico de TI o la DATI, reestablece la palabra
clave de un usuario sin verificar la identidad del usuario.
5. Se hacen las pruebas requeridas con una cuenta que no es el
Administrador o se ejecuta software de terceros mal intencionado.
Luego de esto, las ideas se deben categorizar por tipos de riesgos, siempre
utilizando el Mind Manager como herramienta de organización de ideas, ya que la
herramienta permite mover las ideas en categorías o subcategorías, quedando
como se muestra en la siguiente imagen (continuando con el ejemplo inicial):
Figura 20: Categorización del resultado de la Tormenta de Ideas.
Se deben ubicar las ideas dentro de cuatro categorías principales de riesgo,
considerando los siguientes parámetros:
79
Riesgos Técnicos y de Calidad: Dentro de esta categoría
encontramos la confiabilidad de una tecnología compleja, cambios de
los estándares de la calidad de la Industria durante el proyecto y
deficiencia en las especificaciones técnicas.
Riesgos de Gestión del proyecto: En esta categoría podemos
agrupar la deficiente asignación de tiempos y recursos, calidad
inadecuada del Plan de Proyecto, pobre uso de las disciplinas de la
Dirección de Proyectos y deficientes mecanismos de comunicación
con los steakholders.
Riesgos de la Organización: Para esta categoría podemos tomar en
cuenta los objetivos de costo, tiempo y alcance que son internamente
inconsistentes, financiación inadecuada y falta de priorización del
proyecto, lo que provoca conflictos por la obtención recursos con
otros proyectos de la organización.
Riesgos Externos: Para esta categoría se pueden tomar en cuenta
aspectos de índole legal, cuestiones laborales, prioridades
cambiantes del cliente, conflictos socio-políticos y aspectos
meteorológicos.
Finalmente, debemos con la información obtenida y ordenada, llenar la
siguiente matriz del riesgo, la cual resume y contempla toda la información a la
que se le realizará la evaluación del riesgo (continuando con el ejemplo):
Cuadro 7: Plantilla de Identificación del Riesgo.
80
Código Causa Descripción del Riesgo Relación
con otros
Riesgos
RT-001 Recurso Humano -
Personal desmotivado
Si no se mantiene una línea de mando
y se hace respetar lo pactado; esto
provocará un problema de desigualdad
y trato preferencial hacia algunos
usuarios, por lo que el personal se
desmotivará.
RE-001 Encargados de TI - Desacuerdos
Si no se coordina adecuadamente la
ejecución de la presente metodología
en todos los Proyectos de la UEN
PySA; se provocará un problema de
seguridad, el cual se heredará de un
Proyecto a otro.
RO-001 Organización -
Problemas Presupuestarios
Si no se invierte en la SIBC y se
asegura un adecuado presupuesto, la
información y permanencia de los
servicios, no se podrá garantizar en los
diferentes proyectos.
RA-001 Director – Falta de
apoyo o identificación con la SIBC
Si no se logra una empatía del Director
con la SIBC, se dificultará o
imposibilitará el poder implementar las
presentes metodologías en los
Proyectos.
Todos los riesgos detectados y asociados al proyecto, serán la base para
los procesos posteriores que se deben desarrollar de acuerdo a la presente
metodología, como lo son: análisis cualitativo, plan de respuesta al riesgo y su
81
seguimiento y control.
5.3.2 Análisis Cualitativo del Riesgo.
Este proceso permite priorizar los riesgos identificados para realizar futuras
acciones como es el caso de la planificación de la respuesta a los riesgos.
Además de ser el proceso donde se evalúa el impacto y la probabilidad de los
riesgos identificados.
Adicionalmente otorga prioridades a los riesgos de acuerdo con su efecto
potencial en los objetivos del proyecto. El criterio que se utilizará es por el rango o
calificación. Se debe ubicar la probabilidad y el impacto en las escalas respectivas,
según el criterio del equipo de Gestión de Riesgos y finalmente se determinará la
matriz P*I (Probabilidad * Impacto), para lo cual se recomienda utilizar las
siguientes escalas:
Cuadro 8: Escala de Calificación de la Probabilidad.
Probabilidad Muy Probable 0.9 Bastante Probable 0.7 Probable 0.5 Poco Probable 0.3 Improbable 0.1
82
Cuadro 9: Escala de Calificación del Impacto.
Impacto Muy Alto 0.8 Alto 0.4 Moderado 0.2 Bajo 0.1 Muy Bajo 0.05
Para ubicar el impacto de cada riesgo en la escala, se utilizarán los
siguientes criterios:
Cuadro 10: Evaluación del impacto de los Riesgos.
EVALUACIÓN DEL IMPACTO DE LOS RIESGOS Objetivos del Proyecto
Muy Bajo 0.05
Bajo 0.1 Moderado 0.2
Alto 0.4 Muy Alto 0.8
Costo Insignificante incremento del costo
Incremento del costo < al 5%
Incremento del costo entre 5 - 10%
Incremento del costo entre 10 - 20%
Incremento del costo > 20%
Calendario Insignificante variación del calendario
Variación del calendario < %5
Desviación general del proyecto 5 – 10%
Desviación general del proyecto 10 – 20%
Desviación general del proyecto > 20%
Alcance Reducción del alcance apenas perceptible
Areas menores del alcance son afectadas
Areas mayores del alcance son afectadas
Reducción del alcance inaceptable para el Director
Producto final es inservible.
Calidad Degradación de la calidad apenas perceptible
Solo aplicaciones muy específicas con afectadas
La reducción de la calidad, demanda la aprobación del Director
Reducción de la calidad inaceptable para el Director
Producto final es inservible
83
Ahora de la combinación de las escalas de probabilidad e impacto se
obtiene la matriz P*I, la cual nos permite evaluar cada riesgo según la escala:
Cuadro 11: Matriz de valoración de un riesgo específico (P*I).
Impacto Probabilidad
Muy Bajo 0.05 Bajo 0.1 Moderado
0.2 Alto 0.4 Muy Alto 0.8
0.9 0.05 0.09 0.18 0.38 0.72 0.7 0.04 0.07 0.14 0.28 0.56 0.5 0.03 0.05 0.10 0.20 0.40 0.3 0.02 0.03 0.06 0.12 0.24 0.1 0.01 0.01 0.02 0.04 0.08
Donde el color verde: se interpreta como un Riesgo Bajo, el color amarillo
como un Riesgo Moderado y el color rojo como un Riesgo Alto.
De acuerdo a esto, se puede evaluar cada riesgo identificado aplicando los
criterios de probabilidad e impacto definidos en los cuadros 8 y 9 respectivamente,
y utilizando los valores de P*I calculados en el cuadro #11, luego de evaluar cada
riesgo, se debe ordenar la columna de “Riesgo” de mayor a menor y establecer
los colores respectivos de acuerdo a los rangos establecidos en el cuadro #11,
como sigue (continuando con el ejemplo):
Cuadro 12: Matriz de Evaluación del Riesgo, priorizada descendentemente.
MATRIZ DE EVALUACIÓN DE RIESGOS Código Probabilidad Impacto Riesgo RT-001 0.7 0.8 0.56 RA-001 0.3 0.8 0.24 RE-001 0.3 0.4 0.12 RO-001 0.3 0.1 0.03
84
5.3.3 Proceso de respuesta al Riesgo.
En la planificación de la respuesta a los riesgos, se desarrollarán opciones
y determinarán acciones, para mejorar las oportunidades y reducir las amenazas a
los objetivos propuestos. Se deben abordar los riesgos en función de su prioridad,
introduciendo recursos y actividades según sea necesario. Se debe aprender de
los errores, de manera que si un problema de seguridad se llega a presentar, se
deben considerar aspectos como:
1. ¿Cómo ocurrió?
2. ¿Se ha cometido el mismo error en otras ocasiones?
3. ¿Cómo pudo hacer sido prevenido?
4. ¿Qué debe haber cambiado para prevenir este tipo de error?
5. ¿Es requerido nuevo entrenamiento o capacitación para hacer
frente es este problema?
5.3.3.1 Estrategias y acciones.
Hay disponibles varias estrategias de respuesta a los riesgos. Para cada
riesgo se debe seleccionar la estrategia o combinación de estrategias con mayor
probabilidad de ser efectiva. Luego se deben desarrollar acciones específicas para
implementar las estrategias escogidas. Normalmente existen tres estrategias que
se ocupan de las amenazas o los riesgos que pueden tener impactos negativos
sobre los objetivos del proyecto en caso de ocurrir, estas estrategias son:
85
Cuadro 13: Estrategias de Riesgos Negativos o Amenazas.
Acción del Riesgo Definición
Eliminar
Aislar los objetivos del impacto del riesgo o relajar el
objetivo que está en peligro, implica cambiar el plan para
evitar la amenaza que representa un riesgo adverso.
Transferir El acto de trasladar todo o parte del riesgo a otro ente,
normalmente se hace en forma de contratos y seguros.
Mitigar
El acto de revisar el alcance de los proyectos y el
presupuesto, preferiblemente sin invertir más tiempo u
ocasionar un impacto en la calidad del logro de los
objetivos, para reducir incertidumbre.
Aceptar
El reconocimiento de la existencia de un riesgo se da,
pero no se puede evitar, por lo que se acepta su
ocurrencia. La aceptación debe incluir el desarrollo de un
plan de contingencia para su manejo.
Por otro lado, se deben desarrollar acciones específicas para implementar
las estrategias que se ocupan de las oportunidades o los riesgos positivos sobre
los objetivos del proyecto en caso de ocurrir, estas estrategias serán:
86
Cuadro 14: Estrategia de Riesgos Positivos u Oportunidades.
Acción del Riesgo Definición
Explotar
Se puede seleccionar esta estrategia para los riesgos con
impactos positivos, cuando la organización desea
asegurarse de que la oportunidad se haga realidad.
Mejorar
Esta estrategia modifica el “tamaño” de una oportunidad,
aumentado la probabilidad y los impactos positivos, e
identificando y maximizando las fuerzas impulsoras claves
de estos riesgos de impacto positivo.
Compartir
Implica asignar la propiedad a un tercero que se
encuentra mejor capacitado, para capturar la oportunidad
para lograr un beneficio.
Aceptar
El reconocimiento de la existencia de un riesgo se da,
pero no se puede evitar, por lo que se acepta su
ocurrencia. La aceptación debe incluir el desarrollo de un
plan de contingencia para su manejo.
Se deberá escoger una estrategia para cada riesgo u oportunidad
identificada, todo esto basándose en el juicio de expertos. Además se desarrollará
una plantilla en la cual se contempla la clasificación anterior (Ver Cuadro #15)
5.3.3.2 Contingencias y respaldos.
Estas deberán usarse únicamente si tienen lugar, determinado tipo de
eventos. Para las estrategias de “Eliminar y Explotar”, es innecesaria la definición
de una contingencia o respaldo. Para el resto, debe ser desarrollado un plan B
(opcional) en caso de no ocurrir la estrategia planificada. Luego para la estrategia
de “Aceptar” en caso de que el riesgo ocurra, se debe ejecutar el plan de
87
contingencia; si la estrategia difiere de “Aceptar” se debe ejecutar el plan de
contingencia, en caso de que la primera estrategia falle. Además se desarrollará
una plantilla en la cual se contempla la clasificación anterior (Ver Cuadro #15)
5.3.3.3 Disparadores del Riesgo.
Los disparadores son síntomas o señales de advertencia de riesgos que
han ocurrido o que están por ocurrir. Una vez que se han identificado y agrupado
los riesgos del proyecto por categoría procederemos entonces a identificar los
disparadores y estos se observarán en el proceso de seguimiento y control de esta
área de conocimiento, a estos se les puede conocer como síntomas de riesgo o
señales de advertencia. Además se desarrollará una plantilla en la cual se
contempla la clasificación anterior (Ver Cuadro #15).
5.3.3.4 Fecha y responsable.
El responsable será aquel miembro del equipo que debe responder por la
ejecución de las acciones planeadas para dicho riesgo. La fecha nos permite
organizar las estrategias por la etapa o rangos de fechas de cumplimiento
(urgencia). Además se desarrollará una plantilla en la cual se contempla la
clasificación anterior (Ver Cuadro #15).
5.3.3.5 Matriz de respuesta al Riesgo
El registro de riesgos se desarrolla en la identificación de riesgos, y se
actualiza durante el análisis cualitativo. En el proceso de planificación de la
respuesta a los riesgos, se eligen y acuerdan las respuestas apropiadas, y se
incluyen en el registro de riesgos. La respuesta al riesgo debe ser planificada con
un nivel de detalle que corresponda con la clasificación de prioridades e
identificación del riesgo, de forma similar a la matriz que se muestra a
continuación (continuando con el ejemplo):
88
Cuadro 15: Plantilla de Planificación a la Respuesta de los Riesgos.
89
90
5.3.4 Seguimiento y Control de los Riesgos
Este proceso consiste en identificar, analizar y planificar nuevos riesgos,
realizar el seguimiento de los riesgos identificados y los que se encuentran en la
lista de supervisión, volver a analizar los riesgos existentes, realizar el seguimiento
de las condiciones que disparan los planes para contingencias, realizar el
seguimiento de los riesgos residuales y revisar la ejecución de las respuestas a los
riesgos mientras se evalúa su efectividad. Este proceso como los demás procesos
de gestión de riesgos, es continuo que se realiza durante el tiempo en que se
estén ejecutando las presentes metodologías, en este caso se realizará por medio
de la siguiente plantilla:
Cuadro 16: Plantilla de Planificación a la Respuesta de los Riesgos
PLANTILLA PARA DOCUMENTAR Y DAR SEGUIMIENTO Y CONTROL DE LOS RIESGOS Fecha de auditoria o revisión: Número de revisión: Riesgo se encuentra incluido en el Plan de Gestión de Riesgo: Si No
Código del Riesgo: Probabilidad: Muy probable, poco,
etc. Y su % según tabla.
Causa del Riesgo: Impacto: Muy bajo, moderado,
etc. Y su % según tabla
Descripción del Riesgo: Riesgos relacionados o residuales
Estrategia Eliminar, transferir, mitigar o aceptar Acción correctiva acordada / Contingencia
Describir las acciones tanto para el riesgo principal como el residual
Acción de respaldo Describir las acciones tanto para el riesgo principal como el residual
Disparador del Riesgo Describir el disparador tanto para el riesgo principal como el residual
Responsable: Nombre de la persona que tiene la responsabilidad de dar el bandera para ejecutar la acción planeada
91
PLANTILLA PARA DOCUMENTAR Y DAR SEGUIMIENTO Y CONTROL DE LOS RIESGOS
Estado del Riesgo: Aquí se establecen los resultados de la evaluación del riesgos, como lo son actualizaciones de todos los datos que se encuentran en el registro de riesgos.
Cambios Solicitados: Se registra cualquier modificación a la acción correctiva inicial o a la contingencia
Acciones Correctivas recomendadas Describir aquella solución al riesgo que no se planificó inicialmente.
Acción Preventivas recomendadas:
Firma(s) de responsable(s) de la auditoria
5.4 Guía de Aplicación.
Con el objetivo de instruir en la implementación de las metodologías
propuestas en el presente trabajo, es que se desarrolla la siguiente guía, de
manera que el Administrador de TI en cada Proyecto tenga una idea que cómo
arrancar el proceso y llevarlo por buen camino hacia el éxito en cada Proyecto:
1. El primer paso es concienciar a Dirección del Proyecto, acerca de los
beneficios que trae el aumento de la SIBC en su Proyecto. Esto busca la
identificación y aprobación del trabajo el cual puede ser planteado como
un proyecto (se debe recordar que el Plan de Gestión del Proyecto no
es parte de los objetivos del presente trabajo).
2. El siguiente paso es un trabajo fuerte en la ejecución de la metodología
para la gestión del Recurso Humano, en la cual el primer paso y muy
importante de esta metodología es el desarrollo del manual o
procedimiento que definirá el concepto de SIBC, para esto se
recomienda que los gestores de TI de todos los Proyecto se reúnan y
tomen como base una política institucional existente en el ICE llamada
“Utilización de recursos informáticos de usuario final hardware, software
92
y servicio de comunicaciones (muy débil por cierto en materia de SIBC,
razón por la cual se debe revisar y replantear).
3. Luego se debe trabajar fuertemente en la divulgación o metodología
para la gestión de las Comunicaciones, la cual fortalecerá y consolidará
el concepto de SIBC en el Proyecto.
4. Finalmente se debe en el proceso de seguimiento y control desarrollar la
metodología para la gestión de riesgos que afectarán el nivel alcanzado
o por alcanzar de SIBC en el Proyecto. Se debe tener presente que el
trabajo es continuo y con fecha de finalización al término del mismo
Proyecto que se está construyendo, por lo que se debe conceptualizar
como un trabajo de mejoramiento continuo y permanente durante el
ciclo de vida del Proyecto.
93
6 Conclusiones
1. La divulgación de las posibles conductas ilícitas derivadas del uso de las
TI, mejoran el nivel de seguridad que los usuarios manejan dentro de la
empresa u organización.
2. El adecuado proceso de selección del personal que trabajará con equipo
informático es vital en la reducción de los tiempos de inducción,
capacitación, costos, además de asegurar una alta productividad con
tiempos mínimos de retorno.
3. Parte importante en la elaboración del procedimiento, es que fue
conceptualizarlo de tal forma que no generara ningún tipo de salida de
dinero para el Proyecto, ni en una eventual fase de instalación, ni
durante su fase de aplicación en el tiempo. Por el contrario, a través de
la estandarización y organización del proceso promoverá economías de
tiempo y costo.
4. La investigación permite ver que los Proyectos tienen la madurez para
reconocer las debilidades que en materia de Seguridad Informática
existen y que existe disponibilidad y compromiso para lograr un cambio
importante en el actuar, producto del conocimiento transmitido en
materia de Seguridad Informática.
5. Entre mayor sea el nivel de seguridad que se implemente en los
sistemas informáticos, mas complejos serán a la hora de utilizarlos, lo
que demanda de personal capacitado y conocedor de las tecnologías y
sistemas informáticos, esto con el fin de reducir el tiempo de producción
de los usuarios en los mismos sistemas.
94
6. La corrección de vulnerabilidades es más costosa cuando no se
consideran o tratan a tiempo, la acción preventiva siempre resultará ser
más económica que la correctiva, de ahí la importancia de ejecutar las
presentes metodologías a la brevedad, para nivelar (alcanzar al menos
el 80% propuesto) el conocimiento de SIBC que actualmente tienen los
Proyectos de la UEN PySA.
95
7 Recomendaciones
1. Para el manejo de la recopilación de la información que en materia de
riesgos exista, se debe solicitar a Gestión del Sistema la elaboración de
un registro que permita dar trazabilidad a la gestión, por lo que debe
estar estandarizada y normada dentro de los Planes de Calidad de
Tecnologías de Información de los Proyectos.
2. Se debe integrar como parte de las funciones del Administrador de TI, la
formación en el conocimiento de la seguridad informática en los
Proyectos, esto en coordinación con el área de capacitación del mismo
Proyecto o del CAP.
3. Se debe establecer una responsabilidad común entre todos los
participantes del proceso, que va desde el inicio de la solicitud de
servicios informáticos, hasta que dicha persona es liquidada de su
respectivo Proyecto.
4. El personal encargado de la administración, definición y mantenimiento
de los procesos que favorecen a la optimización de la seguridad, deben
ser los llamados a velar por el cumplimiento, inducción, capacitación de
los nuevos elementos que eventualmente se estarán integrando a los
Proyectos.
5. Se debe realizar un trabajo arduo e intenso sobre las actividades que
mostraron un alto riesgo en el diagnóstico realizado, tomando las
medidas pertinentes a fin de prevenir la delincuencia informática; esto
debe ser revisado y complementado con el pasar del tiempo, dando un
adecuado seguimiento a los riesgos a partir del plan de gestión del
96
Riesgo propuesto.
6. La SIBC requiere de un apoyo total y absoluto de la Dirección y
Jefaturas de Área de los Proyectos, esto es crucial para el éxito y el
cumplimiento de los objetivos, de existir la menor duda, no se
recomienda el arranque del proceso.
7. La Dirección debe ser enérgica e imparcial a la hora de aplicar las
diferentes políticas y normativas de seguridad en el Proyecto, de lo
contrario se perderá credibilidad por parte de todo el personal del
Proyecto en el proceso y el mismo será llevado a un fracaso rotundo.
8. Plantear una revisión profunda en conjunto con el equipo de trabajo, a
los métodos desarrollados en el presente trabajo, de tal forma que se
puedan presentar en los formatos oficiales establecidos y que permita
una identificación del equipo de trabajo con la SIBC y la metodología
propuesta.
9. Desarrollar procesos de capacitación inmediata sobre el manual de
SIBC, que permitan nivelar el conocimiento mínimo deseado de la SIBC,
con el fin de aliviar los problemas en la ejecución y administración de la
metodología propuesta. Es importante tener en cuenta que la
modificación de la conducta se logra mediante una retroalimentación
positiva a los usuarios, de manera que sean ellos mismos quienes a
futuro, se encarguen de controlar y vigilar a sus compañeros de acuerdo
a la normativa definida en el manual o procedimiento.
10. Implementar dentro del módulo del SIPP un módulo que permita agilizar
el registro y consulta de las ofertas de trabajo y expedientes de cada
97
uno de los trabajadores del Proyecto, esto con el fin de agilizar la
obtención de información referente a cualidades y calidades que en
materia informática tienen los oferentes y empleados del Proyecto.
11. En la medida de las posibilidades, el equipo de trabajo debe mantener
los mismos miembros para garantizar el beneficio de la experiencia
adquirida.
12. Realizar un diagnóstico similar al desarrollado en el presente PFG, con
una periodicidad no mayor a 2 años, para con esto poder establecer los
avances que producto de la ejecución de las presentes metodologías se
ha tenido y para poder tomar acciones preventivas o correctivas según
correspondan.
13. Incorporar todo el procedimiento de Gestión del Riesgo de la SIBC
planteado en el presente trabajo, a la RBS que a futuro se estaría
desarrollando en el ICE, dado que en la actualidad a nivel de la DATI no
existe un análisis de riesgo documentado.
98
8 Glosario
CAP: Centro de Apoyo a Proyectos: unidad donde se concentra la
Coordinación General de Proyectos de la UEN PySA.
CGP: Coordinación General de Proyectos de la UEN PySA. Correo Electrónico: Servicio de mensajería electrónica que está relacionado
a un ámbito de acción mundial, en este caso los correos pueden
ser enviados tanto hacia dentro, como afuera de la Institución o
Proyecto; en otras palabras a cualquier parte del mundo donde se
cuente con este servicio.
Cracker: Intruso. Es un persona que intenta acceder a un sistema
informático sin autorización. Estas personas tienen a menudo
malas intenciones, en contraste con los hackers, y suelen
disponer de muchos medios para introducirse en un sistema.
Persona que intenta romper las protecciones de un cierto sistema
informático, normalmente con fines maliciosos (distinto de un
"hacker", que procura profundizar en un cierto sistema para
aprender de él).
DATI: Dirección Administrativa de Tecnologías de Información.
Dirección del Proyecto: Máximo ente de nivel organizacional que tiene un
Proyecto o autoridad de más alto nivel en un Proyecto.
Firewall: Dispositivo que permite bloquear o filtrar el acceso entre dos
redes, usualmente una privada y otra pública. Los firewall
99
permiten que los usuarios internos se conecten a la red externa al
mismo tiempo que previene la intromisión de atacantes o virus a
los sistemas de la organización.
FTP: Es una aplicación para transferir archivos entre su PC (el Sistema
"Local”) y un sitio de FTP (el Sistema Remoto o “Servidor”).
Usando FTP, usted puede conectar a otro sistema para visualizar
archivos y carpetas en ambos sistemas y transferir los archivos
entre los mismos.
Hacker: Persona con altos conocimientos sobre el funcionamiento interno
de un sistema, de un ordenador o de una red de ordenadores.
Este término se suele utilizar indebidamente como peyorativo,
confundiéndolo con el término “Cracker”. Experto informático
especialista en entrar en sistemas ajenos sin permiso,
generalmente para mostrar la baja seguridad de los mismos o
simplemente para demostrar que es capaz de hacerlo.
Hacking: Son las técnicas y procedimientos utilizados por un hacker para
un determinado objetivo. Normalmente son procedimientos
ilegales. Acción de piratear sistemas informáticos y redes de
telecomunicación.
Hardware: Conjunto de componentes materiales de un sistema informático.
Cada una de las partes físicas que forman un ordenador, incluidos
sus periféricos (CPU, discos, cintas, modem, cables, etc.). En
operación, un computador es tanto hardware como software. Uno
es inútil sin el otro. El diseño del hardware especifica los
comandos que puede seguir, y las instrucciones le dicen qué
100
hacer. El hardware es "almacenamiento y transmisión".
ICE: Instituto Costarricense de Electricidad
Internet: Es una red de redes a escala mundial de millones de
computadoras interconectadas con el conjunto de protocolos
TCP/IP. También se usa este nombre como sustantivo común y
por tanto en minúsculas para designar a cualquier red de redes
que use las mismas tecnologías que la Internet,
independientemente de su extensión o de que sea pública o
privada.
Intranet: Es una red privada la cual puede estar formada por varias redes
de área local conectadas entre sí. El objetivo de la misma es
propiciar un ambiente de comunicación propietaria, para que los
empleados de la Institución o compañía aprovechen la
infraestructura y los servicios que se brindan a través de ella.
PFG: Proyecto Final de Graduación.
Política Institucional: Documento vigente de utilización de recursos
informáticos de usuario final: hardware, software y servicio de
comunicaciones, aprobada por el Consejo Directivo del ICE en
acuerdo tomado en el artículo 01 del acta de Sesión 5601
celebrada el 13 de abril del 2004.
Sistemas Biompetricos: Este es un tipo de tecnología que realiza
mediciones en forma electrónica, guarda y compara
características únicas para la identificación de personas.
101
Sistema Informático: Es un conjunto de dispositivos constituido por, al
menos, una Unidad Central de Proceso (UCP), estando física y
lógicamente conectados entre sí todos los equipos que lo
integran, ya sea a través de canales -en local- o mediante líneas
de telecomunicación. Representa la concreción e infraestructura
física y lógica que sirve de soporte al proceso, almacenamiento,
entrada y salida de los datos, textos y gráficos que forman parte
de un sistema de información general o específico.
SIBC: Seguridad Informática Basada en el Conocimiento.
SIPP: Sistema de Información para Proyectos, el desarrollo de los
módulos informáticos para la gestión administrativa de los
proyectos, es desarrollada por un equipo de programadores que
se concentran en el CAP.
Software: El término inglés original define el concepto por oposición a
hardware: blando-duro, en referencia a la intangibilidad de los
programas y corporeidad de la máquina. Software es un término
genérico que designa al conjunto de programas de distinto tipo
(sistema operativo y aplicaciones diversas) que hacen posible
operar con el ordenador. El software es "lógica y lenguaje". El
software se ocupa de los detalles de un negocio en constante
cambio y debe procesar transacciones en una forma lógica. Los
lenguajes se utilizan para programar el software. La lógica y el
lenguaje involucrados en el análisis y la programación son por lo
general mucho más complejos que especificar un requerimiento
de almacenamiento y de transmisión.
102
Steakholders: Involucrados de un Proyecto.
TI: Tecnologías de Información, departamento o unidad
administrativa de los Proyectos, encargada del desarrollo
tecnológico e informático. Tecnologías de Información,
refiriéndonos al almacenamiento, procesamiento, recuperación y
distribución de la información por medio de procesos
microelectrónicos computarizados, lo que se denomina informática
y también hablamos de la transmisión de dicha información a
través de redes integradas de telecomunicación mediante
satélites, la digitalización, la fibra óptica, entre otros.
UEN PySA: Unidad Estratégica de Negocio Proyectos y Servicios Asociados
del Instituto Costarricense de Electricidad.
Usuario: Se entiende por usuario a una división, departamento, oficina o un
individuo ya sea de nuestra institución o ajena a ella. Los mismos
se encuentran clasificados a nivel del Sistema Operativo en tres
principales grupos:
Los “usuarios”, los cuales no pueden hacer cambios
accidentales o intencionados en el sistema, pueden ejecutar
aplicaciones certificadas pero no la mayoría de las heredadas.
Los “usuarios avanzados”, los cuales tienen más derechos
administrativos con algunas restricciones. De este modo,
pueden ejecutar aplicaciones heredadas junto con
aplicaciones certificadas.
Los “administradores”, los cuales tienen acceso completo y sin
restricciones al equipo.
103
UTP: Tipo de cable utilizado en redes de tipo Ethernet (tipo de topología
de red), con categorías 5 o 6, la categoría determina la capacidad
de transmisión del cable, usualmente este tipo de cable es
configurado en sus extremos a través de la norma 568b o 568a. Web Site: Se entiende como una web site al conjunto de textos, gráficos,
fotografías, sonidos o videos que unidos a otros elementos
análogos como pueden ser títulos o hipervínculos y que han sido
creados para su exposición en la Red para que sean visionados
por terceros a través de un navegador. Dentro del concepto de
página web se entienden todos los logros, marcas, párrafos de
textos inéditos incluidos dentro del mismo, imágenes y enlaces
que acceden a la descarga de aplicaciones u otro tipo de datos
para que sean bajados del servidor al ordenador del usuario.
104
9 Bibliografía
A.S.S. Borghello, Cristian Fabián. Seguridad Informática. Tesis de
Licenciatura en Sistemas, Universidad Tecnológica Nacional. Argentina. Septiembre del 2001.
Castillo Quesada. Alvaro. Diagnóstico del procedimiento utilizado en el
Proyecto Hidroeléctrico Pirrís para la Administración y Cierre de Contratos de Adquisiciones de bienes y servicios. Tesis de MAP, Universidad para la Cooperación Internacional. Costa Rica. Septiembre del 2004.
Chamoun, Yamal. Administración Profesional de Proyectos. La Guía. México:
McGraw Hill, 2002. Gido, Jack / Clements, James P. Administración Exitosa de Proyectos. EUA:
Internacional Thomson Editores, 1999. Grupo ICE. Información General del ICE y Proyectos de la UEN PySA. 2005.
Disponible en: http://www.ice.go.cr/esp/ele/index.html. Consultado el 03/08/2006.
ICE. Instituto Costarricense de Electricidad. Costa Rica: Publicado por Instituto
Costarricense de Electricidad, 1997. Muñoz Razo, Carlos. Cómo Elaborar y Asesorar una Investigación de Tesis.
Primera Edición. México: Pearson Educación, 1998. Naciones Unidas. Declaración Universal de los Derechos Humanos. 1948.
Disponible en http://www.un.org/spanish/aboutun/hrights.htm. Consultado el 15/08/2006.
P.H. Pirrís. Proyecto Hidroeléctrico Pirrís – ICE. 2006.
Disponible en: http://phpsa02/PHPirris/php_0000_Principal.asp. Consultado el 03/08/2006.
PMI (Project Management Institute). Guía de los Fundamentos de la Dirección
de Proyectos (PMBOK® Guide). Tercera Edición. USA. 2004. PYSA. Proyectos y Servicios Asociados. 2006.
Disponible en: http://inelec.ice/pysa. Consultado el 17/08/2006.
105
Segu-Info.com.cr. Seguridad de la Información. Argentina. 2006. Todos los contenidos de este sitio se encuentran bajo Licencia Creative Commons (Ver Anexo #6) a menos que se indique lo contrario. Disponible en: http://www.segu-info.com.ar/. Consultado el 03/08/2006.
106
10 Anexos
Anexo 1: Plantilla de acta (charter) del PFG. Anexo 2: Declaración del Alcance del Proyecto. Anexo 3:.Estructura de División del Trabajo Anexo 4: Cronograma del Proyecto. Anexo 5: Mapa del Proyecto Final de Graduación. Anexo 6: Licencia Creative Commons. Anexo 7: Estructura del Contenido del PFG. Anexo 8: Instrumento Entrevista Anexo 9: Instrumento Encuesta Anexo 10: La Seguridad Informática hoy día, “Terrorismo Digital”.
107
Anexo 1: Plantilla de acta (charter) del PFG.
108
ACTA (CHARTER) DEL PROYECTO
NFORMACIÓN PRINCIPAL Y AUTORIZACIÓN DEL PROYECTO INFORMACIÓN GENERAL DEL PROYECTO
Fecha: 22/07/2006
Código del proyecto: PIR – AD – TI – 01
Nombre del proyecto: Propuesta para el mejoramiento del nivel de Seguridad Informática basada en el Conocimiento en los Proyectos de la UEN PySA. Área de Conocimiento / Proceso: Recurso Humano, Comunicaciones y Riesgos
Área de Aplicación (Sector / Actividad): Tecnologías de Información
Fecha de Inicio del Proyecto: 22/07/2006
Fecha tentativa de finalización del Proyecto: 28/11/2006
Nombre del director del proyecto Ing. William Madrigal Zúñiga
DETALLE DEL PROYECTO Objetivos del Proyecto: Elaborar una propuesta metodológica que sirva de guía para mejorar la Seguridad Informática basada en el conocimiento (SIBC) de los usuarios de las Tecnologías de Información (TI), en los Proyectos de la UEN PySA.
Evaluar la situación actual de los Proyectos de la UEN PySA, en aspectos de Seguridad Informática basada en el Conocimiento, e identificar cuales son las principales debilidades o carencias existentes en los mismos.
Elaborar un método para realizar una adecuada planificación del Recurso Humano, que utilizan Tecnologías de Información en los Proyectos de la UEN PySA.
Elaborar un método para realizar una adecuada planificación de las Comunicaciones para nivelar conocimientos en los usuarios de Tecnologías de Información, en los Proyectos de la UEN PySA.
Elaborar un método para realizar una adecuada Gestión de los Riesgos, de manera que se pueda aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos al mejoramiento de la SIBC en los Proyectos de la UEN PySA, estableciendo como respuesta a los estos, que puedan ser eliminados, transferirlos, mitigados o aceptarlos.
Determinar o diagnosticar el nivel de Seguridad Informática basada en el Conocimiento, en los Proyectos de la UEN PySA.
Aplicar técnicas y herramientas de la Administración de Proyectos de manera que se desarrolle un fundamento científico a la presente Propuesta
109
Crear conciencia en la Dirección de la Unidad Estratégica de Negocios Proyectos y Servicios Asociados (UEN PySA), acerca de la importancia que tiene la formación de los empleados de Proyectos, en materia de Seguridad Informática.
Desarrollar en el empleado un mayor nivel de compromiso con la Seguridad Informática basada en el Conocimiento.
Nivelar conocimiento en los usuarios de Tecnologías de Información, en materia de Seguridad Informática en los diferentes Proyectos de la UEN PySA.
Descripción del Producto / Problema (lo que da origen): Problema: El ICE ha realizado una gran inversión (muchos cientos millones de colones) en equipode protección de las Tecnologías de Información; sin embargo, a pesar de toda esta gran inversión, se mantiene un portillo grande por medio del cual es totalmente vulnerable: “los usuarios finales de las Tecnologías de Información”, los cuales a falta de conocimiento podrían permitir a terceras personas acceder a la red y que los mismos hagan uso de los diferentes servicios que la Tecnología facilita hoy en día a toda la organización. Producto: Se entregará una propuesta metodológica para el mejoramiento del nivel de Seguridad Informática basada en el Conocimiento en los Proyectos de la UEN PySA, tomando en cuenta tres enfoques principales: los Recursos Humanos, la Comunicación y los Riesgos (una metodología en cada caso como aporte al conocimiento), además del diagnóstico y análisis de la información obtenida de la investigación de campo; finalmente, las recomendaciones y conclusiones producto de lo encontrado y desarrollado en el presente trabajo. Justificación de Impacto (Aporte y resultados esperados) El tema de Seguridad Informática es hoy en día un asunto de vital importancia en las organizaciones; sin embargo por la aparente debilidad que el usuario muestra en el conocimiento de ésta, es que se debe crear una propuesta que logre crear conciencia en la Dirección de la UEN PySA y en los mismos usuarios de Tecnologías de Información, logrando de esta manera reducir la posibilidad de que la Organización se vea afectada seriamente por accesos no autorizados de personas internas o externas a la misma. Laaplicación de esta propuesta beneficiará a todos los usuarios de Tecnologías de Información y la Organización, generando un amplio conocimiento que reforzará una adecuada conducta cuando se utilicen Tecnologías de Información en los Proyectos de la UEN PySA.
110
Restricciones:
La propuesta será aplicable en los Proyectos de la UEN PySA. No se desarrollarán metodologías de carácter administrativo de las Tecnologías de
Información de Proyectos. No se desarrollarán metodologías relevantes al tema de la Seguridad Informática,
ya sea física o lógica. Identificación de Grupos de Interés (stakeholders): Cliente(s) directo(s):
(Profesor seminario de Graduación). Lic. Álvaro Castillo Quesada MAP (Tutor de PFG). Encargados de las Tecnologías de Información en los Proyectos de la UEN PySA. Directores, Jefes de Área, Jefes Staff y usuarios de equipo Informático de los
Proyectos de la UEN PySA. Cliente(s) indirecto(s):
Coordinación de Tecnologías de Información de la UEN PySA. La Dirección Administrativa de Tecnologías de Información (DATI - ICE).
Usuarios en general del equipo Informático de la Institución.
AUTORIZACIÓN PARA EL PROYECTO Aprobado por:
M.Sc. Miguel Ángel Vallejo Solís
Fecha:
Profesor Tutor:
Lic. Álvaro Castillo Quesada MAP.
Fecha: 17/08/2006
Estudiante:
Ing. William Madrigal Zúñiga.
Fecha: 16/08/2006
111
Anexo 2: Declaración del Alcance del Proyecto.
112
DECLARACIÓN DE ALCANCE DEL PROYECTO PERFIL DEL PROYECTO
Fecha: 22/07/2006
Código del proyecto: PIR-AD-TI-01
INFORMACIÓN GENERAL DEL PROYECTO Nombre del proyecto: Propuesta para el mejoramiento del nivel de Seguridad Informática basada en el Conocimiento en los Proyectos de la UEN PySA.
ENFOQUE DEL PROYECTO Planteo del Problema (necesidad, oportunidad) y Justificación del Proyecto: Problema: El ICE ha realizado una gran inversión (muchos cientos millones de colones) en equipo de protección de las Tecnologías de Información; sin embargo, a pesar de toda esta gran inversión, se mantiene un portillo grande por medio del cual es totalmente vulnerable: “los usuarios finales de las Tecnologías de Información”, los cuales a falta de conocimiento podrían permitir a terceras personas acceder a la red y que los mismos hagan uso de los diferentes servicios que la Tecnología facilita hoy en día a toda la organización. Justificación: El tema de Seguridad Informática es hoy en día un asunto de vital importancia en las organizaciones; sin embargo por la aparente debilidad que el usuario muestra en el conocimiento de ésta, es que se debe crear una propuesta que logre crear conciencia en la Dirección de la UEN PySA y en los mismos usuarios de Tecnologías de Información, logrando de esta manera reducir la posibilidad de que la Organización se vea afectada seriamente por accesos no autorizados de personas internas o externas a la misma. La aplicación de esta propuesta beneficiará a todos los usuarios de Tecnologías de Información y la Organización, generando un amplio conocimiento que reforzará una adecuada conducta cuando se utilicen Tecnologías de Información en los Proyectos de la UEN PySA. Objetivo(s) del proyecto: Elaborar una propuesta metodológica que sirva de guía para el mejorar de la Seguridad Informática basada en el conocimiento (SIBC) de los usuarios de las Tecnologías de Información (TI), en los Proyectos de la UEN PySA.
Evaluar la situación actual de los Proyectos de la UEN PySA, en aspectos de Seguridad Informática basada en el Conocimiento e identificar cuales son las principales debilidades o carencias existentes en los mismos.
Elaborar un método para realizar una adecuada planificación del Recurso Humano, que utilizan Tecnologías de Información en los Proyectos de la UEN PySA.
113
Elaborar un método para realizar una adecuada planificación de las Comunicaciones para nivelar conocimientos en los usuarios de Tecnologías de Información, en los Proyectos de la UEN PySA.
Elaborar un método para realizar una adecuada Gestión de los Riesgos, de manera que se pueda aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos al mejoramiento de la SIBC en los Proyectos de la UEN PySA, estableciendo como respuesta a los estos, que puedan ser eliminados, transferirlos, mitigados o aceptarlos.
Determinar o diagnosticar el nivel de Seguridad Informática basada en el Conocimiento, en los Proyectos de la UEN PySA.
Aplicar técnicas y herramientas de la Administración de Proyectos de manera que se desarrolle un fundamento científico a la presente Propuesta.
Crear conciencia en la Dirección de la Unidad Estratégica de Negocios Proyectos y Servicios Asociados (UEN PySA), acerca de la importancia que tiene la formación de los empleados de Proyectos, en materia de Seguridad Informática.
Lograr que el empleado adquiera un nivel de compromiso con la Seguridad Informática basada en el Conocimiento.
Nivelar conocimiento en los usuarios de Tecnologías de Información, en materia de Seguridad Informática en los diferentes Proyectos de la UEN PySA.
ABORDAJE DEL PROYECTO Producto Principal del Proyecto: 1. Se entregará una propuesta metodológica para el mejoramiento del nivel de
Seguridad Informática basada en el Conocimiento en los Proyectos de la UEN PySA, tomando en cuenta tres enfoques principales: los Recursos Humanos, la Comunicación y los Riesgos (una metodología en cada caso como aporte al conocimiento).
2. Diagnóstico y análisis de la información obtenida de la investigación de campo; finalmente, las recomendaciones y conclusiones producto de lo encontrado y desarrollado en el presente trabajo.
Exclusiones: 1. No desarrollará metodologías de carácter administrativo de las Tecnologías de
Información de Proyectos. 2. No desarrollará metodologías relevantes al tema de la Seguridad Informática, ya sea
física o lógica.
114
Supuestos 1. Se contará con el apoyo de los encargados de TI de los Proyectos del la UEN PySA. 2. Se contará con el apoyo de los Directores de los Proyectos, para la aplicación de las
herramientas de campo en su respectivo Proyecto. 3. Se contará con el apoyo de los usuarios de Tecnología de Información de los
proyectos, para la oportuna obtención de resultados, siendo los mismos veraces y confiables.
Restricciones o limitaciones 1. La propuesta será aplicable en los Proyectos de la UEN PySA.
Riesgos y Problemas 1. No disponibilidad del personal al momento de aplicar las herramientas de campo. 2. Entrega tardía de la información solicitada por parte del personal seleccionado.
EQUIPO PLANIFICADOR DEL PROYECTO 1. William Madrigal Zúñiga. 2. Álvaro Castillo Quesada
AUTORIZACIÓN PARA EL PROYECTO
Director del proyecto
Ing. William Madrigal Zúñiga
Fecha: 16/08/2006
115
Anexo 3: Estructura de División del Trabajo.
116
Figura 21: EDT del PFG
117
Anexo 4: Cronograma del Proyecto.
118
Figura 22: Cronograma del PFG
119
120
Anexo 5: Mapa del Proyecto Final de Graduación.
121
Propuesta para desarrollar la SIBC en Proyectos de la
UEN PySA29/08 : 28/1192 day(s)
Proceso de Cierre29/10 : 28/1131 day(s)
Revisión de PFG29/10 : 31/103 day(s)
Preparación del Borrador Final de Tesis
01/11 : 01/111 day(s)
Revisión de la Tesis por parte de los Lectores y Tutor Asignado
02/11 : 16/113 week(s)
Corrección de Tesis17/11 : 18/112 day(s)
Preparación del Documento Final de Tesis
19/11 : 22/114 day(s)
Preparación de la Presentación para el día de la Defensa
23/11 : 27/111 week(s)
Sustentación del PFG28/11 : 28/111 day(s)
Conclusiones y Recomendaciones
25/10 : 28/104 day(s)
Desarrollo de Métodos de Gestión
27/09 : 24/1028 day(s)
Método para la Planificación del Recurso Humano
27/09 : 06/102 week(s)
Planificación del Recurso Humano
27/09 : 30/094 day(s)
Desarrollo de la Matriz de Roles y Responsabilidades
27/09 : 30/094 day(s)
Adquisición del Recurso Humano
01/10 : 02/102 day(s)
Desarrollo del Recurso Humano
03/10 : 06/104 day(s)
Método para la Planificación de las Comunicaciones
07/10 : 15/109 day(s)
Planificación de la Comunicación
07/10 : 12/106 day(s)
Logistica de la comunicación
07/10 : 09/103 day(s)
Flujo de la Información
10/10 : 12/103 day(s)
Distribución de la Información
13/10 : 15/103 day(s)
Desarrollo de la Matriz de Comunicación
13/10 : 15/103 day(s)
Método para la Planificación de los Riesgos
16/10 : 24/109 day(s)
Identificación de los Riesgos16/10 : 19/104 day(s)
Desarrollo del Mapa de Riesgos
16/10 : 18/103 day(s)
Desarrollo de la Matriz de Riesgo
19/10 : 19/101 day(s)
Análisis Cualitativo20/10 : 21/102 day(s)
Matriz de Respuesta a los Riesgos
22/10 : 24/103 day(s)
Diagnóstico de la SIBC en Proyectos
29/08 : 26/0929 day(s)
Planificación y desarrollo de la Investigación de Campo
29/08 : 24/0927 day(s)
Entrevista Cualitativa (3 miembros de TI)
29/08 : 11/0914 day(s)
Selección de entrevistados (Miembros de TI)
29/08 : 29/081 day(s)
Concertación de Citas 30/08 : 05/097 day(s)
Confección de cuestionarios
30/08 : 03/091 week(s)
Ejecución de la Entrevista
06/09 : 09/094 day(s)
Tabulación y orden conceptual de la información
10/09 : 10/091 day(s)
Análisis e interpretación de los resultados obtenidos
11/09 : 11/091 day(s)
Encuesta (Usuarios)12/09 : 24/0913 day(s)
Selección de entrevistados (Usuarios)
12/09 : 13/092 day(s)
Concertación de Citas 14/09 : 20/097 day(s)
Confección de cuestionario
14/09 : 17/094 day(s)
Inducción al los encargados de TI en el cuestionario
18/09 : 18/091 day(s)
Ejecución de la Encuesta
21/09 : 22/092 day(s)
Tabulación y orden conceptual de la información
23/09 : 23/091 day(s)
Análisis e interpretación de los resultados obtenidos
24/09 : 24/091 day(s)
Resumen de hallazgos encontrados
25/09 : 26/092 day(s)
Figura 23: Mapa del PFG
122
Anexo 6: Licencia Creative Commons.
123
124
Anexo 7: Estructura del Contenido del PFG.
125
ESTRUCTURA DEL CONTENIDO DEL PFG
4.1. DIAGNÓSTICO DE LA SIBC EN LOS PROYECTOS
4.1.1. Planificación y Desarrollo de la Investigación de Campo. 4.1.1.1. Planificación y ejecución de la entrevista cualitativa a tres
miembros de TI. 4.1.1.1.1. Selección de entrevistados (tres miembros de TI). 4.1.1.1.2. Concertación de Citas. 4.1.1.1.3. Confección de Cuestionarios. 4.1.1.1.4. Ejecución de la Entrevista. 4.1.1.1.5. Tabulación y orden conceptual de la información. 4.1.1.1.6. Análisis e interpretación de los resultados obtenidos.
4.1.1.2. Planificación y ejecución de la encuesta a usuarios de Tecnologías de Información.
4.1.1.2.1. Selección de entrevistados (30% de usuarios de cada Proyecto).
4.1.1.2.2. Concertación de Citas. 4.1.1.2.3. Confección de Cuestionarios. 4.1.1.2.4. Inducción a los encargados de TI de Proyectos en el
Cuestionario. 4.1.1.2.5. Ejecución de la Encuesta. 4.1.1.2.6. Tabulación y orden conceptual de la información. 4.1.1.2.7. Análisis e interpretación de los resultados obtenidos
4.1.2. Resumen de hallazgos encontrados.
4.2. DESARROLLO DE MÉTODOS DE GESTIÓN. 4.2.1. Método para la planificación del Recurso Humano.
4.2.1.1. Planificación del Recurso Humano. 4.2.1.2. Desarrollo de la Matriz de Roles y Responsabilidades. 4.2.1.3. Adquisición del Recurso Humano. 4.2.1.4. Desarrollo del Recurso Humano.
4.2.2. Método para la planificación de las Comunicaciones. 4.2.2.1. Planificación de la Comunicación.
4.2.2.1.1. Logística de la Comunicación. 4.2.2.1.2. Flujo de Información.
4.2.2.2. Distribución de la Información. 4.2.2.3. Desarrollo de la Matriz de Comunicación.
4.2.3. Método para la planificación de los Riesgos. 4.2.3.1. Identificación de los Riesgos.
4.2.3.1.1. Desarrollo del Mapa de Riesgos. 4.2.3.1.2. Desarrollo de la Matriz de Riesgos.
4.2.3.2. Análisis Cualitativo de los Riesgos. 4.2.3.3. Matriz de respuesta a los Riesgos.
126
Anexo 8: Instrumento Entrevista.
127
ENTREVISTA
Proyecto: _______________________________ Fecha: __/__/____
Idea de entrevista:
La presente entrevista pretende evaluar y determinar el nivel que se tiene
en la actualidad, en aspectos de Seguridad Informática basada en el Conocimiento
de los encargados de TI y su personal, en los Proyectos de la UEN PySA; e
identificar cuales son las principales debilidades existentes referentes al tema. Los
resultados de la investigación ayudarán a desarrollar una metodología, que
permitirá mejorar la Seguridad Informática basada en el Conocimiento, de los
usuarios en general de las Tecnologías de Información de los Proyectos de la
UEN PySA, es por esta razón que se solicita toda la colaboración posible en el
desarrollo de la presente entrevista:
Indique el valor que mejor se ajusta a la realidad en su Proyecto: Área del Recurso Humano: 1. ¿Cuenta el Proyecto con un manual o procedimiento para el uso de las
Tecnologías de Información (hardware y software)?
SI NO
¿Tiene este manual tiene algún tipo de utilidad o fin? Explique:
2. ¿Es su usuario y clave de acceso conocidos por otros compañeros o colegas
de Tecnologías de información u otros usuarios?
SI NO
¿A que obedece esta situación (p.e. a necesidades propias del trabajo o quehacer del departamento o alguna otra particularidad)?
128
3. ¿El ingreso de cada usuario a los diferentes servicios está documentado
mediante una solicitud y debidamente respaldado (firmas, archivo físico)?
SI Algunas Veces NO
Explique:
4. ¿Existen usuarios que son Administradores de su propio equipo?
SI NO
Explique:
5. ¿Existen momentos en que se hace necesario conocer la clave de ingreso de
un usuario para poder brindarle un soporte?
SI NO
Explique:
6. ¿El ingreso a la red esta delimitado por un horario previamente autorizado?
SI NO
129
¿Como interpreta esta delimitación?
7. ¿Denunciaría usted cualquier patrón o conducta anormal de cualquier usuario
de los servicios que brinda Tecnologías de Información?
SI NO
Explique:
8. ¿Es el uso de computadores personales (no ICE) una práctica normal en el
Proyecto?
SI NO
¿Como podemos interpretar este tipo de práctica?
9. ¿Es utilizado el equipo tecnológico como un medio de entretenimiento en lugar
de ser una verdadera herramienta de trabajo?
SI Algunas Veces NO
Explique:
130
10. ¿Existe conocimiento por parte de los miembros de TI, respecto al tema de la
propiedad intelectual y derechos de autor, tanto de su empleador como otras personas creadoras de un producto en particular (Planos, Software, etc.)?
SI NO
Explique:
11. ¿Se conocen claramente los peligros de la instalación de software de terceros
no confiables en los equipos de la organización?
SI NO
Explique:
12. ¿Con este tipo de instalaciones (software de terceros), se puede desarrollar
cualquier otro tipo de acción malintencionada, teniendo desastrosas consecuencias para los Sistemas de la Organización?
SI NO
Explique:
13. ¿Tomar un disco compacto en la calle e introducirlo en los Sistemas de la
organización se puede considerar como una violación básica de seguridad?
SI NO
131
Explique:
14. ¿Se desatienden las advertencias de que el software no es seguro, debido a
que la instalación se hace sobre cualquier tipo de programa ejecutable que llegue de fuentes confiables?
SI NO
Explique:
15. ¿Se limitaría en exceso la capacidad de trabajo y la comodidad de uso en el
computador, cuando se establecen normas de uso de los equipos, cuando el usuario y administrador deben buscar consenso en un entorno seguro?
SI NO
Explique:
16. ¿Considera usted que es importante invertir en la formación del recurso
humano con el objetivo de alcanzar niveles óptimos de seguridad?
SI NO
Explique:
132
Área de la Comunicación: 1. ¿Ha sido instruido usted en que instalar un software de dudosa procedencia,
es una violación de las políticas de seguridad del lugar donde labora?
SI NO
Explique:
2. ¿Considera usted que una comunicación basada en un consejo o
recomendación no es suficiente para que los usuarios sean conscientes de su responsabilidad en el tema de seguridad?
SI NO
Explique:
3. ¿Según su experiencia, cómo reaccionan los usuarios ante las advertencias
expuestas?
4. ¿Cuales considera usted que sean los riesgos de no capacitar a los usuarios?
133
5. ¿Recursos Humanos notifica por escrito a TI, la salida o traslado de un
empleado del Proyecto?
SI NO
Explique:
6. ¿Se ha capacitado a los usuarios para que no se utilicen las facilidades del
Sistema Informático en beneficio propio o de terceros?
SI NO
Explique:
7. ¿Son los usuarios conocedores de que los equipos de cómputo asignados se
deben utilizar exclusivamente para labores oficiales?
Nunca Algunas Veces Siempre
Explique:
134
Área del Riesgo: 1. ¿La instalación de software de terceros es común entre los miembros de TI del
Proyecto?
Nunca Algunas Veces Siempre
Explique:
2. ¿Se dedican a explorar e incluso ejecutar programas en CD o DVD, sin dar
mayor importancia a las advertencias?
Nunca Algunas Veces Siempre
Explique:
3. ¿Es consciente usted que el usuario es el primer y más sencillo paso hacia la
red de la compañía para la que trabaja?
SI NO
Explique:
4. ¿Cree que el mayor riesgo de seguridad, se da por la confianza intrínseca
depositada en los usuarios y los derechos inherentes que deben poseer sobre la red?
Nunca Algunas Veces Siempre
135
Explique:
5. ¿Si los usuarios no son correctamente formados, pueden suponer un riesgo
para cualquier red corporativa ya sea consciente o inconscientemente, y provocar un incidente de seguridad importante en el sistema?
SI NO
Explique:
6. ¿Tecnologías de Información administra en forma centralizada la red, siendo
los dueños absolutos de las claves del Administrador de Dominio y el Administrador local de todos los equipos del Proyecto?
SI NO
Explique:
7. ¿Se comparten los recursos en la red en forma segura?
Nunca Algunas Veces Siempre
Explique que entiende por “forma segura”:
136
8. ¿Considera usted que se minimizan los riesgos, si se acatan estricta y constantemente las advertencias?
SI NO
Explique:
Finalmente:
Se agradece la atención y la información brindada, esta información es de
gran importancia para la formulación de tres metodologías que ayudarán en el
mejoramiento de la Gestión del Recurso Humano, la Gestión de las
Comunicaciones y la Gestión del Riesgo, para fortalecer la seguridad que basada
en el conocimiento tienen los usuarios de los proyectos de la UEN PySA.
137
Anexo 9: Instrumento Encuesta.
138
ENCUESTA
Proyecto: _______________________________ Fecha: __/__/____
Idea de encuesta:
La presente encuesta pretende evaluar y determinar el nivel que se tiene en la actualidad, en aspectos de Seguridad Informática basada en el Conocimiento de los usuarios de los equipos informáticos, en los Proyectos de la UEN PySA; e identificar cuales son las principales debilidades existentes referentes al tema. Los resultados de la investigación ayudarán a desarrollar una metodología, que permitirá mejorar la Seguridad Informática basada en el Conocimiento, de los usuarios en general de las Tecnologías de Información de los Proyectos de la UEN PySA, es por esta razón que se solicita toda la colaboración posible en el desarrollo de la presente entrevista: Indique el valor que mejor se ajusta a la realidad en su Proyecto: Área del Recurso Humano: 1. ¿Conoce usted de un manual o procedimiento para el uso de las Tecnologías
de Información (hardware y software) en su proyecto?
SI NO
Explique:
2. ¿Es su usuario y clave de acceso conocidos por otros compañeros,
obedeciendo a necesidades propias del trabajo?
SI Algunas Veces NO
Explique:
3. ¿Para obtener servicios de Tecnologías de Información debe realizarse
previamente una solicitud formal de los mismos?
139
Nunca Algunas Veces Siempre
Explique:
4. ¿Cree usted que debe tener derechos de Administrador local de su equipo?
SI NO
Explique:
5. ¿Le pide TI su clave de usuario a la hora de brindarle un soporte?
SI NO
Explique:
6. ¿Cree que debe su ingreso a los servicios de TI, estar limitado por un horario?
SI NO
Explique:
7. ¿Denunciaría usted cualquier patrón o conducta anormal de cualquier usuario,
con los servicios que brinda Tecnologías de Información?
SI NO
Explique:
140
8. ¿Utiliza su computador personal (no ICE) normalmente en el Proyecto?
SI NO
Explique:
9. ¿Utiliza el equipo tecnológico como un medio de entretenimiento (p.e.:
escuchar música, ver videos de música)?
SI NO
Explique:
10. ¿Es respetuoso de la propiedad intelectual y derechos de autor, tanto de su
empleador como otras personas creadoras de un producto en particular (Planos, Software, etc)?
SI NO
Explique:
11. ¿Es consciente sobre los peligros de la instalación de software de terceros no
confiables en los equipos de la organización?
SI NO
Explique:
141
12. ¿Es consiente que cualquier otro tipo de acción malintencionada puede ser posible, con este tipo de instalaciones (software de terceros) además de haber tenido desastrosas consecuencias para los Sistemas de la Organización?
SI NO
Explique:
13. ¿Es consciente de que el hecho de tomar un disco compacto en la calle e
introducirlo en los Sistemas, viola toda regla básica de seguridad?
SI NO
Explique:
14. ¿Se limita en exceso la capacidad de trabajo y la comodidad de uso en el
computador, cuando se establecen normas de uso de los equipos, cuando el usuario y administrador deben buscar consenso en un entorno seguro?
SI NO
Explique:
Área de la Comunicación: 1. ¿Se le ha indicado que el hecho de instalar software de terceros, podría
suponer una violación de las políticas de seguridad del lugar donde labora?
SI NO
Explique:
142
2. ¿Considera que un consejo es suficiente para acatar cualquier disposición y
que la misma se siga cumpliendo?
SI NO
Explique:
3. ¿Hace caso omiso de claras advertencias expuestas?
Nunca Algunas Veces Siempre
Explique:
4. ¿Es conciente de la importancia y responsabilidad que usted tiene en la
cadena de seguridad de cualquier empresa?
SI NO
Explique:
5. ¿Utiliza las facilidades del Sistema Informático para beneficio propio o de
terceros?
SI NO
Explique:
6. ¿Utiliza el equipo exclusivamente para labores oficiales?
SI NO
143
Explique:
Área del Riesgo: 1. ¿La instalación de software de terceros es común entre los usuarios del
Proyecto?
SI NO
Explique:
2. ¿Se dedican a explorar e incluso ejecutar programas en CD o DVD, sin dar
mayor importancia a las advertencias?
SI NO
Explique:
3. ¿Reconoce que usted es el primer y más sencillo paso para poder ingresar a la
red de la compañía para la que trabaja?
SI NO
Explique:
4. ¿Cree que el mayor riesgo de seguridad, se da por la confianza depositada en
usted y los derechos inherentes que debe poseer sobre la red?
SI NO
144
Explique:
5. ¿Comparte los recursos en la red en forma segura?
SI NO
Explique:
Se agradece la atención y la información brindada, esta información es de
gran importancia para la formulación de tres metodologías que ayudarán en el
mejoramiento de la Gestión del Recurso Humano, la Gestión de las
Comunicaciones y la Gestión del Riesgo, para fortalecer la seguridad que basada
en el conocimiento tienen los usuarios de los proyectos de la UEN PySA.
145
Anexo 10: La Seguridad Informática hoy día, “Terrorismo Digital”.
146
Conferencia sobre el llamado ‘terrorismo digital’
Ticos son vulnerables a ‘hackers’ por ser confiados
Riesgo de robo informático en sistemas nacionales es cercano al 80%
Bancos, turismo y telecomunicaciones son los sitios favoritos para atacar
Alejandra Vargas M.
Los costarricenses (personas y empresas) son un blanco fácil para el robo
de información valiosa por medio de computadoras.
Ello se debe a que no tienen ni las herramientas técnicas ni los hábitos que
podrían dificultar la labor a los llamados intrusos informáticos o hackers.
Así lo advirtió ayer el reconocido hacker mexicano Enrique Sánchez
Montellano (alias Nahualt) en el “Congreso de seguridad informática” que realizó
ayer el Grupo Cesa Costa Rica en Los Yoses, Montes de Oca.
“Todo se puede hackear. El asunto es más bien cuánto alguien está
dispuesto a invertir en dinero y tiempo para lograr burlar los mecanismos de
seguridad de una entidad para robarse los datos deseados”.
Enrique Sánchez (Hacker mexicano)
147
Según reconoció Sánchez, al prepararse para dar esta charla él mismo
logró ingresar (sin delinquir) al menos a tres empresas privadas costarricenses sin
ninguna dificultad.
“La mayoría de los ticos son muy vulnerables porque no tienen la mentalidad de seguridad y tienen la idea de que no es con ellos, de que son
demasiado pequeños para que algún hacker se meta en sus sitios”, dijo Nahualt.
El hacker recalcó que hay una porción grande de costarricenses que no
cambia periódicamente la clave ( password) de la computadora ni le permite a los
sistemas operativos –como Windows– instalar las actualizaciones para asegurar
su información.
En la empresa. Si hablamos de ambientes corporativos ticos, la situación no
es más halagüeña. Según añadió el experto venezolano Carlos Meza, de la
empresa 3Com, casi la totalidad de las empresas privadas, bancos y otras utilizan
solo tres herramientas para proteger sus datos.
Las herramientas son Firewalls (98%), los antivirus (97%) y el dispositivo
IDS (69%). El Firewalls, significa cortafuegos, es un elemento que permite o
prohíbe las comunicaciones en una red. Mientras, el IDS es un dispositivo de
protección contra intrusos.
Meza enfatizó en que este trío solo es capaz de prevenir el 20% de los
ataques informáticos, lo que significa que hay un 80% de vulnerabilidad en
nuestros sistemas.
Los sitios ticos más “tentadores” para los hackers serían los bancos, los
148
sitios de telecomunicaciones y los turísticos.
Los bancos son las entidades que más invierten en seguridad, pero la
situación empeora respecto a las instancias de gobierno, porque las licitaciones
para concretar su compra tardan mucho tiempo.
Como solución, ambos especialistas propusieron complementar el
Firewalls, los antivirus y el IDS con otros dispositivos como el llamado Tipping
Point.
Esta es una plataforma de seguridad construida por hackers ‘de sombrero
blanco’, esto es, de los que invaden los sistemas para averiguar dónde están las
fallas y repararlas (ayudar).
“No existe un sitio completamente seguro. Todo se puede hackear. El
asunto es más bien cuánto tiempo y dinero se puede invertir para lograr burlar los
mecanismos de seguridad y extraer los datos deseados”, dijo Sánchez.
“Un hacker es un investigador metódico y disciplinado que se propone un
objetivo y lo cumple.
“Es mucho más sencillo cuando hay menos protección; de ahí la llamada de
atención a los costarricenses para que se protejan”, insistió en señalar Sánchez.
![Tesis Versión para imprimir[1]](https://img.pdfslide.net/doc/110x75/5571fa20497959916991576e/tesis-version-para-imprimir1.jpg)
![un sol que en invierno [versión para descargar e imprimir]](https://img.pdfslide.net/doc/110x75/5571f24949795947648c6ce0/un-sol-que-en-invierno-version-para-descargar-e-imprimir.jpg)
