Nombre del estudiante: Gerardo Flores Plata 010004194

Sal Carmona Escobar 010003900

Juan Carlos Baez Carreo 010003447
Brenda A. Riou Barrales 01234541
Nuez Rodriguez Octavio 010014442

Carrera: Licenciatura en Sistemas de Computacin Administrativa

Materia: SEMINARIO DE TEMAS CONTEMPORANEOS

No. de Reporte: 02 del segundo bloque

Fecha de entrega: 5 de diciembre del 2013

Campus: San Rafael

Cuatrimestre: 9no Cuatrimestre

Nombre del maestro: Valdemar Franco Zertuche

Universidad del Valle de Mxico Campus San Rafael Pgina 1

ndice Pag

C3.1 Mantenimiento de la integridad de los sistemas

C3.1 Determinar planes de contingencia1

C3.2 Definir Polticas de seguridad.2

C3.3 Aplicar Auditora Informtica3

C3.4 Conclusiones4

C3.5 Bibliografa..5

Universidad del Valle de Mxico Campus San Rafael Pgina 2

C3.1 Mantenimiento de la integridad de los sistemas

C3.1 Determinar planes de contingencia

Por qu se necesita un Plan de Contingencia?

A medida que las empresas se han vuelto cada vez ms dependientes de las computadoras y las redes para
manejar sus actividades, la disponibilidad de los sistemas informticos se ha vuelto crucial. Actualmente, la
mayora de las empresas necesitan un nivel alto de disponibilidad y algunas requieren incluso un nivel continuo
de disponibilidad, ya que les resultara extremadamente difcil funcionar sin los recursos informticos.

Los procedimientos manuales, si es que existen, slo seran prcticos por un corto periodo. En caso de un
desastre, la interrupcin prolongada de los servicios de computacin puede llevar a prdidas financieras
significativas, sobre todo si est implicada la responsabilidad de la gerencia de informtica. Lo ms grave es que
se puede perder la credibilidad del pblico o los clientes y, como consecuencia, la empresa puede terminar en
un fracaso total.

Cabe preguntarse "Por se necesita un plan de contingencia para desastres si existe una pliza de seguro para
esta eventualidad?" La respuesta es que si bien el seguro puede cubrir los costos materiales de los activos de
una organizacin en caso de una calamidad, no servir para recuperar el negocio. No ayudar a conservar a los
clientes y, en la mayora de los casos, no proporcionar fondos por adelantado para mantener funcionando el
negocio hasta que se haya recuperado.

En un estudio realizado por la Universidad de Minnesota, se ha demostrado que ms del 60% de las empresas
que sufren un desastre y que no tienen un plan de recuperacin ya en funcionamiento, saldrn del negocio en
dos o tres aos. Mientras vaya en aumento la dependencia de la disponibilidad de los recursos informticos,
este porcentaje seguramente crecer.

Por lo tanto, la capacidad para recuperarse exitosamente de los efectos de un desastre dentro de un periodo
predeterminado debe ser un elemento crucial en un plan estratgico de seguridad para una organizacin.

Imagnese una situacin que interrumpa las operaciones de las computadoras durante una semana o un mes;
imagine la prdida de todos los datos de la empresa, todas las unidades de respaldo del sitio y la destruccin
de equipos vitales del sistema Cmo se manejara semejante catstrofe? Si Ud. se ve en esta situacin y lo
nico que puede hacer es preguntarse "Y ahora qu?" ya es demasiado tarde! La nica manera efectiva de
afrontar un desastre es tener una solucin completa y totalmente probada para recuperarse de los efectos del
mismo.

Qu es un desastre?

Universidad del Valle de Mxico Campus San Rafael Pgina 3

Se puede considerar como un desastre la interrupcin prolongada de los recursos informticos y de
comunicacin de una organizacin, que no puede remediarse dentro de un periodo predeterminado aceptable
y que necesita el uso de un sitio o equipo alterno para su recuperacin.

Ejemplos obvios son los grandes incendios, las inundaciones, los terremotos, las explosiones, los actos de
sabotaje, etctera.

Estadsticas recientes sobre los tipos ms comunes de desastres que ocurren muestran que el terrorismo, los
incendios y los huracanes son las causas ms comunes en muchos pases.

La alta gerencia tiene que decidir el periodo predeterminado que lleva una interrupcin de servicio de la
situacin de "problema" a la de "desastre". La mayora de las organizaciones logran esto llevando a cabo un
anlisis de impacto en el negocio para determinar el mximo tiempo de interrupcin permisible en funciones
vitales de sus actividades.

Plan de contingencia

La reanudacin de las actividades ante una calamidad puede ser una de las situaciones ms difciles con las que
una organizacin deba enfrentarse. Tras un desastre, es probable que no haya posibilidades de regresar al lugar
de trabajo o que no se disponga de ninguna de los recursos acostumbrados. Incluso, es posible que no se pueda
contar con todo el personal. La preparacin es la clave del xito para enfrentar los problemas.

No existe ninguna manera costeable para protegerse completamente contra todo tipo de riesgos,
particularmente amenazas naturales a gran escala que pueden arrasar zonas extensas. Como consecuencia,
siempre se tiene que tolerar algn riesgo residual. La decisin sobre el alcance del desastre para el que habr
de prepararse debe tomarse en los ms altos niveles de la empresa. Por ejemplo, la mayor parte de las empresas
implementan una estrategia que proteja contra desastres locales, pero pocas cubren desastres a nivel nacional
o incluso internacional. Asimismo, las organizaciones que cuentan dos o ms sitios, pueden tener una estrategia
de recuperacin que funcione en caso de que un sitio sea destruido o daado, pero no si varios sitios son
destruidos o daados al mismo tiempo.

