ENCRIPTADOS

C APTULO 9
Tesis "Seguridad Informtica: Sus

Implicancias e Implementacin".
Copyright Cristian F. Borghello 2001
webmaster@cfbsoft.com.ar
www.cfbsoft.com.ar
Cuando no ocurre nada, nos quejamos de lo mucho que gastamos en seguridad. Cuando algo sucede, nos
lamentamos de no haber invertido ms... Ms vale dedicar recursos a la seguridad que convertirse en una estadstica.
P OLTICAS DE
S EGURIDAD
Hoy es imposible hablar de un sistema cien por cien seguro, sencillamente porque el
costo de la seguridad total es muy alto. Por eso las empresas, en general, asumen riesgos:
deben optar entre perder un negocio o arriesgarse a ser hackeadas.
La cuestin es que, en algunas organizaciones puntuales, tener un sistema de seguridad
muy acotado les impedira hacer ms negocios. Si un Hacker quiere gastar cien mil dlares
en equipos para descifrar una encriptacin, lo puede hacer porque es imposible de controlarlo.
Y en tratar de evitarlo se podran gastar millones de dlares.
La solucin a medias, entonces, sera acotar todo el espectro de seguridad, en lo que
hace a plataformas, procedimientos y estrategias. De esta manera se puede controlar todo un
conjunto de vulnerabilidades, aunque no se logre la seguridad total. Y esto significa ni ms ni

menos que un gran avance con respecto a unos aos atrs.
Algunas organizaciones gubernamentales y no gubernamentales internacionales han
desarrollado documentos, directrices y recomendaciones que orientan en el uso adecuado de
las nuevas tecnologas para obtener el mayor provecho y evitar el uso indebido de la mismas,
lo cual puede ocasionar serios problemas en los bienes y servicios de las empresas en el
mundo.
En este sentido, las Polticas de Seguridad Informtica (PSI), surgen como una
herramienta organizacional para concientizar a cada uno de los miembros de una organizacin
sobre la importancia y sensibilidad de la informacin y servicios crticos. Estos permiten a la
compaa desarrollarse y mantenerse en su sector de negocios.
9.1 POLTICAS DE SEGURIDAD INFORMTICA

De acuerdo con lo anterior, el proponer o identificar una poltica de seguridad requiere
un alto compromiso con la organizacin, agudeza tcnica para establecer fallas y debilidades,
y constancia para renovar y actualizar dicha poltica en funcin del dinmico ambiente que
rodea las organizaciones modernas.
Est lejos de mi intencin (y del alcance del presente) proponer un documento
estableciendo lo que debe hacer un usuario o una organizacin para lograr la mayor Seguridad
Informtica posible. S est dentro de mis objetivos proponer los lineamientos generales que se
deben seguir para lograr (si as se pretendiese) un documento con estas caractersticas.
El presente es el resultado de la investigacin, pero sobre todo de mi experiencia
viendo como muchos documentos son ignorados por contener planes y polticas difciles de
lograr, o peor an, de entender.
Esto adquiere mayor importancia an cuando el tema abordado por estas polticas es la
Seguridad Informtica. Extensos manuales explicando como debe protegerse una computadora
o una red con un simple Firewall, un programa antivirus o un monitor de sucesos. Falacias
altamente remuneradas que ofrecen la mayor Proteccin = Aceite de Serpiente del mundo.
He intentado dejar en claro que la Seguridad Informtica no tiene una solucin
definitiva aqu y ahora, sino que es y ser (a mi entender) el resultado de la innovacin
tecnolgica, a la par del avance tecnolgico, por parte de aquellos que son los responsables de
nuestros sistemas.
En palabras de Julio C. Ardita: Una poltica de seguridad funciona muy bien en
EE.UU. pero cuando estos manuales se trajeron a Amrica Latina fue un fiasco... Armar una
poltica de procedimientos de seguridad en una empresa est costando entre 150350 mil
dlares y el resultado es ninguno... Es un manual que llevado a la implementacin nunca se
realiza... Es muy difcil armar algo global, por lo que siempre se trabaja en un plan de
seguridad real: las polticas y procedimientos por un lado y la parte fsica por otra.1

www.cfbsoft.com.ar
ARDITA, Julio Csar. Director de Cybsec S.A. Security System y exHacker. Entrevista personal realizada el
da 15 de enero de 2001 en instalaciones de Cybsec S.A. http://www.cybsec.com
Para continuar, har falta definir algunos conceptos aplicados en la definicin de una
PSI:
Decisin: eleccin de un curso de accin determinado entre varios posibles.
Plan: conjunto de decisiones que definen cursos de accin futuros y los medios para
conseguirlos. Consiste en disear un futuro deseado y la bsqueda del modo de conseguirlo.
Estrategia: conjunto de decisiones que se toman para determinar polticas, metas y
programas.
Poltica: definiciones establecidas por la direccin, que determina criterios generales a
adoptar en distintas funciones y actividades donde se conocen las alternativas ante
circunstancias repetidas.
Meta: objetivo cuantificado a valores predeterminados.
Procedimiento: Definicin detallada de pasos a ejecutar para desarrollar una actividad
determinada.
Norma: forma en que realiza un procedimiento o proceso.
Programa: Secuencia de acciones interrelacionadas y ordenadas en el tiempo que se
utilizan para coordinar y controlar operaciones.
Proyeccin: prediccin del comportamiento futuro, basndose en el pasado sin el
agregado de apreciaciones subjetivas.
Pronostico: prediccin del comportamiento futuro, con el agregado de hechos
concretos y conocidos que se prev influirn en los acontecimientos futuros.
Control: capacidad de ejercer o dirigir una influencia sobre una situacin dada o
hecho. Es una accin tomada para hacer un hecho conforme a un plan.2
Riesgo: proximidad o posibilidad de un dao, peligro. Cada uno de los imprevistos,
hechos desafortunados, etc., que puede tener un efecto adverso. Sinnimos: amenaza,
contingencia, emergencia, urgencia, apuro.
Ahora, una Poltica de Seguridad es un conjunto de requisitos definidos por los
responsables de un sistema, que indica en trminos generales que est y que no est permitido
en el rea de seguridad durante la operacin general del sistema.3
La RFC 1244 define Poltica de Seguridad como: una declaracin de intenciones de
alto nivel que cubre la seguridad de los sistemas informticos y que proporciona las bases para
definir y delimitar responsabilidades para las diversas actuaciones tcnicas y organizativas que
se requerirn.4
La poltica se refleja en una serie de normas, reglamentos y protocolos a seguir, donde
se definen las medidas a tomar para proteger la seguridad del sistema; pero... ante todo, (...)
una poltica de seguridad es una forma de comunicarse con los usuarios... Siempre hay que
tener en cuenta que la seguridad comienza y termina con personas.5 y debe:
www.cfbsoft.com.ar
2
3
4
5
FERNADEZ, Carlos M. Seguridad en sistemas informticos. Ediciones Daz de Santos S.A.. Espaa. 1988.
Pgina 105.
HUERTA, Antonio Villaln. Seguridad en Unix y redes. (Versin 1.2). Captulo 16Pgina 259
RFC 1244: Site Security Handbook. J. Reynolds P. Holbrook. Julio 1991
SPAFFORD, Gene. Manual de seguridad en redes. ArCERT. Argentina. 2000. http://www.arcert.gov.ar
Ser holstica (cubrir todos los aspectos relacionados con la misma). No tiene
sentido proteger el acceso con una puerta blindada si a esta no se la ha cerrado con
llave.
Adecuarse a las necesidades y recursos. No tiene sentido adquirir una caja fuerte
para proteger un lpiz.
Ser atemporal. El tiempo en el que se aplica no debe influir en su eficacia y
eficiencia.
Definir estrategias y criterios generales a adoptar en distintas funciones y
actividades, donde se conocen las alternativas ante circunstancias repetidas.
Cualquier poltica de seguridad ha de contemplar los elementos claves de seguridad ya

