La implementación de medidas de seguridad, es un proceso Técnico-Administrativo. Como este proceso debe abarcar TODA la organización, sin exclusión alguna, ha de estar fuertemente apoyado por el sector gerencial, ya que sin ese apoyo, las medidas que se tomen no tendrán la fuerza necesaria.
Se deberá tener en cuenta que la implementación de Políticas de Seguridad, trae aparejados varios tipos de problemas que afectan el funcionamiento de la organización. La implementación de un sistema de seguridad conlleva a incrementar la complejidad en la operatoria de la organización. tanto técnica como administrativamente.
Por esto, será necesario sopesar cuidadosamente la ganancia en seguridad respecto de los costos administrativos y técnicos que se generen.
Es fundamental no dejar de lado la notificación a todos los involucrados en las nuevas disposiciones y, darlas a conocer al resto de la organización con el fin de otorgar visibilidad a los actos de la administración.
Una PSI informática deberá abarcar:
Alcance de la política, incluyendo sistemas y personal sobre el cual se aplica.
Objetivos de la política y descripción clara de los elementos involucrados en su definición.
Responsabilidad de cada uno de los servicios, recurso y responsables en todos los niveles de la organización.
Responsabilidades de los usuarios con respecto a la información que generan ya la que tienen acceso.
Requerimientos mínimos para la configuración de la seguridad de los sistemas al alcance de la política.
Definición de violaciones y las consecuencias del no cumplimiento de la política.
Por otra parte, la po1ítica debe especificar la autoridad que debe hacer que las cosas ocurran, el rango de los correctivos y sus actuaciones que permitan dar indicaciones sobre la clase de sanciones que se puedan imponer. Pero, no debe especificar con exactitud qué pasara o cuándo algo sucederá; ya que no es una sentencia obligatoria de ley.
Explicaciones comprensibles (libre de tecnicismos y términos legales pero sin sacrificar su precisión) sobre el porqué de las decisiones tomadas.
Finalmente, como documento dinámico de la organización, deben seguir un proceso de actualización periódica sujeto a los cambios organizacionales relevantes: crecimiento de la planta de personal, cambio en la infraestructura computacional, alta y rotación de personal, desarrollo de nuevos servicios, cambio o diversificación de negocios, etc.
Una proposición de una forma de realizar una PSI adecuada puede apreciarse en el siguiente diagrama:
Se comienza realizando una evaluación del factor humano, el medio en donde se desempeña, los mecanismos con los cuales se cuenta para llevar a cabo la tarea encomendada, las amenazas posibles y sus posibles consecuencias.
Luego de evaluar estos elementos y establecida la base del análisis, se originan un programa de seguridad, el plan de acción y las normas y procedimientos a llevar a cabo.
Para que todo lo anterior llegue a buen fin debe realizarse un control periódico de estas políticas, que asegure el fiel cumplimiento de todos los procedimientos enumerados. Para asegurar un marco efectivo se realiza una auditoría a los archivos Logs de estos controles.
Con el objeto de confirmar que todo lo creado funciona en un marco real, se realiza una simulación de eventos y acontecimientos que atenten contra la seguridad del sistema. Esta simulación y los casos reales registrados generan una realimentación y revisión que permiten adecuar las políticas generadas en primera instancia.
Por último el Plan de Contingencia es el encargado de suministrar el respaldo necesario en caso en que la política falle.
Es importante destacar que la Seguridad debe ser considerada desde la fase de diseño de un sistema. Si la seguridad es contemplada luego de la implementación del mismo, el personal se enfrentará con problemas técnicos, humanos y administrativos muchos mayores que implicaran mayores costos para lograr, en la mayoría de los casos, un menor grado de seguridad.
"Construya la seguridad desde el principio. La máxima de que es más caro añadir después de la implementación es cierta."
Julio C. Ardita menciona; "Muchas veces nos llaman cuando está todo listo, faltan dos semanas y quieren que lo aseguremos (…) llegamos, miramos y vemos que la seguridad es imposible de implementar. Últimamente nos llaman en el diseño y nosotros los orientamos y proponemos las soluciones que se pueden adoptar (.–)
5.3.2 AUDITORIA y CONTROL
Se considera que la Auditoría son los "ojos y oídos" de la dirección, que generalmente no puede, no sabe o no debe realizar las verificaciones y evaluaciones.
La Auditoría consiste en contar con los mecanismos para poder determinar qué es lo que sucede en el sistema, qué es lo que hace cada uno y cuando lo hace.
En cuanto al objetivo del Control es contrastar el resultado final obtenido contra el deseado a fin de incorporar las correcciones necesarias para alcanzarlo, o bien verificar la efectividad de lo obtenido.
5.3.3 PLAN DE CONTINGENCIA
Pese a todas las medidas de seguridad puede (va a) ocurrir un desastre. De hecho los expertos en seguridad afirman "sutilmente" que hay que definir un plan de recuperación de desastres "para cuando falle el sistema", no "por si falla el sistema".
Por tanto es necesario que el plan de contingencias que incluya un plan de recuperación de desastres, el cual tendrá como objetivo, restaurar el servicio de cómputo en forma rápida, eficiente y con el menor costo y perdidas posibles.
Si bien es cierto que se pueden presentar diferentes niveles de daños, también se hace necesario presuponer que el daño ha sido total, con la finalidad de tener un Plan de Contingencias lo mas completo y global posible.
Un Plan de Contingencia de Seguridad Informática consiste los pasos que se deben seguir, luego de un desastre, para recuperar, aunque sea en parte, la capacidad funcional del sistema aunque, y por lo general, constan de reemplazos de dichos sistemas.
Se entiende por Recuperación, "tanto la capacidad de seguir trabajando en un plazo mínimo después de que se haya producido el problema, como la posibilidad de volver a la
situación anterior al mismo, habiendo reemplazado o recuperado el máximo posible de los recursos e información".
Se dice que el Plan de Contingencias es el encargado de sostener el modelo de Seguridad Informática planteado y de levantarlo cuando se vea afectado.
La recuperación de la información se basa en el uso de una política de copias de seguridad (Backup) adecuada.
5.3.4 EQUIPOS DE RESPUESTA A INCIDENTES
Es aconsejable formar un equipo de respuesta a incidentes. Este equipo debe estar implicado en los trabajos proactivos del profesional de la seguridad. Entre éstos se incluyen:
El desarrollo de instrucciones para controlar incidentes.
Creación del sector o determinación del responsable: usualmente la designación del Administrador de seguridad.
La identificación de las herramientas de software para responder a ilícitos y eventos.
La investigación y desarrollo de otras herramientas de Segundad informática.
La realización de actividades formativas y de motivación.
La realización de investigaciones acerca de virus.
La ejecución de estudios relativos a ataques al sistema.
Estos trabajos proporcionarán los conocimientos que la organización puede utilizar y la información que hay que distribuir antes y durante los incidentes.
Una vez que el administrador de seguridad y el equipo de respuesta a incidentes han realizado estas funciones proactivas, el Administrador debe delegar la responsabilidad del control de incidentes a! equipo de respuesta. Esto no significa que el Administrador no deba seguir implicado o formar parte del equipo, sino que no tenga que estar siempre disponible, necesariamente, y que el quipo debe ser capaz de controlar los incidentes por sí mismos.
El equipo será el responsable de responder a incidentes como virus, gusanos o cualquier otro código dañino, invasión, engaños, y ataques del personal interno. El equipo también debe participar en el análisis de cualquier evento inusual que pueda estar implicado en la seguridad de los equipos o de la red.
5.3.5 BACKUPS
El Backup de archivos permite tener disponible e íntegra la información para cuando sucedan los accidentes. Sin un backup. simplemente. es imposible volver la información al estado anterior al desastre.
Como siempre, será necesario realizar un n análisis costo / beneficio para determinar qué información será almacenada, los espacios de almacenamiento destinados a tal fin, la forma de realización, las estaciones de trabajo que cubrirá el Backup, etc.
Para una conecta realización y seguridad de backups se deberán tener en cuenta estos puntos:
1. Se debe de contar con un procedimiento de respaldo de los sistemas operativos y de la información de los usuarios, para poder reinstalar fácilmente en caso de sufrir un accidente.
2. Se debe determinar el medio y las herramientas correctas para realizar las copias, basándose en análisis de espacios, tiempos de lectura /escritura, tipo de backup a realizar, etc.
3. El almacenamiento de los backups debe realizarse en locales diferentes de donde reside la información primaria. De este modo se evita la pérdida si el desastre alcanza todo el edificio o local.
4. Se debe verificar, periódicamente, la integridad de los respaldos que se están almacenando. No hay que esperar hasta el momento en que se necesitan para darse cuenta de que están incompletos, dañados, mal almacenados, etc.
5. Se debe de contar con un procedimiento para garantizar la integridad física de los respaldos, en previsión de robo o destrucción.
6. Se debe contar con una política para garantizar la privacidad de la información que se respalda en medios de almacenamiento secundarios. Por ejemplo, la información se debe encriptar antes de respaldarse.
7. Se debe de contar con un procedimiento para borrar físicamente la información de los medios de almacenamiento, antes de desecharlos.
8. Mantener equipos de hardware. de características similares a los utilizados para el proceso normal, en condiciones para comenzar a procesar en caso de desastres físicos. Puede optarse por:
a. Modalidad externa: otra organización tiene los equipos similares que brindan la seguridad de poder procesar la información, al ocurrir una contingencia, mientras se busca una solución definitiva al siniestro producido.
b. Modalidad Interna: se tiene más de un local, en donde uno es espejo del otro en cuanto a equipamiento, características técnicas y capacidades físicas. Ambos son susceptibles de ser usados como equipos de emergencia.
Se debe asegurar reproducir toda la información necesaria para la posterior recuperación sin pasos secundarios. Por ejemplo, existe información que es función de otra (checksums). Si sólo se almacenara la información principal, sin sus checksums, esto puede derivar en la inutilización de la misma cuando se recupere el backup.
5.3.6 PRUEBAS
El último elemento de las estrategias de seguridad, las pruebas y el estudio de sus resultados, se lleva a cabo después de que se han puesto en marcha las estrategias reactiva y proactiva. La realización de ataques simulados (Ethical Hacking) en sistemas de pruebas o en laboratorios permiten evaluar los lugares en los que hay puntos vulnerables y ajustar las directivas y los controles de seguridad en consecuencia.
Estas pruebas no se deben llevar a cabo en los sistemas de producción real, ya que el resultado puede ser desastroso. La carencia de laboratorios y equipos de pruebas a causa de restricciones presupuestarias puede imposibilitar la realización de ataques simulados. Para asegurar los fondos necesarios para las pruebas, es importante que los directivos sean conscientes del riesgo y consecuencias de los ataques, así como de las medidas de seguridad que se pueden adoptar para proteger al sistema, incluidos los procedimientos de las pruebas. Si es posible, se deben probar físicamente y documentar todos los casos de ataque para determinar las mejores directivas y controles de seguridad posibles que se van a implementar .
Determinados ataques, por ejemplo desastres naturales como inundaciones y rayos, no se pueden probar, aunque una simulación servirá de gran ayuda. Por ejemplo, se puede simular un incendio en la sala de servidores en el que todos los servidores hayan resultado dañados y hayan quedado inutilizables. Este caso puede ser útil para probar la respuesta de los administradores y del personal de seguridad, y para determinar el tiempo que se tardará en volver a poner la organización en funcionamiento.
La realización de pruebas y de ajustes en las directivas y controles de seguridad en función de los resultados de las pruebas es un proceso iterativo de aprendizaje. Nunca termina, ya que debe evaluarse y revisarse de forma periódica para poder implementar mejoras.
5.4 LA POLÍTICA
Después de nueve capítulos de detalles técnicos, legales, administrativos y humanos ha llegado la hora esperada por mí y espero por el lector. Las páginas que siguen tienen la intención de ofrecer un acercamiento a una metodología sistemática en la importante tarea de administrar la Seguridad Informática.
Como ya se ha mencionado, los fundamentos aquí expuestos NO deben ser tomados puntualmente en cada organización tratada. Deberán ser adaptados a la necesidad, requisitos y limitaciones de cada organización (o usuario individual) y, posteriormente requerirá actualizaciones periódicas asegurando el dinamismo sistemático ya mencionado.
5.4.1 NIVEL FÍSICO
El primer factor considerado, y el más evidente debe ser asegurar el sustrato físico del objeto a proteger. Es preciso establecer un perímetro de seguridad a proteger, y esta protección debe adecuarse a la importancia de lo protegido.
La defensa contra agentes nocivos conlleva tanto medidas proactivas (limitar el acceso) como normativas de contingencia ( que hacer en caso de incendio) o medidas de recuperación (realizar copias de seguridad). El grado de seguridad solicitado establecerá las necesidades: desde el evitar el café y el tabaco en las proximidades de equipos electrónicos, hasta el establecimiento de controles de acceso a la sala de equipos.
Lo mas importante es recordar que quien tiene acceso físico a un equipo tiene control absoluto del mismo. Por ello sólo deberían accederlo aquellas personas que sea estrictamente necesario.
5.4. 1. 1 AMENAZA NO INTENCIONADA (DESASTRE NATURAL)
El siguiente ejemplo ilustra una posible situación:
Una organización no cuenta con sistemas de detección y protección de incendios en la sala de servidores. El Administrador del sistema deja unos papeles sobre el aire acondicionado de la sala. Durante la noche el acondicionador se calienta y se inicia un incendio que arrasa con la sala de servidores y un par de despachos contiguos.
Directivas:
1. Predecir Ataque / riesgo: Incendio
2. Amenaza: Desastre natural. Incendio
3. Ataque: No existe
4. Estrategia Proactlva:
a. Predecir posibles daños: Pérdida de equipos e información
b. Determinar y minimizar vulnerabilidades: protección contra Incendios.
c. Evaluar planes de contingencia: backup de la información.
5. Estrategia Reactiva:
a. Evaluar daños: perdida de hardware e información.
b. Determinar su origen y repararlos: bloqueo del aire acondicionado.
c. Documentar y aprender
d. Implementar plan de contingencias: recuperar backups.
6. Examinar resultados V eficacia de la directiva: Ajustar la directiva con los nuevos conceptos incorporados.
5.4.2 NIVEL HUMANO
5.4.2.1.1 Amenaza no Intencionada (Empleado)
El siguiente ejemplo ilustra una posible situación de contingencia y el procedimiento a tener en cuenta:
Un empleado, no desea perder la información que ha guardado en su disco rígido, así que la copia (el disco completo) a su carpeta particular del servidor. que resulta ser también el servidor principal de aplicaciones de la organización. No se han definido cuotas de disco para las carpetas particulares de los usuarios que hay en el servidor. El disco rígido del usuario tiene 6 GB de información y el servidor tiene 6,5 GB de espacio libre. El servidor de aplicaciones deja de responder a las actualizaciones y peticiones porque se ha quedado sin espacio en el disco, El resultado es que se deniega a los usuarios los servicios del servidor de aplicaciones y la productividad se interrumpe.
A continuación se explica la metodología que se debería haber adoptado antes de que el usuario decida realizar su copia de seguridad.
Directivas:
1. Predecir Ataque / riesgo: Negación de servicios por abuso de recursos.
2. Amenaza: No existe. Empleado sin malas intenciones.
3. Ataque: No existe motivo ni herramienta, solo el desconocimiento por parte del usuario.
4. Estrategia proactiva:
a. Predecir posibles daños: perdida de productividad por espacio de disco / memoria agotados.
b. Determinar y minimizar vulnerabilidades: Implementar cuotas de discos.
c. Evaluar planes de contingencia: Servidor Backup.
d. Capacitar al usuario.
5. Estrategia Reactiva:
a. Evaluar daños: Perdida de producción.
b. Determinar su origen y repararlos. Hacer espacio de disco.
c. Documentar y aprender: Implementar plan de contingencias.
6. Examinar resultados y eficacia de la directiva: Ajustar la directiva con los nuevos conceptos incorporados.
5.4.2.1.2 Amenaza Malintencionada (Insider)
Una empresa competidora ofrece a un usuario cierta suma de dinero para obtener el diseño del último producto desarrollado por su empresa. Como este usuario carece de los permisos necesarios para obtener el diseño se hace pasar como administrador, y usando ingeniería social, consigue el nombre de usuario y password de un usuario con los permisos que el necesita.
La política de seguridad asociada a este evento debería haber contemplado:
Directivas:
1. Predecir Ataque / riesgo: Robo de información mediante el uso de ingeniería social.
2. Amenaza: Insider.
3. Ataque: Ingeniería social.
4. Estrategia proactiva:
a. Predecir posibles daños: Perdida de productividad y/o beneficios.
b. Determinar y minimizar vulnerabilidades: concientización de los usuarios.
c. Evaluar planes de contingencia.
5. Estrategia Reactiva:
a. Evaluar daños: Perdida de beneficios e información.
b. Determinar su origen: Revelación de login y password por parte del usuario.
c. Reparación de daños: Implementar entrenamiento de los usuarios.
d. Documentar y aprender.
e. Implementar plan de contingencia.
6. Examinar resultados y eficacia de la directiva: Ajustar la directiva con lol nuevos conceptos incorporados.
Autor:
Yessi
9 de Julio 14 -; Bº Centro – Tel.: (0351) 4239361 / 4247118.-
[1] HUERTA, Antonio Villalón. "Seguridad en Unix y Redes". Versión 1.2 Digltal -Open Publication License v.10 o later. 2 de Octubre de 2000. http://www.kriptopolis.com
[2] ALDEGANI, Gustavo. Miguel. Seguridad Informática. MP Ediciones. 1° Edición. Argentina. 1997. Página 30.
[3] http://www.nist.gov
[4] Orange Book. Department O( Defense. Llbrary N° S22S, 711. EEUU. 1985. http://www.doe.gov
[5] LIMA de la LUZ, Marla. Criminalia N° 1-6 Año L. Delitos Electrónicos. Ediciones Porrua. México. Enero-Julio 1984
[6] CARRION, Hugo Daniel: “Presupuestos para la Punibilidad del Hacking”
[7] ARDITA, Julio césar. Director de Cybsec S.A. Securtty System y ex-Hacker. Entrevista personal realizada el día 15 de enero de 2001 en instalaciones de Cybsec S.A. htt.o:.l.lwww.cybsec.com
[8] HOWARD, John D. Thesis: An Analysís of security on the Internet 1989-1995. Carnegie Instítute of TechnalaQY. CarneQíe Mellan University. 1995. EE.UU. http:/lwww.cert.arg. 2
[9] CERT: Computer Emergency RespOf1se Team. Grupo de Seguridad Internacional especializado en dar respuesta a las empresas V organizaciones que denuncian ataques informáticos a sus sistemas.
[10] Computers Chaos Club. http://www.ccc.de
| Página siguiente |