Un plan de contingencia es el proceso de determinar qu hacer si una catstrofe se abate sobre la empresa y
es necesario recuperar la red y los sistemas.

Desdichadamente, un plan de contingencia es como el ejercicio y la dieta: ms fcil pensar en ello que hacerlo.
Con la cantidad de trabajo que la mayora de los gerentes tienen, el plan de contingencia tiende a dejarse para
una ocasin posterior. Uno de los problemas asociados al plan de contingencia es saber por dnde empezar.

Con mucho gusto le puedo ayudar a planificar, disear e implementar una solucin de recuperacin de desastre
que cumpla con las necesidades de su empresa tan solo escrbame a c.victor[arroba]cantv.net.

Universidad del Valle de Mxico Campus San Rafael Pgina 4

METODOLOGA PARA EL PLAN DE CONTINGENCIA

El disear e implementar un plan de contingencia para recuperacin de desastres no es una tarea fcil; puede
implicar esfuerzos y gastos considerables, sobre todo si se est partiendo de cero. Una solucin comprende las
siguientes actividades:

Debe ser diseada y elaborada de acuerdo con las necesidades de la empresa.

Puede requerir la construccin o adaptacin de un sitio para los equipos computacionales.

Requerir del desarrollo y prueba de muchos procedimientos nuevos, y stos deben ser compatibles con las
operaciones existentes. Se har participar a personal de muchos departamentos diferentes, el cual debe
trabajar en conjunto cuando se desarrolle e implemente la solucin.

Implicar un compromiso entre costo, velocidad de recuperacin, medida de la recuperacin y alcance de los
desastres cubiertos. .

Como con cualquier proyecto de diseo, un mtodo estructurado ayuda a asegurar de que se toman en cuenta
todos estos factores y de que se les trata adecuadamente.

A continuacin se muestran las principales actividades requeridas para la planificacin e implementacin de

una capacidad de recuperacin de desastres.

Identificacin de riesgos

Evaluacin de riesgos

Asignacin de prioridades a las aplicaciones

Establecimiento de los requerimientos de recuperacin

Elaboracin de la documentacin

Verificacin e implementacin del plan

Distribucin y mantenimiento del plan

1. Identificacin de riesgos

La primera fase del plan de contingencia, el anlisis de riesgos, nos sita en el lugar de un asesor de una
compaa de seguros. En esta fase, la preocupacin est relacionada con tres simples preguntas: qu est bajo
riesgo?, qu puede ir mal? y cul es la probabilidad de que suceda?

1.1. Qu est bajo riesgo?

La primera de estas preguntas, qu est bajo riesgo?, necesita incorporar todos los componentes del sistema
susceptibles de ser daados, dando lugar a la prdida de conectividad, computadoras o datos. Un diagrama de
la arquitectura de todos los componentes del sistema facilitar la realizacin de un inventario de los elementos

Universidad del Valle de Mxico Campus San Rafael Pgina 5

que pueden necesitar ser restituidos tras un desastre. No hay que olvidar que tambin el software necesita ser
reemplazado, y que todos los productos software relevante han de ser identificados. Esto incluye cosas como
las utilidades del sistema de archivos empleados para facilitar las operaciones de red.

Un inventario completo de una red muestra de manera clara la complejidad de sta. Cualquiera que realice
inventarios de componentes para redes, comprende los problemas en el seguimiento del hardware y software
utilizado por los usuarios finales. Afortunadamente, existen algunos productos disponibles, como los de las
compaas Seagate Software, McAfee y otros, que facilitan la construccin de un inventario de los sistemas.

Una omisin en el inventario fcilmente puede dar lugar a una recuperacin fallida tras un desastre. El sistema
de aplicacin puede no encontrarse preparado para su uso si alguno de sus componentes no est disponible;
en tal caso, es aconsejable estar constantemente a la expectativa de los nuevos elementos que pueden haberse
olvidado. Por ejemplo, una aplicacin para acceso remoto no funcionara si los cables no estn disponibles para
conectar los mdem.

Uno de los aspectos menos agradables a tener en cuenta, y que a menudo se pasa por alto, es que las personas
esenciales se vean afectadas por el desastre y sea necesario recurrir a otras para realizar sus labores. Una
formacin diversificada en los sistemas dentro de la organizacin pude ayudar a reducir el impacto de la
indisponibilidad de uno de los colaboradores. Al menos, los manuales de las aplicaciones ms importantes para
la empresa deberan encontrarse disponibles en un sitio externo.

1.2. Qu puede ir mal?

Lo ms difcil en el plan de contingencia es responder a la pregunta, qu posiblemente pueda ir mal? La

respuesta a tal cuestin vara desde lo evidente hasta lo casi increble. La ley de Murphy nos proporciona una
coleccin de extraos e inesperados desastres. Por ejemplo, las inundaciones son bastante frecuentes, pero
pocos podan haber predicho la inundacin de un sistema de tneles del metro en la ciudad de Chicago, en
1992, provocada por la rotura de una tubera a raz de las obras de reparacin de un puente.

Las clases ms obvias de desastres son los desastres naturales que conllevan tormentas de todo tipo o los
acontecimientos geolgicos como terremotos o volcanes. En cada localidad existe la posibilidad de tener mal
tiempo. En los ltimos aos se han visto huracanes destrozar instalaciones a lo largo Florida, islas del Caribe y
el Golfo de Mxico. Los tornados y vientos de elevadas velocidades han destruido edificios cada ao en el
interior de los Estados Unidos y Canad.