mencionados: la Integridad, Disponibilidad, Privacidad y, adicionalmente, Control,
Autenticidad y Utilidad.
No debe tratarse de una descripcin tcnica de mecanismos de seguridad, ni de una
expresin legal que involucre sanciones a conductas de los empleados. Es ms bien una
descripcin de los que deseamos proteger y el porqu de ello.
9.2 EVALUACIN DE RIESGOS

www.cfbsoft.com.ar
El anlisis de riesgos supone ms que el hecho de calcular la posibilidad de que

ocurran cosas negativas.
Se debe poder obtener una evaluacin econmica del impacto de estos sucesos.
Este valor se podr utilizar para contrastar el costo de la proteccin de la
informacin en anlisis, versus el costo de volverla a producir (reproducir).
Se debe tener en cuenta la probabilidad que sucedan cada uno de los problemas
posibles. De esta forma se pueden priorizar los problemas y su coste potencial
desarrollando un plan de accin adecuado.
Se debe conocer qu se quiere proteger, dnde y cmo, asegurando que con los
costos en los que se incurren se obtengan beneficios efectivos. Para esto se deber
identificar los recursos (hardware, software, informacin, personal, accesorios,
etc.) con que se cuenta y las amenazas a las que se est expuesto.
La evaluacin de riesgos y presentacin de respuestas debe prepararse de forma

personalizada para cada organizacin; pero se puede presupone algunas preguntas que ayudan
en la identificacin de lo anteriormente expuesto6:
Qu puede ir mal?
Con qu frecuencia puede ocurrir?
Cules seran sus consecuencias?
Qu fiabilidad tienen las respuestas a las tres primeras preguntas?
Se est preparado para abrir las puertas del negocio sin sistemas, por un da, una
semana, cuanto tiempo?
Cul es el costo de una hora sin procesar, un da, una semana...?

Cunto, tiempo se puede estar offline sin que los clientes se vayan a la
competencia?
Se tiene forma de detectar a un empleado deshonesto en el sistema?
Se tiene control sobre las operaciones de los distintos sistemas?
Cuantas personas dentro de la empresa, (sin considerar su honestidad), estn en
condiciones de inhibir el procesamiento de datos?
A que se llama informacin confidencial y/o sensitiva?
La informacin confidencial y sensitiva permanece as en los sistemas?
La seguridad actual cubre los tipos de ataques existentes y est preparada para
adecuarse a los avances tecnolgicos esperados?
A quien se le permite usar que recurso?
Quin es el propietario del recurso? y quin es el usuario con mayores
privilegios sobre ese recurso?
Cules sern los privilegios y responsabilidades del Administrador vs. la del
usuario?
Cmo se actuar si la seguridad es violada?
Una vez obtenida la lista de cada uno de los riesgos se efectuar un resumen del tipo:
Tipo de Riesgo
Robo de hardware
Factor
Alto
Robo de informacin
Alto
Vandalismo
Medio
Fallas en los equipos
Medio
Virus Informticos
Medio
Equivocaciones
Medio
Accesos no autorizados
Medio
Fraude
Bajo
Fuego
Muy Bajo
Terremotos
Muy Bajo
Tabla 9.1 Tipo de RiesgoFactor
Segn esta tabla habr que tomar las medidas pertinentes de seguridad para cada caso
en particular, cuidando incurrir en los costos necesarios segn el factor de riesgo representado.
9.2.1 N IVELES DE RIESGO

Como puede apreciarse en la Tabla 9.1, los riesgos se clasifican por su nivel de
importancia y por la severidad de su prdida:
1. Estimacin del riesgo de prdida del recurso (Ri)
2. Estimacin de la importancia del recurso (Ii)

www.cfbsoft.com.ar
Para la cuantificacin del riesgo de perder un recurso, es posible asignar un valor

numrico de 0 a 10, tanto a la importancia del recurso (10 es el recurso de mayor importancia)
como al riesgo de perderlo (10 es el riesgo ms alto).
5
El riesgo de un recurso ser el producto de su importancia por el riesgo de perderlo7:

WRi = Ri * I i
Luego, con la siguiente frmula es posible calcular el riesgo general de los recursos de
la red:
WR =
(WR1 * I1 + WR2 * I 2 + ... + WRn * I n )

