bisogno tesisdegradoingenieriainformatica

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: [email protected]; [email protected]

Tutor: Prof. Lic. Sergio Villagra

Co-tutores: Andrea Morales, Saverio Locane, y Héctor Dinamarca

12 de octubre de 2004

mailto:[email protected]

mailto:[email protected]

Metodología para el Aseguramiento de Entornos Informatizados.

MAEI - María Victoria Bisogno.

1

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



2

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



3

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



4

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



5

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



6

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.



7

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”.



8

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



9

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.



10

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.



11

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:



12

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.



13

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:



14

• 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:



15

Relevamiento

Definición del Alcance

Estabilización

ImplantaciónPlanificación

MantenimientoEntorno inseguro

Entorno protegido

Plan de aseguramiento

aprobado?

No

Sí

Estudio del Entorno

Implantación de la solución

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



16

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



17

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.



18

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.



19

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.



20

[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, usuarios

Relevamiento General

2.2 Elaboración del Relevamiento de Usuario ES Relevamiento de Usuario



21

FASE / ETAPA ACTOR ENTREGABLE

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 Operativos

Plan de Aseguramiento, Mapa de 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


ES Manual de Seguridad

4.3.1 Interiorización del experto con la política y negocio de la organización

cliente Organigrama, documentación del proceso comercial, etc.

4.3.2 Elaboración/adaptación de la Normativa de Seguridad

ES Manual de Seguridad

4.3.3 Aprobación de la Política de Seguridad


4.4.1 Implantación de una campaña de concientización

Comunicados, Presentaciones, 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



22

FASE / ETAPA ACTOR ENTREGABLE organización


Tabla de Criticidades por Equipo, 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



23

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.



24

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.



25

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




26

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:



27

• 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.



28

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.



29

• 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



30

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.



31

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.



32

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;



33

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;



34

• 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:



35

• 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.



36

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:



37

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.




38

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;



39

• 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

1 MAEI - Manual de Seguridad 10 días2 Sondeo en sede central 3 días3 Sondeo General 1 día4 Política general de seguridad 2 días5 Responsabilidades de seguridad 2 días6 Clasificación y tratamiento de la información 2 días7 Comunicaciones de redes de datos 2 días8 Administración de usuarios y recursos 2 días9 Protección ante virus informáticos 2 días10 Protección física 2 días11 Copiasde respaldo (backup) 2 días12 Ambientes de procesamiento 2 días13 Continuidad de procesamiento 2 días14 Generación de registros de eventos 2 días15 Sondeo en planta 1 día16 Revisión documentación 1 día17 Reunión de presentación con directores/gerente 1 día18 Análisis documentación con directores/gerentes 3 días19 Actualización de la documentación 3 días20 Generación versión final 1 día

M M J V S D L M M J V S D L M May '04 23 may '04 30 may '04



40

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



41

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);



42

• 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;



43

• 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:



44

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).



45

• 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;



46

• 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:



47

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.



48

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?

9 ¿Guarda la documentación impresa o magnética bajo llave común al sector?

10 ¿Maneja algún tipo de codificación para la rotulación de diskettes, cintas, 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?

16 ¿Trabaja con servidores de uso exclusivo de su sector o son compartidos por más de un sector ( por ejemplo Desarrollo y Prueba)?



49

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?

34 ¿Procesa información que es confidencial para gente del mismo 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.



50

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;



51

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?



52

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.



53

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?



54

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.



55

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:



56

• 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;



57

• 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.



58

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;



59

• 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.



60

• 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.



61

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;



62

• 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;



63

• 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.



64

• 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.



65

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;



66

• 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;

• 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;

• Que se encuentre implantado adecuadamente un ambiente general de control de 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



67

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;



68

• 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



69

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;



70

• 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.



71

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:



72

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;



73

• 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”:

A BM

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



74

1) Interrupción: Sucede cuando el destinatario nunca recibe el mensaje emitido por el origen:

A

B

M

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:

A

I

BM

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:

A

I

BM

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)



75

AM

I

BN

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):



76

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:



77

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.



78

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:



79

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:



80

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;



81

• 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:



82

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;



83

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).



84

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:



85

Alto

Alto Bajo

Mayor

importanciProbabilidadde ocurrencia

a

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;



86

• 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.



87

# VULNERABILIDAD RIESGO CRITICIDAD P(ocurrencia) IMPACTO

1

Existencia de material inflamable en el CPD

(Centro de Procesamiento de

Datos)

Fuego en el Data Center

2 0.5 Destrucción de equipos

y espacio físico

2

Existencia de material inflamable en el CPD y

en las oficinas aledañas

Fuego en lugares

cercanos 1 0.45

Destrucción de documentación

impresa y posibilidad de afección del centro

de cómputos

3 Ubicación física en

zona inundable Inundación 1 0.1 Posibles cortocircuitos,

equipos quemados, incendios

4

Falta de equipo de aire acondicionado de

backup

Fallas en el aire

acondicionado

2 0.4 Mal funcionamiento

por recalentamiento de equipos

5

Falta de mantenimiento de los

equipos de procesamiento de

datos.

Fallas en equipos

1 0.5 Indisponibilidad de los

servicios

6

Existencia de cables de red al descubierto atravesando los

pasillos

Fallas en comunicacio

nes 1 0.3

Indisponibilidad de los servicios

7

Descuido del cableado eléctrico, falta de

acondicionamiento de la central eléctrica y pobre aislamiento.

Corte de suministro eléctrico

1 0.6 Indisponibilidad de los servicios, pérdida de

datos.

8

Exposición de los equipos a personal no

autorizado. Acto de vandalismo

2 0.1

Pérdida de equipos, negación de servicios,

pérdida de información, mala

imagen en clientes, périda de confiabilidad.

9 Exposición de los

equipos a terceros. Acto de

sabotaje o robo

2 0.45 Pérdida de

confiabilidad, pérdida de información.

10

Administración de los equipos por personal

no especializado.

Errores humanos no intencionale

s

0 0.5 Indisponibilidad de los servicios, pérdida de

datos.

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.



88

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

0

0,5

1

0 0,5 1

Impacto

Pro

ba

bilid

ad

de

Ocu

rre

ncia Fuego en el CPD

Fuego en lugarescercanosInundación

Fallas en el aireacondicionadoFallas en equipos

Fallas en comunicaciones

Corte de suministroeléctricoActo de vandalismo

Acto de sabotaje o robo

Errores humanos nointencionales



89

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.



90

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



91

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;



92

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;



93

• 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



94

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.



95

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:



96

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;



97

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;



98

• 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;



99

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.



100

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.



101

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



102

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:



103

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.



104

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.



105

• 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:



106

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:



107

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:



108

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;



109

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);



110

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 DE SESIÓN

OTROS GRUPOS A LOS 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:



111

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:



112

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;



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$

Aciertos 28/11/2003 11:06:54 Security Inicio/cierre de sesión 538 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$

Aciertos 28/11/2003 11:05:49 Security Inicio/cierre de sesión 538 EMUI_18$ EMUI_18$

113



114

• 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;



115

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.



116

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

CÓDIGO

DESCRIPCIÓN

PERFILES AUTORIZADOS

USUARIOS

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:



117

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.



118

Documento de Actualización de Software

SOFTWARE

DESCRIPCIÓN

Fecha

Server1

Server2

Server...

CPU001

CPU002

CPU…

Antivirus

Sdat4299.exe

Actualización del antivirus

20/10 Ok Ok Ok Ok Ok Ok

Win2k

Kb823182

Hotfix para Windows 2000


Win2k

Kb824141



Win2k

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;



119

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



120


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;



121

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.



122

• 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:



123

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;



124

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;



125

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:



126

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;



127

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:



128

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;



129

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;



130

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.



131

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.



132

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.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.2 Capacitación de los usuarios



133


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

4.6.8.5 Formación del Equipo de Recuperación del Entorno ante Desastres (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



134

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:







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.



135

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;



136

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]



137

Estructura del Inventario de Activos

CÓDIGO

DESCRIP.

UBICACIÓN

RESP.

FECHA CREACIÓN

FECHA EXPIRACIÓN

CRI-TICI-DAD

ES-TA-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.