Las inundaciones pueden acaecer en casi cualquier lugar donde el drenaje existente no sea capaz de absorber
el volumen de lluvia o fango. Relacionado con las inundaciones se encuentra el perjuicio producido por el agua.
Cada ao los incendios en los edificios provocan importantes daos a los sistemas informticos debido al agua,
cuando los sistemas automticos de irrigacin (sprinklers) se activan para apagar el fuego.

Los propios incendios constituyen uno de los peores desastres posibles. El calor, el humo y el agua que rodea a
los incendios son tremendamente perjudiciales para los sistemas informticos. Los dispositivos de
almacenamiento se deterioran fcilmente debido a las altas temperaturas y el humo. La eliminacin de los
residuos txicos tras el incendio de una oficina puede llevar meses, incluso aos. En los Estados Unidos, la
agencia de proteccin ambiental (EPA), en ocasiones, ha tenido que cerrar edificios despus de un incendio

Universidad del Valle de Mxico Campus San Rafael Pgina 6

debido a la alta concentracin de toxinas encontradas en el mismo. Esto implica que puede no ser posible
disponer de lo sistemas y datos hasta bastante tiempo despus del incendio. Existen compaa especializadas
en preparar operaciones especficas de limpieza de instalaciones vctimas del incendio, que darn su aprobacin
para enviar especialistas con trajes protectores al edificio incendiado, recuperar el equipo de procesamiento de
datos e intentar restaurar la informacin de los discos.

Deben considerarse mecanismos alternativos de acceso a la red en el caso de que, por alguna razn, sea
imposible acceder al edificio, incluso aunque el edificio puede estar en pie y operacional. Ejemplos de sucesos
que pueden impedir e acceso al interior del edificio son los accidentes qumicos e industriales, as como los
motines y disturbios callejeros.

El fuego no tiene por qu darse necesariamente en la propia instalacin para que el problema sea devastador.
Un incendio destruy la oficina central dc Ameritech, en Hinsdale, Illinois, en mayo de 1988, dejando a
numerosos clientes sin servicio telefnico durante meses mientras la compaa reparaba la edificacin daada.
Obviamente, las comunicaciones que empleaban las lneas telefnicas que haban sido enrutadas a travs de
esta instalacin, se vieron seriamente afectadas.

Desgraciadamente, los ataques terroristas y otros actos deliberados de destruccin cometidos por personas
pueden devastar sistemas e instalaciones. Este incluye actos violentos (por ejemplo, descargar armas sobre los
equipos informticos). Menos excitante, pero igual de perjudicial para la organizacin, es la prdida de equipos
debido al robo. Existen tambin ataques a los datos contra los que hay que estar prevenidos, en los que la gente
destruye intencionadamente datos mediante su borrado o inutilizndolos. Los virus se encuentran en este
campo.

Los errores humanos son una de las causas ms probables de la prdida o deterioro de los datos. Si un error de
este tipo provoca la prdida de un sistema en la red, tiene el mismo efecto que cualquier otro tipo de desastre,
y como tal debe ser tratado.

1.3. Cul es la probabilidad de que suceda?

Si se tuviera una cantidad ilimitada de recursos y fuera posible protegerse contra todas las calamidades, esta
pregunta carecera de inters. Sin embargo, no se dispone de recursos infinitos; de hecho, los recursos son
bastante escasos. Por lo tanto, se deben seleccionar los tipos de desastres contra los que uno intentar
protegerse. Obviamente, estos preciados recursos se querrn gastar en aquellos desastres que tengan la mayor
probabilidad de afectar a la organizacin.

Por ejemplo, se podra intentar proteger los sistemas de la improbable ocurrencia de la cada sobre el edifico
de un meteorito procedente del espacio exterior. Esto no sera tan valioso como proteger los sistemas de las
inundaciones.

Responder a la pregunta: cul es la probabilidad de que suceda? tambin requiere de ciertas consideraciones
presupuestarias. Ello puede ayudar a asumir distintos escenarios de presupuesto para comprender cules son
los costos de compromiso para diferentes niveles de proteccin y preparacin. Finalmente, se puede estar
expuesto a ciertas amenazas cuya proteccin no est al alcance del presupuesto, pero, al menos, se es
consciente de su existencia y, por lo tanto, es posible mejorar el plan en un futuro.

Universidad del Valle de Mxico Campus San Rafael Pgina 7

2. Evaluacin de riesgos

Es el proceso de determinar el costo para la organizacin de sufrir un desastre que afecte su actividad. Si una
inundacin impidiera la actividad comercial durante cinco das, la compaa perdera cinco das de ventas,
adems del deterioro fsico de los edificios e inventario. En el caso de los sistemas informticos, la preocupacin
principal es comprender la cantidad de prdida financiera que puede provocar la interrupcin de los servicios,
incluyendo los que se basan en las redes.

Por ejemplo, si la empresa se anuncia a travs o realiza negocios en Internet, cul es el costo de tener el
servidor web inhabilitado? Si la red a travs de la cual se produce la solicitud de pedidos est cada, o si el
sistema de control de inventario utiliza la red, cul es el impacto sobre la productividad de la empresa?

Los costos de un desastre pueden clasificarse en las siguientes categoras:

Costos reales de reemplazar el sistema informtico

Costos por falta de produccin.

Costos por negocio perdido

Costos de reputacin.

El costo real de los equipos y el software es fcil de calcular, y depende de si se dispone de un buen inventario
de todos los componentes de la red necesarios.

