Estas posturas constituyen la base de todas las
demás políticas de seguridad y regulan los
procedimientos puestos en marcha para implementarlas. Se dirigen
a describir qué acciones se toleran y cuáles
no.
Actualmente, y "gracias" a las, cada dia mas repetitivas
y eficaces , acciones que atentan contra los sistemas
informáticos los expertos se inclinan por recomendar la
primera política mencionada.
5.3.1 IMPLEMENTACIÓN
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:
Incendio2. Amenaza: Desastre natural.
Incendio3. Ataque: No existe
4. Estrategia Proactlva:
a. Predecir posibles daños:
Pérdida de equipos e informaciónb. 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:
Yesssi
9 de Julio 14 – Bº Centro –
–
CARRERA: Analista de Sistemas de
Computación
CATEDRA: Seguridad e Integridad de
Sistemas
PROFESOR: An. Gabriel Medina
[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 anterior | Volver al principio del trabajo | Página siguiente  |