I1 + I 2 + ... + I n
Otros factores que debe considerar para el anlisis de riesgo de un recurso de red son
su disponibilidad, su integridad y su carcter confidencial, los cuales pueden incorporarse a la
frmula para ser evaluados.
Ejemplo: el Administrador de una red ha estimado los siguientes riesgos y su
importancia para los elementos de la red que administra:
Recurso
Router
Riesgo (Ri)
Importancia (Ii)
Riesgo Evaluado (Ri*Ii)
42
Gateway
30
Servidor
10
10
100
18
PCs
Tabla 9.2 Valuacin de Riesgos
Aqu ya puede apreciarse que el recurso que ms debe protegerse es el servidor. Para la
obtencin del riesgo total de la red calculamos:
42 + 30 + 100 + 18
= 7,92
WR =
7 + 5 + 10 + 2
www.cfbsoft.com.ar
Al ver que el riesgo total de la red es de casi 8 puntos sobre 10 debera pensarse seriamente en buscar
las probables causas que pueden provocar problemas a los servicios brindados por los elementos
evaluados.
9.2.2 I DENTIFICACIN DE A MENAZA

Una vez conocidos los riesgos, los recursos que se deben proteger y como su dao o
falta pueden influir en la organizacin es necesario identificar cada una de las amenazas y
vulnerabilidades que pueden causar estas bajas en los recursos. Como ya se mencion existe
una relacin directa entre amenaza y vulnerabilidad a tal punto que si una no existe la otra
tampoco.
Se suele dividir las amenazas existentes segn su mbito de accin:
Desastre del entorno (Seguridad Fsica).

Amenazas del sistema (Seguridad Lgica).
Amenazas en la red (Comunicaciones).
Amenazas de personas (InsidersOutsiders).
Manual de seguridad en redes. ArCERT. Argentina. 2000. Pgina 31. http://www.arcert.gov.ar
Se debera disponer de una lista de amenazas (actualizadas) para ayudar a los

administradores de seguridad a identificar los distintos mtodos, herramientas y tcnicas de
ataque que se pueden utilizar. Es importante que los Administradores actualicen
constantemente sus conocimientos en esta rea, ya que los nuevos mtodos, herramientas y
tcnicas para sortear las medidas de seguridad evolucionan de forma continua.
En la siguiente seccin se explica una metodologa para definir una estrategia de
seguridad informtica que se puede utilizar para implementar directivas y controles de
seguridad con el objeto de aminorar los posibles ataques y amenazas. Los mtodos se pueden
utilizar en todos los tipos de ataques a sistemas, independientemente de que sean
intencionados, no intencionados o desastres naturales.
La metodologa se basa en los distintos ejemplos (uno para cada tipo de amenaza) y
contempla como hubiera ayudado una poltica de seguridad en caso de haber existido.
9.2.3 E VALUACIN DE C OSTOS

Desde un punto de vista oficial, el desafo de responder la pregunta del valor de la
informacin ha sido siempre difcil, y ms difcil an hacer estos costos justificables,
siguiendo el principio que si desea justificarlo, debe darle un valor8.
Establecer el valor de los datos es algo totalmente relativo, pues la informacin
constituye un recurso que, en muchos casos, no se valora adecuadamente debido a su
intangibilidad, cosa que no ocurre con los equipos, la documentacin o las aplicaciones.
Adems, las medidas de seguridad no influyen en la productividad del sistema por lo
que las organizaciones son reticentes a dedicar recursos a esta tarea. Por eso es importante
entender que los esfuerzos invertidos en la seguridad son costeables.
La evaluacin de costos ms ampliamente aceptada consiste en cuantificar los daos
que cada posible vulnerabilidad puede causar teniendo en cuenta las posibilidades. Un
planteamiento posible para desarrollar esta poltica es el anlisis de lo siguiente:
Qu recursos se quieren proteger?

De qu personas necesita proteger los recursos?
Copyright
Cristian F. Borghello 2001
Qu tan reales son las amenazas?
www.cfbsoft.com.ar
Qu tan importante es el recurso?
Qu medidas se pueden implantar para proteger sus bienes de una manera
econmica y oportuna?
Con esas sencillas preguntas (ms la evaluacin de riesgo) se debera conocer cules
recursos vale la pena (y justifican su costo) proteger, y entender que algunos son ms
importantes que otros.
El objetivo que se persigue es lograr que un ataque a los bienes sea ms costoso que su
valor, invirtiendo menos de lo que vale. Para esto se define tres costos fundamentales:
STRASSMANN, Paul A. El arte de presupuestar: como justificar los fondos para Seguridad Informtica.
http://www.nextvision.com
CP: Valor de los bienes y recursos protegidos.

CR: Costo de los medios necesarios para romper las medidas de seguridad
establecidas.
CS: Costo de las medidas de seguridad.
Para que la poltica de seguridad sea lgica y consistente se debe cumplir que:
CR > CP: o sea que un ataque para obtener los bienes debe ser ms costoso que el
valor de los mismos. Los beneficios obtenidos de romper las medidas de seguridad
no deben compensar el costo de desarrollo del ataque.
CP > CS: o sea que el costo de los bienes protegidos debe ser mayor que el costo
de la proteccin.
Luego, CR > CP > CS y lo que se busca es:
Minimizar el costo de la proteccin mantenindolo por debajo del de los bienes

protegidos9. Si proteger los bienes es ms caro de lo que valen (el lpiz dentro de
la caja fuerte), entonces resulta ms conveniente obtenerlos de nuevo en vez de
protegerlo.
Maximizar el costo de los ataques mantenindolo por encima del de los bienes
protegidos10. Si atacar el bien es ms caro de lo que valen, al atacante le conviene
ms obtenerlo de otra forma menos costosa.
Se debe tratar de valorar los costos en que se puede incurrir en el peor de los casos
contrastando con el costo de las medidas de seguridad adoptadas. Se debe poner especial
nfasis en esta etapa para no incurrir en el error de no considerar costos, muchas veces, ocultos
y no obvios (costos derivados).
9.2.3.1 V A L O R I N T R N S E C O

www.cfbsoft.com.ar
Es el ms fcil de calcular (pero no fcil) ya que solo consiste en otorgar un valor a la