Los costos de produccin pueden determinarse midiendo la produccin generada asociada a la red. La empresa
tiene una correcta valoracin de la cantidad de trabajo realizado diariamente y su valor relativo. La prdida de
produccin, debida a la interrupcin de la red, puede ser calculados utilizando esta informacin.

Los costos por negocio perdido son los ingresos perdidos por las organizaciones de ventas y marketing cuando
la red no est disponible. Si el sistema de solicitud de pedidos no funciona y la empresa slo es capaz de procesar
el 25% del volumen diario habitual de ventas, entonces se ha perdido el 75% de ese volumen de ventas.

Los costos de reputacin son ms difciles de evaluar y, sin embargo, es conveniente incluirlos en la evaluacin.
Estos costos se producen cuando los clientes pierden la confianza en la empresa y se llevan su negocio a otro
sitio. Los costos de reputacin crecen cuando los retardos en el servicio a los clientes son ms prolongados o
frecuentes.

3. Asignacin de prioridades en las aplicaciones

Despus de que acontezca un desastre y se inicie la recuperacin de los sistemas, debe conocerse qu
aplicaciones recuperar en primer lugar. No hay que perder el tiempo restaurando los datos y sistemas
equivocados cuando la actividad empresarial necesita primero sus aplicaciones esenciales.

Esto implica la necesidad de determinar por anticipado cules son las aplicaciones fundamentales del negocio.
Si la empresa es como la mayora, se tendrn aplicaciones "muy importantes" dependiendo de a quin se le
pregunte. El departamento de recursos humanos afirmar que el sistema de nminas es el ms importante, el

Universidad del Valle de Mxico Campus San Rafael Pgina 8

departamento de ventas dir que es su sistema de entrada de pedidos, el departamento de produccin insistir
en su control de inventario y el departamento de compras asignar el papel de ms importante a su sistema de
facturacin. Desgraciadamente, no todos estos sistemas pueden ser el ms importante; por lo tanto, es
fundamental que la direccin ayude a determinar el orden en que los sistemas sern recuperados.

Es de esperar que esta informacin sea aceptada de buen grado por todos los jefes de departamento.
Independientemente de ello, el plan de contingencia debera incluir la lista de los sistemas y su prioridad. Esta
seccin del plan debera ser firmada por la direccin para minimizar las desavenencias.

Una vez conocido lo que se va a restaurar, debera disponerse de todo lo necesario para la disponibilidad de
tales aplicaciones. Un sistema de aplicacin en una red est compuesto por los sistemas servidores, donde las
aplicaciones almacenan sus datos, los sistemas de estaciones de trabajo que los procesan, las impresoras o fax
empleados para entrada/salida, la red que interconecta todo, y el software de las aplicaciones. Las aplicaciones
cliente/servidor o distribuidas aaden un nivel extra de complejidad al requerir que distintas partes de la
aplicacin residan en mquinas separadas.

Puede caerse en la tentacin de construir una infraestructura superior a la necesaria para la aplicaciones de
mayor prioridad. Por ejemplo, si actualmente la red tiene 50 estaciones de trabajo, se puede comenzar a
trabajar inmediatamente en la reconstruccin de las 50 estaciones de trabajo. Sin embargo, si las aplicaciones
ms prioritarias slo necesitan cinco estaciones de trabajo, se debera detener la reconstruccin de las
estaciones de trabajo una vez alcanzado el nmero de cinco y concentrar los esfuerzos en lograr que la
aplicacin funcione. Es mucho mejor intentar lograr que un sistema pequeo funcione, que no uno ms grande,
y de esta manera se ahorrar gran cantidad de tiempo en el proceso. De hecho, cuando se est asignando las
prioridades a las aplicaciones junto con la direccin, tambin es posible beneficiarse de la determinacin del
nmero mnimo de estaciones de trabajo necesarias para tener el sistema accesible. El tamao de la red siempre
puede incrementarse a posteriori una vez el sistema est en funcionamiento.

Una de las ventajas del enfoque basado en el sistema de aplicaciones es la cantidad de tiempo necesaria para
recuperar una aplicacin comparada con la cantidad de tiempo requerida para restaurar un servidor en su
totalidad. Si la aplicacin tiene slo 500 MB de datos y el servidor 4 GB, es obvio que se ahorra una gran cantidad
de tiempo recuperando nicamente la aplicacin.

Sin embargo este enfoque requiere un conocimiento algo ms detallado sobre los sistemas que actualmente se
tienen. En primer lugar, es necesario saber dnde se encuentra toda la informacin que emplean las
aplicaciones y qu dependencias entre sistemas de archivos pueden existir. Si existen archivos del sistema que
contienen informacin sobre la aplicacin, como es el caso de los archivos .ini de Windows, es necesario
asegurarse de que esos archivos tambin se recuperan junto a la aplicacin. En segundo lugar, es preciso
conocer cmo funciona el sistema de copias de seguridad para realizar este tipo de recuperacin selectiva.
Aunque esto no supone necesariamente una dificultad, no obstante esta operacin debera ser familiar.

4. Establecimiento de requisitos de recuperacin

La clave de esta fase del proceso de elaboracin del plan de migracin es definir un periodo de tiempo aceptable
y viable para lograr que la red est de nuevo activa. Tal y como se ha planteado en la seccin anterior, la

Universidad del Valle de Mxico Campus San Rafael Pgina 9

preocupacin bsica debera ser disponer de las aplicaciones ms importantes en primer lugar. El personal
directivo de la organizacin desear saber cundo estarn sus aplicaciones funcionado para planificar la
actividades de la compaa.

Es muy importante concederse una cantidad de tiempo adecuada y no realizar estimaciones poco realistas
sobre las propias posibilidades. No es el deseo de nadie tener a un montn de gente alrededor esperando la
finalizacin de las operaciones de recuperacin; una distraccin de este tipo probablemente perturbe las
labores. El trmino para este tiempo es tiempo de recuperacin objetivo o en ingls TRO (Recovery Time
Objective). El TRO definido debe ser verificado para comprobar que es realista y factible, no slo por uno mismo,
sino por el resto de la organizacin, que puede ser requerido para realizar el trabajo.

La direccin de la empresa debera colaborar ntimamente con el personal de administracin de redes para
determinar el TRO de las aplicaciones. Aplicaciones diferentes tendrn TRO diferentes.

Es necesario asegurarse de que se dispone de tiempo para recuperar las cintas localizadas en la instalacin de
almacenamiento exterior y para adquirir los sistemas necesarios. Por cierto, debera conocerse por anticipado
cmo realizar las rdenes de compra de los equipos cuando la empresa se encuentra en un estado de total
desorganizacin.

Es posible que sea necesario actualizar el sistema de copias de seguridad para satisfacer el TRO. Un sistema de
cinta que recupera datos a 2 MB por segundo realizar la labor mucho ms rpido que uno que lo ejecute a 500
KB por segundo. Hay que ser precavido y no suponer que se pueden hacer muchas cosas al mismo tiempo; uno
se puede encontrar cometiendo desafortunados errores que frenan la labor si no se presta atencin al trabajo
que se tiene entre manos.

5. Elaboracin de la documentacin

Crear un documento que mucha gente pueda tener como referencia es quizs lo ms difcil del plan de
contingencia. No hay que engaarse: implicar un esfuerzo significativo para algunas personas, pero ayudar a
aprender cosas sobre el sistema y puede que algn da salve la empresa.

Los recursos necesarios para escribir y mantener un plan de contingencia representan ms de lo que puede
realizarse en ratos libres y despus de horas de oficina. La direccin de la organizacin debe apoyar la iniciativa
para que sea un xito. Uno de los problemas del plan de contingencia en un entorno de comunicaciones es que
la tecnologa de redes cambia tan rpidamente que resulta difcil permanecer al da. Esto incluye nuevos
dispositivos, as como nuevos sistemas de aplicacin que introducen su propio nivel de complejidad en este
campo. Como ejemplo, considrese la recuperacin de un gran sistema de base de datos relacional Unix. Este
tipo de trabajo requiere un conocimiento mucho ms complejo del que corresponde a la instalacin de la base
de datos y del que un administrador de redes es probable que tenga; generalmente es necesario un
administrador de base de datos, para el que tambin la labor ser un desafo.

Dado el hecho de que la tecnologa de red evoluciona tan rpidamente, debera planificarse la actualizacin del
plan de contingencia peridicamente, por ejemplo una vez al ao. Aunque la redaccin del plan inicial supondr
una gran cantidad de trabajo, una vez que se dispone del plan, las actualizaciones son relativamente fciles.

Universidad del Valle de Mxico Campus San Rafael Pgina 10

5.1. Contenido del plan de contingencia

El plan de contingencia debe intentar definir las cinco reas siguientes:

Listas de notificacin, nmeros de telfono, mapas y direcciones

Prioridades, responsabilidades, relaciones y procedimientos

Informacin sobre adquisiciones y compras

Diagramas de las instalaciones

Sistemas, configuraciones y copias de seguridad en cinta

Hay que cerciorarse de que se sabe a quin notificar en primer lugar cundo ocurre un desastre. Por ejemplo,
si hay un incendio, llamar primero a los bomberos y luego al director general. Pueden existir otras personas o
organizaciones identificadas con caractersticas o conocimientos especiales que puedan ayudar a minimizar el
dao. Si no se dispone de nmeros de telfono o direcciones actualizados, se puede pasar muy mal contactando
con las personas afectadas.

Mapas mostrando las ubicaciones del centro de operaciones temporal y la instalacin externa pueden ahorrar
mucho tiempo. Tambin puede ser til mostrar itinerarios alternativos de acceso para el caso de que las rutas
principales no se encuentren disponibles.

Cuando en primer lugar se comienza a reflexionar sobre cmo responder a un desastre, hay que centrarse en
las prioridades establecidas. El tiempo pasa; el trabajo debe empezar por recuperar inmediatamente las
aplicaciones de mayor prioridad. Las personas deberan disponer de instrucciones y responsabilidades precisas.
La relacin entre tareas debera hallarse documentada de manera que pueda identificarse cualquier cuello de
botella que pudiera surgir. Por ltimo, deberan incluirse, de manera detallada, las operaciones y tareas que
muestren las labores de instalacin y recuperacin necesarias, debiendo ser fciles de leer y seguir. Tambin
habra que incluir aqu los nmeros de telfono de las organizaciones de asistencia que pudieran requerirse.

Como se ha mencionado anteriormente, debe saberse cmo expedir una solicitud de compra y obtener los
equipos para el centro de operaciones temporal. Esto significa proporcionar a los vendedores la direccin y
cualquier instruccin necesaria para el transporte. No hay que suponer que todos los vendedores del mundo
van a enterarse de la difcil situacin y venir a nuestro rescate. Es aconsejable disponer de copias de las facturas,
recibos y dems para mostrarlos como prueba de compra. Tambin viene bien tener a mano una lista de 1os
nmeros de serie de los equipos hardware. No hay que olvidar que, actualmente, gran parte de los productos
para el mercado de comunicaciones de LANs se vende a travs de grandes sistemas de distribucin, y que los
fabricantes y desarrolladores de software de los productos utilizados puede que no tengan ni idea de quin es
su cliente. No espere recibir los repuestos de manera gratuita; en su lugar, debera ser capaz de llegar a acuerdos
especiales de compra y provisin para sustituir los bienes perdidos.

Los diagramas de red simplifican cu gran medida la labor de construir una red. Un diagrama detallado de la red,
necesaria para las primeras aplicaciones, facilita y agiliza la reanudacin de las actividades. La asignacin de
etiquetas a los cables y su almacenamiento en un lugar reservado, probablemente no llevar mucho tiempo y

Universidad del Valle de Mxico Campus San Rafael Pgina 11

evitar muchas confusiones con posterioridad. La otra ventaja de un diagrama de conexiones es la posibilidad
de emplear contratistas para realizar las instalaciones. Alguien experimentado en la instalacin del cableado y
otros dispositivos de red, y que se dedica a ello, puede ser capaz de realizarlo mejor y ms eficientemente que
uno mismo.

Es posible ahorrarse horas o incluso das en el proceso de recuperacin si existe la posibilidad de almacenar
algunos sistemas de repuesto con la capacidad de gestionar tareas diferentes. Planifquese instalar una
configuracin genrica que, como mnimo, permita ejecutar las aplicaciones de mayor prioridad sin problemas.
Si se desconoce los productos que la gente tiene en sus PC, un producto para inventario de LAN puede ayudar
en la recopilacin de esta informacin. Despus de que la red alternativa se encuentre funcionando, y se
disponga de un momento de respiro, ser posible restaurar los PC con sus configuraciones anteriores utilizando
la informacin de configuracin extrada de los informes de inventario.

Hay que asegurarse la disponibilidad de un sistema de copias de seguridad de cinta en funcionamiento. Si es

posible, debe mantenerse un sistema de reserva, incluyendo adaptadores SCSI, cables y software de unidades
de dispositivo, en un sitio alterno. No es inusual encontrarse con que los vendedores locales no disponen de
existencias de los productos necesarios, obligando, por tanto, a esperar el envo de los repuestos antes de poder
empezar la recuperacin de los datos. Si se sigue este consejo, no hay que olvidar actualizar este sistema cuando
se actualicen los sistemas de copias de seguridad de produccin; en caso contrario, uno se puede encontrar con
formatos de cinta o bases de datos incompatibles u otros problemas que impedirn la restauracin de la
informacin.

6. Verificacin e implementacin del plan

Una vez redactado el plan, hay que probarlo. Hay que estar seguro de que el plan va a funcionar. Para ello, se
debe ser escptico sobre el propio trabajo, de manera que pueda uno probarse a s mismo que funciona.
Psicolgicamente, esto no es fcil porque con toda probabilidad se ha invertido una gran cantidad de tiempo y
energa personal en este proceso, aunque lo mejor sera, si es posible, situarse de manera imparcial ante la
confiabilidad del plan. Por consiguiente, han de realizarse las pruebas para encontrar problemas, no para
verificar que el plan funciona. Si existen errores en la informacin, tmese nota de ellos y corrjase el plan.

6.1. Comprobacin del plan por partes

No se puede tumbar el sistema algn da para ver si se es capaz de recuperarlo. Existen muchas y mejores
formas de verificar un plan de contingencia sin causar mayores interrupciones en el trabajo de la organizacin.
Algunas de las cosas en las que habitualmente no se piensa a la hora de comprobar pueden ahorrar mucho
tiempo posteriormente. Por ejemplo, llamar a los nmeros telefnicos de los colaboradores incluidos en la listas
telefnicas del plan para confirmar si son actuales; llamar a los vendedores y comprobar si disponen de
existencias de productos, ya que puede que hayan modificado su poltica de inventario. Algn da, viajar hasta
la instalacin alterna para saber dnde est y cmo reconocer el edificio.

Por supuesto, tambin es necesario verificar los procedimientos que se emplearn para recuperar los datos.
Comprubese el software para la realizacin de las copias de seguridad para confirmar si pueden recuperarse
las aplicaciones de mayor prioridad de la manera esperada. Esto debera hacerse en una red aislada para evitar

Universidad del Valle de Mxico Campus San Rafael Pgina 12

problemas con el servidor de licencias. Por ejemplo, si la idea es unificar dos servidores mediante la
recuperacin completa de uno de ellos en el servidor de repuesto y a continuacin restaurar slo los archivos
de datos de usuario procedentes del otro, finalmente se tendr dos servidores con la misma licencia de software
de servidor en la red, lo que podra dar lugar a la difusin por toda la red de mensajes de aviso sobre la licencia.
Incluso aunque se utilice una nueva licencia de sistema operativo de red, todava existen otros conflictos como
nombres de servidores duplicados y cualquier otro problema de duplicacin que podra causar problemas en
los sistemas de produccin.

Una vez recuperada la informacin, verifquese si el usuario puede acceder a ella. Esto requiere de algunas
estaciones de trabajo conectadas a la red para simular autnticos usuarios finales con cuentas en los servidos
originales. En este punto, puede ser necesario actualizar el plan para incluir informacin sobre el
establecimiento de cuentas de usuario. Comprubese cada una de las operaciones del plan individualmente y
examnese entonces si, como resultado, se tiene un sistema de red en funcionamiento. No est de ms verificar
el plan con otras personas de la organizacin que se encuentren tan familiarizadas con los productos o
procedimientos empleados.

Revsese cada da la parte del plan relacionada con las operaciones de copias de seguridad verificando la
finalizacin correcta de las mismas. Adems, supervise esto asegurndose de que algunas personas de la
organizacin saben realizar copias de seguridad adecuadamente, y comprobar su finalizacin.

7. Distribucin y mantenimiento del plan

Por ltimo, cuando se disponga de un plan definitiva ya verificado, es necesario distribuirlo a las personas que
necesitan tenerlo. Intntese controlar las versiones del plan, de manera que no exista confusin con mltiples
versiones. As mismo, es necesario asegurar la disponibilidad de copias extra del plan para su depsito en la
instalacin exterior a en cualquier otro lugar adems del lugar de trabajo. Mantngase una lista de todas las
personas y ubicaciones que tienen una copia del plan. Cuando se actualice el plan, sustituya todas las copias y
recoja las versiones previas.

El mantenimiento del plan es un proceso sencillo. Se comienza con una revisin del plan existente y se examina
en su totalidad, realizando cambios a cualquier informacin que pueda haber variado. En ese instante, se debe
volver a evaluar los sistemas de aplicacin y determinar cules son los ms importantes para la organizacin.
Las modificaciones a esta parte del plan causarn modificaciones consecutivas a los procedimientos de
recuperacin. Sin embargo, esto no debera verse como un problema porque probablemente la seccin de
procedimientos tenga que actualizarse de todas formas debido a otros cambios. Si se han realizado
modificaciones al sistema de copias de seguridad, hay que cerciorarse de incluir la informacin sobre el
funcionamiento del nuevo o actualizado sistema.

Este proceso llevar tiempo, pero posee algunos valiosos beneficios que se percibirn aunque nunca tengan
que utilizarse. Ms gente conocer la red. Esto proporcionar a la organizacin una base tcnica ms amplia
para mantener correctamente la red. Tambin facilitar el crecimiento de una perspectiva global sobre la red
dentro del ncleo de administradores de sistemas de informacin y puede ayudar a identificar las futuras o
actuales reas conflictivas. Uno de los aspectos ms difciles en cualquier labor distribuida, como es la gestin

Universidad del Valle de Mxico Campus San Rafael Pgina 13

y administracin de LAN, es dar a conocer la situacin actual. El mantenimiento y verificacin de un plan de
migracin ayudar a que se produzca dicha comunicacin dentro de la organizacin.

C3.2 Definir Polticas de seguridad

El mundo digital se ha integrado en toda la sociedad de una forma vertiginosa, en nuestro diario vivir son ms
las personas que se apoyan en Internet para utilizar sus servicios y realizar sus actividades, enviar un correo
electrnico, participar en un foro de discusin, tener una sesin de chat, comunicacin de voz sobre ip,
descargar msica o el libro favorito, hacer publicidad, etc. Son algunas de las cosas ms comunes. Sin embargo,
el mundo de los negocios empresariales es an ms complejo y la gama de servicios nos presenta mayores
alternativas. Las transacciones electrnicas nos permiten ahorrar tiempo y recursos, pagar los servicios
pblicos, transferir de una cuenta bancaria a otra, participar en una subasta para comprar un vehculo, pagar
un boleto de avin etc. En todos estos ejemplos hay algo en comn, el dinero, y cuando hablamos de tan escaso
pero tan apreciado bien las empresas deben garantizar la implementacin de polticas de seguridad informtica.

Los que trabajan en el mundo empresarial, deben recibir instrucciones claras y definitivas que los ayuden a
garantizar la seguridad de la informacin en el complejo mundo de los negocios. Cada vez encontramos ms
gerentes interesados en entender las reglas del negocio, entre ellas las referentes a las polticas de seguridad
informtica. El ofrecer productos o servicios a travs de Internet sin tomar en cuenta la seguridad informtica
no slo denota negligencia, sino que constituye una invitacin para que ocurran incidentes de seguridad que
podran daar severamente la reputacin y afectar los ciclos del negocio.

Las empresas han implementado un modelo de acceso a la informacin ms abierto y a la vez ms distribuido,
lo cual redunda en beneficios tales como:

Mayor productividad por empleado: Los empleados agilizan su trabajo, toman mejores decisiones y responden
con rapidez a las cambiantes demandas del mercado en el que se mueven, al tener un acceso seguro a la
informacin que necesitan desde cualquier lugar y en cualquier momento.

Reduccin de costos: Reduce los costos e incrementa la efectividad a travs de las herramientas de colaboracin
y de la conectividad de red

- Integracin de los procesos de negocios:

Incrementa las ventas al permitir una relacin ms estrecha con los clientes y los socios de negocios, a travs
de comunicaciones seguras y procesos colaborativos.

Para aprovechar estos beneficios, las empresas necesitan tener una infraestructura de informtica segura, que
minimice los riesgos asociados con la seguridad y los costos de administracin y operaciones. El secreto del
xito, tanto individual como de un negocio, de una empresa estatal, etc. , depende cada vez ms de la habilidad
para poder comunicarse con cualquiera, en tiempo real y con los niveles de seguridad necesarios. La aparicin

Universidad del Valle de Mxico Campus San Rafael Pgina 14

de la conectividad generalizada a travs de Internet, as como de dispositivos cada vez ms potentes y
omnipresentes, ha causado una revolucin en el terreno de las comunicaciones y la informtica.

