Sunteți pe pagina 1din 27

INDICE

No se encontraron elementos de tabla de contenido.

INTRODUCCION

La Metodologa de Gestin de Riesgos de los sistemas de


Informacin, tiene como objetivo primordial la evaluacin de los
riesgos que soportan los Sistemas de Informacin. La gestin del
riesgo para los Sistemas de Informacin, debe estar basada en un
soporte metodolgico que junto a profesionales especializados y
herramientas de un soporte adecuado.
La gestin de riesgos juega un rol crtico en la proteccin de los
activos de la organizacin. La gestin de riesgos ayuda a identificar
todos los activos importantes para la seguridad de los sistemas de
informacin, las amenazas que pueden afectarles, identificar la
vulnerabilidad de cada uno de ellos frente a estas amenazas y
calcular el riesgo existente de un posible impacto sobre el activo. Con
toda esta informacin, el responsable de seguridad puede tomar las
decisiones pertinentes para implantar medidas de seguridad
optimizando el factor riesgo-inversin.
Un efectivo proceso de gestin de riesgos es un componente
importante en el xito de la gestin de la seguridad informtica. El
objetivo principal del proceso de gestin de riesgos de una
organizacin es el de construir bases slidas para alcanzar su misin,
proteger la informacin y dems activos informticos. Por lo tanto el
proceso de gestin de riesgos tecnolgicos no debe ser llevado a
cabo nicamente por los expertos en tecnologas de la informacin
sino que debe reflejar el compromiso de los niveles gerencial,
administrativo y operativo.

Anlisis de riesgos de la seguridad de los sistemas de informacin en el


Ministerio Pblico De Cajamarca

1. Gua Metodolgica de Gestin de Riesgos en los Sistemas de


Informacin NIST SP 800-30.
NIST 800-30 es una metodologa basada en los conceptos generales
presentados en el Instituto Nacional de los Estndares y la Tecnologa
(NIST, National Institute of Standards and Technology). El propsito de la
gua es dar unos principios del desarrollo de un programa de gestin de
riesgos y proporcionar informacin de controles de seguridad a un coste
efectivo [1].
La gua tiene distintas secciones:
La seccin 2 proporciona una visin general sobre la gestin de
riesgos, explica cmo encaja dentro del ciclo de vida de desarrollo
del proyecto y los roles de las personas que soportan y utilizan
este proceso.
La seccin 3 describe la metodologa de evaluacin del riesgo y
los 9 pasos primarios para dirigir una evaluacin de riesgos de un
sistema de IT.
La seccin 4 describe el proceso de mitigacin de riesgos,
incluyendo estrategias de mitigacin de riesgos, enfoque a
implementacin y categoras de control, anlisis coste-beneficios y
riesgos residuales.
La seccin 5 discute las buenas prcticas y la necesidad de
evaluar la progresin de los riesgos, y los factores que conducirn
a un programa de gestin de riesgos exitoso.

Figura 01: Flowchart de metodologia de evaluacin de riesgos. Fuente NIST


800-30

1.1. Fases de la Evaluacin


metodolgica NIST SP 800-30

de

Riesgo

segn

la

gua

1.1.1.Fase de Caracterizacin del Sistema


El primer paso debe ser el de definir el alcance que va a tener
la evaluacin dentro de la organizacin. En este paso los
lmites del sistema de ti son identificados junto con los
recursos y la informacin que constituyen el sistema. La
caracterizacin de un sistema de ti establece el alcance de la
evaluacin de riesgos, proporciona informacin (por ejemplo
hardware, software, conectividad del sistema, y la divisin
responsable o el personal de apoyo) esencial para definir el
riesgo.
La metodologa descrita en este documento puede ser aplicada
a la evaluacin de sistemas individuales o mltiples,
interrelacionados. En el ltimo caso, es importante que el
dominio de inters, todas las interfaces y dependencias deban
ser bien definidos antes de la aplicacin de la metodologa.

a) Identificacin de la Informacin relacionada con


el sistema
La identificacin del riesgo para un sistema de
informacin requiere un hondo entendimiento del
ambiente del sistema. La persona o el equipo de
trabajo que conducen la evaluacin de riesgo, por lo
tanto,
primero
deben recoger la informacin
relacionada con el sistema, clasificada as:
Hardware y Software.
Interfaces de sistema (por ejemplo, conectividad
interna y externa)
Datos e informacin.
Equipo humano que apoyan y usan el sistema de
informacin.
Misin de sistema
Sistema y la criticidad de la data(el valor del
sistema o la importancia para la organizacin)
Sistema y sensibilidad de datos.
La informacin adicional relacionada con el ambiente
operacional del sistema de informacin y sus datos incluye,
pero no se limita a los siguientes:

Los requerimientos funcionales del sistema de


Informacin.
Los usuarios del sistema (por ejemplo, los
usuarios del sistema que proporcionan el soporte
tcnico al sistema de informacin; los usuarios de la
aplicacin que usan el sistema de informacin
para realizar funciones de negocio).
Polticas de seguridad del sistema que gobiernan el
sistema de informacin (poltica de organizacin,
exigencias federales, leyes).
Arquitectura de seguridad del sistema.
La topologa de red actual (por ejemplo, diagrama de
red).
La proteccin de medios de almacenamiento de la
Informacin de respaldo que protegen el sistema y
la disponibilidad de datos, la integridad, y la
confidencialidad.
Flujo
de
la
informacin
perteneciente
al
sistema
de
TI
(por
ejemplo, interfaces del
sistema, entradas del sistema y organigrama de
rendimiento).

Controles tcnicos usados en el sistema de


informacin
(por
ejemplo,
el producto
de
seguridad
embebido
o
complementario
que
apoya
la identificacin y la autenticacin, el
control de acceso privado y pblico, mtodos de
cifrado).
Controles de gestin usados para el sistema de TI
(por ejemplo, las reglas de comportamiento,
planificacin de seguridad).
Controles operacionales usados para el sistema
de
informacin
(por ejemplo, seguridad de
personal, respaldos, contingencia, reanudacin, y
recuperacin de las operaciones; mantenimiento de
sistema; respaldos de la informacin fuera de la
empresa; establecimiento de cuentas de usuario y
procedimientos de administracin; los controles
para la segregacin de funciones de usuario
diferenciando as polticas de acceso para usuario
privilegiado y el usuario estndar).
El entorno de seguridad fsico del sistema de
informacin (por ejemplo, polticas del centro de
datos)
La seguridad ambiental puesta en prctica para el
sistema de informacin o el
tratamiento
del
ambiente
(por
ejemplo,
controles
para
la
humedad,
el agua, alimentacin elctrica, la
contaminacin,
la
temperatura,
y
sustancias
qumicas).

Para un sistema que est iniciando o se encuentra en la fase


de diseo, la informacin del entorno del sistema puede
ser obtenida del documento de requerimientos o de
diseo.
Para un sistema en desarrollo, es necesario definir reglas de
seguridad claves
y atributos
planeados
para
el
futuro sistema de informacin. Los documentos de diseo
de sistema y el plan de seguridad de sistema pueden
proporcionar la informacin til sobre la seguridad de
un sistema de informacin que est en la fase de desarrollo.
Para un sistema de informacin operacional, los datos
son recogidos directamente
de
su
ambiente
de
produccin, incluyendo datos como la configuracin

de sistema, la conectividad
encuentre documentado o no.

todo

lo

que

se

Por lo tanto, la descripcin del sistema puede estar basada


en la seguridad proporcionada por la infraestructura
subyacente o sobre futuros proyectos de seguridad para el
sistema de informacin.
Tcnicas para la obtencin de la Informacin:
Alguna de las tcnicas, o una combinacin de ellas, pueden
ser usadas en la obtencin de la informacin relevante del
sistema de informacin dentro de su lmite operacional:
Cuestionario: Para recoger la informacin relevante,
el
personal
de evaluacin de riesgo desarrollar un
cuestionario referente a los controles de gestin y operacin
planeados o usados en el Sistema de TI. Este cuestionario
debera ser distribuido al personal tcnico y no tcnico
quienes disean o apoyan el sistema de informacin. El
cuestionario podra ser usado como una entrevista.
Entrevistas Locales: Las entrevistas al personal de
gestin y soporte del sistema de Informacin, permitir al
personal de evaluacin de riesgo recoger informacin til
(por ejemplo, como el sistema es operado y manejado).
Visitas locales tambin permiten al personal de evaluacin
de riesgo observar y juntar la informacin sobre la
seguridad fsica, ambiental, y operacional del sistema de
informacin.
El Anexo A contiene preguntas de entrevistas realizadas al
personal de sitio con el fin de entender claramente las
caractersticas operacionales de una organizacin. Para
sistemas todava en la fase de diseo, la visita local podra
proporcionar la oportunidad de evaluar el ambiente fsico en
el cual el sistema de informacin funcionar.
Revisin de Documentacin: Otra de las tcnicas es
la revisin de documentacin como por ejemplo:
Documentacin de polticas generales:
Documentacin legislativa, Documentacin de directrices.
Documentacin del sistema de informacin: Gua de usuario
del sistema, Manual administrativo del sistema, Manual del

diseo
del
requerimientos.

sistema,

Manual

de

Documentacin relacionada con la seguridad: ltimo


informe de auditora, Informe de evaluacin de riesgos,
Resultados de pruebas del sistema, Plan de seguridad del
sistema, Manual de Polticas de seguridad. Toda
esta informacin puede proporcionar una mejor visin
sobre los controles de seguridad usados y planeados para
el sistema.
Empleo de Herramienta de rastreo automatizado:
Mtodos tcnicos pueden ser usados para recoger la
informacin del sistema de manera eficiente. Por ejemplo,
una herramienta de descripcin de la red puede
identificar
los servicios
disponibles
sobre
los
computadores
clientes
y
servidores.
Adems
proporcionan un modo rpido de identificar los perfiles
individuales del sistema de informacin.
La recoleccin de Informacin puede ser conducida a travs
del proceso de evaluacin de riesgo, comprendido entre la
Caracterizacin de Sistema hasta la Documentacin de
Resultados.
Como
resultado
de
la
fase
inicial
de
la
metodologa se obtiene la caracterizacin del sistema
de informacin evaluado, una mejor visin del entorno
del sistema de informacin, y el delineamiento de las
fronteras del sistema.
1.1.2.Fase de Identificacin de Amenazas.
Una amenaza es un evento que puede producir un incidente
en la organizacin, provocando daos materiales o prdidas
inmateriales en sus activos. Una fuente potencial de amenazas no
representa ningn riesgo cuando no hay ninguna vulnerabilidad
que pueda ser ejercida.
Una vulnerabilidad es una debilidad que puede ser provocada
o
explotada intencionalmente. Las fuentes de amenazas
accidentales o deliberadas deben ser identificadas y su posibilidad
de ocurrencia debe ser evaluada.
En la determinacin de la probabilidad de una amenaza descrita a
fondo en la fase de determinacin de la probabilidad, hay que

considerar fuentes de amenaza, vulnerabilidades potenciales


detalladas en la fase de identificacin de vulnerabilidades, y
controles existentes descritos en la fase de anlisis de controles
Identificacin de las fuentes de amenaza
El objetivo de este paso es de identificar las fuentes de amenaza
potenciales y recopilar una lista de amenazas aplicables al
sistema de informacin evaluado.
Una fuente de amenaza es definida como cualquier
circunstancia
o acontecimiento
con
el
potencial
para
causar el dao a un sistema de informacin. Las fuentes
de amenazas comunes pueden ser naturales, humanas, o
ambientales.
En la evaluacin de fuentes de amenazas, es importante
considerar todas las
amenazas
potenciales
que
podran
causar dao a un sistema y a su capacidad para operar con
normalidad.
Por ejemplo, aunque el reconocimiento de amenazas para un
localizado en un desierto no pueda incluir la inundacin natural
debido a la baja probabilidad de ocurrencia de tal acontecimiento,
amenazas ambientales como un tubo que se revienta rpidamente
y que finalmente pueda inundar un cuarto de servidores y
causar dao a los activos y recursos de informacin de una
organizacin deben ser considerados.
La gente es una de las principales fuentes de amenaza
por actos intencionales, como ataques deliberados por personas
maliciosas o empleados disgustados, actos involuntarios, como
la negligencia y errores. Un ataque deliberado puede ser:

Intencin maliciosa de conseguir el acceso no


autorizado a un sistema de TI (por
ejemplo,
intentando descifrar la contrasea) afectando la
integridad
de
datos,
la disponibilidad,
o
la
confidencialidad de la informacin del sistema.

Una fuente de amenaza involuntaria, pero sin embargo


perjudicial son los eventos provocados por la
naturaleza.

Ataques deliberados como la escritura de un caballo de


Troya para violar la seguridad del sistema y
conseguir informacin confidencial de la organizacin
afectan directamente la integridad de datos.

Fuentes de amenaza Comunes


Amenazas
Naturales:
Inundaciones,
terremotos,
tornados,
derrumbes, avalanchas, tormentas elctricas,
entre otros.
Amenazas Humanas: Los acontecimientos causados
por el recurso humano, como actos involuntarios (ingreso
inadvertido de datos perjudiciales) o acciones deliberadas
(ataques directos a la red de datos, instalacin de
software malicioso, acceso no autorizado a informacin
confidencial).
Amenazas Ambientales: fallos en la alimentacin
elctrica, contaminacin, sustancias qumicas, o una fuga
lquida.
Las personas es la fuente de amenaza ms peligrosa en los
ataques a un sistema de informacin.
La definicin de las fuentes de amenaza potenciales, debern ser
adaptadas a cada organizacin basndose en la cultura de
seguridad y de acuerdo a los hbitos de los usuarios. En general,
existe mucha informacin disponible sobre amenazas naturales
como inundaciones, terremotos, tormentas, etc.
Muchas de las amenazas han sido identificadas por
organizaciones del gobierno y del sector privado. Herramientas
para la deteccin de intrusos se hacen
ms
frecuentes.
El
gobierno y las organizaciones de industria continuamente
recogen datos sobre acontecimientos de seguridad, mejorando as
la capacidad para identificar las amenazas en los sistemas de
informacin.
Las fuentes de informacin no son limitadas, entre estas
nombramos a:

Agencias de inteligencia (por ejemplo, la Polica judicial


Nacional Centro de Proteccin de Infraestructura).

Centro de Respuesta de Incidente de Ordenador


Federal (FedCIRC)
Medios de comunicacin, recursos en particular a
base
de
Web
como SecurityFocus.com,
SecurityWatch.com, SecurityPortal.com, y SANS.ORG.

Como resultado de la fase de Identificacin de Amenazas, se tiene


una lista de las fuentes de amenaza que podran explotar las
vulnerabilidades del sistema.
1.1.3.Fase de identificacin de vulnerabilidades
El anlisis de las amenazas en un sistema de informacin debe
incluir el anlisis de las vulnerabilidades asociadas con el
entorno del sistema. El objetivo de este paso es de
desarrollar
una
lista
de vulnerabilidades
del
sistema
(defectos o debilidades) que podran ser explotadas por las
fuentes de una amenaza potencial.
La tabla 1 explica ejemplos de vulnerabilidades relacionadas a las
fuentes de potenciales amenazas.
La vulnerabilidad en un
sistema de informacin es un defecto o debilidad dentro de los
procedimientos de seguridad del sistema, diseo, implementacin,
o de los controles internos.
Las mismas que podran ser usadas intencionalmente o por
casualidad para ocasionar daos en el sistema de informacin
y causar una brecha de inseguridad o una violacin de la
poltica
de
seguridad
del
sistema.
La vulnerabilidad
corresponde a la potencialidad o posibilidad de ocurrencia de la
materializacin de una amenaza sobre algn activo de la
organizacin.
Esta etapa incluye la identificacin de debilidades en el
ambiente
fsico, organizacional
procedimientos,
gestin,
administracin,
hardware,
software
o en equipos
de
comunicacin, que podran ser explotados por una fuente de
amenazas para causarle dao a un activo en particular.
Los mtodos recomendados para identificar vulnerabilidades del
sistema son el empleo de fuentes
de
informacin
de
las
potenciales vulnerabilidades, el nivel de rendimiento de las
pruebas de seguridad del sistema, y el desarrollo de una lista de
comprobacin de exigencias de seguridad.
Es importante reconocer que los tipos de vulnerabilidades
reconocidos, y la metodologa necesaria para determinar si las

vulnerabilidades estn presentes, por lo general varan


dependiendo la naturaleza del sistema de informacin y la fase en
la que se encuentra, en el SDLC (Software Development Life
Cicle):del sistema, y los anlisis de productos de seguridad
desarrollados y vendidosdetallados en white papers.

Vulnerabilidades

Fuentes de
Amenaza

Identificadores del sistema (Ej.


nombre de usuarios de correo,
de autentificacin) de empleados
despedidos
no
han
sido
removidos.

Empleados
Despedidos

El firewall de la compaa
permite el acceso de telnet por
medio del usuario invitado sobre
un servidor XYZ.

Usuarios
no
autorizados

El
vendedor
ha
detectado
defectos sobre el diseo de
seguridad de un sistema de
software,
sin
embargo,
los
nuevos parches no han sido
aplicados al sistema

Usuarios no
autorizados (Por
Ej.Hackers,
Empleados
descontentos,
Criminales,
terroristas)

El centro de datos e impresiones


posee rociadores de agua para
suprimir el incendio, sin embargo
no se posee de cobertores para
proteger el hardware y equipos
del dao del agua.

Fuego,
Negligencia del
Personal.

Acciones de
la amenaza
Ingreso a la
red de la
compaa y
acceso a los
datos
utilizando la
autentificacin
del empleado
despedido.
Usar
el
telnet
al
servidor XYZ y
buscar
archivos con
el perfil del
usuario
invitado.
Obtener el
acceso no
autorizado al
sistema de
software
inestable
conociendo la
Vulnerabilidad
del sistema.
Los
rociadores
de agua son
encendidos en
el centro de
datos e
impresiones.

Tabla 1: Vulnerabilidades relacionadas a las fuentes de potenciales


amenazas.
1.1.3.1.
Fuentes de Vulnerabilidad
Las vulnerabilidades tcnicas y no tcnicas asociadas con el
entorno de procesamiento de un sistema de TI pueden ser

identificadas por medio de las tcnicas descritas en la seccin de


tcnicas para la obtencin de la informacin. La investigacin de
otras fuentes por ejemplo, pginas de Web que
identifican
defectos y daos, sern tiles en la preparacin para las
entrevistas y en el desarrollo de cuestionarios eficaces para
identificar las vulnerabilidades que pueden ser encontradas en
un sistema de informacin especficos por ejemplo, una versin
especfica de sistema operativo.
El Internet es otra fuente de informacin sobre vulnerabilidades
conocidas en los sistemas. Las fuentes de vulnerabilidad que
deberan ser consideradas
son
las
que
nombramos
a
continuacin,
sin
embargo
no debemos
limitarnos
en
ningn momento, a investigar ms fuentes de informacin:

Documentacin previa de evaluacin de riesgo del


sistema de informacin.

Los informes de auditora del sistema de informacin,


informe de anomalas del sistema, informes de
seguridad, y los reportes de prueba y evaluacin del
sistema.

Listas de vulnerabilidades, como la base de datos de


vulnerabilidad de I-CAT NIST (http: //icat.nist.gov).

Asesoras de especialistas de seguridad informtica.

Alertas de vulnerabilidades para el Aseguramiento


de la Informacin y boletines para sistemas militares.

Anlisis de seguridad de software del sistema.

1.1.3.1.1.
Mtodos
vulnerabilidades
-

para

identificar

las

Pruebas de Seguridad del Sistema

Mtodos proactivos para la aplicacin de pruebas de


seguridad al sistema, pueden ser usados para identificar
vulnerabilidades de manera eficiente, dependiendo de
la criticidad del sistema de informacin y los
recursos asignados como por ejemplo, financiamiento,
tecnologa disponible, personas con experiencia en
implantacin de pruebas en los sistemas de informacin.
Algunos mtodos de prueba incluyen:


Herramienta automatizada de exploracin de
vulnerabilidades
Evaluacin y pruebas de seguridad (E&PS)
Pruebas de Penetracin.
Una herramienta automatizada de exploracin de
vulnerabilidades es usada para
detectar
grupos
de
usuarios
que
poseen
servicios
conocidos
como
vulnerables en una red, por ejemplo el reconocimiento
del Protocolo de Transferencia de
Archivos
(FTP)
con
usuario annimo habilitado es considerada como una
vulnerabilidad en el sistema de TI. Sin embargo, debemos
aadir, que algunas vulnerabilidades identificadas por la
herramienta de
exploracin automatizada
no
pueden representar verdaderas vulnerabilidades en el
contexto del entorno del sistema. Por ejemplo, algunas de
estas
herramientas
de
exploracin
detectan
vulnerabilidades sin considerar los requerimientos y el
entorno de la organizacin. Algunas vulnerabilidades
sealadas por el software de exploracin en realidad
no son consideradas como
vulnerables,
depende
particularmente
del
sistema
de
informacin,
posiblemente fueron configuradas as porque su ambiente lo
requiere. Por lo tanto, este mtodo de prueba puede
producir aspectos positivos falsos.
E&PS es otra tcnica que puede ser usada en la
identificacin
de vulnerabilidades del sistema de
informacin durante el proceso de evaluacin de riesgo.
Esto incluye el desarrollo y la ejecucin de un plan de
prueba (por ejemplo: descripcin
de
pruebas,
procedimientos de pruebas, y resultados esperados de las
pruebas). El objetivo de pruebas de seguridad del sistema
es de examinar la eficacia de los controles de
seguridad de un sistema de informacin y como ellos han
sido aplicados en un ambiente operacional.
El objetivo es asegurar que los controles aplicados
encuentran
en
el esquema
de
especificacin
seguridad para el software y el hardware y ponen
prctica la poltica de seguridad de la organizacin
acuerdo a las normas de la industria.

se
de
en
de

Las pruebas de penetracin pueden ser usadas para


complementar la revisin de controles de seguridad y
asegurar que los componentes del sistema de informacin
han sido protegidos correctamente.
La aplicacin de las pruebas de penetracin, en el proceso
de evaluacin de riesgo, trata de evaluar la capacidad de un
sistema de IT
y su manera de resistir tentativas
intencionales de engaar su seguridad.
Permitir de esta manera probar el sistema de
informacin e identificar fuentes de vulnerabilidades y
fallos potenciales en los esquemas de proteccin del
sistema.
-

Elaboracin de una lista de


de Requerimientos de Seguridad

comprobacin

Durante este paso, el personal de evaluacin de riesgo


determina si los requerimientos de seguridad estipulados
para el sistema de TI e investigados durante la
caracterizacin del sistema se relacionan con los
controles de seguridad existentes o planeados.
Tpicamente los requerimientos
de
seguridad
del
sistema pueden ser presentados utilizando una tabla, con
cada requerimiento acompaado por una explicacin de
como el diseo del sistema o la implementacin satisfacen
o no, aquel requerimiento de control de seguridad.
Una lista de comprobacin de requerimientos de
seguridad contiene las normas de seguridad bsicas que
pueden ser usadas para sistemticamente evaluar
e
identificar las vulnerabilidades del activo (personal,
hardware, software, y la informacin), procedimientos no
automatizados,
procesos,
y transferencias de la
informacin asociadas con un sistema de informacin dado
en las siguientes reas de seguridad:
Gerencial
Operacional
Tcnica

rea de Seguridad

Controles de S
eguridad
Asignacin de responsabilidades,So
porte continuo, Capacidad de
Respuesta inmediata a los incident
es
Revisin continua de controles
de
seguridad, Autorizacin de personal
Administracin de la seguridad Evaluacin de Riesgos, Entrenamie
nto
tcnico
y
de seguridad,
Establecimiento de Responsabilida
des,Autorizacin y Reautorizaci
n del
sistema,
Plan
de
seguridad
de aplicaciones y del sistema.

Seguridad Operacional

Seguridad Tcnica

Control de contaminacin en el me
dio
ambiente (humo, desperdicios, bas
ura)
Controles para asegurar la calidad
del
suministro
elctrico),
Acceso
y
Disponibilidad a los datos. Distribu
cin
y etiquetado de informacin ext
erna.
Protecciones, Control de la Humed
ad
Comunicaciones, Criptografa, Co
ntrol
de Acceso libre, Identificaci
n y
Autentificacin,
Deteccin
de
intromisin, Reutilizacin de ob
jetos, Auditora de sistemas

Tabla 2 Lista de Comprobacin de Requerimientos


Como resultado de este proceso tenemos una la lista de
comprobacin de requerimientos de seguridad.

Las fuentes para el desarrollo de la lista de requerimientos no son


limitadas entre las que nombramos instituciones del gobierno y
reguladoras:

CSA de 1987
Publicaciones
de
Normas
referentes
al
procesamiento de informacin
Circular A-130 del OMB - Noviembre del 2000
Acto de Aislamiento de 1974
Plan de seguridad del Sistema informacin
Poltica de seguridad de la organizacin, pautas, y
normas
Prcticas de industria.

EL
NIST
SP
800-26,
Gua
de
Autovaloracin
de
Seguridad para la tecnologa de la informacin de Sistemas,
proporciona un cuestionario extenso con objetivos de control
especficos contra los cuales un sistema o el grupo de sistemas
interconectados pueden ser probados y medidos.
Los objetivos de control han sido abstrados directamente de
requerimientos encontrados en el estatuto, las polticas, y la
direccin sobre la seguridad y la privacidad. Los resultados de la
lista de comprobacin (o el cuestionario) pueden ser usados
para una evaluacin de cumplimiento e incumplimiento.
Este proceso identifica el sistema, el proceso, y
debilidades que representan vulnerabilidades potenciales.

las

El resultado de la fase de Identificacin de Vulnerabilidades es una


lista de las vulnerabilidades del sistema que podran ser ejercidas
por las fuentes de amenaza potenciales.
1.1.4.Fase de Anlisis de Controles
El objetivo de este paso es analizar los controles que han sido
puestos en prctica, o son planeados por la organizacin
para reducir al mnimo la probabilidad de ejercer una amenaza
sobre las vulnerabilidades del sistema.
Para determinar el ndice de probabilidad que indique la
posibilidad de explotacin de una vulnerabilidad relacionada
con un ambiente general de amenazas, la implementacin de
controles debe ser considerada.
Por
ejemplo
una
vulnerabilidad
probablemente
no
es
ejercida o la probabilidad es baja si hay un nivel bajo de

fuentes de amenaza o si hay controles eficaces de seguridad


para reducir la magnitud del dao.
1.1.4.1.

Mtodos de Control

Los controles de seguridad abarcan el uso de mtodos


tcnicos y no tcnicos. Controles tcnicos son las protecciones
incorporadas en el hardware, software, o programas fijos (por
ejemplo,
identificacin
y
mecanismos
de autenticacin,
mtodos de cifrado, y software de deteccin de intrusin).
Controles no tcnicos son controles operacionales,
polticas
de seguridad; procedimientos operacionales
personal; seguridad fsica, y ambiental.
1.1.4.2.

como
y de

Categoras de Control

Las categoras de control tanto para mtodos de control tcnicos


como para no tcnicos pueden ser clasificadas como preventivo o
detectivo. Estas dos sub categoras son explicadas as: La
inhibicin de controles preventivos atenta contra las polticas de
seguridad y controles de acceso, cifrado, y autenticacin.
Controles detectivos notifican la violacin intencional de las
polticas de seguridad e incluyen controles de auditora,
mtodos de deteccin de intrusin, y errores de programacin.
1.1.4.3.

Tcnica de Anlisis de Control

Como se explic en el desarrollo de una lista


comprobacin de requerimientos de seguridad el resultado
este proceso ser provechoso en el anlisis de controles
manera eficiente y sistemtica. La lista de comprobacin
requerimientos de seguridad puede ser usada para validar
cumplimiento de seguridad.

de
de
de
de
el

Por lo tanto, es esencial poner al da tales listas de comprobacin


para reflejar cambios del ambiente de control de una organizacin
(por ejemplo, cambios de las polticas de seguridad, mtodos, y
exigencias) para asegurar la validez de la lista de comprobacin.
El resultado de la fase de Anlisis de Controles es una lista de
controles planeados usados para el sistema de informacin
permitiendo as mitigar la probabilidad de la explotacin de una
vulnerabilidad y reducir el impacto de un acontecimiento adverso
sobre la organizacin.
1.1.5.Fase de Determinacin de la Probabilidad

Para obtener la probabilidad de que una potencial vulnerabilidad


pueda ser ejecutada en unambiente de amenazas, los siguientes
factores principales deben ser considerados: Capacidad y
Motivacin
de
la fuente de amenaza, Naturaleza de la
vulnerabilidad, Existencia y eficacia de controles actuales.
La probabilidad que una vulnerabilidad potencial podra ser ejercida
por una fuente de amenaza dada puede ser descrita como alta,
media, o baja. La Tabla 3 describe estos tres niveles de probabilidad.

NIVEL
PROBABEILIDAD
ALTA

MEDIA

BAJA

DE

DEFINICION DE LA
PROBABILIDAD
La
fuente
de
amenazas
es
altamente
motivada
y
suficientemente
capaz
de
ser
ejecutada,
y
los
controles
para
prevenir
esta
probabilidad
son
realizados pero no
efectivos.
La fuente de amenaza
es motivada y capaz,
pero los
Controles
aplicados
pueden dificultar
la
ejecucin exitosa de
la vulnerabilidad.
La
fuente
de
amenaza
es
pobremente
motivada,
Existe
controles
realizados
para
prevenir
las
amenazas,
existe
dificultad
para
la
ejecucin de la
Vulnerabilidad.

Tabla 3 Niveles de Probabilidad

El resultado de la Determinacin de la Probabilidad de una


vulnerabilidad es el ndice de Probabilidad (Alta, Media, Baja).
1.1.6.Fase de Anlisis de Impacto
Dentro de la medicin del nivel de riesgo es importante
determinar
el impacto adverso, resultado de la ejecucin
exitosa de una amenaza sobre
la organizacin.
Antes de comenzar el anlisis de impacto, es necesario obtener la
siguiente
informacin necesaria como se indic en la
caracterizacin del sistema: Misin de
sistema
(procesos
realizados por el sistema de informacin), Sistema y datos,
Sistema y sensibilidad de datos.
Esta informacin puede ser obtenida de la documentacin
existente en la organizacin, como el Informe de Anlisis de
Impacto de la misin, o el informe de evaluacin de activos
crticos.
Un anlisis de impacto de misin (tambin conocido como el
anlisis de impacto de negocio [BIA] para algunas organizaciones)
prioriza los niveles de impacto asociados con el compromiso
del activo de informacin de una organizacin basado en
una evaluacin cualitativa o cuantitativa de la sensibilidad
y criticidad de aquel activo.
Un evaluacin de los activo crticos identifica y prioriza la
sensibilidad del activo de informacin de la organizacin (por
ejemplo, el hardware, el software, sistemas, servicios, y el
activo de tecnologa relacionado) que apoya a las misiones
crticas de la organizacin.
Si esta documentacin no existe o tales evaluaciones de
activos para la organizacin no
han
sido
realizadas,
el
sistema y la sensibilidad de datos

pueden ser determinados basados en el nivel de proteccin


requerida para
mantener el sistema y la disponibilidad de los datos, la
integridad, y la confidencialidad.
Independientemente del mtodo usado para determinar como
estn, el sistema de informacin y sus datos; el dueo del
sistema y de la informacin son los responsables de determinar
el nivel de impacto para su sistema de informacin. Por
consiguiente, en el anlisis del impacto, el acercamiento
apropiado es de entrevistar al dueo de la organizacin y
del sistema de informacin.
Por lo tanto, el impacto adverso de un acontecimiento de
seguridad puede ser descrito en trminos de prdida o
degradacin de alguno, o una combinacin de alguno, de
los
tres
objetivos
de
seguridad
siguientes: integridad,
disponibilidad, y confidencialidad. La lista siguiente proporciona
una breve descripcin de cada objetivo de seguridad y la
consecuencia (o el impacto) de no ser aplicado en la organizacin:
-

Prdida de Integridad. El sistema y la integridad de


datos se refieren a la exigencia de que la informacin
sea protegida de la modificacin inadecuada.
Si la prdida de la integridad del sistema o de los
datos no es corregida, seguida del empleo del
sistema contaminado o datos corrompidos podra
causar la inexactitud o decisiones errneas. Tambin, la
violacin de integridad puede ser la primera fase en
el
inicio
de
un
ataque
acertado
contra
la
disponibilidad del sistema o la confidencialidad.

Prdida de Disponibilidad. Si un sistema de


informacin no est disponible a sus usuarios finales, la
misin de la organizacin puede ser afectada. Puede
causar la prdida de tiempos en produccin.

Prdida de Confidencialidad. El sistema y la


confidencialidad de datos se refieren a la proteccin
de informacin del apoderamiento no autorizado. El
impacto
de
apoderamiento
no
autorizado
de
informacin confidencial puede extenderse desde el
descubrimiento de informacin para la seguridad
nacional al descubrimiento de datos privados.

Algunos
impactos
tangibles
pueden
ser
medidos
cuantitativamente en las utilidades perdidas, el coste de
reparar el sistema, o el nivel de esfuerzo requerido para
corregir problemas causados por una accin de una amenaza
acertada.
Otros impactos (por ejemplo, la prdida de confianza pblica,
prdida de credibilidad, dao al inters de una organizacin) no
pueden ser medidos en unidades especficas, pero pueden ser
calificados o descritos en trminos de alto, medio, y bajo como se
lo hacen en el impacto. A causa de la naturaleza genrica de
esta discusin, esta metodologa designa y describe slo las
categoras cualitativas altas, medias, y bajas de la magnitud del
impacto.

Magnitud del impacto

Alto

Medio

Bajo

Definicin del impacto


La
ejecucin
de
una
vulnerabilidad (1) puede causar
una alta prdida econmica de
los principales activos tangibles
o
recursos;
(2)
puede
significantemente violar, daar,
impedir alcanzar la misin
de la organizacin, reputacin,
o
intereses;
o
(3)
puede
causar la muerte humana o
lesiones graves.
La ejecucin de la vulnerabilidad
(1) puede resultar en la prdida
econmica de activos de la
empresa o recursos; (2) puede
violar, daar, o impedir alcanzar
la misin de la organizacin,
reputacin, o intereses; o (3)
puede resultar en lesiones
personales.
La ejecucin de la vulnerabilidad
(1) puede causar la prdida de
algunos recursos o activos
tangibles
o
(2)
puede
evidenciar un dao en la
misin
de
la organizacin,
reputacin o intereses.

Tabla 3 Descripcin de la magnitud de Impacto


Evaluacin Cuantitativa contra Evaluacin Cualitativa
En la administracin del anlisis del impacto, deberan dar a
consideracin las ventajas y las desventajas de la evaluacin
cuantitativa contra la evaluacin cualitativas. La ventaja principal
del anlisis de impacto cualitativo consiste en que este prioriza los
riesgos e identifica reas para la mejora inmediata de la direccin
de las vulnerabilidades.
La desventaja del anlisis cualitativo es que este no proporciona
las medidas especficas cuantificables de la magnitud de los
impactos, por lo tanto se dificulta la elaboracin de un
anlisis de costo-beneficio de algn control recomendado.
La ventaja principal de un anlisis de impacto cuantitativo
consiste en que este proporciona una medida de la magnitud de
impactos, que puede ser usada en el anlisis de costo-beneficio de
controles recomendados. La desventaja es que, dependiendo de
las gamas numricas usadas para expresar la medicin, el
significado del anlisis de impacto cuantitativo puede ser
confuso, requiriendo que el resultado sea interpretado en una
manera cualitativa.
Factores adicionales a menudo se deben considerar para
determinar la magnitud de impacto. Entre los que nombramos:

Una valoracin de la frecuencia de la ejecucin de la


fuente de amenaza sobre un perodo de tiempo
especfico (por ejemplo, 1 ao)
Un coste aproximado para cada acontecimiento de la
ejecucin de la fuente de amenaza.
Un factor ponderado basado en un anlisis subjetivo
del impacto relativo de la ejecucin de una amenaza
especfica sobre una vulnerabilidad especfica.

Como resultado de Anlisis de Impacto tenemos la Magnitud


de impacto (Alto, Medio o bajo)
1.1.7.Fase de Determinacin del Riesgo
El objetivo de este paso es de evaluar el nivel
en el sistema de informacin.

de

riesgo

La
determinacin
de riesgo
para una
amenaza/vulnerabilidad particular puede ser expresada como una
funcin de:

La probabilidad del intento de ejecucin de una fuente


de amenaza dada sobre una vulnerabilidad.

La magnitud del impacto determinado de una fuente de


amenaza ejecutada exitosamente.

La
determinacin
de
controles
de
seguridad
planeados o existentes para reducir o eliminar el
riesgo.
Para medir el riesgo, debe desarrollarse una escala de riesgo y
una matriz de nivel de riesgo.
Descripcin del Nivel de Riesgo
La siguiente tabla describe los niveles de riesgo mostrados
en la matriz anterior. Esta escala de riesgo, con sus posiciones de
los Altos, Medio, y Bajo, representa el grado o el nivel de
riesgo al cual un sistema de informacin podran ser expuesto
si una vulnerabilidad dada fuera ejercida.
La escala de riesgo tambin presenta acciones que la direccin,
los dueos de la organizacin, deben tomar para cada nivel de
riesgo.
La evaluacin de alto, medio y bajo, se utiliza
para determinar el nivel de ocurrencia de una amenaza
adems nos permite establecer el impacto de una amenaza sobre
la confidencialidad, integridad y disponibilidad de un activo.
Nivel de Riesgo
Alto

Medio

Bajo

Descripcin del riesgo y acciones


necesarias
Si se evala un riesgo como alto, existe la
necesidad de aplicar medidas correctivas.
Un
sistema
de
informacin puede
continuar operando, pero el plan de
acciones correctivas debe ser puesto en
prctica tan pronto como sea posible.
Si se evala un riesgo como medio,
acciones correctivas son necesarias y un
plan
debe
ser
desarrollado
para
incorporar estas acciones en un perodo
razonable de tiempo.
Si un riesgo se evala como bajo, se

debe determinar acciones de acuerdo a las


necesidades y la obtencin de un nivel de
riesgo aceptable
Tabla 4 Descripcin del Nivel de Riesgo
1.1.8.Fase de Recomendaciones de Control
Durante este paso del proceso,
controles que podran mitigar
identificados.

se proporcionan
los
o
eliminar
los riesgos

El objetivo de los controles recomendados es de reducir el nivel de


riesgo del sistema de informacin y sus datos a un nivel
aceptable.
Los factores siguientes deberan ser considerados
para recomendar controles y soluciones alternativas de reducir al
mnimo o eliminar los riesgos identificados:

Opciones recomendadas de
compatibilidad de sistema)
Legislacin y regulacin
Poltica de organizacin
Impacto operacional
Seguridad y fiabilidad.

eficacia

(por

ejemplo,

Las recomendaciones de control son los resultados de la


evaluacin de riesgo y proporcionan la entrada al proceso de
mitigacin de riesgo, durante el cual los controles de seguridad
recomendados procesales y tcnicos son evaluados, priorizados,
y puestos en prctica.
Debera ser notado que no todos los controles recomendados
pueden ser puestos en prctica para reducir la prdida. Para
determinar que los controles requeridos y apropiados para una
organizacin especfica, un anlisis de costo-beneficio debera ser
conducido se debera demostrar que los gastos de poner en
prctica los controles pueden ser justificados por la reduccin del
nivel de riesgo.
Adems, el impacto operacional (por ejemplo, el efecto sobre el
rendimiento del sistema) y la viabilidad (por ejemplo, exigencias
tcnicas, la aceptacin de usuario) de introducir la opcin
recomendada debera ser evaluada con cuidado durante el
proceso de mitigacin de riesgo.

Como resultado de la Fase de Recomendaciones de Control,


tenemos soluciones alternativas para la mitigacin del riesgo.
1.1.9.Fase de Documentacin de Resultados
Una vez que la evaluacin de riesgo ha sido completada (fuentes
de
amenaza
y vulnerabilidades identificadas, controles
evaluados, y recomendados), los resultados deberan ser
documentados en un informe oficial o dentro de una reunin
informativa. Un informe de evaluacin de riesgos es una gestin
que ayuda a la direccin de la organizacin, a los dueos de la
empresa, para la toma de decisiones sobre la poltica, procesal, el
presupuesto, y el sistema operacional y cambios de en la
gestin de la seguridad.
A diferencia de una revisin de cuentas, un informe de evaluacin
de riesgo no debe ser presentado en una manera acusatoria, ms
bien debe tener un acercamiento sistemtico y analtico a la
evaluacin del riesgo de modo que la direccin entienda los
riesgos y asigne recursos para reducir y corregir prdidas
potenciales. Por esta razn, algunas personas prefieren
dirigir amenazas y vulnerabilidades como observaciones en vez de
conclusiones en el informe de evaluacin de riesgo.
Como resultado de la Documentacin de resultados para la
evaluacin de Riesgo se tiene una descripcin de amenazas y
vulnerabilidades, mide el riesgo, y proporciona recomendaciones
para la implementacin de controles.
2. DESCRIPCION DE LA EMPRESA
a. RESUMEN HISTORICO DE LA EMPRESA
b. ESTRUCTURA ORGANIZACIONAL
(organigrama y detalle de cada area)
c. ARQUITECTURA DE INFORMACION
d. MAPA DE REDES Y UBICACIN DE EQUIPOS DE COMPUTO Y COMUNIC
ACIONES
e. DESCRIPCION DE LOS SISTEMAS INFORMATICOS UTILIZADOS
f. INFORMACION COMPLEMENTARIA DE LA EMPRESA
3. OBJETIVOS
g. Objetivo general
h. Objetivos especifico
4. ALCANCE DEL TRABAJO
5. LIMITACIONES
6. APLICACIN DE LA METODOLOGIA con todos los pasos descrito
s en el punto 3
7. MAPA DE RIESGOS Y PROPUESTAS DE CONTROLES
8. CONCLUSIONES Y RECOMENDACIONES

9. REFERENCIAS BIBLIOGRAFICAS

[1]

INTECO, Guia Avanzada de Gestion de Riesgos, 2008.