informacin contestando preguntas como las mencionadas y examinando minuciosamente
todos los componentes a proteger.
9.2.3.2 C O S T O S D E R I V A D O S D E L A P E R D I D A
Una vez ms deben abarcarse todas las posibilidades, intentando descubrir todos los
valores derivados de la prdida de algn componente del sistema. Muchas veces se trata del
valor aadido que gana un atacante y la repercusin de esa ganancia para el entorno, adems
del costo del elemento perdido. Deben considerarse elementos como:
Informacin aparentemente inocua como datos personales, que pueden permitir a
alguien suplantar identidades.
POYATO, CheloCOLL, FranciscoMORENO David. Definicin de una poltica de seguridad. Espaa. 2000.
http://www.rediris.es/cert
10
Datos confidenciales de acuerdos y contratos que un atacante podra usar para su

beneficio.
Tiempos necesarios para obtener ciertos bienes. Un atacante podra acceder a ellos
para ahorrarse el costo (y tiempo) necesario para su desarrollo.
9.2.3.3 P U N T O D E E Q U I L I B R I O
Una vez evaluados los riesgos y los costos en los que se est dispuesto a incurrir y
decidido el nivel de seguridad a adoptar, podr obtenerse un punto de equilibrio entres estas
magnitudes:

www.cfbsoft.com.ar
Grfico 9.1 Punto de equilibrio Costo/Seguridad
Como puede apreciarse los riesgos disminuyen al aumentar la seguridad (y los costos
en los que incurre) pero como ya se sabe los costos tendern al infinito sin lograr el 100% de
seguridad y por supuesto nunca se lograr no correr algn tipo de riesgo. Lo importante es
lograr conocer cuan seguro se estar conociendo los costos y los riesgos que se corren (Punto
de Equilibrio).
9.3 ESTRATEGIA DE SEGURIDAD

Para establecer una estrategia adecuada es conveniente pensar una poltica de
proteccin en los distintos niveles que esta debe abarcar y que no son ni mas ni menos que los
estudiados hasta aqu: Fsica, Lgica, Humana y la interaccin que existe entre estos factores.
En cada caso considerado, el plan de seguridad debe incluir una estrategia Proactiva y
otra Reactiva11.
La Estrategia Proactiva (proteger y proceder) o de previsin de ataques es un
conjunto de pasos que ayuda a reducir al mnimo la cantidad de puntos vulnerables existentes
11
BENSON, Christopher. Estrategias de Seguridad. Inobis

http://www.microsoft.com/latam/technet/articulos/200011
Consulting
Pty
Ltd.
Microsoft
Solutions.
en las directivas de seguridad y a desarrollar planes de contingencia. La determinacin del

dao que un ataque va a provocar en un sistema y las debilidades y puntos vulnerables
explotados durante este ataque ayudar a desarrollar esta estrategia.
La Estrategia Reactiva (perseguir y procesar) o estrategia posterior al ataque ayuda al
personal de seguridad a evaluar el dao que ha causado el ataque, a repararlo o a implementar
el plan de contingencia desarrollado en la estrategia Proactiva, a documentar y aprender de la
experiencia, y a conseguir que las funciones comerciales se normalicen lo antes posible.
Con respecto a la postura que puede adoptarse ante los recursos compartidos:
Lo que no se permite expresamente est prohibido: significa que la

organizacin proporciona una serie de servicios bien determinados y
documentados, y cualquier otra cosa est prohibida.
Lo que no se prohbe expresamente est permitido: significa que, a menos que
se indique expresamente que cierto servicio no est disponible, todos los dems s
lo estarn.
Estas posturas constituyen la base de todas las dems polticas de seguridad y regulan
los procedimientos puestos en marcha para implementarlas. Se dirigen a describir qu
acciones se toleran y cules no.
Actualmente, y gracias a las, cada da ms repetitivas y eficaces, acciones que
atentan contra los sistemas informticos los expertos se inclinan por recomendar la primera
poltica mencionada.
9.3.1 I MPLEMENTACIN

www.cfbsoft.com.ar
La implementacin de medidas de seguridad, es un proceso TcnicoAdministrativo.

Como este proceso debe abarcar TODA la organizacin, sin exclusin alguna, ha de estar
fuertemente apoyado por el sector gerencial, ya que sin ese apoyo, las medidas que se tomen
no tendrn la fuerza necesaria.
Se deber tener en cuenta que la implementacin de Polticas de Seguridad, trae
aparejados varios tipos de problemas que afectan el funcionamiento de la organizacin. La
implementacin de un sistema de seguridad conlleva a incrementar la complejidad en la
operatoria de la organizacin, tanto tcnica como administrativamente.
Por esto, ser necesario sopesar cuidadosamente la ganancia en seguridad respecto de
los costos administrativos y tcnicos que se generen.
Es fundamental no dejar de lado la notificacin a todos los involucrados en las nuevas
disposiciones y, darlas a conocer al resto de la organizacin con el fin de otorgar visibilidad a
los actos de la administracin.
Una PSI informtica deber abarcar:
Alcance de la poltica, incluyendo sistemas y personal sobre el cual se aplica.

Objetivos de la poltica y descripcin clara de los elementos involucrados en su
definicin.
10
Responsabilidad de cada uno de los servicios, recurso y responsables en todos los

niveles de la organizacin.
Responsabilidades de los usuarios con respecto a la informacin que generan y a la
que tienen acceso.
Requerimientos mnimos para la configuracin de la seguridad de los sistemas al
alcance de la poltica.
Definicin de violaciones y las consecuencias del no cumplimiento de la poltica.
Por otra parte, la poltica 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 cundo algo suceder; ya que no es una
sentencia obligatoria de la ley.
Explicaciones comprensibles (libre de tecnicismos y trminos legales pero sin
sacrificar su precisin) sobre el porque de las decisiones tomadas.
Finalmente, como documento dinmico de la organizacin, deben seguir un
proceso de actualizacin peridica sujeto a los cambios organizacionales
relevantes: crecimiento de la planta de personal, cambio en la infraestructura
computacional, alta y rotacin de personal, desarrollo de nuevos servicios, cambio
o diversificacin de negocios, etc.
Una proposicin de una forma de realizar una PSI adecuada puede apreciarse en el
siguiente diagrama:
11