Con los beneficios que nos brindan las nuevas posibilidades de conectividad, emergen tambin una serie de
nuevos riesgos. Muchas empresas son amenazadas en sus activos, y ms an cuando el activo ms importante
es la informacin. El deterioro de sta puede representa millones de dlares en prdidas en el mundo de los
negocios. Las vulnerabilidades en los sistemas de informacin pueden traer graves problemas.

Cada vez las redes estn expuestas a virus informticos, spam, cdigo malicioso, hackers y crakers que penetran
los sistemas de seguridad. Los elementos que la seguridad de la informacin busca proteger son:

La informacin

Los equipos que la soportan

Las personas que la utilizan

Universidad del Valle de Mxico Campus San Rafael Pgina 15

En el mundo de las certificaciones de calidad y en el cumplimiento de estndares internacionales que permitan
acceder a nuevos mercados o se brinden nuevos valores agregados que marquen una diferenciacin o ventaja
competitiva, las polticas definen la forma de hacer las cosas, el mejoramiento de los procesos. Reconocer las
limitaciones y restricciones de la tecnologa es un buen paso para entender la importancia de las polticas. En
este sentido podemos definir la poltica como un instrumento gerencial que traza una direccin predeterminada
describiendo la manera de manejar un problema o situacin. Las polticas son planteamientos de alto nivel que
transmiten a los colaboradores de la empresa la orientacin que necesitan para tomar decisiones presentes y
futuras. Las polticas son requisitos generalizados que deben ser escritos en papel y comunicados a ciertos
grupos de personas dentro y en algunos casos fuera de la organizacin

reas de normalizacin de las polticas de seguridad

Tecnolgica: Se refiere a los esfuerzos que se deben realizar para el buen funcionamiento de la plataforma de
hardware, software y telecomunicaciones. Servidores, estaciones de trabajo, sistemas operativos, bases de
datos, acceso a Internet etc. Algunas personas relacionan directamente los problemas de seguridad con el rea
tecnolgica pero es importante hacer relevancia que se parte de la tica profesional y la buena conducta de los
usuarios.

Humana: En definitiva todos se convierten en usuarios los proveedores, clientes, empleados etc. Y para ellos
se enfocan los recursos y esfuerzos. Este aspecto va muy ligado a la cultura organizacional y cmo se integran
en sus actividades diarias aspectos como la tica, la responsabilidad, capacitacin y mejoramiento continuo.

Universidad del Valle de Mxico Campus San Rafael Pgina 16

Elaboracin de la poltica

Para elaborar una poltica de seguridad de la informacin es importante tomar en cuenta las exigencias bsicas
y las etapas necesarias para su produccin.

1. Exigencias de la Poltica: La poltica es elaborada tomando como base la cultura de la organizacin y el

conocimiento especializado en seguridad de los profesionales involucrados con su aplicacin y
comprometimiento. Es importante considerar que para la elaboracin de una poltica de seguridad institucional
se debe:

a. Integrar el comit de seguridad responsable de definir la poltica (equipo multidisciplinario)

b. Elaborar el documento final (preocupaciones de la administracin, atribucin de las responsabilidades

de las personas involucradas, legislacin y clusulas contractuales, prevencin contra amenazas,
educacin y formacin en seguridad de la informacin.)

c. Hacer oficial la poltica una vez que se tenga definida (aprobacin por parte de la administracin,
mecanismos de comunicacin efectiva a socios, empleados, proveedores y clientes de la empresa).

2. Etapas de produccin de la poltica: Elaborar una poltica es un proceso que exige tiempo e informacin. Es
necesario saber cmo se estructura la organizacin y cmo son dirigidos en la actualidad sus procesos.

Las polticas son requisitos generalizados que deben ser escritos en papel y comunicados a ciertos grupos de
personas dentro y en algunos casos fuera de la organizacin.

A partir de este reconocimiento, se evala el nivel de seguridad existente para poder despus detectar los
puntos a analizar para que est en conformidad con los estndares de seguridad. El trabajo de produccin se
compone por distintas etapas, entre otras:

a. Objetivos y mbito (presentacin del tema de la norma en relacin con sus propsitos y contenidos)

b. Entrevista (identificar junto con los usuarios las preocupaciones que ellos tienen con los activos, los procesos
de negocio)

c. Investigacin y anlisis de documentos (se identifican y analizan los documentos existentes en la

organizacin)

d. Reunin de poltica (se discuten los temas y se redactan las polticas)

e. Glosario de la poltica (aclaracin de dudas conceptuales alrededor de la poltica)

f. Responsabilidades y penalidades (identificar a los responsables por la gestin de la seguridad y cumplimiento

de tareas)

Universidad del Valle de Mxico Campus San Rafael Pgina 17

 a. Bibliografa

Andrews, K. R. (1962). The concept of corporate strategy. New York: Dow - Jones Irwin.
Ansoff, I. (1962). Corporate Strategy. New York: McGaw Hill.
Betancourt, Jos R. (2002), Ediciones T.G.Red, 2000, Tercera edicin, Porlamar.
Chandler, A. (1962). Strategy and Structure: Chapters in the History of Industrial Enterprise. New
York: Doubleday.
IEEE Std(1993), IEEE Software Engineering Standard: Glossary of Software Engineering
Terminology. IEEE Computer Society Press.
ISO/IEC (1990) "Information Technology - Information Resources Dictionary System (IRDS) -
Framework", ISO/IEC intl. Standard edition,
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James (2000). El Proceso Unificado de Desarrollo
de Software (en Espaol). Pearson Addisson-Wesley.

Universidad del Valle de Mxico Campus San Rafael Pgina 18