138

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:



139

• 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

CÓDIGO

DESCRIP.

UBICACIÓN

RESP.

FECHA CREACIÓN

FECHA EXPIRACIÓN

CRI-TICI-DAD

ES-TA-DO

HDW0001 Mouse serie Logitech

Piso 9, sector QA, cpu: HW0017

María Martinez

12/2001 - (011) A

--- --- --- --- --- --- --- …

HDW0034 Router Cisco 8000

Piso 7, sector comunicaciones

Manuel Belgrano

7/2003 - (021) A

--- --- --- --- --- --- --- …

--- --- --- --- --- --- --- …

--- --- --- --- --- --- --- …

Inventario de Activos Lógicos

CÓDIGO

DESCRIP.

UBICACIÓN

RESP.

FECHA CREACIÓN

FECHA EXPIRACIÓN

CRI-TICI-DAD

ES-TA-DO

BKP0102 Backup de Srv01/externo/proy5.mbd

HW0024 Juan Perez

20/05/2003 20/06/2003 (233) B

--- --- --- --- --- --- --- …

DAT0067 Notas de logística en formato .doc

CPU0002/d:/Logística/Notas/

María López

14/12/2002 14/12/2003 (121) A

--- --- --- --- --- --- --- …

BKP0106 Backup de Srv01/externo/proy5.mbd

HW0024 Juan Perez

20/06/2003 20/07/2003 (233) M

--- --- --- --- --- --- --- …



140

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.



141

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)



142

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.



143

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;



144

• 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




145

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.


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:

Política de Seguridad

Normas

General

Particular



146

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



147

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;



148

• 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.



149

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;



150

• 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



151

• 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;



152

• 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



153

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;



154

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



155

• 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.



156

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;



157

• 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.



158

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.


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



159

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.



160

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.



161

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.