www.cfbsoft.com.ar
Grfico 9.2 Fuente: Manual de Seguridad en Redes. http://www.arcert.gov.ar
Se comienza realizando una evaluacin del factor humano, el medio en donde se

desempea, 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 anlisis, se originan un
programa de seguridad, el plan de accin y las normas y procedimientos a llevar a cabo.
Para que todo lo anterior llegue a buen fin debe realizarse un control peridico de estas
polticas, que asegure el fiel cumplimiento de todos los procedimientos enumerados. Para
asegurar un marco efectivo se realiza una auditora a los archivos Logs de estos controles.
Con el objeto de confirmar que todo lo creado funciona en un marco real, se realiza
una simulacin de eventos y acontecimientos que atenten contra la seguridad del sistema. Esta
simulacin y los casos reales registrados generan una realimentacin y revisin que permiten
adecuar las polticas generadas en primera instancia.
Por ltimo el Plan de Contingencia es el encargado de suministrar el respaldo necesario
en caso en que la poltica falle.
Es importante destacar que la Seguridad debe ser considerada desde la fase de diseo
de un sistema. Si la seguridad es contemplada luego de la implementacin del mismo, el
personal se enfrentar con problemas tcnicos, humanos y administrativos muchos mayores
12
que implicaran mayores costos para lograr, en la mayora de los casos, un menor grado de
seguridad.
Construya la seguridad desde el principio. La mxima de que es ms caro aadir
despus de la implementacin es cierta.12
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 diseo y nosotros los orientamos y
proponemos las soluciones que se pueden adoptar (...)13
Queda claro que este proceso es dinmico y continuo, sobre el que hay que adecuarse
continuamente a fin de subsanar inmediatamente cualquier debilidad descubierta, con el fin de que
estas polticas no caigan en desuso.
9.3.2 A UDITORA Y C ONTROL

www.cfbsoft.com.ar
Se considera que la Auditora son los ojos y odos de la direccin, que generalmente
no puede, no sabe o no debe realizar las verificaciones y evaluaciones.
La Auditora 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.
9.3.3 P LAN DE C ONTINGENCIA

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 recuperacin de
desastres para cuando falle el sistema, no por si falla el sistema14.
Por tanto, es necesario que el Plan de Contingencias que incluya un plan de
recuperacin de desastres, el cual tendr como objetivo, restaurar el servicio de cmputo en
forma rpida, eficiente y con el menor costo y prdidas posibles.
Si bien es cierto que se pueden presentar diferentes niveles de daos, tambin se hace
necesario presuponer que el dao ha sido total, con la finalidad de tener un Plan de
Contingencias lo ms completo y global posible.
Un Plan de Contingencia de Seguridad Informtica 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.
12
13
14
Encuesta de Seguridad Informtica 2001. Marzo de 2001. Ernst & Young. http://www.ey.com
ARDITA, Julio Csar. Director de Cybsec S.A. Security System y exHacker. Entrevista personal realizada el
da 15 de enero de 2001 en instalaciones de Cybsec S.A. http://www.cybsec.com
POYATO, Chelo. COLL, Francisco. MORENO, David. Recomendaciones de Seguridad. Definicin de una Poltica
de Seguridad. http://www.rediris.es/cert
13
Se entiende por Recuperacin, tanto la capacidad de seguir trabajando en un plazo

mnimo despus de que se haya producido el problema, como la posibilidad de volver a la
situacin anterior al mismo, habiendo reemplazado o recuperado el mximo posible de los
recursos e informacin15.
Se dice que el Plan de Contingencias es el encargado de sostener el modelo de
Seguridad Informtica planteado y de levantarlo cuando se vea afectado.
La recuperacin de la informacin se basa en el uso de una poltica de copias de
seguridad (Backup) adecuada.
9.3.4 E QUIPOS DE R ESPUESTA A I NCIDENTES

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.

Creacin del sector o determinacin del responsable: usualmente la designacin del
Administrador de seguridad.
La identificacin de las herramientas de software para responder a incidentes y
eventos.
La investigacin y desarrollo de otras herramientas de Seguridad Informtica.
La realizacin de actividades formativas y de motivacin.
La realizacin de investigaciones acerca de virus.
www.cfbsoft.com.ar
La ejecucin de estudios relativos a ataques al sistema.
Estos trabajos proporcionarn los conocimientos que la organizacin puede utilizar y la

informacin 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 al 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 equipo debe ser capaz de controlar los incidentes por s mismo.
El equipo ser el responsable de responder a incidentes como virus, gusanos o
cualquier otro cdigo daino, invasin, engaos, y ataques del personal interno. El equipo
tambin debe participar en el anlisis de cualquier evento inusual que pueda estar implicado en
la seguridad de los equipos o de la red.
15
POYATO, Chelo. COLL, Francisco. MORENO, David. Recomendaciones de Seguridad. Definicin de una Poltica
de Seguridad. http://www.rediris.es/cert
14
9.3.5 B ACKUPS
El Backup de archivos permite tener disponible e ntegra la informacin para cuando
sucedan los accidentes. Sin un backup, simplemente, es imposible volver la informacin al
estado anterior al desastre.
Como siempre, ser necesario realizar un anlisis Costo/Beneficio para determinar qu
informacin ser almacenada, los espacios de almacenamiento destinados a tal fin, la forma de
realizacin, las estaciones de trabajo que cubrir el backup, etc.
Para una correcta realizacin y seguridad de backups se debern tener en cuenta estos
puntos:
1. Se debe de contar con un procedimiento de respaldo de los sistemas operativos y de
la informacin de los usuarios, para poder reinstalar fcilmente en caso de sufrir un
accidente.
2. Se debe determinar el medio y las herramientas correctas para realizar las copias,
basndose en anlisis 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 informacin primaria. De este modo se evita la prdida si el desastre
alcanza todo el edificio o local.
4. Se debe verificar, peridicamente, la integridad de los respaldos que se estn
almacenando. No hay que esperar hasta el momento en que se necesitan para darse
cuenta de que estn incompletos, daados, mal almacenados, etc.
5. Se debe de contar con un procedimiento para garantizar la integridad fsica de los
respaldos, en previsin de robo o destruccin.
6. Se debe contar con una poltica para garantizar la privacidad de la informacin que
se respalda en medios de almacenamiento secundarios. Por ejemplo, la informacin
se debe encriptar antes de respaldarse.
7. Se debe de contar con un procedimiento para borrar fsicamente la informacin de
los medios de almacenamiento, antes de desecharlos.
8. Mantener equipos de hardware, de caractersticas similares a los utilizados para el
proceso normal, en condiciones para comenzar a procesar en caso de desastres
fsicos. Puede optarse por:

www.cfbsoft.com.ar
Modalidad Externa: otra organizacin tiene los equipos similares que brindan
la seguridad de poder procesar la informacin, al ocurrir una contingencia,
mientras se busca una solucin definitiva al siniestro producido.
Modalidad Interna: se tiene ms de un local, en donde uno es espejo del otro
en cuanto a equipamiento, caractersticas tcnicas y capacidades fsicas. Ambos
son susceptibles de ser usados como equipos de emergencia.
Se debe asegurar reproducir toda la informacin necesaria para la posterior

recuperacin sin pasos secundarios. Por ejemplo, existe informacin que es funcin de otra
(checksums). Si slo se almacenara la informacin principal, sin sus checksums, esto puede
derivar en la inutilizacin de la misma cuando se recupere el backup.
15
9.3.6 P RUEBAS
El ltimo elemento de las estrategias de seguridad, las pruebas y el estudio de sus
resultados, se lleva a cabo despus de que se han puesto en marcha las estrategias reactiva y
proactiva. La realizacin 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 produccin real, ya que el
resultado puede ser desastroso. La carencia de laboratorios y equipos de pruebas a causa de
restricciones presupuestarias puede imposibilitar la realizacin de ataques simulados. Para
asegurar los fondos necesarios para las pruebas, es importante que los directivos sean
conscientes de los riesgos 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 fsicamente 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 simulacin servir de gran ayuda. Por ejemplo, se puede simular
un incendio en la sala de servidores en el que todos los servidores hayan resultado daados 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 organizacin en funcionamiento.
La realizacin de pruebas y de ajustes en las directivas y controles de seguridad en
funcin de los resultados de las pruebas es un proceso iterativo de aprendizaje. Nunca termina,
ya que debe evaluarse y revisarse de forma peridica para poder implementar mejoras.
www.cfbsoft.com.ar
9.4 LA POLTICA
Despus de nueve captulos de detalles tcnicos, legales, administrativos y humanos ha

llegado la hora esperada por m y espero por el lector. Las pginas que siguen tienen la
intencin de ofrecer un acercamiento a una metodologa sistemtica en la importante tarea de
administrar la Seguridad Informtica.
Como ya se ha mencionado, los fundamentos aqu expuestos NO deben ser tomados
puntualmente en cada organizacin tratada. Debern ser adaptados a la necesidad, requisitos y
limitaciones de cada organizacin (o usuario individual) y, posteriormente requerir
actualizaciones peridicas asegurando el dinamismo sistemtico ya mencionado.
9.4.1 N IVEL F SICO

El primer factor considerado, y el ms evidente debe ser asegurar el sustrato fsico del
objeto a proteger. Es preciso establecer un permetro de seguridad a proteger, y esta proteccin
debe adecuarse a la importancia de lo protegido.
16
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 recuperacin
(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 electrnicos, hasta el
establecimiento de controles de acceso a la sala de equipos.
Lo ms importante es recordar que quien tiene acceso fsico a un equipo tiene control
absoluto del mismo. Por ello slo deberan accederlo aquellas personas que sea estrictamente
necesario.
9.4.1.1 A M E N A Z A N O I N T E N C I O N A D A (D E S A S T R E
NATURAL)
El siguiente ejemplo ilustra una posible situacin:
Una organizacin no cuenta con sistemas de deteccin y proteccin 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.
2.
3.
4.
5.
6.
Predecir Ataque/Riesgo: Incendio

Amenaza: Desastre natural. Incendio
www.cfbsoft.com.ar
Ataque: No existe.
Estrategia Proactiva:
a. Predecir posibles daos: prdida de equipos e informacin.
b. Determinar y minimizar vulnerabilidades: proteccin contra incendios.
c. Evaluar planes de contingencia: backup de la informacin.
Estrategia Reactiva:
a. Evaluar daos: perdida de hardware e informacin.
b. Determinar su origen y repararlos: bloqueo del aire acondicionado.
c. Documentar y aprender
d. Implementar plan de contingencia: recuperar backups.
Examinar resultados y eficacia de la directiva: Ajustar la directiva con los nuevos conceptos
incorporados.
9.4.2 N IVEL H UMANO

9.4.2.1 E L U S U A R I O
Estas son algunos de las consideraciones que se deberan tener en cuenta para la
proteccin de la informacin:
1. Quizs el usuario contempla todas las noticias de seguridad con escepticismo,
piensan que los Administradores son paranoicos y se aprovechan de las contadas
situaciones dadas. Quizs tengan razn, pero se debe recordar que el mundo virtual
no es ms que una pequea muestra del mundo fsico, con el agregado que es el
campo ideal de impunidad y anonimicidad.
17
2. Generalmente se considera que la propia mquina es poco importante para que un

atacante la tenga en cuenta. Se debera recordar que este atacante no sabe quien
est del otro lado del monitor, por lo que cualquier objetivo (en principio) es tan
importante (o no) como cualquier otro.
Ejemplo: Se instal un Firewall personal en dos usuarios normales de Internet, utilizando modems
y Windows 98 como sistema operativo. Los resultados obtenidos en los archivos de Logs de estos
usuarios fueron los siguientes:
Usuario 1 ubicado en Paran (Entre RosArgentina): 49 scaneos de puertos y 14 intentos de
instalacin de troyanos en 10 das.
Usuario 2 ubicado en Buenos Aires (Argentina): 28 scaneos de puertos en 8 das.
La pregunta ya no es ser atacado?; a cambiando a cundo ser atacado?.

3. Generalmente se sobrevalora la capacidad de un atacante. Al contrario de la
creencia popular no se necesita ser un Gur para ingresar en una computadora y
generalmente quienes lo hace son ScriptKiddies en busca de diversin. De
hecho un Gur siempre tendr mejores cosas que hacer.
4. Convencerse de que TODOS los programas existentes tienen vulnerabilidades
conocidas y desconocidas es muy bueno. Esta idea permite no sobrevalorar la
seguridad de su sistema.
Ejemplo: Un usuario dice a otro: Yo utilizo Linux porque es ms seguro que Windows. Esto es
una falacia disfrazada: el usuario debera decir que Linux PUEDE ser ms seguro que Windows. De
hecho cualquier sistema bien configurado puede ser ms seguro que uno que no lo est.
5. La Regla de Oro que todo usuario debe tomar como obligacin (y su

responsabilidad) es tomar la seguridad de su computadora en serio. Recordar que
el eslabn ms dbil de una cadena equivale a la resistencia de la misma es muy
bueno en este momento.
www.cfbsoft.com.ar
Ningn usuario inocente estar contento si su nombre aparece en la lista de posibles
intruso en una red, nada ms que porque alguien decidi utilizarlo para tales fines. Tampoco
es bueno ser acusado de expandir un virus por el simple hecho de enviar mails sin
comprobarlos anteriormente.
Los procedimientos simples mencionados pueden evitar grandes dolores de cabezas.
9.4.2.1.1 Amenaza no Intencionada (Empleado)

El siguiente ejemplo ilustra una posible situacin de contingencia y el procedimiento a
tener en cuenta:
Un empleado, no desea perder la informacin que ha guardado en su disco rgido, as
que la copia (el disco completo) a su carpeta particular del servidor, que resulta ser tambin el
servidor principal de aplicaciones de la organizacin. No se han definido cuotas de disco para
las carpetas particulares de los usuarios que hay en el servidor. El disco rgido del usuario
tiene 6 GB de informacin 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.
18
A continuacin, se explica la metodologa que se debera haber adoptado antes de que

el usuario decida realizar su copia de seguridad:
Directivas:
1.
2.
3.
4.
5.
6.
Predecir Ataque/Riesgo: Negacin de servicios por abuso de recursos.

Amenaza: No existe. Empleado sin malas intenciones.
Ataque: No existe motivo ni herramienta, solo el desconocimiento por parte del usuario.
a. Predecir posibles daos: prdida 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 el usuario.
www.cfbsoft.com.ar
a. Evaluar daos: prdida de produccin.
b. Determinar su origen y repararlos: hacer espacio en el disco.
c. Documentar y aprender: implementar plan de contingencia.
incorporados.
9.4.2.1.2 Amenaza Malintencionada (Insider)

Una empresa competidora ofrece a un usuario cierta suma de dinero para obtener el
diseo del ltimo producto desarrollado por su empresa. Como este usuario carece de los
permisos necesarios para obtener el diseo se hace pasar como un Administrador, y usando
ingeniera social, consigue el nombre de usuario y password de un usuario con los permisos
que l necesita.
La poltica de seguridad asociada a este evento debera haber contemplado:
Directivas:
1.
2.
3.
4.
5.
6.
Predecir Ataque/Riesgo: Robo de informacin mediante el uso de ingeniera social.

Amenaza: Insider.
Ataque: Ingeniera social.
a. Predecir posibles daos: prdida de productividad y/o beneficios.
b. Determinar y minimizar vulnerabilidades: concientizacin de los usuarios.
c. Evaluar planes de contingencia.
a. Evaluar daos: prdida de beneficios e informacin.
b. Determinar su origen: revelacin de login y password por parte el usuario.
c. Reparacin de daos: implementar entrenamiento de los usuarios.
d. Documentar y aprender.
e. Implementar plan de contingencia.
incorporados.
9.4.1.2 P E R S O N A S A J E N A S A L S I S T E M A
9.4.1.2.1 Amenaza No Intencionada
Un virus ingresa a la empresa mediante un mail enviado a un empleado, y comienza a
expandirse dentro de la misma tomando como base la libreta de direcciones de los usuarios:
19
Directivas:
1.
2.
3.
4.
5.
6.
Predecir Ataque/Riesgo: Negacin de servicio del servidor de correo electrnico por gran la
cantidad de mensajes enviados/recibidos.
Amenaza: Virus.
Ataque: Virus de correo electrnico.
a. Predecir posibles daos: prdida de productividad por negacin de servicio.
b. Determinar y minimizar vulnerabilidades: actualizacin de antivirus y concientizacin de
usuarios en el manejo del correo electrnico.
c. Evaluar planes de contingencia: evaluar la importancia de un servidor backup. Antivirus.
a. Evaluar daos: prdida de produccin.
b. Determinar su origen: cada del servidor por overflow de mensajes.
c. Reparacin de daos: implementar el servidor backup. Eliminacin del virus causante del
problema.
d. Documentar y aprender.
e. Implementar plan de contingencia: servidor backup.
incorporados.
9.4.1.2.2 Amenaza Malintencionada (OutSider)

Una persona ingresa al sistema de la empresa, con intenciones de recopilar informacin
para su posterior venta:
Directivas:
7.
Predecir Ataque/Riesgo: Ingreso al sistema por vulnerabilidades en los sistemas o poltica de

claves ineficiente.
8. Amenaza: Outsider recopilando informacin significativa.
9. Ataque: Ingreso al sistema.
www.cfbsoft.com.ar
10. Estrategia Proactiva:
a. Predecir posibles daos: Robo y venta de informacin. Dao a la imgen de la empresa.
b. Determinar y minimizar vulnerabilidades: actualizacin de sistemas vulnerables.
Concientizacin a los usuarios en el manejo de contraseas fuertes.
c. Evaluar planes de contingencia: implementacin de servidor backup para casos de dao de la
informacin. Recuperacin de imagen. Evaluar formas de minimizar el dao por la informacin
robada.
11. Estrategia Reactiva:
f.
Evaluar daos: informacin susceptible robada.
g. Determinar su origen: ingreso al sistema.
h. Reparacin de daos.
i.
Documentar y aprender.
j.
Implementar plan de contingencia: servidor backup.
12. Examinar resultados y eficacia de la directiva: Ajustar la directiva con los nuevos conceptos
incorporados.
20
POLTICAS DE SEGURIDAD ................................................................1

9.1 POLTICAS DE SEGURIDAD INFORMTICA ...........................2
9.2 EVALUACIN DE RIESGOS...........................................................4
9.2.1 NIVELES DE RIESGO .............................................................................................5
9.2.2 IDENTIFICACIN DE AMENAZA ............................................................................6
9.2.3 EVALUACIN DE COSTOS.....................................................................................7
9.2.3.1 Valor Intrnseco ...........................................................................................8
9.2.3.2 Costos Derivados de la Perdida ..................................................................8
9.2.3.3 Punto de Equilibrio......................................................................................9
9.3 ESTRATEGIA DE SEGURIDAD......................................................9

9.3.1 IMPLEMENTACIN..............................................................................................10
9.3.2 AUDITORA Y CONTROL .....................................................................................13
9.3.3 PLAN DE CONTINGENCIA ...................................................................................13
9.3.4 EQUIPOS DE RESPUESTA A INCIDENTES..............................................................14
9.3.5 BACKUPS ...........................................................................................................15
9.3.6 PRUEBAS ............................................................................................................16
9.4 LA POLTICA ...................................................................................16

9.4.1 NIVEL FSICO .....................................................................................................16
9.4.1.1 Amenaza no Intencionada (Desastre Natural) ..........................................17
9.4.2 NIVEL HUMANO.................................................................................................17
9.4.2.1 El Usuario..................................................................................................17
9.4.1.2 Personas Ajenas al Sistema .......................................................................19
21

ENCRIPTADOS

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ENCRIPTADOS

Загружено:

Авторское право:

Доступные форматы

C APTULO 9

Tesis "Seguridad Informtica: Sus

conjunto de vulnerabilidades, aunque no se logre la seguridad total. Y esto significa ni ms ni

9.1 POLTICAS DE SEGURIDAD INFORMTICA

Tesis "Seguridad Informtica: Sus

Cualquier poltica de seguridad ha de contemplar los elementos claves de seguridad ya

9.2 EVALUACIN DE RIESGOS

Tesis "Seguridad Informtica: Sus

El anlisis de riesgos supone ms que el hecho de calcular la posibilidad de que

La evaluacin de riesgos y presentacin de respuestas debe prepararse de forma

RFC 1244: Site Security Handbook. J. Reynolds P. Holbrook. Julio 1991

Cul es el costo de una hora sin procesar, un da, una semana...?

Fallas en los equipos

Tabla 9.1 Tipo de RiesgoFactor

9.2.1 N IVELES DE RIESGO

Tesis "Seguridad Informtica: Sus

Para la cuantificacin del riesgo de perder un recurso, es posible asignar un valor

El riesgo de un recurso ser el producto de su importancia por el riesgo de perderlo7:

(WR1 * I1 + WR2 * I 2 + ... + WRn * I n )

Riesgo Evaluado (Ri*Ii)

Tabla 9.2 Valuacin de Riesgos

9.2.2 I DENTIFICACIN DE A MENAZA

Desastre del entorno (Seguridad Fsica).

Manual de seguridad en redes. ArCERT. Argentina. 2000. Pgina 31. http://www.arcert.gov.ar

Se debera disponer de una lista de amenazas (actualizadas) para ayudar a los

9.2.3 E VALUACIN DE C OSTOS

Qu recursos se quieren proteger?

CP: Valor de los bienes y recursos protegidos.

Luego, CR > CP > CS y lo que se busca es:

Minimizar el costo de la proteccin mantenindolo por debajo del de los bienes

Tesis "Seguridad Informtica: Sus

Es el ms fcil de calcular (pero no fcil) ya que solo consiste en otorgar un valor a la

Datos confidenciales de acuerdos y contratos que un atacante podra usar para su

Tesis "Seguridad Informtica: Sus

Grfico 9.1 Punto de equilibrio Costo/Seguridad

9.3 ESTRATEGIA DE SEGURIDAD

BENSON, Christopher. Estrategias de Seguridad. Inobis

en las directivas de seguridad y a desarrollar planes de contingencia. La determinacin del

Lo que no se permite expresamente est prohibido: significa que la

Tesis "Seguridad Informtica: Sus

La implementacin de medidas de seguridad, es un proceso TcnicoAdministrativo.

Alcance de la poltica, incluyendo sistemas y personal sobre el cual se aplica.

Responsabilidad de cada uno de los servicios, recurso y responsables en todos los

Tesis "Seguridad Informtica: Sus

Grfico 9.2 Fuente: Manual de Seguridad en Redes. http://www.arcert.gov.ar

Se comienza realizando una evaluacin del factor humano, el medio en donde se

9.3.2 A UDITORA Y C ONTROL

Tesis "Seguridad Informtica: Sus

9.3.3 P LAN DE C ONTINGENCIA

Se entiende por Recuperacin, tanto la capacidad de seguir trabajando en un plazo

9.3.4 E QUIPOS DE R ESPUESTA A I NCIDENTES

El desarrollo de instrucciones para controlar incidentes.

Estos trabajos proporcionarn los conocimientos que la organizacin puede utilizar y la

Tesis "Seguridad Informtica: Sus

Se debe asegurar reproducir toda la informacin necesaria para la posterior

Despus de nueve captulos de detalles tcnicos, legales, administrativos y humanos ha

9.4.1 N IVEL F SICO

Tesis "Seguridad Informtica: Sus

Predecir Ataque/Riesgo: Incendio

9.4.2 N IVEL H UMANO

2. Generalmente se considera que la propia mquina es poco importante para que un

La pregunta ya no es ser atacado?; a cambiando a cundo ser atacado?.

5. La Regla de Oro que todo usuario debe tomar como obligacin (y su

9.4.2.1.1 Amenaza no Intencionada (Empleado)