Bisogno Tesisdegradoingenieriainformatica PDF

UNIVERSIDAD DE BUENOS AIRES
FACULTAD DE INGENIERÍA
Ingeniería en informática
Tesis de grado:
“Metodología para el
Aseguramiento de Entornos
Informatizados” – MAEI.
Alumna: María Victoria Bisogno

Padrón: 74.784
E-mail: vickybisogno@hotmail.com; vbisogno@fi.uba.ar
Tutor: Prof. Lic. Sergio Villagra
Co-tutores: Andrea Morales, Saverio Locane, y Héctor Dinamarca
12 de octubre de 2004
Metodología para el Aseguramiento de Entornos Informatizados.
MAEI - María Victoria Bisogno.
I. ÍNDICE:
I. Índice:..................................................................................................... 1
II. Prefacio...................................................................................... 6
1. Propósito de la tesis.................................................................................. 6
2. Estado del Arte de la Seguridad Informática. ................................................ 8
3. Motivación para la realización de este trabajo ............................................. 10
4. Alcance de la tesis .................................................................................. 11
5. Organización del documento .................................................................... 12
III. Introducción. ............................................................................ 13
1. La metodología. ..................................................................................... 13
1.1 El estudio del entorno......................................................................... 13
1.2 La implantación de la solución. ............................................................ 13
2. Descripción de las fases. ......................................................................... 15
IV. Desarrollo de la metodología AEI ................................................. 23
1 Definición del Alcance ................................................................................. 25
Contenido: ............................................................................................. 25
1.1 Análisis de Requerimientos de Usuario ..................................................... 26
1.1.1 Documento de Requerimientos de Usuario .......................................... 26
1.1.2 Ejemplo - Requerimientos de Usuario ................................................. 27
1.2 Elaboración del Alcance ......................................................................... 27
1.2.1 Alcance.......................................................................................... 28
1.2.2 Ejemplo - Alcance ........................................................................... 30
1.3 Aprobación del Alcance.......................................................................... 33
1.4 Estimación de tiempos y costos. ............................................................. 33
1.4.1 Costos capitales .............................................................................. 34
1.4.2 Costos recurrentes .......................................................................... 35
1.4.3 Costos No recurrentes...................................................................... 37
1.5 Elaboración del Plan de Trabajo .............................................................. 37
2 Relevamiento ............................................................................................ 40
Contenido: ............................................................................................. 40
2.1 Elaboración del Relevamiento General. .................................................... 41
2.1.1 Relevamiento General ...................................................................... 43
2.2 Elaboración del Relevamiento de Usuario ................................................. 45
2.2.1 Relevamiento de Usuario .................................................................. 48
2.2.2 Asignación de puntaje...................................................................... 49
2.2.3 Aclaración sobre las preguntas .......................................................... 51
1
2.2.4 Resultados de la evaluación .............................................................. 55

2.2.5 Evaluación del entorno..................................................................... 56
2.2.5.1 Referencias al puntaje obtenido en el test por nivel: .......................... 56
2.2.5.2 Configuraciones de resultados: ....................................................... 56
2.3 Análisis de vulnerabilidades.................................................................... 57
2.3.1 Conocer al enemigo ......................................................................... 57
2.3.2 Ejemplo – Atacantes ........................................................................ 58
2.3.3 Las amenazas................................................................................. 59
2.3.4 Análisis de Vulnerabilidades .............................................................. 61
2.3.4.1 Aspectos funcionales ..................................................................... 61
2.3.4.2 Análisis de la documentación.......................................................... 65
2.3.4.3 Análisis de las aplicaciones y equipos .............................................. 66
2.3.4.3.1 Intento de Penetración ............................................................... 69
2.3.4.3.2 Herramientas de análisis de vulnerabilidades ................................. 70
2.3.5 Mapa de Vulnerabilidades ................................................................. 70
2.3.5.1 Vulnerabilidades a nivel físico ......................................................... 71
2.3.5.2 Vulnerabilidades a nivel lógico ........................................................ 75
2.3.5.3 Vulnerabilidades a nivel de la organización. ...................................... 82
2.4 Análisis de Riesgos ............................................................................... 83
2.4.1 Informe de Riesgos ......................................................................... 85
2.4.2 Ejemplo – Informe de Riesgos........................................................... 86
3 Planificación .............................................................................................. 89
Contenido: ............................................................................................. 89
3.1 Elaboración del Plan de Aseguramiento....................................................... 90
3.1.1 Protección física .............................................................................. 90
3.1.1.1 Protección de las Instalaciones ....................................................... 91
3.1.1.2 Protección de los equipos............................................................... 94
3.1.2 Protección lógica ........................................................................... 100
3.1.2.1 Protección de la información ........................................................ 100
3.1.2.2 Protección del Sistema Operativo. ................................................. 104
3.1.2.3 Protección de los datos................................................................ 115
3.1.3 Protección a nivel de la organización. ............................................... 122
3.2 Aprobación del Plan de Aseguramiento ..................................................... 130
4 Implantación ........................................................................................... 132
Contenido: ........................................................................................... 132
4.1 Elaboración del Relevamiento de Activos. ............................................... 135
4.1.1 Inventario de Activos ..................................................................... 135
2
4.1.2 Ejemplo – Inventario de Activos ...................................................... 139

4.1.3 Rotulación de activos ..................................................................... 140
4.1.4 Análisis de Criticidades................................................................... 140
4.2 Clasificación de la Información.............................................................. 142
4.2.1 Identificación de la información ....................................................... 142
4.2.2 Tipos de información...................................................................... 143
4.2.3 Beneficios de la clasificación de la información................................... 144
4.2.4 Riesgos de la información ............................................................... 144
4.3 Elaboración/ adaptación de la Normativa de Seguridad............................. 144
4.3.1 Interiorización del experto con la política y negocio de la organización .. 144
4.3.2 Elaboración/adaptación de la Normativa de Seguridad ........................ 145
4.3.2.1 Política de Seguridad................................................................... 147
4.3.2.1.1 Definición ............................................................................... 147
4.3.2.1.2 Ámbitos de aplicación y personal afectado ................................... 149
4.3.2.2 Normas y Procedimientos ............................................................ 149
4.3.2.2.1 Definición ............................................................................... 149
4.3.2.2.2 Espectro de las Normas y los Procedimientos ............................... 150
4.3.2.2.3 Ejemplo – Normas y Procedimientos ........................................... 152
4.3.2.3 Estándares, Esquemas y Manuales de usuarios ............................... 156
4.3.2.3.1 Definición ............................................................................... 156
4.3.2.4 Implantación y uso de la Normativa de Seguridad ........................... 156
4.3.2.5 Convenio de Confidencialidad ....................................................... 157
4.3.3 Aprobación de la Política de Seguridad ............................................. 157
4.4 Publicación de la Normativa de Seguridad .............................................. 158
4.4.1 Implantación de una campaña de concientización .............................. 158
4.4.2 Capacitación de los usuarios ........................................................... 159
4.5 Implantación del Plan de Aseguramiento ................................................ 159
4.5.1 Implantación a nivel físico .............................................................. 160
4.5.2 Implantación a nivel lógico ............................................................. 160
4.5.3 Implantación a nivel de la organización ............................................ 161
4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres (PRED) ... 161
4.6.1 Determinación del escenario considerado.......................................... 163
4.6.2 Determinación de los tipos de operación en una contingencia .............. 163
4.6.3 Establecimiento de criticidades ........................................................ 164
4.6.3.1 Tabla de Criticidades por Equipo. .................................................. 165
4.6.3.2 Ejemplo - Tabla de Criticidades por Equipo. .................................... 165
4.6.3.3 Tabla de Criticidades por Servicios. ............................................... 165
3
4.6.3.4 Ejemplo - Tabla de Criticidades por Servicios. ................................. 166

4.6.3.5 Tabla de Criticidades por Aplicaciones............................................ 167
4.6.3.6 Ejemplo - Tabla de Criticidades por Aplicaciones. ............................ 167
4.6.4 Determinación de las prestaciones mínimas ...................................... 168
4.6.5 Análisis de riesgos......................................................................... 168
4.6.5.1 Probabilidad de ocurrencia de desastres......................................... 168
4.6.5.2 Determinación de los niveles de desastre ....................................... 168
4.6.6 Presentación de las distintas estrategias posibles de recuperación ........ 169
4.6.7 Selección de la estrategia de recuperación ........................................ 169
4.6.8 Elaboración de la estrategia de recuperación ..................................... 169
4.6.8.1 Mitigación de riesgos – Medidas preventivas ................................... 169
4.6.8.2 Descripción de la estrategia ......................................................... 170
4.6.8.3 Requerimientos para llevar a cabo el Plan ...................................... 170
4.6.8.4 Esquemas técnicos ..................................................................... 171
4.6.8.5 Formación del Equipo de Recuperación del Entorno ante Desastres
(ERED) ................................................................................................ 171
4.6.8.5.1 Roles y responsabilidades ......................................................... 172
4.6.8.5.2 Asignación de roles .................................................................. 174
4.6.8.6 Establecimiento de los procedimientos........................................... 175
4.6.8.6.1 Declaración de la emergencia .................................................... 175
4.6.8.6.2 Recuperación de las prestaciones ............................................... 175
4.6.8.6.3 Reestablecimiento de las condiciones normales ............................ 176
5 Estabilización........................................................................................... 177
Contenido: ........................................................................................... 177
5.1 Análisis de resultados.......................................................................... 178
5.2 Ajuste ............................................................................................... 179
5.3 Cierre de la implantación. .................................................................... 179
5.4 Capacitación de usuarios. .................................................................... 180
5.4.1 Técnicas para la capacitación de usuarios: ........................................ 180
6 Mantenimiento......................................................................................... 183
Contenido: ........................................................................................... 183
6.1 Control de incidencias. ........................................................................ 184
6.1.1 Incidencias de seguridad ................................................................ 184
6.1.2 Notificación de incidencias .............................................................. 185
6.1.3 Documentación ............................................................................. 188
6.1.4 Reporte de Incidencias................................................................... 188
6.1.4.1 Manual de Procedimientos sobre Reporte de Incidencias.................. 191
4
6.1.5 Respuesta a incidencias ................................................................. 191

6.1.6 Recolección de incidencias .............................................................. 192
6.1.7 Registro de incidencias................................................................... 192
6.1.8 Investigación ................................................................................ 194
6.1.9 Seguimiento de incidencias............................................................. 194
6.1.10 Prevención de incidencias ............................................................. 194
6.2 Control de cambios ............................................................................. 195
6.2.1 Procedimiento de Control de Cambios .............................................. 197
6.2 2 Diagrama de flujo.......................................................................... 204
6.2.3 Formulario de Control de cambios.................................................... 205
6.2.4 ABM Activos ................................................................................. 210
6.2.5 Ejemplo - AMB Activos ................................................................... 211
6.2.6 Actualizaciones de Software............................................................ 212
6.2.6.1 Documento de Actualizaciones de Software .................................... 213
V. Conclusión.............................................................................. 214
VI. Bibliografía ............................................................................. 219
VII. Anexo I. MAEI – Resumen de Fases y Tareas............................... 222
VIII. Anexo II. Estándares Internacionales. Reseña introductoria. .......... 223
ISO/IEC estándar 17799 ........................................................................ 223
Cobit ................................................................................................... 224
MAGERIT.............................................................................................. 226
IX. Anexo III. Glosario de términos. ................................................ 228
5
II. PREFACIO
1. Propósito de la tesis
La Seguridad Informática es una disciplina cuya importancia crece día a día.
Aunque la seguridad es un concepto difícil de medir, su influencia afecta

directamente a todas las actividades de cualquier entorno informatizado en los que
interviene el Ingeniero en Informática, por lo que es considerada de vital
importancia.
[Huerta2000] define la seguridad como “una característica de cualquier sistema

(informático o no) que nos indica que ese sistema está libre de todo peligro, daño o
riesgo, y que es, en cierta manera, infalible”... “para el caso de sistemas
informáticos, es muy difícil de conseguir (según la mayoría de los expertos,
imposible) por lo que se pasa a hablar de confiabilidad”.
[IRAM/ISO/IEC17799] sostiene que “la seguridad de la información protege a ésta de

una amplia gama de amenazas, a fin de garantizar la continuidad comercial,
minimizar el daño al negocio y maximizar el retorno sobre las inversiones y las
oportunidades.”
En cualquier entorno informatizado es necesario estar protegido de las múltiples (y

hasta desconocidas) amenazas, garantizando, fundamentalmente, la preservación de
tres características:
• Integridad: que se proteja la exactitud y totalidad de los datos y los métodos

de procesamiento;
• Confidencialidad: que la información sea accesible sólo a las personas

autorizadas;
• Disponibilidad: que los usuarios autorizados tengan acceso a la información y a

los recursos cuando los necesiten;
[IRAM/ISO/IEC17799] también agrega “La seguridad de la información se logra

implementando un conjunto adecuado de controles, que abarca políticas, prácticas,
procedimientos, estructuras organizacionales y funciones del software”.
Para la realización de este trabajo se han estudiado diversas metodologías de

seguridad citadas en el Anexo I, que cubren distintos aspectos, pero ninguna tiene
un enfoque estructural similar al que un Ingeniero en Informática le da a los
problemas, según la visión que se adquiere con la formación en la Universidad.
6
Además, la bibliografía relacionada ofrece soluciones puntuales para problemas

específicos de seguridad, pero no da una solución integral al problema.
La motivación de este trabajo es la falta de una herramienta que les permita a los
profesionales de Informática analizar e implementar técnicas de seguridad en
entornos informatizados bajo la visión del Ingeniero.
El propósito del presente proyecto es formalizar una metodología práctica, y factible

para convertir entornos informatizados inseguros en entornos protegidos, y lograr
una clara evaluación de los mismos, teniendo en cuenta el objetivo y los procesos del
negocio.
El principal objetivo, entonces, es proveer a los Ingenieros en Informática y

Licenciados en Análisis de Sistemas de una herramienta con modelos estructurados
para que, de forma ordenada y efectiva, les facilite y les guíe en la tarea de dar
informe de las vulnerabilidades presentes en el entorno en que trabajan y las
posibles soluciones, para luego implementarlas con éxito y así lograr una efectiva
protección y documentación del entorno objetivo.
Esta metodología estará compuesta por una serie de fases en las que se aplicarán
procedimientos y se buscará el conocimiento de los procesos, y a su vez, una
completa documentación que avale y acompañe al proyecto y que sirva de referente
a lo largo de la vida operativa del entorno.
Se pretende que esta metodología cree un cambio cultural en el ambiente donde se

implementa (una empresa informatizada, un sector informatizado de un negocio,
etc.), al aplicar políticas que afecten al personal, al uso de los recursos y a la forma
de trabajo, además de una conciencia integral de la importancia de la seguridad en
entornos informatizados y las implicancias de las falencias en este tema.
Este proyecto está destinado a aplicarse en entornos en los que nunca se han
realizado controles de seguridad, como en los que están bajo un régimen de
seguridad controlado, sobre el que se desea evaluar su efectividad, o comprobar su
completitud.
Al hablar de sistema “inseguro” se hace referencia a un sistema no confiable, no

auditado, no controlado o mal administrado con respecto a la seguridad.
NOTA: De ahora en más se hará referencia al experto en seguridad, actor

protagonista del proceso de aseguramiento aquí presentado, como “ES”.
7
2. Estado del Arte de la Seguridad Informática.
Básicamente, los problemas de Seguridad Informática son sucesos que no deseamos

que ocurran. La mayoría son inesperados, aunque en muchos casos se pueden
prevenir.
Cuando hablamos de incidentes de Seguridad, o problemas de Seguridad Informática

nos referimos a:
• Acceso no autorizado a la información;

• Descubrimiento de información;
• Modificación no autorizada de datos;
• Invasión a la privacidad;
• Denegación de servicios;
• Etc.
Cada entorno informatizado es diferente, y maneja distintos tipos de información, y

por ende, es distinta la forma en que se tratan los datos.
Los componentes de los entornos informatizados son distintos, por lo que las
especificaciones de seguridad asociadas a cada uno varía notablemente dependiendo
de la tecnología utilizada a nivel de plataforma, software base y dispositivos físicos.
La funcionalidad y características técnicas de los componentes de los entornos varían

notablemente según la marca, en particular en los aspectos concernientes a la
seguridad.
Hoy en día la amenaza más común en los ambientes informatizados se centra en la

eliminación o disminución de la disponibilidad de los recursos y servicios que utiliza el
usuario.
El crecimiento de las telecomunicaciones y la estricta dependencia que existe entre el

negocio de las empresas y la tecnología informática hace crítica la inversión en
seguridad. Cada vez más los procesos comerciales se ven estrechamente ligados a
procesos informáticos.
Prácticamente toda la información vital para el negocio de una compañía comercial se

encuentra informatizada, no sólo almacenada en dispositivos electrónicos, sino que,
en la mayor parte de los casos, se encuentra distribuida físicamente y viaja
constantemente a través de medios públicos como redes de telefonía e Internet.
Es por eso que se pone énfasis en el crecimiento de soluciones para el problema de la

Seguridad Informática, por lo que el conocimiento en esta área ha crecido
8
enormemente en los últimos años, al punto en que somos capaces de afirmar que es
posible lograr una completa enumeración de las fallas de seguridad de los sistemas y
los entornos en los que viven.
Estas fallas de seguridad son las que se convierten en amenazas susceptibles de ser
aprovechadas por usuarios malintencionados para causar daño o algún tipo de
invasión a la confidencialidad.
Protegerse contra accesos no autorizados es el problema más sencillo a resolver, ya

que durante años se han desarrollado y perfeccionado algoritmos matemáticos para
la encripción de datos, para el intercambio seguro de información, para garantizar el
correcto funcionamiento del software, que se ha traducido en herramientas capaces
de proporcionar soluciones rápidas y sencillas a problemas técnicos de seguridad.
Desafortunadamente, no es suficiente simplemente arreglar los errores o eliminar las

fallas técnicas de seguridad. El problema va mucho más allá.
La Seguridad Informática es un problema cultural, en el que el usuario juega un rol

protagónico.
La responsabilidad sobre la seguridad de los datos y equipos ya no recae solamente

en el personal técnico especializado encargado de resguardar los bienes y servicios
brindados por el entorno, sino que es el usuario el que debe velar por la seguridad de
los bienes físicos y lógicos que maneja.
Para ello debe existir una conciencia de trabajo seguro, de resguardo de la

confidencialidad y de protección de los activos utilizados a diario en el trabajo de
cada individuo.
Por esta razón la seguridad Informática debe estar incorporada desde el principio de
todo proceso, desde el diseño para garantizar la evaluación de todos los factores
funcionales (y no solamente los técnicos) a tener en cuenta para el uso seguro del
entorno. Si esto sucede, el objetivo inicial de la seguridad habrá sido logrado.
La seguridad, entonces, debe nacer en el diseño seguro de los sistemas, de la

correcta formación de la estructura de la organización, de la adecuada distribución de
tareas y contraposición de intereses en los roles de control y ejecución de tareas.
Luego de lograr eso se deben implantar medidas de índole técnica que garanticen el
adecuado uso de los recursos y servicios solamente a los usuarios autorizados, y la
disponibilidad de los mismos.
Pero lo importante es ver que la Seguridad Informática ya no es un problema de la

gente especializada en sistemas, sino que ha salido de los laboratorios y los centros
de cómputo para instalarse en el escritorio del usuario, en donde nacen los
problemas de Seguridad.
9
3. Motivación para la realización de este trabajo
Este trabajo es la culminación de muchos años de estudio, en los que incursioné en

técnicas, modelos, formas de trabajo, teorías, estudios y descubrimientos y a través
de ellos me empapé de conocimientos en las distintas formas en que los presenta la
ciencia.
Durante los años transcurridos en la facultad, mi forma de pensar se fue modelando,

puliendo, transformando, de modo de lograr una visión distinta de la vida, no solo de
los problemas de la ingeniería.
Luego, al ingresar en el mundo laboral, descubrí que los aspectos del negocio tienen
una influencia crucial en la toma de decisiones en todos los aspectos, incluido el de
las soluciones informáticas.
En el tiempo que llevo tratando clientes, observando distintas realidades, y

conociendo su negocio, como el de la industria petrolera, el de la industria del maíz,
el de los laboratorios químicos, el de entidades estatales, el de los bancos, el de las
líneas aéreas, entre otros, aprendí que es fundamental tener en cuenta los procesos
del negocio al evaluar los procesos informáticos.
Es por eso que en este trabajo pretendo traducir el conocimiento en seguridad

informática disperso por el mundo en sus distintas formas, ya sea de conocimiento
público o el privado al que pueda acceder, para crear una herramienta de trabajo
que siga la línea de pensamiento del Ingeniero de la UBA, agregando a esta línea de
pensamiento la incursión en los procesos de negocio del cliente con que se trabaje,
para ofrecerle la mejor solución.
Particularmente como alumna, el tema me fue atrapando luego de cursar la materia

“Introducción a los sistemas distribuidos” en la que se vieron técnicas de seguridad
en el contexto del modelo TCP/IP.
En esa oportunidad la seguridad informática fue presentada con seriedad, aunque de

forma escueta, pero especialmente logró despertar mi interés personal, por lo que
comencé a investigar sobre el tema.
Un tiempo después descubrí de la existencia de la asignatura “Criptografía y

Seguridad Informática” dictada como materia optativa en la carrera Ingeniería
Electrónica. Inmediatamente me interesé en la misma y realicé los trámites
correspondientes para lograr la autorización para cursarla y la aceptación de los
créditos como materia optativa.
10
Pude cursarla efectivamente y aprobarla en el segundo cuatrimestre del año 2002, lo

cual dejó una marca importante en mi formación profesional ya desde mi condición
de alumna.
Luego continué investigando sobre el tema, pero noté que la información se

encontraba dispersa y desordenada; sin embargo también noté que la bibliografía era
en general muy específica.
Considero muy importante para la formación de los Ingenieros en Informática la

educación en Seguridad Informática.
Cualquier profesional de esta carrera debería poseer un mínimo conocimiento sobre

el tema que le permita profundizar en el aspecto que considere necesario.
Es por esto que decidí realizar este trabajo con la idea de que sirva de guía para los
colegas en el trabajo de detectar fallas de seguridad y recomendar soluciones en el
aspecto del entorno en que se esté trabajando, que a fin de cuentas este es el
trabajo del ingeniero: dar soluciones.
4. Alcance de la tesis
En esta tesis se desarrollará una metodología de trabajo.
Se describirán las tareas y subtareas a realizar para obtener resultados específicos,

se indicará un orden para realizarlas, se servirá de documentación a desarrollar para
completar informes y relevamientos, se dará un marco general para el desarrollo del
proyecto de aseguramiento del entorno en estudio, pero no se entrará en detalle en
los siguientes temas:
• Administración del proyecto:

No se entrará en detalles en la formalización del Alcance, ni en la estimación de
tiempos y costos del proyecto, ya que son tareas puramente administrativas que
no hacen al problema de aseguramiento del entorno informatizado.
• Vulnerabilidades conocidas en sistemas operativos y aplicaciones:

No se enumerarán las vulnerabilidades conocidas en software base ni en
aplicativos, ya que éstas cambian y se incrementan día a día, lo que restaría
escalabilidad y vigencia en el tiempo a la tesis.
• Implantación de las soluciones en plataformas tecnológicas específicas:
11
No se entrará en detalle en configuraciones ni ejecución de procesos específicos

para solucionar problemas de seguridad en sistemas operativos ni software
aplicativo pues se pretende hacer una metodología portable, independiente de la
plataforma tecnológica.
5. Organización del documento
El trabajo ha sido desarrollado en seis partes:
I. Índice
II. Prefacio
III. Introducción
IV. Desarrollo de la Metodología AEI
V. Conclusión
VI. Bibliografía
VII. Anexo I. MAEI – Resumen de Fases y Tareas
VIII. Anexo II. Estándares Internacionales. Reseña introductoria.
IX. Anexo III. Glosario de términos.
A su vez, la parte IV, Desarrollo de la Metodología AEI, está organizada en seis

capítulos correspondientes a cada una de las fases de la metodología que aquí se
presenta. Los capítulos son los siguientes:
1. Definición del Alcance.

2. Relevamiento.
3. Planificación.
4. Implantación.
5. Estabilización.
6. Mantenimiento.
12
III. INTRODUCCIÓN.
1. La metodología.
La metodología propuesta se compone de seis fases que agrupan etapas. Estas fases,
a su vez, desde un aspecto macroscópico se pueden generalizar en dos grandes
grupos: el estudio del entorno y la implantación de la solución.
1.1 El estudio del entorno.
En este primer grupo de fases se encuentran:
• La definición del Alcance;

• El Relevamiento;
• La Planificación.
Aquí se fija como objetivo conocer al entorno informatizado donde se implementará

la metodología, a fin de asegurarlo.
Este conocimiento implica la intervención del usuario, que aportará el conocimiento

personal desde su perspectiva, también aportará inquietudes y necesidades que
ayudarán al ES a dar la solución más satisfactoria para el cliente.
Cliente es toda entidad, empresa, organismo o persona que presente su entorno

informatizado con el fin de que el ES lo analice y lo asegure.
En este estudio, el ES investiga, observa, documenta. Investiga cómo se trabaja,

cómo está formada la empresa, qué tecnología posee, cómo ésta es utilizada.
Observa cómo se manejan los empleados, cuáles son las políticas implícitas en el
entorno con respecto al trabajo, al manejo de la información y de los bienes.
Documenta en un formato comprensible el conocimiento que él adquiere, para el
intercambio con el usuario, y como fuente para el desarrollo de la solución de la
próxima etapa de la metodología.
1.2 La implantación de la solución.
Este segundo grupo de fases comprende:
13
• La Implantación de la solución;
• La Estabilización del entorno;
• El Mantenimiento de la solución, para guardar el entorno en condiciones
confiables de seguridad.
En esta parte el ES ya conoce el entorno objetivo, por lo que se dedica a hallar la

solución que mejor se adapte al mismo.
Vuelca la planificación a la práctica, a través de la implantación de las técnicas que se

eligieron en la etapa anterior, genera y desarrolla los modelos de análisis que forman
parte del Plan de Aseguramiento y que le servirán de ahí en adelante, durante toda la
vida del ambiente.
Luego de la ejecución del Plan de Aseguramiento, el entorno objetivo se estabiliza

determinando una adecuada capacitación de los usuarios, y verificando los beneficios
logrados como resultado.
La implantación se cierra, aunque siempre queda latente una extensión de la misma

que se ocupará del registro de incidencias, de cambios en los bienes físicos y lógicos,
entre los que se considerarán las periódicas actualizaciones de software antivirus y
otras técnicas a aplicarse con regularidad para mantener el nivel de seguridad a
medida que el entorno cambia.
A continuación se exhibe un diagrama que muestra las fases:
14
Plan de
Sí
aseguramiento
aprobado?
No
Planificación Implantación de Implantación

la solución
Relevamiento Estabilización
Definición del Estudio del Entorno

Alcance Entorno protegido
Entorno
Mantenimiento
inseguro
2. Descripción de las fases.
Las siguientes son las fases de la metodología AEI, con las principales etapas que las
constituyen. Las mismas se desarrollarán en detalle en la parte IV de este trabajo,
Desarrollo de la metodología AEI.
1. Definición del Alcance

En esta fase se determinan qué aspectos, sectores, áreas y recursos se van a
proteger.
Se desarrolla en cinco subfases:
1.1 Análisis de requerimientos de usuario

En esta etapa se realiza la negociación con el cliente sobre los niveles,
sectores, servicios y activos a proteger en función de los requerimientos
que hace el usuario.
1.2 Elaboración del Alcance

Se confecciona un documento detallando objetivos claros y puntuales que se
deberán cumplir en el proceso de aseguramiento.
1.3 Aprobación del Alcance
15
En esta etapa el cliente determina la aprobación o el rechazo del Alcance, de

manera de continuar o no con el proyecto, o ver las modificaciones que él
propone.
1.4 Estimación de tiempos y costos

Parte destinada a la determinación aproximada de la duración del proyecto y
de los costos asociados: recursos financieros, recursos humanos, recursos
recurrentes y no recurrentes, etc.
1.5 Elaboración del Plan de Trabajo

Luego del análisis anterior, y con el objetivo bien claro, el ES confecciona el
plan a seguir estimando períodos de trabajo, asignación de recursos y
fechas de presentación de los entregables.
2. Relevamiento
En esta etapa el ES comienza a familiarizarse con el entorno a proteger, mediante
la identificación de los elementos que lo componen.
Comprende las siguientes etapas:
2.1 Elaboración del Relevamiento General

El ES realiza una inspección general sobre los aspectos de la organización,
de su negocio y de los bienes.
2.2 Elaboración del Relevamiento de Usuario

Consiste en obtener información del usuario respecto de las costumbres y
usos del sistema, el manejo de la información, y el nivel de conciencia del
usuario respecto a las potenciales amenazas existentes en su entorno.
Se elabora el Relevamiento de Usuario.
2.3 Análisis de vulnerabilidades

Determinación de las amenazas presentes en la organización respecto de la
seguridad.
2.4 Análisis de riesgos

Se analiza el impacto y la probabilidad de ocurrencia de las vulnerabilidades
detectadas en la etapa anterior, el riesgo que implican y los potenciales
nuevos riesgos a los que esté expuesto el entorno.
3. Planificación
Esta fase comprende el análisis detallado de los puntos a proteger estudiando el
entorno en distintos aspectos: el físico, el lógico y el de la organización.
3.1 Elaboración del Plan de Aseguramiento
16
El Plan de Aseguramiento es el documento que describe las medidas que se

tomarán para asegurar el sistema, según los objetivos planteados en el
Alcance.
3.2 Aprobación del Plan de Aseguramiento

El Plan de Aseguramiento debe ser consensuado por el cliente para
comenzar su implantación. Por motivos de presupuesto, de política, u otras
causas el responsable del proyecto por parte del cliente puede solicitar
recortes o ampliaciones del Plan, que serán analizadas por el ES quien
deberá exigir una justificación por todos los cambios solicitados, y presentar
los riesgos que estos generen en el entorno.
4. Implantación
En esta fase se llevará a cabo el Plan de Aseguramiento antes propuesto (y
aprobado) y las etapas de ajuste político y organizativo que el ES considere
necesarias.
Vemos a continuación las etapas de esta fase:
4.1 Elaboración del Relevamiento de Activos

Es una enumeración detallada de los bienes físicos y lógicos de la empresa,
junto con una asignación de responsabilidades sobre cada activo, y la
valoración de su criticidad a nivel de la seguridad, y la clasificación de la
información en cuanto a su criticidad.
En esta etapa se elabora el Inventario de Activos
4.2 Clasificación de la Información

A partir del análisis de criticidad de los activos, se procede a clasificar la
información según su grado de criticidad en cuanto a la disponibilidad,
confidencialidad e integridad. Esto permitirá determinar las medidas
necesarias de seguridad a fijar en el marco normativo de la empresa.
4.3 Elaboración/adaptación de la Normativa de Seguridad
Esta etapa de la implantación consiste en el punto de partida del proceso de

aseguramiento de un entorno. Pretende establecer las pautas, los requisitos
legales, normativos, reglamentarios y contractuales que deben cumplir
todos los miembros de la organización, sus socios comerciales, los
contratistas y los prestadores de servicios.
4.4 Publicación de la Normativa de Seguridad

Una vez elaborada, se debe dar a conocer el Manual de Seguridad de la
organización, haciendo firmar los convenios de confidencialidad existentes y
la confirmación de lectura y conocimiento de las Normas por parte de los
usuarios.
17
4.5 Implantación del Plan de Aseguramiento

En esta etapa se implantarán todas las medidas planificadas especialmente
para el entorno objetivo, en cada nivel analizado: físico, lógico y de la
organización.
4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres

El Plan de Recuperación del Entorno ante Desastres consiste en un plan para
garantizar la continuidad del negocio cuando ocurran eventuales catástrofes
de distinta índole.
Para la elaboración de este plan se deberá tener en cuenta la criticidad de

las aplicaciones y de los equipos, y el riesgo al que están expuestos, según
lo estudiado en la etapa 2.2 de la fase de Alcance.
Los desastres pueden ser naturales (inundaciones, caídas de rayos,

tormentas eléctricas), provocados intencionalmente (sabotaje, hurto,
negación de servicio), por error humano (incendios, destrucción accidental
de información) o, fallas mecánicas o eléctricas inherentes a los equipos
(rotura de discos, placas de red quemadas).
En todos los casos habrá que prever cierto número de accidentes, su

probabilidad de ocurrencia, identificar los equipos y aplicaciones críticas para
el funcionamiento del negocio, y crear un plan de contingencia que garantice
la continuidad del negocio y la recuperación del entorno informatizado en un
tiempo adecuado.
5. Estabilización
En este período se pretende estabilizar el entorno ya que a esta altura del
proyecto, seguramente ha sufrido numerosos cambios.
Se hace una observación y evaluación de la implantación en las siguientes

etapas:
5.1 Análisis de resultados

En esta etapa se cotejan los resultados obtenidos con el Alcance planteado
en la fase 1 de esta metodología y se evalúan los resultados obtenidos: los
objetivos logrados y los puntos postergados o descartados con su respectiva
justificación.
5.2 Ajuste
Esta subfase de estabilización está dedicada a realizar ajustes sobre el Plan
de Aseguramiento según los resultados obtenidos y analizados en la etapa
anterior de esta misma fase y los inconvenientes o nuevos requerimientos
que pudieran surgir en la etapa de implantación.
18
Los puntos de control que necesiten cambios, mejoras o los que surjan
durante el proyecto se tomarán en cuenta para completar y adaptar el Plan
de aseguramiento para una segunda implementación, delimitando
nuevamente su Alcance, que podrá reducirse a aplicar solamente los
cambios surgidos en esta etapa para lograr un completo aseguramiento del
entorno.
5.3 Cierre de la implantación

El cierre de la implantación se realiza cuando se concluyeron los últimos
controles que constituyen el Plan de Aseguramiento y concluidas las etapas
de concientización y capacitación de usuarios de la fase 4 de esta
metodología.
5.4 Capacitación de usuarios

Se les explica a los usuarios los cambios efectuados, los nuevos procesos y
formas de proceder ante incidencias, y la manera en que deben administrar
la seguridad para mantener el entorno protegido.
6. Mantenimiento
Esta fase comienza posteriormente a la implantación del Plan de Aseguramiento,
luego de la estabilización del entorno y se mantiene durante toda su vida.
Durante la vida del entorno ocurrirán incidencias y cambios que deberán ser
analizados y documentados, así como también se deberán llevar a cabo controles
periódicos y aplicar las correspondientes actualizaciones para mantener un nivel
confiable de seguridad en el entorno, en las siguientes subfases:
6.1 Control de incidencias

Esta fase se ocupa de analizar y documentar las incidencias ocurridas del
uso diario de los recursos, tales como:
• Mal funcionamiento de elementos de hardware;

• Ruptura de elementos de hardware;
• Anomalías en productos de software;
• Fallas en procesos;
• Detección de virus malignos;
• Averío de documentación;
• Pérdida de bienes;
• Etc.
Todo incidente, incluso los no especificados en este trabajo, deberá ser

reportado a quien corresponda, según lo especificado en la Normativa de
seguridad, mediante un Reporte de Incidencias, y asentado en el Registro de
Incidencias por el responsable a cargo. El Registro de Incidencias es un
documento destinado para tal fin.
19
[IRAM/ISO/IEC17799] hace referencia a este importante punto:

“Los incidencias que afectan la seguridad deben ser comunicados mediante
canales gerenciales adecuados tan pronto como sea posible. Se debe
concientizar a todos los empleados y contratistas acerca de los
procedimientos de comunicación de los diferentes tipos de incidencias
(violaciones, amenazas, debilidades o anomalías en materia de seguridad)
que podrían producir un impacto en la seguridad de los activos de la
organización.”
6.2 Control de cambios

Durante la vida del sistema se producirán cambios en el aspecto lógico como
físico, que deberán ser detalladamente registrados. Se deberá documentar
cada Alta, Baja o Modificación de activos en un archivo específico que
llamaremos ABM Activos, y que está directamente relacionado con el
Inventario de Activos.
Esta etapa incluye la periódica actualización de software antivirus y de

detección de intrusos, la revisión periódica del archivo de los registros de log
del sistema, el mantenimiento de las demás herramientas de las que se
hace uso durante la implantación, etc.
El ES establecerá los períodos con que se realizan los controles establecidos

en el plan de aseguramiento, según él lo crea conveniente para el caso en
estudio.
A continuación se muestra una tabla con las fases y etapas de esta metodología y la
documentación propuesta para su implantación:
FASE / ETAPA ACTOR ENTREGABLE
1 Definición del Alcance
1.1 Análisis de requerimientos de usuario ES, cliente Documento de Requerimientos de

Usuario
1.2 Elaboración del Alcance ES, cliente Alcance
1.3. Aprobación del Alcance cliente
1.4 Estimación de tiempos y costos ES
1.4.1 Costos capitales
1.4.2 Costos recurrentes
1.4.3 Costos no recurrentes
1.5 Elaboración del Plan de Trabajo ES Plan de Trabajo
2 Relevamiento
2.1 Elaboración del Relevamiento General ES, Relevamiento General

usuarios
2.2 Elaboración del Relevamiento de Usuario ES Relevamiento de Usuario
20
2.3 Análisis de vulnerabilidades ES Mapa de Vulnerabilidades
2.4 Análisis de riesgos ES Informe de Riesgos
3 Planificación ES
3.1 Elaboración del Plan de Aseguramiento ES Plan de Aseguramiento
3.1.1 Protección física ES Plan de Aseguramiento, Mapa de

Elementos de Red
3.1.1.1 Protección de las instalaciones ES Plan de Aseguramiento
3.1.1.2 Protección de los equipos ES Plan de Aseguramiento, Mapa de

Elementos de Red
3.1.2 Protección lógica ES Plan de Aseguramiento, Mapa de

Usuarios, Inventario de Backups,
Documento de Actualización de
Software, Tabla de Permisos sobre
Activos Lógicos
3.1.2.1 Protección de la información ES Plan de Aseguramiento
3.1.2.2 Protección de los Sistemas Plan de Aseguramiento, Mapa de

Operativos Usuarios, Registros y archivos de Log
3.1.2.3 Protección de los datos ES Plan de Aseguramiento, Tabla de

Permisos sobre Activos Lógicos,
Documento de actualización de
Software, Inventario de backups,
3.1.2.4 Protección a nivel de la organización ES Plan de Aseguramiento
3.2 Aprobación del Plan de aseguramiento cliente
4 Implantación
4.1 Elaboración del Relevamiento de Activos ES Inventario de Activos, ABM Activos
4.1.1 Inventario de activos Inventario de Activos Físicos,

Inventario de Activos Lógicos
4.1.2 Rotulación de activos ES Inventario de Activos
4.1.3 Análisis de criticidades ES Inventario de Activos
4.2 Clasificación de la información ES
4.3 Elaboración/adaptación de la Normativa ES Manual de Seguridad

de Seguridad
4.3.1 Interiorización del experto con la cliente Organigrama, documentación del

política y negocio de la organización proceso comercial, etc.
4.3.2 Elaboración/adaptación de la ES Manual de Seguridad

Normativa de Seguridad
4.3.3 Aprobación de la Política de Seguridad
4.4 Publicación de la Normativa de

Seguridad
4.4.1 Implantación de una campaña de Comunicados, Presentaciones,

concientización Documentación,
4.4.2 Capacitación de usuarios Presentaciones, Documentación,

Manual de Seguridad
4.5.1 Implantación a nivel físico ES Inventario de Activos, ABM Activos
4.5.2 Implantación a nivel lógico ES Inventario de Activos, ABM Activos
4.5.3 Implantación a nivel de la
21

organización
4.6 Elaboración del Plan de Recuperación Tabla de Criticidades por Equipo,

del Entorno ante Desastres Tabla de Criticidades por Servicio,
Tabla de Criticidades por Aplicación,
PRED, Procedimiento de Declaración
de la emergencia, Procedimiento de
Recuperación de las prestaciones,
Procedimiento de Reestablecimiento
de las Condiciones Normales
5 Estabilización
5.1 Análisis de resultados ES Informe de Implantación
5.2 Ajuste
5.3 Cierre de la implantación ES Informe de Cierre de la Implantación
5.4 Capacitación de usuarios ES Manual de Seguridad, Manual de

Procedimientos sobre Reporte de
Incidencias, presentaciones,
Manuales, Folletos, Cursos,
Comunicados
6 Mantenimiento
6.1 Control de incidencias ES, cliente Reportes de Incidencias, Registro de

Incidencias
6.2 Control de cambios ES, cliente Formulario de Control de Cambios,

ABM Activos, Documento de
Actualizaciones de software
22
IV. DESARROLLO DE LA METODOLOGÍA AEI
La metodología de Aseguramiento de Entornos Informatizados (MAEI) de desarrolla

en las siguientes fases:
1. Definición del Alcance

2. Relevamiento
3. Planificación
4. Implantación
5. Estabilización
6. Mantenimiento
Estas fases, como vimos en la introducción, se categorizar formando dos grandes

grupos según el objetivo que persiguen: el estudio del entorno y la implantación de
la solución.
Partiendo de un entorno inseguro o desprotegido, a través de las primeras tres fases

de la MAEI se logra un estudio del entorno que le aporta el ES el conocimiento
necesario para encarar la solución de los problemas de seguridad detectados.
Es en esta parte en que el ES delimita el entorno elaborando el Alcance, que abarca

los activos lógicos y físicos afectados en el análisis.
Una vez delimitada el área de trabajo o entorno objetivo, se procede a realizar el

sondeo que conducirá al conocimiento funcional y técnico detallado del entorno, sus
activos, los empleados, los procesos y procedimientos involucrados que se registrará
en los respectivos documentos de Relevamiento.
Para finalizar esta primera parte del trabajo, el ES construye el Plan de

Aseguramiento del Entorno que contendrá todos los objetivos de control deseados y
la forma de implantarlos en el entorno para asegurarlo.
Todas las tareas desarrolladas en esta etapa inicial conducen a la familiarización del
Experto con el entorno y su conocimiento. Esto le permitirá al Experto determinar las
mejores medidas a tomar para asegurar el entorno objetivo.
Esta Tesis se basa en estándares internacionales, Normas y las mejores prácticas

profesionales, por lo que no es necesario poseer un conocimiento especializado en
Seguridad Informática para utilizar la Metodología AEI. Sin embargo, se confía en el
buen criterio del Ingeniero o Licenciado en Análisis de Sistemas que la utilice para
lograr la mejor implementación de la solución.
23
Continuando con la metodología, la segunda parte del trabajo consiste en llevar a la

práctica los controles planificados antes, en la fase que llamamos Implantación.
Luego de la implantación de los controles y las mejoras en los procesos que conducen
a la obtención de los objetivos fijados en el Plan, el ES deberá realizar un balance
ponderando los objetivos fijados al principio del proyecto con los resultados obtenidos
en la última etapa. Su trabajo aquí es evaluar la implantación, su grado de éxito y
realizar los ajustes al Plan que sean necesarios para completar el aseguramiento del
entorno. A esta fase la llamamos Estabilización.
Finalmente nace una fase que se mantendrá a lo largo de toda la vida del entorno: la
fase de Mantenimiento, que acompaña todos los cambios en el entrono persiguiendo
la preservación de su seguridad.
En esta etapa, la etapa final de la MAEI, el entorno se convierte en seguro y se

mantiene de esa forma hasta que se implanten cambios lo suficientemente grandes
como para que se deba considerar la construcción de un nuevo Plan de
Aseguramiento. En este caso la metodología EAI permite reiniciar el proceso
haciendo mucho más cortas las etapas iniciales, saltando tareas de sondeo como la
realización del Relevamiento General y el Relevamiento de Usuario, que ya han sido
realizados no requieren mayor detalle.
Como vimos, entonces, partiendo de un entorno inseguro, realizando las tareas que
forman parte de las primeras tres fases de la MAEI, en una primera etapa se logra el
conocimiento del entorno. Siguiendo con la implantación de la solución, a través de
las tres últimas fases compuestas por tareas de implantación, control y mejora
continua, se obtiene un entorno seguro, que es el objetivo de este trabajo.
24
1 DEFINICIÓN DEL ALCANCE
Contenido:
1.1 Análisis de Requerimientos de Usuario

1.1.1 Documento de Requerimientos de Usuario
1.1.2 Ejemplo - Documento de Requerimientos de Usuario
1.2.1 Alcance
1.2.2 Ejemplo - Alcance
1.4 Estimación de tiempos y costos
1.4.3 Costos No recurrentes
25
1.1 Análisis de Requerimientos de Usuario
En esta etapa el ES se pone en contacto con el cliente (la persona o entidad

interesada en asegurar el entorno objetivo) y escucha e interpreta lo que el usuario
le pide.
En general el usuario no sabe qué es lo que quiere asegurar, por eso es tarea de ES
orientarlo en el campo mostrándole los distintos aspectos que se deberían asegurar,
para determinar a qué nivel el usuario desea que se realice el proyecto de
aseguramiento.
A partir de esta decisión el ES concentrará su esfuerzo en el Relevamiento General y

en el Relevamiento de usuario, haciendo foco en el o los aspectos que el usuario
señaló.
Muy probablemente el usuario no tenga claro siquiera qué nivel desea proteger
(físico, lógico u organizacional) y dejará la decisión en manos de ES.
El ES puede, entonces, pasar a las etapas siguientes de esta fase de la MAEI para
detectar a grandes rasgos las mayores falencias en cuanto a seguridad por nivel (a
so apunta el Relevamiento de Usuario) y ofrecer los resultados al cliente para que
este decida el camino a seguir.
1.1.1 Documento de Requerimientos de Usuario
De una forma u otra, el ES registrará el pedido del usuario en un documento llamado

Documento de Requerimientos de Usuario, que contendrá la voluntad del usuario
respecto de los niveles y elementos a asegurar.
El Documento de Requerimientos de Usuario contendrá la siguiente información:
Niveles a asegurar:
• Nivel físico;
• Nivel lógico;
• Nivel de la Organización.
Elementos a asegurar por nivel:
26
• Nivel físico:
o Elementos a asegurar del nivel físico.
• Nivel lógico:
o Elementos a asegurar del nivel lógico.
• Nivel de la organización:
o Elementos a asegurar del nivel de la organización.
1.1.2 Ejemplo - Requerimientos de Usuario
Niveles a asegurar:
• Nivel físico;
• Nivel lógico.
Elementos a asegurar por nivel:
• Nivel físico:
o Protección del acceso a los servidores;
o Protección de los equipos;
o Controlar el acceso del personal y determinar a qué usuarios se les puede
permitir el uso de los distintos recursos y a cuáles se les debe restringir.
• Nivel lógico:
o Poner contraseñas para el acceso a los servidores;
o Hacer backup de los datos más importantes;
o Ver que nadie (usuarios no autorizados) puedan leer la base de datos de la
nómina de personal.
A partir de los requerimientos obtenidos del usuario se establece el alcance que

tendrá el proyecto de aseguramiento del entorno informatizado objetivo.
27
En esta etapa se determinan claramente todos los puntos sobre los que se elaborará
el Plan de Aseguramiento y se registran en un documento elaborado para tal fin. Este
documento se llamará Alcance.
Cabe mencionar que el Alcance es elaborado por el ES con una adecuada

colaboración del cliente, que deberá asumir responsabilidad sobre los temas que se
decida dejar fuera del proyecto. Éste deberá reflejar objetivos claros y puntuales que
se deberán cumplir en el proceso de aseguramiento.
1.2.1 Alcance
El Alcance deberá contener la siguiente información:
Objetivo
Se define claramente lo que se pretende lograr en el proyecto.
Los objetivos deben responder al acrónimo SMART, que enmarca las prácticas
fundamentales necesarias para alcanzar alta motivación y mejora para conseguir el
objetivo propuesto:
S : Simple, específico con un significado preciso.
M: Meaningful (con significado), motivante, mensurable.
A: Aceptable, alcanzable orientado a la acción, acordado, activable, asignable.
R: Realístico, susceptible a revision, relative, compensatorio, razonable, orientado a

resultados, relevante a una misión.
T: Timelines (líneas de tiempo), con registro de fecha, relacionado con el tiempo,

tangible, basado en tiempo, específico en el tiempo, limitado por el tiempo,
relacionado con el tiempo, verdadero.
Participantes del proyecto
• Responsable por la empresa objetivo:

Ejecutivo de nivel gerencial que avala el proyecto.
• Experto en Seguridad (ES):

Profesional responsable del diseño y planificación del Plan de Aseguramiento del
entorno.
28
• Recursos afectados al proyecto:

Son personas que colaborarán durante todo el proyecto liderado por el ES.
Definición del Entorno
Se debe determinar con precisión cuál será el entorno donde se implementará el

proyecto. El Alcance estará circunscrito a ese entorno y todas las referencias que se
hagan a él serán en relación a esta definición.
El entorno puede ser desde un equipo informático hasta una Corporación distribuida
en distintas regiones geográficas; puede definirse como el edificio que alberga a la
empresa objetivo o como el Centro de Cómputos (CC) o Centro de Procesamiento de
Datos (CPD) donde se encuentran los servidores.
Niveles que cubrirá el proyecto
Esto es, definir a qué nivel se hará al estudio para lograr el aseguramiento.
Como se definió en la introducción, el estudio se puede enfocar en alguno o todos

estos niveles:
• Nivel físico;
• Nivel lógico;
• Nivel de la organización.
Hitos a cubrir en cada nivel:
Definir a alto nivel qué hitos se deberán cumplir a lo largo del proyecto.
Elementos fuera del Alcance
Ítems que se haya decidido dejar fuera del proyecto por diversos motivos;
Planificación del trabajo
29
Definición de las etapas o fases en que se desarrollará el proyecto, a nivel macro, sin
entrar en detalle.
Entregables de cada etapa
El cliente debe ver el avance del proyecto a medida que transcurre el tiempo. Para
eso se define una serie de documentos o entregables de cada etapa del proyecto que
reflejarán el trabajo hecho.
Consideraciones adicionales
Consideraciones que el ES crea necesarias para el proyecto.
1.2.2 Ejemplo - Alcance
El siguiente ejemplo pretende mostrar los objetivos planteados en un Alcance

genérico, que abarca parte de los elementos susceptibles de ser analizados:
Objetivo
Crear e implementar los controles y medidas necesarias para cumplir con el nivel
medio de seguridad, según los estándares de la empresa, en el corto plazo.
Participantes del proyecto
Responsable por la empresa objetivo:

Gerente del área de sistemas, Ing. Francisco López.
Recursos afectados al proyecto:

Project leader: ES
Recursos:
Carina Rodríguez
Pablo Benigno
Santiago Carpenari
Manuel Lopez
Cintia Kers
Definición del Entorno
Se define como entorno al Centro de Procesamiento de Datos (CPD) de la compañía.
30
Niveles que cubrirá el proyecto
Nivel físico;
Nivel lógico;
Nivel de la organización.
Hitos a cubrir en cada nivel
Alcance a nivel Físico:

Protección del edificio contra el acceso físico no autorizado;
Protección de las oficinas del sector de Cómputos contra el acceso físico no
autorizado;
Protección del hardware e instalaciones del sector de Cómputos y de Ventas
contra el acceso físico no autorizado;
Protección de la red de comunicaciones de toda la empresa contra el acceso
físico no autorizado;
Protección de Cables;
Protección de Servidores;
Protección de la conexión gíreles.
Alcance a nivel Lógico:

Protección de los datos del sector de Cómputos contra el acceso no
autorizado;
Protección de la integridad de los datos del sector de Cómputos;
Protección de las aplicaciones de toda la empresa contra el acceso no
autorizado;
Implantación de restricciones de uso de software
Implantación de un sistema de administración de usuarios y contraseñas;
Alcance a nivel de la organización:

Elaboración de la Normativa de Seguridad de la empresa;
Revisión de la estructura de la organización en el sector de Cómputos;
Protección de las marcas de la empresa;
Capacitación de los empleados.
31
Elementos fuera del proyecto
Los elementos pendientes que no formarán parte de este proyecto de aseguramiento

del entorno:
Regularización de la situación de las licencias de software;

Protección del hardware e instalaciones del sector de Diseño y Manufactura;
Implantación de medidas de prevención de catástrofes naturales:
Incendios;
Inundaciones;
Cortocircuitos;
Etc;
Elaboración de un Plan de Recuperación del Entorno ante Desastres.
Planificación del trabajo
El proyecto se llevará a cabo en las siguientes etapas:

Relevamiento;
Planificación;
Implantación;
Estabilización;
Mantenimiento.
Entregables de cada etapa:
Etapa 1:
Relevamiento general;
Relevamiento de usuario;
Mapa de vulnerabilidades;
Informe de Riesgos.
Etapa 2:
Plan de Aseguramiento;
Documento de Administración de Backups;
Documento de Actualización de Software;
Mapa de Usuarios;
Tabla de Permisos sobre Activos Lógicos;
32
Test de viabilidad.
Etapa 3:
Políticas de Seguridad, Normas, Procedimientos, Estándares Técnicos,
Manuales de Procedimiento;
Inventario de Activos;
ABM de Activos;
Presentaciones y comunicados a usuarios como medio de capacitación.
Etapa 4:
Informe de Implantación;
Informe de cierre de la implantación.
Etapa 5:
Registro de Incidencias.
Como documento inicial del proyecto el Alcance deberá ser aprobado por los
responsables del lado del cliente, previo consenso con el ES encargado de la
elaboración del Plan de Aseguramiento del entorno informatizado objetivo.
1.4 Estimación de tiempos y costos.
Como en todo proyecto de IT, es necesario realizar una estimación del tiempo que se
deberá invertir y los recursos a asignar para culminar con éxito y en un tiempo finito
el proyecto de aseguramiento del entorno.
Para la estimación de tiempos no existe una fórmula que determine el tiempo que
llevará cada tarea. La duración de las mismas depende de muchos factores:
• de la cantidad de recursos asignados;

• de la calidad de esos recursos;
• de la carga que se les pueda asignar a esos recursos;
• de la experiencia de los recursos humanos involucrados;
33
• del tamaño del entorno;

• de la complejidad del entorno;
• de la estabilidad económico-financiera de la empresa objetivo (pues el proyecto
puede perder prioridad ante situaciones de crisis);
• del apoyo del nivel gerencial y la seriedad con que tomen el proyecto (pues
muchas decisiones surgirán a ese nivel, como la aprobación de la política de
seguridad).
Es por eso que la experiencia le dará al ES la capacidad para medir el tiempo que le
llevará hacer cada tarea según los parámetros antes mencionados.
La estimación de costos, por otro lado, es una variable fundamental a determinar, en

la que la experiencia del ES se utiliza para la asignación de recursos, a partir de la
cual se calculan los costos.
Para ello existen métodos, pero no es el fin de este trabajo entrar en detalle al
respecto.
En esta sección mencionaremos los costos que se deberán tener en cuenta a nivel
general. Como en todo este trabajo, se deja la responsabilidad al ES de bajar el nivel
de análisis, para que, siguiendo esta Metodología para el Aseguramiento de Entornos
Informatizados, llegue al punto de reflejar el caso en el que está trabajando.
Los costos que genera un proyecto de IT como éste se pueden categorizar en 3

clases:
• costos capitales;
• costos recurrentes;
• costos no recurrentes.
Son los costos para adquirir, desarrollar, o instalar los principales bienes o activos.
Un activo principal es una ventaja palpable que tiene una vida útil de más que un año
y se pretende continuar su uso con el tiempo.
Activos capitales estándar incluyen hardware de computadora (como computadoras

personales e impresoras) y software comprado como un paquete o desarrollado a
pedido.
Los siguientes son algunos ejemplos de costos capitales:
34
• Equipos de procesamiento de datos:

o CPUs;
o Workstations;
o Laptops;
o Unidades de almacenamiento externo (Discos rígidos externos);
o Monitores;
o Impresoras;
o Scanners.
• Equipos de telecomunicaciones:
o Routers;
o Switches;
o Hubs;
o Modems;
o Servidores;
o Cableado de red.
• Software:
o Sistemas operativos;
o Aplicaciones;
o Software de comunicaciones;
o Utilitarios;
o Firewalls;
o IDSs.
• Otros:
o UPSs o SAIs;
o Generadores de energía eléctrica;
o Mueblería.
Los costos recurrentes son los costos que se presentan con regularidad.
35
En contraste con los costos capitales, los costos recurrentes deben ser tratados como
si fueran a ser pagados completamente al ser facturados.
Los costos recurrentes en general son costos operativos, en muchos casos fáciles de
definir como alquileres de equipos y salarios. Otros son más difíciles de distinguir de
los costos capitales, como por ejemplo la compra de hardware y software, que
pueden ser tratados como costos capitales o recurrentes.
En el entorno de IT, los costos recurrentes son los siguientes:
• Salarios
Incluye los costos por todos los empleados involucrados directa o indirectamente
con el proyecto, encargados del manejo, el soporte y la administración del
proyecto en todas sus fases.
• Contratos
Contratos a ser pagados regularmente durante la vida del entorno, como por
ejemplo:
o Contratos de mantenimiento de hardware;
o Contratos de mantenimiento de software;
o Contratos de operación externa de IT (outsourcing).
• Hardware:
o Alquiler de equipos;
o Actualización de equipos;
o Mantenimiento interno.
• Software:
o Actualización de software;
o Licencias de software;
o Mantenimiento interno.
• Telecomunicaciones:
o Alquileres;
o Transmisión de datos;
o Mantenimiento.
• Recursos humanos:
36
o Salarios;
o Seguros;
o Capacitación;
o Provisiones;
o Viajes.
1.4.3 Costos No recurrentes
Los costos no recurrentes son los que se presentan una sola vez durante la vida del
proyecto de seguridad. Aunque aparecen una vez, suelen ser los mayores costos del
proyecto.
Por ejemplo, el costo de los empleados que se contratan para hacer tareas exclusivas
en proyecto, y que luego de terminado se retiran sin participar en ningún otro
proyecto, es un costo no recurrente.
• Salarios;
• Contratos;
• Estudios
• Análisis de requerimientos, diseño, performance, estudios de viabilidad, etc;
• Conversión de costos;
• Provisión de datos;
• Testing;
• Auditorías internas;
• Acondicionamiento del entorno;
• Costos incidentales;
• Entrenamiento;
• Viajes;
• Documentación.
Una vez estimados los tiempos y los costos a invertir en el proyecto, el ES está en
condiciones de elaborar la propuesta de trabajo que contendrá el Plan de trabajo que
especifique las tareas y los recursos necesarios para desarrollarlas.
37
El paso siguiente a la elaboración del Alcance, y una vez aprobado por los
responsables, es la elaboración del Plan de Trabajo.
Este Plan de Trabajo no es más que la organización de las tareas a desarrollar

durante la duración estimada del proyecto.
En todo plan se fijan objetivos o “hitos” a cumplir. Estos hitos están asociados a una
serie de tareas necesarias para lograr el objetivo, que tendrán un período asignado.
Una buena práctica es fijar las fechas de inicio y fin de la tarea para que los períodos
no se extiendan demasiado.
Cada subetapa del proyecto tendrá (o no) entregables, documentos o resultados para
los que se trabaja en el período asignado.
A su vez, el comienzo de una tarea puede depender del resultado de otras tareas,
por lo que no podrá comenzar hasta que todas las tareas de las que depende hayan
finalizado.
Puede haber tareas que se solapen, cuyo resultado alimente otra tarea, etc.
Las posibilidades de dependencia son múltiples, por lo que es importante organizarlas

con anticipación previendo posibles retrasos o inconvenientes.
El Plan de Trabajo deberá incluir, como mínimo:
• Nombre del proyecto;

• Duración total del proyecto;
• Períodos laborales;
• Hitos;
• Tareas;
• Fases;
• Duración de las tareas;
• Fecha de Inicio del proyecto;
• Fecha de Inicio de cada tarea;
• Fecha de Fin del proyecto;
• Fecha de Fin de cada tarea;
• Recursos asignados por tarea;
• Solapamiento de tareas;
• Tareas predecesoras o tareas dependientes de otras;
• Entregables por hito;
38
• Entregables por tarea.
Ejemplo
Como ejemplo incluimos una imagen de un Plan de Trabajo de un proyecto de

normativa de seguridad.
Este proyecto se desarrolla en dos semanas, y está compuesto de 17 tareas.
Id Task Name Duración

ay '04 23 may '04 30 may '04
M M J V S D L M M J V S D L M M
1 MAEI - Manual de Seguridad 10 días
2 Sondeo en sede central 3 días
3 Sondeo General 1 día
4 Política general de seguridad 2 días
5 Responsabilidades de seguridad 2 días
6 Clasificación y tratamiento de la información 2 días
7 Comunicaciones de redes de datos 2 días
8 Administración de usuarios y recursos 2 días
9 Protección ante virus informáticos 2 días
10 Protección física 2 días
11 Copiasde respaldo (backup) 2 días
12 Ambientes de procesamiento 2 días
13 Continuidad de procesamiento 2 días
14 Generación de registros de eventos 2 días
15 Sondeo en planta 1 día
16 Revisión documentación 1 día
17 Reunión de presentación con directores/gerente 1 día
18 Análisis documentación con directores/gerentes 3 días
19 Actualización de la documentación 3 días
20 Generación versión final 1 día
39
2 RELEVAMIENTO
Contenido:
2.1 Elaboración del Relevamiento General

2.1.1 Relevamiento General
2.2.1 Relevamiento de Usuario
2.2.2 Asignación de puntaje
2.2.3 Aclaración sobre las preguntas
2.2.4 Resultados de la evaluación
2.2.5 Evaluación del entorno
2.2.5.1 Referencias al puntaje obtenido en el test por nivel
2.2.5.2 Configuraciones de resultados
2.3 Análisis de vulnerabilidades
2.3.1 Conocer al enemigo
2.3.2 Ejemplo – Atacantes
2.3.3 Las amenazas
2.3.4 Análisis de Vulnerabilidades
2.3.4.1 Aspectos funcionales
2.3.4.2 Análisis de la documentación
2.3.4.3 Análisis de las aplicaciones y equipos
2.3.4.3.1 Intento de Penetración
2.3.4.3.2 Herramientas de análisis de vulnerabilidades
2.3.5 Mapa de Vulnerabilidades
2.3.5.1 Vulnerabilidades a nivel físico
2.3.5.2 Vulnerabilidades a nivel lógico
2.3.5.3 Vulnerabilidades a nivel de la organización
2.4 Análisis de Riesgos
2.4.1 Informe de Riesgos
2.4.2 Ejemplo – Informe de Riesgos
40
2.1 Elaboración del Relevamiento General.
Para desarrollar un Plan de Aseguramiento, el ES debe conocer la empresa objetivo,

su organización y sus procesos de negocio.
Sobre esta información se basará una serie de estudios que dependerá de muchos de
los factores aquí relevados. Por ejemplo, para la correcta administración de los
usuarios se deberá tener en cuenta si la empresa tiene procesos de manufactura o
solamente administrativos, pues en estos dos ámbitos suelen ser muy distintos los
circuitos de autorización de alta de usuarios, etc.
Es por eso que aquí se propone una serie de puntos de control sobre los que se
deberá investigar, cuestionar y observar:
• El rubro de la empresa, y conocer sobre su negocio;
• La calidad de la sede en cuanto al manejo del negocio (Administrativa,

productiva, comercial, etc);
• El tamaño de la empresa y su distribución física;
• Detalles sobre la infraestructura edilicia (cantidad de edificios, pisos u oficinas) y

su distribución física;
• Que exista una definición de funciones y estructura de comunicación en la

empresa;
• Que exista un área de Seguridad Informática;
• Que existan roles adecuados para la supervisión de la seguridad de las

aplicaciones y equipos que existen en el entorno, y la realización de controles que
garanticen la autorización y el adecuado uso de los recursos;
• Organización de personal – jerarquías dentro de la empresa;
• Que exista un encargado de soporte para las aplicaciones y equipos tratados;
• La arquitectura de la red;
• La tecnología que maneja la empresa (hardware y software);
41
• Las aplicaciones específicas que apoyan al negocio;
• Analizar la existencia de documentación en relación a:

o Un marco normativo que defina la política de la empresa, y siente las bases
para el desarrollo de procedimientos y estándares técnicos;
o Relaciones formales y conocidas por el personal, referidas a la documentación
de carácter obligatorio y deseable que debe ser desarrollada y mantenida;
o Los requerimientos de tecnología, de procesamiento, de archivos y de
interfases para los usuarios.
Para verificar estos puntos de control el ES puede realizar las siguientes tareas:
• Revisar la documentación del proceso de negocio de la empresa objetivo con el

fin de conocer su estructura y funcionamiento;
• Entrevistar a los responsables del nivel gerencial para obtener información sobre
el manejo del negocio y sobre los aspectos críticos del mismo;
• Entrevistar a los responsables del nivel gerencial para obtener información sobre
el manejo del negocio y los activos de información que los soportan;
• Obtener de los usuarios, información adicional sobre el entorno a relevar, tales

como:
o Satisfacción funcional de los requerimientos de información de los usuarios;
o Confianza de los usuarios en la información que manejan estos equipos y
aplicaciones;
• Entrevistar al personal del Área de Sistemas a fin de identificar la documentación

existente y los procedimientos formales e informales relacionados con el
desarrollo, autorización y mantenimiento de la misma;
• Analizar la documentación existente en cuanto a estructura, niveles de

aprobación, vigencia, contenido, publicación y distribución entre los involucrados;
• Identificar los componentes de hardware presentes en las instalaciones;
• Identificar los componentes de software de base;
42
• Entrevistar al personal de comunicaciones para comprender globalmente las

facilidades de acceso a través de Internet y los mecanismos de seguridad
implantados para prevenir el acceso a dichas facilidades.
2.1.1 Relevamiento General
El sondeo propuesto en el Relevamiento General deberá documentarse como parte

de los entregables del proyecto de aseguramiento del entorno. Para esto se propone
el siguiente esquema que resume los puntos de control básicos a relevar:
• Rubro de la empresa
• Calidad de la sede
o Administrativa, productiva, comercial, etc;
• Negocio
o Descripción;
o Procesos de negocio;
o Productos;
o Servicios;
o Actividades rutinarias;
o Actividades extraordinarias;
o Actividades excepcionales.
• Dependencia:
o Es una empresa con presencia multinacional?
o El negocio se ve afectado por la actividad de la empresa en otros países?
o El negocio se ve afectado por la actividad de la empresa en otras provincias?
o El negocio se ve afectado por la actividad de la empresa en otras ciudades?
o El negocio se ve afectado por la actividad de la empresa en otros edificios?
• Si es multinacional:
o Se trata de una sede o de la corporación?
o Cantidad de países donde opera;
o Listado de países donde opera.
• Información edilicia:
43
o Cantidad de edificios;
o Cantidad de pisos por edificio;
o Cantidad total de pisos;
o Cantidad de oficinas por piso;
o Cantidad total de oficinas.
• Red
o Arquitectura física;
o Arquitectura lógica;
o Protocolos;
o Cableado.
• Hardware
o Tipos de maquinarias (mainframes, terminales, PCs);
o Cantidad de equipos por tipo;
o Elementos de Red (switches, routers, hubs, etc.);
o Cantidad de elementos de red;
o Telefonía (centrales telefónicas, teléfonos);
o Cantidad de teléfonos;
o Otros elementos (UPSs, impresoras, scaners, etc.);
o Cantidad de elementos por tipo.
• Software
o Sistemas Operativos;
o Utilitarios;
o Bases de datos;
o Software de gestión;
o Otros;
o Cantidad de licencias.
• Personal
o Jerarquía;
o Cantidad de áreas;
o Cantidad de sectores;
o Personal: Contabilización por puesto (gerentes, administrativos, usuarios, no
usuarios, externos).
44
• Administración
o ¿Existe un área de desarrollo de software?
o ¿Existe un área de control de calidad de software?
o ¿Existe de un área de Seguridad Informática?
o ¿De quién es la responsabilidad de la administración de los equipos (de la
corporación, del país, de la sucursal, del sector)?
o ¿Cuántas personas abarca?
o ¿De quién es la responsabilidad de la operación de los equipos ((de la
corporación, del país, de la sucursal, del sector)?
o ¿Cuántas personas abarca?
En esta etapa del relevamiento el ES realiza una investigación sobre el entorno

objetivo con el fin de obtener un panorama de la situación actual y conocer su forma
de funcionamiento, y detectar, a grandes rasgos, fuentes de debilidades para luego
realizar un estudio profundo enfocado en los puntos hallados, en la etapa llamada
Análisis de Vulnerabilidades.
En este análisis, el ES verificará los siguientes objetivos de control:
• Que se haya definido y documentado un modelo de administración de la

seguridad;
• Que existan estándares y procedimientos de trabajo definidos para todas las

tareas del área;
• Que el circuito de trabajo responda a criterios de seguridad, eficiencia y

productividad;
• Que exista un perímetro de seguridad para los equipos de procesamiento crítico;
• Que se apliquen medidas de seguridad física en el entorno de trabajo de los

usuarios finales;
• Que los equipos informáticos sean utilizados sólo con fines autorizados y
siguiendo los procedimientos establecidos;
• Que existan procedimientos de control para la utilización de los recursos;
45
• Que exista un encargado de soporte del mantenimiento para las aplicaciones

analizadas;
• Que los usuarios tienen conciencia de los problemas de seguridad informática y

están informados acerca de los riesgos existentes;
• Que existen adecuados procedimientos manuales o automatizados de control de

cambios a los programas y de toma de nuevos requerimientos de usuarios;
• Que existen acuerdos de confidencialidad firmados por los usuarios para el

manejo de la información que tratan los sistemas;
• Que exista un marco normativo que defina la política de la empresa, y siente las
bases para el desarrollo de procedimientos y estándares técnicos;
• Que existan relaciones formales y conocidas por el personal, referidas a la

documentación de carácter obligatorio y deseable que debe ser desarrollada y
mantenida;
• Que exista documentación de usuario que especifique los requerimientos de

tecnología, de procesamiento, de archivos y de interfases;
• Que se encuentre implantado adecuadamente un ambiente general de control de

accesos propio de las aplicaciones y recursos a efectos de prevenir el uso no
autorizado de funciones interactivas, tanto desde conexiones desde la red interna
como desde Internet.
Para verificar estos puntos de control el ES y su equipo de trabajo puede realizar las
siguientes tareas:
• Entrevistar a los usuarios a fin de obtener información sobre el entorno a relevar,

en los siguientes aspectos:
o Físico;
o Lógico;
o De la organización.
Para ello el ES explicará a los usuarios el objetivo de la charla, y dará todo el

detalle necesario para que las respuestas de los mismos sean válidas.
• Entrevistar a ciertos usuarios finales a efectos de verificar:
46
o Cuán involucrados están con la seguridad en el entorno donde trabajan;

o Cómo reaccionan ante incidencias de seguridad y cómo realizan solicitudes de
cambios;
o Si conocen el marco normativo que define la política de la empresa.
En estas entrevistas, se sugiere realizar un test en cada uno de los diferentes

departamentos de la organización, y, dentro de estos, en los distintos sectores.
Este test tiene por fin obtener una medida de lo expuesto que se encuentra el
ambiente a vulnerabilidades, fallas en la cultura de trabajo, vicios en la organización,
el nivel de información que manejan los empleados y su nivel de conciencia respecto
de la seguridad, etc. O sea, una medida general de lo expuesto que se encuentra el
sistema a los ataques informáticos por nivel.
Esto servirá como introducción al ES para la construcción del Mapa de

Vulnerabilidades y para fijar los objetivos del Plan de Aseguramiento del sistema.
El siguiente esquema pretende mostrar las principales puertas de ataques que se

deben proteger, y evaluar, en un entorno informatizado:
Una vez recompilada como mínimo esta información, la Metodología AEI prevé la
intervención del usuario como fuente de conocimiento del ES.
A continuación se especifica el documento formal que materializa la intervención

directa del usuario como referente de las características del entorno en estudio.
47
El Relevamiento de Usuario consiste en una serie de preguntas separadas en tres

módulos por nivel. Los módulos corresponden a los niveles físico, lógico y de la
organización respectivamente.
El Experto en Seguridad, evaluará la criticidad de cada punto asignando un valor

según la respuesta obtenida.
2.2.1 Relevamiento de Usuario
AREA:
SECTOR:
CPU:
EMPLEADO:
ANTIGÜEDAD:
Nº NIVEL SÍ NO PUNTOS
NIVEL FÍSICO
1 ¿El espacio es compartido? (oficina propia, box del sector, común)

2 ¿Hay otros sectores de la empresa en el mismo piso?
3 ¿Se accede a esta Workstation con llave propia del sector?
4 ¿Existe algún circuito de circulación abierto hasta esta Workstation?

5 ¿Está cerca de alguna puerta?
6 ¿Está cerca de algún pasillo?
7 ¿Está cerca de alguna ventana?
8 ¿Guarda la documentación impresa o magnética bajo llave propia?
¿Guarda la documentación impresa o magnética bajo llave común al

9
sector?
¿Maneja algún tipo de codificación para la rotulación de diskettes, cintas,

10
CDs, etc?
11 ¿Posee conexión física a una LAN?
12 ¿Posee conexión física a una WAN?
13 ¿Tiene acceso a Internet?
14 ¿Hay cables al descubierto?
15 ¿Usa esta Workstation otro usuario regularmente?
¿Trabaja con servidores de uso exclusivo de su sector o son compartidos

16
por más de un sector ( por ejemplo Desarrollo y Prueba)?
48
Nº NIVEL SÍ NO PUNTOS
SUBTOTAL NIVEL FÍSICO
NIVEL LÓGICO
17 ¿Posee conexión permanente a Internet?
18 ¿Posee IP fija?
19 ¿Se puede acceder en forma remota a esta Workstation?
20 ¿Tiene acceso solamente a los recursos que necesita para trabajar?

21 ¿Lo ven desde la LAN sólo los que lo necesitan ver?
22 ¿Posee documentación de las aplicaciones que utiliza?
23 ¿Hay más usuarios configurados de los que realmente usan la workstation?

24 ¿Usa un SO monousuario?
25 ¿Es usuario experto de su SO?
26 ¿Usa la misma contraseña para más de un sistema?

27 ¿Cambia las contraseñas con regularidad?
28 ¿realiza copias de respaldo de su información personal sensible?
29 ¿Posee carpetas compartidas en esta PC?
30 ¿Usa el antivirus regularmente para revisar archivos peligrosos?
SUBTOTAL NIVEL LÓGICO
NIVEL DE LA ORGANIZACIÓN
31 ¿Existe una persona encargada de administrar la seguridad?
32 ¿Existen Normas o procedimientos de seguridad?

33 ¿Existe algún procedimiento para solicitar nuevos requerimientos?
¿Procesa información que es confidencial para gente del mismo

34
departamento?
35 ¿Intercambia datos/información con otros departamentos?
36 ¿Intercambia datos/información con otras empresas?
37 ¿Trabajan terceros en su piso?
38 ¿Cuando ocurre un incidente, informa a alguien?
39 ¿Cómo informa los nuevos requerimientos?
40 ¿Ha firmado algún acuerdo de confidencialidad?
SUBTOTAL NIVEL DE LA ORGANIZACIÓN
TOTAL
2.2.2 Asignación de puntaje
Para la asignación del puntaje se siguió el criterio adoptado por la empresa Internet
Security Systems [iss.net], experta en seguridad, considerado adecuado para el
estudio que se lleva a cabo en este Relevamiento.
49
Se definen los valores posibles y su significado como sigue:
• 0: No representa amenaza alguna;

• 1: Amenaza leve;
• 2: Gran amenaza al sistema.
Para medir la criticidad se utiliza el siguiente criterio:
• No representa amenaza alguna:

Si están presentes elementos que provean información que no es del sistema que
pueda ser usada para efectuar ataques estructurados en un objetivo, pero que no
otorgan acceso autorizado directamente.
Por ejemplo:
o Ataques por fuerza bruta;
o Descubrimiento de información que no es del sistema (datos sueltos,
información pública).
• Amenaza leve:
Si existen eventos que tengan el potencial de otorgar acceso o permitir ejecución
de código por medio de procedimientos largos o complejos, o elementos de bajo
riesgo aplicados a componentes importantes.
Por ejemplo:
o Ataques de hombre en el medio (ver “Man in the middle attack” en
[Stallings1999]);
o Negación de servicio de elementos no críticos;
o Descubrimiento de información privada (pero no confidencial, por ejemplo
información de uso interno).
• Gran amenaza al sistema:

Si existen elementos que permiten acceso local o remoto inmediato, o la
ejecución de código o comandos con privilegios desautorizados, o la negación de
servicios.
Por ejemplo:
o Overflow de buffers;
o Scripting a través de sitios (ejecución de algoritmos malintencionados a través
de la web);
o Denegación de servicios de elementos críticos;
50
o Backdors;
o Contraseñas por default o contraseñas en blanco;
o Salteo de la seguridad en firewalls y otros componentes de red.
2.2.3 Aclaración sobre las preguntas
2.2.3.1 Nivel Físico
1- ¿El espacio es compartido (oficina propia, box del sector, común)?

La pregunta apunta a ver si la Workstation en estudio está aislada físicamente de
otras, o está ubicada en un sector compartido, como un box de trabajo o un lugar
abierto.
2- ¿Hay otros sectores de la empresa en el mismo piso?

La pregunta apunta a si el espacio físico es ocupado por personas de distintos
sectores.
3- ¿Se accede a esta Workstation con llave propia del sector?

Se refiere a si la Workstation en estudio está ubicada en un lugar físico al que se
accede con llave u otro mecanismo de seguridad propio del sector de trabajo, y no da
acceso a otros sectores.
4- ¿Existe algún circuito de circulación abierto hasta esta Workstation?

Se apunta a verificar si existe un camino inseguro a la Workstation como podría ser
un pasillo que da a una salida no asegurada. Un ejemplo típico es la PC de trabajo de
una recepcionista que está al alcance del público.
5- ¿Está cerca de alguna puerta?

Con CERCA se hace referencia a “pocos metros”.
6- ¿Está cerca de algún pasillo?

7- ¿Está cerca de alguna ventana?

8- ¿Guarda la documentación impresa o magnética bajo llave propia?
51
Por ejemplo en un armario de uso particular.
9- ¿Guarda la documentación impresa o magnética bajo llave común al sector?

Por ejemplo en un armario de uso común de todo el sector.
10- ¿Maneja algún tipo de codificación para la rotulación de diskettes, cintas, CDs,
etc?
La pregunta apunta a verificar si se utiliza alguna técnica preestablecida para
nomenclar dispositivos de almacenamiento, o simplemente se rotulan con nombres
legítimos.
Un ejemplo de nombre legítimo podría ser: back05122002.tar que indica claramente

que ese dispositivo contiene un archivo de backup del día 5 de diciembre del 2002.
Un ejemplo de codificación podría ser CDC640 que tiene significado solamente para
las personas concernientes.
11- ¿Posee conexión a una LAN?

Se le debe preguntar al usuario si está conectado a la red local.
12- ¿Posee conexión a una WAN?

Se le pregunta al usuario si en su red existen equipos ubicados físicamente en otro
edificio.
13- ¿Tiene acceso a Internet?

La pregunta apunta a verificar si el usuario tiene acceso a Internet.
14- ¿Hay cables al descubierto?

La pregunta apunta a verificar si el cableado está protegido, por ejemplo, con tubos
cobertores e se encuentran subterráneos, o simplemente se expanden a la vista.
15- ¿Usa esta Workstation otro usuario regularmente?

Esta pregunta apunta a verificar si la Workstation es compartida por distintos
usuarios. Esto suele darse en situaciones donde los empleados trabajen part-time o
simplemente se requiera de monitorización continua durante las 24 hs.
16- ¿Trabaja con servidores de uso exclusivo de su sector o son compartidos por más
de un sector?
Por ejemplo, si trabajan los sectores de Desarrollo y Prueba con un mismo servidor.
52
2.2.3.2 Nivel Lógico
17- ¿Posee conexión permanente a Internet?

Por ejemplo ADSL, Cablemodem, etc.
18- ¿Posee IP fija?

Esta pregunta apunta a conocer cómo se hace la administración de las direcciones de
red, que afectará en la definición de un blanco identificable o no. (Algunos ataques
internos tienen como objetivo la penetración de las barreras de seguridad de ciertos
equipos en particular. La IP fija facilita la identificación de máquinas para este fin.)
Si el usuario no sabe si su IP es fija o variable, el ES puede solicitarle realizar la

verifiación.
19- ¿Se puede acceder en forma remota a esta Workstation?

Por ejemplo a través de conexiones TELNET, o haciendo un REMOTE LOGON.
20- ¿Tiene acceso solamente a los recursos que necesita para trabajar?
La pregunta apunta a verificar si desde la Workstation se puede acceder a sectores
de al LAN que no son necesarios para realizar el trabajo, apuntando al principio de
“otorgar solo los privilegios mínimos y necesarios para la realización del trabajo”
21- ¿Lo ven desde la LAN sólo los que lo necesitan ver?
Para verificar si sectores no autorizados tienen acceso a esta terminal.
22- ¿Posee documentación de las aplicaciones que utiliza?

Esta pregunta apunta a chequear si los usuarios poseen documentación suficiente (y
adecuada) para el uso de los aplicativos de trabajo (por ejemplo manuales de
usuario, manuales técnicos de los proveedores, etc.).
23- ¿Hay más usuarios configurados de los que realmente usan la workstation?
Esta pregunta apunta a verificar si existen configurados usuarios que no son
estrictamente necesarios. Por ejemplo en algunos sistemas operativos como ciertas
distribuciones de Linux se instala el sistema con un conjunto de usuarios por default
de los cuales algunos no son utilizados.
En otros casos puede ocurrir que un empleado deje la organización pero quede
configurado el usuario en el sistema.
24- ¿Usa un SO monousuario?
53
Por ejemplo DOS o Windows 95, Windows 98, Windows Millenium, etc.
25- ¿Es usuario experto de su SO?

Apunta a verificar si el usuario es capaz de realizar tareas de administración del
sistema, por ejemplo, configurar un firewall, verificar opciones de seguridad, y
manejar el file system en forma adecuada.
26- ¿Usa la misma contraseña para más de un sistema?

Por ejemplo, si el usuario utiliza la misma contraseña para ingresar al sistema
operativo y para el programa de correo.
27- ¿Cambia las contraseñas con regularidad?

REGULARIDAD se podría llegar a considerar hasta un mes.
28- ¿Realiza copias de respaldo de su información personal sensible?

La realización de las copias de respaldo o backup es responsabilidad del
administrador de la red y del operador responsable. Sin embargo, La información
personal guardada localmente en las estaciones de trabajo no es resguardada, siendo
ésta responsabilidad del usuario.
29- ¿Posee carpetas compartidas en esta PC?

Se refiere a las carpetas que pueden ser accedidas por otros usuarios desde otras
workstations.
30- ¿Usa el antivirus regularmente para revisar archivos peligrosos?

Se consideran ARCHIVOS PELIGROSOS los de origen incierto, o los transportados en
medios magnéticos como diskettes, cintas, etc.
Esta pregunta apunta a ver si el usuario realiza controles especiales en situaciones

particulares, por ejemplo cuando trabaja con dispositivos extraíbles, en los que no se
realiza un análisis de antivirus automático.
2.2.3.3 Nivel De La Organización
31- ¿Existe una persona encargada de administrar la seguridad?
32- ¿Existen Normas o procedimientos de seguridad?

La pregunta apunta a descubrir si el usuario está informado de la existencia de un
marco normativo de seguridad.
54
33- ¿Existe algún procedimiento para solicitar nuevos requerimientos?

Esta pregunta apunta a verificar si el usuario conoce los procedimientos formales de
solicitud de nuevos requerimientos, y si efectivamente estos procedimientos existen.
34- ¿Procesa información que es confidencial para gente del mismo piso?
Esta pregunta pretende verificar si en esta Workstation se procesa información que
es confidencial para personas que comparten el mismo espacio físico.
35- ¿Intercambia datos/información con otros departamentos?

Esta pregunta pretende descubrir la interrelación entre departamentos, y la
existencia de flujo de información entre ellos.
36- ¿Intercambia datos/información con otras empresas?

Esta pregunta pretende descubrir la interrelación entre los empleados de la empresa
con externos, y la existencia de flujo de información entre ellos.
37- ¿Trabajan terceros en su piso?

Se refiere a si trabajan personas subcontratadas o externas a la empresa en el
mismo sector físico.
38- ¿Cuando ocurre un incidente, informa a alguien o trata de manejarlo solo?

Por ejemplo: cuando sucede una anomalía en el software el usuario llama a un
técnico de sistemas para que vea lo sucedido?
39- ¿Cómo informa los nuevos requerimientos?

La pregunta apunta a descubrir si existe un procedimiento de control de cambios y
reporte de requerimientos de usuario.
40- ¿Ha firmado algún acuerdo de confidencialidad?

La pregunta apunta a determinar si el usuario tienen conciencia de la criticidad de la
información que maneja, y si se ha realizado alguna vez una clasificación de la
información de la organización.
2.2.4 Resultados de la evaluación
Según la cantidad de puntos obtenidos en cada nivel se establece la calificación del

entorno en cuanto a seguridad informática:
Nivel físico:
55
• De 0 a 6 puntos: Seguro/protegido;
• De 7 a 16 puntos: Medianamente vulnerable;
• De 17 a 32 puntos: Altamente vulnerable.
Nivel lógico:
Nivel de la organización:
2.2.5 Evaluación del entorno
2.2.5.1 Referencias al puntaje obtenido en el test por nivel:
• 0: Seguro/protegido;
• 1: Medianamente vulnerable;
• 2: Altamente vulnerable;
• x: 0 o 1.
2.2.5.2 Configuraciones de resultados:
• 000: Entorno seguro.

• 001, 010, 001, 011, 110, 101, 111: Entorno medianamente vulnerable.
Asegurable a corto plazo;
• xx2,x2x, xx2: Entorno altamente vulnerable. Asegurable de mediano a corto
plazo;
• x22, 22x, 2x2: Entorno altamente vulnerable. Asegurable a mediano/ largo
plazo;
56
• 222: Entorno altamente vulnerable. Requiere una planificación completa a largo

plazo.
2.3 Análisis de vulnerabilidades.
Esta etapa comprende la determinación de las amenazas que enfrenta el entorno

respecto de la seguridad de la información.
Los datos almacenados en los servidores de la red, los almacenados en cada estación
de trabajo, los equipos e instalaciones, las aplicaciones, los documentos y todo
mensaje (pulso eléctrico, sonido, luz, etc), corren riesgos reales, potenciales y
latentes a cada instante.
Estos mensajes, datos, activos deben cumplir su función conservando los tres pilares
de la seguridad intactos:
• Integridad: que se proteja la exactitud y totalidad de los datos y los métodos

de procesamiento;
• Confidencialidad: que la información sea accesible sólo a las personas

autorizadas;
• Disponibilidad: que los usuarios autorizados tengan acceso a la información y a

los recursos cuando los necesiten.
“Una vulnerabilidad es cualquier situación que pueda desembocar en un problema de

seguridad” asegura [Huerta].
Se le llama amenaza a todo acontecimiento, persona, u ente capaz de hacer

provecho de una vulnerabilidad para producir daño, modificación o escucha indebida
de información, atentando contra al menos una de estas características.
Las vulnerabilidades pueden generar amenazas en el entorno en estudio: si son

conocidas por un atacante, pueden causar la pérdida de alguna de las características
deseables de la información, antes mencionadas.
2.3.1 Conocer al enemigo
Es muy importante conocer el entorno en estudio para predecir el tipo de atacante

que puede atraer.
57
Según las características del entorno, se estará expuesto a un abanico de atacantes

más o menos peligroso, y más o menos experto.
Como un perro es atraído por un hueso, y un ladrón de guantes blancos es atraído

por un diamante, en informática, los usuarios inexpertos son atraídos por entornos
inseguros (como una computadora hogareña conectada a Internet), mientras que los
intrusos más hábiles se ven seducidos por ambientes confidenciales y protegidos
(como organismos militares y de investigación).
Es por eso que el ES debe analizar qué tipo de entorno maneja para predecir a qué
tipo de ataques probablemente se deberá enfrentar.
2.3.2 Ejemplo – Atacantes
A continuación enumeramos algunos entornos comunes y sus enemigos más

conocidos:
• Los entornos de investigación como universidades y laboratorios suelen ser

boicoteados por los propios alumnos e investigadores, y rara vez por el personal,
y más ocasionalmente por extraños;
• Los organismos militares suelen ser investigados por la competencia (organismos

militares y de inteligencia de países enemigos) principalmente con el fin de
obtener información;
• La confidencialidad de los datos es la característica más preciada en estos

entornos;
• Las instituciones políticas y gubernamentales suelen ser carnada para pares de la

competencia, como partidos opositores y gremios;
• Los entornos personales suelen ser atacados por intrusos desconocidos al azar
(no se hacen ataques personales) que simplemente sienten satisfacción tomando
control de máquinas ajenas o provocando daños, pero en general estos ataques
no apuntan a una obtención de información, sino a la negación de servicios o
pérdida de información;
• Las instituciones bancarias son blanco de atacantes codiciosos que pretenden, en

general, malversar los datos para obtener beneficios económicos;
• En este tipo de entornos la característica que se desea preservar es la integridad

de los datos;
58
• En los entornos comerciales los ataques apuntan a la negación de servicios, en

general son perpetrados por los propios empleados de la compañía;
• Aquí la característica más valiosa es la disponibilidad de recursos y servicios, ya

que una negación de servicios suele impactar fuertemente en los negocios.
2.3.3 Las amenazas
Las amenazas más comunes a los entornos informatizados son:
• La falta de protección física del entorno:

Las instalaciones, los equipos y documentos pueden estar expuestos a catástrofes
naturales, a hurto, o destrucción por falta de protección o mala disposición física
de los elementos.
• La mala administración de proyectos:

La mala planificación, la escasa separación de tareas y definición de roles
disminuye la calidad del producto de software, provoca la disconformidad de los
usuarios y una escasa documentación de las distintas etapas del desarrollo. La
falta de control y capacitación de los programadores hace que se genere código
inseguro a partir de la programación descuidada de rutinas.
• Una inadecuada separación de ambientes:

Genera riesgos de integridad y coherencia de los datos además de la inestabilidad
del sistema productivo con la consecuente falta de disponibilidad de los recursos.
• Los errores en la administración del entorno:

Una mala administración abre puertas a los intrusos. Es fundamental detectar y
corregir estas situaciones.
• El diseño inseguro:
En el diseño de las aplicaciones, de las redes, de los CPDs. se subestima la
implantación de medidas de control de acceso, de separación de funciones y
tareas.
• Los defectos funcionales en las aplicaciones:

La falta de flexibilidad en la administración y la mala separación en módulos,
entre otros factores que se discutirán luego, hacen a las aplicaciones más
susceptibles a ataques.
59
• Las amenazas lógicas programadas:

Muchos ataques lógicos son perpetrados por intrusos que aprovechan errores en
las aplicaciones y sistemas para realizar actos destructivos o delictivos como el
daño de dispositivos o la escucha desautorizada de información.
Uno de los mayores puntos débiles de las organizaciones son estos “bugs”
informáticos y la falta de protección lógica de los datos. Por eso es muy
importante estar al tanto de ello, y llevar una frecuente actualización con los
parches otorgados por los fabricantes de software.
• Una incompleta protección lógica:

La mala configuración de los servidores donde residen las aplicaciones, del
sistema operativo, de las bases de datos y de las interfases con las que se
conectan genera errores y riesgos importantes.
• La ausencia de control de incidencias:

El control de incidencias permite generar una base de conocimiento para el
manejo de situaciones de riesgo y prevenir nuevos ataques. La falta de control y
administración de incidencias hace que el conocimiento de las amenazas
detectadas se pierda y que se atrasen los tiempos de solución por la falta de
circuitos de asignación de responsabilidades sobre el tratamiento de los casos.
• La falta de una normativa de seguridad:

También la falta de una completa normativa procedimental y técnica, y una mala
conducta y cultura de trabajo, producen descuidos o errores no forzados por los
usuarios.
• Las personas:
El acceso de personas no autorizadas implica la vulnerabilidad del sistema ante
hurtos, acceso indebido, pérdida de confidencialidad de los datos y todo tipo de
escucha no autorizada de información, con sus respectivas consecuencias.
Estos factores y muchos otros más, hacen que muchas vulnerabilidades de los
entornos informatizados tengan origen en el mal uso del sistema por parte de los
usuarios.
Es fundamental detectar y conocer las vulnerabilidades del entorno informatizado en

el que se está trabajando para poder establecer el camino a seguir que lleve a un
aseguramiento efectivo.
60
A continuación se propone un documento que refleja la identificación de las

potenciales vulnerabilidades del entorno en estudio. Lo llamaremos Mapa de
Vulnerabilidades.
Este modelo contendrá la especificación, por nivel (físico, lógico y de la organización)

de las amenazas latentes y las probables.
2.3.4 Análisis de Vulnerabilidades
En esta etapa se analizan las fallas de seguridad en el entorno según los estándares
internacionales referenciados en la bibliografía de este trabajo.
Se considera una vulnerabilidad a toda diferencia entre los parámetros deseados

recomendados por dichos estándares y las mejores prácticas profesionales en cuanto
a Seguridad Informática.
Los objetivos de control considerados, según [IRAM/ISO/IEC17799], [BS7799],

[Cobit], [MRSA-ISACA], [AAW-ISI], [OSSTMM-ISECOM] y [AACF-ROBOTA] son los
siguientes:
2.3.4.1 Aspectos funcionales
• Que exista una adecuada definición de funciones y estructura de comunicación en

el área;
• Que las tareas incompatibles sean adecuadamente segregadas;
• Que existan licencias de uso del producto para cada recurso / usuario;
• Que las aplicaciones activas en el entorno contribuyan a perseguir los objetivos

del negocio;
• Que se haya definido y documentado un modelo de administración de la

seguridad;
• Que existan estándares y procedimientos de trabajo definidos para todas las
tareas del área;
• Que el circuito de trabajo responda a criterios de seguridad, eficiencia y

productividad;
61
• Que los procedimientos adoptados estén de acuerdo con normas estándares en la

materia;
• Que estén definidos y se encuentren documentados para cada puesto del

organigrama perfiles de usuario modelo a los cuales se les asocian las
identificaciones individuales de cada persona;
• Que los equipos informáticos sean utilizados sólo con fines autorizados y
siguiendo los procedimientos establecidos;
• Que todo procesamiento esté debidamente autorizado por los responsables

correspondientes;
• Que existan procedimientos de control de los resultados que surgen del

procesamiento en los equipos;
• Que existan estándares definidos a seguirse para la realización de pruebas de los

desarrollos y/o mantenimientos, que contemplen:
o La realización de pruebas de detalle por parte de personal de sistemas antes

de ser probados por personal de las áreas usuarias;
o La realización, por parte de personal de las áreas usuarias, de la definición de

los casos, ejecución de las pruebas, análisis de los resultados, interfases,
corridas mensuales y anuales, etc. antes de la implantación;
o La forma de documentación de la participación y validación de los resultados

de las pruebas;
o Los requerimientos en cuanto a niveles de autorización para su implantación

en el ambiente productivo;
o El procedimiento de implantación en producción.
• Que el acceso a la documentación de los sistemas de aplicación de producción

sólo se permita a personal autorizado;
• Que exista un encargado de soporte del mantenimiento para las aplicaciones

analizadas;
62
• Que existen adecuados procedimientos manuales o automatizados de control de

cambios a los programas;
• Que existen cláusulas de confidencialidad en los contratos con los proveedores de

software y/o terceros que trabajen en las aplicaciones.
Este análisis permitirá visualizar el nivel de adhesión que tiene la estructura del
proceso a los estándares metodológicos que se tengan establecidos para el desarrollo
y mantenimiento, así como para la documentación de las etapas del proceso. Además
se podrán establecer los criterios que fueron utilizados para definir y establecer las
características de los controles internos y las validaciones. El análisis funcional
permite visualizar las distintas etapas que se suceden en el proceso, así como
también identificar etapas de alto, medio y bajo riesgo.
Para verificar estos puntos de control el ES y su equipo de trabajo puede realizar las
siguientes tareas:
• Revisar la documentación del proceso de negocio de la empresa objetivo con el

fin de conocer su estructura y funcionamiento;
• Entrevistar a los analistas/programadores/técnicos responsables del

mantenimiento de las aplicaciones y equipos y comparar el procedimiento que
cada uno está aplicando;
• Entrevistar a los analistas/programadores responsables del

desarrollo/mantenimiento de las aplicaciones así como al personal usuario, a
efectos de obtener una visión global del mismo, tanto en su fase manual como
automática;
• Entrevistar a los analistas/programadores/técnicos responsables del

desarrollo/mantenimiento de las aplicaciones y equipos para validar la adecuada
concientización del personal a fin de cumplir con la documentación vigente;
• Obtener de los usuarios y de los analistas, información adicional sobre el entorno

a relevar, tal como:
o Satisfacción funcional de los requerimientos de información de los usuarios;
o Tiempos de procesamiento y de generación de salidas;
o Experiencias anteriores sobre procesamiento de errores;
o Confianza de los usuarios en la información que manejan estos equipos y
aplicaciones.
Para ello se pueden distribuir encuestas de evaluación del funcionamiento de

las aplicaciones y equipos entre personal del área de sistemas y de sectores
usuarios.
63
• Obtener información sobre trazas de auditoría, históricos de archivos generados

por los sistemas y procedimientos de emergencia, de reenganche y de
procesamiento alternativo disponible;
• Conocer los procesos y funciones de administración de las bases de datos y de

“back-up” de archivos y programas (fuentes y ejecutables) de cada una de las
aplicaciones;
• Entrevistar a ciertos usuarios finales, elegidos al azar, a efectos de verificar cuán

involucrados están con las distintas fases de desarrollo/mantenimiento de
sistemas (diseño, desarrollo, prueba y aceptación). Además, se obtendrá de los
usuarios finales la siguiente información:
o Nivel de participación con relación a la calidad de los servicios;
o Problemas detectados durante el último año;
o Asignaciones incorrectas de acceso a los archivos de datos y a las
transacciones de las aplicaciones on-line.
• Relevar y probar los procedimientos de administración, control, control de los

cambios efectuados a las aplicaciones e identificar a los responsables de llevar a
cabo los mismos;
• Identificar y entrevistar al personal responsable de implantar cambios, de realizar

controles sobre las incidencias que involucren las aplicaciones, para verificar que
se cumpla con los procedimientos vigentes;
• Solicitar (en caso de existir) y analizar el log utilizado para priorizar y monitorizar
la recepción y progreso de los cambios de sistemas;
• Solicitar y analizar muestras de documentos relacionados con modificaciones de

los programas:
o Documentos aprobados por los supervisores de desarrollo autorizando la
puesta en producción de los programas modificados;
o Documentos que demuestren que los usuarios finales han aprobado los
desarrollos/modificaciones efectuados antes de migrar los nuevos programas
al área de producción;
o Formularios o memorándums que formalmente comuniquen el orden de
ejecución de los programas modificados (Job step) al área de operaciones;
• Identificar una muestra de requerimientos de cambios a las aplicaciones

relevadas en el log requerido y verificar que para cada uno de ellos se haya
cumplimentado adecuadamente el procedimiento de modificación de programas y
catalogación en producción, con su respectivo control.
64
2.3.4.2 Análisis de la documentación
En relación a la documentación, los objetivos de control que se deben verificar son

los siguientes:
• Que exista un marco normativo que defina la política de la empresa, y siente las
bases para el desarrollo de procedimientos y estándares técnicos;
• Que existan relaciones formales y conocidas por el personal, referidas a la

documentación de carácter obligatorio y deseable que debe ser desarrollada y
mantenida;
• Que se cumpla con las definiciones formales e informales relacionadas al

desarrollo, mantenimiento y cadenas de autorización referidos a la
documentación;
• Que se encuentren implantados métodos efectivos de distribución y comunicación

entre los involucrados;
• Que los procesos tecnológicos estén alineados con las normas establecidas, y
sean adecuados;
• Que los procedimientos alcancen los niveles de servicio perseguidos por la

empresa;
• Que exista documentación de usuario que especifique los requerimientos de

tecnología, de procesamiento, de archivos y de interfases;
• Que exista un procedimiento formal para realizar el control de cambios, niveles

de revisión, autorización y publicación.
Para analizar si el entorno objetivo cumple con estos objetivos, se pueden llevar a
cabo las siguientes tareas:
• Entrevistar al personal del Área de Sistemas a fin de identificar la documentación

existente y los procedimientos formales e informales relacionados con el
desarrollo, autorización y mantenimiento de la misma;
• Analizar la documentación existente en cuanto a estructura, niveles de

aprobación, vigencia, contenido, publicación y distribución entre los involucrados;
65
• Evaluar los niveles de cumplimiento de los procedimientos existentes;
• Seleccionar un grupo de personas para evaluar el nivel de conocimiento y

utilización de la documentación existente;
• Identificar los puntos débiles de la documentación y procedimientos existentes.
2.3.4.3 Análisis de las aplicaciones y equipos
Los objetivos de control que debe verificar el ES en este aspecto son los siguientes:
• Que existan roles adecuados para la supervisión de la seguridad de las

aplicaciones y equipos que existen en el entorno, y la realización de controles que
garanticen la autorización y el adecuado uso de los recursos;
• Que se encuentre implantado adecuadamente un control de accesos a la red de

datos y sus equipos que eviten el uso no autorizado de los recursos, el
descubrimiento y divulgación de información, y el mal uso y abuso de la
información tratada por los mismos;

accesos propio de las aplicaciones y recursos a efectos de prevenir el uso no
autorizado de funciones interactivas, tanto desde conexiones desde la red interna
como desde Internet;

accesos para el procesamiento "batch";
• Que exista una adecuada política de configuración de los equipos informáticos y

de comunicaciones;
• Que se encuentre implantada adecuadamente la estructura de control de accesos

del ambiente de procesamiento de forma de evitar que se puedan modificar o leer
archivos de datos o programas de las aplicaciones analizadas en forma no
autorizada. Es necesario tener en cuenta los aspectos referidos a perfiles de
acceso de los usuarios definidos en los sistemas, así como la protección de los
recursos informáticos residentes en ellos;
• Que la arquitectura técnica de las aplicaciones se encuentre adecuadamente

diseñada, para lo cual se analizarán los esquemas de acceso a las bases de datos,
la interacción con el sistema operativo donde están instaladas las aplicaciones, la
interacción con el servicio de publicación de páginas web (si existiera), el
66
lenguaje de programación utilizado, la forma de codificación de los programas,

etc;
• Que se realicen adecuados controles de los incidentes y problemas emergentes,

con el seguimiento necesario;
• Que las aplicaciones gestionen los errores de forma estándar, y que se realicen
las validaciones adecuadas en la entrada y salida de datos;
• Que exista un plan de contingencia que permita recuperar las aplicaciones y

equipos del entorno ante desastres o situaciones de emergencia;
Para cumplir con estos objetivos, el ES puede llevar a cabo las siguientes tareas:
• Identificar los archivos y directorios críticos de las aplicaciones y de los sistemas

operativos;
• Analizar la asignación de permisos otorgados sobre los archivos y directorios

críticos;
• Identificar los componentes de software de base de las instalaciones;
• Identificar y entrevistar al personal que pueda proveer información de detalle en

cuanto a los caminos por los que la información (datos y programas) puede ser
accedida y los controles establecidos para restringir dicho acceso;
• Entrevistar al personal de soporte técnico para identificar puntos de control sobre

utilitarios riesgosos que puedan modificar archivos y/o programas sin dejar pistas
de auditoría;
• Entrevistar al personal responsable de seguridad informática a fin de analizar los

controles efectuados en las aplicaciones, en los equipos relacionados y el entorno;
• Entrevistar al personal del área de desarrollo y mantenimiento de sistemas

relacionados con las aplicaciones a efectos de identificar los nombres de los
principales archivos, las transacciones on-line con funciones de actualización y las
transacciones on-line con funciones de lectura que muestran información
sensible;
• Entrevistar al operador responsable del resguardo y recuperación de los datos a

fin de analizar el nivel de cumplimiento de los procedimientos vigentes;
67
• Entrevistar al personal encargado de la administración de las aplicaciones y

software de base para conocer los detalles de la gestión de usuarios y permisos;
• Entrevistar al personal de comunicaciones para comprender globalmente las

facilidades de acceso a través de Internet y los mecanismos de seguridad
implantados para prevenir el acceso a dichas facilidades;
• Documentar los modelos de acceso lógico que representa los caminos por los que
se accede a los datos críticos de las aplicaciones;
• Comprender los controles que existen para realizar las pruebas de cumplimiento
sobre esos controles;
• Identificar y analizar el sistema de autenticación de usuarios utilizado por la

aplicación, el sistema operativo que la soporta;
• Analizar si son adecuados los permisos de acceso otorgados a los diferentes

usuarios;
• Realizar una toma de la configuración lógica de los equipos mediante:

o Scripts de relevamiento técnico que lean los archivos de configuración más
importantes, y los vuelquen en informes;
o Captura de pantallas;
o Generación de listados.
• Realizar pruebas de cumplimiento para verificar que los accesos a los diferentes
recursos informáticos están adecuadamente otorgados y/o restringidos
El ES determinará el Alcance de estas pruebas según el grado de criticidad de las

aplicaciones, equipos y de las funciones comprendidas. Las tareas de revisión
podrán incluir:
o Solicitar listas de seguridad de las aplicaciones;
o Verificar que los sistemas de seguridad internos restrinjan el acceso a través
de transacciones on-line a personal autorizado;
o Verificar la correcta definición de los parámetros de seguridad propios de las
aplicaciones;
o Verificar la adecuada asignación de accesos a las aplicaciones y equipos;
o Realizar pruebas que permitan detectar el manejo de errores de las
aplicaciones y la concurrencia.
• Realizar un intento de penetración con el fin de vulnerar las barreras de acceso

existentes para utilizar los recursos informáticos de la compañía en forma no
68
autorizada desde una conexión proveniente de Internet (Intento de Penetración

Externo), o desde la red interna de la compañía (Intento de Penetración interno).
2.3.4.3.1 Intento de Penetración
Un intento de Penetración es un análisis que permite detectar vulnerabilidades en un

entorno informatizado mediante la búsqueda, la identificación y explotación de
vulnerabilidades. Su alcance se extiende a:
• Equipos de comunicaciones;
• Servidores;
• Estaciones de trabajo;
• Aplicaciones;
• Bases de Datos;
• Servicios Informáticos;
• Casillas de Correo Electrónico;
• Portales de Internet;
• Intranet corporativa;
• Acceso físico a recursos y documentación;
• Ingeniería social (La ingeniería social es la técnica por la cual se obtiene
información convenciendo al usuario que otorgue información confidencial,
haciéndose parar por usuarios con altos privilegios como administradores y
técnicos).
Para realizar un Intento de Penetración es necesario realizar las siguientes tareas:
• Reconocimiento de los recursos disponibles mediante el empleo de herramientas

automáticas (Ver 2.3.5.2.1 Herramientas de análisis de vulnerabilidades);
• Identificación de las vulnerabilidades existentes mediante herramientas
automáticas;
• Explotación manual y automática de las vulnerabilidades para determinar su
alcance;
• Análisis de los resultados.
Este análisis otorga información referente a:
• Versiones desactualizadas de software;

• Versiones de software con vulnerabilidades conocidas;
• Contraseñas triviales;
• Usuarios default;
69
• Configuraciones default;
• Utilización de servicios inseguros;
• Recursos compartidos desprotegidos;
• Errores en la asignación de permisos.
Analizando toda la información obtenida mediante el Intento de Penetración, las

entrevistas, la documentación y los diferentes métodos de sondeo, se elabora el
Mapa de Vulnerabilidades dando detalle de los recursos informáticos e información de
la compañía a la que se ha accedido de manera no autorizada.
2.3.4.3.2 Herramientas de análisis de vulnerabilidades
Existe una serie de herramientas que ofrecen datos útiles para el análisis de
vulnerabilidades, como analizadores de configuraciones, analizadores de logs,
herramientas de escaneo de puertos (Port Scanners), sniffers, Network Mapping,
Testing Tools, y otras herramientas, sobre las que no se dará detalle por su
constante evolución.
No es el objetivo de esta Tesis dar detalles sobre implementaciones en particular, sin

embargo, se considera interesante remarcar la importancia del uso de estas
herramientas para la detección de vulnerabilidades, sobre todo porque reducen
considerablemente los tiempos de búsqueda y recolección de datos.
2.3.5 Mapa de Vulnerabilidades
El Mapa de Vulnerabilidades es un documento que se propone con la idea de registrar

y contabilizar las vulnerabilidades presentes en el entorno en estudio antes de la
implantación del Plan de Aseguramiento.
Para registrar las vulnerabilidades detectadas en el análisis anterior se divide el

estudio del entorno en tres partes:
• Nivel físico;
• Nivel lógico;
• Nivel de la organización.
El ES incluirá en el Mapa de Vulnerabilidades del entorno objetivo los niveles que se

hayan determinado en el Alcance.
70
Aquí se enumera una serie de aspectos concernientes a seguridad que implican

vulnerabilidades y que el ES incluirá en el Mapa de Vulnerabilidades:
2.3.5.1 Vulnerabilidades a nivel físico
Amenazas a las instalaciones
• Acceso libre a todos los sectores de la empresa a cualquier usuario:

Si cualquier usuario puede acceder a todas las oficinas de la empresa, sin
controles ni barreras físicas, es muy probable que acceda un intruso a las
instalaciones provocando actos ilícitos como hurtos, daños físicos o espionaje de
información confidencial;
• Falta de un perímetro de seguridad:

Si no se establece un perímetro de seguridad, la empresa se convierte en una
continuación física de la vereda;
• Falta de áreas protegidas que guarden los equipos críticos:

Permitiendo el acceso indiscriminado de personas;
• Falta de barreras físicas que protejan los activos:

Permite el ingreso a la organización de intrusos;
• Existencia de múltiples puntos de acceso:

Esto facilita el ingreso no autorizado de intrusos;
• Falta de autenticación de usuarios:

Esto dificulta la identificación de usuarios no autorizados;
• Ausencia de métodos confiables de autenticación de usuarios;

Un método no confiable de autenticación de usuarios es levemente mejor que
ningún método de autenticación de usuarios;
• Áreas de procesamiento de información y de entrega y carga de materiales

comunicadas:
Facilita el acceso de intrusos al sector de cómputos;
• Áreas de entrega y carga de materiales descuidadas:
71
Facilita la circulación de personas no autorizadas con los efectos consecuentes

(hurtos, infiltrados, etc);
• Integración del área de procesamientote información administrada por la

organización y la administrada por terceros:
Provoca una alteración a la confidencialidad de datos y la exposición a ataques
internos por parte de terceros (ver la sección 4.1.2.1 Protección de la
información);
• Señalización indiscreta del edificio o sobreindicación:

Toda la ayuda que se de para acceder a los sectores protegidos será una
herramienta útil para un intruso que desee perpetrar las instalaciones;
• Falta de sistemas de detección de intrusos;
• Hacer pública información sensible:

Toda información delicada debe ser cuidadosamente administrada, pues todo dato
es una llave para el sistema, que un intruso experimentado puede utilizar. Por
ejemplo, es común hacer públicas todas las extensiones telefónicas, incluso las
de los sectores restringidos. Si un usuario no autorizado accede a uno de estos
números, sería capaz de implementar la ingeniería social para obtener
información o accesos que no le pertenecen.
Amenazas a los equipos.
• Mala distribución física de los activos:

Los equipos pueden estar ubicados en forma descuidada, expuestos a catástrofes
naturales (cerca de ventanas) o hurto (cerca de puertas o pasillos);
• Almacenamiento de materiales dañinos cerca de los equipos:

Como combustibles o químicos;
• Humo del cigarrillo:

El humo del cigarrillo ataca los discos magnéticos y ópticos y provoca trastornos
en la ventilación de los artefactos eléctricos. Además, el cigarrillo puede provocar
incendios;
• Permitir comer y beber en los sectores con equipos:

La comida y bebida puede provocar deterioros en los equipos y cortocircuitos y
hasta quemar elementos eléctricos;
72
• Exposición a temperaturas extremas:

Exponer los equipos a temperaturas extremas daña sus circuitos, provocando
cortocircuitos e incendios.;
• Terminales abandonadas:
Las terminales encendidas en desuso son un riesgo alto, ya que cualquier persona
puede hacer uso de sus recursos, sin siquiera la necesidad loguearse;
• Falta de higiene:
La falta de higiene en oficinas puede provocar daño en los documentos impresos
y en los equipos por acumulación de polvo, grasa, etc;
• Descuido de las unidades de soporte de información:

Tener en mal estado o en lugares inseguros las unidades de backup y
recuperación de sistemas es casi lo mismo que no tenerlas;
• No llevar un control de los cambios en los equipos:

No registrar cada alta, baja o modificación en los equipos conlleva a un
desconocimiento del capital invertido, con lo que cualquier hurto pasaría
desapercibido.
Amenazas generadas por el uso de una red física de datos.
Cuando un mensaje “M” es enviado por un usuario origen “A” a un usuario destino
“B” determinado a través de una red, como se muestra en la figura 1, este mensaje
viaja por el medio físico con el riesgo de sufrir alguno de los siguientes ataques por
parte de un intruso “I”:
M
A B
Figura 1
En el medio del viaje del origen al destino, el mensaje puede sufrir de ataques de
intrusos para su lectura, modificación, o eliminación. A continuación detallamos las
amenazas más comunes que puede sufrir un mensaje:
Tipos de amenazas
73
1) Interrupción: Sucede cuando el destinatario nunca recibe el mensaje emitido

por el origen:
M
A
Figura 2
2) Intercepción: El mensaje enviado por el origen es interceptado por un intruso

que recibe el mensaje tanto como el verdadero destino:
M
A B
Figura 3
3) Modificación: El mensaje enviado por el origen es interceptado por un intruso

que lo modifica, y lo reenvía modificado al verdadero destino. El destino recibe
el mensaje modificando creyendo que es el original:
M
A B
M
Figura 4
4) Fabricación: El mensaje enviado por el origen nunca es distribuido; en su

lugar el intruso envía otro mensaje en reemplazo del original:
5)
74
M
A B
N
Figura 5
Factores de riesgo
• conectores de LAN inutilizados, al descubierto:

Cualquier usuario no autorizado puede conectar una Laptop y sumarse a la red
directamente;
• Cables al descubierto:
Pueden ser dañados con facilidad provocando una negación deservicio;
• Cables atravesando zonas públicas:

Pueden ser interceptados por intrusos que desvíen o modifiquen los paquetes
transmitidos;
• Tender los cables de energía junto con los cables de comunicaciones:

Pueden provocar interferencias en las comunicaciones;
2.3.5.2 Vulnerabilidades a nivel lógico
Amenazas generadas por el uso del correo electrónico
• Virus:
Son porciones de código que son insertadas dentro de un archivo (generalmente
ejecutable) llamado host, de manera que cuando el archivo es ejecutado, se
ejecuta también la porción de código insertada, la cual puede efectuar distintas
acciones malintencionadas, destructivas, y hasta copiarse en otros archivos;
• Gusanos (Worms):
75
Son programas independientes (no necesitan insertarse en otros archivos) que se

expanden a través de la red realizando distintas acciones como instalar virus, o
atacar una PC como un intruso;
• Troyanos:
Son programas que tienen una porción de código oculta, que dicen hacer una
cosa y en realidad hacen otra (desconocida por el usuario) o simplemente hacen
lo que dicen hacer y además ejecutan instrucciones no autorizadas;
• Conejos:
Son programas que no dañan directamente al sistema por alguna acción
destructiva, sino que tienen la facilidad de reproducirse exponencialmente de
manera de provocar en poco tiempo una negación de servicio al consumir los
recursos (memoria, disco, procesador, etc);
• Empleados pueden comprometer a la organización, enviando correos electrónicos

difamatorios, llevando a cabo prácticas de hostigamiento, o realizando compras
no autorizadas;
• Acceso remoto a las cuentas de correo electrónico sin control;
• Falta de una política de eliminación de mensajes:

Puede suceder que se eliminen mensajes que, si se almacenaran, podrían ser
hallados en caso de litigio;
• Los mensajes son vulnerables a ser modificados por personas no autorizadas;
• Es un servicio vulnerable al descubrimiento (“disclosure”) de información

confidencial;
• Se pueden producir errores como por ejemplo la consignación incorrecta de la

dirección de destino, o la publicación de direcciones de personal jerárquico de la
empresa.
Amenazas generadas por el uso de software dañino
• Bombas lógicas:
Son un conjunto de instrucciones que se ejecutan bajo condiciones especiales
(una fecha, etc);
• Backdors y trapdors:
76
Son instrucciones que permiten a un usuario acceder a otros procesos o a una

línea de comandos, y suelen ser aprovechados por intrusos malintencionados
para tomar control sobre las computadoras;
• Timeouts:
Son programas que se pueden utilizar durante un período de tiempo
determinado;
• Herramientas de seguridad:
Son utilitarios que sirven para identificar vulnerabilidades en un sistema. Pueden
ser una amenaza si un intruso las utiliza en el sistema y detecta fallas en la
seguridad de las que el administrador no está enterado.
Amenazas generadas por la presencia de intrusos
• Eaves dropping:
Es la escucha no autorizada de conversaciones, claves, datos, etc;
• Ingeniería social:
Consiste en la manipulación de las personas para que voluntariamente realicen
actos que normalmente no harían, como revelar su contraseña o cambiarla;
• Shoulder Surfing:
Consiste en espiar físicamente a los usuarios para obtener claves de acceso al
sistema, números válidos de tarjetas de crédito, etc;
• Masquerading:
Un intruso puede usar la identidad de un usuario autorizado que no le pertenece
simplemente apoderándose de un nombre de usuario y contraseña válidos;
• Piggy backing:
Ocurre cuando un usuario no autorizado accede a una zona restringida gracias al
permiso otorgado a otra persona que sí está autorizada;
• Basurero:
La información de los desperdicios dejados alrededor de un sistema puede ser
aprovechada por intrusos provocar un hurto o daño.
77
Vulnerabilidades en los sistemas operativos
• Existencia de cuantas de usuarios no utilizadas:

Muchas cunetas de usuario son creadas por defecto en la instalación del sistema
operativo y nunca son deshabilitadas, a pesar de que no se utilicen. Esta situación
es una puerta abierta para los intrusos que conocen estas vulnerabilidades de los
sistemas operativos;
• Existencia de cuantas de usuario con permisos excesivos:

Generada por la falta de control de los permisos asignados a los usuarios;
• Existencia de servicios no utilizados:

Muchos servicios (en particular los de red, y los de conexión remota) son
instalados por defecto con el sistema operativo, o para la corrida de procesos
especiales y nunca son eliminados. Estos pueden ser utilizados por intrusos para
manipular el sistema en forma remota y acceder a los recursos;
• Malas configuraciones de seguridad del sistema operativo:

Como la existencia de cuentas de usuario creadas en la instalación, que son de
conocimiento público y muchas veces se crean con una contraseña por default,
aumentando el riesgo de ataques a la integridad y confidencialidad mediante un
acceso no autorizado;
• Errores en los archivos de configuración existentes y sus valores;
• Falta de un esquema de backup;
• Ausencia de una estrategia de recuperación ante desastres:

El Plan de Recuperación del Entorno ante Desastres cubre las aplicaciones,
equipos y software base que soporta el negocio para su recuperación. No poseer
un plan de acción ante emergencias implica un crecimiento exponencial del
tiempo invertido en la recuperación de las prestaciones, y una potencial pérdida
de información vital para el negocio;
• Contraseñas almacenadas en texto plano:

Algunos sistemas operativos almacenan las contraseñas en texto plano
permitiendo el acceso autorizado (enmascarado) de intrusos si ellos lograran
acceder a la información de passwords. Ésta es una de las primeras tácticas que
utilizan los intrusos para atacar sistemas débiles;
• Falta de registro de las pistas de auditoría:
78
Las pistas de auditoría o logs sirven para dejar registro de las acciones de los
usuarios y los procesos. No llevar un adecuado registro de las pistas de auditoría
dificulta la tarea de detección de intrusos y recuperación de información.
Vulnerabilidades en las aplicaciones
A nivel funcional:
• Falta de documentación:
La ausencia de documentación dificulta la capacitación de los usuarios y el
seguimiento de los proyectos y procesos, provocando incoherencias en el trabajo,
por ejemplo entre los requerimientos de usuario y los cambios realizados en el
software afectado;
• Mala organización del área de sistemas;
• Mala administración de la seguridad informática;
• Fallas en la metodología de desarrollo de las aplicaciones;
• Planificación deficiente;
• Pobre separación de tareas;
• Falta de separación de ambientes:

La separación de ambientes es fundamental, más allá de las ventajas
metodológicas en el proceso de desarrollo de software, en la conservación de la
integridad de los datos a través de la separación lógica y física de los entornos de
producción, desarrollo y prueba;
• Mala configuración de entornos:

Generalmente en los entornos de desarrollo se otorgan permisos excesivos a los
programadores que provocan fallas en la confidencialidad e integridad de los
datos;
• Falta de las pruebas en el desarrollo de aplicaciones;
• Mal manejo de datos:
79
o Datos utilizados para las pruebas:

Muchas veces se utilizan para las pruebas datos de producción. Esto no es
crítico si la base de datos de prueba es independiente, pero tiene un riesgo
asociado cuando se manejan datos de carácter personal, protegidos por las
leyes de todo el mundo, para los cuales hay que tomar medidas de seguridad
adicionales. La falta de estos controles o el uso indebido de datos puede tener
consecuencias legales graves;
o Clasificación, manejo y protección de los datos productivos:

La falta de análisis de criticidad de los datos y categorización hace que no se
brinden los controles que garanticen la correcta manipulación de datos con la
consecuente pérdida de confidencialidad e integridad.
• Falta de control de cambios;
• Defectos en la funcionalidad general de la aplicación;
• Falta de coherencia con los objetivos del negocio;
• Mala separación en módulos;
• Mala administración de la aplicación:

o Falta de organización de los perfiles de usuarios;
o Formas erróneas de asignación de permisos;
o Falta de registro y control de las pistas de auditoría;
o Mal manejo de incidencias.
• Prestaciones limitadas;
• Pobre análisis del control interno:

o Falta d separación de tareas;
o Análisis de asignación de funciones incompatibles.
• Falta de asignación de responsabilidades de seguridad;
Aspectos lógicos:
• Mala estructura de navegación del menú/ páginas de la aplicación;
80
• Errores en las interfaces e interacción con otros servicios;

• Malas configuraciones de seguridad del sistema operativo;
• Vulnerabilidades en los servicios prestados por el mismo servidor;
• Errores en los archivos de configuración existentes y sus valores;
• Mal manejo de transacciones;
• Mal manejo de la concurrencia;
• Falta de un esquema de backup;
• Ausencia de una estrategia de recuperación ante desastres;
• Mala administración de la base de datos;
• Mala configuración de seguridad de las bases de datos utilizadas;
• Formas inseguras de comunicación con la aplicación;
• Contraseñas almacenadas en texto plano;
• Falta de registro de las pistas de auditoría;
• Mal manejo de datos:
o Falta de validación de los datos de entrada;
o Falta de validación de los datos de salida.
• Mal manejo de errores de la aplicación.
Amenazas generadas por mala administración de la información
• No controlar el acceso a los sistemas:

Cualquier usuario podría utilizar y modificar los archivos sin tener que pasar
ninguna barrera que filtre a los intrusos;
• No llevar un registro de los incidencias (como pérdida de datos o mal

funcionamiento de software);
• No contar con un sistema de perfiles de usuarios:

Un sistema de perfiles permite asignar distintos privilegios a los usuarios, de
manera que no todos tengan las mismas posibilidades de acceso a los recursos,
según su tarea. Si esto no se tiene en cuenta, un data entry podrá acceder a los
recursos indistintamente del gerente de sistemas, o del administrador de bases
de datos;
• No llevar un control de los cambios en el software:
No registrar cada alta, baja o modificación en los programas de software conlleva
a un desconocimiento del capital invertido, con lo que cualquier hurto o
modificación pasaría desapercibido;
• Ausencia de un control de impacto del nuevo software:
81
Puede haber una incoherencia entre los requerimientos de capacidad de

procesamiento y almacenamiento del nuevo software, y los disponibles, o una
incompatibilidad con la plataforma de hardware utilizada;
• No mantener actualizado el software de detección y reparación antivirus:

[10lawsMS] asegura que: “Un antivirus desactualizado es sólo marginalmente
mejor que ningún antivirus”;
• Falta de backups:
Sin copias de respaldo la recuperación de la información y la restauración del
sistema luego de un incidente es imposible;
• Realización de backups incompletos pueden llegar a no servir de mucho a la hora

de reconstruir un sistema caído;
• Acceso ilimitado o no controlado a los datos:

Permite el libre acceso de intrusos a los datos facilitando los ataques anónimos;
• Documentación desprotegida;
Un intruso o espía puede hacer mal u:o de la documentación para distintos fines:
espionaje, sabotaje, hurto, o para obtener información que le sirva como puerta
al sistema objetivo;
2.3.5.3 Vulnerabilidades a nivel de la organización.
• Superposición o mala asignación de roles:

[CISA] realizó un estudio de compatibilidades de funciones y desarrolló una
matriz de compatibilidades donde se refleja qué funciones son compatibles o no
con otras, por lo que deberían llevarse a cabo por distintas personas. Este criterio
es utilizado para reforzar el control interno por oposición de intereses;
• Ausencia de administradores y responsables por la seguridad del sistema:

Esta falta implica una gran falla en la seguridad ya que se omite el primer paso
en el camino de la protección: el control. Los administradores y las personas
responsables por la seguridad del sistema cumplen un rol fundamental en este
proceso, y su ausencia exhibe una clara desatención en la materia de seguridad,
que provocará:
o Ausencia o mal manejo de incidencias;
o Mala administración de los recursos;
o Falta de control lógico;
82
o Falta de registro o monitorización de la actividad del sistema;

o Etc.
• Falta de políticas contra ataques internos;
• Ausencia de una Normativa de Seguridad;
• Descuido de los escritorios y las pantallas:

Dejando el acceso libre a los documentos y archivos de la oficina;
• Sectores de desarrollo, de prueba y producción unificados:

Provoca fallas en la calidad del software y falta de control en las distintas etapas
del desarrollo de software, además de problemas en la implantación en el
ambiente de producción;
• Falta de registro del flujo del personal:

No permite detectar intrusos, provocando hurtos y otros ataques;
• Falta de protección de las operaciones de comercio electrónico;
2.4 Análisis de Riesgos
A partir del Mapa de Vulnerabilidades construido en la etapa anterior de la fase de

Definición del Alcance de la MAEI, se analiza el riesgo que corren los activos de la
organización para determinar la probabilidad de ocurrencia de incidencias de
seguridad y su impacto en el sistema.
Los riesgos pueden ser:
• Tecnológicos: si tienen origen o afectan aspectos técnicos del entorno (como

deterioro de equipamientos, falta de disponibilidad de recursos, etc);
• Funcionales: si tienen origen o afectan aspectos funcionales del entorno (como

posible descubrimiento de información por la existencia de usuarios con
contraseña por default, o el acceso no autorizado a los recursos por una pobre
autenticación de usuarios).
83
Todos los entornos están expuestos a amenazas. Todos los entornos tienen
vulnerabilidades, algunas conocidas, otras no, pero están presentes, esperando ser
usadas por un atacante para penetrar las barreras de seguridad y apoderarse de
información, denegar servicios, o provocar toda clase de daño.
No importa la plataforma tecnológica, no importa la marca de software que se usa.

Tampoco importa la infraestructura edilicia, los equipos, el cableado. Siempre existen
riesgos.
Existe una relación entre tipo de desastre y sus efectos, y, por supuesto, su
probabilidad de ocurrencia. Los riegos reales y potenciales son variables en el tiempo
y en el lugar.
En el Análisis de vulnerabilidades se vieron los distintos tipos de amenazas que

pueden presentarse a nivel lógico, físico y de la organización.
No es posible eliminar todos los riesgos sino que se pueden mitigar (empleando
medidas para reducirlos), transferir (ceder su responsabilidad a otra persona) o
asumir (cuando se decide correr el riesgo con sus posibles consecuencias).
Sin embargo, siempre existen riesgos remanentes y desconocidos.
Es más, cada día surgen nuevos riesgos a medida que la tecnología avanza y los
sistemas cambian. Los entornos informatizados suelen acompañar estos cambios
adaptándose a los requerimientos tecnológicos del momento. Es por eso que surgen
nuevos riesgos día a día.
Es tarea del ES en esta parte de la metodología examinar las vulnerabilidades

halladas y evaluar su riesgo asociado, determinar su probabilidad de ocurrencia y
medir su impacto en el entorno.
Los riesgos observados que presentan una probabilidad de ocurrencia no

despreciable en función de las características del entorno varían desde los factores
climáticos y meteorológicos que afectan a la región hasta el factor humano de los
recursos de la empresa.
Para la evaluación de riesgos es posible utilizar métodos muy variados en

composición y complejidad, pero para todos ellos es necesario realizar un diagnóstico
de la situación.
Un método comúnmente utilizado es el diagrama:
84
Alto
Mayor
Probabilidad importancia
de ocurrencia
Bajo
Alto
Impacto
Este análisis de riesgos permite al ES ofrecer un informe de los riesgos entorno, los
peligros que corre e identificar los requerimientos de seguridad del sistema objetivo y
su prioridad, de manera de poder encarar la elaboración del Plan de Aseguramiento
del proyecto junto a los requerimientos planteados por el usuario.
El análisis de riesgos se realiza en cada área de la empresa, mediante métodos de

adquisición de información como entrevistas con los usuarios.
2.4.1 Informe de Riesgos
A continuación se presenta un documento que ayuda a la formalización de estos

conceptos para su estudio: el Informe de Riesgos.
Este documento recompila todas las vulnerabilidades halladas en la etapa anterior de

la metodología, para evaluar su riesgo, su criticidad, la probabilidad de que ocurran y
determinar su impacto en el entorno informatizado y en el negocio.
Esta es una adaptación de la Tabla de Riesgos utilizada en el análisis de sistemas en

la que se ha agregado la criticidad que implica la vulnerabilidad en estudio.
Se recomienda agrupar las vulnerabilidades con algún criterio, como por ejemplo por
nivel de criticidad, que puede clasificarse en:
• Alto;
• Medio;
85
• Bajo.
U ordenarlas en forma decreciente según su impacto o probabilidad de ocurrencia.
Formato del Informe de Riesgos
# VULNERABILIDAD RIESGO CRITICIDAD P(ocurrencia) IMPACTO
Descripción de los campos
#: Número correlativo de vulnerabilidad.
VULNERABILIDAD: Nombre de la vulnerabilidad descubierta en la etapa de análisis

de vulnerabilidades.
RIESGO: Breve descripción del riesgo detectado en el análisis. Es todo evento, falla
o bien que ponga en peligro la integridad, la confidencialidad o la disponibilidad de la
información o los recursos y activos;
CRITICIDAD: Una medida de la criticidad del riesgo, según el criterio aplicado en la

evaluación de vulnerabilidades del Relevamiento de Usuario:
• 0: No representa amenaza alguna;

• 1: Amenaza leve;
• 2: Gran amenaza al sistema.
P (ocurrencia): Es la probabilidad de ocurrencia de dicho evento tomando en

cuenta las amenazas y vulnerabilidades predominantes, y los controles actualmente
implementados.
IMPACTO: Es el efecto potencial de una falla de seguridad, teniendo en cuenta sus

consecuencias en el negocio.
2.4.2 Ejemplo – Informe de Riesgos.
86
# VULNERABILIDAD RIESGO CRITICIDAD P(ocurrencia) IMPACTO
Existencia de material
inflamable en el CPD
Fuego en el Destrucción de equipos
1 (Centro de 2 0.5
Data Center y espacio físico
Procesamiento de
Datos)
Existencia de material Destrucción de

inflamable en el CPD y Fuego en documentación
2 en las oficinas lugares 1 0.45 impresa y posibilidad
aledañas cercanos de afección del centro
de cómputos
Ubicación física en Posibles cortocircuitos,

3 zona inundable Inundación 1 0.1 equipos quemados,
incendios
Falta de equipo de aire Fallas en el

Mal funcionamiento
acondicionado de aire
4 2 0.4 por recalentamiento de
backup acondiciona
equipos
do
Falta de
mantenimiento de los
Fallas en Indisponibilidad de los
5 equipos de 1 0.5
equipos servicios
procesamiento de
datos.
Existencia de cables de
Fallas en
red al descubierto Indisponibilidad de los
6 comunicacio 1 0.3
atravesando los servicios
nes
pasillos
Descuido del cableado

eléctrico, falta de Corte de Indisponibilidad de los
7 acondicionamiento de suministro 1 0.6 servicios, pérdida de
la central eléctrica y eléctrico datos.
pobre aislamiento.
Exposición de los Pérdida de equipos,

equipos a personal no negación de servicios,
autorizado. Acto de pérdida de
8 2 0.1
vandalismo información, mala
imagen en clientes,
périda de confiabilidad.
Exposición de los Acto de Pérdida de

9 equipos a terceros. sabotaje o 2 0.45 confiabilidad, pérdida
robo de información.
Administración de los Errores

Indisponibilidad de los
equipos por personal humanos no
10 0 0.5 servicios, pérdida de
no especializado. intencionale
datos.
s
Diagrama de riesgos:
El diagrama de riesgos esquematiza el impacto de los riesgos en función de su

probabilidad de ocurrencia.
Cuanto mayor sea el impacto y la probabilidad de ocurrencia, más fuertes deberán

ser los controles a aplicar para mitigar el riesgo asociado.
87
Los riesgos más altos, por ende, se ubicarán en el cuadrante derecho superior del
siguiente diagrama:
Análisis de Riesgos en el CPD
1 Fuego en el C PD
Probabilidad de Ocurrencia
Fuego en lugares
cercanos
Inundación
Fallas en el aire
0,5 acondicionado
Fallas en equipos
Fallas en comunicaciones
C orte de suministro
eléctrico
Acto de vandalismo
0
0 0,5 1 Acto de sabotaje o robo
Impacto Errores humanos no

intencionales
88
3 PLANIFICACIÓN
Contenido:
3.1 Elaboración del Plan de Aseguramiento.

3.1.1 Protección física.
3.1.1.1 Protección de las Instalaciones.
3.1.1.2 Protección de los equipos.
3.1.2 Protección lógica.
3.1.2.1 Protección de la información.
3.1.2.2 Protección del Sistema Operativo.
3.1.2.3 Protección de los datos.
3.1.3 Protección a nivel de la organización.
3.2 Aprobación del Plan de Aseguramiento.
89
3.1 ELABORACIÓN DEL PLAN DE ASEGURAMIENTO
En esta parte de la fase de planificación se establece, en base al Alcance y al

Relevamiento anteriormente realizado, el Plan de Aseguramiento.
Este documento describe en forma precisa y detallada las medidas, cambios y

controles que se implementarán a fin de proteger el sistema objetivo, mitigando los
riesgos descubiertos en la fase anterior de la MAEI.
Los objetivos de control planteados por el Experto en la etapa de Análisis de

Vulnerabilidades se reflejan aquí en medidas de control que garanticen la reducción
del riesgo asociado a las vulnerabilidades halladas, tanto en aspectos tecnológicos
como funcionales.
[IRAM/ISO/IEC17799] indica: “Una vez identificados los requerimientos de

seguridad, deben seleccionarse e implementarse controles para garantizar que los
riesgos sean reducidos a un nivel aceptable.”…” Los controles deben seleccionarse
teniendo en cuenta el costo de implantación en relación con los riesgos a reducir y las
pérdidas que podrían producirse de tener lugar una violación de la seguridad.
También deben tenerse en cuenta los factores no monetarios, como el daño en la
reputación”.
Se detalló en etapas anteriores de la MAEI cómo a partir de un análisis de

vulnerabilidades, de requerimientos de usuario y de riesgos se llega a establecer el
Alcance.
En la presente fase se pretende dar una serie de medidas, controles y técnicas

aplicables a cualquier sistema de información, con el fin de alcanzar los resultados
fijados en el Alcance.
Sin embargo, no es el fin de este trabajo dar detalles sobre las técnicas a
implementar para conseguir estos resultados, entendiéndose por buenos resultados
el aseguramiento del elemento en cuestión. Se limitará a dar las pautas
procedimentales para asegurar el entorno informatizado que es objetivo, y el ES que
lo implemente deberá realizar el trabajo de investigación específico para obtener los
resultados propuestos por este trabajo, según la tecnología involucrada.
3.1.1 Protección física
90
3.1.1.1 Protección de las Instalaciones
Se analiza en esta parte la protección del edificio, salas e instalaciones a nivel físico.
Se evalúa la implantación de alguna de las siguientes técnicas:
• Definición de áreas de la organización en cuanto a seguridad:

En esta etapa se deberán diferenciar los sectores de acceso común a todos los
usuarios (como el comedor, la sala de reuniones, etc) de los sectores de acceso
restringido (como el área de cómputos o tesorería) y los distintos niveles de
seguridad requeridos;
• Definición de un perímetro de seguridad:

Un perímetro de seguridad es un área considerada segura. Al definir un perímetro
de seguridad, se establece un área donde se implementarán medidas de
protección que garanticen cierto grado de seguridad, como por ejemplo, berreras
físicas;
[IRAM/ISO/IEC17799] define: “Un perímetro de seguridad es algo delimitado por

una barrera, por ejemplo, una pared, una puerta de acceso controlado por tarjeta
o un escritorio u oficina de recepción atendidos por personas.”
• Construcción de barreras físicas:

Paredes, alarmas, cerraduras, sistemas automáticos de autenticación de usuarios,
etc;
• Verificación del perímetro de seguridad:

Realizar pruebas de penetración de las barreras físicas, para determinar su
fortaleza;
• Determinación de áreas protegidas:

Un área protegida es una zona que se desea mantener segura, a la que no tiene
acceso todo el personal, sino un grupo reducido de éste, a la que acceden con
fines específicos y bajo severos controles de autenticación. Puede ser una oficina
cerrada con llave, o diversos recintos dentro de un perímetro de seguridad física
donde se realicen operaciones confidenciales, como el centro de procesamiento
de información, etc. Se deben definir las zonas u oficinas que tienen estos
requerimientos;
• Controles en las áreas protegidas:

o Dar conocimiento de la existencia de un área protegida, o de las actividades
que se llevan a cabo dentro de la misma, sólo al personal estrictamente
necesario e involucrado;
91
o Controlar el trabajo en las áreas protegidas tanto por razones de seguridad

como para evitar la posibilidad de que se lleven a cabo actividades maliciosas;
o Bloquear físicamente las áreas protegidas desocupadas e inspeccionarlas
periódicamente;
o Brindar acceso limitado a las áreas protegidas o a las instalaciones de
procesamiento de información sensible al personal del servicio de soporte
externo. Otorgar este acceso solamente cuando sea necesario y autorizar y
monitorearlo. Pueden requerirse barreras y perímetros adicionales para
controlar el acceso físico entre áreas con diferentes requerimientos de
seguridad, y que están ubicadas dentro del mismo perímetro de seguridad;
o Prohibir el ingreso de equipos fotográficos, de vídeo, audio u otro tipo de
equipamiento que registre información.
• Determinación de un área de acceso y autenticación de personal:

El control de acceso y la autenticación de usuarios se deben realizar en un punto
de acceso común y alejado de las áreas protegidas. Se recomienda la
centralización del puesto de acceso para facilitar el registro y control de flujo de
personal;
• Determinación de uno o varios métodos de autenticación de usuarios:

Autenticar usuarios implica verificar a los usuarios que intentan acceder al
entorno, a la red o al sistema, comprobando que estos sean quienes dicen ser.
Existen muchos métodos de autenticación de usuarios, y se clasifican según lo
que utilizan para la verificación de la identidad:
o Métodos que se basan en algo que el usuario sabe:
Contraseñas (passwords);
Frases secretas (passphrases);
o Métodos que autentican a través de un elemento que el usuario posee o lleva
consigo:
Tarjetas magnéticas;
Tarjetas de identidad inteligentes (chipcards o smartcards) que poseen un
procesador que se encarga de encriptar la información y otras funciones;
o Métodos que utilizan características físicas del usuario o actos inconscientes:
Verificación del aspecto físico;
Reconocimiento por huella digital;
Reconocimiento por el patrón de la retina del ojo;
Reconocimiento por el patrón del iris del ojo;
Reconocimiento de la voz;
Firmas es un acto inconsciente, ya que no se razona cómo se hace cada
trazo);
Verificación de la geometría de la mano;
92
• Determinación de la forma de registro del flujo de personas en los distintos

sectores:
Por ejemplo, mediante un sistema de tarjetas magnéticas:
o Registrar la hora de ingreso y egreso de cada usuario que ingrese al edificio;
o Registrar la hora de ingreso y egreso de cada usuario que recurra al centro de
cómputos;
• Separación del área de procesamiento de información de las áreas de entrega y

carga de materiales:
Si estas áreas se mantienen separadas por barreras físicas, se evitan graves
intrusiones y hurtos de información;
• Separación de las áreas de entrega y carga de materiales:

Las áreas de entrega y carga, si es posible, se aíslan de las instalaciones de
procesamiento de información, a fin de impedir accesos no autorizados;
• Controles en las áreas de entrega y carga de materiales:

o Controlar el acceso a las áreas de depósito, desde el exterior de la sede de la
organización. El acceso estará limitado a personal que sea previamente
identificado y autorizado;
o Diseñar el área de depósito de manera tal que los suministros puedan ser
descargados sin que el personal que realiza la entrega acceda a otros sectores
del edificio;
o Establecer un mecanismo que obligue a que todas las puertas exteriores de un
área de depósito se cierren cuando se abre la puerta interna;
o Inspeccionar el material entrante para descartar peligros potenciales antes de
ser trasladado desde el área de depósito hasta el lugar de uso;
• Separación del área de procesamiento de información administrada por la

organización de la administrada por terceros:
Las instalaciones de procesamiento de información administradas por la
organización se ubican físicamente separadas de aquellas administradas por
terceros;
• Señalización discreta del edificio:

Establecer una forma de identificación de sectores dentro del edificio de manera
discreta y se ofrece una señalización mínima de su propósito, sin signos obvios,
exteriores o interiores, que identifiquen la presencia de actividades de
procesamiento de información;
• Implantación de sistemas de detección de intrusos:

Implantar adecuados sistemas de detección de intrusos que se instalan según
estándares profesionales y probados periódicamente. Estos sistemas
93
comprenden todas las puertas exteriores y ventanas accesibles. Las áreas vacías
deben tener alarmas activadas en todo momento. También se considera la
protección de otras áreas, como la sala de cómputos o las salas de
comunicaciones;
• No hacer pública información sensible:

o Las guías telefónicas y listados de teléfonos internos que identifican las
ubicaciones de las instalaciones de procesamiento de información sensible no
deben ser fácilmente accesibles al público;
o Llevar un exhaustivo control de la información publicada en los servidores
Web de acceso Público, en particular la referida a la institución.
3.1.1.2 Protección de los equipos
Se analiza en esta parte la protección de los distintos Activos a nivel físico. Se evalúa
la posibilidad de implementar alguna de las siguientes técnicas:
• Evaluación de la distribución física de los activos:

Se realiza a fin de evitar accidentes, o para prevenir, mediante la ubicación
estratégica de los bienes, hurtos o deterioros de activos:
o Ubicar las instalaciones clave en lugares a los cuales no pueda acceder el
público;
o Ubicar las funciones y el equipamiento de soporte compartidas por los
usuarios, por ejemplo, fotocopiadoras, máquinas de fax, dentro del área
protegida para evitar solicitudes de acceso, que podrían comprometer la
información;
• Mantener alejados los suministros:

o Almacenar los materiales peligrosos o combustibles en lugares seguros a una
distancia prudencial del área protegida;
o No almacenar los suministros a granel, como los útiles de escritorio, en el
área protegida hasta que sean requeridos;
• Individualización de los elementos de red:

Es fundamental tener un conocimiento completo de la red, individualizar todos
sus elementos, su respectiva ubicación física y su dirección lógica.
Para ello se presenta una tabla que registra estos datos: el Mapa de elementos de
red.
94
Mapa de Elementos de Red
SUBNET ELEMENTO SECTOR IP
SUBNET: Dirección IP de la subred a la que pertenece.

ELEMENTO: tipo de elemento de red:
• CPU;
• Router;
• Switch;
SECTOR: lugar físico donde el elemento está ubicado el elemento;

IP: dirección IP local de la máquina;
• Rotulación de activos físicos:

Los equipos, dispositivos externos, cintas de backup y demás activos físicos
deben ser rotulados según la nomenclatura fijada en el Inventario de Activos
Físicos de forma clara y legible;
• Control de cambios en equipos:

o Mantener el equipamiento de acuerdo con los intervalos de servicio y
especificaciones recomendados por el proveedor;
o Permitir que sólo personal de mantenimiento autorizado brinde mantenimiento
y lleve a cabo reparaciones en el equipamiento;
o Mantener registro de todas las fallas supuestas o reales en el Registro de
Incidencias y de todo el mantenimiento preventivo, correctivo y
actualizaciones de hardware en el documento de ABM Activos y en el
Inventario de Activos Físicos, según lo especificado en la fase de
Mantenimiento de la MAEI;
o Verificar que en el mantenimiento se cumpla con todos los requisitos
impuestos por las pólizas de seguro;
• Prevención de catástrofes:
95
o Incendios:
Provocados por rayos, por fallas eléctricas o descuido de los usuarios
(cigarrillos, hornallas). Colocar extinguidotes automáticos en los techos, y
extinguidotes manuales en todo el edificio;
o Humo:
Provocado por incendios y por el cigarrillo. El humo ataca los discos
magnéticos y ópticos y provoca trastornos en la ventilación de los artefactos
eléctricos. Se considera prohibir fumar en las oficinas y colocar detectores de
humo en los techos;
o Temperaturas extremas:
Los artefactos eléctricos y electrónicos funcionan correctamente dentro de un
rango determinado de temperaturas, en general entre los 0 y los 70 grados
centígrados. Si se exceden estos extremos se corre el riesgo de que los
materiales dejen de ser ferromagnéticos. Consultar los manuales de los
fabricantes y mantener la temperatura dentro de los rangos sugeridos. Se
aconseja la utilización de equipos de aire acondicionado en todas las salas;
o Polvo:
El polvo se deposita sobre los artefactos removibles y entra por los
ventiladores de las CPU y daña los circuitos. Es necesario tener una rutina de
limpieza y aspiración de los ambientes;
o Explosiones;
o Vibraciones:
Ciertos objetos presentes en oficinas provocan vibraciones indeseadas.
Impresoras, máquinas expendedoras de bebidas, provocan estas vibraciones.
Instalar plataformas antivibración;
o Electricidad:
Trastornos o fallas en la línea eléctrica pueden provocar cortocircuitos, subidas
de tensión, cortes en el flujo eléctrico y hasta incendios. Instalar cables a
tierra y estabilizadores de tensión. También se sugiere la utilización de
baterías o unidades de alimentación ininterrumpida;
o Tormentas eléctricas:
Las tormentas eléctricas pueden provocar altísimas subidas de tensión que
quemen los equipos. Para evitar esto se colocan pararrayos, guardar los
backups lejos de columnas metálicas para que no se desmagneticen, y
desconectar los equipos de la línea eléctrica cada vez que se desata una
tormenta;
96
o Ruido eléctrico:
El ruido eléctrico es generado por motores, equipos eléctricos y celulares.
Colocar filtros en la línea de alimentación y alejar los equipos de otros
artefactos;
o Humedad:
El exceso de humedad en equipos eléctricos provoca cortocircuitos y la
escasez de humedad provoca estática. Se recomienda instalar alarmas
antihumedad y mantener la misma al 20%;
o Inundaciones:
Colocar los equipos alejados del piso, instalar un falso suelo o ubicar censores
en el piso que corten el suministro de energía eléctrica al detectar agua;
o Terremotos:
Para proteger los equipos más críticos de los terremotos se fijan éstos de
manera que no se puedan desplazar y se trata de ubicar todo equipo alejado
de las ventanas;
o Insectos;
o Comida y bebidas:
La organización debe analizar su política respecto de comer, beber y fumar
cerca de las instalaciones de procesamiento de información. Se recomienda
prohibir estas actividades para proteger los equipos e instalaciones;
o Terminales abandonadas:
Las terminales encendidas en desuso son un riesgo alto. Utilizar un sistema
automático de detección y apagado de terminales encendidas en desuso;
o Vandalismo;
o Hurto;
• Ubicación de la información crítica en lugares seguros:

Mantener el equipamiento de sistemas de soporte UPC (usage parameter control),
de reposición de información perdida (fallback) y los medios informáticos de
respaldo (backups) a una distancia prudencial de la fuente de información, en
lugares protegidos contra intrusos y catástrofes naturales que permitan evitar
daños ocasionados por eventuales desastres en el sitio original;
97
• Protección de las copias de respaldo:

Los medios que contienen las copias de respaldo o backup como cintas o discos
deben ser cuidadosamente almacenados en lugares alejados de la fuente de datos
y protegidos contra robo, incendio e inundación;
• Protección de las unidades de soporte de información:

Manejar las cintas, discos, diskettes u otros dispositivos que contengan
información crítica según las especificaciones de los fabricantes, a fin de evitar
pérdidas o daño de la información;
• Restricción del acceso a unidades removibles:

Únicamente los usuarios locales deben tener acceso a las unidades removibles
como discos removibles, CD-ROM y floppy disks;
• Garantizar el adecuado suministro de energía:

Proteger el equipamiento con respecto a las posibles fallas en el suministro de
energía u otras anomalías eléctricas. Se debe contar con un adecuado suministro
de energía que esté de acuerdo con las especificaciones del fabricante o
proveedor de los equipos. Se recomiendan las siguientes opciones para asegurar
la continuidad del suministro de energía:
o Usar múltiples bocas de suministro para evitar un único punto de falla en el
suministro de energía;
o Utilizar fuentes o suministros de energía ininterrumpible (UPS);
o Se recomienda usar una UPS para asegurar el apagado normal o la ejecución
continua del equipamiento que sustenta las operaciones críticas de la
organización;
o Tener un generador de respaldo;
o Se recomienda el empleo de un generador de respaldo si no se puede
interrumpir un proceso en caso de una falla prolongada en el suministro de
energía;
o Ubicar interruptores de emergencia cerca de las salidas de emergencia de las
salas donde se encuentra el equipamiento, a fin de facilitar un corte rápido de
la energía en caso de producirse una situación crítica;
o Proveer de iluminación de emergencia en caso de producirse una falla en el
suministro principal de energía;
• Protección del cableado:

Proteger contra interceptación o daño del cableado de energía eléctrica y de
comunicaciones, que transporta datos o brinda apoyo a los servicios de
información:
o Instalar líneas de energía eléctrica y telecomunicaciones que se conectan con
las instalaciones de procesamiento de información subterráneas, o sujetas a
una adecuada protección alternativa;
98
o Proteger el cableado de red contra interceptación no autorizada o daño,

evitando trayectos que atraviesen áreas públicas;
o Separar los cables de energía de los cables de comunicaciones para evitar
interferencias;
o Instalar conductos blindados y recintos o cajas con cerradura en los puntos
terminales y de control:
Usar cableado de fibra óptica;
Realizar barridos para eliminar dispositivos no autorizados conectados a
los cables.
• Protección de los equipos utilizados fuera de la organización:

El nivel gerencial debe autorizar el uso de equipamiento destinado al
procesamiento de información fuera del ámbito de la organización. Proveer
seguridad de forma equivalente a la suministrada dentro del ámbito de la
organización, para un propósito similar, teniendo en cuenta los riesgos de
trabajar fuera de la misma:
o Controlar el equipamiento y dispositivos retirados del ámbito de la
organización para que no estén desatendidos en lugares públicos;
o Transportar las computadoras personales como equipaje de mano y de ser
posible enmascaradas, durante el viaje;
o Respetar permanentemente las instrucciones del fabricante, por ejemplo,
protección por exposición a campos electromagnéticos fuertes;
o Contar con una adecuada cobertura de seguro proteger el equipamiento fuera
del ámbito de la organización;
o Contar con medios de protección de las comunicaciones entre los equipos
portables (como Laptops) mediante técnicas de encriptación de los canales.
• Control de la baja de equipos:

o Controlar los equipos que se den de baja para evitar la utilización indebida de
la información que transporten;
o Verificar el borrado seguro de datos sobrescribiendo las pistas de discos antes
de desecharlos;
o Procurar la destrucción física de diskettes y unidades de cinta y todo artefacto
removible capaz de contener información;
o Documentar toda baja o modificación de equipos en el ABM Activos.
• Control de la disponibilidad de almacenamiento:

o Verificar la disponibilidad de espacio de almacenamiento físico de datos;
o Monitorear las demandas de capacidad requeridas por los elementos de
software;
o Realizar proyecciones sobre los futuros requerimientos de capacidad.
99
3.1.2 Protección lógica
Se analiza en esta parte la protección de los distintos Activos a nivel lógico.
3.1.2.1 Protección de la información
En este apartado se pretende establecer reglas para la protección de la información

de la organización objetivo, o sea, técnicas de prevención del hurto, modificación o
deterioro de la confidencialidad de los datos con significado para la institución;
• Prevención de ataques externos:
o Eaves dropping:
Es la escucha no autorizada de conversaciones, claves, datos, etc.
Se asegura que no haya cables atravesando zonas públicas, se cierran todas
las salidas de red no utilizadas, proteger el cableado con caños metálicos o
cablear al vacío con aire comprimido;
o Ingeniería social:
La Ingeniería social consiste en la manipulación de las personas para que
voluntariamente realicen actos que normalmente no harían, como revelar su
contraseña o cambiarla. Se capacita a los usuarios para prevenirlos de estos
ataques y se los informa del procedimiento formalizado en la Política de
seguridad sobre el cambio de contraseñas;
o Shoulder Surfing:
Consiste en espiar físicamente a los usuarios para obtener claves de acceso al
sistema, números válidos de tarjetas de crédito, etc. Se recomienda prevenir
a los usuarios sobre estos temas a fin de concientizarlos para que tomen los
cuidados necesarios;
o Masquerading:
Un intruso puede usar la identidad de un usuario autorizado que no le
pertenece simplemente apoderándose de un nombre de usuario y contraseña
válidos. Se capacita a los usuarios para que mantengan en secreto tanto su
nombre de usuario como su contraseña para que nadie más los pueda usar en
su nombre;
o Piggy backing:
Se lo llama así al ataque en que un usuario no autorizado accede a una zona
restringida gracias al permiso otorgado a otra persona que sí está autorizada.
100
Para evitar esto se establecen controles en los accesos a las salas y se

construyen barreras físicas que impidan el acceso;
o Basurero:
Basurero es la obtención de información de los desperdicios dejados alrededor
de un sistema:
documentación antigua;
listados viejos;
buffers reimpresoras;
memoria liberada por procesos;
bloques libres de disco;
tachos de basura dentro y fuera del edificio;
diskettes desechados.
Es de vital importancia destruir toda documentación que ya no se utilice, con

una máquina trituradora de papel y borrar los documentos en “forma segura”,
según el sistema operativo que se use.
[IRAM/ISO/IEC17799] indica: “Los medios que contienen información sensible

deben ser eliminados de manera segura, por ej. incinerándolos o
rompiéndolos en pequeños trozos, o eliminando los datos y utilizando los
medios en otra aplicación dentro de la organización.”
Se debe prestar especial atención a la eliminación segura de:

documentos en papel;
grabaciones (audio, video, otros);
papel carbónico;
informes y estadísticas;
cintas de impresora de un sólo uso;
cintas magnéticas;
discos, zips o casetes removibles;
medios de almacenamiento óptico;
listados de programas;
datos de prueba;
documentación del sistema.
• Clasificación de la información:
La información se debe clasificar en cuanto a su acceso (qué perfiles de usuarios
tienen acceso a lectura, ejecución o modificación de los datos) y en cuanto a su
criticidad. Para clasificarla según su acceso, se hace uso de la Tabla de Accesos
101
sobre Activos Lógicos, y para clasificarla según su criticidad, se hace referencia al

inventario de Activos Lógicos;
• Establecer medidas de protección según la clasificación de la información:

Según el tipo de información que se trate, se deberán garantizar controles como
se indica a continuación:
o Para la información pública o no restringida:

No es necesario establecer restricciones especiales, más allá de las
recomendaciones sobre su buen uso y conservación;
o Para la información restringida y/o secreta:

Dependiendo que la información se haya clasificado como restringida o secreta
se deben cumplir con los siguientes requerimientos mínimos y obligatorios
para su protección:
Autorización:
Los usuarios a quienes por la naturaleza de su trabajo se les permita el
acceso a la información clasificada como confidencial o secreta, deben
estar expresamente autorizados.
El Dueño de los Datos debe mantener un detalle de los usuarios

autorizados a acceder a la información.
El Administrador de Seguridad debe conservar la documentación

respaldatoria de las autorizaciones recibidas para los cambios de permisos.
Limitar el acceso a las aplicaciones a través de un adecuado sistema de

control de accesos.
No permitir el uso de información secreta para propósitos de prueba

durante los desarrollos o implantaciones. En cuanto a la información
restringida, sólo debe utilizarse teniendo en cuenta las autorizaciones
definidas en la Norma de Ambientes de procesamiento.
El Dueño de los Datos debe autorizar expresamente el acceso a la

información en el ambiente de producción por parte de personal del área
de Sistemas, siempre y cuando lo considere absolutamente necesario y
debido a situaciones de emergencia. En estos casos documentar la
autorización y las tareas efectuadas, de acuerdo al Procedimiento de
Administración de Usuarios y Recursos.
Conservación:
102
La información clasificada como secreta y los medios físicos donde se

almacene, deben protegerse utilizando cajas de seguridad cuya llave y/o
combinación debe ser conservada por el Dueño de los Datos, quien debe
autorizar toda copia adicional de dicha información así como la
transmisión, envío, impresión y/o destrucción de la misma.
La conservación de soportes impresos de esta información debe efectuarse

en archivos cerrados cuyo acceso físico debe estar restringido únicamente
a los usuarios autorizados, según lo especificado en la Norma de
Protección física del Manual de Seguridad de la organización.
Realizar el proceso de generación y/o restauración de la información de

acuerdo a lo definido en la Norma de Copias de Respaldo.
Impresión:
Imprimir los reportes que contienen información confidencial en
impresoras de acceso exclusivo para usuarios autorizados;
Entrega/Traslado:
Realizar toda entrega de documentación que contenga información
secreta/confidencial en sobre cerrado. Asimismo, establecer mecanismos
que permitan asegurarle al remitente de la documentación que ésta fue
recibida por el destinatario correspondiente;
Divulgación a terceros:
Instrumentar convenios de confidencialidad con los terceros que deben
acceder a información de la empresa.
No trasmitir información en forma verbal o escrita a personas externas a la

empresa, sin la expresa autorización del Dueño de los Datos.
Destrucción:
Destruir toda información secreta y sus correspondientes soportes físicos
cuando se considere no vigente y se discontinúe su utilización y/o
conservación.
o Informar a los usuarios sobre el manejo de la información:

Toda la información conservada en los equipos informáticos (archivos y
correos electrónicos residentes en servidores de datos centralizados y/o
estaciones de trabajo) puede ser considerada propiedad de la compañía y no
de los usuarios, dependiendo de su Política de Seguridad, por lo que podrá ser
administrada y/o monitoreada por los responsables del área de Sistemas de
acuerdo con las pautas de seguridad definidas.
103
Esto debe estar claramente establecido en la Norma de Clasificación y

Tratamiento de la Información de la empresa y pertinentemente informado a
todos los usuarios.
3.1.2.2 Protección del Sistema Operativo.
• Actualización de del Sistema Operativo:

o Actualizar periódicamente los Sistemas Operativos de Servidores y estaciones
de trabajo para las diferentes plataformas. En Unix-Linux, actualizar el kernel
y en la plataforma Microsoft, actualizar el SO con la versión que se considere
necesaria de acuerdo con las necesidades funcionales y las mejoras
implementadas por el fabricante;
o Aplicar los parches (hot fixes, service packs) que publican los proveedores de
software en todos los equipos. Para ello se recomienda el uso de algún
software de distribución según la cantidad de máquinas a actualizar;
• Estandarización de servidores:
La configuración de seguridad de los equipos puede ser tediosa, pero es
necesaria.
Los servidores deben seguir un estándar para su identificación y para su

configuración. El Manual de Seguridad incluye estándares técnicos que se
elaboran para estos fines. El ES deberá evaluar la posibilidad de elaborar uno
para facilitar la tarea de homogenización de configuraciones de seguridad por
plataforma deben tener los equipos respecto de la seguridad, que se aplique a
todos los servidores existentes, y cada vez que se de de alta a uno nuevo.
Es muy práctico para estos casos la elaboración de scripts de configuración que

seteen los parámetros de seguridad automáticamente sin intervención del
administrador del equipo.
• Control del acceso remoto:

Realizar los adecuados controles para evitar el acceso no autorizado a los equipos
en forma remota, según lo establecido en la Política de Seguridad de la compañía.
En general se sugiere limitar el acceso remoto a un grupo reducido de usuarios

para fines administrativos utilizando medios seguros (protocolos que encripten la
identificación de usuario y la contraseña) y prohibir el acceso remoto de los
equipos más críticos.
En todos los casos una práctica muy recomendada es eliminar el acceso dial up a
los servidores.
104
• Protección del inicio del sistema:

Establecer la configuración del arranque de los equipos según lo establecido en el
Manual de Seguridad. La práctica más recomendable es deshabilitar la posibilidad
de booteo de los servidores desde el CD-ROM y floppy disk.
• Control de la instalación de programas y dispositivos:

Permitir únicamente a usuarios con privilegios de administrador que instalen
software y dispositivos en los equipos. Para la actualización de programas de
software o instalación de dispositivos se debe seguir el lineamiento indicado en
los Procedimientos del Manual de Seguridad para el manejo de incidencias (en
una organización con sistema de Atención al Cliente o Help Desk el procedimiento
comenzaría con la solicitud del usuario, la apertura de caso en Help Desk y
posterior derivación al responsable. Ver el punto 6.1 Manejo de Incidencias de
esta metodología).
• Creación de subsistemas en el sistema operativo limitada:

Sistemas Operativos como la serie Windows permite la creación de subsistemas
OS/2 y POSIX. Los de la familia Unix permiten la creación de shells hijos donde
correr procesos en segundo plano. Ambos casos deben evaluarse según la
funcionalidad del equipo que se trate, y restringir el uso de estas facilidades
cuando no sean estrictamente necesarias para el desarrollo de las tareas y
servicios que prestan.
• Desconexión de todas las unidades de red inutilizadas:

Muchas veces se conectan unidades de red con fines específicos para alguna
instalación remota, etc. Todas las conexiones que no se necesitan deben ser
removidas del sistema operativo para evitar el intento de conexión por parte de
usuarios no autorizados y el descubrimiento de información.
Ciertas tecnologías exponen información del sistema incluso ante un intento

fallido de conexión.
Es ejemplo la utilidad Netware Connections de Novel, que ante un intento de

conexión muestra el árbol NDS que contiene al servidor, el número de conexión,
la dirección completa de la red, el número de la red y la dirección del nodo,
implicando un descubrimiento importante de información.
• Limpieza de la memoria:
Cada vez que el sistema se cierra se deben limpiar las páginas de memoria
virtual;
• Apagado seguro:
105
No permitir el apagado de equipos sin la autenticación (login de un usuario). La

única excepción es durante la utilización de medios alternativos de alimentación
eléctrica (como UPSs) durante una emergencia;
• Implantación de un sistema de perfiles y grupos de usuarios:

La administración de usuarios es clave para el mantenimiento de la seguridad del
entorno;
Todos los sistemas operativos actuales permiten la creación de usuarios, perfiles

de usuario y grupos.
Los usuarios son identificaciones individuales de personas o servicios.
Los perfiles son los tipos de usuarios existentes (generalmente el sistema

operativo trae un conjunto de perfiles de usuario por defecto, y el administrador
luego crea los que considera necesarios).
Los grupos son conjuntos de usuarios. Por lo general se crean grupos para
identificar a los usuarios que realizan una misma tarea.
Las mejores prácticas de seguridad sugieren crear un conjunto de grupos de

usuarios, y asignar los permisos sobre los archivos y directorios a los grupos, y no
a los usuarios. Esto hace mucho más sencillo el mantenimiento de los permisos
en caso de cambios o recupero de información de cintas de backup, puesto que
solamente hay que modificar los permisos de los grupos, y no individualmente los
de los usuarios, que, serán muchos más en número.
Un caso muy común de cambio de permisos que implica trabajo es cuando un

usuario cambia de área de trabajo, con el consecuente cambio de permisos de
acceso sobre los archivos compartidos. En el caso de que se otorguen permisos
por usuario habría que eliminar individualmente todos los permisos de ese
usuario a los archivos del área de donde es promovido y agregarle los permisos
correspondientes al área donde comienza a desenvolverse. Esto puede llegar a
ser un trabajo engorroso y siempre se corre el riesgo de no eliminar todos los
permisos del usuario, con el consecuente acceso indebido a los recursos.
En cambio, si los permisos son otorgados por grupo, simplemente alcanza con
eliminar al usuario del grupo y asignarlo al nuevo, con la automática asignación
de permisos del grupo al que pertenece.
En general es útil crear grupos por áreas de trabajo o sectores dentro de las
áreas donde todos los usuarios que pertenecen a ese sector acceden con los
mismos permisos a los recursos informáticos de la empresa.
• Implantación de una Política sobre las cuentas de usuarios:
106
El Manual de Seguridad de la organización debe contener, entre sus normas y

procedimientos, la Política de ABM de Usuarios. En ella se debe especificar los
parámetros que deben cumplir la identificación de usuario (como estándar de
nomenclatura, responsabilidad del usuario sobre su uso), la cuenta (como
vencimiento, bloqueo por inutilización, etc) y las contraseñas (longitud mínima y
máxima, período máximo de uso, políticas de cambios y conformación de la
contraseña, etc).
El ABM de usuarios consiste en la Alta, Baja y Modificación de usuarios en el

sistema, entendiéndose por:
o Alta de un usuario: requerimiento de acceso a una aplicación o un servicio

para un usuario inexistente;
o Modificación de un usuario: requerimiento de:
diferentes tipos de acceso a las aplicaciones o servicios,
acceso a una nueva aplicación o servicio;
eliminación de acceso a una aplicación o servicio;
o Baja de un usuario: requerimiento de eliminar los derechos de acceso de ese
usuario a toda aplicación o servicio;
o Deshabilitación de un usuario: requerimiento de negar los derechos de acceso
de ese usuario a toda aplicación o servicio, sin eliminarlo definitivamente del
dominio de usuarios;
El Dueño de los Datos del área o sector al cual pertenece el usuario en el

desempeño de sus funciones, debe solicitar la creación, modificación o
borrado de la cuenta de usuario;
En una empresa con Help Desk, una operación (ABM) sobre una cuenta de
usuario deberá registrarse como un caso y llevarse a cabo según lo
establecido en el correspondiente Procedimiento de Administración de
Usuarios y Recursos.
Tipos de cuentas de usuarios:

o Cuentas personales: Identificación personal del usuario:
Cada persona debe tener una única identificación personal de usuario en los
servicios centralizados de la compañía y es responsable de la correcta
utilización de la información que se realiza con esa cuenta.
En general, la identificación de la cuenta personal suele ser alfanumérica y

está relacionada con el nombre y apellido del usuario.
o Cuentas de servicios:
Son cuentas de usuarios no personales que se crean con fines específicos:
107
Usuarios creados por defecto durante la instalación de aplicaciones y

sistemas operativos: no deben utilizarse con fines operativos;
Usuarios genéricos para satisfacer necesidades propias de la ejecución de
aplicaciones o servicios, por ejemplo, para administrar las comunicaciones:
deben ser autorizados expresamente por el Oficial de Seguridad;
Para estos casos las contraseñas deben permanecer resguardadas y su
acceso debe ser registrado según los Procedimientos correspondientes.
Descripción de las cuentas:

Las cuentas de usuarios generadas en cada uno de las aplicaciones, deben
contener, al menos, los siguientes datos:
o El nombre y apellido completo del propietario de la misma y el área de
trabajo, en el caso de los usuarios personales;
o En el caso de las cuentas de servicios debe figurar la función para la que fue
creada;
o Debe crearse una cuenta para cada servicio individual con los mínimos
privilegios posibles, y no utilizar una misma cuenta para varios servicios;
Todo usuario se debe comprometer a:

o mantener la confidencialidad de la información a la que acceda;
o utilizar en forma personal y exclusiva su identificación de usuario;
o responsabilizarse del uso que se haga de su identificación de usuario.
• Implantación de una Política de Contraseñas de Usuarios:

El Manual de Seguridad de la organización debe contener, entre sus normas y
procedimientos, la Política de Contraseñas de Usuarios. En ella se debe especificar
los parámetros que deben cumplir las contraseñas.
A continuación se enumera una serie de controles que deberán tenerse en cuenta

a la hora de elaborar la Política de Contraseñas:
o Longitud mínima (por ejemplo de 6 caracteres y sin contener blancos);

o Longitud máxima (por ejemplo de 16 caracteres;
o Vida máxima (para obligar a los usuarios a realizar el cambio de clave cada
cierto período, por ejemplo de 45 días);
o Vida mínima (para evitar que un usuario realice el cambio obligatorio de la
clave a su vencimiento y luego vuelva inmediatamente a la clave anterior)
o Cantidad mínima de caracteres numéricos;
o Cantidad mínima de caracteres alfabéticos;
o Cantidad mínima de caracteres especiales (@#$%^&*);
o Cantidad mínima de caracteres distintos de la última contraseña;
108
o Tiempo mínimo que debe transcurrir antes de reutilizar una password (por
ejemplo, un año);
o Cantidad mínima de contraseñas distintas antes de reutilizar una. Es una
variante del control anterior, utilizada para el mismo fin;
o Determinar si debe ser cambiada obligatoriamente la primera vez que el
usuario ingrese al sistema;
Además, debe cumplir con las siguientes características:

o Debe poder ser cambiada toda vez que el usuario lo requiera;
o No debe ser compartida;
o Se debe preservar su confidencialidad;
o No debe ser fácil de adivinar;
Para lograr esto existen varias soluciones:

Utilizar un software generador de passwords:
Utilizar un software que analice la password (por ejemplo comparando la
contraseña ingresada por el usuario con una lista contenida en un
diccionario de contraseñas prohibidas) y rechace contraseñas fáciles al
momento de su ingreso;
• Administración de Usuarios:
Garantizar que todos los usuarios posean los privilegios mínimos necesarios para
la realización de su tarea.
Las prácticas recomendadas para las cunetas de usuarios son las siguientes:
o Renombrar la cuenta de Administrador Local;

o Crear una cuenta de Administrador Local ficticia. Llamada de forma estándar
según el sistema operativo del que se trate. Por ejemplo:
Para Windows 2000 en español, llamarla Administrador;
Para Windows 2000 en Inglés, llamarla Administrador;
Para Linux, llamarla root;
o Deshabilitar la cuenta de Administrador ficticia;
o Deshabilitar la cuenta de invitado o Guest;
o Nunca usar cuentas grupales (de uso masivo). Las cuentas deben ser de uso
individual exclusivo;
o Todos los usuarios personales deben autenticarse en el sistema. No se deben
permitir cuentas de usuario personales sin password;
o Establecer una nomenclatura para la denominación de las cuentas de usuarios
personales y para las de servicios (como por ejemplo utilizar las iniciales del
nombre seguidas por el apellido);
109
o Utilizar descripciones de usuarios claras y completas que permitan la

identificación y clasificación de los usuarios.
Para lograr una adecuada y efectiva implantación de un sistema de grupos y

perfiles de usuarios, sin superposición de roles ni de permisos, y con el fin de
detectar cualquier inconsistencia, se sugiere relevar los usuarios con sus
respectivos permisos y roles en un documento generado para tal fin llamado
Mapa de Usuarios, que permite la rápida visualización de inconsistencias en la
asignación de perfiles.
Mapa de Usuarios
El siguiente documento presenta una alternativa para visualizar, documentar y

administrar los grupos de usuarios:
GRUPO USUARIOS NOMBRE DE INICIO OTROS GRUPOS A LOS

DE SESIÓN QUE PERTENECE
GRUPO: nombre del grupo que se está relevando;

USUARIOS: nombre completo de los usuarios que pertenecen a ese grupo;
NOMBRE DE INICIO DE SESIÓN: por ejemplo: pgarcia;
OTROS GRUPOS A LOS QUE PERTENECE: en este campo se agregan todos los
grupos a los que pertenece el usuario, excepto en el que se está definiendo, esto
sirve para detectar inconsistencias.
También el ES deberá interiorizarse con los permisos proporcionados por perfil, y

deberá verificar que, según la estructura de la organización, ningún usuario está
abusando del sistema con permisos que no le corresponden, y, asimismo, que no
existan usuarios donde sus accesos estén indebidamente restringidos y así,
dificultar o impedir su trabajo.
• Revisión de las cuentas de usuario:

El administrador de seguridad debe realizar una periódica revisión de las cuentas
de los usuarios del sistema, a fin de detectar usuarios inactivos y realizar las
bajas correspondientes, según el procedimiento de seguridad de administración
de usuarios;
• Revisión de los permisos de los usuarios:
110
Realizar una periódica revisión de los permisos otorgados sobre le file system y
sobre los recursos.
Un control básico consiste en restringir los permisos para los grupos genéricos, e
ir otorgándolos individualmente o por grupo según la necesidad.
En los sistemas operativos de la línea Microsoft Windows el grupo genérico más

abarcativo es el llamado Everyone. En la línea de Linux, es Others (el último
octeto de los permisos).
• Revisión de los servicios de red:

Revisar periódicamente los servicios de red habilitados y eliminar todos aquéllos
que no se necesiten, en particular los que permiten hacer conexiones remotas o
transporte de datos en texto plano (como FTP);
• Revisión de los protocolos de red:

Revisar periódicamente los protocolos de red habilitados y eliminar todos aquéllos
que no se necesiten, en particular los protocolos antiguos e inseguros (como
NetBIOS);
• Control del inicio de sesión:

Establecer un número máximo de intentos fallidos de inicio de sesión de los
usuarios, luego del cual se bloquee la cuenta hasta que el usuario solicite su
desbloqueo mediante el procedimiento vigente.
Asimismo, establecer el período en que una cuenta puede permanecer en estado

“bloqueado”, luego del cual se debe proceder al borrado definitivo del usuario,
luego de los controles necesarios, indicados en la Norma de administración de
usuarios (por ejemplo, el administrador o persona con rol equivalente, encargada
de la revisión y eliminación de usuarios, debería consultar con el área de recursos
humanos para obtener la autorización de la eliminación definitiva de un usuario).
La administración de usuarios también implica realizar periódicos controles sobre

los usuarios del sistema, eliminando los que no presenten actividad, según el
procedimiento correspondiente.
• Nombre del último usuario logueado:

Evitar que se muestre la identificación del último usuario que se logueó en el
sistema. Esto podría facilitar los ataques de adivinanza de contraseña por fuerza
bruta;
• Bloqueo de cuentas de usuario:
111
Las cuentas bloqueadas por intentos fallidos de sesión, o por permanecer

inactivas durante un período determinado deben permanecer bloqueadas durante
un tiempo, para impedir el inicio de sesión.
Este período de tiempo puede ser de minutos o días, dependiendo de la criticidad

de la información que maneje la empresa objetivo.
Como ejemplo, a continuación se exponen controles sobre las cuentas de

usuarios, que deben estar explícitos en las Normas de Usuarios, y deben ser de
conocimiento de todos los usuarios del Sistema:
o Toda cuenta de usuario que haya intentado cuatro (4) veces el acceso al
sistema en forma fallida y consecutiva, debe ser automáticamente bloqueada;
o Toda cuenta de usuario que no haya accedido al sistema por un período de 60

días será bloqueada y se iniciará la gestión de baja de la misma, que
comprende:
verificación por parte de Recursos Humanos y del Dueño de los Datos de la
inexistencia del usuario;
aprobación por parte de éste último para la eliminación definitiva de la
cuenta.
En caso de comprobar la necesidad de la baja, el Administrador de Seguridad

deberá proceder a su inmediata eliminación. Transcurrida ua cantidad de días
(por ejemplo 120) sin utilización de la cuenta, la misma se dará
automáticamente de baja.
• Registros de pistas de auditoría o logs:

Registrar pistas de auditoría, más conocidas como “logs” con el fin de asegurar un
adecuado monitoreo de los eventos que pudieran afectar a la seguridad de la
información de la compañía objetivo.
Toda aplicación utilizada en el entorno productivo debe permitir el registro
automático y la explotación de la información de las siguientes pistas de
auditoría:
o Trazas generales a activar en sistema operativos y equipos de

comunicaciones:
Intentos exitosos y fallidos de ingreso de usuarios;
Desconexión forzada de usuarios;
Alta, baja o modificación de usuarios, grupos y/o perfiles;
Cambios en la configuración de la seguridad;
Instalación de software de aplicación;
Encendido y apagado de servidores y equipos de comunicaciones;
112
Procesos de depuración de información no automatizados.
o Trazas generales a activar en aplicaciones:

Intentos exitosos y fallidos de ingreso de usuarios;
Desconexión automática de sesiones de usuario por inactividad;
Alta, baja o modificación de usuarios, grupos y/o perfiles;
Cambios en la configuración de la seguridad;
Instalación de software de aplicación;
Procesos manuales de depuración de datos;
Las acciones llevadas a cabo por los usuarios especiales.
o Trazas especiales a activar:

Todos los accesos a información clasificada como confidencial;
Todos los eventos de un usuario cuando sean específicamente solicitados
por los Dueños de los Datos;
Todos los accesos de aquellas cuentas de usuarios con altos privilegios
sobre los sistemas.
Ejemplo:
A continuación se muestra una porción pequeña de un archivo de log generado

por el sistema operativo Windows 2000 Server, en un entorno con 18 estaciones
de trabajo en un dominio de un archivo de log:
Tipo Fecha Hora Origen Categoría Suceso Usuario Equipo
Aciertos 28/11/2003 11:08:07 Security Inicio/cierre de sesión 540 SYSTEM

EMUI_SISTEMAS
Aciertos 28/11/2003 11:07:54 Security Inicio/cierre de sesión 540 EMUI_18$
Aciertos 28/11/2003 11:06:54 Security Inicio/cierre de sesión 538 gmarrollo

EMUI_5$
Errores 28/11/2003 11:06:34 Security Inicio/cierre de sesión 529 plopez
Errores 28/11/2003 11:06:34 Security Inicio de sesión de la cuenta 681 SYSTEM
EMUI_SISTEMAS
Aciertos 28/11/2003 11:06:02 Security Inicio/cierre de sesión 538 lkien
EMUI_3$
EMUI_18$
113
• Revisión de las licencias de software:

Verificar que todos los equipos funcionen con el Sistema Operativo bajo la licencia
otorgada por el proveedor.
• Revisión de los contratos con los proveedores;

En los contratos con los proveedores se deben incluir cláusualas de
confidencialidad de la información tratada, y contemplar los niveles de servicio de
mantenimiento pos venta acordados.
• Administración de las pistas de auditoría:

Las pistas de auditoría o logs son valiosos sólo cuando pueden ser analizados, y
se encuentren disponibles en forma legible y completa. Para lograr esto, los
registros de log deben:
o Ser completos (deben registrar toda la información que se considere útil para
el caso);
o Ser auténticos (deben ser verídicos, no deben ser falsificados ni modificados
por nadie);
o Ser íntegros (deben ser completos).
Para ello se debe establecer una serie de controles sobre la lógica de los logs, y
sobre la tecnología que los soporta.
A continuación se detallan controles y medidas recomendadas para obtener un

registro de auditoría confiable:
o Acceso a los logs:

Permitir únicamente el acceso a los logs a aquellas personas que son
responsables de la gestión o control de las mismas;
o Administración del espacio disponible para el almacenamiento:

Revisar periódicamente el crecimiento de las trazas con el objetivo de
identificar la necesidad de depuración de las mismas evitando toda posibilidad
de pérdida;
o Eliminación de las pistas:

Ante situaciones que requieran la eliminación de las pistas o trazas de
auditoría debido a la falta de espacio de almacenamiento, generar una copia
de respaldo antes de proceder a su eliminación. Estas copias deben
mantenerse accesibles y adecuadamente registradas en el Inventario de
Backup;
114
o Definición de eventos:
Para aquellos entornos que gestionen información sensible se deberán definir
los eventos de seguridad que requieren monitoreo;
o Control de logs:
El Oficial de Seguridad debe controlar periódicamente las pistas de auditoría,
con el objetivo de detectar alertas e informar la ocurrencia de las mismas a
los responsables de la administración de la seguridad de la información, con el
propósito de definir e implantar las acciones correctivas necesarias para evitar
o limitar la repetición del hecho.
Además se deberá informar al Dueño de los Datos involucrado la ocurrencia

de eventos críticos de seguridad que puedan interferir en el correcto
desempeño la empresa.
o Estadísticas de eventos:
El Oficial de Seguridad deberá generar informes con las estadísticas de los
eventos críticos detectados, a fin de tomar las acciones correctivas
correspondientes, cuando la frecuencia de repetición o el impacto lo
justifiquen;
o Herramientas de análisis de logs:

A fin de proteger a la información más crítica, en la medida en que se cuente
con la tecnología apropiada, es conveniente realizar una revisión de las pistas
de auditoría con herramientas de análisis que faciliten la tarea.
Estas herramientas de análisis de eventos permiten la generación de alarmas,

reportes, etc.
• Prevención de enumeración de recursos compartidos

Evitar la enumeración de los recursos compartidos y del administrador de
seguridad de cuentas (SAM – Security Account Manager) mediante la
configuración correspondiente.
3.1.2.3 Protección de los datos.
• Controlar y administrar el acceso de los usuarios sobre los activos lógicos:

Se debe administrar correctamente los recursos lógicos como archivos, bases de
datos, programas de software y data warehouses, y llevar un control sobre ellos
para detectar posibles accesos no autorizados, hurto de datos o descubrimiento
de información.
115
Para este fin se propone la elaboración de una tabla que refleje la asignación de
permisos sobre los activos lógicos por perfil y por usuario.
Este documento llamado Tabla de Permisos sobre Activos Lógicos se exhibe a

continuación:
Tabla de Permisos sobre Activos Lógicos
PERFILES USUARIOS
AUTORIZADOS
CÓDIGO DESCRIPCIÓN AUTORIZADOS PERMISOS CRITICIDAD
CÓDIGO DEL ACTIVO: Es el código correspondiente al activo, previamente asignado

en el Inventario de Activos (ver sección 4.2)
DESCRIPCIÓN: descripción del activo que se está clasificando.
PERFILES AUTORIZADOS: Perfil de usuarios que poseen algún tipo de autorización
de acceso al activo.
USUARIOS AUTORIZADOS: Usuarios que poseen algún tipo de autorización de
acceso al activo.
PERMISOS: Permisos otorgados a ese perfil o usuario. Puede ser:
o L: lectura;
o E: escritura;
o X: ejecución.
O la combinación de los mismos.
CRITICIDAD: Grado de prioridad de protección que se le asigna al bien, según la
experiencia del Ingeniero, el grado de confidencialidad requerido o el valor asignado
por el usuario.
Esta criticidad se medirá en tres niveles:
o 0 (cero): No crítico;
o 1 (uno): medianamente crítico;
o 2 (dos): altamente crítico.
• Espacio de almacenamiento restringido:
116
Restringir el uso del espacio de almacenamiento común (como servidores de

archivos) a los usuarios creando directorios de uso exclusivo individual o por
grupos de trabajo.
De esta forma se protege la confidencialidad e integridad de los datos de los

usuarios, y se ofrece una herramienta de trabajo para los grupos al permitirles
compartir los datos entre los usuarios pertenecientes a ese grupo, y denegar el
acceso al resto.
Con esta facilidad es muy útil la creación de grupos de usuarios por área o sector,
según la funcionalidad de la tarea que realizan.
• Control de cambios en Software:

Llevar un adecuado control y documentación de los cambios realizados en el
software ya sea:
o Una actualización;
o Un cambio de plataforma;
o Agregados de funcionalidad.
Todos los cambios se registrarán adecuadamente en el ABM Activos, como se

especifica en la etapa 4.5 Control de Cambios de esta metodología y en el
Documento de Actualización de Software.
A continuación se presenta el Documento de Actualización de Software para su

utilización cuando se realicen puntualmente actualizaciones de software
(upgrades). Este documento que tiene como fin específico ayudar al
administrador a controlar el proceso de actualización de software en forma
Masiva.
Por ejemplo, cuando se actualiza el software antivirus, que es una tarea ardua ya
que muchos programas no permiten que las actualizaciones sean instaladas por
usuarios sin permisos de administrador, éste es el que debe pasar máquina por
máquina instalando el software.
El Documento de Actualización de Software se usará como ayuda para el control

de las actualizaciones registrando cada máquina a medida que se avanza con las
workstations de la red.
Para más detalles referirse a la sección 6.2.6 Control de Cambios.
117
Documento de Actualización de Software
SOFTWARE DESCRIPCIÓN Fecha Server1 Server2 Server.. CPU001 CPU002 CPU…

.
Antivirus Actualización del 20/10 Ok Ok Ok Ok Ok Ok

antivirus
Sdat4299.exe
Win2k Hotfix para 21/10 Ok Ok Ok Ok Ok Ok

Windows 2000
Kb823182

Windows 2000
Kb824141

Windows 2000
Kb825119
• Control de impacto de nuevo software:

Antes de instalar nuevo software en los equipos se realiza un control de
compatibilidades y aprobación por parte de la gerencia:
o Controlar las licencias de software y de las actualizaciones;
o Verificar los requerimientos de capacidad de procesamiento y almacenamiento
del nuevo software;
o Verificar la compatibilidad con la plataforma de hardware utilizada;
o Preparar los ambientes para la actualización;
o Realizar pruebas de instalación y uso del nuevo software antes de la
instalación definitiva;
o Realizar pruebas de recuperación de errores;
o Verificar la compatibilidad del nuevo software con otros elementos existentes;
o Capacitar a los usuarios.
• Instalación y continua actualización de software de detección y reparación

antivirus:
o Comprobar diariamente la existencia de nuevo software antivirus y sus
actualizaciones (y documentar las actualizaciones en el ABM Activos y en el
Documento de Actualizaciones de Software);
o Comprobar la ausencia de virus antes de utilizar archivos transportados a
través de la red, o en medios magnéticos como diskettes, zips, u otros;
118
o Comprobar la ausencia de virus en archivos adjuntos a mensajes en los

servidores de mail;
o Comprobar la ausencia de virus en los archivos bajados de Internet
(downloads) antes de su ejecución o instalación;
o Realizar planes de continuidad de los negocios ante ataques de virus.
• Realización de copias de seguridad (backups):

o Guardar en forma segura (ver 4.1.1.2 Protección de los equipos) los datos
críticos, información de recuperación de sistemas y registros exactos de las
aplicaciones en forma periódica;
El período de realización de copias y la vida de cada una están definidos en el
Manual de Procedimientos de realización de copias de seguridad (backups);
o Mantener siempre al menos los tres últimos ciclos de backup;
o Comprobar periódicamente los medios de almacenamiento de los backups
(cintas) para garantizar una recuperación exitosa, en caso de necesitarlo;
o Comprobar periódicamente el correcto funcionamiento de las unidades de
cinta para la recuperación de datos desde los medios físicos de
almacenamiento.
o Verificar los procedimientos y procesos de recuperación a partir de los
backups, para garantizar su eficacia y la adecuada restitución del sistema ante
eventualidades;
o Borrar en forma segura el contenido de los dispositivos de backup que estén
fuera de uso, o que contengan información vencida;
o Volcar el procedimiento de backup a un documento para el registro y control
de las unidades de almacenamiento, y su relación con el contenido
electrónico.
Aquí se presenta un registro para llevar ese control de forma ordenada: el Inventario
de Backup.
Inventario de Backup
El ES determinará la técnica más conveniente para realizar el Backup en su sistema

objetivo.
Para la aplicación de cualquier técnica el ES deberá documentar el resguardo de

datos que hizo y proteger ese documento con claves u otros métodos para prohibir
su acceso a extraños. Este documento deberá contener como mínimo la siguiente
información:
CÓDIGO FECHA TIPO A/S MEDIO PASSWORD
BKP0001 24/10/2003 Incremental A Cinta# ******
119
CÓDIGO: Código de 7 dígitos que rotula la copia de seguridad. Sirve para identificar
unívocamente cada copia.
Formato: BKPNNNN
Donde N representa un número, que crecerá correlativamente para identificar los
backups;
FECHA: Fecha en que se realizó la copia de seguridad;
TIPO:
• Incremental;
• Normal;
• Diferencial;
• Diaria;
• Copia.
A/S:
• A: Append: si los backups se van concatenando en el medio físico;
• S: sobreescritura: Si los backups son reemplazados por la nueva copia.
MEDIO: Medio físico en el que se realiza la copia. Ej: Cinta#1, Cinta#2;
PASSWORD: Contraseña de cifrado de la copia.
• Restricción de acceso a los datos:

Establecer en forma unívoca los permisos otorgados a cada perfil de usuario para
evitar accesos no autorizados en los distintos entornos:
o Archivos;
o Bases de datos;
o Aplicaciones;
o Servicios.
• Protección de la documentación del sistema:

o Almacenar la documentación del sistema en forma segura: bajo llave en
archivos o armarios de acceso restringido;
o Los documentos de administración de la seguridad deben estar protegidos de
manera especial, y sólo debe tener acceso a ellos el o los responsables
correspondientes. Son de crítico manejo los siguientes documentos:
La Política de Seguridad;
Los manuales de Procedimiento;
120
Los instructivos técnicos;

Los Estándares de seguridad;
El Inventario de Activos;
El Mapa de Vulnerabilidades;
El ABM Activos;
El Diario de Incidencias.
o Proteger la documentación del sistema almacenada en una red local,

implementando un sistema de acceso o privilegios por perfil;
o Proteger la documentación del sistema almacenada en una red pública, o
suministrada a través de una red pública con métodos seguros:
Permitir sólo acceso a la lectura de los documentos;
Implementar un sistema de verificación de integridad de los archivos,
contra las modificaciones no autorizadas;
Implementar métodos de intercambio de información seguro, protegiendo
la confidencialidad de los datos;
Aplicar otros métodos que garanticen integridad de los datos, según la
necesidad;
Ejemplos de herramientas que se pueden utilizar para lograr esto son:
- Aplicar funciones HASH;
- Aplicar MAC (Message Authentication Code);
- Implementar IPSec.
• Protección de la información publicada en la Web:

La información publicada en Internet debe ser protegida contra modificación, ya
que si se ve afectada la integridad de las publicaciones, la seguridad de la
empresa, y su reputación estarán en juego.
• Protección del correo electrónico:

Implementar técnicas de encripción de mensajes o firma digital para el
intercambio seguro de correo electrónico.
• Protección del tráfico cliente-servidor:

Proteger el tráfico entre equipos clientes y servidores mediante el recurso
adecuado según corresponda:
o Firma digital;
o Cifrado de paquetes;
o Autenticación Kerberos;
o Métodos de hash.
121
• Protección del tráfico de los vínculos:

Proteger el tráfico entre equipos distantes mediante el ccifrado de paquetes.
3.1.3 Protección a nivel de la organización.
Se analiza en esta parte la protección de los distintos Activos a nivel de la

organización.
Se deben considerar algunos de los siguientes puntos:
• Elaboración/adecuación de una Normativa de seguridad:

A nivel de la organización, el primer paso en la protección del entorno es
establecer la normativa que dicte los lineamientos sobre los procedimientos, las
tareas y procesos informáticos. La normativa se materializa en un “Manual de
Seguridad” compuesto por:
o La Política general de Seguridad;
o Las Normas;
o Los procedimientos;
o Los estándares técnico;
o Los Manuales de usuarios.
Para la Elaboración/adecuación de una Normativa de seguridad referirse al

capítulo 4, sección 3 de esta tesis.
• Determinación de la necesidad de un cambio en la estructura de la organización:

o Crear un sector dedicado a la seguridad informática:
Si la empresa en cuestión no presenta la estructura organizacional que
soporte el siguiente esquema de responsabilidades, será tarea de ES diseñar y
proponer una serie de responsabilidades a crear en la organización, pudiendo
implicar la creación de un área de Seguridad Informática y una de Control
Interno o Auditoría;
o Determinar los roles y responsabilidades:

Este proyecto consiste en dar una razonable protección a la información a
través de la correcta administración de la seguridad por parte de los
responsables asignados a cada una de las funciones dentro de la compañía
objetivo. Para ello se deben definir los roles y las responsabilidades que lo
ejecuten.
A continuación se definen los roles y responsabilidades de cada una de las
funciones relacionadas con la seguridad:
122
Dueño de los datos

Se llama Dueño de los Datos a todo Director y/o Gerente de cada área de la
empresa responsable sobre la información correspondiente a su ámbito de
trabajo.
El Dueño de los Datos podrá asignar las tareas de administración y control de
las medidas de seguridad del área, a un colaborador, quien recibe el nombre
de Dueño de los Datos Delegado.
Son sus principales responsabilidades:
Identificar toda la información de su área, cualquiera sea su forma y
medio de conservación;
Clasificar su información de acuerdo a su grado de criticidad,
documentando y actualizando periódicamente esta clasificación;
Determinar qué usuarios de su área pueden acceder a su información,
asegurando que cada uno tenga garantizado el ingreso a los datos de
acuerdo a sus respectivas funciones, y en el marco de lo especificado por
la Norma de Administración de Usuarios, Accesos y Recursos;
Proponer los eventos de seguridad adicionales que considere necesarios
para proteger su información.
Oficial de Seguridad
El Oficial de Seguridad es quien tiene a su cargo la definición y el
mantenimiento del marco normativo y el asesoramiento a todo el personal de
la compañía para su implantación.
En relación a esta función, es responsable de:
Implantar un programa de concientización permanente de usuarios sobre
la seguridad de la información y su mantenimiento a futuro;
Mantener actualizada la normativa de seguridad y la lista de todos los
Dueños de los Datos/ Delegados;
Dar soporte a los involucrados en los procesos de:
- Definición de los Dueños de los Datos/ Delegados;
- Identificación de la información sensible;
- Identificación de las medidas de seguridad necesarias en cada sistema
para cumplir con la normativa;
- Implantación de dichas medidas;
Asistir al Administrador de Seguridad en la implantación de la normativa
de seguridad informática;
Efectuar el control de los principales eventos que afecten la seguridad de
la información y la posterior comunicación y asistencia a los Dueños de los
Datos / Delegados y demás responsables en:
- Identificación del problema;
- Análisis del impacto;
- Definición de acciones a llevar a cabo;
123
Participar en la investigación y recomendación de productos de seguridad

en conjunto con el área de Sistemas, para la implantación de las medidas
de seguridad en los sistemas;
Participar en el proceso de evaluación de los riesgos emergentes ante una
situación de interrupción no prevista del procesamiento de sistemas,
definición de las distintas estrategias de recuperación, y en la prueba e
implantación de los planes de recuperación ante desastres definidos;
Participar en el diseño, desarrollo, mantenimiento o adquisición de
sistemas de aplicación en cuanto a:
- Identificación y evaluación de los controles automatizados del sistema,
menúes de usuarios y controles manuales adicionales a incluir en los
procedimientos que acompañen a su operatoria;
- Participación en la definición y evaluación de los lotes de prueba y
durante los procesos de conversión e implantación de los sistemas de
aplicación;
- Determinación de los perfiles de usuarios que accedan a cada uno de los
puntos de menú en relación al puesto de trabajo.
Administrador de Seguridad
Se define como tal a la persona que tiene a su cargo la ejecución de las
medidas de seguridad en algún equipo de procesamiento, servicio y/o
aplicación.
Sus principales responsabilidades relacionadas con la protección de la
información son:
Administrar todas las solicitudes de alta, baja y modificación de permisos
relacionados con los accesos de los usuarios a los respectivos equipos y
aplicaciones;
Implantar en los sistemas todos los parámetros definidos en las normas,
procedimientos y estándares específicos;
Asistir a los usuarios en las tareas relacionadas con la protección de los
datos;
Analizar e informar cualquier evento que atente contra la seguridad
informática, así como controlar periódicamente que solamente los usuarios
autorizados posean acceso a los recursos.
Operador Responsable
Se establecen como Operadores Responsables de la información a:
Los responsables de los archivos centralizados de la información en
soportes (escritos en papel o electrónicos);
Los responsables de los Centros de Procesamiento de Datos o de los sitios
donde se encuentren los equipos de procesamiento centralizado, de
comunicación y/o de almacenamiento;
Sus principales responsabilidades son:
Implantar las medidas de seguridad física definidas para la protección de
la información en la normativa correspondiente;
124
Disponer la efectiva custodia de las claves de mayor riesgo de los

equipos/servicios/aplicaciones conservadas en medios impresos.
Comité de Cambios
Planificar, priorizar, autorizar y coordinar las tareas a realizar por los
distintos involucrados ante la necesidad de realización de cambios de
sistemas en producción;
Definir los criterios sobre los cuales se realiza la evaluación de impacto y
criticidad de los cambios;
Liderar los procesos de cambio a realizar ante situaciones de emergencia;
Evaluar periódicamente el registro de los cambios realizados en los
sistemas de producción, a fin de ajustar los criterios de evaluación,
planificación y priorización de tareas.
Usuarios
Se considera como tales a todos los sujetos que hacen uso de los equipos,
servicios y aplicaciones y de la información de la empresa, para poder cumplir
con sus respectivas tareas.
Son sus responsabilidades:
Cumplir con todas las medidas de seguridad definidas en el Manual de
Seguridad;
Resguardar los soportes de información que conserven en su poder, según
lo establecido en el Procedimiento de Tratamiento de la Información;
Firmar el Compromiso de Confidencialidad de la Información.
• Implantación de políticas para evitar ataques internos:

[Huerta2000] Afirma que: “el 80 % de los fraudes, robos, sabotajes o accidentes
relacionados con los sistemas informáticos son causados por el propio personal de
la organización propietaria de dichos sistemas, lo que se suele denominar insider
factor.”
Esto significa que la mayoría de los ataques a los sistemas informáticos son
perpetrados por el propio personal que trabaja actualmente en la empresa, o que
ha trabajado con anterioridad. Estas son personas con envidia, codicia o ex
empleados que desean vengarse por haber sido despedidos, o por otras
desconformidades.
Las personas que trabajan en el área de administración de los sistemas, de redes

o en desarrollo, tienen conocimiento de claves, formas de acceso, ubicación de
información crítica y hasta tienen conocimiento de las fallas y debilidades del
sistema.
Es por esto que se aconseja tomar medidas preventivas acerca de esta realidad:
125
o Mínimo privilegio:
A cada usuario se le debe otorgar el mínimo privilegio que necesita para
realizar su actividad;
o Conocimiento parcial:
Las actividades críticas de la organización deben ser conocidas y realizadas
por varias personas competentes para que puedan respaldarse en caso de
incidencias como accidentes o viajes. No centralizar el conocimiento de datos
críticos en una sola persona, por ejemplo el conocimiento de la contraseña del
administrador debe ser compartido con al menos 2 personas de confianza;
o Rotación de funciones:
Para evitar la complicidad de dos responsables, o evitar el mutuo sabotaje si
están enemistados;
o Separación de funciones:
La separación de funciones es un método usado para reducir el riesgo de mal
uso, accidental o deliberado del sistema.
Separar la gestión o ejecución de ciertas tareas o áreas de
responsabilidad, a fin de reducir las oportunidades de modificación no
autorizada o mal uso de la información o los servicios;
Evitar que una sola persona tenga la responsabilidad total de la seguridad
de la empresa;
• Implantación de políticas de escritorios y pantallas limpias:
o Implementar una política de escritorios limpios para proteger documentos en

papel y dispositivos de almacenamiento removibles para evitar robos,
pérdidas o daño de la información, y protegerla de desastres naturales.
o Implementar una política de pantallas limpias para reducir los riesgos de

acceso no autorizado, pérdida y daño de la información durante el horario
normal de trabajo y fuera del mismo.
Almacenar bajo llave los documentos en papel y los medios de
almacenamiento cuando no están siendo utilizados, especialmente fuera
del horario de trabajo;
Guardar bajo llave la información sensible o crítica de la empresa,
especialmente cuando no hay personal en la oficina;
No dejar conectadas las computadoras personales, terminales e
impresoras cuando están desatendidas;
Desconectar toda sesión activa cuando la terminal no verifique uso
durante un período minutos de duración (10, 15 o 30) e implantar
medidas para bloquear las terminales desatendidas;
126
Proteger las computadoras personales, terminales e impresoras con

cerraduras de seguridad, contraseñas u otros controles cuando no están
en uso;
Proteger los puntos de recepción y envío de correo y las máquinas de fax y
telex no atendidos;
Bloquear las fotocopiadoras (o protegerlas de alguna manera del uso no
autorizado) fuera del horario normal de trabajo;
Retirar de la impresora inmediatamente la información sensible o
confidencial, una vez impresa.
• Separación de las instalaciones de desarrollo, de prueba y producción:

Es fundamental separar físicamente las instalaciones de desarrollo, prueba y
producción para evitar confusiones, pérdida de información y fallas en la
confidencialidad de los datos.
Se debe trabajar en instalaciones separadas que garanticen integridad en el

ambiente de desarrollo, estabilidad en el ambiente de pruebas y confidencialidad
en al ambiente de producción u operación.
Se recomienda la separación entre las instalaciones de desarrollo, pruebas y

operaciones, a fin de reducir el riesgo de cambios accidentales o accesos no
autorizados al software operativo y a los datos del negocio.
Se deben tener en cuenta los siguientes controles:

o Ejecutar el software en desarrollo y en producción en diferentes procesadores
o en diferentes dominios o directorios;
o Separar las actividades de desarrollo y prueba;
o Prohibir el acceso a compiladores, editores y otros utilitarios del desde los
sistemas que están operativos ( en producción);
o Utilizar diferentes procedimientos de login para sistemas de prueba y en
producción, a fin de reducir el riesgo de error por parte de los usuarios;
o Recomendar a los usuarios la utilización de diferentes contraseñas para estos
sistemas;
o Definir las reglas para la transferencia de software desde el ambiente de
desarrollo hacia el ambiente de prueba y al de producción y documentarlas en
el Manual de Procedimientos correspondiente según lo indica la Política de
Seguridad;
• Establecimiento de un método de registro del flujo de personal:

Registrar fecha y hora de entrada y salida del personal, tal como se sugiere en
4.1.1.1 Protección de las Instalaciones.
• Implantación de medidas de protección para el transporte de activos:
127
o Utilizar medios de transporte o servicios de mensajería confiables;

o Crear una lista de servicios de mensajería autorizados e implementar un
procedimiento para verificar la identificación de los mismos;
o Proteger el bien contra eventuales daños físicos durante el tránsito con un
adecuado embalaje, siguiendo las especificaciones de los fabricantes o
proveedores;
o Adoptar controles especiales para proteger la información sensible contra
divulgación o modificación no autorizadas;
Por ejemplo:
Usar recipientes cerrados;
Entregar el Activo en mano;
Cuando sea necesario, hacer una división de los bienes a enviar en más de
una entrega y enviarla por diferentes rutas;
Usar una codificación adecuada para rotular los paquetes, que no permita
descifrar el contenido por personal no autorizado.
• Protección de las operaciones de comercio electrónico:

Las transacciones de comercio electrónico comprenden un intercambio de
información delicada, como precios, números de tarjetas de crédito, crédito
disponible de un usuario, y otros datos personales como dirección, número de
teléfono, número de documento, y hasta preferencias personales.
Todos estos datos pueden ser interceptados por intrusos que los modifiquen o
simplemente saquen provecho de forma fraudulenta de esa información.
Para prevenir el mal uso de nuestros datos, su manipulación o modificación, se

debe hacer uso de herramientas y aplicar técnicas que lo eviten. Estas técnicas
deben garantizar:
o Autenticación del cliente y el comerciante;
o Autorización para fijar precios, emitir o firmar los documentos comerciales;
o Confidencialidad, integridad y prueba de envío y recepción de documentos
clave y de no repudio de contratos en los procesos de oferta y contratación;
o Confiabilidad y autenticación en la información sobre precios y descuentos;
o Confidencialidad e integridad de los datos suministrados con respecto a
órdenes, pagos y direcciones de entrega, y confirmación de recepción en las
transacciones de compra;
o Verificación de los datos del cliente;
o Cierre de la transacción;
o Determinar la forma de pago más adecuada para evitar fraudes;
o Confidencialidad e integridad de la información sobre órdenes de compra para
evitar la pérdida o duplicación de transacciones;
o Definir la responsabilidad de las partes;
128
o Determinar quién asume el riesgo de eventuales transacciones fraudulentas;

Para implementar estas medidas se puede hacer uso de alguna de las
siguientes herramientas:
Firma digital;
Encripción de datos;
Certificados digitales;
IPSec;
SET (Secure Electronic Transaction).
El ES determinará, según el caso, la forma más adecuada de llevar a cabo

esta tarea.
• Protección del correo electrónico:

o Determinar cuáles son las cuentas no autorizadas para intercambio de correo;
o Determinar las consideraciones legales aplicables:
Publicación de direcciones corporativas;
Filtrado de contenido de los mensajes;
Necesidad de prueba de envío, origen, entrega y aceptación;
o Determinar las acciones aplicables a correo entrante al dominio para usuarios
desconocidos;
• Implantación de un proceso de autorización para la publicación de información

electrónica de la empresa:
o A través de la publicación de páginas en Internet;
o A través de la difusión de noticias y contenido en mensajes de correo
electrónico;
• Control de las operaciones de oficina:

Las oficinas manejan datos de una forma en que se propicia la divulgación de
información y el intercambio de datos mediante el uso de documentos impresos,
intercambio de archivos, computación móvil, correo postal, correo electrónico,
correo de voz, máquinas de fax, comunicaciones telefónicas, servicios
multimedia, etc;
Se deben controlar:
o La autorización de grabación de comunicaciones telefónicas o
teleconferencias;
o La forma en que se distribuye la información, por ejemplo a través de
comunicados generales o boletines corporativos;
o El proceso de recepción de correspondencia y su distribución;
o Restricción en el uso de determinadas instalaciones;
129
o Políticas de retención y resguardo de información;
• Persuadir a los empleados del intercambio discreto de información:

En las oficinas se produce un continuo y hasta forzoso intercambio de información
entre los empleados de la compañía y entre terceros;
Se debe persuadir a los empleados el intercambio discreto de información,
recomendándoles:
o No tratar temas confidenciales en comunicaciones telefónicas, en particular
con teléfonos móviles;
o No tratar temas confidenciales en lugares públicos u oficinas de acceso
común;
o Tener especial cuidado con la información dejada en contestadores
automáticos ya que puede ser escuchada por personas no autorizadas;
o Tener especial cuidado al enviar mensajes por fax, ya que se puede enviar
documentación a un número erróneo;
• Reportar los incidencias:

Crear un circuito que permita el reporte, registro y solución de incidencias, así
como la prevención a partir de la Norma de Manejo de incidencias del Manual de
Seguridad Informática.
Para más detalles sobre el manejo de incidencias ver la etapa 6.1 de la MAEI.
• Controlar los cambios:

Mantener un control sobre los cambios realizados en el entorno, en equipos, en
software y otros recursos.
Para ello se recomienda seguir el procedimiento fijado en la Norma de Control de

Cambios, y, para una fácil administración de los cambios, referirse a la sección
6.2 de esta metodología.
3.2 APROBACIÓN DEL PLAN DE ASEGURAMIENTO
Una vez elaborado el plan de Aseguramiento, el cliente debe dar su aprobación para
su implantación.
Como todo proyecto, debe estar acompañado del apoyo del nivel gerencial y de los
responsables directos involucrados.
130
El proceso de aprobación variará según las costumbres y políticas del cliente, pero en
todos los casos va acompañado de la asignación de un presupuesto a invertir en los
recursos asignados en la planificación.
131
4 IMPLANTACIÓN
Contenido:

4.1.1 Inventario de Activos
4.1.2 Ejemplo – Inventario de Activos
4.1.3 Rotulación de activos
4.1.4 Análisis de Criticidades
4.2.1 Identificación de la información
4.2.2 Tipos de información
4.2.3 Beneficios de la clasificación de la información
4.2.4 Riesgos de la información
4.3 Elaboración/ adaptación de la Normativa de Seguridad
4.3.1 Interiorización del experto con la política y negocio de la organización
4.3.2 Elaboración/adaptación de la Normativa de Seguridad
4.3.2.1 Política de Seguridad
4.3.2.1.1 Definición
4.3.2.1.2 Ámbitos de aplicación y personal afectado
4.3.2.2 Normas y Procedimientos
4.3.2.2.2 Espectro de las Normas y los Procedimientos
4.3.2.2.3 Ejemplo - Normas y Procedimientos
4.3.2.3 Estándares, Esquemas y Manuales de usuarios
4.3.2.4 Implantación y uso de la Normativa de Seguridad
4.3.2.5 Convenio de Confidencialidad
4.4.1 Implantación de una campaña de concientización
4.4.2 Capacitación de los usuarios
132

4.5.1 Implantación a nivel físico
4.5.2 Implantación a nivel lógico
4.5.3 Implantación a nivel de la organización
4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres (PRED)
4.6.1 Establecimiento del escenario considerado
4.6.2 Determinación de los tipos de operación en una contingencia
4.6.3 Establecimiento de criticidades
4.6.3.1 Tabla de Criticidades por Equipo
4.6.3.2 Ejemplo - Tabla de Criticidades por Equipo
4.6.3.3 Tabla de Criticidades por Servicios
4.6.3.4 Ejemplo - Tabla de Criticidades por Servicios
4.6.3.5 Tabla de Criticidades por Aplicaciones
4.6.3.6 Ejemplo - Tabla de Criticidades por Aplicaciones
4.6.4 Determinación de las prestaciones mínimas
4.6.5 Análisis de riesgos
4.6.5.1 Probabilidad de ocurrencia de desastres
4.6.5.2 Determinación de los niveles de desastre
4.6.6 Presentación de las distintas estrategias posibles de recuperación
4.6.7 Selección de la estrategia de recuperación
4.6.8 Elaboración de la estrategia de recuperación
4.6.8.1 Mitigación de riesgos – Medidas preventivas
4.6.8.2 Descripción de la estrategia
4.6.8.3 Requerimientos para llevar a cabo el Plan
4.6.8.4 Esquemas técnicos
(ERED)
4.6.8.5.1 Roles y responsabilidades
4.6.8.5.2 Asignación de roles
4.6.8.6 Establecimiento de los procedimientos
4.6.8.6.1 Declaración de la emergencia
4.6.8.6.2 Recuperación de las prestaciones
4.6.8.6.3 Reestablecimiento de las condiciones normales
133
Culminadas las fases correspondientes a la primera parte de esta metodología, el

estudio del entorno, se da comienzo al segundo y último grupo de fases llamado
Implantación de la solución. Dentro de este grupo se encuentra la fase que da título
al presente capítulo. En el mismo se desarrolla la implantación de la solución.
En esta fase se lleva a la práctica lo planificado realizando los controles y ajustes

necesarios según lo relevado anteriormente.
A su vez, y como en todo este trabajo, este capítulo se divide en etapas que
describen tareas.
Se pretende llevar un orden en la ejecución de las etapas aquí presentadas, pues es

de particular importancia para seguir el razonamiento desarrollado en esta tesis.
Las etapas a desarrollar son las siguientes:

4.3 Elaboración/adaptación de la Normativa de Seguridad
Cada una tiene un objetivo específico e individual, que contribuye en parte a lograr el
objetivo de la fase, que es la implantación de las medidas de seguridad planificadas.
El ES considerará la necesidad de implementar todas o alguna de las etapas

propuestas, pero de hacerlo, deberá respetar el orden sugerido ya que las tareas que
se desarrollan alimentan muchas veces a otras que les siguen, aunque no
necesariamente deben estar todas presentes.
La Clasificación de la Información no puede realizarse sin un relevamiento de los

activos físicos y lógicos de la Organización, aunque no es estrictamente necesario
que se formalice esto en un inventario como se sugiere en la etapa 4.1.
También, para la elaboración del Manual de Seguridad, en particular de ciertos

procedimientos como los de manipulación de equipos, el de transmisión de datos, el
de borrado seguro de información, es necesario clasificar la información., y a su vez,
para poder clasificar la información se debe contar con la Norma que establezca esa
clasificación.
134
Más allá de la interdependencia entre etapas, la fase debe interpretarse como una
unidad en la que se pretende materializar las medidas planificadas para lograr el
aseguramiento del entorno.
4.1 Elaboración del Relevamiento de Activos.
Según [IRAM17799] “para mantener una adecuada protección de los activos de la

organización se debe rendir cuentas por todos los recursos de información
importantes y se debe designar un propietario para cada uno de ellos”.
En esta etapa de la MAEI el ES realiza un detallado relevamiento de los bines o

activos en posesión de la organización objetivo.
Para el desarrollo de esta tarea se presenta una tabla para la documentación de la

existencia de los recursos de hardware, software y la información de una empresa y
su clasificación, según su criticidad.
Este documento es el Inventario de Activos.
4.1.1 Inventario de Activos
El Inventario de Activos aquí propuesto pretende llevar una contabilidad de los bienes
de la organización en cuestión, clasificándolos según el nivel de protección que cada
uno necesita, según la valorización de los responsables.
Se hará distinción entre los elementos físicos o tangibles (como las instalaciones) y
los lógicos o intangibles (como la información).
Para este fin se propone la elaboración de un Inventario de Activos Físicos, y un

Inventario de Activos Lógicos.
El Inventario de Activos Físicos contendrá los siguientes elementos:
• Elementos de hardware:
o Equipamiento informático: monitores, módems;
o Equipos de comunicaciones: routers, PABXs, hubs, switches, etc;
o Medios magnéticos: cintas y discos removibles;
135
o Periféricos: impresoras, máquinas de fax, contestadores automáticos;

o Cableado: cables internos y externos;
o Otros equipos técnicos: de suministro de electricidad como UPSs, aire
acondicionado;
o Mobiliario, lugares de emplazamiento;
o Se hará una distinción especial sobre las CPUs para facilitar su identificación.
• CPUs:
Se establece una distinción del resto de los elementos de hardware para su fácil
identificación:
o Procesadores, computadoras portátiles.
Asimismo, el Inventario de Activos Lógico contendrá estos elementos:
• Elementos de software:
o Sistemas operativos;
o Software de aplicaciones;
o Software de sistemas;
o Herramientas de desarrollo;
o Utilitarios.
• Servicios:
o Servicios informáticos;
o Servicios de comunicaciones;
o Servicios generales (calefacción, iluminación, energía eléctrica, aire
acondicionado).
• Datos:
o bases de datos;
o archivos;
o documentación de sistemas: manuales de usuario, material de capacitación,
procedimientos operativos o de soporte, planes de continuidad, documentos
de alcance, de diseño, de pruebas, etc.;
o información archivada.
• Backups:
Se hace especial mención de los elementos de recuperación de información,
para su correcta administración, actualización y control y como apoyo al
documento de Administración de Backups [3.1.2.4]
136
Estructura del Inventario de Activos
FECHA FECHA CRI- ES-

CREACIÓN EXPIRACIÓN TICI- TA-
CÓDIGO DESCRIP. UBICACIÓN RESP. DAD DO
CÓDIGO: Es el código rotulador que se asignará a cada elemento que permitirá

identificar cada bien unívocamente, para su identificación y seguimiento. Este rótulo
se deberá colocar a la vista en elementos físicos (productos de hardware, cintas de
backup, periféricos, etc) para su identificación.
Se establece para ello la siguiente clasificación de elementos:

• Hardware notado HDW
• CPUs notado CPU
• Software notado STW
• Servicio notado SRV
• Datos notado DAT
• Backup notado BKP
La codificación de los activos se realiza concatenando la sigla del tipo de elemento

con un número correlativo creciente decimal de 4 dígitos.
Por ejemplo:
HDW0034: es el elemento de hardware número 34
BKP0102: es el backup número 102
NOTA: cabe destacar que este tipo de codificación incrementa la seguridad,

protegiendo los elementos de backup contra hurto, ya que el rótulo no se puede
relacionar inmediatamente con la fecha de backup y la aplicación sobre la cual se
realizó la copia de seguridad, si no es mediante el presente documento, que
establece una relación única entre el código de activo y la descripción.
137
DESCRIP.: es una descripción del elemento en cuestión en la que se debe destacar

marca del producto, y otros datos relevantes (como número de serie, etc)
UBICACIÓN: Es la ubicación física del activo. Para elementos de hardware, será el

piso, el sector, sala donde está ubicado. Para elementos de software será la ubicación
lógica del archivo: servidor o PC con path completo en la unidad de hardware
correspondiente.
RESP.: Es la persona que se hace cargo del elemento cuando ocurre un incidente en
el que esté involucrado.
FECHA CREACIÓN: Para elementos de hardware será la fecha de compra del

mismo, o la de fabricación, y para los elementos de software se considerará la fecha
de creación de dicho archivo.
Formato: dd/mm/aaaa
FECHA EXPIRACIÓN: Frecuentemente, la información deja de ser sensible o crítica

después de un cierto período de tiempo, por ejemplo, cuando la información se ha
hecho pública.
Para elementos de hardware este campo puede dejarse en blanco, salvo que el
elemento sea alquilado y tenga una fecha de baja preestablecida, y para los
elementos de software se considerará la fecha en que la información contenida en el
archivo pierda validez, o se realice la depuración correspondiente.
Formato: dd/mm/aaaa
CRITICIDAD: Indica el grado de protección que se le deberá asignar al bien, según

la experiencia del Ingeniero o el valor asignado por el usuario.
Este nivel de criticidad será asignado en el Inventario de Activos una vez hecho el
correspondiente Análisis de Criticidades y la posterior Clasificación de la Información.
Por el momento, se sugiere dejar este campo vacío y completarlo una vez pasadas
las etapas mencionadas.
Para más detalles en cuanto al Análisis de Criticidades ver el apartado 4.1.2 de esta
Tesis.
Para la Clasificación de la Información consultar la parte 4.2.
ESTADO: puede tomar tres valores:
138
• A: Significa que el activo ha sido dado de alta y efectivamente forma parte del
inventario actual de la organización;
• B: Indica que el activo existió, y fue dado de baja;
• M: El activo ha sido modificado (pero sigue en uso).
4.1.2 Ejemplo – Inventario de Activos
Inventario de Activos Físicos

HDW0001 Mouse serie Piso 9, sector María 12/2001 - (011) A

Logitech QA, cpu: Martinez
HW0017
--- --- --- --- --- --- --- …
HDW0034 Router Cisco Piso 7, sector Manuel 7/2003 - (021) A

8000 comunicaciones Belgrano
--- --- --- --- --- --- --- …
--- --- --- --- --- --- --- …
--- --- --- --- --- --- --- …
Inventario de Activos Lógicos

BKP0102 Backup de HW0024 Juan 20/05/2003 20/06/2003 (233) B

Srv01/exter Perez
no/proy5.m
bd
--- --- --- --- --- --- --- …
DAT0067 Notas de CPU0002/d:/Lo María 14/12/2002 14/12/2003 (121) A

logística en gística/Notas/ López
formato .doc
--- --- --- --- --- --- --- …
BKP0106 Backup de HW0024 Juan 20/06/2003 20/07/2003 (233) M

Srv01/exter Perez
no/proy5.m
bd
--- --- --- --- --- --- --- …
139
4.1.3 Rotulación de activos
Luego de la clasificación de la información y de la elaboración del inventario de

Activos Lógicos y del Inventario de Activos Físicos se procede a la identificación de
los activos por medio de rótulos o labels.
La ventaja de llevar actualizado los inventarios es que de esta forma se pueden

rotular los activos con el código asignado en el Inventario, y no con la descripción
explícita.
Este mecanismo es muy útil para proteger la información contra hurtos y sabotajes.
Un ejemplo claro es el caso de las cintas de backup. Si una cinta de backup contiene
una indicación clara de la información que contiene, su criticidad, la fecha en que se
realizó, etc, es susceptible de ser un blanco de codicia por parte de intrusos
hambrientos de información.
Es mucho más fácil para un delincuente extraer de la empresa una cinta de backup
que una CPU, y más fácil aún que penetrar las barreras de seguridad lógica de la red.
La forma en que se rotulen los activos puede ser muy variada, pero para hacer esto
se deberá desarrollar un estándar que indique claramente cómo se realizará esta
identificación, si se utilizará una nomenclatura distinta de la del inventario de Activos,
para lo cual se deberá establecer la relación entre el código registrado en el
Inventario y el asignado al medio físico.
Esta práctica es la menos recomendada, ya que provoca confusiones, es más

laboriosa, se pierde integridad en la forma de manejar los indicadores, y está en
riesgo la pérdida de la transformación que relaciona la descripción del activo (entrada
en el Inventario de Activos) y su rótulo, que es la identificación asignada para su
visualización física.
Mucho más práctico es utilizar el código asignado en el Inventario de Activos que fue
diseñado con el fin de otorgar una descripción al personal que maneja los bienes en
su labor diaria, pero que no aporta información sobre su contenido y clasificación a
personas ajenas al manejo de estos códigos.
4.1.4 Análisis de Criticidades
El análisis de criticidades es el paso previo a la Clasificación de la Información.
140
Para clasificar la información de acuerdo a algún rango establecido en primer lugar

hay que establecer cuán crítico es el activo en cuestión.
La criticidad se puede expresar mediante la necesidad de conservar tres atributos:
• La autenticidad;
• La disponibilidad;
• La integridad.
Cada Dueño de los Datos debe analizar su información para proceder a su

clasificación, basándose principalmente en los perjuicios que pudiera ocasionarle a la
Compañía objetivo y/o a su personal, el incumplimiento de alguno de los valores
establecidos en la Política General. Dichos prejuicios pueden ser: sociales, legales, de
imagen, políticos, económicos y/o financieros.
La clasificación de la información debe estar sustentada por los siguientes criterios

básicos:
• El valor estratégico de la información para la Compañía;

• La ventaja competitiva que puede darles a terceros su conocimiento;
• Los criterios específicos que definan las autoridades de la Compañía;
• Las leyes y reglamentaciones vigentes.
Asimismo, el impacto y probabilidad de una pérdida en seguridad se pueden clasificar

en cuatro niveles:
• Nivel 3: Alto riesgo; Daño irreparable, Impacto a nivel corporativo de 2 a 5 años.

Es un objetivo de ataque de alta probabilidad;
• Nivel 2: Nivel 2: Daño Significativo. Impacto a nivel de país de la empresa / sede

hasta 2 años. Es un objetivo posible.
• Nivel 1: Daño Moderado. A nivel departamental. Impacto de menos de 1 año. Es

un objetivo poco probable;
• Nivel 0: Ningún Daño. Con licencia completa. Dominio público. No es un objetivo

de ataque.
Para establecer la criticidad del activo se sugiere la siguiente notación, de uso

común en varias compañías internacionales:
(Nivel de autenticidad, Nivel de disponibilidad, Nivel de integridad)
141
Cuanto mayor sea el nivel con que se clasifique la información, mayor será el riesgo
de la misma y por ende los controles que se ejerzan sobre ella para protegerla.
Ejemplo: (0,1,3) implica que la información necesita garantizar una autenticidad

mínima, un nivel moderado de integridad, y un alto requerimiento de integridad, por
lo que se deberá hacer hincapié en controles que garanticen este último atributo.
La Clasificación de la Información de la Compañía debe estar alineada a la Política de

Seguridad de la compañía, y se debe definir para cada una de las áreas de negocio.
El tratamiento de la Información debe responder a su clasificación.
4.2.1 Identificación de la información
Los gerentes de las áreas o de las divisiones, que son Dueños de los Datos, tienen la
responsabilidad primaria de clasificar la información y protegerla adecuadamente. La
clasificación de datos y los procedimientos de manejo especial se usan para proteger
los datos de divulgaciones no autorizadas.
Cada Dueño de los Datos debe identificar toda la información que se genera dentro
del área que maneja, en todas sus formas y medios, tales como:
• documentos propios y/o de terceros;

• información en los sistemas/equipos de procesamiento, individuales y/o
centralizados;
• informes, reportes y listados;
• medios magnéticos móviles;
• cualquier otro soporte físico que contenga información.
La dirección de la empresa debe evaluar la probabilidad y el impacto producto de la

divulgación, modificación y/o pérdida de información, como base para determinar el
valor de la información.
Cada organización deberá establecer las categorías adecuadas para la clasificación de

la información que maneja. En algunos casos manejará información confidencial, en
otros será restringida o pública.
142
4.2.2 Tipos de información
Existen muchos modelos de clasificación de la Información, unos más populares que

otros. Es importante entender el negocio de la empresa objetivo para determinar el
que más se ajusta a su realidad.
Entre los modelos más utilizados está el siguiente, en el que la información se puede
clasificar en tres categorías:
• Confidencial o Sensible: Información de acceso restringido, con alto grado de

secreto, sobre la que tiene permiso un grupo reducido de usuarios (generalmente
de alto rango jerárquico) sobre la que se deben realizar estrictos controles;
Se trata de toda aquella información que puede presentar mayores riesgos para
la Compañía, y que sólo debe ser utilizada por el Dueño de los Datos y las
personas expresa y directamente autorizadas por él en forma específica.
Por ejemplo:
o Políticas de largo alcance;
o Fórmulas críticas que no llevan protección de patentes;
o Planes de fusión y adquisición.
Los generadores de este tipo de información, o el correspondiente Dueño de los

Datos, deben proceder a clasificarla y salvaguardarla de acuerdo al Procedimiento
de Tratamiento de Información.
Además, es necesario incluir en los registros de eventos, todos aquéllos referidos

a la actualización de esta información.
• Restringida: Información de acceso medianamente restringido (utilizada por

usuarios de rango medio, empleados) sobre la que es necesario realizar
suficientes controles para garantizar el acceso adecuado;
• Pública: Información de acceso libre, sobre la que se realizan los mínimos

controles (información disponible para la comunidad);
En otros casos, se utilizan modelos de más niveles de detalle, en los que se incluyen,
además de los anteriores, los siguientes:
• Privada: relacionada con los individuos, tal como evaluaciones de desempeño,

compensaciones y beneficios, carpetas personales o registros médicos;
143
• Uso Interno: relacionada con la operatoria diaria, como por ejemplo planes de
viajes y reuniones, iniciativas de proyectos, distribución física de usuarios y
recursos, precios y demarcaciones.
4.2.3 Beneficios de la clasificación de la información
• Mejora de forma continua la seguridad de la información;

• Establece los principales controles necesarios para evitar accesos externos o
internos no autorizados a la información.;
• Brinda medidas de control para la protección de datos de carácter personal;
• Posiciona la utilización del correo electrónico e Internet como una herramienta de
trabajo;
• Permite la identificación de acciones indebidas en los sistemas;
• Promueve el buen uso y protección de las contraseñas.
4.2.4 Riesgos de la información
Para establecer una clasificación es necesario realizar el paso previo según esta
metodología, que consiste en hacer un análisis de la criticidad de los Activos lógicos y
físicos. Ver 4.1.2 Análisis de Criticidades.
Asimismo, el Dueño de los Datos debe identificar los riesgos a los cuales está
expuesta su información, teniendo en cuenta la posibilidad de que personal interno
y/o externo realice:
• Divulgación no autorizada;
• Modificación indebida;
• Destrucción de los soportes.
4.3 Elaboración/ adaptación de la Normativa de Seguridad
4.3.1 Interiorización del experto con la política y negocio de la organización
144
Para la elaboración o adaptación de un adecuado Marco Normativo el ES debe

interiorizarse con el manejo del negocio, la estructura de la organización, la jerarquía
de la empresa y el manejo de los empleados, pero sobre todo debe interpretar y
conocer la estrategia de la empresa y sus políticas implícitas sobre el manejo de la
información.
El ES deberá evaluar la adecuación de esas costumbres y sugerir los cambios

necesarios para llevar a cabo las mejores prácticas de seguridad.
4.3.2 Elaboración/adaptación de la Normativa de Seguridad
En esta etapa de la MAEI, el ES determinará si es conveniente hacer una adaptación

de la Normativa de Seguridad, si existiera, o si se inclina por la elaboración de una
nueva.
La Normativa de Seguridad es el marco que regula el comportamiento de las

personas en la empresa, su forma de trabajar y de efectuar las tareas que involucran
los recursos del entorno informatizado.
El conjunto formado por los documentos que componen la Normativa de seguridad es

llamado Manual de Seguridad de la empresa.
El Manual de Seguridad está formado por la Política de Seguridad, las Normas, los
Procedimientos, los Instructivos y Estándares técnicos.
A continuación se muestra un gráfico que lo ilustra:
General
Política de Seguridad
Normas
Particular
145
Procedimientos Estándares
La Política de Seguridad es la más general. Contiene los lineamientos y definiciones

independientes de plataformas y tecnologías.
Las Normas son también leyes pero más puntuales que las políticas. Las Normas
generalmente tratan temas específicos a alto nivel.
Los Procedimientos, en cambio, bajan el nivel a una serie de pasos a seguir, siempre
independientemente de la plataforma con que se trabaje.
Los Esquemas, en cambio, son procedimientos dependientes de la tecnología, por lo

que se debe especificar la plataforma, sistema operativo o aplicativo para el que se
deba aplicar.
Finalmente, los Estándares técnicos son documentos que describen la configuración

de cierto sistema, aplicación o hardware. Por ejemplo se puede establecer un
estándar técnico para la configuración de los servidores, para que cada vez que se de
de alta a un nuevo servidor se garantice que siguiendo ese estándar se obtendrá la
misma configuración de los demás servidores, ayudando a la automatización, por
medio de scripts, de dicha configuración.
Para la elaboración del Manual de Seguridad de la Información, que es el conjunto de

documentación que avala el Marco Normativo de una empresa, el ES debe realizar un
relevamiento de aspectos organizativos y políticos, además de los técnicos.
El ES deberá descubrir la forma de comunicación que maneja la empresa, sobre todo

deberá estudiar el lenguaje que emplea la alta gerencia para emitir sus comunicados
detectando la forma gramatical que se utiliza para las expresiones imperativas y las
enunciativas.
Debe prestar especial atención en esto, ya que la Política y las Normas son
enunciadas con un carácter exclusivamente imperativo, ya que son leyes a cumplir
algunas veces por gran parte del personal y en su mayoría por todos.
La forma en que se enuncien las oraciones será crucial para las futuras auditorías, al
momento de verificar el cumplimiento de las Normas.
Como ejemplo, en la experiencia personal de la autora, se observó que en España,

país que posee el mismo idioma que la República Argentina, una manera común de
expresar obligatoriedad es utilizar el tiempo futuro simple, mientras que en la
146
Argentina se hace hincapié en la obligatoriedad de una enunciación agregando las

palabras “se debe”.
El siguiente ejemplo lo ilustra:
La frase: “Se implementarán medidas de restricción de acceso al CPD” en España

expresa una clara obligatoriedad de implementar medidas de restricción del acceso al
CPD, mientras que en la Argentina esta misma frase podría ser interpretada como:
“En algún momento, alguien, implementará medidas de restricción de acceso al CPD,
mientras tanto no me preocupo yo por implementarlas”.
En nuestro país, por tal motivo se utilizan frases del tipo: “Se deben implementar
medidas de restricción de acceso al CPD” para enfatizar la obligatoriedad de la
Norma.
Se debe tener presente al momento de escribir el Manual de Seguridad de una

empresa, que estas leyes deben ser interpretadas y cumplidas por los usuarios, por
lo que deben ser de fácil comprensión, simples y sintéticas, sin ambigüedades ni
contradicciones.
A continuación se pasa a describir en detalle cada componente del Manual de

Seguridad de la Información:
4.3.2.1 Política de Seguridad
La Política de Seguridad es un documento que establece las pautas, según el enfoque

de la organización, y su negocio, en cuanto a la gestión de la seguridad.
La política de Seguridad contiene los principios de seguridad sobre los cuales deben
basarse las normas, procedimientos y estándares detallados. Debe ser conocida y
acatada por todos y cada uno de los miembros de la organización, y debe ser
concebida bajo el total consentimiento y apoyo de la gerencia.
Entre estos principios se encuentran:
• Eficacia: Garantizar que toda información que sea utilizada es necesaria y

entregada de forma oportuna, correcta, consistente y útil para el desarrollo de
las actividades;
147
• Eficiencia: Asegurar que el tratamiento de la información se realice mediante

una óptima utilización de los recursos humanos y materiales;
• Confiabilidad: Garantizar que los sistemas informáticos brinden información

correcta para ser utilizada en la operatoria de cada uno de los procesos;
• Integridad: Asegurar que sea procesada toda la información necesaria y

suficiente para la marcha de las actividades en cada uno de los sistemas
informatizados y procesos transaccionales;
• Exactitud: Asegurar que toda la información se encuentre libre de errores y/o

irregularidades de cualquier tipo;
• Disponibilidad: Garantizar que la información y la capacidad de su tratamiento

manual y automático, sean resguardados y recuperados eventualmente cuando
sea necesario, de manera tal que no se interrumpa significativamente la marcha
de las actividades;
• Legalidad: Asegurar que toda la información y los medios físicos que la

contienen, procesen y/o transporten, cumplan con las regulaciones legales
vigentes en cada ámbito;
• Confidencialidad: Garantizar que toda la información está protegida del uso no

autorizado, revelaciones accidentales, espionaje industrial, violación de la
privacidad y otras acciones similares de accesos de terceros no permitidos;
• Autorización: Garantizar que todos los accesos a datos y/o transacciones que
los utilicen, cumplan con los niveles de autorización correspondientes para su
utilización y divulgación;
• Protección Física: Garantizar que todos los medios de procesamiento y/o

conservación de información cuenten con medidas de protección física que eviten
el acceso y/o utilización indebida por personal no autorizado;
• Propiedad: Asegurar que todos los derechos de propiedad sobre la información

utilizada en el desarrollo de las tareas, estén adecuadamente establecidos a favor
de sus propietarios;
• No Repudio: Garantizar los medios necesarios para que el receptor de una

comunicación pueda corroborar fehacientemente la autenticidad del emisor.
148
4.3.2.1.2 Ámbitos de aplicación y personal afectado
La Política de seguridad, junto con sus extensiones, como los Manuales de

Procedimiento y Estándares de Seguridad, formaliza las medidas a implementar en
los distintos ámbitos determinados en el Alcance de la documentación respectiva, y
que afecta a:
• Personal efectivo del área de sistemas;

• Personal efectivo de otras áreas;
• Personal de mantenimiento;
• Externos (soporte de hardware, contratistas, etc);
• Pasantes;
• Consultores;
• Clientes.
4.3.2.2 Normas y Procedimientos
Una Norma es toda definición concreta sobre cada uno de los temas de seguridad que
luego serán adaptados a cada servicio informático en forma específica.
Un Procedimiento es toda especificación de las pautas a seguir para el desarrollo de

una tarea en particular. Incluye el desarrollo de instrucciones operativas y
procedimientos apropiados de respuesta a incidencias y recuperación de las
prestaciones frente a una catástrofe.
Ambos son independientes de la plataforma, y lo suficientemente genéricos como

para poder ser aplicados en distintos entornos.
Las Normas y Procedimientos deberán contener:
• Definición de la seguridad de la información, sus objetivos y alcance generales;

• Declaración del propósito de los responsables del nivel gerencial, apoyando los
objetivos y principios de la seguridad de la información;
• Explicación* de las Políticas, principios, Normas y requisitos de cumplimiento en
materia de seguridad, que son especialmente importantes para la organización;
149
• Definición de los responsables en materia de gestión de la seguridad de la

información:
o por nivel jerárquico;
o por área o sector del negocio;
• Definición de los responsables sobre los activos afectados:
o Hardware;
o CPUs;
o Software;
o Servicios;
o Datos;
o Backups;
• Definición del procedimiento a seguir ante la ocurrencia de incidencias relativos a
la seguridad;
• Referencias a documentos que puedan respaldar la política, por ejemplo:
o Estándares de Seguridad más detallados para sistemas de información
específicos o normas de seguridad que deben cumplir los usuarios;
o Instructivos que definen la forma de proceder ante la sucesión de ciertos
eventos, la administración de las contraseñas, el uso de los recursos
específicos y el manejo de los datos;
o Normativas internacionales.
*se especifica el modo de extender la seguridad al ámbito técnico.
4.3.2.2.2 Espectro de las Normas y los Procedimientos
En un entorno informatizado se pueden generar Normas y Procedimientos en los

distintos aspectos de la seguridad, haciendo foco en los niveles físico, lógico y de la
organización.
Un Marco Normativo completo (y útil) está compuesto por Políticas, Normas y sus
respectivos Procedimientos, Instructivos y Estándares.
En general, se puede elaborar la normativa abarcando los siguientes tópicos, siempre

dependiendo del negocio y de la estructura de la organización objetivo:
A nivel físico
150
• Comunicaciones;
• Correo electrónico;
• uso de Internet;
• Uso de antivirus;
• Seguridad física;
• Seguridad del entorno, centros de cómputos (CPDs), oficinas, escritorios, etc.
• Backup;
• Separación física de ambientes de procesamiento: controles y documentación;
• Destrucción de Información;
• Destrucción de la información contenida en distintos soportes magnéticos,
borrado seguro y eliminación de medios impresos.
• Utilización de equipos;
• Utilización de celulares;
• Recuperación del Entorno ante Desastres;
• Administración de la Seguridad de Acceso;
• Reinicio de sistemas;
Para procesos críticos, de tiempo real o que poseen un lato nivel de
disponibilidad, los cuales deben ser reiniciados bajo condiciones específicas y
siguiendo procedimientos especiales.
• Eliminación segura de salidas de tareas fallidas;
Se establecen las pautas para terminar procesos o tareas de las que dependen
otras, o de las que se esperaba un resultado.
A nivel lógico
• Clasificación y manejo de la información;

• Modo de procesamiento de los datos;
• Acceso a datos;
• Administración de usuarios;
• Administración de contraseñas;
• Procedimiento de solicitud de permisos de usuarios;
• Desarrollo de software;
• Requerimientos de programación (schedulling), incluyendo dependencias con
otros sistemas, tiempos de inicio de primeras tareas y tiempos de terminación de
últimas tareas;
• Separación lógica de ambientes: requerimiento de metodologías de desarrollo de
software, ciclo de vida;
• ABM Aplicaciones;
• Uso de Software;
151
• Normas para el manejo de salidas (outputs), como el uso de papelería especial o

la administración de salidas confidenciales;
• Continuidad del procesamiento - Recuperación del Entorno ante Desastres;
• Administración de registros de eventos de auditoría (logs);
• Conexiones a la LAN;
• Conexiones de Terceros;
• Accesos Remotos;
• Concientización y Capacitación;
• Normas para usuarios;
• Criptografía;
• Seguridad en Bases de Datos;
• Administración de la Seguridad de las Aplicaciones;
• Administración de la Seguridad de la Red;
• Intercambio de archivos a través de la red;
• Acuerdo de Confidencialidad.
A nivel de la organización
• Responsabilidades de Seguridad;
• Licencias legales de Software;
• Auditoria de Sistemas;
• Administración y respuesta ante Incidencias;
• Denominación de responsables sobre los activos de la empresa;
• Identificación y registro de cambios en el sistema (ver 5.3 Control de Cambios);
• Procedimiento de aprobación formal de los cambios propuestos;
• Comunicaciones a usuarios;
• Puestas Operativas: Reglas para la transferencia de software desde el ambiente
de desarrollo hacia el ambiente de prueba y al de producción;
• Procedimiento de ABM de usuarios.
4.3.2.2.3 Ejemplo – Normas y Procedimientos
Norma de Responsabilidades de Seguridad
En un entorno informatizado donde se pretende implementar Normas y

Procedimientos de a cuerdo a la Política de Seguridad vigente, es necesario definir el
152
equipo de recursos humanos responsable de hacer cumplir esto, de efectuar

controles y capacitar a los usuarios en cuanto al uso y aplicación de esta normativa.
Los roles dentro de esta organización deberán ser algunos de los siguientes:
• Dueño de los Datos;

• Oficial de seguridad;
• Administrador de seguridad, que puede estar dividido en:
o Administrador de Seguridad de Base;
o Administrador de Seguridad de Aplicaciones;
• Operador Responsable;
• Auditor de Sistemas;
• Usuarios;
Norma de Administración de Usuarios
Una norma muy importante que jamás debe faltar en ningún entorno informatizado
es la que regula la administración de usuarios.
Esta norma es un marco para la creación de nuevos usuarios, para la administración

de perfiles y la asignación y modificación de permisos y la baja de usuarios para
establecer un adecuado control de acceso y así garantizar la autorización y
confidencialidad de los datos.
Establece, entre otras cosas, la administración de:
• Usuarios de gestión, aplicación y de servicios;

• Proceso de autenticación por identificación de usuario y contraseña;
• Características de las contraseñas:
o Cantidad mínima de caracteres;
o Cantidad mínima de caracteres distintos de la última contraseña;
o Cantidad máxima de caracteres repetidos;
o Cantidad mínima de caracteres alfabéticos;
o Cantidad mínima de caracteres numéricos;
o Cantidad mínima de caracteres especiales;
o Vida mínima de la contraseña;
o Vida máxima de la contraseña (expiración);
o Cantidad de contraseñas (o tiempo) que se deben utilizar antes de repetir una
contraseña;
153
o Cantidad de intentos fallidos de logueo antes de bloquearse la estación de

trabajo;
o Cantidad máxima de días de inactividad para el bloqueo del usuario;
o Cantidad máxima de días de inactividad para la baja definitiva del usuario;
• Medidas de restricción complementarias.
Procedimiento de ABM de Usuarios
• Requerimientos para dar de alta a una cuenta personal de usuario;

• Requerimientos para dar de alta a una cuenta no personal (para aplicaciones y
servicios – no se les permite tener logueo);
• Procedimientos para la modificación de permisos de un usuario;
• Procedimientos para la eliminación normal (por renuncia) de un usuario
o Eliminación de la entrada correspondiente en el archivo de contraseñas;
o Eliminación de la cuota de recursos en la Workstation utilizada;
o Restricción de todos los permisos previamente otorgados en los sistemas
operativos, en las bases de datos y en las aplicaciones;
• Procedimientos para la eliminación conflictiva (por despido) de un usuario.
Norma para Licencias legales de software
• Licencias a nombre de la compañía;

• Responsabilidades en la instalación de software;
Norma de Comunicaciones/Correo electrónico y uso de Internet/ Antivirus
• Normas de buen uso;

• Utilización de herramientas exclusivamente para el desempeño de las funciones
laborales;
• Restricciones;
• Responsabilidad del usuario sobre la información transmitida.
Norma de Backup
• Protección de los medios físicos;

• Recupero de la información;
Procedimiento de Backups
154
• Especificación de la rotación de los medios físicos e inventario (uso del documento

de administración de backup);
• Operatoria y periodicidad;
• Autorización para recuperación.
Norma de Ambientes de procesamiento
• Separación de los ambientes de Desarrollo, Control de Calidad (QA),

Preproducción y Producción;
• Segregación funcional entre ambientes;
• Evaluación de los controles y la seguridad.
Norma de Seguridad física
• Características mínimas de la estructura física;

• Características ambientales;
• Protección de la información guardada en soportes y equipos;
• Protección de los escritorios;
• Acceso restringido al CPD o Centro de Cómputos:
o Verificación de las condiciones físicas del CPD;
o Registro de los incidencias ocurridos;
• Acceso al CPD por visitas:
o Acompañados siempre de personal autorizado;
o Realización de sus tareas bajo supervisión;
o Registro de los motivos de la visita;
• Traslado de equipamiento fuera del CPD para mantenimiento:
o Borrado de la información del equipamiento;
o Solicitud de autorización a los Responsables de Datos involucrados ante la
imposibilidad de borrar la información.
Procedimiento de destrucción de Información
• Utilización de máquinas trituradoras de papeles;

• Destrucción definitiva de medios magnéticos desechados (diskettes, CDs, etc);
• Borrado seguro de discos rígidos.
155
4.3.2.3 Estándares, Esquemas y Manuales de usuarios
Los Estándares de Seguridad son documentos más detallados para sistemas de

información particulares o equipos, que deban llevar a cabo los usuarios para el
desarrollo de tareas específicas, cuyo seguimiento depende de la plataforma. Definen
la parametrización de una aplicación, sistema operativo o equipo. Su uso otorga el
beneficio de la homogenización del ambiente, y facilita la automatización de tareas
de instalación y configuración.
Por ejemplo, se desarrolla un Estándar de Seguridad para la elaboración de scripts

que corran sobre bases de datos Oracle.
Los Esquemas técnicos y Manuales de Usuario son documentos que especifican la

forma de llevar a cabo una tarea, la forma de implantación de controles y procesos
según la Política de Seguridad, Norma o Procedimiento en que se basan, a un nivel
más bajo de detalle.
Los Esquemas, Instructivos y Manuales de usuario dependen de la plataforma, y en

general están formados por una serie de pasos o instrucciones.
4.3.2.4 Implantación y uso de la Normativa de Seguridad
Para implantar el conjunto normativo de Seguridad Informática se debe definir un

plan de acción que contemple:
• Clasificación de la información;
• Definición de los dueños de la información;
• Definición de los Responsables de Datos, Seguridad y Administradores;
• Publicación de la Política, Normas, Procedimientos, Estándares, Esquemas y
Manuales de usuario;
• Capacitación de los usuarios finales e informáticos en el tema;
• Adaptación de sistemas operativos, servicios y aplicaciones;
• Creación y actualización de inventarios, registros e informes (ver 4.2 Clasificación
de la información);
• Acondicionamiento físico del Centro de cómputos y sitios donde se encuentren los
equipamientos;
• Revisión del plan de copias de respaldo, medios físicos y lugar en los que se
conservan los mismos;
156
• Creación y/o adaptación de los distintos ambientes de procesamiento.
4.3.2.5 Convenio de Confidencialidad
Para las empresas que manejen información particularmente sensible para su

negocio, se sugiere elaborar un documento que especifique las responsabilidades de
los usuarios respecto del manejo y la publicación de la información de la
organización.
Este documento deberá detallar qué información es secreta y confidencial, el trato

que se le debe dar, los requerimientos de control de acceso y las medidas a tomar si
no se cumpliera con ellas.
Los usuarios involucrados deberán firmar este convenio cuando ingresan a la

compañía, tanto los miembros de la nómina como los externos.
Luego de la elaboración de la Política de Seguridad, ésta debe ser validada con los
responsables de referencia y aprobada por el nivel gerencial de la compañía.
La aprobación de los superiores de la empresa implica la autoridad para hacer

cumplir lo dispuesto en el Manual de Seguridad, tanto en la Política como en las
Normas Y Procedimientos.
Como ya se explicó anteriormente, el Manual de Seguridad está formado por la

Política General de Seguridad con los lineamientos generales, las Normas con
lineamientos más específicos pero siempre a un nivel macroscópico, procedimientos a
nivel de tarea y Manuales técnicos, Estándares e instructivos que despliegan los
procedimientos en detalle.
De todos estos elementos es necesario realizar las correspondientes validaciones y

consensos con los responsables que poseen en conocimiento de la tarea.
La Política General debe ser aprobada, como bien antes se ha dicho, por el nivel
gerencial de la organización.
Las normas deben ser validadas por los responsables de las áreas afectadas, pero no
necesitan la aprobación gerencial ya que éstas se ajustan a los principios enunciados
en la Política General, y conforman el instrumento por el cual se implementan tales
lineamientos.
157
Los demás documentos normativos técnicos, como Procedimientos, Estándares,

Manuales de Usuario e Instructivos no necesitan validación salvo la técnica por parte
de personal especializado.
Toda la documentación que conforma el Manual de Seguridad constituye una única

pieza normativa que debe ser consistente de arriba a abajo y debe cubrir todos los
aspectos donde intervenga información computarizada del entorno en estudio.
Luego de la aprobación correspondiente, se debe dar a conocer el Manual de

Seguridad de la organización.
En esta etapa se deben firmar los convenios de confidencialidad existentes y la

confirmación de lectura y conocimiento de las Normas por parte de los usuarios, si
así se haya dispuesto.
Es recomendable que esta etapa dispare el comienzo de la fase de concientización y

capacitación de usuarios como se sugiere en esta metodología.
4.4.1 Implantación de una campaña de concientización
Para lograr el conocimiento del Manual de seguridad y su correcta interpretación se

debe realizar una campaña de concientización para que los usuarios adquieran los
conceptos de Seguridad que se defienden a través de la normativa, y comprendan la
importancia de de su implantación.
La protección de la información debe convertirse en un factor cultural dentro de la

empresa. Los usuarios deben incorporar los conceptos a su desenvolvimiento diario
para realizar su trabajo cumpliendo con prácticas seguras de manera casi implícita.
Para ello la campaña de concientización debe remachar en conceptos como la

confidencialidad, la legalidad, la autorización, la información de incidencias, etc.
Para lanzar una campaña de concientización se puede recurrir a herramientas de

marketing, como publicación de afiches, reparto de pines, elementos de escritorio y
librería, mensajería masiva, publicación de noticias, foros de discusión, cursos y
seminarios, charlas informales y cafés inductivos que promuevan conceptos e
158
incentiven a la incorporación de prácticas que lleven a la implantación de la

seguridad.
4.4.2 Capacitación de los usuarios
Además de la concientización, se debe realizar una adecuada capacitación de los

usuarios que garantice que poseen los conocimientos mínimos para el manejo de la
información y la implantación de las medidas impuestas en las Normas de Seguridad
vigentes.
Es responsabilidad de la empresa y no de los usuarios en particular la capacitación

técnica y administrativa correspondiente.
El Manual de Seguridad de la organización, compuesto de la Política de Seguridad, las

Normas y Procedimientos, Estándares técnicos e Instructivos deben ser conocidos
por todos los miembros de la empresa estén involucrados directamente con alguna
de las responsabilidades de Seguridad o no.
En particular, las personas que tienen asignados roles específicos de Seguridad, o

que intervengan en el manejo de la información deberán informarse de sus
responsabilidades y derechos de la forma determinada en la Política, ya sea firmando
un convenio de confidencialidad o firmando la lectura y aceptación del marco
Normativo de la Organización.
En los casos en que sea preciso una capacitación formal, como en los aspectos
técnicos, se debe garantizar la adquisición de los conocimientos necesarios para
poder implementar las Normas correspondientes, proveyendo a los usuarios de los
medios educativos adecuados (cursos, manuales, bibliografía, etc)
En esta etapa se implantarán todas las medidas planificadas especialmente para el

entorno objetivo, y específicamente en cada nivel estudiado: físico, lógico y de la
organización.
Cada tarea desarrollada en esta etapa implica un período de pruebas o revisión de los
controles efectuados. Así, por ejemplo luego de efectuar una restricción de permisos
de usuarios se debe realizar una revisión sobre los accesos para verificar su correcta
asignación, y una prueba de acceso a los recursos para detectar excesos de
autorización o restricciones que no permitan desarrollar el trabajo normal del usuario
afectado.
159
Dado que un proyecto de esta clase puede tener una magnitud considerable en un
entorno amplio, se sugiere realizar las revisiones y pruebas necesarias luego de
finalizada cada subetapa, correspondiente a los niveles antes mencionados.
4.5.1 Implantación a nivel físico
En el capítulo 3 se estudiaron las soluciones posibles para los problemas de seguridad

de los activos de nivel físico, lógico y de la organización.
La metodología aquí propuesta invita a llevar a la práctica los controles seleccionados

para obtener el nivel de seguridad deseado en el aspecto físico.
En esta parte se implanta la solución correspondiente sobre los activos físicos:
Protección de las Instalaciones

Se hacen efectivas las medidas planificadas sobre las instalaciones físicas del
entorno.
Protección de los equipos

Se implantan los procedimientos de protección sobre los equipos informáticos.
Revisiones y pruebas
Luego de realizar los cambios o controles, se realizan las revisiones y pruebas
pertinentes sobre equipos de procesamiento, equipos de comunicación, dispositivos
electrónicos, unidades de cinta, etc.
4.5.2 Implantación a nivel lógico
Aquí se implantan los controles sobre los activos lógicos de la organización:
Protección de la información
En esta parte se procede a proteger la información del entorno como activo
fundamental del negocio.
Protección del sistema operativo

Se implantan medidas de protección en el software de base del sistema.
160
Protección de los datos

Se establecen las medidas preventivas al menor nivel de granularidad de los activos
lógicos: los datos.
Una vez realizados los cambios o controles, se realizan las revisiones y pruebas sobre
las aplicaciones, el software de base como sistemas operativos y bases de datos y los
datos.
4.5.3 Implantación a nivel de la organización
Aquí se implantan los controles en la organización, en la estructura de la empresa, en

las tareas y procesos, en los roles y responsabilidades asignadas.
Protección de la organización
Se realiza la implantación de medidas correctivas y preventivas sobre la estructura
de la organización, sobre los roles y responsabilidades de los individuos involucrados
con el entorno, el comportamiento de los empleados en la oficina, etc.
Siempre luego de realizar los cambios o controles, se realizan las revisiones y
pruebas para asegurar un control interno adecuado, y que no surgieron incoherencias
generadas por las medidas aplicadas.

(PRED)
El Plan de Recuperación del Entorno ante Desastres, en adelante PRED, tiene

como objetivo detectar los riesgos presentes en el entorno, analizar su
probabilidad de ocurrencia, establecer su criticidad según cómo afectan la
continuidad del negocio, y finalmente proponer un plan que logre mitigar en cierta
medida estos riesgos, y que permita la recuperación de la disponibilidad de los
recursos lógicos, físicos y humanos para mantener la continuidad del proceso del
negocio.
Muchas veces desastres naturales o accidentes, como incendios, inundaciones,

hasta cortes en el suministro de energía eléctrica provocan pérdidas enormes no
sólo a nivel de bienes, sino pérdidas provocadas por la interrupción del negocio.
161
Hoy en día el negocio es más y más dependiente de la informática, ya que la

mayoría de las empresas tiene sus sistemas productivos y financieros
automatizados y computarizados.
De esta forma es crucial contar con un plan para sostener el flujo de los negocios
ante emergencias que imposibiliten el uso de los recursos de computación o del
entorno completo.
En esta tesis se utilizarán indistintamente los términos “emergencia”,

“contingencia” y “desastre”. Por lo tanto, el hecho de utilizar la palabra
“contingencia” no indica menor gravedad que las situaciones en las que se
referencia al hecho acontecido como un “desastre”.
El PRED contiene las siguientes partes:
• Establecimiento del escenario considerado;

• Determinación de los tipos de operación en una contingencia;
• Establecimiento de criticidades:
o Criticidades por equipo;
o Criticidades por servicios;
o Criticidades por aplicaciones;
• Determinación de las prestaciones mínimas;
• Análisis de riesgos:
o Probabilidad de ocurrencia de desastres;
o Determinación de los niveles de desastre;
• Presentación de las distintas estrategias posibles de recuperación;
• Selección de la estrategia de recuperación;
• Elaboración de la estrategia de recuperación:
o Mitigación de riesgos – Medidas preventivas;
o Descripción de la estrategia;
o Requerimientos para llevar a cabo el Plan;
o Esquemas técnicos con pasos a seguir;
• Formación del Equipo de Recuperación del Entorno ante Desastres (ERED):
o Roles y responsabilidades;
o Asignación de roles;
• Establecimiento de los procedimientos:
o Declaración de la emergencia;
o Recuperación de las prestaciones;
162
o Reestablecimiento de las condiciones normales.
A continuación se detallará cada una de las partes que componen el PRED.
4.6.1 Determinación del escenario considerado
Se deberá hacer un relevamiento de:

• Las condiciones físicas del entorno;
• Los servicios y aplicaciones existentes;
• Los equipos presentes;
o Los servidores;
o Los elementos de backup;
o Los elementos de almacenamiento de datos;
o Los elementos de comunicaciones.
4.6.2 Determinación de los tipos de operación en una contingencia
Los principales tipos de operaciones considerados ante una situación de

contingencia son:
• Operación normal inicial: es la operatoria que se registraba antes de ocurrir el

desastre. Asimismo, define las condiciones que se deben alcanzar como objetivo
final mediante la ejecución del Plan De Recuperación Del Entorno Ante Desastres;
• Operación alternativa: mientras se trabaja en la recuperación de las

prestaciones afectadas por la contingencia, los usuarios deberán utilizar una
operatoria alternativa, constituida fundamentalmente por procesos manuales,
durante la cual se genera información. A partir del momento en que los servicios
y aplicaciones están disponibles, existe un tiempo de “catch up” o actualización
de la información del sistema, en el cual se ingresan las novedades ocurridas
desde la ocurrencia de la emergencia;
• Operación normal en desastre: mediante la ejecución de los procedimientos

que reciben el nombre de “Recuperación de las prestaciones”, se llega a esta
instancia en la cual todos los servicios y aplicaciones han sido recuperados, pero
no se encuentran ejecutando en su lugar original o bajo las mismas condiciones
en que se encontraba originalmente.
Al finalizar el proceso de actualización de la información o “catch up”, se

considera que se ha llegado a la operación normal en desastre. El tiempo desde la
declaración de la emergencia hasta que se alcanza la operación normal en
desastre no debe ser superior a los tiempos máximos tolerables de suspensión
definido para cada una de las prestaciones.
163
• Operación normal reestablecida: mediante la ejecución de los procedimientos

que reciben el nombre de “Reestablecimiento de las condiciones normales” se
alcanza esta última instancia, en la cual todos los servicios y aplicaciones se
encuentran ejecutando correctamente y bajo las mismas condiciones que
presentaba antes de la contingencia.
Para alcanzar este tipo de operación, es posible que haya que considerar una
suspensión programada de alcance total o parcial de las prestaciones, para lo cual
es necesario acotar el tiempo de interrupción al mínimo indispensable, y que
preferentemente sea imperceptible por los usuarios.
Bajo este esquema y considerando a modo de ejemplo una contingencia producida

por una falla técnica en el disco local de un servidor de archivos, los eventos que
definen cada una de las operaciones son:
• Operación normal: es la operación del servidor utilizando su disco local;
• Operación alternativa: los usuarios almacenan los nuevos archivos en el disco

local hasta tanto se habilite un lugar de almacenamiento central. En el momento
en que se recupere las prestaciones del servidor de archivos, como parte del
proceso de actualización de la información o “catch up”, los archivos distribuidos
se copian en el sitio habilitado;
• Operación normal en desastre: se considera desde el momento en que la

información del disco local del servidor se encuentra copiada en un disco de la
cabina, la unidad ha sido montada en el servidor y todos los archivos generados
durante la operatoria alternativa ha sido copiado en el sitio central.
Adicionalmente, a partir de la declaración de la emergencia, se debe realizar el
reclamo al servicio técnico del proveedor del servidor, para que repare o
reemplace el disco que ha fallado;
• Operación normal reestablecida: se alcanza esta operatoria en el momento en

que el servidor nuevamente utiliza su disco local;
4.6.3 Establecimiento de criticidades
En función del impacto producido por la suspensión de las prestaciones del entorno
informatizado, se determina la criticidad y el tiempo máximo de tolerancia de corte
de las mismas.
A continuación se presenta el análisis realizado desde la perspectiva de los equipos y

desde el punto de vista de servicios y aplicaciones.
Los documentos que registran las criticidades los organizamos en tablas llamadas:
Tabla de Criticidades por Equipo, Tabla de Criticidades por Servicios y Tabla de
Criticidades por Aplicaciones.
164
4.6.3.1 Tabla de Criticidades por Equipo.
Sistema Tolerancia
Operativo Máxima
# Equipo Función Impacto
4.6.3.2 Ejemplo - Tabla de Criticidades por Equipo.
Sistema Tolerancia
Operativo Máxima
# Equipo Función Impacto
1 DBBA Bases de Perdida de

datos imagen pública
Solares 9 1 día
Reprocesamiento
de formularios
cargados
manualmente
2 DBCH Bases de Pérdida /

datos inconsistencia de
Solares 9 1 semana información
3 DBCH2 Bases de Pérdida /

datos inconsistencia de
Solares 9 2 semanas información
4.6.3.3 Tabla de Criticidades por Servicios.
# Período Procedim. Parada

crítico
Servicio Criticidad Alternat. Máxima Plataf. Usuarios
165
4.6.3.4 Ejemplo - Tabla de Criticidades por Servicios.
# Período Procedim. Parada

crítico
Servicio Criticidad Alternat. Máxima Plataf. Usuarios
1 Servidor de Media Cierre a fin Guardar los 1 semana Novell Todos

Archivos de mes archivos en Netware
las PC 5.0
locales
2 Correo Alta Todos los Toma de 1-2 días Windows Compras,

electrónico días pedidos 2000 ventas,
Lotus telefónicos despacho.
Domino
Server
166
4.6.3.5 Tabla de Criticidades por Aplicaciones
# Aplicación Proveedor Plataforma Descripción Criticidad Período Parada Proced. Interde- Usuarios
Crítico Máxima Alternt pendencias
4.6.3.6 Ejemplo - Tabla de Criticidades por Aplicaciones.
# Aplicación Proveedor Plataforma Descripción Criticidad Período Parada Proced. Interde- Usuarios
Crítico Máxima Alternt pendencias
1 MANTEC Datastream Windows NT Sistema de Media Fin de mes 2 días --- Almacén,
para la mantenimient procesos,
publicación o preventivo Mantenimiento.
de la de maquinas.
aplicación de
la Base de
Datos Oracle.
2 SUMTEC Datastream Windows NT Sistema de Media 1 día Pedidos de Almacén,

para la manejo de respuestos procesos,
publicación repuestos de manuales. Mantenimiento.
de la almacén.
aplicación.ón
de la
aplicación.Ba
se de Datos
Oracle.
167
4.6.4 Determinación de las prestaciones mínimas
Ante una situación de desastre se debe tener en claro cuál debe ser la prestación
mínima que debe recuperarse de manera prioritaria, para preservar la
continuidad del negocio.
Asimismo se debe estimar el tiempo máximo para recuperar esta prestación.
4.6.5 Análisis de riesgos
En esta etapa se analizan los riesgos presentes en el entorno como se ha explicado

en la fase 2 de esta metodología, para determinar qué riesgos se pueden mitigar,
cuáles se pueden transferir y cuáles se deben asumir.
4.6.5.1 Probabilidad de ocurrencia de desastres
Los riesgos considerados para el plan de recuperación ante desastres, son aquellos
que presentan una probabilidad de ocurrencia no despreciable en función de las
características del entorno:
• Ubicación geográfica;
• Características meteorológicas de la región;
• Características generales del edificio;
• Condiciones ambientales;
• Equipamiento alojado;
• Condiciones de acceso;
• Condiciones de las oficinas contiguas.
4.6.5.2 Determinación de los niveles de desastre
En función del impacto producido por una contingencia, se definen 3 grandes tipos
de desastres:
• Total o Mayor: En el caso en que:

o El lugar físico no pueda disponerse por un período máximo tolerado para la
interrupción de las prestaciones mínimas.
168
o El tiempo que demoran las tareas de reestablecimiento de todas o algunas

de las prestaciones sea mayor al período máximo aceptable.
• Parcial: En el caso en que:

o Los equipos han sufrido daños menores que permiten su funcionamiento
parcial o sus prestaciones pueden ser realizadas por otros equipos, y es
necesaria la acción de alguien externo (proveedores, mantenimiento, etc.)
• Menor: En el caso en que:

o Los desperfectos se solucionan mediante la reinstalación y/o reconfiguración
de los equipos, y por lo tanto no es necesaria la acción de alguien externo
para superar la situación de emergencia.
4.6.6 Presentación de las distintas estrategias posibles de recuperación
En esta etapa el ES analiza las distintas alternativas que aporten solución al

problema, teniendo en cuneta todo el análisis anterior.
4.6.7 Selección de la estrategia de recuperación
El ES presenta las distintas alternativas al cliente quién decide por cuál opta.
4.6.8 Elaboración de la estrategia de recuperación
La estrategia de recuperación deberá ofrecer medidas preventivas y de mitigación

de los riesgos existentes, además de la estrategia de recuperación de las
prestaciones.
4.6.8.1 Mitigación de riesgos – Medidas preventivas
La estrategia de recuperación supone la realización de acciones de mitigación de los

riesgos considerados en el análisis correspondiente, las cuales deben considerar las
actuales condiciones de redundancia y tolerancia a fallas existentes, por ejemplo:
• Realizar pruebas periódicas de recuperación de las cintas de backup;
169
• Almacenamiento de cintas de backups adicionales en locaciones externas al

edificio del entorno analizado;
• Generación periódica de backups en medios de recuperación universal (cintas
DAT).
4.6.8.2 Descripción de la estrategia
En esta parte el ES describe detalladamente la estrategia seleccionada por el

cliente, y especifica las medidas a tomar para la eficaz recuperación del entorno,
luego de un desastre.
Cada estrategia dependerá pura y exclusivamente del entorno informatizado en

estudio, y del Alcance del Plan. Muchas empresas suelen implementar el PRED en
varias etapas, comenzando por ejemplo por los servidores de datos, continuando
por las aplicaciones, luego las comunicaciones y el Centro de Cómputos (CC) o
Centro de Procesamiento de Datos (CPD), o Data Center (DC). Otras, en cambio,
deciden hacer un solo plan completo en una fase, que abarque todos sus bienes y
activos físicos y lógicos.
Lógicamente esta es una decisión empresarial, influenciada fuertemente por el

presupuesto de la empresa y los límites de tiempo.
El PRED suele ser requerido por auditorías, por lo que a veces el cliente se ve
presionado por las fechas y se decide dejar ciertos elementos fuera del Alcance.
En general, en la descripción de la estrategia se definirán las medidas a tomar para

la recuperación del entorno, como por ejemplo:
• Creación de un Equipo de Recuperación del Entorno ante Desastres (ERED) con

responsabilidades y conocimientos específicos que actuará ante las situaciones
de contingencia;
• Recuperación de las prestaciones de los elementos afectados por una
contingencia utilizando la redundancia existente;
• Utilización de un CPD alternativo con un servidor de contingencia para la
recuperación de la aplicación más crítica en caso de un desastre mayor;
• Exigencia del cumplimiento de los tiempos de respuesta especificados en los
contratos de soporte con proveedores de hardware.
4.6.8.3 Requerimientos para llevar a cabo el Plan
170
Los requerimientos conforman una guía de las principales características y

condiciones que deben cumplir los elementos sobre los cuales versa el documento,
a fin de ser utilizados en procedimientos de mantenimiento y auditoría.
Los documentos desarrollados establecen las condiciones de:
• Características físicas del Centro de Cómputos alternativo, si la estrategia

requiriera la instalación de un CPD alternativo para la recuperación;
• Características físicas de los equipos de recuperación, si la estrategia implicara
la compra de equipos de contingencia;
• Miembros del Equipo de Recuperación ante Desastres;
4.6.8.4 Esquemas técnicos
Los esquemas definen pasos generales a seguir de manera operativa para la

ejecución de una determinada tarea.
La ejecución de dichos pasos supone el conocimiento técnico de la tarea que se

está realizando y tiene por objetivo brindar un marco integral de rápida referencia.
Algunos de los esquemas a desarrollar son:
• Activación del CPD alternativo;

• Recuperación de equipos;
• Reestablecimiento de servidores;
• Reestablecimiento de bases de datos;
• Reestablecimiento de Aplicativos;
• Ejemplos de notificación de la emergencia.

(ERED)
El ERED tiene como fin determinar y asignar distintas responsabilidades para lograr
una exitosa recuperación del entorno ante una emergencia, según el Plan (PRED)
establecido.
Para ello se establecen ciertas pautas que las personas que lo componen deben
cumplir:
171
4.6.8.5.1 Roles y responsabilidades
El Equipo de Recuperación del Entorno ante Desastres tiene las siguientes

responsabilidades:
• Definir las medidas preventivas necesarias y factibles de aplicar, a fin de

disminuir la probabilidad de ocurrencia de desastres;
• Definir, probar, ajustar y mantener actualizado el Plan de Recuperación del
Entorno ante Desastres;
• Ante un desastre que afecte al Centro de Cómputos debe:
• Recuperar las prestaciones en el menor tiempo posible y dentro de los plazos
máximos establecidos;
• Reestablecer las condiciones normales que se presentaban antes del desastre;
• Analizar las causas del desastre y la forma en que se ha procedido a fin de
emitir un informe y modificar las medidas preventivas y plan de recuperación en
función de las conclusiones.
A su vez, el ERED está compuesto por sub-equipos con distintas obligaciones.
Estos equipos son:
• Equipo de dirección estratégica y coordinación [EDEC]

• Equipo de recuperación de hardware [ERH]
• Equipo de recuperación de software [ERS]
• Equipo de recuperación de comunicaciones [ERC]
• Equipo de comunicaciones a usuarios [ECU]
Gráficamente el Equipo de Recuperación del Entorno ante Desastres se esquematiza

de la siguiente forma:
172
ECU ERC
EDEC
ERS ERH
Equipo de dirección estratégica y coordinación
Las responsabilidades de este equipo son:
• Dirigir y coordinar las actividades del resto de los equipos que conforman el
Equipo de Recuperación del Entorno ante Desastres;
• Realizar las declaraciones de los distintos estados: emergencia, contingencia y
reestablecimiento de las condiciones normales;
• Determinar el nivel de desastre producido por una contingencia: total o mayor,
parcial, menor;
• Elaborar los planes de recuperación de las prestaciones y reestablecimiento de
las condiciones normales;
• Controlar la ejecución de los planes, detectar desvíos y realizar los ajustes de
los planes en función de los inconvenientes, problemas y errores hallados
durante la aplicación de los mismos;
• Interactuar con personal de mantenimiento para la resolución de contingencias
físicas del Centro de Cómputos.
Equipo de recuperación de hardware
• Identificar los elementos de hardware que hayan sido dañados por una
contingencia;
• Coordinar con los proveedores de hardware el cumplimiento de los contratos de
mantenimiento, garantías y niveles de soporte;
• Participar en las instalaciones de sistemas operativos que realicen los
proveedores;
173
• Verificar el correcto funcionamiento de los elementos de hardware que hayan

sido restaurados o reemplazados por los proveedores.
Equipo de recuperación de software
• Identificar los servicios, procesos, bases de datos y aplicaciones que hayan sido
afectados por una contingencia;
• Instalar, configurar y ajustar todo el software que haya sido afectado por una
contingencia.
Equipo de recuperación de comunicaciones
• Identificar los elementos de comunicaciones que hayan sido dañados por la

contingencia;
• Detectar los problemas de conectividad de los equipos del CPD y determinar las
causas;
• Coordinar con el responsable los cambios que haya que realizar en las
comunicaciones que no sean internas del Centro de Cómputos para que los
usuarios puedan seguir utilizando las prestaciones ;
• Verificar el correcto funcionamiento de los elementos de comunicaciones y la
conectividad general para que los usuarios puedan acceder a los recursos del
CPD.
Equipo de comunicaciones a usuarios
• Participar en la generación de las comunicaciones oficiales a usuarios ante

contingencias, recuperación de prestaciones, demoras incurridas que invaliden o
modifiquen lo comunicado anteriormente y el reestablecimiento de las
condiciones normales;
• Realizar las comunicaciones a los usuarios internos.
4.6.8.5.2 Asignación de roles
174
Luego de determinar las características de los quipos de recuperación, el cliente

debe designar recursos humanos para cubrir todos los roles, teniendo en cuenta
que una persona no puede formar parte de más de dos equipos.
4.6.8.6 Establecimiento de los procedimientos
Más allá del alcance del PRED, se deben especificar procedimientos claros que
ayuden a alcanzar el reestablecimiento de las condiciones normales del entorno
informatizado.
Los principales procedimientos a definir son:
4.6.8.6.1 Declaración de la emergencia
• Abarca desde la detección del desastre hasta que el mismo es comunicado a los
afectados;
• Durante el mismo no se procede a recuperar nada, simplemente se evalúa los
daños causados;
• Se encuentra conformado por los siguientes sub-procedimientos:
o Respuesta inicial ante la detección de un siniestro o contingencia;
o Evaluación del nivel de desastre;
o Notificación de la emergencia.
4.6.8.6.2 Recuperación de las prestaciones
• Consta básicamente del diseño y ejecución del plan de recuperación de las

prestaciones, conforme a lo acontecido;
• Contempla la aparición de imprevistos que puedan alterar o modificar el plan
inicialmente armado;
o Definición del plan de recuperación de las prestaciones;
o Ejecución del plan;
o Ajustes al plan.
175
4.6.8.6.3 Reestablecimiento de las condiciones normales
• Consiste en el diseño y ejecución del plan de reestablecimiento de las

condiciones normales de operación, finalizando con el análisis de la situación
ocurrida a fin de ajustar el PRED en función de los errores, demoras e
inconvenientes acontecidos, así como también la posible toma de nuevas
medidas preventivas;
o Definición del plan de reestablecimiento de las condiciones normales;
o Ejecución del plan;
o Evaluación y análisis de la contingencia.
176
5 ESTABILIZACIÓN
Contenido:
5.1 Análisis de resultados

5.2 Ajuste
5.3 Cierre de la implantación
5.4 Capacitación de usuarios
5.4.1 Técnicas para la capacitación de usuarios
177
En el capítulo anterior se describieron las medidas a implantar para asegurar el

entorno, a partir del estudio del mismo y de la elaboración del Plan de
Aseguramiento.
En esta fase se realiza un estudio con el objeto de verificar la obtención de los

resultados esperados de la implantación anterior, y la realización de los ajustes
necesarios para estabilizar el entorno.
Todo cambio genera más cambios, y en particular esta metodología, al abarcar

todos los niveles de estudio del entorno (físico, lógico y organizacional) hace que
todos los ámbitos de la empresa objetivo se vean afectados por el proyecto en
mayor o menor medida.
Es por eso que en esta etapa uno de los objetivos es verificar la evolución del
entorno a partir de los cambios propuestos, y realizar los ajustes necesarios para
corregir errores, adecuar los controles y minimizar las diferencias entre el Plan y la
Implantación de la solución.
5.1 Análisis de resultados.
Dentro del proyecto de Aseguramiento del entorno informatizado, el ES debe

considerar un tiempo para realizar el balance respecto de la efectividad y
adecuación de los cambios implantados en el entorno y evaluar la necesidad de
realizar ajustes.
Todo Plan sufre cambios continuos a través del tiempo, que deben acompañar la
transformación del entorno. Estos cambios deben ser considerados dentro del Plan
de Aseguramiento, en los distintos modelos propuestos para cada etapa.
En particular los modelos que deberán revisarse al menos una vez por año para su
adaptación a los cambios son:
• Informe de Riesgos;
• Mapa de Usuarios;
• Mapa de Red;
• PRED.
Requiriendo los demás modelos presentados en esta Tesis pero no mencionados en

este apartado una contínua adaptación a través de la vida del Entorno.
178
5.2 Ajuste
La etapa de ajuste está dedicada a realizar ajustes sobre el Plan de Aseguramiento
según los resultados obtenidos y analizados en la etapa anterior de esta misma fase
y los inconvenientes o nuevos requerimientos que pudieran surgir en la etapa de
implantación.
Un proyecto como el que aquí se presenta puede tomar gran envergadura y

desarrollarse en un tiempo prolongado durante el cual el entorno sufrirá
modificaciones inherentes a la vida de los sistemas, por lo que puede surgir la
necesidad de ajustes en ciertos aspectos de seguridad.
También, a medida que se implantan los controles para asegurar el entorno, surgen
nuevos requerimientos susceptibles a ser considerados en una segunda etapa de
Aseguramiento.
Se debe considerar siempre en esta disciplina que los avances científicos son muy
rápidos, y se deben considerar las nuevas soluciones tecnológicas ofrecidas en el
mercado, que pueden traducirse, muchas veces, en cambios funcionales y en las
técnicas procedimentales de implantación.
Los puntos de control que necesiten cambios, mejoras o los que surjan durante el
proyecto se tomarán en cuenta para completar y adaptar el Plan de aseguramiento
para una segunda implementación, delimitando nuevamente su Alcance, que podrá
reducirse a aplicar solamente los cambios surgidos en esta etapa para lograr un
completo aseguramiento del entorno.
5.3 Cierre de la implantación.
El cierre de la implantación se debe realizar cuando se concluyeron los últimos

controles que constituyen el Plan de Aseguramiento y concluidas las etapas de
concientización y capacitación de usuarios.
Como todo cierre de proyectos, es recomendable realizar un balance del trabajo y

presentar los resultados al sector responsables de la empresa objetivo.
Un informe ejecutivo es un informe resumido los objetivos fijados al comienzo del

proyecto y los objetivos logrados, de los conceptos manejados y la forma en que se
obtuvieron los resultados.
179
5.4 Capacitación de usuarios.
Se deberá capacitar a los usuarios para la correcta interpretación y su natural

adaptación a los cambios implementados en el entorno, para su inserción en el
sistema y su normal desarrollo de actividades, y por sobre todo para que
comprenda la importancia de los cambios realizados y de su mantenimiento.
Se debe convencer al usuario de la importancia de su colaboración en el esfuerzo

de mantener el entorno seguro.
Asimismo, se le debe informar de las nuevas reglas y/o políticas de la organización,

la forma de trabajar para que su labor no interfiera ni perjudique el esfuerzo
implicado en el proyecto de aseguramiento, los procedimientos a usar para revertir
situaciones o manejar catástrofes, etc.
Se deberá dejar constancia de que el usuario fue informado respecto de las Políticas
de Seguridad, y su completa comprensión, y su conformidad respecto de su
cumplimiento.
5.4.1 Técnicas para la capacitación de usuarios:

• Presentaciones grupales;
• Manuales y folletos;
• Cursos;
• Coaching (un usuario experimentado capacita a un usuario inexperto);
• Mesa de ayuda;
• Teleconferencias;
• Comunicados.
En todos los casos, se recomienda generar confianza de los usuarios en la persona

encargada de la capacitación. Se sugiere encargar esta tarea a un empleado
carismático y emprendedor, predispuesto y que tenga una buena relación
interpersonal con sus pares.
Para todas las técnicas de capacitación aquí presentadas, y las que se escapan a
este trabajo, se sugiere contar con una fuerte documentación que pueda ser
consultada por los usuarios, acompañada por gráficos y todo tipo de material que
colabore al rápido aprendizaje e incorporación de los conceptos de seguridad.
180
5.4.1.1 Temario
A continuación se presenta un temario básico de capacitación general que deberá
ser analizarlo para aplicar en detalle los temas que correspondan según las Políticas
aplicadas en la empresa objetivo:
1. Qué es la información?
Explicar qué se entiende por información, sus diferentes formas, cómo se genera,
dónde y cómo se puede guardar, y su valor para la empresa. Esto último se
relaciona directamente con el nivel de confidencialidad de información que se
maneje en el negocio dependiendo de sus características.
2. Qué es la Seguridad.
Presentar el concepto de Seguridad, sus implicancias y sus consecuencias.
3. Intrusos y amenazas.
Definir los intrusos externos e internos, sus amenazas y formas de presentación.
4. Nivel de Seguridad de la Organización

¿Cuál es el nivel de seguridad de la información de su empresa? ¿Qué tan
vulnerable es el sistema informático?
5. Plan de Aseguramiento del Entorno

Explicación del proyecto de seguridad implementado, composición del Plan de
Aseguramiento, su Alcance, implicancias, resultados esperados, responsabilidades
de los usuarios desprendidas de la aplicación del Plan.
6. Medidas adicionales de protección. Buenas costumbres.

Los virus informáticos son, dentro de la seguridad informática, la fuente de
mayores pérdidas económicas en el mundo entero. Instalar un buen software
antivirus no es suficiente, ya que la variedad y cantidad de puertas de entrada de
virus, troyanos, etc., puede sorprender en cualquier momento a la mejor
herramienta, sin contar con otros inconvenientes como falsas alarmas, HOAX, etc.
Los usuarios deben estar consientes de este peligro y deben conocer su alcance e
implicancias.
Se les debe dar recomendaciones para el uso cotidiano de sus herramientas de

trabajo y la protección de los activos de la organización.
7. Diseño del Manual de Seguridad

La seguridad no depende solamente de la tecnología. Las empresas establecen las
bases fundamentales para custodiar su información a través del desarrollo de
Políticas, Normas y Procedimientos que una vez definidos.
181
Los usuarios deben conocer la diferencia entre los distintos elementos del Manual
de Seguridad como la Política General, las Normas y procedimientos y demás
documentos técnicos, su responsabilidad y las posibles consecuencias sobre el
incumplimiento de las mismas.
8. Soluciones Tecnológicas:
• Firewalls;
• Antivirus;
• Sistemas de Detección de Intrusos;
• Redes Virtuales (VPN);
• Sistemas de Backup;
• Plan de Recuperación del Entorno ante Desastres (PRED).
9. Formación en Seguridad
Evaluar la posibilidad de capacitación en temas específicos de seguridad, tanto
técnicos como funcionales para los distintos roles y niveles jerárquicos de la
empresa.
10. Responsabilidades:
Administradores de Seguridad y nuevas responsabilidades.
El rol de cada usuario.
182
6 MANTENIMIENTO
Contenido:
6.1 Control de incidencias

6.1.1 Incidencias de seguridad
6.1.2 Notificación de incidencias
6.1.3 Documentación
6.1.4 Reporte de Incidencias
6.1.4.1 Manual de Procedimientos sobre Reporte de Incidencias
6.1.5 Respuesta a incidencias
6.1.6 Recolección de incidencias
6.1.7 Registro de incidencias
6.1.8 Investigación
6.1.9 Seguimiento de incidencias
6.1.10 Prevención de incidencias
6.2.1 Procedimiento de Control de Cambios
6.2 2 Diagrama de flujo
6.2.3 Formulario de Control de cambios
6.2.4 ABM Activos
6.2.5 Ejemplo - AMB Activos
6.2.6 Actualizaciones de Software
6.2.6.1 Documento de Actualizaciones de Software
183
Esta es la última fase de la metodología AEI. Comienza posteriormente a la

implantación del Plan de Aseguramiento, luego de la estabilización del entorno y se
mantiene durante toda su vida.
Durante la vida del entorno ocurren incidencias y cambios que deben ser analizados
y documentados, así como también se deben llevar a cabo controles periódicos y
aplicar las correspondientes actualizaciones para mantener un nivel confiable de
seguridad en el entorno.
6.1 Control de incidencias.
El control de incidencias es una técnica que permite controlar y registrar los

eventos ocurridos que atentan contra la seguridad del entorno.
Consiste en llevar un registro y un seguimiento de los eventos anormales que

ocurran en el entorno objetivo en particular, y en la compañía en general.
Se debe definir el alcance de los eventos o incidencias a registrar.
El control de incidencias permite:
• Registrar cambios o pérdida de información;

• Registrar y dar solución a los requerimientos de los usuarios;
• Administrar los usuarios (dar de alta, baja y modificar permisos);
• Registrar nuevas vulnerabilidades manifiestas en el sistema y tomar medidas
preventivas para el futuro;
• Dar informe del incidente a quien corresponda;
• Justificar posibles cambios;
• Crear una fuente de información para capacitar a los usuarios.
Las incidencias pueden ser de muchos tipos. Entre ellos se encuentran los eventos
de mantenimiento, los pedidos de reparación de hardware y servicios de los
usuarios, nuevos requerimientos de los usuarios, errores en los datos e incidencias
de seguridad.
6.1.1 Incidencias de seguridad
184
Los siguientes eventos son considerados incidencias de seguridad, entre otros:
• Violaciones a la confidencialidad de los datos;

• Violaciones a la integridad de los datos;
• Bloqueo de cuentas de usuarios;
• Anomalías en la disponibilidad de recursos;
• Negación del servicios;
• Fallas en los sistemas de información;
• Anomalías en el funcionamiento de los sistemas de software;
• Desaparición de información;
• Aparición de datos no creados por el usuario.
6.1.2 Notificación de incidencias
El usuario que protagonice o presencie un evento que pueda poner en riesgo la

seguridad del entorno deberá informar de lo ocurrido.
El Procedimiento de Manejo de Incidencias del Manual de Seguridad de la empresa

indicará los pasos a seguir o el circuito para el registro de incidencias.
La información fluye en los distintos ámbitos de las empresas. Para nuestro estudio
nos concentraremos en el entorno informatizado que pretendemos asegurar.
El ES debe analizar la forma de establecer un circuito de administración de

incidencias. Para esto deberá pensar en:
• Un ente denunciante que presente el incidente e informa de la ocurrencia y

efectos observados (por lo general son los usuarios);
• Un ente receptor-derivador de incidencias (un concentrador de pedidos como

un Servicio de Atención al Cliente (SAC) o Help Desk) encargado del asiento en
registros apropiados;
• Un ente responsable encargado de la resolución del incidente, entendiéndose

por resolución el manejo de la incidencia, su tratamiento y, si es posible, su
solución (personal técnico especializado, el administrador de la red, etc);
• Un ente informante que entregue el resultado del manejo del incidente al ente
denunciante.
En estructuras medianas y grandes suele dar soporte a este esquema el Servicio de

Atención al Cliente (SAC), o Help Desk.
185
El Help Desk es un ente concentrador y derivador de casos. En este esquema de

Help Desk, un incidente se maneja de la siguiente forma:
1- El ente denunciante (usuario) informa de la ocurrencia de un incidente;
2- El receptor-derivador (Help Desk) registra el incidente;
3- El receptor-derivador (Help Desk) deriva el incidente al ente RESPONSABLE que

corresponda para que lo maneje y le de solución;
4- El ente responsable analiza el incidente;
5- Si se trata de un incidente grave de seguridad lo deriva al Oficial de Seguridad o

figura equivalente (responsable de seguridad de control interno);
5.1- El Oficial de Seguridad analiza el incidente;

5.2- El Oficial de Seguridad toma medidas para prevenir el incidente en el
futuro;
6- El ente responsable toma medidas para prevenir el incidente en el futuro;
7- Si tiene solución el responsable resuelve el caso;
8- El responsable informa al receptor-derivador (Help Desk) las medidas tomadas y

las medidas a tomar por el usuario;
6- El receptor-derivador (Help Desk) informa al denunciante (usuario) del estado de

su caso, con detalle de la solución dada e instrucciones de las acciones a tomar.
A continuación se muestra un diagrama que ilustra el procedimiento:
186
Receptor –Derivador
(Help Desk
Denunciante o Atención Oficial de
(Usuario) al Cliente) Responsable Seguridad
Denuncia Abre caso de

incidente Help Desk
Deriva
Registra el
denuncia de
incidente
incidente
Analiza el
incidente
Incidente Sí
Analiza el
grave de
incidente
seguridad?
No
Toma medidas
para prevenir Toma medidas
el incidente en para prevenir
el futuro el incidente en
el futuro
Tiene Sí
solución?
No
Informa
medidas
preventivas
Cierra caso de
tomadas y
Help Desk
acciones a
tomar por el
usuario
Se notifica del
cierre del caso
Informa cierre
y de las
de caso Resuelve el
medidas a
tomar incidente
Informa
solución del
Cierra caso de incidente y
Help Desk medidas a
tomar por el
usuario
Se notifica del
cierre del caso Informa cierre
y de las de caso
medidas a exitoso
tomar
187
Toda persona que detecte un incidente de seguridad deberá informarlo de

inmediato al ente receptor-derivador.
El área de Recursos Humanos debe intervenir en los casos en que se produzcan

eventos que requieran medidas disciplinarias o correctivas.
El Oficial de Seguridad debe mantener una lista de contactos actualizada sobre las
personas que deberán ser notificadas ante la ocurrencia de incidencias de
seguridad.
6.1.3 Documentación
Se deberá conservar de manera segura un resumen de todas las incidencias y

acciones realizadas.
El acceso y conservación de la información referente a incidencias que han afectado

a información clasificada deberá ser limitado y controlado cuidadosamente a fin de
proteger la confidencialidad de los individuos y minimizar la exposición de la
compañía y las obligaciones relacionadas con la privacidad.
6.1.4 Reporte de Incidencias
Es un informe detallado que elabora el ente receptor-derivador del incidente

inmediatamente de ocurrido éste, en el que debe especificar con el mayor detalle
posible lo ocurrido, y enviárselo al responsable asignado, junto al mail de
notificación.
El Reporte de Incidencias contiene:
• Número de incidente (asignado por el responsable);

• Fecha del incidente;
• Hora del incidente;
• Nombre de la persona que reporta el incidente;
• Sector donde trabaja;
• Ubicación física;
• PC afectada por el incidente;
188
• Activo (software o hardware) afectado con path completo y/o nombre de la

aplicación;
• Nombre del responsable;
• Descripción del incidente;
• Archivos adjuntos (imágenes, logs, etc);
• Acción/reacción del usuario frente al incidente (por ejemplo: “apagué la
máquina”, “cerré la aplicación”, etc).
Todos estos datos deben ser completados con el mayor detalle posible por el
usuario afectado, salvo el campo correspondiente al número de incidente, que
deberá ser completado por el responsable.
Los Reportes de Incidencias deberán ser conservados con fines de análisis y

reportes.
Formato del Reporte de Incidencias
189
REPORTE DE INCIDENCIAS
# INCIDENTE: FECHA: HORA: SECTOR:
UBICACIÓN FÍSICA:
NOMBRE DEL DENUNCIANTE:
_____________________
FIRMA DEL DENUNCIANTE
DESCRIPCIÓN DEL INCIDENTE:
NOMBRE DEL RESPONSABLE:
_____________________
FIRMA DEL RESPONSABLE
ARCHIVOS ADJUNTOS: ACCIÓN TOMADA:
Número de incidente: Número correlativo asignado por el responsable.
190
Fecha del incidente: Fecha en la que se produjo la incidencia.

Hora del incidente: Hora en la que se produjo la incidencia.
Sector: Sector donde ocurrió el incidente.
Ubicación física: Lugar físico donde se produjo el incidente (piso, oficina, etc).
Nombre del denunciante: Nombre de la persona que reporta el incidente.
Descripción del incidente: Activo (software o hardware) afectado por el
incidente.
Nombre del responsable: Nombre completop de la persona responsable del
manejo del incidente.
Archivos adjuntos: imágenes, logs, etc.
Acción tomada: Acción/reacción del usuario ante la incidencia y acción tomada por
el responsable del incidente.
6.1.4.1 Manual de Procedimientos sobre Reporte de Incidencias
El Manual de Procedimientos sobre Reporte de Incidencias es un documento que

deberá confeccionarse para capacitar a los usuarios en el proceso de reporte de
incidencias de seguridad en el entorno.
Este documento debe explicar en forma sencilla y concisa el procedimiento de

reporte de incidencias para se utilizado como guía por los usuarios al momento de
declarar un incidente.
Este Manual, como toda la documentación referente a procedimientos de usuarios y

Normas debe estar al alcance de todos los empleados, y se debe asegurar que los
usuarios tengan conocimiento de la existencia del mismo, su fin y aplicación.
6.1.5 Respuesta a incidencias
El ente responsable encargado de analizar y resolver el incidente debe dar

respuesta al usuario afectado por el evento, intentando dar indicaciones para que
éste comprenda el origen del incidente y tome medidas correctivas cuando sea
posible.
Asimismo, el responsable deberá informar al Oficial de Seguridad cuando ocurran

incidencias graves de seguridad. Es su responsabilidad desarrollar soluciones en
respuesta a las incidencias de seguridad críticos que hayan afectado a los servicios
informáticos o aquellos que tengan efectos globales, tales como ataques de virus
191
informáticos, vulnerabilidades de parches de software o inconvenientes con los

proveedores de servicios.
6.1.6 Recolección de incidencias
Todas las evidencias deberán ser recolectadas en una manera consistente utilizando
técnicas apropiadas que garanticen la autenticidad, integridad, exactitud y
veracidad de las mismas. Las evidencias físicas deben ser conservadas en una
forma segura, tal como guardarlas en una caja fuerte.
Se debe preservar la cadena de custodia de las evidencias recolectadas. El acceso

se debe limitar al mínimo de personas necesarias para responder e investigar
incidencias de seguridad.
Es altamente recomendable mantener y auditar un log del acceso a las evidencias,

incluyendo el nombre, fecha y hora en que se retiró, fecha y hora en que se
devolvió, el propósito del acceso y las acciones tomadas.
Para las evidencias lógicas se ha desarrollado un documento llamado Registro de

Incidencias, que recompila la información obtenida en cada incidente por el Reporte
de Incidencias.
6.1.7 Registro de incidencias
Es un documento donde se centraliza el registro de las incidencias, para fines

estadísticos, educativos y de control.
Es administrado por una persona responsable de la administración de las

incidencias, que suele ser el Oficial de seguridad.
Al recibir un Reporte de Incidencias de un usuario, el responsable en cuestión

agrega una fila en el registro de incidencias correspondiente al reporte recién
recibido y guarda el reporte de Incidencias en una carpeta determinada para tal fin.
Se mantiene un solo documento a fin de simplificar el mantenimiento, pero, en

organizaciones que por su tamaño lo necesiten, se podrá llevar un documento por
sector, cuyos responsables se encargarán de centralizar finalizado el período
especificado en la Política de Seguridad.
192
Formato del Registro de Incidencias
NOMBRE DEL NOMBRE DESCRIPCIÓN /

DENUNCIANTE RESPONSABLE MEDIDA TOMADA
# FECHA SECTOR T E
NÚMERO: Número de Incidente (correlativo);

FECHA: Fecha en que ocurrió el incidente;
SECTOR: Sector que lo reportó;
NOMBRE DEL DENUNCIANTE: Nombre de la persona que lo reportó;
NOMBRE DEL RESPONSABLE: Nombre del responsable del manejo del incidente;
T: Tipo de Incidente: Es recomendable tener una lista con los tipos de incidentes
predeterminados, por ejemplo:
1- Negación de servicios;
2- Pérdida de datos;
3- Afección de hardware;
4- Afección de la integridad de los datos;
5- Afección de la confidencialidad de los datos;
6- Virus Informático;
7-Afección de soportes de información en papel;
8- Afección de soportes de información en medios magnéticos;
9- Daño de activos.
DESCRIPCIÓN/MEDIDA TOMADA: Descripción de la incidencia;
E: Estado:
I- En investigación;
P- Pendiente;
R- Resuelto.
193
6.1.8 Investigación
Todas las áreas de sistemas deberán colaborar en la investigación de las incidencias

de seguridad ocurridas a fin de asegurar que todas las posibles consecuencias del
mismo han sido consideradas.
A fin de incrementar la integridad del proceso de investigación de incidencias,

deberá existir un doble control y segregación de funciones, lo que significa que más
de una persona deberá estar involucrada en el proceso. Esto incluye prevenir el
caso que un individuo potencialmente modifique o las pistas de auditoría de un
sistema o aplicación.
Durante el proceso de investigación se deberá tomar nota de hechos tales como

quién, qué, cómo y cuándo, a fin de tener registro de todas las acciones realizadas
y la información no cubierta y evitar fraudes informáticos.
6.1.9 Seguimiento de incidencias
El Oficial de Seguridad debe garantizar que todas las incidencias de seguridad sean
analizadas en función de la causa de origen, a fin de prevenir la ocurrencia de
incidencias similares en el futuro y de mejorar la metodología de respuesta ante
incidencias en función de lo aprendido durante la resolución de los mismos.
6.1.10 Prevención de incidencias
Se deberá contar con un plan de respuesta ante incidencias con un equipo de

personas responsables, que puede estar considerado dentro del PRED (Plan de
Recuperación del Entorno ante Desastres)
Se deberá documentar los roles y responsabilidades del personal involucrado en el

manejo de incidencias de seguridad.
El Oficial de Seguridad deberá asegurar que las técnicas de prevención incluyan la

utilización de software antivirus, filtrado de contenido, y mecanismos de control de
acceso de los usuarios y recursos que sean razonables y apropiados, mediante la
utilización de firewalls y routers, que son administrados por la organización.
194
En la fase de Mantenimiento, y durante toda la vida del entorno, se recomienda

llevar un estricto control de cambios en el sistema y las instalaciones.
Se deben considerar cambios que afecten cualquier elemento del entorno, como:
• Sistemas operativos de servidores;

• Sistemas operativos de estaciones de trabajo;
• Configuraciones de equipos;
• Sistemas aplicativos en general;
• Aplicaciones de escritorio;
• Motores de base de datos;
• Servicios de correo electrónico;
• Sistemas de protección contra virus informáticos;
• Elementos de comunicaciones (routers, switches, etc,);
• Entre otros.
Este control tiene el fin de:
• Lograr una efectiva autorización de los cambios a implantar;

• Llevar un control de los cambios para evitar pérdidas o deterioros de
información;
• Tener un registro documentado de los cambios;
• Evitar incidencias y fallas en la seguridad.
Los cambios deben pasar por un circuito de autorizaciones desde que nace el
requerimiento hasta que se implanta el cambio.
Desde un punto de vista macroscópico, se podría decir que un cambio pasa por
cuatro estados durante su vida:
1. Inicialmente surge como un requerimiento solicitado por un usuario.

2. Luego del análisis de los responsables, se convierte en un requerimiento
aprobado.
3. El siguiente estado en el desarrollo de la solución.
4. Finalmente, se concreta el cambio en la implantación del cambio.
195
El requerimiento de cambio puede surgir de cualquier área, más comúnmente del

área usuaria.
Una vez que un requerimiento nuevo o cambio es solicitado, deben existir varios
niveles de aprobación.
Inicialmente, el jefe del sector o área de trabajo del usuario solicitante, debe
analizar la coherencia y factibilidad del cambio solicitado, para su aprobación.
A continuación se deberán realizar una serie de análisis para determinar la

influencia del cambio sobre el entorno, teniendo en cuenta los efectos sobre la
tecnología, sobre el software base y aplicativo, sobre la disponibilidad de los
recursos.
Asimismo, se analizará la cantidad de usuarios afectados por el cambio.
Idealmente se recomienda crear un comité de cambios formado por especialistas

en las distintas áreas y disciplinas intervinientes: un administrador de la
infraestructura técnica, un administrador de la base de datos, un analista de
aplicaciones y el Oficial de Seguridad.
Lo siguiente es el desarrollo del cambio, la realización de las pruebas pertinentes

para comprobar que el cambio será se realizará correctamente, para luego
implantarlo en el entorno productivo.
En el momento de su implantación se requiere la autorización del responsable del

entorno vivo, o ambiente productivo, que en general es la persona a cargo del
centro de cómputos.
Estas son las responsabilidades del comité de cambios:
• Planificar, priorizar, autorizar y coordinar las tareas a realizar por los distintos
involucrados ante la necesidad de realización de cambios de sistemas en
producción;
• Definir los criterios sobre los cuales se realiza la evaluación de impacto y
criticidad de los cambios;
• Liderar los procesos de cambio a realizar ante situaciones de emergencia;
• Evaluar periódicamente el registro de los cambios realizados en los sistemas de
producción, a fin de ajustar los criterios de evaluación, planificación y
priorización de tareas.
196
Las siguientes son las responsabilidades de las personas que forman el comité de
cambios:
• Usuario solicitante:
o Detectar mejoras a implantar en el entorno, ya sean cambios de
configuraciones, mejoras de performance, mejoras de operatoria, mejoras
de estética, etc;
• Administrador de la infraestructura técnica:

o Analizar que los cambios a realizar en el entorno no afecten la funcionalidad
del mismo, evaluando no solo el impacto sino también la criticidad;
o Planificar e implantar el cambio, y en caso de ser necesario realizar las
pruebas adecuadas y las acciones necesarias para volver a atrás en caso
que se produzca alguna contingencia durante la implantación en producción;
o Mantener actualizada la documentación de configuración del entorno;
• Administrador de bases de datos:

pruebas adecuadas y las acciones necesarios para volver a atrás en caso
o Mantener actualizada la documentación de configuración de los sistemas;
• Analista de aplicaciones:
pruebas adecuadas y las acciones necesarios para volver a atrás en caso
o Mantener actualizada la documentación de configuración de los sistemas;
• Oficial de Seguridad:
o Evaluar el impacto de los cambios para que no se realicen cambios en
configuraciones que estén en contra de la normativa de seguridad.
6.2.1 Procedimiento de Control de Cambios
A continuación se muestra el procedimiento de control de cambios en una tabla,

donde las filas grisadas corresponden a pasos de cumplimiento obligatorio.
197
Paso Descripción Objetivo Involucrados Resultado
Fase de Análisis
Detecta la necesidad de realizar un cambio en la

configuración de los sistemas con los que esta vinculado Involucrar a las distintas personas
01 en la ejecución de su labor diaria. en la identificación de cambios a Usuario solicitante
Estos cambios pueden ser solicitados por cualquier realizar en los sistemas.
persona que trabaja en la compañía.
Comunica la necesidad de realizar un cambio en la

configuración de los sistemas.
Los datos mínimos necesarios que se deben completar

para realizar el requerimiento son:
Tipo de cambio a realizar.
Documentación detallada
Sistema donde se aplica el cambio. Fomentar el análisis por parte del
del requerimiento de
02 solicitante de los requerimientos Usuario solicitante
Si se necesita o un la realización de una evaluación cambio en el Formulario
que realiza.
detallada. de Control de cambios
Si afecta la funcionalidad de otros sistemas.

Fecha límite aceptable para la implantación de la
solicitud.
Nombres y apellidos del solicitante.
198
Comité de cambios
(coordinación)
Reciben la solicitud de cambio de configuración. Registro de la solicitud en
Administrador de la el Formulario de Control
Analizan todos los elementos del entorno que podrían infraestructura técnica
Identificar la necesidad real del de Cambios
verse afectados por el cambio solicitado. (responsable)
cambio y las implicancias en el Documentación técnica
03 Una vez comprendidos todos los factores afectados por resto de los sistemas de la Administrador de base de datos del cambio a realizar junto
el cambio, se realiza una evaluación del posible impacto Compañía. (responsable) con todos los sistemas
y la criticidad que tendrá el cambio solicitado.
Analista de aplicaciones afectados y el evaluación
(responsable) del impacto
Oficial de Seguridad (implicado)
Comité de cambios
En función al análisis realizado se determinada si el (coordinación)
cambio podrá ser aplicado o no.
Administrador de la
Algunos de los motivos por los cuales no se aplicará infraestructura técnica
un cambio solicitado son: (responsable)
- No recomendado por el proveedor. Documentación con las
04 - Costos no aceptados. Administrador de base de conclusiones del
- Alto impacto y muy pocos beneficios. datos (responsable) análisis realizado
Analista de aplicaciones
En caso que el cambio no se vaya a implantar, se (responsable)
continúa en el paso # 20.
Oficial De Seguridad
(implicado)
Comité de cambios
(coordinación)
Identifican todas las actividades necesarias para realizar
el cambio, entre las que se encuentran: Administrador de la
infraestructura técnica
Identificación exacta de los cambios a realizar. Determinar las tareas a realizar Plan de implantación del
05 (responsable)
Identificación de los sectores involucrados en el cambio. para realizar el requerimiento cambio
Administrador de base de datos
Identificación del momento más adecuado para realizar (responsable)
el cambio.
(responsable)
199
Comité de cambios
(coordinación)
Luego de la planificación de las actividades a realizar
Administrador de la
para implantar los cambios, se determina la necesidad
de realizar pruebas previas en entornos no productivos
06 (responsable)
antes de realizarlos en producción.
En caso de no ser necesarias las pruebas se continúa en
(responsable)
el paso # 11.
(responsable)
Fase de Pruebas
Administrador de la
Definen las pruebas unitarias e integrales que se deben infraestructura técnica
realizar para garantizar que los cambios realizados sean (responsable) Documentación con el
Prever adecuadamente las
los adecuados y no generen inconvenientes a los detalle de las pruebas a
07 actividades a realizar durante la Administrador de base de datos
sistemas vigentes. realizar junto su
ejecución de las pruebas (responsable)
planificación
Planifican la realización de las pruebas identificadas. Analista de aplicaciones
(responsable)
Administrador de la
(responsable)
Ejecutan las pruebas según la planificación realizada
Identificar los problemas que Documentación con el
08 oportunamente, identificando los problemas que se Administrador de base de datos
pueden ocasionar los cambios. resultado de las pruebas
suscitan y las posibles causas. (responsable)
(responsable)
Administrador de la
(responsable)
Si las pruebas no han sido satisfactorias, continúan en
09 Administrador de base de datos
el paso # 20.
(responsable)
(responsable)
200
Comité de cambios
(coordinación)
Otorgan la aceptación formal a la realización de los Administrador de la
cambios planificados en el entorno de producción. infraestructura técnica Documentación formal de
Infundir la toma de
(responsable) la aceptación de la
10 responsabilidad en las decisiones
implantación del cambio
tomadas. Administrador de base de datos
En caso de ser necesario modifican las especificaciones en producción
realizadas en la etapa de planificación. (responsable)
(responsable)
Fase de Implantación
Comité de cambios
Identifican todas las actividades necesarias para realizar (coordinación)
el cambio y todas las precauciones a considerar antes
de realizarlo a fin de poder volver atrás sin mayores Administrador de la
inconvenientes. infraestructura técnica
Coordinar las tareas entre todas (responsable) Plan de implantación del
11
las áreas. cambio
Adicionalmente se planificará con todos los (responsable)
Administradores y Analistas involucrados el momento
más adecuado de implantación. Analista de aplicaciones
(responsable)
Administrador de la
infraestructura técnica Documentación de las
Ejecutan todas las tareas identificadas en la Concientizar a los administradores (responsable) configuraciones anteriores
planificación para realizar la vuelta atrás en las de la necesidad de contar con un del entorno y
modificaciones de configuración en caso de existir algún plan de recuperación ante una documentación de las
(responsable)
inconveniente. contingencia. acciones para volver al
Analista de aplicaciones estado inicial.
(responsable)
201
Administrador de la
(responsable)
Si las tareas previas a la implantación del cambio en
13 producción no se han podido realizar, no se realizará el Administrador de base de datos
cambio y se continúa en el paso # 20. (responsable)
(responsable)
Administrador de la
(responsable)
Ejecutan las tareas acordadas en la planificación,
Implantar los cambios en Configuración implantada
14 realizando previamente la notificación a los usuarios Administrador de base de datos
producción. en producción
afectados en caso de ser necesario. (responsable)
(responsable)
Administrador de la
(responsable)
Si los cambios de configuración de los sistemas en
15 producción han sido satisfactorios se continúa en el Administrador de base de datos
paso # 17. (responsable)
(responsable)
Administrador de la
(responsable)
Ejecutan todas las tareas planificadas para la vuelta a la Documentación de las
Conservar el entorno productivo
16 configuración inicial de los sistemas, y continúan en el Administrador de base de datos acciones de vuelta atrás
en caso de contingencia.
paso # 20. (responsable) realizadas
(responsable)
202
Comité de cambios
(coordinación)
Administrador de la
Asegurarse de que los sistemas infraestructura técnica Documentación formal de
Aceptan formalmente la implantación del cambio de (responsable)
17 continúan funcionando la aceptación de la
configuración realizado.
correctamente Administrador de base de datos solución realizada
(responsable)
(responsable)
Administrador de la
(responsable) Documentación
Identifican y actualizan toda la documentación de los Mantener vigente la actualizada de las
sistemas involucrados en el cambio de configuración. documentación. configuración de los
(responsable)
sistemas
(responsable)
Registran los cambios de configuración realizados en los

sistemas, incluyendo:
Administrador de la
Fecha infraestructura técnica
(responsable) Documentación
Hora Identificar adecuadamente los
actualizada de la
19 cambios realizados en los Administrador de base de datos
Responsable del cambio configuración realizada en
sistemas (responsable)
los sistemas
Tipo de cambio
Impacto identificado (responsable)
Criticidad
20 Finalización del proceso.
203
6.2 2 Diagrama de flujo

Administrador de la
Administrador de Analista de Oficial de Seguridad
Fase Usuario Solicitante Infraestructura
Bases de Datos Aplicaciones
Técnica
Inicio
0
1 Identifica 0
necesidad de 3
Evalúan el impacto del cambio
cambio en
configuración
0
Análisis
0
2 Comunica No 4
el cambio Se aplicará el cambio?
a realizar
Sí
0
5
Planifican el cambio
0
6 No
Requiere pruebas?
Sí
0
7
Definen y planifican pruebas necesarias
0
Pruebas
8 Ejecutan pruebas
0
No 9
Pruebas OK?
Sí
1
0
Autorizan realización del cambio
1
1
Definen y planifican tareas para realizar el cambio
1
2 Ejecutan tareas previas para permitir una vuelta
atrás
1
3
No
Tareas previas OK?
1
Sí
4
Implantan el cambio
Implantación
1
No 5
Cambio OK ?
1 Sí
6
Ejecutan tareas de vuelta atras
1
7
Aceptan formalmente el cambio
1
8 Actualizan documentación
1
9
2 Registran el cambio
0
Fin
204
6.2.3 Formulario de Control de cambios
Para realizar un efectivo control de cambios, a continuación se presenta un

formulario para documentar el seguimiento de los cambios, desde que surgen como
un requerimiento de usuario hasta su implantación en producción.
El objetivo de este registro es dejar asentados los datos de la persona que realizó el
requerimiento (usuario solicitante), las autorizaciones correspondientes, los
requisitos para su implantación en el entorno productivo y la aceptación del
responsable del sitio vivo y el personal del área usuaria.
FORMULARIO DE CONTROL DE CAMBIOS
NÚMERO: FECHA:
1. DATOS DEL USUARIO SOLICITANTE
Nombre:
Puesto:
Departamento:
Sede/Sucursal:
Ubicación (Ciudad/País):
E-mail:
Teléfono:
2. DESCRIPCIÓN DEL CAMBIO:
Tamaño:
Menor (menor de 50 usuarios afectados)
Medio / grande (más de 50 usuarios afectados)
Motivo:
Alta
Modificación
Baja
Descripción:
Fecha de implantación programada:
Horario de implantación programado:
Duración esperada (horas):

Resultados esperados:
Fecha de implantación real:
205
Duración real (horas):

Impacto:
Responsable:
3. SERVICIO(S) AFECTADO(s)
Aplicación(es):
Infraestructura:
Observaciones:
4. PRUEBAS
Fecha de prueba programada:
Horario de prueba programado:

Requerimientos:
Duración esperada (horas):
Resultados esperados:
Responsable:
Aprobación:
5. CANCELACIÓN Y RECUPERACIÓN
Procedimientos de cancelación de cambios:
Procedimientos de recuperación:
Notificación:
6. AUTORIZACIONES
_______________________ _________________________
Firma del usuario Firma del Jefe del
Solicitante departamento
206
7. AUTORIZACIONES ADICIONALES
_______________________ _________________________
Nombre Firma
_______________________ _________________________
Nombre Firma
8. CONFORMIDAD DEL SUPERVISOR DEL CPD
Observaciones:
_______________________ _________________________
Nombre Firma
NÚMERO: Número de requerimiento de cambios.

FECHA: Fecha del requerimiento.
1. DATOS DEL USUARIO SOLICITANTE: Este bloque de datos corresponden a

datos personales del usuario que realiza el requerimiento.
Nombre: Nombre del usuario solicitante.
Puesto: Posición que ocupa el usuario solicitante en la empresa.
Departamento: Departamento o sector al que pertenece el usuario solicitante.
207
Sede/Sucursal: Sede o sucursal de la empresa en la que trabaja el solicitante.

Ubicación (Ciudad/País): Ciudad o país donde trabaja el usuario solicitante,
para el caso de empresas distribuídas territorialmente.
E-mail: Dirección de correo electrónico del usuario solicitante.
Teléfono: Interno o línea directa del solicitante.
2. DESCRIPCIÓN DEL CAMBIO: Este bloque corresponde a información sobre el

cambio solicitado.
Tamaño: Tamaño del cambio medido en cantidad de usuarios afectados.
Menor (menor de 50 usuarios afectados)
Medio / grande (más de 50 usuarios afectados)
Motivo: Motivo de la solicitud del cambio
Alta
Modificación
Baja
Descripción: Breve descripción del cambio.
Fecha de implantación programada: Fecha programada para la realización del
cambio en el entorno de producción.
Horario de implantación programado: Horario programada para la realización
del cambio en el entorno de producción.
Duración esperada (horas): Tiempo que se invertirá en la implantación del
cambio.
Resultados esperados: Efectos de la realización del cambio.
Fecha de implantación real: Fecha real en que se ha realizado el cambio en el
entorno de producción.
Duración real (horas): Duración real de la implantación del cambio en el entorno
de producción.
Impacto: Efectos producidos por el cambio.
Responsable: Nombre de la persona responsable de la realización del cambio.
3. SERVICIO(S) AFECTADO(s): Este bloque corresponde a información sobre el

impacto del cambio solicitado.
Aplicación(es): Aplicaciones afectadas por el cambio.
Infraestructura: Equipamiento técnico afectado por el cambio.
Observaciones: Aclaraciones.
4. PRUEBAS: Este bloque corresponde a información sobre las pruebas realizadas

antes de implantar el cambio solicitado en el ambiente productivo.
208
Fecha de prueba programada: Fecha programada para la realización de las

pruebas.
Horario de prueba programado: Horario programado para la realización de las
pruebas.
Requerimientos: Requisitos para la realización de las pruebas.
Duración esperada (horas): Duración esperada de las pruebas.
Resultados esperados: Efecto esperado por los cambios a implantarse.
Responsable: Nombre de la persona responsable de la realización de las pruebas.
Aprobación: Nombre de la persona que deberá dar la aprobación de las pruebas
realizadas.
5. CANCELACIÓN Y RECUPERACIÓN: Este bloque corresponde a información

sobre los procedimientos de cancelación y vuelta atrás de la implantación del
cambio solicitado en el ambiente productivo.
Procedimientos de cancelación de cambios: Información sobre los
procedimientos de cancelación de la implantación del cambio solicitado en el
ambiente productivo.
Procedimientos de recuperación: Información sobre los procedimientos de
vuelta atrás de la implantación del cambio solicitado en el ambiente productivo.
Notificación: Lista de usuarios que deben ser notificados del cambio.
6. AUTORIZACIONES: Este bloque corresponde a información sobre las

autorizaciones necesarias para el pasaje al entorno productivo de los cambios
solicitados.
Firma del usuario solicitante: Firma del usuario solicitante.
Firma del Jefe del departamento: Firma del Jefe del departamento.
7. AUTORIZACIONES ADICIONALES: Este bloque corresponde a información

sobre las autorizaciones adicionales necesarias para el pasaje al entorno productivo
de los cambios solicitados.
Nombre: Nombre de la persona de la que se le solicita aprobación adicional.
Firma: Firma de la persona de la que se le solicita aprobación adicional.
8. CONFORMIDAD DEL SUPERVISOR DEL CPD: Este bloque corresponde a

información sobre la aprobación del pasaje al entorno productivo de los cambios
por parte de la persona responsable del CPD.
Observaciones: Aclaraciones.
Nombre: Nombre de la persona responsable del Centro de Procesamiento de Datos
de la que se le solicita aprobación adicional.
Firma: Firma de la persona responsable del Centro de Procesamiento de Datos de
la que se le solicita aprobación adicional.
209
6.2.4 ABM Activos
Es un documento creado para implementar el Control de Cambios en los activos,

que sirve para registrar todas las modificaciones inherentes a activos de la
empresa.
[IRAM/ISO/IEC17799] asegura:” Se deben controlar los cambios en los sistemas e

instalaciones de procesamiento de información. El control inadecuado de estos
cambios es una causa común de las fallas de seguridad y de sistemas”
Por lo que en este trabajo se ofrece una forma de llevar a cabo este control de
cambios de activos mediante un documento con forma de tabla, donde se registra
todo cambio realizado en el sistema ya sea a nivel físico o lógico:
• ALTA: Agregar un nuevo activo;

• BAJA: Eliminar un activo del Inventario de Activos;
• MODIFICACIÓN: Registrar cambios sobre un bien.
Se realizará una ALTA cada vez que se agregue al patrimonio de la organización un

activo, por ejemplo, cuando se adquiere un nuevo elemento de hardware como un
dispositivo de red, o un scanner, cuando se adquiera nuevo software, por ejemplo
en la actualización de utilitarios, o cuando se produzcan nuevos datos, por ejemplo
al realizar un backup.
Una BAJA de un activo corresponde a la eliminación del catálogo o Inventario de

Activos de un bien por distintas causas: fin de concesión de uso de bienes,
caducidad de contrato de alquiler de equipos, terminación de la vida útil de datos,
etc.
Se registrará una MODIFICACIÓN en el caso en que un activo sufra cambios en sus

características, por ejemplo en su tamaño y ubicación.
Tiene directa relación con el Inventario de Activos ya que ABM Activos hace
referencia a los activos registrados de la compañía.
Formato del ABM Activos
ACTIVOS
RELACIONADOS
FECHA CÓDIGO ABM CAUSA
210
FECHA: Fecha en que se produjo el ABM.
Se registrará con la siguiente codificación: dd/mm/aaaa.

CÓDIGO: Es el código rotulador que se le asignó a cada elemento en el Inventario
de Activos que permitirá identificar cada bien unívocamente, para su identificación
y seguimiento.
NOTA: Ver detalles sobre la codificación de activos en el apartado Inventario de
Activos.
ABM: En este campo se debe indicar el tipo de operación que se está registrando:
• A: Alta;
• B: Baja;
• M: Modificación;
CAUSA: es una descripción de la razón por la que el elemento sufrió el ABM en
cuestión.
ACTIVOS RELACIONADOS: En este campo se deben mencionar los activos que se
ven afectados por el cambio, por ejemplo unidades de hardware en que se ubicaba
un elemento de software al que se le da de baja.
6.2.5 Ejemplo - AMB Activos
En el ABM Activos:
ACTIVOS
RELACIONADOS
FECHA CÓDIGO ABM CAUSA
20/06/2003 BK0102 B Expiración de validez los datos. Unidad BK0174, HW0243

sobrescrita.
En el Inventario de Activos:
FECHA FECHA CRI ES-

CREACIÓN EXPIRACIÓN TI- TA-
CÓDIGO DESCRIPCIÓN UBICACIÓN RESPONSABLE CID DO
AD
HW0001 Mouse serie Piso 9, sector María Martinez 12/2001 - 0 A
211
Logitech QA, cpu:

HW0017
--- --- --- --- --- --- --- …
HW0034 Router Cisco 8000 Piso 7, sector Manuel Belgrano 7/2003 - 2 A

comunicacione
s
--- --- --- --- --- --- --- …
BK0102 Backup de HW0024 Juan Perez 20/05/2003 20/06/2003 2 B

Srv01/externo/pro
y5.mbd
--- --- --- --- --- --- --- …
BK0174 Backup de HW0024 Juan Perez 20/06/2003 20/07/2003 2 A

Srv01/externo/pro
y5.mbd
Este ejemplo se trata de un backup que, llegada su fecha de expiración, de elimina

sobrescribiendo la unidad física con el nuevo backup.
En la tabla de ABM Activos está indicado con azul el código del activo que ingresó
en el documento para registrar un cambio.
En el campo ABM se indica la eliminación del activo ingresando una “B”, se indica la
causa de la baja y los activos relacionados: HW0024 (indicado en verde, la
unidad de cinta que lo contenía) y BK0174 (el nuevo backup que reemplaza al
eliminado, indicado en rojo)
En este caso se trata de una baja, lo que significa que el activo dejará el estado A
(dado de Alta) para pasar al estado B (dado de Baja). Esto se debe ver reflejado en
el Inventario de Activos.
En la tabla Inventario de Activos se debe modificar el campo ESTADO del activo,

ingresando “B”de Baja. También se deberá insertar una nueva fila que dará de alta
la nueva versión.
Indicado con color rojo, se muestra el código de la nueva copia de backup

(nuevo activo) que ha sido dado de alta al reemplazar el backup anterior (vencido).
6.2.6 Actualizaciones de Software
Cada vez que se realicen “upgrades”, o sea, actualizaciones de versiones de

software se deberá llevar un control estricto de las máquinas donde se instaló y la
fecha.
212
Esta sirve no solo para ordenar y organizar la instalación, sino para controlar el
comportamiento de las máquinas actualizadas.
Muchas veces las actualizaciones pueden dejar la máquina inestable o provocar

otros efectos que se pueden revertir llevando una completa y rigurosa
documentación de los parches instalados.
6.2.6.1 Documento de Actualizaciones de Software
El documento de actualizaciones de software tiene como fin registrar la instalación

de todo “upgrade”de software realizado en las máquinas del dominio.
Tiene el siguiente formato:
SOFT DESCRIPCIÓN FECHA CPU# CPU# CPU# CPU#
SOFT: nombre del archivo de actualización instalado.

DESCRIPCIÓN: nombre de la aplicación que se está instalando, versión, etc.
FECHA: fecha de la actualización.
CPU#: código de la máquina donde se instala.
213
V. CONCLUSIÓN
En la introducción de este trabajo mencionamos la necesidad de una herramienta

que les permita a los profesionales de Informática descubrir y analizar las
vulnerabilidades de los entornos informatizados e implantar técnicas para
asegurarlos.
A la largo de esta tesis hemos analizado objetivos de control que llevan al ES a

lograr el aseguramiento del entorno objetivo (que se pretende asegurar) basados
en los principales estándares internacionales de seguridad, la normativa argentina
vigente y las mejores prácticas profesionales del mundo.
Con este análisis logramos formalizar una metodología práctica, y factible para
convertir entornos informatizados inseguros en entornos protegidos, y lograr una
clara evaluación de los mismos.
La metodología fue desarrollada en la parte IV de este trabajo. A través de los seis

capítulos que la componen, describimos las fases necesarias para lograr el completo
y total aseguramiento del entorno.
El Ingeniero que utilice esta metodología, podrá evaluar el contenido y alcance de

las distintas fases y aplicar los controles que considere necesario para el objeto de
su trabajo.
Independientemente del tamaño del entrono objetivo y de la clase de negocio que

apoye, esta metodología permitirá conocer el entorno e implantar medidas para
asegurarlo, basándose en las siguientes tareas:
• Elaborar un Plan de Trabajo evaluando tiempo, recursos y costos implicados;

• Realizar sondeo para descubrir vulnerabilidades;
• Analizar las vulnerabilidades para determinar su riesgo;
• Evaluar el impacto de los riesgos sobre el entrono, y sobre el negocio;
• Analizar la forma de mitigar los riesgos;
• Elaborar un Plan de Aseguramiento del entorno teniendo en cuenta aspectos
físicos, lógicos y de la organización, de manera de establecer objetivos de
control que mitiguen los riesgos existentes;
• Confeccionar un Inventario de los Activos físicos y lógicos de la empresa para
identificar y rotular cada uno de los bienes;
• Clasificar la Información para determinar su criticidad;
• Elaborar o adaptar para conveniencia de la empresa la Normativa de Seguridad
que apoye los procesos del negocio;
214
• Confeccionar una campaña de concientización de los usuarios involucrados para

lograr una efectiva implantación de los controles de Seguridad, y una adecuada
aplicación de las medidas que componen el Manual de seguridad;
• Realizar una adecuada capacitación de los usuarios para garantizar el
conocimiento de las medidas de seguridad aplicadas y la continuidad de los
controles en el tiempo;
• Implantar el Plan de Aseguramiento;
• Elaborar un Plan de Recuperación del Entorno ante Desastres (PRED) para la
prevención de catástrofes y la planificación de la recuperación del entorno
informatizado ante situaciones de emergencia, tratando de resguardar el
negocio de la empresa objetivo;
• Estabilizar el entorno realizando los ajustes necesarios al Plan de
Aseguramiento;
• Mantener el nivel de seguridad logrado mediante el control de Incidencias y de
cambios;
Todas estas tareas estarán documentadas, y se apoyarán en registros y tablas que

las facilitarán y también guiarán al ES interviniente en su tarea.
Estos son los documentos asociados a las distintas tareas que desarrollamos en
esta metodología:
• Documento de Requerimientos de Usuario: formaliza la voluntad del cliente y de

los usuarios respecto de los requerimientos de seguridad del entorno;
• Alcance: establece es espectro que abarcará el proyecto. En este documento se
define el entorno a asegurar, se delimita su extensión y se establecen los
distintos niveles que se evaluarán.
Este punto es muy importante porque la metodología permite efectuar un

aseguramiento a nivel:
o Físico;
o Lógico;
o De la organización.
A su vez este análisis se puede reducir a un nivel o dos, según el deseo del cliente y
su presupuesto.
Es importante recalcar que, como vimos en todo el desarrollo de la MAEI, no es

necesario aplicar todas las fases, ni en los tres niveles. Pueden saltearse fases,
cambiarlas de orden, investigarse aspectos netamente físicos, netamente lógicos,
netamente de la organización o una combinación de ellos.
• Plan de Trabajo: ofrece una organización del proyecto con las tareas a realizar
con su duración aproximada y los recursos destinamos a cada una;
215
• Relevamiento General: ofrece un marco de referencia para comenzar a trabajar.

El objetivo de este documento es registrar el sondeo inicial que realiza el ES
para conocer el entorno a asegurar;
• Relevamiento de Usuario: consiste en un test que tiene por objetivo determinar
el grado de conocimiento y concientización respecto de la seguridad que poseen
los usuarios finales;
• Mapa de Vulnerabilidades: es un registro que recompila las vulnerabilidades
halladas;
• Informe de Riesgos: esta tabla ofrece una forma de documentar las
vulnerabilidades halladas asociándoles su riesgo, su probabilidad de ocurrencia,
el impacto en el entorno y en el negocio y su criticidad;
• Plan de Aseguramiento: recompila todas las medidas, controles y
procedimientos que se llevarán a cabo para asegurar el entorno en estudio y
mitigar los riesgos hallados en los distintos niveles (físico, lógico y de la
organización);
• Mapa de Elementos de Red: es una lista de los elementos físicos presentes en la
red de datos;
• Mapa de Usuarios: permite organizar los usuarios en grupos, y a su ver
visualizar los distintos grupos a los que pertenece un usuario;
• Documento de Actualización de software: Permite llevar un control de las
actualizaciones aplicadas a los distintos equipos de la red;
• Tabla de Permisos sobre Activos Lógicos: Permite documentar la relación directa
entre recursos y usuarios, asignando permisos a usuarios y perfiles sobre
activos lógicos;
• Archivos de log: son registros (archivos de texto, bases de datos u otros) que
permiten el registro de las pistas de auditoría que emite el sistema informático;
• Inventario de Activos: documento que sirve para llevar un control de los activos
lógicos y físicos presentes en el entorno:
o Inventario de Activos Físicos: recompila todos los activos de tipo físico y los
enumera y clasifica;
o Inventario de Activos Lógicos: recompila todos los activos de tipo lógico y
los enumera y clasifica;
• Inventario de Backups: es un registro de las copias de respaldo de los datos que
se realiza junto con la fecha, el medio físico que los contiene y un código
identificatorio. Está directamente ligado al Inventario de Activos ya que el
código es el utilizado para identificar el activo lógico “backup” y el número de
dispositivo identifica a la cinta o medio físico;
• ABM Activos: es un registro de los cambios que sufren los activos, y su relación
entre con otros activos;
• Manual de Seguridad: compuesto por la normativa de la organización:
o Política general;
o Normas;
o Procedimientos;
o Estándares técnicos;
o Manuales de usuario;
216
o Instructivos;
• Comunicados: medios escritos por los cuales se informan los usuarios y
empleados;
• Presentaciones: medios por los cuales se capacita a los usuarios y empleados;
• Documentación de Capacitación: documentos que sirven para la capacitación de
los usuarios y empleados;
• Tabla de Criticidades por Equipo: documento que sirve para establecer las
criticidades de los equipos del entorno;
• Tabla de Criticidades por Servicio: documento que sirve para establecer las
criticidades de los servicios del entorno;
• Tabla de Criticidades por Aplicación: documento que sirve para establecer las
criticidades de las aplicaciones del entorno;
• PRED: Plan de Recuperación del Entorno ante Desastres: establece las medidas
a tomar para prevenir catástrofes y recuperar el entorno una vez ocurridas,
preservando los objetivos del negocio:
o Procedimiento de Declaración de la Emergencia: conjunto de tareas a
realizar ante un acontecimiento que afecte las prestaciones del entorno;
o Procedimiento de Recuperación de las Prestaciones: tareas a realizar una
vez declarada la emergencia, para recuperar el funcionamiento en
emergencia de los equipos y servicios
o Procedimiento de Reestablecimiento de las Condiciones Normales: tareas a
realizar una vez recuperadas las prestaciones en contingencia, para
recuperar el funcionamiento normal de los equipos y servicios;
• Informe de Implantación: documento con los detalles del avance del proyecto
de aseguramiento del entorno y de los cambios realizados;
• Informe de Cierre de Implantación: es un documento que contiene los detalles
de los resultados del proyecto de aseguramiento del entorno y de los cambios
realizados;
• Manual de Procedimientos sobre Reporte de Incidencias: manual que capacita a
los usuarios en el proceso de reporte de incidencias de seguridad en el entorno;
• Reportes de Incidencias: documento que se utiliza para registrar las incidencias
ocurridas en el entorno;
• Registro de Incidencias: es un documento que recompila todas las incidencias
ocurridas y las centraliza para su posterior análisis y estudio estadístico;
• Formulario de Control de Cambios: es un documento que creamos con el fin de
registrar todos los requerimientos de cambios surgidos en el entorno, y su
prueba e implantación;
La idea de este conjunto de herramientas es seleccionar las apropiadas para el

entorno que se está estudiando, quizás combinarlas, y utilizarlas como constante
fuente de control y auditoría de la vida del entorno.
Como fuente de control estos documentos sirven ya que su constante

mantenimiento garantiza el conocimiento de los distintos aspectos que traten. Por
ejemplo, mantener actualizado el Inventario de Activos Físicos implica tener un
217
completo conocimiento de los bienes físicos de la empresa, lo que permitiría

detectar hurtos que, de otra manera, pasarían desapercibidos.
Como fuentes de auditoría estos documentos también proporcionan pruebas de

violaciones a las Normas de la compañía, actos ilícitos y falta de control interno en
los procesos del negocio.
Todos los sistemas informáticos sufren cambios constantemente. El entorno cambia

con ellos, y es por eso que considero fundamental registrar todos esos cambios, no
solo específicamente utilizando los procedimientos recomendados en la fase de
Control de Cambios, sino considerar todo el proyecto como una oportunidad para
documentar el entorno para detectar fallas en los objetivos de control fijados por el
Experto, para depurar los procesos no documentados y perfeccionarlos, para
mejorar el flujo de la información y la comunicación de los datos, para verificar que
se tenga en cuenta la contraposición de intereses en los roles de control y ejecución
de las tareas y procesos, para dejar pistas de auditoría y para incrementar la base
de conocimiento de todos los empleados de la compañía.
Entonces, la Metodología de Aseguramiento de Entornos Informatizados provee a

los Ingenieros en Informática y Licenciados en Análisis de Sistemas de una
herramienta con modelos estructurados para que, de forma ordenada y efectiva, les
facilite y les guíe en la tarea de dar informe de las vulnerabilidades presentes en el
entorno en que trabajan, su criticidad e impacto, los riesgos tecnológicos y
funcionales asociados, determinar las posibles formas de mitigarlos, planificar la
forma de implantar la solución más conveniente para el entorno en estudio y para
el cliente, para luego implantarlas con éxito y así lograr una efectiva protección y
documentación del entorno objetivo, que era el propósito de este trabajo.
218
VI. BIBLIOGRAFÍA
• [IRAM/ISO/IEC17799] IRAM/ISO/IEC 17799 Julio 2002. Proyecto 1 de norma

argentina. Código de práctica para la gestión de la seguridad de la información.
Basada en ISO/IEC Standard 17799: Information Technology – Code of Practice
for Information Security Management.
• [BS7799] British Standard - Information technology. Code of practice for

information security management.
• [Cobit] Cobit Standard- Objetivos de Control para la Información y Tecnologías -

2000, emitido por el Comité directivo del Cobit y la Information Systems audit.
And Control Fundation.
• [Huerta2000] Huerta, A. 2000. Seguridad en Uníx y redes. 2da edición. España.
• [Tackett-Burnett2000] Tackett, j. y Burnett S. 2000. Linux. 4ta edición. Prentice

Hall Iberia. España.
• [Scambray-McClure-Kurtz2001] Scambray, J., McClure, S. Y Kurtz, G. 2001.

Hackers 2. McGraw-Hill/Interamericana de España.
• [Stallings1999] Stallings, W. 1999. Cryptography and Network Security:

Principles and Practice, 2da edición, Prentice Hall, Inc.
• [Martorell] Martorell, M. Control de Accesos. Escola Universitaria Politecnica de

Mataro.
• [hispasec] Hispasec Sistemas.

o http://www.hispasec.com
• [isecom] ISECOM - Institute for security and Open Methodologies.

o http://www.isecom.org
• [ iss.net] ISS- Internet Security Systems.

o http://iss.net
• [xforce.iss] Base de datos de vulnerabilidades y amenazas de ISS.
219
o http://xforce.iss.net/
• [bsi] British Standards Online.

o http://www.bsi-global.com/index.xalter
• [Benson] Microsoft Solutions Framework. Estrategias de Seguridad. Christopher

Benson, Inobits Consulting (Pty) Ltd.
o http://microsoft.com/latam/technet/articulos/200011/art04
• [Consid-MS] Microsoft Solutions Framework. Consideraciones de seguridad para

la autoridad administrativa.
o http://msn.com
.
• [10laws-MS] Microsoft Technet. The Ten Immutable Laws of Security. 2003
o http://microsoft.com/technet/colums/security/assays/10imlaws.asp
• [Technet] Microsoft Technet.

o http://microsoft.com/technet
• [MMC] Conjunto de herramientas de configuración de seguridad de Microsoft-

MMC. 2003.
o http://microsoft.com
• [ISACA] ISACA (Information Systems Audit and Control Association).

o http://www.isaca.org
• [MRSA-ISACA]“Metodología de revisión de software aplicativo” (Application

Software Audit Methodology). ISACA (Information Systems Audit and Control
Association).
o http://www.isaca.org
• [AAW-ISI] “Auditoría de aplicaciones web”. Instituto Seguridad Internet (ISI).

o http://www.instisec.com
220
• [OSSTMM-ISECOM] “Open Source Security Testing Methodology Manual –

OSSTMM”. Pete Herzog. Isecom.
o http://www.isecom.org
• [AACF-ROBOTA] “Auditoría de aplicaciones y Código fuente”. Robota.

o http://www.robota.net
221
VII. ANEXO I. MAEI – RESUMEN DE FASES Y TAREAS
1 Definición del Alcance.

1.1 Análisis de Requerimientos de Usuario.
1.2 Elaboración del Alcance.
1.3 Aprobación del Alcance.
1.4 Estimación de tiempos y costos.
1.5 Elaboración del Plan de Trabajo.
2 Relevamiento.
2.1 Elaboración del Relevamiento General.
2.2 Elaboración del Relevamiento de Usuario.
2.3 Análisis de vulnerabilidades.
2.4 Análisis de Riesgos.
3 Planificación .
3.1 Elaboración del Plan de Aseguramiento.
3.2 Aprobación del Plan de Aseguramiento.
4 Implantación.
4.1 Elaboración del Relevamiento de Activos.
4.2 Clasificación de la Información.
4.3 Elaboración/ adaptación de la Normativa de Seguridad.
4.4 Publicación de la Normativa de Seguridad.
4.5 Implantación del Plan de Aseguramiento.
4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres (PRED).
5 Estabilización.
5.1 Análisis de resultados.
5.2 Ajuste.
5.3 Cierre de la implantación.
5.4 Capacitación de usuarios.
6 Mantenimiento.
6.1 Control de incidencias.
6.2 Control de cambios.
222
VIII. ANEXO II. ESTÁNDARES INTERNACIONALES. RESEÑA

INTRODUCTORIA.
ISO/IEC estándar 17799

Information Technology – Code of Practice for Information Security
Management
El ISO/IEC estándar 17799 es un marco que brinda recomendaciones para la

gestión de la seguridad de la información.
Su origen es el estándar británico BS7799.
Su objetivo es proveer de una base común para el desarrollo de estándares de

seguridad de la organización y una práctica efectiva de su administración,
brindando asimismo, confianza en las relaciones llevadas a cabo entre las
organizaciones.
Estas recomendaciones han de ser aplicadas por los responsables de iniciar,

implantar o mantener la seguridad en sus organizaciones, entre las que se
encuentran la definición de seguridad de la información, la organización de la
seguridad, controles en los distintos aspectos físicos, lógicos, en el personal, en los
activos de la compañía, control de accesos y gestión de comunicaciones, desarrollo
y mantenimiento de sistemas, administración de la continuidad del negocio, entre
otros.
En particular, este estándar trata el análisis de “Requerimientos de seguridad de los

sistemas”, que se ha tomado en esta metodología como parte de los controles a
realizar en la etapa de relevamiento y de análisis de vulnerabilidades.
Esta sección describe cómo se deben tratar los datos de entrada: “Los datos de
entrada en sistemas de aplicación deben ser validados para asegurar que son
correctos y apropiados. Los controles deben ser aplicados a las entradas de las
transacciones de negocios, datos permanentes (nombres y direcciones, límites de
crédito, números de referencia al cliente) y tablas de parámetros (precios de venta,
tasa de impuestos, índice de conversión de dinero).” También especifica controles
de procesamiento interno, asegurando que “el diseño de aplicaciones debe asegurar
que las restricciones se implementen para minimizar los riesgos de fallas de
procesamiento, conducentes a una pérdida de la integridad.” Y controles en los
datos de salida.
Asimismo, encontramos la sección “Controles criptográficos” que establece criterios

para aplicar controles criptográficos, firma digital, servicios de no repudio, y la
administración de las claves criptográficas, afirmando que “Decidir si una solución
criptográfica es apropiada, debe ser visto como parte de un proceso más amplio de
evaluación de riesgos, para determinar el nivel de protección que debe darse a la
223
información”. Se realiza este análisis de riesgos en la etapa 2.4 de esta

metodología.
La sección “Seguridad de los archivos del sistema” trata el control del software
operativo y la protección de los datos de prueba del sistema. Los relevamientos que
forman parte de esta tesis se efectúan según lo dispuesto en la Ley Orgánica
española 15/1999, de 13 de Diciembre, de Protección de datos de carácter
personal, en adelante LOPD y Real Decreto 994/1999, de 11 de Junio, por el que se
aprueba el Reglamento de Medidas de Seguridad (en adelante RMS) de los archivos
automatizados que contengan datos de carácter personal.
Finalmente, este trabajo se referencia en la verificación de la seguridad de los

procesos de desarrollo y soporte, y de los procedimientos de control de cambios en
donde el estándar afirma que “se debe imponer el cumplimiento de los
procedimientos formales de control de cambios. Estos deben garantizar que no se
comprometan los procedimientos de seguridad y control, que los programadores de
soporte solo tengan acceso a aquellas partes del sistema necesarias para el
desempeño de sus tareas, y que se obtenga un acuerdo y aprobación formal para
cualquier cambio”.
En el apartado “Desarrollo y mantenimiento de sistemas” del estándar se hace

referencia a los controles considerados en la etapa de Análisis de vulnerabilidades
en las aplicaciones.
Para validar la forma de realización de los cambios se han considerado los puntos
referidos en la sección “Seguridad de los procesos de desarrollo y soporte”.
Para el registro y seguimiento de pistas de auditoría se toma en cuenta la

“Monitorización del acceso y uso de los sistemas”.
Las secciones “Validación de los datos de entrada”, “Controles de procesamiento

interno”, y “Validación de los datos de salida” se manifiestan como parte de la
etapa 2.3.2.
Para la última fase de esta metodología (Mantenimiento) se han adaptado los

controles y las recomendaciones de la sección “Respuesta a incidencias y anomalías
en materia de seguridad”.
Cobit
Objetivos de Control para la Información y Tecnologías - 2000, emitido por
el Comité directivo del Cobit y la Information Systems audit. and Control
Fundation
224
Cobit es un estándar que pretende conciliar el negocio con los recursos (personas,
aplicaciones, datos, tecnología, instalaciones) del ambiente de IT, haciendo énfasis
en la organización y en la planificación.
Define 34 procesos de IT que considera como unidades controlables, sobre los que
establece objetivos de control. Éstos se agrupan en cuatro dominios:
• Planificación y organización
• Adquisición e implantación
• Entrega y soporte
• Monitorización
Cobit define 318 objetivos detallados que involucran a todas las áreas de la
empresa.
Estos objetivos permiten determinar la situación actual, es decir, el nivel de

madurez, según el modelo de madurez o Capability Maturity Model (MMC), y
permite fijar objetivos para subir el nivel mediante estos puntos de control.
Para la elaboración de esta metodología se consideraron los siguientes puntos de

control:
• Planificación y organización:
Objetivos de “Determinación de la dirección tecnológica” para la verificación de

temas técnicos de la aplicación como la estrategia de recuperación ante desastres.
Objetivos de “Definición de la organización y las relaciones de IT” para el análisis

del control interno y separación de funciones.
Los objetivos de “Administración de proyectos” fueron considerados para los

controles a realizar a nivel de metodología de desarrollo de proyectos.
Los de “Administración de calidad” conforman la base para el estudio de la

separación de ambientes, el análisis de los entornos y de las pruebas.
• Adquisición e implantación:
Para el análisis de las interfases con los usuarios, el análisis de la documentación,

aprobación del diseño y de cambios como parte del control de cambios analizado en
la etapa 2.3, se han analizado los objetivos de control de “Adquisición y
mantenimiento del software de aplicación”, los de “Desarrollo y mantenimiento de
procedimientos” y “Administración de cambios”.
225
• Entrega y soporte:
En el análisis de la administración de la seguridad informática se estudiaron los
objetivos de control de “Garantía de la seguridad de los sistemas”.
Los objetivos de “Administración de problemas e incidencias”se consideran en la

etapa de manejo de incidencias.
El análisis de manejo de datos es efectuado siguiendo los procedimientos

presentados en “Administración de datos”.
El análisis de las operaciones se basa en los objetivos de control de “Administración

de operaciones”.
• Monitoreo:
Los objetivos agrupados en “Evaluación de la idoneidad del control interno” se
consideran a la hora de evaluar la coherencia, efectividad y adecuación del control
interno.
MAGERIT
Metodología de Análisis y Gestión de Riesgos de los Sistemas de
Información de las Administraciones Públicas
MAGERIT, es una metodología formal destinada a investigar los riesgos que

soportan los Sistemas de Información, y recomendar las medidas apropiadas que
deberían adoptarse para controlar estos riesgos.
Las recomendaciones de MAGERIT permiten conocer, prevenir, impedir, reducir o

controlar los riesgos investigados, mediante la gestión de riesgos.
En particular, se han considerado las presentes en la “Guía Para Responsables Del

Dominio Protegible”, entre las que se encuentran: “Conocimiento de las Amenazas”,
“Estimación de las Vulnerabilidades”, “Identificación de Impactos”, “Estimación de
Impactos”, “Riesgos”
Según MAGERIT, el análisis de riegos identifica seis elementos:
• Activos
• Amenazas
• Vulnerabilidades
• Impactos
226
• Riesgo
• Salvaguardas
Estos seis elementos son estudiados durante todo el proceso que presentamos en
nuestra metodología de revisión de aplicaciones, donde se realiza el relevamiento
que abarca, entre otras cosas, la evaluación de la aplicación a revisar como activo
lógico de la organización, y los elementos relacionados con ésta como bases de
datos y otras aplicaciones, para pasar a la etapa donde se identifican las amenazas,
las vulnerabilidades y se estudia su riesgo asociado, para finalmente recomendar la
mejor salvaguarda que corresponda.
227
IX. ANEXO III. GLOSARIO DE TÉRMINOS.
Los siguientes son términos utilizados en este trabajo, obtenidos de

[IRAM/ISO/IEC17799], [Huerta2000] , [Stallings1999], [Technet]:
Accesos autorizados: autorizaciones concedidas a un usuario para la utilización

de los diversos recursos.
Análisis de riesgos: Evaluación de las amenazas, impactos y vulnerabilidades

relativos a la información y a las instalaciones de procesamiento de la misma, y a la
probabilidad de que ocurran.
Autenticación: procedimiento de comprobación de la identidad de un usuario.
Autorización: Garantizar que todos los accesos a datos y/o transacciones que los
utilicen, cumplan con los niveles de autorización correspondientes para su
utilización y divulgación.
Backup: copia de los datos de un archivo automatizado en un soporte que

posibilite su recuperación.
Basurero: La información de los desperdicios dejados alrededor de un sistema

puede ser aprovechada por intrusos provocar un hurto o daño.
Bombas lógicas: Programas que se activan al producirse un acontecimiento

determinado. La condición suele ser una fecha (Bombas de Tiempo), una
combinación de teclas, o un estilo técnico Bombas Lógicas), etc. Si no se produce la
condición permanece oculto al usuario.
Backdors y trapdors: Son instrucciones que permiten a un usuario acceder a

otros procesos o a una línea de comandos, y suelen ser aprovechados por intrusos
malintencionados para tomar control sobre las computadoras.
Challenge-response: Metodología utilizada para la autenticación de usuarios

denominada usualmente desafío-respuesta. Se realiza un interrogante o una serie
de ellos que sólo el usuario autorizado puede conocer la respuesta.
Chip-cards: Tarjetas que poseen integrado un circuito impreso, en el cual se

almacenan datos que posibilitan la autenticación del usuario.
Cliente: toda entidad, empresa, organismo o persona que presente su entorno

informatizado con el fin de que el ES lo analice y lo asegure.
228
Conejos: Programas que no dañan directamente al sistema por alguna acción

destructiva, sino que tienen la facilidad de reproducirse exponencialmente de
manera de provocar en poco tiempo una negación de servicio al consumir los
recursos (memoria, disco, procesador, etc).
Confiabilidad: Garantizar que los sistemas informáticos brinden información

correcta para ser utilizada en la operatoria de cada uno de los procesos.
Confidencialidad: Garantizar que toda la información está protegida del uso no

autorizado, revelaciones accidentales, espionaje industrial, violación de la
privacidad y otras acciones similares de accesos de terceros no permitidos.
Contraseña: información confidencial, frecuentemente constituida por una cadena

de caracteres, que puede ser usada en la autenticación de un usuario.
Control de acceso: mecanismo que en función de la identificación ya autenticada

permite acceder a datos o recursos.
Copia del respaldo o resguardo: ver backup.
Courier: Mensajero, correo. Persona o dispositivo mediante el cual se envían

mensajes o elementos.
Desktop environments: Configuraciones de escritorio.
Dial-back: Metodología de rellamado ante la recepción de petición para establecer

una comunicación con un servidor. Al recibir este dicho requerimiento produce el
corte de la llamada y luego se comunica mediante una dirección preestablecida.
Disponibilidad: Garantizar que la información y la capacidad de su tratamiento

manual y automático, sean resguardados y recuperados eventualmente cuando sea
necesario, de manera tal que no se interrumpa significativamente la marcha de las
actividades.
Download: (descargar, bajar, bajarse) En Internet proceso de transferir

información desde un servidor de información al propio ordenador personal.
Eaves dropping: Es la escucha no autorizada de conversaciones, claves, datos,

etc.
229
Eficacia: Garantizar que toda información que sea utilizada es necesaria y

entregada de forma oportuna, correcta, consistente y útil para el desarrollo de las
actividades.
Eficiencia: Asegurar que el tratamiento de la información se realice mediante una

óptima utilización de los recursos humanos y materiales.
Entorno: Se considera entorno un amplio espectro de ambientes, desde empresas

multinacionales distribuidas físicamente en el mundo hasta datos individuales, una
empresa informatizada, puede definirse como el edificio que alberga a la empresa
objetivo o como el Centro de Cómputos (CC) o Centro de Procesamiento de Datos
(CPD) donde se encuentran los servidores, un sector informatizado de un negocio,
una red de telecomunicaciones, un equipo de cómputos, una aplicación, archivos
lógicos o cualquier elemento susceptible a ataques informáticos.
ES: Experto en Seguridad. En este trabajo se lo considera el principal actor, que

utiliza la metodología AEI para asegurar un entorno informatizado.
Exactitud: Asegurar que toda la información se encuentre libre de errores y/o

irregularidades de cualquier tipo.
Fallback: Metodología de emergencia ante fallas que posibilitan la recuperación de

información perdida.
Firewall (cortafuegos): Dispositivo que se coloca entre una red local e Internet y
cuyo objetivo es asegurar que todas las comunicaciones entre los usuarios de dicha
red e Internet se realicen conforme a las normas de seguridad de la organización
que lo instala.
Gateway (pasarela): Punto de una red que actúa como punto de entrada a otra
red.
Gusanos (Worms): Son programas independientes (no necesitan insertarse en

otros archivos) que se expanden a través de la red realizando distintas acciones
como instalar virus, o atacar una PC como un intruso.
Hacker (pirata): Una persona que goza alcanzando un conocimiento profundo

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, cuando
en este último sentido sería más correcto utilizar el término cracker. Los hackers
proclaman tener una ética y unos principios contestatarios e inconformistas pero no
delictivos.
Hacking (pirateo): Acción de piratear sistemas informáticos y redes de

telecomunicación.
230
Herramientas de seguridad: Son utilitarios que sirven para identificar

vulnerabilidades en un sistema. Pueden ser una amenaza si un intruso las utiliza en
el sistema y detecta fallas en la seguridad de las que el administrador no está
enterado.
Hoax: (camelo, bulo) Término utilizado para denominar a rumores falsos,

especialmente sobre virus inexistentes, que se difunden por la red, a veces con
mucho éxito causando al final casi tanto daño como si se tratase de un virus real.
Host system: (sistema anfitrión, sistema principal) Ordenador que, mediante la

utilización de los protocolos TCP/IP, permite a los usuarios comunicarse con otros
sistemas anfitriones de una red. Los usuarios se comunican utilizando programas
de aplicación, tales como el correo electrónico, Telnet, WWW y FTP. La acepción
verbal (to host) describe el hecho de almacenar algún tipo de información en un
servidor ajeno.
Identificación: procedimiento de reconocimiento de la identidad de un usuario.
ID: Nombre o identificación de usuario.
Incidencia o incidente: cualquier anomalía que afecte o pudiera afectar a la

seguridad del entorno.
Ingeniería social: Consiste en la manipulación de las personas para que

voluntariamente realicen actos que normalmente no harían, como revelar su
contraseña o cambiarla.
Integridad: Asegurar que sea procesada toda la información necesaria y suficiente

para la marcha de las actividades en cada uno de los sistemas informatizados y
procesos transaccionales.
Laptop: (computador portátil, ordenador portátil) Ordenador de tamaño pequeño-

medio, que se puede transportar como un maletín y apoyar en el regazo (lap).
Legalidad: Asegurar que toda la información y los medios físicos que la contienen,
procesen y/o transporten, cumplan con las regulaciones legales vigentes en cada
ámbito.
Logged in: Conexión del equipamiento.
Logged out: Desconexión de equipamiento.
231
Logging: Registro de actividades en un archivo informático, de diferentes

situaciones, se utiliza normalmente como evidencia de auditoria.
Login: Conexión. Entrada en una red.
Logon: Procedimiento de conexión o entrada al sistema por parte de un usuario.
Logs: Registros de situaciones en un sistema informático, tales como actividades

de usuarios, control de contraseñas, etc. Es el resultado de puesta en marcha del
logging.
Mainframe: Estructura principal. Computadora de gran tamaño de tipo

multiusuario, utilizada en empresas.
Masquerading: Un intruso puede usar la identidad de un usuario autorizado que

no le pertenece simplemente apoderándose de un nombre de usuario y contraseña
válidos.
No Repudio: Garantizar los medios necesarios para que el receptor de una

comunicación pueda corroborar fehacientemente la autenticidad del emisor.
Notebook: Computador u ordenador portátil.
Normativa de Seguridad: Conjunto de reglas, normas, procedimientos,

estándares e instructivos que regulan los aspectos funcionales y técnicos de la
seguridad informática en una organización.
Outputs: Salida. Se refiere al producto del proceso de datos, con relación a su

presentación, bien puede ser impresa o por pantalla u otro medio idóneo.
Over-classification: Clasificación en exceso. Se refiere al proceso de clasificación

de la información con relación a la categorización respecto a su publicidad o no.
PABXs: Centralita privada automática (Private Automatic Branch eXchange) (ramal

de intercomunicación telefónica privada). Son ramales de intercomunicación digital
interno que permiten manejar tanto la circulación de voz como la de los datos,
utiliza conmutación de circuitos.
Palmtop: (computador de palma, ordenador de palma) Ordenador de pequeño

tamaño, algo mayor que un paquete de cigarrillos, que se puede llevar en la palma
de la mano (palm) y que, además de otras funciones, permite la conexión con
Internet.
232
Password: (palabra de paso, contraseña) Conjunto de caracteres alfanuméricos

que permite a un usuario el acceso a un determinado recurso o la utilización de un
servicio dado.
PC: Personal Computer. Computadora Personal.
Piggy backing: Ocurre cuando un usuario no autorizado accede a una zona

restringida gracias al permiso otorgado a otra persona que sí está autorizada.
PIN: Personal Identification Number. Número de identificación personal, clave

utilizada para el acceso a cajeros automáticos, asociada con una tarjeta de débito o
de credito.
Protección Física: Garantizar que todos los medios de procesamiento y/o

conservación de información cuenten con medidas de protección física que eviten el
acceso y/o utilización indebida por personal no autorizado.
Propiedad: (derecho a propiedad) Asegurar que todos los derechos de propiedad

sobre la información utilizada en el desarrollo de las tareas, estén adecuadamente
establecidos a favor de sus propietarios.
Recurso: cualquier parte componente de un entorno informatizado.
Router: Sistema constituido por hardware y software para la transmisión de datos

en una red. El emisor y el receptor deben utilizar el mismo protocolo de
comunicaciones.
Scanners: Software, a veces asociado a equipamiento que permite realizar la

inspección de comunicaciones, usualmente mediante el barrido de frecuencias.
Schedulling: Planificación, se utiliza como requerimiento para el desarrollo de

tareas, programación, ejecución de procesos, etc.
Shoulder Surfing: Consiste en espiar físicamente a los usuarios para obtener

claves de acceso al sistema, números válidos de tarjetas de crédito, etc.
Spooled data: Datos en cola de espera. Los mismos pueden hallarse en dicha
situación para su ingreso o su salida, impresión.
Start-up: Inicio del sistema. Tanto de software, programa o aplicación, como de

hardware, equipamiento.
233
Stop: Cierre del sistema. Tanto de software, programa o aplicación, como de

hardware, equipamiento.
Seguridad de la información: La preservación de la confidencialidad, integridad y

disponibilidad de la información.
Sistemas de información: conjunto de archivos automatizados, programas,

soportes y equipos empleados para el almacenamiento y tratamiento de datos.
Software malicioso: (malware) Es un término común que se utiliza al referirse a

cualquier programa malicioso o inesperado o a códigos móviles como virus,
troyanos, gusanos o programas de broma.
Soporte: objeto físico susceptible de ser tratado en un entorno informatizado y

sobre el cual se pueden grabar o recuperar datos.
Teleworking site: Sitio de trabajo remoto o a distancia.
Timeouts: Son programas que se pueden utilizar durante un período de tiempo

determinado;
Tokens: Dispositivos de hardware que posibilitan la generación aleatoria de claves

de acceso.
Troyanos: Similar al famoso Caballo de Troya, estos programas maliciosos ocultan

sus intenciones reales bajo la apariencia de un juego, una animación, etc. Algunos
troyanos permiten el acceso al equipo infectado, otros borran archivos, introducen
un virus o comprometen la seguridad del sistema atacado de diferentes maneras.
Upgrading: Ascender de nivel, actualizar, modernizar.
UPS: Usage Parameter Control. Parámetros de control de uso.
Usuario: sujeto o proceso autorizado para acceder a datos o recursos.
Web: World Wide Web, o simplemente Web, es el universo de información

accesible a través de Internet, una fuente inagotable del conocimiento humano.
Worms: (Gusanos) Son programas que tratan de reproducirse a si mismo, no

produciendo efectos destructivos sino el fin de dicho programa es el de colapsar el
sistema o ancho de banda, replicándose a si mismo.
234

Bisogno Tesisdegradoingenieriainformatica PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bisogno Tesisdegradoingenieriainformatica PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE BUENOS AIRES

Alumna: María Victoria Bisogno

2.2.4 Resultados de la evaluación .............................................................. 55

4.1.2 Ejemplo – Inventario de Activos ...................................................... 139

4.6.3.4 Ejemplo - Tabla de Criticidades por Servicios. ................................. 166

6.1.5 Respuesta a incidencias ................................................................. 191

La Seguridad Informática es una disciplina cuya importancia crece día a día.

Aunque la seguridad es un concepto difícil de medir, su influencia afecta

[Huerta2000] define la seguridad como “una característica de cualquier sistema

[IRAM/ISO/IEC17799] sostiene que “la seguridad de la información protege a ésta de

En cualquier entorno informatizado es necesario estar protegido de las múltiples (y

• Integridad: que se proteja la exactitud y totalidad de los datos y los métodos

• Confidencialidad: que la información sea accesible sólo a las personas

• Disponibilidad: que los usuarios autorizados tengan acceso a la información y a

[IRAM/ISO/IEC17799] también agrega “La seguridad de la información se logra

Para la realización de este trabajo se han estudiado diversas metodologías de

Además, la bibliografía relacionada ofrece soluciones puntuales para problemas

El propósito del presente proyecto es formalizar una metodología práctica, y factible

El principal objetivo, entonces, es proveer a los Ingenieros en Informática y

Se pretende que esta metodología cree un cambio cultural en el ambiente donde se

Al hablar de sistema “inseguro” se hace referencia a un sistema no confiable, no

NOTA: De ahora en más se hará referencia al experto en seguridad, actor

2. Estado del Arte de la Seguridad Informática.

Básicamente, los problemas de Seguridad Informática son sucesos que no deseamos

Cuando hablamos de incidentes de Seguridad, o problemas de Seguridad Informática

• Acceso no autorizado a la información;

Cada entorno informatizado es diferente, y maneja distintos tipos de información, y

La funcionalidad y características técnicas de los componentes de los entornos varían

Hoy en día la amenaza más común en los ambientes informatizados se centra en la

El crecimiento de las telecomunicaciones y la estricta dependencia que existe entre el

Prácticamente toda la información vital para el negocio de una compañía comercial se

Es por eso que se pone énfasis en el crecimiento de soluciones para el problema de la

Protegerse contra accesos no autorizados es el problema más sencillo a resolver, ya

Desafortunadamente, no es suficiente simplemente arreglar los errores o eliminar las

La Seguridad Informática es un problema cultural, en el que el usuario juega un rol

La responsabilidad sobre la seguridad de los datos y equipos ya no recae solamente

Para ello debe existir una conciencia de trabajo seguro, de resguardo de la

La seguridad, entonces, debe nacer en el diseño seguro de los sistemas, de la

Pero lo importante es ver que la Seguridad Informática ya no es un problema de la

3. Motivación para la realización de este trabajo

Este trabajo es la culminación de muchos años de estudio, en los que incursioné en

Durante los años transcurridos en la facultad, mi forma de pensar se fue modelando,

En el tiempo que llevo tratando clientes, observando distintas realidades, y

Es por eso que en este trabajo pretendo traducir el conocimiento en seguridad

Particularmente como alumna, el tema me fue atrapando luego de cursar la materia

En esa oportunidad la seguridad informática fue presentada con seriedad, aunque de

Un tiempo después descubrí de la existencia de la asignatura “Criptografía y

Pude cursarla efectivamente y aprobarla en el segundo cuatrimestre del año 2002, lo

Luego continué investigando sobre el tema, pero noté que la información se

Considero muy importante para la formación de los Ingenieros en Informática la

Cualquier profesional de esta carrera debería poseer un mínimo conocimiento sobre

En esta tesis se desarrollará una metodología de trabajo.

Se describirán las tareas y subtareas a realizar para obtener resultados específicos,

• Administración del proyecto:

• Vulnerabilidades conocidas en sistemas operativos y aplicaciones:

• Implantación de las soluciones en plataformas tecnológicas específicas:

No se entrará en detalle en configuraciones ni ejecución de procesos específicos

5. Organización del documento

El trabajo ha sido desarrollado en seis partes:

A su vez, la parte IV, Desarrollo de la Metodología AEI, está organizada en seis

1. Definición del Alcance.

1.1 El estudio del entorno.

En este primer grupo de fases se encuentran: