Documente Academic
Documente Profesional
Documente Cultură
INTRODUCCIN
Las redes informtica en el mundo han mostrado un gran progreso, la posibilidad de comunicarse a travs de redes ha abierto
mucho horizontes a las empresas para mejorar su productividad y poder expandirse a muchos pases, debido a esto hay que
garantizar la seguridad de la informacin que se trabaja da a da, estos riesgos nos han llevado a implementar nuevos
procedimientos que nos van a ayudar en el adecuado uso de los sistemas tecnolgicos y de las redes en general, la cual consisten
en compartir recursos, y que todos los programas, datos y equipo estn disponibles para cualquiera de la red que as lo solicite, sin
importar la localizacin del recurso y del usuario.
Tambin consiste en proporcionar una alta fiabilidad, al contar con fuentes alternativas de suministro. Adems, la presencia de
mltiples equipos significa que si una de ellos deja de funcionar, los otros pueden ser capaces de encargarse de su trabajo, aunque
se tenga un rendimiento menor. Este manual fue elaborado con nociones Bsicas de Seguridad en redes informticas, recogiendo
los principales conceptos y recomendaciones de los problemas que se pueden presentar en una red, con el fin de informar a los
trabajadores sobre los riesgos ms comunes y sus medidas preventivas.
Anlisis y Diseo
A lo largo de esta fase se desarrollarn cada una de las tareas definidas en el estudio de viabilidad. Adems de mostrar la solucin
elegida, en la mayor parte de los casos, se valorarn las alternativas posibles y sus implicaciones.
Por cuestiones de evolucin y marco de competencia en el mercado, gran parte del volumen de llamadas se est moviendo hacia el
segmento de la telefona mvil. Tradicionalmente, el servicio de conexin a la red telefnica vena siendo proporcionado por lo que
hoy conocemos como operadores fijos, siendo tarificado el trfico entre la red fija de la empresa, y cualquier telfono mvil con un
sobrecoste con respecto a los precios habituales entre el mismo, o diferentes operadores mviles. Es por ello que resulta ms que
interesante establecer un doble acuerdo de conexin tanto con un proveedor de telefona fija como con uno de telefona mvil (que
en la prctica puede ser la misma empresa, en el caso que opere en ambos mercados).
El medio de conexin a ambos proveedores es el mismo: accesos primarios
ISDN dedicados (30 canales o llamadas simultneas). Por cuestiones de dimensionamiento de trfico y tolerancia a fallos, se
propone la contratacin de dos enlaces ISDN PRI por centro al operador de telefona fija, y un enlace por centro al operador de
telefona mvil, configurndolos en modo agrupado, de forma que los cuatro, o los dos, formen una unidad capaz de desbordar
trfico de un enlace al siguiente del grupo, as como comportarse de forma tolerante a fallos, en caso de fallo de alguno de ellos.
Al operador de telefona fija seleccionado se le solicitar uno o varios nuevos rangos de numeracin consecutiva para uniformar los
nmeros de telfonos de ambas sedes, y de forma adicional, servir de medio para el periodo transitorio entre ambos sistemas.
Dentro del plan de integracin de servicios con el operador mvil se encuentra la red privada virtual mvil (RPVM) que posibilitar
que los telfonos mviles de los empleados que se considere, se integren en el plan de numeracin de la empresa, con numeracin
corta, y cuyo trfico, cuando su destino sea otro mvil corporativo o una extensin fija de la empresa, sea consideracin de llamadas
internas, con una poltica de precios diferenciado (que en funcin del acuerdo comercial con el operador mvil podra llegar a ser
coste cero).
En el caso de la interconexin de las dos centralitas, ya no es necesario un enlace dedicado de la compaa telefnica, sino que se
utilizar la propia infraestructura de datos de la empresa, que ya se encuentra completamente consolidada, y en principio,
sobradamente dimensionada para transportar el trfico de voz.
Es evidente que tanto la inclusin del operador mvil como la eliminacin de la conexin dedicada entre centralitas suponen una
gran fuente de ahorro en lo que se refiere a costes recurrentes.
Arquitectura de red
A la hora de plantear la conexin de los telfonos IP a la red, existen varias posibilidades:
1. Conexin directa a la infraestructura actual de redundancia.
2. Establecimiento de una nueva red separada
Es importante remarcar, llegados a este punto, las especiales caractersticas del trfico IP que da soporte a los servicios de voz en
un sistema VoIP:
Las llamadas, aun usando un codec de alta calidad como G.711 (ms adelante se analizarn los distintos codecs y protocolos de
sealizacin), utilizan un ancho de banda equivalente a unos 100 Kbps por conversacin.
Las llamadas VoIP son muy sensibles a cualquier retardo o desorden de llegada de los paquetes RTP (los que transportan los
datos de audio), el retraso mximo aceptable se sita en torno a los 100 ms. Estos retardos producen que el codec en cuestin
descarte los paquetes afectados y se produzca una cada sensible en la calidad del audio de la conversacin en un efecto
denominado jitter.
Cualquier problema en la red de datos (en el caso de ser compartida con la de voz) como una reconfiguracin del spanning-tree,
un uso masivo de recursos, como un ftp, o un programa P2P incontrolado, pueden tener un efecto directo en el jitter de las
conversaciones de voz simultaneas.
Para paliar esta ltima cuestin existen soluciones que pueden implementarse de forma independiente o simultneamente:
Utilizar VLANs diferentes para cada uno de los trficos, de forma que problemas de reconfiguraciones (en el caso de usarse pervlan-spanningtree), etc, no afecten al trfico de voz.
Utilizar las capacidades de QOS (Quality of Service) de la infraestructura comn de red, de forma que se priorice el trfico de la
VLAN de voz sobre cualquier otro trfico.
Una funcionalidad bastante habitual en las redes VoIP es el uso de unas extensiones al protocolo Ethernet para el soporte de
alimentacin (power) a travs del mismo cable de red, de forma que cualquier dispositivo, por el hecho de disponer de conexin de
red, dispone simultneamente de la alimentacin necesaria para su funcionamiento, a travs de un nico cable. A esta funcionalidad
se la denomina Power Over Ethernet (POE), y es de especial utilidad en despliegues como el que nos ocupa, debido al ahorro que
supone no tener que adquirir fuentes de alimentacin para cada telfono, y una innegable ventaja a nivel de espacio y complejidad
en el escritorio del usuario.
En cualquier caso, y dada la red de partida, ampliar la capacidad de conexiones en los conmutadores Catalyst actuales es una
opcin de coste econmico elevado, y en algunos casos, implicara la ampliacin fsica del chasis del conmutador, al ser necesario
incluir nuevos mdulos de puertos 10/100. Las tarjetas Cisco con soporte POE son an mucho ms caras.
A la vista de la problemtica anteriormente descrita, y en base a la infraestructura ya existente a nivel de cableado estructurado, se
propone la instalacin de una red paralela, en forma de estrella, a base de conmutadores con soporte POE y puertos de conexin
Fast Ethernet (100 Mbps) de cara al usuario, y conexin GigabitEth de cara al punto central de la estrella (que no precisa tener
soporte POE, dado que no se conectarn telfonos IP al mismo).
Existen en el mercado conmutadores de bajo coste con estas caractersticas, como los comercializados por Linksys (una marca
paralela de Cisco), que con densidades de 24 puertos POE se encuentran por debajo de los 500 por unidad. Los conmutadores
centrales, con doble densidad de puertos (48 10/100/1000 no POE) se encuentran en el mercado en torno a los 400 . En funcin
de la distribucin de extensiones por edificio (200) se decide instalar en cada centro:
10 conmutadores Linksys SRW224P 24 Port 10/100 Switch with POE + (2) Gigabit.
1 conmutador Linksys SRW2048 48-port 10/100/1000
Por cuestiones de mantenimiento y stock, se decide adquirir una unidad ms, por centro, de los anteriores modelos, para un
reemplazo rpido en caso de rotura de algn elemento.
El conexionado desde el centro de la estrella (en el CPD) hasta los repartidores de planta se realizar a travs de los enlaces de par
trenzado Cat. 5 que actualmente se encuentra sin utilizar, y el de los telfonos al centro de reparto de planta, se har usando la
toma I de cada roseta.
La conexin entre edificios se har utilizando la infraestructura actual interconectando ambas estrellas VoIP a los conmutadores
Catalyst 6509 de cada sede, creando para la ocasin una VLAN especfica para la nueva red, de forma que la conexin en ambos
centros de las nuevas redes a un puerto del mencionado conmutador Catalyst configurado con dicha VLAN constituye una unin a
nivel 2 de las mismas. De esta forma se logra, utilizando la red actual de la empresa como transporte, la unin de las dos redes de
voz en una sola.
La definicin de la red VoIP como VLAN especfica en los conmutadores Catalyst corporativos, permite la conexin eventual a la
misma (configurando el puerto correspondiente con la mencionada VLAN) de dispositivos (telfonos, sistemas de monitorizacin,
etc...) en el caso de ser necesario y no disponer de una conexin ms directa a dicha red.
Para su interconexin (la red de voz es una red separada pero no aislada), se definir una direccin de routing en los conmutadores
Catalyst 6500 perteneciente a la mencionada VLAN, de forma que pueda servir como salida hacia el exterior (y el resto de los
servicios de la empresa) a los telfonos, y a su vez, sirva para hacer alcanzables a los telfonos desde la red de datos (por ejemplo,
para que la Intranet pueda desencadenar llamadas contactando directamente con los terminales).
a
9X XXX 42 99
9X XXX 50 00
a
9X XXX 52 99
Lo que permite establecer, usando direcciones privadas, un plan de direccionamiento IP coincidente con DDI del tipo:
192.168.4.000
a
192.168.4.199
192.168.5.000
a
192.168.5.199
Quedando todas las direcciones bajo la red 192.168.4.0/23 (255.255.254.0), y dejando reservadas las direcciones IP superiores a
la .199 para servidores, conmutadores, otros dispositivos, etc... Las extensiones superiores a la mencionadas 4199 y 5199 (200
extensiones) quedarn libres para servicios que no precisen direccin IP asociada, como colas de espera, sistemas de buzn de
voz, salas de multiconferencia, extensiones de telfonos mviles, etc.
A partir de los rangos anteriores, y teniendo en cuenta cuestiones mnemotcnicas, se define el siguiente plan de numeracin
10
11
H.323: es el protocolo ms veterano y probablemente ms completo. Est completamente definido pero adolece de algo de
flexibilidad. En un principio se orient a servicios de videoconferencia, y de ah su excelente soporte de video.
SIP: es el ms extendido con diferencia, y aunque no est completamente definido, goza de suficiente flexibilidad para
funcionar en multitud de escenarios. En su ventaja, existen una gran variedad de terminales compatibles SIP.
IAX: desarrollado como parte del proyecto Asterisk, soluciona mucho de los problemas cotidianos de los dos anteriores, y
sirve de base para una interconexin slida entre centralitas Asterisk, de forma que cubre todas las necesidades de este entorno,
eliminando toda la complejidad extra, as como proporciona un sistema muy sencillo de puertos, que en la prctica permite usar los
sistemas VoIP a travs de de todo tipo de configuraciones NAT, algo impensable con H.323 y SIP. Aun no existen en el mercado una
gama representativa de terminales que implementen IAX.
En general, Asterisk soporta los tres protocolos de sealizacin mencionados, con especial madurez en la implementacin de SIP e
IAX. Es por ello, que se opta por SIP como protocolo de sealizacin a utilizar entre los terminales y la centralita Asterisk, e IAX
como protocolo de sealizacin para el traspaso de llamadas entre las centralitas de ambas sedes. El uso de IAX para este tipo de
trfico permite reducir el ancho de banda necesario gracias a la funcionalidad de trunking IAX, que encapsula la sealizacin de
mltiples conversaciones bajo un nico grupo de cabeceras, reduciendo sensiblemente el ancho de banda necesario para la
interconexin de centralitas.
Codificacin (codec)
En el mundo de los codecs la cuestin es qu relacin ancho de banda / calidad se desea obtener. Los codecs G.711 (tanto en
versin alaw como ulaw) permiten una calidad similar a la producida por los sistemas analgicos, pero con la contraprestacin de un
consumo de ancho de banda relativamente alto. Codecs como GSM (ampliamente utilizado en las redes de telefona mvil), G.726 y
G.729 (teniendo este ltimo algn problema de patentes) permiten reducir el ancho de banda necesario, siempre a costa de reducir
la calidad. El ancho de banda necesario estimado usando dichos codecs se resume en la siguiente tabla:
12
Hay que tener en cuenta que estas cifras han de interpretarse en cada sentido de la comunicacin, si bien es cierto que durante
las mismas, es poco habitual que ambos interlocutores hablen simultneamente, y que durante una conversacin habitual se
producen mltiples silencios que todos estos codecs detectan convenientemente y no se transmite nada durante ellos.
Parece razonable utilizar G.711 alaw (la versin europea de G.711) debido a su mayor calidad de audio, a pesar del alto consumo
de ancho de banda de este codec, dado que la red diseada soportara, aun con estas cifras, centenares de llamadas simultaneas
sin problemas de congestin.
13
Plataforma hardware
En el caso de la plataforma hardware, la empresa tiene un acuerdo comercial con el fabricante de PCs y servidores DELL, de forma
que parece razonable proponer una configuracin dentro de las ofrecidas por el mencionado proveedor.
Las caractersticas que ha de cumplir el sistema elegido son:
Alta fiabilidad y construccin robusta
Buena capacidad de I/O tanto a disco como a red
CPU o CPUs de alto rendimiento (las labores de transcoding realizan un trabajo de CPU intensivo)
Alta capacidad de RAM (cada llamada simultanea o invocacin de servicio precisa la reserva de un espacio propio de memoria)
Con estos requisitos se propone utilizar para el proyecto el sistema PowerEdge 2950 con las siguientes caractersticas:
2 procesadores Quad Core Intel Xeon L5320, 2x4MB Cache, 1.86GHz, 1066MHZ FSB
RAM 4GB, 677MHz
Controladora RAID integrada PERC 6/i
4 discos SAS 146 GB 2.5-inch, 10.000 rpm (450 Gb en Raid5)
14
Sistema operativo
En cuanto al sistema operativo a utilizar, se debe tener en cuenta que normalmente se utiliza de forma corporativa y se muestra
preferencia por sistemas Linux basadas en las variantes de RedHat. Concretamente utilizan Fedora Core (versiones 3 a 7) para la
mayor parte de sus servidores de aplicaciones, servicios Internet, etc... y RedHat Enterprise Linux (la versin comercial de RedHat)
para servicios que precisan algn tipo de certificacin por parte de fabricantes, como son las bases de datos Oracle.
Para la toma de decisin de la distribucin Linux a utilizar, conviene repasar los pros y los contras de ambos productos de RedHat:
Fedora Core: proyecto libre y gratuito auspiciado por RedHat, pero dirigido por la comunidad, con releases rpidas (cada 6 meses)
y corto soporte de actualizaciones (1 ao y medio)
RedHat Enterprise Linux: producto comercial de RedHat que se nutre de los resultados del proyecto Fedora Core, y va
incorporando los componentes ms maduros de dicha distribucin. Tiene un ciclo de release ms largo (cada 2 aos), y soporte
para actualizaciones de hasta 10 aos. En general se considera una versin ms estable y duradera que Fedora Core.
En el caso que nos ocupa, la estabilidad y duracin del periodo de actualizaciones se presenta como un aspecto crtico dado que
por su especfica naturaleza, las centralitas deben ser una plataforma robusta y duradera, que permite largos tiempos de
funcionamiento ininterrumpido.
En cualquier caso, se propone utilizar una nueva distribucin denominada Ubuntu, la cual trae dos grandes ventajas, adems de ser
de distribucin libre. Y estas dos ventajas son: el sistema integrado de actualizaciones (Gestor de actualizaciones) y la tienda de
aplicaciones integrada (Centro de software de Ubuntu).
En Ubuntu las actualizaciones estn centralizadas en una misma aplicacin que se encarga de ello, para cualquier componente
instalado, y en ese caso actualiza el que sea necesario. En Windows, por ejemplo, cada aplicacin se encarga de revisarse a s
misma, y es un verdadero caos mantener las ltimas versiones estables de cada aplicacin. En Ubuntu hacer esto es mucho
sencillo.
15
Por otro lado, en el Centro de software de Ubuntu tenemos miles de aplicaciones de todos los colores, listas para elegir e instalar.
Volviendo al ejemplo anterior, en Windows el usuario tiene que ir instalando aplicacin por aplicacin, despus de haberlas
encontrado dispersas por la Web. Y no hablemos ya de los drivers, que convierten cada instalacin de Windows en una eternidad.
En Ubuntu, todo se actualiza de una sola vez gracias a la descarga de paquetes.
Hardware de comunicaciones
Dado que el nuevo modelo de servicio marca como lnea maestra la definicin de las comunicaciones con el exterior haciendo uso
de enlaces digitales tipo ISDN PRI, ser preciso equipar las centralitas con tarjetas que soporten el mencionado tipo de conexin.
Equipar las centralitas con hardware tipo Intel y Asterisk como software de centralita posibilita la integracin de tarjetas de
comunicaciones de mltiples fabricantes, habida cuenta de las especificaciones abiertas de la solucin. Independientemente, una
apuesta segura de compatibilidad y reduccin de riesgos en el presente y en el futuro es elegir productos desarrollados por Digium
Inc., la empresa que patrocina el proyecto Asterisk y bajo la cual se gest desde sus primeras versiones. Adicionalmente, y debido a
la falta de barreras de entrada para la produccin de este tipo de dispositivos, los precios entre los diferentes fabricantes que
ofrecen soluciones para Asterisk (Eicon, Junghans, Sangoma...) estn bastante equilibrados.
Dado que, por diseo, en cada centro se recibirn conexiones de dos proveedores (fijo y mvil), y que en alguno de los casos, el
mismo proveedor se conectar con ms de una lnea, es interesante seleccionar una tarjeta de comunicaciones que integre ms de
un interfaz de telefona en la misma, de forma que se evite el instalar en un mismo sistema ms de una tarjeta, con el
correspondiente ahorro de IRQs (lneas de interrupciones que utilizan las tarjetas de comunicaciones para comunicarse con la CPU
del sistema), lo cul mejora sensiblemente el rendimiento de dichas tarjetas en el sistema.
Un factor importante a considerar a la hora de seleccionar hardware para servidores de nueva generacin es el voltaje de los slots
del BUS PCI, dado que los recientes, basados en 64 bits, ofrecen un voltaje de 3.3 voltios, mientras que los anteriores, basados en
32 bits, utilizan 5 voltios.
Por otra parte, a la hora de implementar servicios de voz, es bastante frecuente encontrar problemas con el efecto eco, una molesta
realimentacin del audio de la conversacin debido a mltiples posibles causas, en general mala calidad de alguno o varios
16
elementos de transmisin en el recorrido analgico de la llamada. La forma ms eficiente de luchar contra este efecto es haciendo
uso de los denominados canceladores de eco que tanto por software (en la propia centralita Asterisk) o por hardware (integrado en
la tarjeta de comunicaciones) existen en el mercado.
Digium posee dentro de su gama tarjetas con 1, 2 y 4 puertos, con versiones de 3.3v y 5v, as como la posibilidad de integrar en las
mismas un potente cancelador de eco por hardware fabricado por Octasic.
La tarjeta seleccionada para el despliegue de los servidores es el modelo Digium TE412P, que entre otras caractersticas, ofrece:
Compatibilidad E1 (sistema europeo para enlaces ISDN PRI) y T1 (sistema USA para enlaces ISDN PRI).
Capacidad de fuente de sincronizacin tanto para enlaces como para procesos del sistema.
Incluye el mdulo de cancelacin de eco basado en DSP Octasic VPMOCT128, con capacidad de eliminacin de tramas de eco
de hasta 128 ms
17
Redundancia de centralitas:
18
Independientemente de la redundancia geogrfica de las lneas de conexin al exterior es preciso definir un nivel de proteccin en el
caso del fallo de una de las centralitas, dado que este evento podra no ser detectado por el proveedor de servicios, y con toda
seguridad, provocara simultneamente problemas de accesibilidad a los usuarios dependientes de la misma.
La solucin estndar para este tipo de casos es la de redundar los sistemas que configuran una centralita, formando un cluster de
sistemas idnticos que se sincronicen y mantengan un estado de activo-pasivo. Para ello se utilizar la solucin heartbeat + DRDB
del proyecto Linux-HA, entre cada pareja de servidores Dell PowerEdge 2950, de forma que ofrezcan a los usuarios de los telfonos
una direccin IP flotante, compartida entre ambos.
Esta solucin de cluster se complementa con un dispositivo de contingencia o failover, que redirigir la entrada de las lneas de
conexin externas (los tres enlaces ISDN PRI) hacia el servidor que en ese momento se encuentre en estado activo.
El dispositivo seleccionado para esta misin es el ISDNGuard del fabricante Junghanns, un conmutador de nivel 1 (conmutacin de
circuitos a nivel elctrico), que es gobernado por la seal que continuamente le proporciona el sistema encargado de la centralita
principal, a travs de un cable serie y un proceso watchdog integrado en el propio Asterisk, mantiene el encaminamiento de entrada
preestablecido. Ante la falta de seal de vida del sistema principal (por la cada del propio sistema o por la cada del servicio
Asterisk) conmuta de forma inmediata los enlaces de entrada hacia el segundo sistema.
19
Una funcionalidad interesante de este dispositivo es que ante la falta de alimentacin elctrica, continua proporcionando
interconexin entre los enlaces de entrada y la centralita, eso s, sin la inteligencia necesaria para la monitorizacin del puerto serie.
20
Bajo precio
Calidad de audio media
Los equipos de gama alta comparativamente bastante pobres
Snom:
Calidad de construccin buena, pero poco ergonmicos
Precio medio
Los equipos de gama baja (Snom-300) no soportan POE
Calidad de audio buena
Cisco:
Calidad de construccin excelente
Precio medio-alto si se adquieren sin licencia de Call Manager
Equipos de gama media, alta y una versin especial para secretarias
Calidad de audio excelente
Aprovisionamiento a travs de DHCP/TFTP/XML
Finalmente la decisin se decanta hacia los equipos Cisco, que aunque diseados para la solucin propietaria de centralita Call
Manager (se distribuyen pre-configurados con una imagen de software para el protocolo SCCP), es posible utilizar a mitad de precio
si se adquieren sin licencia y se utiliza el firmware SIP que el propio Cisco distribuye para escenarios donde sus telfonos deban
integrarse con centralitas de terceros.
La calidad del audio de estos telfonos es sensiblemente superior a la de sus rivales, y la calidad y usabilidad de los mismos
tambin destaca sobre los del resto de fabricantes.
21
Una de las principales diferencias de la telefona IP con respecto a la telefona tradicional es que en esta ltima se produce un
efecto natural de realimentacin del audio del micrfono al auricular del usuario, as como se mantiene cierto ruido blanco natural
durante los silencios y pausas de una conversacin.
A la simulacin de este ruido blanco se le denomina comfort noise (ruido reconfortante) y su generacin depende de factores
adaptativos a cada situacin (llamadas diferentes precisan un comfort noise diferente). En este campo tambin los equipos de Cisco
han demostrado su alta calidad.
Los terminales seleccionados para el despliegue son:
Cisco 7911G:
Equipo estndar de empleado
Una lnea
Manos libres
Compatible POE
Coste: $280.000 / unidad
Cisco 7941G:
Equipo estndar de director / mando intermedio
Dos lneas
Manos libres
Compatible POE
Posibilidad de despliegue aplicaciones XML
Coste: $300.000 / unidad
22
Cisco 7961G:
Equipo estndar de secretaria / operadora / usuario avanzado
Seis lneas
Manos libres
Compatible POE
Posibilidad de despliegue aplicaciones XML
Coste: $320.000 / unidad
23
24
En el caso de este ltimo modelo, es posible aadirle un panel de extensin de forma que con el mismo equipo se puedan
monitorizar 16 extensiones extra (funcin muy til para las operadoras).
Una vez determinado el nmero de equipos de cada tipo de la gama elegida es posible cerrar el presupuesto con datos reales en la
partida de terminales, que debido a este ajuste se incrementa en $30.000.
25
Definicin de servicios
Puestos al habla con la recepcionista de la empresa, entre cuyas labores se encuentra la de gestionar la posicin de operadora, y
atender las llamadas entrantes que no conocen la extensin destino, y gracias a su experiencia con el sistema actual se enumeran
las funcionalidades actuales del sistema que de forma habitual vienen utilizando los usuarios:
Llamadas internas entre extensiones locales
Llamadas externas, desde extensin interna, marcando el 0 como dgito de salida, con categorizacin de las extensiones internas,
de forma que cada grupo de usuarios tiene permiso para llamar a determinados destinos (fijos locales, provinciales, nacionales,
mviles, extranjero, nmeros especiales 90x, etc...).
Llamadas a la operadora (recepcionista) marcando el 9
Desvo incondicional de una extensin interna a otra, marcando el cdigo *21*ext_destino#
Anulacin de desvo incondicional marcando *21#
Desvo si no contesta de una extensin interna a otra, marcando el cdigo *22*ext_destino#
Anulacin de desvo si no contesta marcando *22#
Anulacin de todos los desvos, marcando *23#
Captura de llamada, llamando a una extensin interna, pulsando 8 mientras suena el tono de ocupado
26
Desvo jefe-secretaria, propio del Proveedor, por el cual las llamadas a la extensin real del jefe, son interceptadas por la
extensin de su secretaria
Ring distintivo, de forma que suena un tono diferente de llamada en el caso de que el origen de la llamada sea interno o externo
A estos servicios se desea aadir los siguientes:
Buzones de voz personalizables: con la posibilidad de escuchar los mensajes a travs del telfono o recibir los mismos a travs
del correo electrnico
Msica en espera: cuando una llamada se deje en espera (hold) debe reproducirse un fichero MP3 al azar de entre los ubicados
en un repositorio.
Agenda corporativa integrada en el telfono: se debe poder acceder al listado completo y actualizado de la totalidad de las
extensiones desde el propio telfono
Click2Call: se implemente un programa que a partir de un nmero de telfono origen y un nmero de telfono destino, sea capaz
de conectarse a un telfono y establecer la mencionada llamada sin intervencin del usuario (a excepcin de hacer click en una
pgina web).
Anlisis y diseo
Implantacin y pruebas
27
28
Verificacin de todas las funcionalidades y todas posibilidades de trfico de voz (llamadas interna-interna, interna-externa,
externa-interna, interna-mvil, etc...).
Prueba exhaustiva del plan de contingencia, en caso de fallo de cualquier elemento.
Pruebas de carga y stress a los servidores.
El desarrollo de todas estas fases se estima en un periodo total de 7 semanas, divididas en los siguientes periodos:
Anlisis y diseo: 2 semanas
Implantacin: 4 semanas
Pruebas: 1 semana
Para llevar a cabo todas las labores descritas en el presente proyecto, se plantea destinar al mismo los recursos humanos
necesarios, en base a los siguientes perfiles:
1 Jefe de Proyecto: cuya responsabilidad ser la de definicin de objetivos, asignacin de recursos y direccin en general del
proyecto, as como de todo el personal destinado al mismo. Ser tambin responsabilidad suya la interlocucin continua con el
cliente para garantizar la convergencia del trabajo desarrollado con los objetivos del mismo. Esta persona desarrollar la
mencionada labor en rgimen de dedicacin parcial, pero a disposicin continua por parte del cliente.
1 Analista de Sistemas: su responsabilidad ser la de definir procesos, configuraciones y aspectos relativos a los servicios de
telefona y arquitectura de red, as como servir de apoyo al proceso de despliegue de la solucin. Dado el profundo conocimiento
preciso de las cuestiones de telefona y comunicaciones para el desarrollo de estas tareas, se plantea como perfil ideal para este
puesto de una persona a dedicacin plena con titulacin de Ingeniero en Telecomunicaciones, con certificado de aptitud dCAP
(certificacin emitida por Digium Inc.).
1 Tcnico de Sistemas: su responsabilidad se centrar en las labores de configuracin de servidores, servicios bsicos (dns, dhcp,
servidor web, etc...), electrnica de red, despliegue de telfonos, etc, as como en apoyar al analista de sistemas en todas las tareas
de desarrollo, implantacin y pruebas. Para el desempeo de las mencionadas funciones se propone una persona con titulacin de
Ingeniero en Informtica o equivalente.
29
PRESUPUESTO INICIAL
Para el desarrollo del proyecto se establece un presupuesto inicial de $17.350.000 (est.), desglosado en las siguientes partidas:
1. Hardware
Servidores: 2x $ 3.000.000
Tarjeta 1 E1 Primario Rdsi: 4x $550.000
Dispositivos failover ISDN: 2x $300.000
Red local LAN POE: 10x $135.000
2. Telfonos IP, dependiendo de la eleccin del cliente: 10x $280.000 (estimacin)
3. Consultora y asistencia tcnica
1 jefe de proyecto: $2.000.000
1 analista de sistemas $1.200.000
1 tcnico de sistemas $1.000.000
En resumen:
Hardware: $10.150.000
Telfonos IP: $3.000.000 (est.)
Consultora y asistencia tcnica: $4.200.000
TOTAL: $17.350.000 (est.)
30
SERVICIOS GENERALES
El servicio global de asistencia tcnica para empresas tiene como objetivo solucionar los problemas cotidianos que da a da surgen
en toda oficina. La aparicin de un virus, la desconfiguracin de un dispositivo, la suciedad dentro de los equipos o la prdida de
conexin a Internet pueden ocasionar verdaderos desastres que lleguen a paralizar el rendimiento de nuestro trabajo. Contamos
con un servicio altamente cualificado para prestar a su empresa soluciones eficaces a los problemas informticos.
SERVICIOS ESPECFICOS
TELECOMUNICACIONES
Empresa dedicada a la instalacin, gestin y acondicionamientos de equipos de telecomunicaciones, asi como mantenimiento
correctivo y preventivo del equipo
-Gestin y administracin de red
-Cableado estructurado
-Diseo, implementacin y mantenimiento de:
-Datos:
-Router
-Switch
-WAN
-LAN
REDES ETHERNET
REDES WI-FI
ASESORAMIENTO EN LA INSTALACIN DE INFRAESTRUCTURAS INFORMTICAS
SERVIDORES
31
32
-DHCP
-DNS
-WINS
ESTRUCTURA FSICA
SEDE PRINCIPAL
La sede principal ubicada en el norte de la ciudad consta de 8,aunque estamos ubicados en cuatro pisos administrativos y
operativos, un stano y una terraza. Posee un rea de 34 m de frente por 33 de fondo.
La distribucin especfica de esta rea se puede apreciar en el Plano Nro. M-001, sobre Distribucin General de Espacio.
En este plano puede apreciarse con claridad sus dimensiones generales, ubicacin de columnas, ventanas y entrada principal.
-La altura de los techos en todos los pisos, salvo especificacin en contrario, es de 3.65 metros
-Todos los techos son falsos o dobles
-Todos los pisos son de hormign, con un piso falso sobrepuesto.
33
34
35
CABLEADO HORIZONTAL
La distribucin principal se hace a partir del buitrn, centro de cableado en el (IDF) donde se halla de patch panel de voz y datos,
luego hacia los equipos que lo requieren.
36
37
CONEXIN DE DATOS
CABLE UTP: El cable UTP para el cableado horizontal de voz y datos ser
Categora 5e, deber estar conformado de 4 pares (8 hilos) de conductores slidos de cobre calibre 24 AWG. El cable debe permitir
la transmisin de datos a altas velocidades (100Mbps, 155 Mbps, 1000 Mbps) y presentar un ancho de banda aprobada de 250
MHz, deber soportar los siguientes estndares: LAN 100 BASE TX, ATM, Gigabit Ethernet, multimedia: audio, digital AES/EBU
38
control RS422, video analgico, y digital NTSC/PAL y CATV Broadband, certificado para sistemas de banda ancha, adems deber
ser aprobado por la UL para video digital a 135 MHZ (270 MBPS) de acuerdo con la FCC clase A.
El cable UTP debe tener un revestimiento aislante externo de PVC retardante al fuego, marcado con unidad de medida para fcil
estimacin de longitudes, la cubierta exterior deber contener adems: Nombre o Marca de fabricante, Categora del cable,
cumplimiento de normas EIA/TIA e ISO/IEC11801. JACKS Y TOMAS: Acorde a la norma EIA/TIA-568-A, se utilizan Jacks y Tomas
tipo RJ45 con el fin de conectar el cable UTP.
39
40
TOPOLOGAS DE LA RED
La topologa de una red, define bsicamente la distribucin del cable que interconecta los diferentes equipos, las estaciones de
trabajo (WS). A la hora de instalar una red es importante seleccionar la topologa ms adecuada a las necesidades del usuario,
debiendo tenerse en cuenta entre otros los siguientes factores:
La distribucin de los equipos a interconectar
El tipo de aplicaciones que se va a ejecutar
La inversin que se quiere hacer
El costo presupuestado para actualizaciones y mantenimiento de red
El trfico que la red deba soportar
La capacidad de crecimiento o expansin futura.
La topologa es la estructura que forman el medio de transmisin y las estaciones conectadas al medio.
41
ESTRUCTURA ORGANIZACIONAL
PERFILES DE USUARIO
Departamento de proceso de pedidos
Nombres de perfil de grupo: DPTOP
Perfil de usuario
Nombre
Clase de usuario
Limitar posibilidades
PEREJ
TORKAR
VELCON
MOLLUI
Perez, Juan
Torrez, Karen
Velazco, Constanza
Molina, Luis
*SECOFR
*NO
Dispositivo de
impresin
PRT05
PRT04
PRT04
Departamento de almacn
Nombres de perfil de grupo: DPTWH
Perfil de usuario
VINAND
CASJOR
RODJUA
MAREMM
DIACAR
Via, Andrs
*SYSOPR
Castellanos, Jorge
Rodrguez, Juan
Martnez, Emmanuel
Daz, Carolina
Limitar
posibilidades
*NO
Programa/
biblioteca inicial
Men/biblioteca
inicial
ICRCPT/ICPGMLIB
ICRCPT/ICPGMLIB
Ninguno
Ninguno
42
Gerencia
Nombres de perfil de grupo: DPTAD
Perfil de
usuario
GOMJON
VILFLO
ANAHEC
PATMAR
REYALA
Texto
Clase de
(descripcin)
usuario
Gmez, Jonathan *MSTKEY
Villalobos,
Florencia
Anaya, Hctor
Patio, Marcos
Reyes,
Alan
Limitar
posibilidades
*NO
Dispositivo de impresin
PRT01
PRT03
PRT03
ESPECIFICACIONES
PCS
ESPECIFICACIONES:
- Procesador: Pentium 4 Intel 540 con tecnologa HT
43
44
MONITORES
HP MONITOR 1502 15" TFT 1024X768
HP L1502 - display de pantalla plana - TFT - 15"
ESPECIFICACIONES:
45
SWITCH CAPA 2 POR 48 PUERTOSModelo: 3Com SW SS3 3870 48 10/100/1000 - Part number: 3CR17451-91-ME
Tipo de dispositivo Conmutador - apilable
46
MODEM RDSI
Modem marca Paradyne (canal conmutado) o RDSI.
Con la utilizacin de este modem se reduce en forma significativa el nmero de
modems requeridos para soportar dispositivos de entrada/salida en redes, as
como tambin, el nmero de lneas de comunicacin necesarias para soportar la aplicacin.
47
48
PATCH PANEL:
Patch Panel IEEE 1394a de ADC
Patch Panel de mltiples puertos IEEE 1394a. Diseado para ser usado en la industria, este producto tiene 24 puertos ocupando
una unidad de rack de altura por 19 pulgadas de ancho
SERVIDORES
IBM xSeries 345 K07RGSP
ESPECIFICACIONES:
49
CONEXIN A INTERNET
50
51
Antes de saber qu es un anlisis de riesgos y lo que conlleva es importante conocer qu son otro tipo de conceptos muy
relacionados con los Anlisis de Riesgos y la seguridad de la informacin. Estos son los ms importantes:
Amenaza: Es la causa potencial de un dao a un activo.
1
Vulnerabilidad: Debilidad de un activo que puede ser aprovechada por una amenaza.
El anlisis de riesgos se define como la utilizacin sistemtica de la informacin disponible, para identificar peligros y estimar los
riesgos.
A la hora de disear un SGSI, es primordial ajustarse a las necesidades y los recursos de la organizacin para que se puedan cubrir
las expectativas, llegando al nivel de seguridad requerido con los medios disponibles. Es relativamente sencillo calcular con cuantos
recursos se cuenta (econmicos, humanos, tcnicos) pero no es tan fcil saber a ciencia cierta cules son las necesidades de
seguridad.
Es aqu donde se muestra imprescindible la realizacin de un anlisis de riesgos. Hacerlo permite averiguar cules son los peligros
a los que se enfrenta la organizacin y la importancia de cada uno de ellos. Con esta informacin ya ser posible tomar decisiones
bien fundamentadas acerca de qu medidas de seguridad deben implantarse.
Por tanto, un aspecto de gran importancia a la hora de realizar la implantacin de un SGSI es tener en cuenta que la inversin en
seguridad tiene que ser proporcional al riesgo.
La informacin es generada y tratada por el personal tanto interno como externo, mediante los equipos de tratamiento de la
informacin existentes en la organizacin y est situada en las instalaciones, por lo hay que considerar todos los riesgos
relacionados con estos aspectos.
1
52
Para realizar un anlisis de riesgos se parte del inventario de activos. Si es razonablemente reducido, puede decidirse hacer el
anlisis sobre todos los activos que contiene. Si el inventario es extenso, es recomendable escoger un grupo relevante y manejable
de activos, bien los que tengan ms valor, los que se consideren estratgicos o todos aquellos que se considere que se pueden
analizar con los recursos disponibles. Se puede tomar cualquier criterio que se estime oportuno para poder abordar el anlisis de
riesgos en la confianza de que los resultados van a ser tiles.
Hay que tener en cuenta que la realizacin de un anlisis de riesgos es un proceso laborioso. Para cada activo se van a valorar
todas las amenazas que pueden afectarle, la vulnerabilidad cada una de las amenaza y el impacto que causara la amenaza en
caso de ocurrir. Con todos esos datos, se calcula el valor del riesgo para ese activo.
Independientemente de la metodologa que se utilice, el anlisis de riesgos debe ser objetivo y conseguir resultados repetibles en la
medida de lo posible, por lo que deberan participar en l todas las reas de la organizacin que estn dentro del alcance del SGSI.
De esta manera quedarn plasmados varios puntos de vista y la subjetividad, que es inevitable, quedar reducida. Adems contar
con la colaboracin de varias personas ayuda a promover el desarrollo del SGSI como una herramienta til para toda la
organizacin y no slo para la direccin o el rea que se encarga del proyecto. Se puede abordar el anlisis de riesgos con varios
enfoques dependiendo del grado de profundidad con el que se quiera o pueda realizar el anlisis:
1
Enfoque de Mnimos: Se escoge un conjunto mnimo de activos y se hace un anlisis conjunto, de manera que se emplean
una cantidad mnima de recursos, consumiendo poco tiempo y por lo tanto tiene el coste es menor. Este enfoque tienen el
inconveniente de que si se escoge un nivel bsico de seguridad muy alto, puede requerir recursos excesivos al implantarlo
para todos los activos y por el contrario, si es muy bajo, los activos con ms riesgos pueden no quedar adecuadamente
protegidos. Debido a la falta de detalle en el anlisis, puede ser difcil actualizar los controles o aadir otros segn vayan
cambiando los activos y sistemas.
53
Enfoque informal: Con este enfoque, no se necesita formacin especial para realizarlo ni necesita de tantos recursos de
tiempo y personal como el anlisis detallado. Las desventajas de este informe son que al no estar basado en mtodos
estructurados, puede suceder que se pasen por altos reas de riesgos o amenazas importantes y al depender de las
personas que lo realizan, el anlisis puede resultar con cierto grado de subjetividad. Si no se argumenta bien la seleccin de
controles, puede ser difcil justificar despus el gasto en su implantacin.
Enfoque detallado: Con este enfoque se consigue una idea muy exacta y objetiva de los riesgos a los que se enfrenta la
organizacin. Se puede decidir un nivel de seguridad apropiado para cada activo y de esa manera escoger los controles con
precisin. Es el enfoque que ms recursos necesita en tiempo, personal y dinero para llevarlo a cabo de una manera efectiva.
Enfoque combinado: Con un enfoque de alto nivel al principio, permite determinar cules son los activos en los que habr que
invertir ms antes de utilizar muchos recursos en el anlisis. Por ello ahorra recursos al tratar antes y de manera ms exhaustiva los
riesgos ms importantes mientras que al resto de los riesgos slo se les aplica un nivel bsico de seguridad, con lo que consigue un
nivel de seguridad razonable en la organizacin con recursos ajustados. Es el enfoque ms eficaz en cuanto a costes y a
adaptabilidad a empresas con recursos limitados. Hay que tener en cuenta que si el anlisis de alto nivel es errneo puede que
queden algunos activos crticos a los que no se realice un anlisis detallado.
1
Identificar amenazas
Como ya se ha visto anteriormente, podramos denominar amenaza a un evento o incidente provocado por una entidad natural,
humana o artificial que, aprovechando una o varias vulnerabilidades de un activo, pone en peligro la confidencialidad, la integridad o
la disponibilidad de ese activo. Dicho de otro modo, una amenaza explota la vulnerabilidad del activo.
Atendiendo a su origen, existen dos tipos de amenazas:
1
Externas: Son las causadas por alguien (hackers, proveedores, clientes, etc.) o algo que no pertenece a la organizacin.
Ejemplos de amenazas de este tipo son los virus y las tormentas.
Internas: Estas amenazas son causadas por alguien que pertenece a la organizacin, por ejemplo errores de usuario o
errores de configuracin.
Las amenazas tambin pueden dividirse en dos grupos segn la intencionalidad del ataque en deliberadas y accidentales:
1
Deliberadas: Cuando existe una intencin de provocar un dao, por ejemplo un ataque de denegacin de servicio o la
ingeniera social.
54
Accidentales: Cuando no existe tal intencin de perjudicar, por ejemplo averas o las derivadas de desastres naturales:
terremotos, inundaciones, fuego, etc.
Para valorar las amenazas en su justa medida hay que tener en cuenta cual sera el impacto en caso de que ocurrieran y a cual o
cules son los parmetros de seguridad que afectara, si a la confidencialidad, la integridad o la disponibilidad.
1
Identificacin de vulnerabilidades
Tal y como hemos comentado anteriormente, una vulnerabilidad es toda aquella circunstancia o caracterstica de un activo que
permite la materializacin de ataques que comprometen la confidencialidad, integridad o disponibilidad del mismo. Por ejemplo, un
equipo ser vulnerable a los virus si no tiene un programa antivirus instalado.
Hay que identificar las debilidades en el entorno de la Organizacin y valorar cmo de vulnerable es el activo en una escala
razonable (alto-medio-bajo, de 1 a 5, etc.).
Hay que tener en cuenta que la presencia de una vulnerabilidad por si misma no causa dao. Para que se produzca este dao debe
existir una amenaza que pueda explotarla.
Algunos ejemplos de vulnerabilidades son:
1
Tener usuarios sin formacin adecuada, que compromete la confidencialidad, la integridad y la disponibilidad de los activos,
ya que pueden filtrar informacin o cometer errores sin ser conscientes del fallo.
Con el equipo de trabajo asignado para ello y la metodologa escogida, se llevar a cabo el anlisis de riesgos. Los participantes
tendrn que valorar las amenazas y las vulnerabilidades que afectan a los activos escogidos para el anlisis y el impacto que
ocasionara que alguna de las amenazas realmente ocurriera, sobre la base de su conocimiento y experiencia dentro de la
organizacin
55
La gestin de esos riesgos implica seleccionar e implantar las medidas tcnicas y organizativas necesarias para impedir, reducir o
controlar los riesgos identificados, de forma que los perjuicios que puedan causar se eliminen o, si esto no es posible, se reduzcan
lo mximo posible.
Un resultado del anlisis de riesgos habr sido el criterio para determinar cules van a ser los niveles de riesgo aceptables y en
consecuencia, cules van a ser los niveles inaceptables y que por lo tanto son susceptibles de ser gestionados. La gestin de los
riesgos tiene como objetivo reducir los riesgos que estn por encima de los niveles aceptables, a niveles que puedan ser asumidos
por la organizacin.
Una vez que conocemos los riesgos de la organizacin y decidido el tratamiento que se le va a dar para cada uno de los activos, se
deben tomar acciones en consecuencia. Los cuatro tipos de tratamiento requieren de acciones de distinta naturaleza:
1
Mitigar el riesgo: Reducirlo mediante la implantacin de controles que reduzcan el riesgo a un nivel aceptable, implica
seleccionar dichos controles, definir y documentar los mtodos para ponerlos en marcha y gestionarlos.
Asumir el riesgo: La Direccin asume el riesgo ya que est por debajo de un valor de riesgo aceptable, simplemente
requiere que quede documentado que la direccin conoce y acepta estos riesgos. Los riesgos que se han asumido han de
ser controlados y revisados peridicamente de cara a evitar que evolucionen y se conviertan en riesgos mayores.
Transferir el riesgo a un tercero: Como por ejemplo, asegurando el activo que tiene el riesgo o subcontratando el servicio.
Deben evaluarse las opciones y tomar las acciones pertinentes para ejecutar la opcin escogida, en funcin del valor del
activo y del coste de realizar esta transferencia (no slo coste econmico sino tambin los riesgos que conlleva esta
transferencia en cuanto a la inclusin de un tercero).
56
Eliminar el riesgo: Aunque no suele ser la opcin ms viable, ya que puede resultar difcil o demasiado costoso, si se cree
posible o necesario, habr que establecer los pasos para conseguirlo: eliminar el activo, eliminar el proceso o incluso el rea
de negocio que es la fuente del riesgo.
No caben ms acciones a la hora de gestionar los riesgos para la correcta implantacin de un sistema de gestin de la seguridad de
la informacin, ya que una organizacin que conoce sus riesgos jams podr ignorarlos, puesto que, de este modo, no estara
vigilando que no se convirtiesen en riesgos que la organizacin no es capaz de asumir o que, por no haberlos tenido en cuenta, se
materialicen y den lugar a un incidente de seguridad.
Una vez decididas las acciones a tomar, se debe realizar un nuevo anlisis de riesgos, teniendo en cuenta la nueva situacin
considerando que los controles y medidas que se ha decidido implantar van a reducir en mayor o menor medida el riesgo que
exista, ya que ese es su objetivo. El nivel de riesgo resultante de este segundo anlisis es el riesgo residual. Este se define como
el riesgo remanente que existe despus de que se hayan tomado las medidas de seguridad apropiadas
En una organizacin nunca se podr eliminar totalmente el riesgo, siempre quedar un cierto nivel de riesgo, por lo que es
importante que todos los riesgos residuales sean aceptados por la Direccin.
1
57
1. Seleccionar los controles apropiados para los riesgos a los que se quiere hacer frente, en principio del Catlogo de Buenas
Prcticas de la ISO/IEC 27002 (133 controles posibles), pero pueden aadirse otros que la organizacin considere necesario.
2. Implantar los controles para lo que deben desarrollarse procedimientos. Aunque sean controles tecnolgicos deben
desarrollarse para su instalacin, uso y mantenimiento.
3. Verificar que los controles estn correctamente implantados.
4. Establecer indicadores para saber en qu medida la implantacin de los controles seleccionados reduce el riesgo a un nivel
aceptable.
Los controles se seleccionarn e implementarn para minimizar en lo posible la posibilidad de que los riesgos detectados en el
anlisis de riesgos daen los activos.
Existen dos grandes grupos de controles. Por un lado los tcnicos, tales como sistemas de cifrado, copias de seguridad, sistemas
de deteccin de intrusos, actualizaciones de software, antivirus o cortafuegos, y por otro los organizativos que son medidas
organizativas tales como la Poltica de Seguridad, procedimientos de uso de los sistemas de informacin para los usuarios, los
planes de formacin o los planes de continuidad del negocio.
Es muy importante conseguir un conjunto de controles que contenga controles de los dos tipos, ya que muchas medidas tcnicas no
pueden impedir que los usuarios de los sistemas cometan errores o daen intencionadamente los activos y, al contrario, emitir
muchas normas internas puede ser intil si no hay una mnima seguridad tcnica implantada.
Por ejemplo, el estudio del uso de ordenadores porttiles para trabajos fuera de las instalaciones de la organizacin puede haber
determinado que existe un riesgo alto de robo para los porttiles. Se pueden escoger varios controles para mitigar este riesgo. Uno
de ellos ser disear unas normas de utilizacin de este tipo de activos, que obligue a los usuarios a no dejar sus porttiles
desatendidos y a no dejarlos a la vista en el coche. Con este control es probable que se reduzca la probabilidad de robo, sin
embargo la posibilidad todava existe. As que es necesario tomar otras medidas como el cifrado del disco duro y un proceso de
autenticacin de usuario, que servirn para reducir el dao a la confidencialidad que se producira si el equipo es robado.
La combinacin de las medidas tcnicas y organizativas consigue un nivel de seguridad razonable con unos recursos limitados para
el escenario de riesgo que se trataba de mitigar.
58
Otra clasificacin que se puede hacer de los controles para facilitar su seleccin es la de controles preventivos y correctivos. Los
controles de tipo preventivo son aquellos que sirven para evitar incidentes de seguridad no deseados mientras que los correctivos
son aquellos que se pondrn en marcha ante la ocurrencia de fallos o incidentes de seguridad.
Por ejemplo, para prevenir accesos no autorizados a una red se crean cuentas de usuario y se otorgan privilegios a estos usuarios,
diferenciando aquellos que s pueden acceder de los que no. En el caso de que ocurriera un acceso no autorizado, por ejemplo, un
empleado que ha cambiado de departamento y conserva sus antiguos privilegios de los que hace uso, lgicamente primero hay que
ser capaces de detectarlo y una vez detectado, esos privilegios deberan ser automticamente eliminados. Muchos controles estn
interrelacionados, por lo que hay que tener en cuenta estas dependencias para que no queden lagunas de seguridad que puedan
suponer nuevas vulnerabilidades.
Hay que tener en cuenta que la implantacin de un control requiere de ciertos recursos y su mantenimiento tambin. Por lo tanto
hay que valorar al escoger un control, si se cuenta con dinero y mano de obra suficientes tanto para ponerlos en marcha como para
gestionarlos.
Esto significa que hay que considerar varios factores y restricciones a la hora de seleccionar un control, ya que puede darse el caso
de que a pesar de cubrir un riesgo detectado, no se puede o no debe ser aplicado, como por ejemplo:
1. El mencionado coste de la implementacin y el mantenimiento del control. Por ejemplo, se escoge el control 11.6.1
Restriccin del acceso a la informacin y para implantarlo se decide instalar un firewall. Esta decisin tiene el coste de su
compra, ms el de su instalacin, configuracin y gestin.
2. La disponibilidad del control. Puede ser necesario instalar un firewall pero si el modelo especfico necesario para la
organizacin tiene un plazo de entrega muy largo, puede ser necesario optar por alguna otra medida al menos
temporalmente.
3. Ayuda que hay que otorgar a los usuarios para desempear su funcin. Siguiendo con el ejemplo del firewall, hay que
considerar que el responsable de su gestin dentro de la organizacin debe saber hacerlo. Si no es as, habr que valorar
darle formacin o bien subcontratar el servicio. Adems los usuarios de la red vern probablemente restringidos sus
privilegios de acceso, por lo que habr que informar de la nueva situacin y buscar soluciones alternativas si surge algn
problema.
4. Controles que ya existen y slo hace falta modificarlos. Si se diera el caso de que ya existe un firewall en la organizacin
realizando las funciones requeridas por el control, quizs se pueda solucionar el problema con un cambio en la configuracin
o con una actualizacin del software. Tambin podra suceder que ya hay aplicados otros controles que mitigan el mismo
riesgo, y aadir otro resulte excesivo o demasiado costoso.
59
5. Su aplicabilidad de acuerdo con los riesgos detectados. En cualquier caso, si no hay un riesgo claro en la organizacin
respecto a los accesos a la informacin, la aplicacin del control 11.6.1 no estara justificada.
No todos los controles deben ser seleccionados, pero los hay que siempre deben ser implantados si no lo estn ya y son aquellos
que constituyen un requisito de la Norma UNE/ISO-IEC 27001 tales como la Poltica de Seguridad o las auditoras internas.
Seleccionados los controles pertinentes, debe definirse los procedimientos para su implantacin. Los controles de tipo organizativo
se prestan ms a ser implantados mediante procedimientos, como por ejemplo la gestin de los recursos humanos. Pero incluso los
de corte tecnolgico pueden ser susceptibles de necesitar documentacin, como por ejemplo la realizacin de copias de seguridad.
Debe analizarse la lista de controles seleccionados y establecer qu procedimientos necesitan ser desarrollados. Hay que contar
tambin que si la organizacin no tiene procesos muy complejos puede ser posible que varios controles puedan agruparse en un
nico procedimiento. No es necesario ni recomendable, desarrollar un procedimiento para cada control. La cantidad de
documentacin generada puede hacer francamente difcil que se logren gestionar correctamente los controles. Por otro lado, los
procedimientos deben ser lo ms breves y claros posible. No deben incluir demasiadas instrucciones ni particularidades de la tarea
a realizar. El objetivo del procedimiento es contar con una herramienta que permita a cualquiera ejecutarla con un mnimo de rigor
aun sin contar con formacin o experiencia previa.
Una vez puestos en marcha, debe comprobarse peridicamente que los controles funcionan como se esperaba. Si no es as,
debern tomarse las acciones necesarias para corregir esa situacin.
Una herramienta fundamental del SGSI es la verificacin de la eficacia de los controles implantados. Para ello deben establecerse
objetivos de rendimiento para los controles, marcar puntos de control y medicin y registrar los resultados de manera que se sepa si
el control realmente protege los activos hasta el punto que la organizacin necesita.
Por ejemplo, se detecta el riesgo de que los puestos de usuarios se infecten de virus, por lo que se determina aplicar el control
10.4.1, Controles contra el cdigo malicioso. Para implantar este control se decide instalar en todos los puestos un antivirus
actualizable automticamente a diario. Se prepara la compra de la aplicacin, se valoran distintas opciones, se compra la que se
considera ms apropiada y el responsable de sistemas se encarga de instalarla en todos los puestos. Se ha hecho un gasto para la
compra del material y otro de mano de obra del responsable de sistemas, para los que he necesario presentar una justificacin. Esta
justificacin vendr dada por la reduccin de las infecciones de virus en los puestos y la consiguiente reduccin de horas de trabajo
perdidas solucionando estas incidencias. Si hasta la instalacin del antivirus tenamos 4 infecciones mensuales, en las que se
empleaban 6 horas de trabajo, los objetivos pueden declararse como sigue:
1. Reducir el N de infecciones /mes a 2
2. Reducir el N de horas empleadas en repararlas/mes a 3
60
Se establece que semanalmente el responsable de sistemas comprobar el nmero de infecciones y registrar el tiempo empleado
en su resolucin, reportando los resultados mensualmente. Los registros de los tres meses siguientes son:
1. Mes 1. N de infecciones 0. Horas empleadas en reparacin. 0
2. Mes 2. N de infecciones 3. Horas empleadas en la reparacin: 3
3. Mes 3. N de infecciones 1. Horas empleadas en la reparacin: 2
De estos datos podemos inferir que ms o menos se est consiguiendo el objetivo, y en cualquier caso ha habido una reduccin
significativa de las prdidas en trminos de costes de horas de trabajo que originaban las infecciones, que justifican sobradamente
la inversin en la compra e instalacin del antivirus.
1. DOCUMENTAR LA GESTIN DE RIESGOS
La documentacin de la gestin de riesgos se realiza mediante la Declaracin de Aplicabilidad tambin conocida por sus siglas en
ingls SOA (Statement Of Applicability). Este documento, requerido por la Norma UNE/ISO-IEC 27001, es un resumen de las
decisiones que se han tomado para tratar los riesgos analizados.
Este documento registra todo lo que se ha realizado y se va a realizar en el futuro inmediato para que la seguridad de la informacin
de la organizacin llegue al nivel que se haya estimado apropiado para sus necesidades y recursos. La declaracin de aplicabilidad
debe incluir los 133 controles del Anexo A de la Norma, mas los controles adicionales a los de la Norma que la organizacin hubiera
estimado conveniente aplicar. Para cada uno de los controles debe reflejarse en este documento:
1. Si est implantado actualmente en la organizacin, con una breve descripcin de cmo se aplica.
2. Si se va a implantar, es decir, si es uno de los controles escogidos para mitigar el riesgo, junto con las razones para haberlo
seleccionado.
3. Si no se va a implantar, y entonces hay que exponer los motivos que han llevado a esta decisin. Las exclusiones deben
justificarse adecuadamente.
61
El principal objetivo de este documento es que, al tener que repasar todos y cada uno de los controles, se hace una comprobacin
de que no se ha pasado por alto ningn control por error o descuido, que podra ser til o necesario para la gestin de la seguridad
de la informacin.
Este documento constituye de alguna manera un registro de los resultados finales del SGSI, ya que concreta de manera clara y
directa en qu va a consistir el sistema de seguridad, detallando cada uno de los controles que se tiene la intencin de aplicar de
manera explcita.
Slo insistir en que no es necesario seleccionar todos los objetivos ni todos los controles asociados a cada uno de los objetivos.
Deben escogerse los objetivos y controles apropiados a las circunstancias, es decir, aquellos que se considera que cubren los
requisitos de seguridad de la organizacin y son viables.
Una vez que est claro que se va a hacer, debe prepararse un plan para la realizacin de todo lo que se ha decidido hacer. Este
plan, que la Norma denomina Plan de Tratamiento de Riesgos, contempla todo las acciones necesarias tanto para implantar el
SGSI y gestionarlo como para la puesta en marcha de los controles escogidos.
El plan tiene que contar con los recursos materiales, tcnicos y humanos necesarios para que pueda ser llevado a cabo con ciertas
garantas de xito. Debe ser revisado a intervalos regulares para comprobar que no se producen desviaciones. Estas pueden ser de
plazo porque no hay recursos para ejecutarlas o han resultado ser ms difciles de ejecutar de lo que se prevea en un principio o
tambin de que no se llevan a cabo las acciones planificadas sino otras, normalmente porque se han tomado decisiones sobre la
marcha para solventar problemas no previstos.
Dentro de este plan pueden quedar recogidos los objetivos definidos para medir la eficacia de los controles, estableciendo asimismo
el mecanismo de recogida y anlisis.
Curso de sistema de gestin de la seguridad de la informacin segn la norma UNE-ISO/IEC 27000 68El avance en la consecucin
de los objetivos suele ser unos de los puntos que se tratan en el Comit de Seguridad, ya que es en este Comit donde se deciden
los objetivos y se modifican segn sea necesario.
62
Paso 1
Para el caso prctico se ha tomado como ejemplo SENA. El inventario de activos para el desarrollo del SGSI. Es el mostrado en
la tabla que se encuentra ms abajo con el ttulo de "Valoracin de Activos. En primer lugar deberamos valorar cada parmetro
de seguridad, para calcular el valor de los activos, segn los siguientes criterios:
DISPONIBILIDAD
Valor
Criterio
No aplica / No es relevante
INTEGRIDAD
Valor
Criterio
No aplica / No es relevante
63
64
CONFIDENCIALIDAD
Valor
Criterio
No aplica / No es relevante
65
Los valores totales son la suma de los valores de los tres parmetros.
VALORACIN DE ACTIVOS
Tipo
Activo
Confidencialidad
Integridad
Disponibilidad
Valor
Total
Aplicaciones de
gestin
Aplicaciones
comerciales
Servidores
Puestos de
usuario
Red de
comunicaciones
Oficinas
Empleados
Subcontratados
Expedientes
Software
Hardware
Instalaciones
Personal
Datos
66
VALORACIN DE ACTIVOS
Tipo
Activo
Confidencialidad
Integridad
Disponibilidad
Valor
Total
Contabilidad
Paso 2
Para realizar el Anlisis de Riesgos, se muestran en las tablas "Valores de Riesgos I y II" los activos con su valor y una lista de
amenazas. En esta siguiente fase se ha de valorar la probabilidad de ocurrencia de las amenazas segn el siguiente criterio:
PROBABILIDAD
Valor
Criterio
10%
20%
40%
60%
80%
100%
VALORES DE RIESGO I
67
Difusi
n de
softw
are
dain
o
Fue
go
Inunda
cin
Fallo
del
sumini
stro
elctric
o
10%
10%
20%
40%
100%
60%
80%
60%
40%
Fallo de las
comunicac
iones
Error
es de
los
usuar
ios
Errores
del
administr
ador
Errores
organizat
ivos
Destruc
cin de
informa
cin
Aplicacion
es de
gestin
0,7
0,7
1,4
2,8
4,2
5,6
4,2
2,8
Aplicacion
es
comerciale
s
0,4
0,4
0,8
1,6
2,4
3,2
2,4
1,6
Servidores
0,4
0,4
0,8
1,6
2,4
3,2
2,4
1,6
Puestos de
usuario
0,4
0,4
0,8
1,6
2,4
3,2
2,4
1,6
Red de
comunicaci
ones
0,7
0,7
1,4
2,8
4,2
5,6
4,2
2,8
Oficinas
0,6
0,6
1,2
2,4
3,6
4,8
3,6
2,4
Empleados
0,6
0,6
1,2
2,4
3,6
4,8
3,6
2,4
Subcontrat
ados
0,5
0,5
Expediente
s
0,9
0,9
1,8
3,6
5,4
7,2
5,4
3,6
Contabilida
68
El valor del riesgo para cada amenaza se calcula segn la siguiente frmula:
Riesgo= Valor del activo * probabilidad de ocurrencia de la amenaza
Tomaremos el valor de riesgo para el activo ser el mayor valor que arrojen los valores individuales de cada amenaza.
VALORES DE RIESGO II
Valor
del
activ
o
Probabilidad
Difusin
de
informaci
n
Fallos de
mantenimie
nto de
hardware
Fallos de
mantenimie
nto de
software
Suplantaci
n de la
identidad
del usuario
Accesos
no
autoriza
do
Rob
o
Indisponibilid
ad del
personal
Ingenier
a social
40%
40%
40%
20%
40%
20%
20%
20%
Riesg
o
Aplicaciones
de gestin
2,8
2,8
2,8
1,4
2,8
1,4
1,4
1,4
Aplicaciones
comerciales
1,6
1,6
1,6
0,8
1,6
0,8
0,8
0,8
Servidores
1,6
1,6
1,6
0,8
1,6
0,8
0,8
0,8
Puestos de
usuario
1,6
1,6
1,6
0,8
1,6
0,8
0,8
0,8
Red de
comunicacion
es
2,8
2,8
2,8
1,4
2,8
1,4
1,4
1,4
69
VALORES DE RIESGO II
Valor
del
activ
o
Difusin
de
informaci
n
Fallos de
mantenimie
nto de
hardware
Fallos de
mantenimie
nto de
software
Suplantaci
n de la
identidad
del usuario
Accesos
no
autoriza
do
Rob
o
Indisponibilid
ad del
personal
Ingenier
a social
Riesg
o
Oficinas
2,4
2,4
2,4
1,2
2,4
1,2
1,2
1,2
Empleados
2,4
2,4
2,4
1,2
2,4
1,2
1,2
1,2
Subcontratad
os
Expedientes
3,6
3,6
3,6
1,8
3,6
1,8
1,8
1,8
Contabilidad
3,6
3,6
3,6
1,8
3,6
1,8
1,8
1,8
Paso 3
Haciendo un resumen, las medidas de seguridad con las que ya cuenta En el SENA son las siguientes:
(Referido a 6 controles) Seguridad fsica de las instalaciones (Correspondiente a la seguridad fsica aplicada en las
dependencias/edificios de la organizacin).
(Referido a 6 controles) Controles que aseguran a los privilegios de acceso a la informacin y los sistemas.
70
(Referido a 5 controles) Controles que establecen los procedimientos de comunicacin y resolucin de problemas e
incidencias.
Teniendo en cuenta las medidas ya implantadas y los riesgos detectados en los pasos anteriores, se han decidido implantar las
siguientes medidas de seguridad (cada una de ellas puede afectar a uno o varios controles de la norma ISO 27001):
(Referido a 2 controles) Tener una poltica de seguridad de la informacin y controlar su ciclo de vida.
(Referido a 1 control) Insertar clusulas detalladas de seguridad en los contratos con terceros.
(Referido a 3 controles) Establecer procedimientos para cambios y finalizacin del empleo as como para todas las acciones
relacionadas con el cese de un empleado.
(Referido a 3 controles) Controles robustos para realizar operaciones remotas (desde el exterior de la organizacin).
(Referido a 6 controles) Monitorizar y supervisar los sistemas de informacin y aplicar las medidas de seguridad apropiadas
sobre las acciones de supervisin/auditora.
71
(Referido a 3 controles) Procedimientos de instalacin del software y actualizacin del software y prohibicin de software no
autorizado.
(Referido a 3 controles) Proteccin , tratamiento y etiquetado de la informacin sensible eliminada, as como de sus
soportes.
Por ltimo en la siguiente lista aparecen los dominios y objetivos de la norma, dentro de los cuales se encuentran los 133
controles detallados en el caso prctico, de cara a establecer un contexto de cada uno de los controles
A.5. Poltica de seguridad:
A.5.1. Poltica de seguridad de la informacin.
A.6. Aspectos organizativos de la seguridad de la informacin:
A.6.1. Organizacin interna.
A.6.2. Organizacin con terceros.
A.7. Gestin de activos:
A.7.1. Responsabilidad sobre los activos.
A.7.2. Clasificacin de la informacin.
72
73
74
La gestin de esos riesgos implica seleccionar e implantar las medidas tcnicas y organizativas necesarias para impedir, reducir o
controlar los riesgos identificados, de forma que los perjuicios que puedan causar se eliminen o, si esto no es posible, se reduzcan
lo mximo posible.
Un resultado del anlisis de riesgos habr sido el criterio para determinar cules van a ser los niveles de riesgo aceptables y en
consecuencia, cules van a ser los niveles inaceptables y que por lo tanto son susceptibles de ser gestionados. La gestin de los
riesgos tiene como objetivo reducir los riesgos que estn por encima de los niveles aceptables, a niveles que puedan ser asumidos
por la organizacin.
Una vez que conocemos los riesgos de la organizacin y decidido el tratamiento que se le va a dar para cada uno de los activos, se
deben tomar acciones en consecuencia. Los cuatro tipos de tratamiento requieren de acciones de distinta naturaleza:
Mitigar el riesgo: Reducirlo mediante la implantacin de controles que reduzcan el riesgo a un nivel aceptable, implica seleccionar
dichos controles, definir y documentar los mtodos para ponerlos en marcha y gestionarlos.
75
Asumir el riesgo: La Direccin asume el riesgo ya que est por debajo de un valor de riesgo aceptable, simplemente requiere que
quede documentado que la direccin conoce y acepta estos riesgos. Los riesgos que se han asumido han de ser controlados y
revisados peridicamente de cara a evitar que evolucionen y se conviertan en riesgos mayores.
Transferir el riesgo a un tercero: Como por ejemplo, asegurando el activo que tiene el riesgo o subcontratando el servicio. Deben
evaluarse las opciones y tomar las acciones pertinentes para ejecutar la opcin escogida, en funcin del valor del activo y del coste
de realizar esta transferencia (no slo coste econmico sino tambin los riesgos que conlleva esta transferencia en cuanto a la
inclusin de un tercero).
Eliminar el riesgo: Aunque no suele ser la opcin ms viable, ya que puede resultar difcil o demasiado costoso, si se cree posible o
necesario, habr que establecer los pasos para conseguirlo: eliminar el activo, eliminar el proceso o incluso el rea de negocio que
es la fuente del riesgo.
No caben ms acciones a la hora de gestionar los riesgos para la correcta implantacin de un sistema de gestin de la seguridad de
la informacin, ya que una organizacin que conoce sus riesgos jams podr ignorarlos, puesto que, de este modo, no estara
vigilando que no se convirtiesen en riesgos que la organizacin no es capaz de asumir o que, por no haberlos tenido en cuenta, se
materialicen y den lugar a un incidente de seguridad.
Una vez decididas las acciones a tomar, se debe realizar un nuevo anlisis de riesgos, teniendo en cuenta la nueva situacin
considerando que los controles y medidas que se ha decidido implantar van a reducir en mayor o menor medida el riesgo que
exista, ya que ese es su objetivo. El nivel de riesgo resultante de este segundo anlisis es el riesgo residual. Este se define como el
riesgo remanente que existe despus de que se hayan tomado las medidas de seguridad apropiadas
En una organizacin nunca se podr eliminar totalmente el riesgo, siempre quedar un cierto nivel de riesgo, por lo que es
importante que todos los riesgos residuales sean aceptados por la Direccin.
76
1.
Seleccionar los controles apropiados para los riesgos a los que se quiere hacer frente, en principio del Catlogo de Buenas
Prcticas de la ISO/IEC 27002 (133 controles posibles), pero pueden aadirse otros que la organizacin considere necesario.
2.
Implantar los controles para lo que deben desarrollarse procedimientos. Aunque sean controles tecnolgicos deben desarrollarse
para su instalacin, uso y mantenimiento.
3.
Verificar que los controles estn correctamente implantados.
4.
Establecer indicadores para saber en qu medida la implantacin de los controles seleccionados reduce el riesgo a un nivel
aceptable.
Los controles se seleccionarn e implementarn para minimizar en lo posible la posibilidad de que los riesgos detectados en el
anlisis de riesgos daen los activos.
Existen dos grandes grupos de controles. Por un lado los tcnicos, tales como sistemas de cifrado, copias de seguridad, sistemas
de deteccin de intrusos, actualizaciones de software, antivirus o cortafuegos, y por otro los organizativos que son medidas
organizativas tales como la Poltica de Seguridad, procedimientos de uso de los sistemas de informacin para los usuarios, los
planes de formacin o los planes de continuidad del negocio.
Es muy importante conseguir un conjunto de controles que contenga controles de los dos tipos, ya que muchas medidas tcnicas no
pueden impedir que los usuarios de los sistemas cometan errores o daen intencionadamente los activos y, al contrario, emitir
muchas normas internas puede ser intil si no hay una mnima seguridad tcnica implantada.
Por ejemplo, el estudio del uso de ordenadores porttiles para trabajos fuera de las instalaciones de la organizacin puede haber
determinado que existe un riesgo alto de robo para los porttiles. Se pueden escoger varios controles para mitigar este riesgo. Uno
de ellos ser disear unas normas de utilizacin de este tipo de activos, que obligue a los usuarios a no dejar sus porttiles
desatendidos y a no dejarlos a la vista en el coche. Con este control es probable que se reduzca la probabilidad de robo, sin
embargo la posibilidad todava existe. As que es necesario tomar otras medidas como el cifrado del disco duro y un proceso de
autenticacin de usuario, que servirn para reducir el dao a la confidencialidad que se producira si el equipo es robado.
77
La combinacin de las medidas tcnicas y organizativas consigue un nivel de seguridad razonable con unos recursos limitados para
el escenario de riesgo que se trataba de mitigar.
Otra clasificacin que se puede hacer de los controles para facilitar su seleccin es la de controles preventivos y correctivos. Los
controles de tipo preventivo son aquellos que sirven para evitar incidentes de seguridad no deseados mientras que los correctivos
son aquellos que se pondrn en marcha ante la ocurrencia de fallos o incidentes de seguridad.
Por ejemplo, para prevenir accesos no autorizados a una red se crean cuentas de usuario y se otorgan privilegios a estos usuarios,
diferenciando aquellos que s pueden acceder de los que no. En el caso de que ocurriera un acceso no autorizado, por ejemplo, un
empleado que ha cambiado de departamento y conserva sus antiguos privilegios de los que hace uso, lgicamente primero hay que
ser capaces de detectarlo y una vez detectado, esos privilegios deberan ser automticamente eliminados.
Curso de sistema de gestin de la seguridad de la informacin segn la norma UNE-ISO/IEC 27000 65
Muchos controles estn interrelacionados, por lo que hay que tener en cuenta estas dependencias para que no queden lagunas de
seguridad que puedan suponer nuevas vulnerabilidades.
Hay que tener en cuenta que la implantacin de un control requiere de ciertos recursos y su mantenimiento tambin. Por lo tanto
hay que valorar al escoger un control, si se cuenta con dinero y mano de obra suficientes tanto para ponerlos en marcha como para
gestionarlos.
Esto significa que hay que considerar varios factores y restricciones a la hora de seleccionar un control, ya que puede darse el caso
de que a pesar de cubrir un riesgo detectado, no se puede o no debe ser aplicado, como por ejemplo:
El mencionado coste de la implementacin y el mantenimiento del control. Por ejemplo, se escoge el control 11.6.1 Restriccin del
acceso a la informacin y para implantarlo se decide instalar un firewall. Esta decisin tiene el coste de su compra, ms el de su
instalacin, configuracin y gestin.
La disponibilidad del control. Puede ser necesario instalar un firewall pero si el modelo especfico necesario para la organizacin
tiene un plazo de entrega muy largo, puede ser necesario optar por alguna otra medida al menos temporalmente.
Ayuda que hay que otorgar a los usuarios para desempear su funcin. Siguiendo con el ejemplo del firewall, hay que considerar
que el responsable de su gestin dentro de la organizacin debe saber hacerlo. Si no es as, habr que valorar darle formacin o
78
bien subcontratar el servicio. Adems los usuarios de la red vern probablemente restringidos sus privilegios de acceso, por lo que
habr que informar de la nueva situacin y buscar soluciones alternativas si surge algn problema.
Controles que ya existen y slo hace falta modificarlos. Si se diera el caso de que ya existe un firewall en la organizacin realizando
las funciones requeridas por el control, quizs se pueda solucionar el problema con un cambio en la configuracin o con una
actualizacin del software. Tambin podra suceder que ya hay aplicados otros controles que mitigan el mismo riesgo, y aadir otro
resulte excesivo o demasiado costoso.
Su aplicabilidad de acuerdo con los riesgos detectados. En cualquier caso, si no hay un riesgo claro en la organizacin respecto a
los accesos a la informacin, la aplicacin del control 11.6.1 no estara justificada.
No todos los controles deben ser seleccionados, pero los hay que siempre deben ser implantados si no lo estn ya y son aquellos
que constituyen un requisito de la Norma UNE/ISO-IEC 27001 tales como la Poltica de Seguridad o las auditoras internas.
Seleccionados los controles pertinentes, debe definirse los procedimientos para su implantacin. Los controles de tipo organizativo
se prestan ms a ser implantados mediante procedimientos, como por ejemplo la gestin de los recursos humanos. Pero incluso los
de corte tecnolgico pueden ser susceptibles de necesitar documentacin, como por ejemplo la realizacin de copias de seguridad.
Curso de sistema de gestin de la seguridad de la informacin segn la norma UNE-ISO/IEC 27000 66
Debe analizarse la lista de controles seleccionados y establecer qu procedimientos necesitan ser desarrollados. Hay que contar
tambin que si la organizacin no tiene procesos muy complejos puede ser posible que varios controles puedan agruparse en un
nico procedimiento. No es necesario ni recomendable, desarrollar un procedimiento para cada control. La cantidad de
documentacin generada puede hacer francamente difcil que se logren gestionar correctamente los controles. Por otro lado, los
procedimientos deben ser lo ms breves y claros posible. No deben incluir demasiadas instrucciones ni particularidades de la tarea
a realizar. El objetivo del procedimiento es contar con una herramienta que permita a cualquiera ejecutarla con un mnimo de rigor
aun sin contar con formacin o experiencia previa.
Una vez puestos en marcha, debe comprobarse peridicamente que los controles funcionan como se esperaba. Si no es as,
debern tomarse las acciones necesarias para corregir esa situacin.
Una herramienta fundamental del SGSI es la verificacin de la eficacia de los controles implantados. Para ello deben establecerse
objetivos de rendimiento para los controles, marcar puntos de control y medicin y registrar los resultados de manera que se sepa si
el control realmente protege los activos hasta el punto que la organizacin necesita.
79
Por ejemplo, se detecta el riesgo de que los puestos de usuarios se infecten de virus, por lo que se determina aplicar el control
10.4.1, Controles contra el cdigo malicioso. Para implantar este control se decide instalar en todos los puestos un antivirus
actualizable automticamente a diario. Se prepara la compra de la aplicacin, se valoran distintas opciones, se compra la que se
considera ms apropiada y el responsable de sistemas se encarga de instalarla en todos los puestos. Se ha hecho un gasto para la
compra del material y otro de mano de obra del responsable de sistemas, para los que he necesario presentar una justificacin. Esta
justificacin vendr dada por la reduccin de las infecciones de virus en los puestos y la consiguiente reduccin de horas de trabajo
perdidas solucionando estas incidencias. Si hasta la instalacin del antivirus tenamos 4 infecciones mensuales, en las que se
empleaban 6 horas de trabajo, los objetivos pueden declararse como sigue:
80
Si est implantado actualmente en la organizacin, con una breve descripcin de cmo se aplica.
Si se va a implantar, es decir, si es uno de los controles escogidos para mitigar el riesgo, junto con las razones para haberlo
seleccionado.
Si no se va a implantar, y entonces hay que exponer los motivos que han llevado a esta decisin. Las exclusiones deben justificarse
adecuadamente.
El principal objetivo de este documento es que, al tener que repasar todos y cada uno de los controles, se hace una comprobacin
de que no se ha pasado por alto ningn control por error o descuido, que podra ser til o necesario para la gestin de la seguridad
de la informacin.
Este documento constituye de alguna manera un registro de los resultados finales del SGSI, ya que concreta de manera clara y
directa en qu va a consistir el sistema de seguridad, detallando cada uno de los controles que se tiene la intencin de aplicar de
manera explcita.
Slo insistir en que no es necesario seleccionar todos los objetivos ni todos los controles asociados a cada uno de los objetivos.
Deben escogerse los objetivos y controles apropiados a las circunstancias, es decir, aquellos que se considera que cubren los
requisitos de seguridad de la organizacin y son viables.
81
Una vez que est claro que se va a hacer, debe prepararse un plan para la realizacin de todo lo que se ha decidido hacer. Este
plan, que la Norma denomina Plan de Tratamiento de Riesgos, contempla todo las acciones necesarias tanto para implantar el SGSI
y gestionarlo como para la puesta en marcha de los controles escogidos.
El plan tiene que contar con los recursos materiales, tcnicos y humanos necesarios para que pueda ser llevado a cabo con ciertas
garantas de xito. Debe ser revisado a intervalos regulares para comprobar que no se producen desviaciones. Estas pueden ser de
plazo porque no hay recursos para ejecutarlas o han resultado ser ms difciles de ejecutar de lo que se prevea en un principio o
tambin de que no se llevan a cabo las acciones planificadas sino otras, normalmente porque se han tomado decisiones sobre la
marcha para solventar problemas no previstos.
Dentro de este plan pueden quedar recogidos los objetivos definidos para medir la eficacia de los controles, estableciendo asimismo
el mecanismo de recogida y anlisis.
El avance en la consecucin de los objetivos suele ser unos de los puntos que se tratan en el Comit de Seguridad, ya que es en
este Comit donde se deciden los objetivos y se modifican segn sea necesario.
LA ORGANIZACIN ISO
ISO (Organizacin Internacional de Estndares) es una organizacin especializada en el desarrollo y difusin de los estndares a
nivel mundial.
Los miembros de ISO, son organismos nacionales que participan en el desarrollo de Normas Internacionales a travs de comits
tcnicos establecidos para tratar con los campos particulares de actividad tcnica. Los comits tcnicos de ISO colaboran en los
campos de inters mutuo con la IEC (International Electrotechnical Commission), la organizacin que a nivel mundial prepara y
publica estndares en el campo de la electrotecnologa. En el campo de tecnologa de informacin, ISO e IEC han establecido unir
un comit tcnico, ISO/IEC JTC 1 (Join Technical Committee N1).
Los borradores de estas Normas Internacionales son enviados a los organismos de las diferentes naciones para su votacin. La
publicacin, ya como una Norma Internacional, requiere la aprobacin de por lo menos el 75% de los organismos nacionales que
emiten su voto.
1
82
A semejanza de otras normas ISO, la 27000 es realmente una serie de estndares. Muchos de ellos no estn an publicados, pero
la estructura ya est definida:
1
ISO/IEC27000 Sistemas de Gestin de Seguridad de la Informacin, Generalidades y vocabulario, publicada en Abril del
2009, en la que se recogen los trminos y conceptos relacionados con la seguridad de la informacin, una visin general de
la familia de estndares de esta rea, una introduccin a los SGSI, y una descripcin del ciclo de mejora continua.
UNE-ISO/IEC 27001, Sistemas de Gestin de la Seguridad de la Informacin (SGSI). Requisitos. (ISO/IEC 27001:2005),
publicada en el ao 2007. Esta es la norma fundamental de la familia, ya que contiene los requerimientos del sistema de
gestin de seguridad de la
83
informacin y es la norma con arreglo a la cual sern certificados los SGSI de las organizaciones que lo deseen.
ISO/IEC27002, Tecnologa de la Informacin. Cdigo de buenas prcticas para la Gestin de la Seguridad de la Informacin,
publicada en el ao 2005. Esta gua de buenas prcticas describe los objetivos de control y controles recomendables en cuanto a
seguridad de la informacin.
ISO/IEC27003. Gua de implementacin de SGSI e informacin acerca del uso del modelo PDCA y de los requerimientos de sus
diferentes fases
ISO27004: Estndar para la medicin de la efectividad de la implantacin de un SGSI y de los controles relacionados.
ISO/IEC27005:2008 Gestin del Riesgo en la Seguridad de la Informacin, publicada en el ao 2008. Esta norma al pertenecer a
la familia de las Normas 27000, se ajusta a las necesidades de las organizaciones que pretende realizar su anlisis de riesgos en
este mbito y cumplir con los requisitos de la Norma ISO 27001.
ISO/IEC27006. Requisitos para las entidades que suministran servicios de auditora y certificacin de sistemas de gestin de
seguridad de la informacin. Publicada en el ao 2007. Recoge los criterios mediante los cuales una organizacin se puede
acreditar para realizar esos servicios.
ISO/IEC27007. Gua para la realizacin de las auditoras de un SGSI.
ISO/IEC27011. Directrices para la seguridad de la informacin en organizaciones de telecomunicaciones utilizando la Norma
ISO/IEC 27002. Contiene recomendaciones para empresas de este sector, facilitando el cumplimiento de la Norma ISO27001 y
conseguir un nivel de seguridad aceptable.
EN ISO27799. Gestin de la seguridad de la informacin sanitaria utilizando la Norma ISO/IEC27002 (ISO27799:2008). Vigente en
nuestro pas ya que ha sido ratificada por AENOR en agosto de 2008. Como en la anterior, es una gua sectorial que da cabida a los
requisitos especficos de entorno sanitario.
1
Orgenes
84
La Norma fue publicada como Norma Espaola en el ao 2007, pero tiene una larga historia antes de llegar a este punto.
Ya en el ao 1995 el British Standard Institute (BSI) publica la norma BS7799, un cdigo de buenas prcticas para la gestin de la
seguridad de la informacin.
A la vista de la gran aceptacin de esta Norma, en 1998, el BSI publica la norma BS7799-2, Especificaciones para los sistemas de
gestin de la seguridad de la informacin; se revisa en 2001. Tras una revisin de ambas Normas, la primera es adoptada como
norma ISO en 2000 y denominada ISO/IEC 17799.
En 2002 la norma ISO se adopta como UNE sin apenas modificacin (UNE 17799), y en 2004 se establece la norma UNE 71502,
basada en BS7799-2, sin que haya un equivalente ISO.
A partir de julio de 2007 la ISO 17799:2005 adopta el nombre de ISO 27002 y en octubre de 2007 la norma ISO 27001 se adopta
como UNE. Con la publicacin de la UNE-ISO/IEC 27001, dej de estar vigente la UNE 71502 y las empresas nacionales se
certifican ahora nicamente con esta nueva norma (UNE-ISO/IEC 27001).
1
La norma UNE-ISO/IEC 27001 especifica los requisitos para establecer, implantar, documentar y evaluar un Sistema de Gestin de
la Seguridad de la Informacin (en adelante SGSI ) de acuerdo a la Norma ISO 27002 dentro del contexto de los riesgos
identificados por la Organizacin.
Como otras Normas de gestin (ISO 9000, ISO 14001, etc.), los requisitos de esta Norma aplican a todo tipo de organizaciones,
independientemente de su tipo, tamao o rea de actividad.
Asimismo est basada en un enfoque por procesos y en la mejora continua, por lo tanto es perfectamente compatible e integrable
con el resto de sistemas de gestin que ya existan en la organizacin. La Norma asume que la organizacin identifica y administra
cualquier tipo de actividad para funcionar eficientemente. Cualquier actividad que emplea recursos y es administrada para
transformar entradas en salidas, puede ser considerada como un "proceso". A menudo, estas salidas son aprovechadas
nuevamente como entradas, generando una realimentacin de los mismos. Estos procesos se someten a revisiones para detectar
fallos e identificar mejoras, por lo que se encuentran dentro de un proceso de mejora continua.
La Norma recoge:
85
Los componentes del SGSI, es decir, en qu consiste la parte documental del sistema: qu documentos mnimos deben formar
parte del SGSI, cmo se deben crear, gestionar y mantener y cules son los registros que permitirn evidenciar el buen
funcionamiento del sistema.
1
Define los controles de seguridad a considerar. Se requiere que se escojan los controles del Anexo A, que recoge todos los
controles detallados en la Norma ISO/IEC 27002.
La ISO 27001 adopta un proceso para establecer, implementar, operar, monitorizar, revisar, mantener y mejorar el SGSI en una
organizacin.
1
Esta norma contiene 11 captulos de controles de seguridad que contienen un total de 133 controles de seguridad. Puede servir de
gua prctica para la gestin de la seguridad de la informacin. No es una norma certificable.
Los objetivos de control contemplados en la Norma son:
1. Poltica de seguridad. Cuenta con dos controles: Documento de Poltica de seguridad y Revisin del Sistema.
2. Organizacin de la seguridad de la informacin, tienen 11 controles: Compromiso de la Direccin, Identificacin de riesgos
relacionados con terceras partes.
3. Gestin de activos, con 5 controles: Utilizacin aceptable de los activos, etiquetado y tratamiento de la Informacin
4. Seguridad ligada a los Recursos Humanos con 9 controles: Anlisis y seleccin, Retirada de los derechos de acceso.
5. Seguridad fsica y del entorno tiene 13 controles: Controles fsicos de entrada, emplazamiento y proteccin de los equipos.
6. Gestin de comunicaciones y operaciones, con 32 controles es el captulo ms extenso y ms tcnico: Gestin de la Capacidad,
Proteccin frente a cdigo malicioso, Copias de seguridad, Registro de fallos
86
1. Control de acceso, cuenta con 25 controles: Gestin de contraseas de usuarios Autenticacin de usuarios para conexiones
externas, Aislamiento de sistemas sensibles.
2. Adquisicin, desarrollo y mantenimiento de SI, tiene 16 controles: Validacin de datos de entrada, Control de acceso al cdigo
fuente de los programas, control de vulnerabilidades tcnicas
3. Gestin de incidentes de seguridad de la informacin, con slo 5 controles: Informes de eventos de seguridad, Recogida de
pruebas, es sin embargo uno de los aspectos claves en la gestin de la seguridad de la informacin.
4. Gestin de la continuidad del negocio, tambin con 5 controles: Evaluacin de riesgos y continuidad del negocio Prueba,
Mantenimiento y re-evaluacin de los planes de continuidad. Es uno de los requisitos fundamentales para cualquier SGSI.
5. Conformidad, tienen 10 controles: Identificacin de la legislacin aplicable, Controles de auditora de los sistemas de
informacin.
La Norma contiene explicaciones exhaustivas de cmo se puede implantar cada uno de los controles, pero hay que tener en cuenta
que no es una norma preceptiva sino informativa, por lo que la informacin que da puede y debe ser adaptada a las necesidades y
situacin especfica de la organizacin. Debe evitarse caer en el error de tratar de seguir al pie de la letra las indicaciones que se
dan, ya que pueden ser excesivamente complejas e innecesarias para muchas organizaciones.