4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres (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.



162

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;



163

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.



164

• 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.



165

4.6.3.1 Tabla de Criticidades por Equipo.

#

Equipo

Función

Sistema Operativo

Tolerancia Máxima

Impacto

4.6.3.2 Ejemplo - Tabla de Criticidades por Equipo.

#

Equipo

Función

Sistema Operativo

Tolerancia Máxima

Impacto

1 DBBA Bases de datos

Solares 9

1 día

Perdida de imagen pública

Reprocesamiento de formularios cargados manualmente

2 DBCH Bases de datos

Solares 9

1 semana

Pérdida / inconsistencia de información

3 DBCH2 Bases de datos

Solares 9

2 semanas

Pérdida / inconsistencia de información

4.6.3.3 Tabla de Criticidades por Servicios.

#

Servicio

Criticidad

Período crítico

Procedim.

Alternat.

Parada

Máxima

Plataf.

Usuarios



166

4.6.3.4 Ejemplo - Tabla de Criticidades por Servicios.

#

Servicio

Criticidad

Período crítico

Procedim.

Alternat.

Parada

Máxima

Plataf.

Usuarios

1 Servidor de Archivos

Media Cierre a fin de mes

Guardar los archivos en las PC locales

1 semana Novell Netware 5.0

Todos

2 Correo electrónico Lotus Domino Server

Alta Todos los días

Toma de pedidos telefónicos

1-2 días Windows 2000

Compras, ventas, despacho.



4.6.3.5 Tabla de Criticidades por Aplicaciones

# Aplicación Proveedor Plataforma Descripción Criticidad Período Crítico

Parada Máxima

Proced. Alternt

Interde-pendencias

Usuarios

4.6.3.6 Ejemplo - Tabla de Criticidades por Aplicaciones.

# Aplicación Proveedor Plataforma Descripción Criticidad Período Crítico

Parada Máxima

Proced. Alternt

Interde-pendencias

Usuarios

1 MANTEC Datastream Windows NTpara la

publicación de la

aplicación de la Base de

Datos Oracle.

Sistema de mantenimiento preventivo de maquinas.

Media Fin de mes 2 días --- Almacén, procesos,

Mantenimiento.

2 SUMTEC Datastream Windows NTpara la

publicación de la

aplicación.ón de la

aplicación.Base de Datos

Oracle.

Sistema de manejo de

repuestos de almacén.

Media 1 día Pedidos de respuestos manuales.

Almacén,procesos,

Mantenimiento.

167



168

• Ubicación geográfica;

o El lugar físico no pueda disponerse por un período máximo tolerado para la interrupción de las prestaciones mínimas.

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:

• 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:



169

• Parcial: En el caso en que:

4.6.6 Presentación de las distintas estrategias posibles de recuperación

4.6.8 Elaboración de la estrategia de recuperación

o El tiempo que demoran las tareas de reestablecimiento de todas o algunas de las prestaciones sea mayor al período máximo aceptable.

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.

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.

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;



170

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.

Lógicamente esta es una decisión empresarial, influenciada fuertemente por el presupuesto de la empresa y los límites de tiempo.

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:

• 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

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.

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.

• 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



171

Los documentos desarrollados establecen las condiciones de:

• Miembros del Equipo de Recuperación ante Desastres;

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.

• 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;

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.

4.6.8.5 Formación del Equipo de Recuperación del Entorno ante Desastres (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:



172

El Equipo de Recuperación del Entorno ante Desastres tiene las siguientes responsabilidades:

• Reestablecer las condiciones normales que se presentaban antes del desastre;

4.6.8.5.1 Roles y 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;

• 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:



173

EDEC

ERS

ECU ERC

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;



174


4.6.8.5.2 Asignación de roles

• 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.



175

• Contempla la aparición de imprevistos que puedan alterar o modificar el plan inicialmente armado;

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;


o Definición del plan de recuperación de las prestaciones;

o Ejecución del plan;

o Ajustes al plan.



176

• 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;

4.6.8.6.3 Reestablecimiento de las condiciones normales


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.



177

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



178

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.



179

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.

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.

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.



180

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.



181

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

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.

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.



182

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.

• Redes Virtuales (VPN);

• Plan de Recuperación del Entorno ante Desastres (PRED).

9. Formación en Seguridad

Administradores de Seguridad y nuevas responsabilidades.

8. Soluciones Tecnológicas:

• Firewalls;

• Antivirus;

• Sistemas de Detección de Intrusos;

• Sistemas de Backup;

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:

El rol de cada usuario.



183

6 MANTENIMIENTO

Contenido:

6.1.6 Recolección de incidencias

6.2.3 Formulario de Control de cambios

6.2.5 Ejemplo - AMB Activos

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.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.4 ABM Activos

6.2.6 Actualizaciones de Software

6.2.6.1 Documento de Actualizaciones de Software



184

6.1.1 Incidencias de seguridad

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.



185

• Aparición de datos no creados por el usuario.

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;

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.



186

8- El responsable informa al receptor-derivador (Help Desk) las medidas tomadas y las medidas a tomar por el usuario;

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;

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:



187

Denunciante(Usuario)


Receptor–Derivador (Help Desk o Atención al Cliente) Responsable

Denuncia incidente

Deriva denuncia de

incidente

Abre caso de Help Desk

Cierra caso de Help Desk

Informa cierre de caso exitoso

Resuelve el incidente

Informa solución del incidente y medidas a

tomar por el usuario

Analiza el incidente

Toma medidas para prevenir el incidente en

el futuro

Sí

No

Registra el incidente

Cierra caso de Help Desk

Informa cierre de caso

Se notifica del cierre del caso

y de las medidas a

tomar

Informa medidas

preventivas tomadas y acciones a

tomar por el usuario

Tiene solución?

Analiza el incidente

Toma medidas para prevenir el incidente en

el futuro

Incidente grave de

seguridad?

Sí

No

Se notifica del cierre del caso

y de las medidas a

tomar



188

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.

• Hora del incidente;

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;

• Nombre de la persona que reporta el incidente;

• Sector donde trabaja;

• Ubicación física;

• PC afectada por el incidente;



189

• Nombre del responsable;

• Activo (software o hardware) afectado con path completo y/o nombre de la aplicación;

• 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



190

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.



191

Fecha del incidente: Fecha en la que se produjo la incidencia.

Hora del incidente: Hora en la que se produjo la incidencia.

Nombre del denunciante: Nombre de la persona que reporta el incidente.

Archivos adjuntos: imágenes, logs, etc.

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.

Sector: Sector donde ocurrió el incidente.

Ubicación física: Lugar físico donde se produjo el incidente (piso, oficina, etc).

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.

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

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



192

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.



193

5- Afección de la confidencialidad de los datos;

7-Afección de soportes de información en papel;

E: Estado:

Formato del Registro de Incidencias

#

FECHA

SECTOR

NOMBRE DEL DENUNCIANTE

NOMBRE RESPONSABLE

T

DESCRIPCIÓN / MEDIDA TOMADA

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;

6- Virus Informático;

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;

I- En investigación;

P- Pendiente;

R- Resuelto.



194

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.



195

• Sistemas operativos de estaciones de trabajo;

• Sistemas aplicativos en general;

• Motores de base de datos;

• Sistemas de protección contra virus informáticos;

• Entre otros.

Este control tiene el fin de:

• Lograr una efectiva autorización de los cambios a implantar;

• Tener un registro documentado de los cambios;


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;

• Configuraciones de equipos;

• Aplicaciones de escritorio;

• Servicios de correo electrónico;

• Elementos de comunicaciones (routers, switches, etc,);

• Llevar un control de los cambios para evitar pérdidas o deterioros de información;

• 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.



196

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.



197

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:


o Planificar e implantar el cambio, y en caso de ser necesario realizar las pruebas adecuadas y las acciones necesarios 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 de los sistemas;

• Analista de aplicaciones:


o Planificar e implantar el cambio, y en caso de ser necesario realizar las pruebas adecuadas y las acciones necesarios 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 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.



Paso Objetivo Involucrados Resultado

Fase de Análisis

02

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.

Sistema donde se aplica el cambio.

Si se necesita o un la realización de una evaluación detallada.

Si afecta la funcionalidad de otros sistemas.

Fecha límite aceptable para la implantación de la solicitud.

Nombres y apellidos del solicitante.

Fomentar el análisis por parte del solicitante de los requerimientos

que realiza. Usuario solicitante

Documentación detallada del requerimiento de

cambio en el Formulario de Control de cambios

Descripción

01

Detecta la necesidad de realizar un cambio en la configuración de los sistemas con los que esta vinculado en la ejecución de su labor diaria.

Estos cambios pueden ser solicitados por cualquier persona que trabaja en la compañía.

Involucrar a las distintas personas en la identificación de cambios a

realizar en los sistemas. Usuario solicitante

198



03

Reciben la solicitud de cambio de configuración.

Analizan todos los elementos del entorno que podrían verse afectados por el cambio solicitado.

Una vez comprendidos todos los factores afectados por el cambio, se realiza una evaluación del posible impacto y la criticidad que tendrá el cambio solicitado.

Identificar la necesidad real del cambio y las implicancias en el

resto de los sistemas de la Compañía.

Comité de cambios (coordinación)

Administrador de la infraestructura técnica

(responsable)

Administrador de base de datos (responsable)

Analista de aplicaciones (responsable)

Oficial de Seguridad (implicado)

Registro de la solicitud en el Formulario de Control

de Cambios

Documentación técnica del cambio a realizar junto

con todos los sistemas afectados y el evaluación

del impacto

04

En función al análisis realizado se determinada si el cambio podrá ser aplicado o no.

Algunos de los motivos por los cuales no se aplicará un cambio solicitado son:

En caso que el cambio no se vaya a implantar, se continúa en el paso # 20.



(responsable)



Oficial De Seguridad (implicado)

Documentación con las conclusiones del análisis realizado

05

Identifican todas las actividades necesarias para realizar el cambio, entre las que se encuentran:

Identificación exacta de los cambios a realizar.

Identificación de los sectores involucrados en el cambio.

Identificación del momento más adecuado para realizar el cambio.



(responsable)



- No recomendado por el proveedor. - Costos no aceptados. - Alto impacto y muy pocos beneficios.

Determinar las tareas a realizar para realizar el requerimiento

Plan de implantación del cambio

199



06

Luego de la planificación de las actividades a realizar para implantar los cambios, se determina la necesidad de realizar pruebas previas en entornos no productivos antes de realizarlos en producción.

En caso de no ser necesarias las pruebas se continúa en el paso # 11.



(responsable)



Fase de Pruebas

07

Definen las pruebas unitarias e integrales que se deben realizar para garantizar que los cambios realizados sean los adecuados y no generen inconvenientes a los sistemas vigentes.

Planifican la realización de las pruebas identificadas.

Prever adecuadamente las actividades a realizar durante la

ejecución de las pruebas


(responsable)



Documentación con el detalle de las pruebas a

realizar junto su planificación

08 Ejecutan las pruebas según la planificación realizada oportunamente, identificando los problemas que se suscitan y las posibles causas.

Identificar los problemas que pueden ocasionar los cambios.


(responsable)



Documentación con el resultado de las pruebas

09 Si las pruebas no han sido satisfactorias, continúan en el paso # 20.


(responsable)



200



10

Otorgan la aceptación formal a la realización de los cambios planificados en el entorno de producción.

En caso de ser necesario modifican las especificaciones realizadas en la etapa de planificación.

Infundir la toma de responsabilidad en las decisiones

tomadas.



(responsable)



Documentación formal de la aceptación de la

implantación del cambio en producción

Fase de Implantación

11

Identifican todas las actividades necesarias para realizar el cambio y todas las precauciones a considerar antes de realizarlo a fin de poder volver atrás sin mayores inconvenientes.

Adicionalmente se planificará con todos los Administradores y Analistas involucrados el momento más adecuado de implantación.



(responsable)



Plan de implantación del cambio

12

Ejecutan todas las tareas identificadas en la planificación para realizar la vuelta atrás en las modificaciones de configuración en caso de existir algún inconveniente.

Concientizar a los administradores de la necesidad de contar con un plan de recuperación ante una

contingencia.


(responsable)



Documentación de las configuraciones anteriores

del entorno y documentación de las acciones para volver al

estado inicial.

Coordinar las tareas entre todas las áreas.

201



13 Si las tareas previas a la implantación del cambio en producción no se han podido realizar, no se realizará el cambio y se continúa en el paso # 20.


(responsable)



14 Ejecutan las tareas acordadas en la planificación, realizando previamente la notificación a los usuarios afectados en caso de ser necesario.

Implantar los cambios en producción.


(responsable)



Configuración implantada en producción

15 Si los cambios de configuración de los sistemas en producción han sido satisfactorios se continúa en el paso # 17.


(responsable)



16 Ejecutan todas las tareas planificadas para la vuelta a la configuración inicial de los sistemas, y continúan en el paso # 20.

Conservar el entorno productivo en caso de contingencia.


(responsable)



Documentación de las acciones de vuelta atrás

realizadas

202



17 Aceptan formalmente la implantación del cambio de configuración realizado.

Asegurarse de que los sistemas continúan funcionando

correctamente



Documentación formal de la aceptación de la solución realizada

18 Identifican y actualizan toda la documentación de los sistemas involucrados en el cambio de configuración.

Mantener vigente la documentación.


(responsable)



Documentación actualizada de las

configuración de los sistemas

19

Registran los cambios de configuración realizados en los sistemas, incluyendo:

Responsable del cambio

Impacto identificado

Fecha

Hora

Tipo de cambio

Criticidad

Identificar adecuadamente los cambios realizados en los

sistemas


(responsable)



Documentación actualizada de la

configuración realizada en los sistemas

20 Finalización del proceso.


(responsable)


203



204

6.2 2 Diagrama de flujo

Usuario Solicitante Analista de Aplicaciones

Administrador de Bases de Datos


Identifica necesidad de cambio en

configuración

Inicio

Administrador de la Infraestructura

TécnicaFase

An

álisis

Pru

ebas

Imp

lanta

ció

n

Comunica el cambio a realizar

Definen y planifican pruebas necesarias

Autorizan realización del cambio

No

Sí

Definen y planifican tareas para realizar el cambio

Actualizan documentación

Fin

Requiere pruebas?

Evalúan el impacto del cambio

Ejecutan tareas previas para permitir una vuelta atrás

Pruebas OK?

Implantan el cambio

Aceptan formalmente el cambio

Cambio OK?

Tareas previas OK?

Ejecutan tareas de vuelta atras

Ejecutan pruebas

No

Sí

No

Sí

No

Sí

No

Se aplicará el cambio?

Sí

Registran el cambio

Planifican el cambio

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

18

192

0



205

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:



206

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



207

7. AUTORIZACIONES ADICIONALES

_______________________ _________________________

Nombre Firma

_______________________ _________________________

Nombre Firma

8. CONFORMIDAD DEL SUPERVISOR DEL CPD

Observaciones:

Nombre Firma

_______________________ _________________________


NÚMERO: Número de requerimiento de cambios.

Nombre: Nombre del usuario solicitante.

Puesto: Posición que ocupa el usuario solicitante en la empresa.

FECHA: Fecha del requerimiento.

1. DATOS DEL USUARIO SOLICITANTE: Este bloque de datos corresponden a datos personales del usuario que realiza el requerimiento.

Departamento: Departamento o sector al que pertenece el usuario solicitante.



208

Ubicación (Ciudad/País): Ciudad o país donde trabaja el usuario solicitante, para el caso de empresas distribuídas territorialmente.

Teléfono: Interno o línea directa del solicitante.

2. DESCRIPCIÓN DEL CAMBIO: Este bloque corresponde a información sobre el cambio solicitado.

Menor (menor de 50 usuarios afectados)

3. SERVICIO(S) AFECTADO(s): Este bloque corresponde a información sobre el impacto del cambio solicitado.

Sede/Sucursal: Sede o sucursal de la empresa en la que trabaja el solicitante.

E-mail: Dirección de correo electrónico del usuario solicitante.

Tamaño: Tamaño del cambio medido en cantidad de 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.

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.



209

Observaciones: Aclaraciones.

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.

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.



210

[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”

• MODIFICACIÓN: Registrar cambios sobre un bien.

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.

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.

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;

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.

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

FECHA

CÓDIGO

ABM

CAUSA

ACTIVOS RELACIONADOS



211


ABM: En este campo se debe indicar el tipo de operación que se está registrando:

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.

• 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:

FECHA CÓDIGO

ABM

CAUSA

20/06/2003 BK0102 B Expiración de validez los datos. Unidad sobrescrita.

BK0174, HW0243

ACTIVOS RELACIONADOS

En el Inventario de Activos:

CÓDIGO DESCRIPCIÓN

UBICACIÓN

RESPONSABLE

FECHA EXPIRACIÓN

CRITI- CIDAD

HW0001 Mouse serie Piso 9, sector María Martinez 12/2001 A - 0

FECHA CREACIÓN

ES-TA-DO



212

Logitech QA, cpu: HW0017

--- --- --- --- --- --- --- …

HW0034 Router Cisco 8000 Piso 7, sector comunicaciones

Manuel Belgrano - 7/2003 2 A

--- --- --- … --- --- ---

BK0102 Backup de Srv01/externo/proy5.mbd

HW0024 B Juan Perez 20/05/2003 20/06/2003 2

--- --- --- --- --- --- --- …

BK0174 Backup de Srv01/externo/proy5.mbd

HW0024 Juan Perez 20/06/2003 20/07/2003 2 A

---

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.



213

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.



214

• Analizar las vulnerabilidades para determinar su riesgo;

• Analizar la forma de mitigar los riesgos;

• Confeccionar un Inventario de los Activos físicos y lógicos de la empresa para identificar y rotular cada uno de los bienes;

• Elaborar o adaptar para conveniencia de la empresa la Normativa de Seguridad que apoye los procesos del negocio;

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;

• Evaluar el impacto de los riesgos sobre el entrono, y sobre el negocio;

• 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;

• Clasificar la Información para determinar su criticidad;



215

• 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;

o Físico;

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;

• 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;

• 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 Lógico;



216

• Mapa de Elementos de Red: es una lista de los elementos físicos presentes en la red de datos;

• Documento de Actualización de software: Permite llevar un control de las actualizaciones aplicadas a los distintos equipos de la red;

• 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;

• 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 Usuarios: permite organizar los usuarios en grupos, y a su ver visualizar los distintos grupos a los que pertenece un usuario;

• 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;

• 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;



217

• Tabla de Criticidades por Aplicación: documento que sirve para establecer las criticidades de las aplicaciones del entorno;

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

• Reportes de Incidencias: documento que se utiliza para registrar las incidencias ocurridas en el entorno;

• 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;

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;

• 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 Recuperación de las Prestaciones: tareas a realizar una vez declarada la emergencia, para recuperar el funcionamiento en emergencia 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;

• 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;

• Registro de Incidencias: es un documento que recompila todas las incidencias ocurridas y las centraliza para su posterior análisis y estudio estadístico;

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



218

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.



219

•

•

• [isecom] ISECOM - Institute for security and Open Methodologies.

•

•

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

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.

http://www.hispasec.com/

http://iss.net/



220

o

•

o

•

o

•

o

.

• [10laws-MS] Microsoft Technet. The Ten Immutable Laws of Security. 2003

•

• [MMC] Conjunto de herramientas de configuración de seguridad de Microsoft-

MMC. 2003.

• [ISACA] ISACA (Information Systems Audit and Control Association).

o

•

o

•

o

http://xforce.iss.net/

[bsi] British Standards Online.

http://www.bsi-global.com/index.xalter

[Benson] Microsoft Solutions Framework. Estrategias de Seguridad. Christopher

Benson, Inobits Consulting (Pty) Ltd.

http://microsoft.com/latam/technet/articulos/200011/art04

[Consid-MS] Microsoft Solutions Framework. Consideraciones de seguridad para

la autoridad administrativa.

http://msn.com

o http://microsoft.com/technet/colums/security/assays/10imlaws.asp

[Technet] Microsoft Technet.

o http://microsoft.com/technet

o http://microsoft.com

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).

http://www.isaca.org

[AAW-ISI] “Auditoría de aplicaciones web”. Instituto Seguridad Internet (ISI).

http://www.instisec.com

http://microsoft.com/technet/colums/security/assays/10imlaws.asp

http://microsoft.com/



221

•

• [AACF-ROBOTA] “Auditoría de aplicaciones y Código fuente”. Robota.

[OSSTMM-ISECOM] “Open Source Security Testing Methodology Manual –

OSSTMM”. Pete Herzog. Isecom.

o http://www.isecom.org

o http://www.robota.net

mailto:[email protected]?subject=OSSTMM



222

1.1 Análisis de Requerimientos de Usuario.

1.3 Aprobación del Alcance.

1.5 Elaboración del Plan de Trabajo.

2 Relevamiento.

2.2 Elaboración del Relevamiento de Usuario.

2.4 Análisis de Riesgos.

3 Planificación .

3.2 Aprobación del Plan de Aseguramiento.

4 Implantación.

4.2 Clasificación de la Información.

4.4 Publicación de la Normativa de Seguridad.

4.6 Elaboración del Plan de Recuperación del Entorno ante Desastres (PRED).

5 Estabilización.

5.2 Ajuste.

5.4 Capacitación de usuarios.

6 Mantenimiento.

6.2 Control de cambios.

VII. ANEXO I. MAEI – RESUMEN DE FASES Y TAREAS

1 Definición del Alcance.

1.2 Elaboración del Alcance.

1.4 Estimación de tiempos y costos.

2.1 Elaboración del Relevamiento General.

2.3 Análisis de vulnerabilidades.

3.1 Elaboración del Plan de Aseguramiento.

4.1 Elaboración del Relevamiento de Activos.

4.3 Elaboración/ adaptación de la Normativa de Seguridad.

4.5 Implantación del Plan de Aseguramiento.

5.1 Análisis de resultados.

5.3 Cierre de la implantación.

6.1 Control de incidencias.



223

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



224

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”.

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”.

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



225

Los objetivos de “Administración de proyectos” fueron considerados para los controles a realizar a nivel de metodología de desarrollo de proyectos.

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 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”.



226

• 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



227

• 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.



228

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.



229

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.



230

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.



231

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.



232

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.



233

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.



234

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.

bisogno tesisdegradoingenieriainformatica

Documents