Bibliografia 04 ISO 27005 PDF

NORMA TCNICA NTP-ISO/IEC 27005
PERUANA 2009
Comisin de Normalizacin y de Fiscalizacin de Barreras Comerciales No Arancelarias - INDECOPI
Calle de La Prosa 138, San Borja (Lima 41) Apartado 145 Lima, Per
EDI. Tecnologa de la informacin. Tcnicas de seguridad.

Gestin del riesgo en seguridad de la informacin
EDI. Information technology. Security techniques. Information security risk management
(EQV. ISO/IEC 27005:2008 EDI. Information technology Security techniques Information security risk
management)
2009-09-30
1 Edicin
R.029-2009/INDECOPI-CNB. Publicada el 2009-11-07 Precio basado en 95 pginas

I.C.S: 35.040 ESTA NORMA ES RECOMENDABLE
Descriptores: EDI, tecnologa de la informacin, tcnicas de seguridad, gestin del riesgo, seguridad de la
informacin
NDICE
pgina
NDICE
PREFACIO
1. ALCANCE 1
2. REFERENCIAS NORMATIVAS 1
3. TRMINOS Y DEFINICIONES 2
4. ESTRUCTURA DE ESTA NORMA TCNICA 3

PERUANA
5. BASES 5
6. VISTA PANORMICA DEL PROCESO DE GESTIN DEL

RIESGO EN SEGURIDAD DE LA INFORMACIN 8
7. DETERMINACIN DEL CONTEXTO 12
8. EVALUACIN DEL RIESGO EN SEGURIDAD

DE LA INFORMACIN 17
9. TRATAMIENTO DEL RIESGO EN SEGURIDAD

DE LA INFORMACIN 32
10. ACEPTACIN DEL RIESGO EN SEGURIDAD

DE LA INFORMACIN 39
11. COMUNICACIN DEL RIESGO EN SEGURIDAD

DE LA INFORMACIN 40
12. MONITOREO Y REVISIN DEL RIESGO EN SEGURIDAD

DE LA INFORMACIN 42
13. ANTECEDENTES 46
i
ANEXOS
ANEXO A 47
ANEXO B 56
ANEXO C 73
ANEXO D 76
ANEXO E 82
ANEXO F 92
ii
PREFACIO
A. RESEA HISTRICA
A.1 La presente Norma Tcnica Peruana ha sido elaborada por el Comit

Tcnico de Normalizacin de Codificacin e intercambio electrnico de datos, mediante
el Sistema 1 o de Adopcin, durante el mes de agosto de 2009, utilizando como
antecedente a la norma ISO/IEC 27005:2008 Information technology Security
techniques Information security risk management.
A.2 El Comit Tcnico de Normalizacin de Codificacin e intercambio

electrnico de datos present a la Comisin de Normalizacin y de Fiscalizacin de
Barreras Comerciales No Arancelarias CNB-, con fecha 2009-08-25, el PNTP-ISO/IEC
27005:2009, para su revisin y aprobacin, siendo sometido a la etapa de Discusin
Pblica el 2009-08-28. No habindose presentado observaciones fue oficializado como
Norma Tcnica Peruana NTP-ISO/IEC 27005:2009 EDI. Tecnologa de la
informacin. Tcnicas de seguridad. Gestin del riesgo en seguridad de la
informacin, 1 Edicin, el 07 de noviembre de 2009.
A.3 Esta Norma Tcnica Peruana es una adopcin de la norma

ISO/IEC 27005:2008. La presente Norma Tcnica Peruana presenta cambios editoriales
referidos principalmente a terminologa empleada propia del idioma espaol y ha sido
estructurada de acuerdo a las Guas Peruanas GP 001:1995 y GP 002:1995.
B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIN

DE LA NORMA TCNICA PERUANA
Secretara GS1 PERU
Presidente Roberto Puy
Secretaria Mary Wong
ENTIDAD REPRESENTANTE
DISTRIBUIDORA MAYORISTA SYMBOL S.A. Adela Barcenas

Walter Equizabel
iii
DROKASA PERU S.A. Juan Aquije
E. WONG S.A. Marcela Aparicio

Rolando Bartra
FOLIUM S.A.C. Roberto Huby
IBC SOLUTIONS PERU S.A.C. Oscar Velsquez

Daniella Orellana
ITS CONSULTANTS S.A.C. Ricardo Dioses
OFICINA DE NORMALIZACION PREVISIONAL Roberto Puy
PONT. UNIV. CATOLICA DEL PERU Viktor Khlebnikov

Willy Carrera
PRESIDENCIA DEL CONSEJO Max Lzaro

DE MINISTROS Cesar Vlchez
PROCTER & GAMBLE DEL PERU S.A. Javier Kameya
SUPERINTENDENCIA DE ADMINISTRACION Daniel Llanos

TRIBUTARIA SUNAT Flor Febres
TECNOLOGA FLEXOGRAFICA S.A. Luis Chvez Saavedra
TCI S.A. Renzo Alcntara
UNILEVER ANDINA PERU S.A. Rolando Rivadeneira

Luis Villena
GS1 PERU Tatiana Pea
---oooOooo---
iv
PERUANA 1 de 95
EDI. Tecnologa de la informacin. Tcnicas de seguridad.

Gestin del riesgo en seguridad de la informacin
1. ALCANCE
Esta Norma Tcnica Peruana establece lineamientos para la gestin del riesgo en seguridad
de la informacin.
Esta Norma Tcnica Peruana apoya los conceptos generales especificados en la norma
ISO/IEC 27001 y est diseado para asistir a la implementacin satisfactoria de la
seguridad de la informacin en base a un enfoque de gestin del riesgo.
Es importante conocer los conceptos, modelos, procesos y tecnologas descritos en las

normas ISO/IEC 27001 e ISO/IEC 27002 para entender cabalmente esta NTP.
Esta Norma Tcnica Peruana es aplicable a todo tipo de organizaciones (por ejemplo:
empresas comerciales, dependencias gubernamentales, organizaciones sin fines de lucro)
que tratan de administrar los riesgos que podran comprometer la seguridad de la
informacin de la organizacin.
2. REFERENCIAS NORMATIVAS
Las siguientes normas contienen disposiciones que al ser citadas en este texto, constituyen
requisitos de esta Norma Tcnica Peruana. Las ediciones indicadas estaban en vigencia en
el momento de esta publicacin. Como toda Norma est sujeta a revisin, se recomienda a
aquellos que realicen acuerdos con base en ellas, que analicen la conveniencia de usar las
ediciones recientes de las normas citadas seguidamente. El Organismo Peruano de
Normalizacin posee la informacin de las Normas Tcnicas Peruanas en vigencia en todo
momento.
PERUANA 2 de 95
2.1 Normas Tcnicas Internacionales
2.1.1 ISO/IEC 27001:2005 Information technology Security techniques

Information security management systems
Requirements.
2.1.2 ISO/IEC 27002:2005 Information technology Security techniques

Code of practice for information security
management.
3. TRMINOS Y DEFINICIONES
Para los fines de esta NTP, se aplican los trminos y definiciones que aparecen en las
normas ISO/IEC 27001, ISO/IEC 27002 y los siguientes:
3.1 impacto: Cambio adverso en el nivel de objetivos empresariales logrados.
3.2 riesgo en la seguridad de la informacin: El potencial de que una

amenaza dada explote las vulnerabilidades de un activo o grupo de activos y cause as dao
a la organizacin.
NOTA: Se mide en trminos de una combinacin de la probabilidad de un evento y su consecuencia.
3.3 evitamiento del riesgo: Decisin de no involucrarse en una accin para

retirarse de una situacin de riesgo.
3.4 comunicacin del riesgo: Intercambio o compartir informacin sobre el

riesgo entre quien toma las decisiones y otros interesados.
3.5 estimacin del riesgo: Proceso para asignar valores a la probabilidad y

consecuencias de un riesgo.
PERUANA 3 de 95
NOTA 1: En el contexto de esta NTP, el trmino actividad se utiliza en vez del trmino proceso
para la estimacin del riesgo.
NOTA 2: En el contexto de esta NTP, el trmino posibilidad se utiliza en vez del trmino
probabilidad para la estimacin del riesgo.
3.6 identificacin del riesgo: Proceso para encontrar, listar y caracterizar

elementos de riesgo.
3.7 reduccin del riesgo: Acciones que se toman para reducir la probabilidad,
consecuencias negativas o ambas asociadas con un riesgo.
3.8 retencin del riesgo: Aceptacin de la carga de la prdida o el beneficio de

la ganancia a partir de un riesgo en particular.
NOTA: En el contexto de los riesgos para la seguridad de la informacin, slo se consideran

consecuencias negativas (prdidas) para la retencin del riesgo.
3.9 transferencia del riesgo: Compartir con otra parte la carga de la prdida o
el beneficio de la ganancia respecto de un riesgo.
NOTA: En el contexto de los riesgos para la seguridad de la informacin, slo se consideran

consecuencias negativas (prdidas) para la transferencia del riesgo.
4. ESTRUCTURA DE ESTA NORMA TCNICA PERUANA
Esta NTP contiene la descripcin del proceso de gestin del riesgo en seguridad de la
informacin y sus actividades.
El captulo 5 proporciona informacin sobre los antecedentes.
El captulo 6 proporciona una vista panormica del proceso de gestin del riesgo en
seguridad de la informacin.
PERUANA 4 de 95
Todas las actividades de gestin del riesgo en seguridad de la informacin que se presentan
en el captulo 6 se describen posteriormente en los captulos siguientes:
- Establecimiento del contexto en el captulo 7,
- Evaluacin del riesgo en el captulo 8,
- Tratamiento del riesgo en el captulo 9,
- Aceptacin del riesgo en el captulo 10,
- Comunicacin del riesgo en el captulo 11,
- Monitoreo y revisin del riesgo en el captulo 12.
En los anexos se presenta informacin adicional para las actividades de gestin del riesgo
en seguridad de la informacin. El Anexo A (Definicin del alcance y lmites del proceso
de gestin del riesgo en seguridad de la informacin) establece el contexto. El Anexo B se
refiere a la identificacin y valorizacin de los activos y evaluacin de impacto (ejemplos
para activos), el Anexo C se refiere a ejemplos de amenazas tpicas y el Anexo D a
ejemplos de vulnerabilidades tpicas.
En el Anexo E se presentan ejemplos sobre enfoques de evaluacin del riesgo en seguridad

de la informacin.
El Anexo F presenta restricciones para la reduccin del riesgo.
Todas las actividades de gestin del riesgo tal como se presentan de el captulo 7 al
captulo 12 se estructuran del modo siguiente:
Insumo: Identifica cualquier informacin requerida para realizar la actividad.
Accin: Describe la actividad.

PERUANA 5 de 95
Gua de implementacin: Provee gua sobre el desempeo de la accin. Parte de esta gua
puede no ser conveniente en todos los casos y en consecuencia otras maneras de realizar la
accin pueden ser ms apropiadas.
Producto: Identifica toda informacin derivada luego de realizar la actividad.
5. BASES
Es necesario tener un enfoque sistemtico sobre la gestin del riesgo en seguridad de la

informacin para identificar las necesidades de la organizacin respecto de los requisitos
de seguridad de la informacin y para crear un sistema eficaz de gestin de seguridad de la
informacin (ISMS, por sus siglas en ingls). Este enfoque debera ser conveniente para el
entorno de la organizacin y en particular debera estar alineado con la gestin general del
riesgo de la empresa. Los esfuerzos de seguridad deben enfrentar los riesgos de manera
eficaz y oportuna cuando y donde sea necesario. La gestin del riesgo en seguridad de la
informacin debera ser parte integral de todas las actividades de gestin de seguridad de la
informacin y debera aplicarse tanto a la implementacin como a la operacin en curso de
un ISMS.
La gestin del riesgo en seguridad de la informacin debe ser un proceso continuo. El

proceso debe establecer el contexto, evaluar los riesgos y tratarlos utilizando un plan de
tratamiento de riesgos para implementar las recomendaciones y decisiones. La gestin del
riesgo analiza lo que puede ocurrir y cules seran las consecuencias posibles, antes de
decidir qu debe hacerse y cundo para reducir el riesgo a un nivel aceptable.
La gestin del riesgo en seguridad de la informacin debe contribuir a lo siguiente:
- Identificar los riesgos.
- Evaluar los riesgos en trminos de sus consecuencias para la empresa y la

posibilidad de su ocurrencia.
- La comunicacin y comprensin de la posibilidad y consecuencias de estos

riesgos.
- El establecimiento de un orden de prioridades para el tratamiento del riesgo.

PERUANA 6 de 95
- Priorizacin de acciones para reducir la ocurrencia de riesgo.
- Participacin de los interesados cuando se toman las decisiones de gestin del

riesgo e informacin sobre la situacin de la gestin del riesgo.
- Eficacia del monitoreo del tratamiento del riesgo.
- Monitoreo y revisin regulares de los riesgos y del proceso de gestin del

riesgo.
- Captacin de informacin para mejorar el enfoque de gestin del riesgo.
- Educacin a gerentes y personal respecto a los riesgos y acciones que se toman

para mitigarlos.
El proceso de gestin del riesgo en seguridad de la informacin puede aplicarse a la

organizacin en su conjunto, a cualquier parte especfica de la organizacin (por ejemplo:
un departamento, una ubicacin fsica, un servicio), a cualquier sistema de informacin,
existente o planeado, o a aspectos particulares del control (por ejemplo: planeamiento de la
continuidad del negocio).
6. VISTA PANORMICA DEL PROCESO DE GESTIN DEL

RIESGO EN SEGURIDAD DE LA INFORMACIN
El proceso de gestin del riesgo en seguridad de la informacin consiste en establecer el

contexto (Captulo 7), evaluar el riesgo (Captulo 8), tratar el riesgo (Captulo 9), aceptar el
riesgo (Captulo 10), comunicar el riesgo (Captulo 11) y monitorear y revisar el riesgo
(Captulo 12).
PERUANA 7 de 95
DETERMINACION DEL CONTEXTO
EVALUACION DEL RIESGO
ANALISIS DEL RIESGO
MONITOREO Y EVALUACIN DEL RIESGO

IDENTIFICACION DEL RIESGO
COMUNICACIN DEL RIESGO
ESTIMACION DEL RIESGO
DECISION SOBRE EL No
RIESGO DEL PUNTO 1
Evaluacin de satisfaccin
Si
TRATAMIENTO DEL RIESGO
DECISION SOBRE EL
RIESGO DEL PUNTO 2 No
Tratamiento satisfactorio
Si
ACEPTACION DEL RIESGO
FIN DE LA PRIMERA O SUBSIGUIENTES ITERACIONES
FIGURA 1 Proceso de gestin del riesgo de seguridad de la informacin

PERUANA 8 de 95
Tal como lo ilustra la Figura 1, el proceso de gestin de seguridad de la informacin puede

ser iterativo para la evaluacin del riesgo y/o para las actividades de tratamiento del riesgo.
Un enfoque iterativo para la conduccin de la evaluacin del riesgo puede incrementar la
profundidad y detalle de la evaluacin en cada iteracin. El enfoque iterativo provee un
buen balance entre minimizar el tiempo y el esfuerzo que se emplea en identificar los
controles y a la vez asegurar que se evale apropiadamente los altos riesgos.
Primero se determina el contexto. Luego se realiza una evaluacin del riesgo. Si esto
provee suficiente informacin para determinar efectivamente las acciones requeridas para
modificar los riesgos a un nivel aceptable, entonces la tarea est completa y sigue el
tratamiento del riesgo. Si la informacin es suficiente, se conducir otra iteracin de la
evaluacin del riesgo con el contexto revisado (por ejemplo criterios de evaluacin del
riesgo, criterios de aceptacin del riesgo o criterios de impacto) posiblemente en partes
limitadas del alcance total (vase la Figura 1, Decisin sobre el Riesgo Captulo 1).
La eficacia en el tratamiento del riesgo depende de los resultados de la evaluacin del

riesgo. Es posible que el tratamiento del riesgo no conduzca inmediatamente a un nivel
aceptable de riesgo residual. En esta situacin, podra requerirse otra iteracin de la
evaluacin del riesgo con parmetros de contexto cambiados (por ejemplo evaluacin del
riesgo, aceptacin del riesgo o criterios de impacto), si fuera necesario, seguido de otro
tratamiento del riesgo (vase la Figura 1, Decisin sobre el Riesgo Captulo 2).
La actividad de aceptacin del riesgo tiene que asegurar que los gerentes de la organizacin
acepten explcitamente los riesgos residuales. Esto es especialmente importante en una
situacin donde la implementacin de controles se omite o pospone, por ejemplo debido al
costo.
Durante todo el proceso de gestin del riesgo en seguridad de la informacin es importante

que los riesgos y su tratamiento se comuniquen a los gerentes apropiados y al personal
operativo. Incluso antes del tratamiento de los riesgos puede ser muy valioso contar con
informacin sobre los riesgos identificados para administrar los incidentes y puede ayudar
a reducir el dao potencial. La conciencia de los gerentes y el personal respecto de los
riesgos, la naturaleza de los controles empleados para mitigar los riesgos y las reas de
preocupacin para la organizacin ayudan a tratar los incidentes y los eventos inesperados
de la manera ms eficaz. Deben documentarse los resultados detallados de toda actividad
del proceso de gestin del riesgo en seguridad de la informacin y de los dos puntos de
decisin sobre el riesgo.
PERUANA 9 de 95
La norma ISO/IEC 27001 especifica que los controles implementados dentro del alcance,
lmites y contexto del ISMS deben basarse en el riesgo. La aplicacin de un proceso de
gestin del riesgo en seguridad de la informacin puede satisfacer este requisito. Existen
muchos enfoques por medio de los cuales se puede implementar exitosamente el proceso
en una organizacin. La organizacin debe utilizar el enfoque que mejor se acomode a sus
circunstancias para cada aplicacin especfica del proceso.
En un ISMS, determinar el contexto, evaluar el riesgo, desarrollar un plan de tratamiento

del riesgo y aceptar el riesgo son parte de la fase del plan. En la fase de hacer del
ISMS, se implementan las acciones y controles requeridos para reducir el riesgo a un nivel
aceptable de acuerdo con el plan de tratamiento del riesgo. En la fase de verificar del
ISMS, los gerentes determinarn la necesidad de revisiones de la evaluacin del riesgo y el
tratamiento del riesgo a la luz de los incidentes y cambios en las circunstancias. En la fase
de actuar, se realizan todas las acciones requeridas, incluyendo la aplicacin adicional
del proceso de gestin del riesgo en seguridad de la informacin.
La tabla siguiente resume las actividades de gestin del riesgo en seguridad de la

informacin relevantes a las cuatro fases del proceso del ISMS:
TABLA 1 Alineamiento del ISMS y del Proceso de Gestin del Riesgo en Seguridad
de la Informacin
Proceso Proceso de Gestin del Riesgo en Seguridad de la

ISMS Informacin
Determinar el contexto
Plan Evaluar el riesgo
Desarrollar el plan de tratamiento del riesgo
Aceptar el riesgo
Hacer Implementar el plan de tratamiento del riesgo
Monitoreo y revisin continuos de los riesgos
Revisar
Hacer Mantener y mejorar el Proceso de Gestin del Riesgo en
Seguridad de la Informacin
PERUANA 10 de 95
7. DETERMINACIN DEL CONTEXTO
7.1 Consideraciones generales
Insumo: Toda la informacin sobre la organizacin que sea relevante para determinar el
contexto de la gestin del riesgo en seguridad de la informacin.
Accin: Se debera establecer el contexto para la gestin del riesgo en seguridad de la

informacin, lo cual implica establecer los criterios bsicos necesarios para la gestin del
riesgo en seguridad de la informacin (7.2), definir el alcance y los lmites (7.3) y
establecer una organizacin apropiada que opere la gestin del riesgo en seguridad de la
informacin (7.4).
Gua de implementacin
Es esencial determinar el propsito de la gestin del riesgo en seguridad de la informacin,

ya que esto afecta el proceso general y la determinacin del contexto en particular. Este
propsito puede:
- Apoyar un ISMS.
- Aplicar la ley y evidenciar diligencia debida.
- Preparar un plan de continuidad del negocio.
- Preparar un plan de respuesta al incidente.
- Describir los requisitos de seguridad de la informacin para un producto,

servicio o mecanismo.
En los captulos 7.2, 7.3 y 7.4 se trata en ms detalle la gua de implementacin para
establecer los elementos del contexto que se requieren para apoyar un ISMS.
PERUANA 11 de 95
NOTA: La norma ISO/IEC 27001 no utiliza el trmino contexto. Sin embargo, todo el captulo 7 se
refiere a los requisitos de definir el alcance y lmites del ISMS [4.2.1 a)], definir una poltica del
ISMS [4.2.1 b)] y definir el enfoque de la evaluacin del riesgo [4.2.1 c)], especificados en
ISO/IEC 27001.
Producto: La especificacin de los criterios bsicos, el alcance y los lmites y la

organizacin para el proceso de gestin del riesgo en seguridad de la informacin.
7.2 Criterios bsicos
Dependiendo del alcance y objetivo de la gestin del riesgo se puede aplicar distintos
enfoques. El enfoque tambin puede ser diferente para cada iteracin.
Se debe seleccionar o desarrollar un enfoque de gestin del riesgo apropiado que resuelva
criterios bsicos como: criterios de evaluacin del riesgo, criterios de impacto, criterios de
aceptacin del riesgo.
Adems, la organizacin debe evaluar si se dispone de los recursos necesarios para:
- Una evaluacin del riesgo y establecer un plan de tratamiento del riesgo.
- Definir e implementar polticas y procedimientos, incluyendo la

implementacin de controles seleccionados.
- Monitorear controles.
- Monitorear el proceso de gestin del riesgo en seguridad de la informacin.
NOTA: Vase tambin la norma ISO/IEC 27001 (Captulo 5.2.1) concerniente al suministro de
recursos para la operacin de implementacin de un ISMS.
PERUANA 12 de 95
Criterios de evaluacin del riesgo
Los criterios de evaluacin del riesgo deben desarrollarse para evaluar el riesgo de
seguridad para la informacin de la organizacin considerando lo siguiente:
- El valor estratgico del proceso de informacin empresarial.
- El carcter crucial de los activos de informacin involucrados.
- Requisitos legales y regulatorios y obligaciones contractuales.
- Importancia operativa y empresarial de la disponibilidad, confidencialidad e

integridad.
- Las expectativas y percepciones de los interesados as como las consecuencias

negativas para el buen nombre y la reputacin.
Adicionalmente, se puede utilizar los criterios de evaluacin del riesgo para especificar
prioridades para el tratamiento del riesgo.
Criterios de impacto
Se debe desarrollar y especificar criterios de impacto en trminos del grado de dao en

costos para la organizacin causados por un evento contra la seguridad de la informacin
considerando lo siguiente:
- Nivel de clasificacin del activo de informacin impactado.
- Infracciones a la seguridad de la informacin (por ejemplo prdida de

confidencialidad, integridad y disponibilidad)
- Operaciones impedidas (internas o de terceros)
- Lucro cesante y valor financiero.
- Perturbacin de los planes y plazos.

PERUANA 13 de 95
- Dao a la reputacin.
- Infracciones de estipulaciones legales, regulatorias o contractuales.
NOTA: Vase tambin la norma ISO/IEC 27001 [Captulo 4.2.1 d) 4] concerniente a la identificacin
de criterios de impacto para prdidas de confidencialidad, integridad y disponibilidad.
Criterios de aceptacin del riesgo
Se debe desarrollar y especificar criterios de aceptacin del riesgo. Los criterios de

aceptacin del riesgo a menudo dependen de los intereses, polticas, metas, objetivos de los
interesados en la organizacin.
Una organizacin debe definir sus propias escalas para los niveles de aceptacin del riesgo.
Durante el desarrollo se deben considerar los siguientes factores:
- Los criterios de aceptacin del riesgo pueden incluir umbrales mltiples con un
nivel objetivo deseado del riesgo, pero con advertencias para los altos gerentes
referentes a aceptar riesgos por encima de este nivel en determinadas
circunstancias.
- Se puede expresar los criterios de aceptacin del riesgo como la tasa de utilidad
estimada (u otro beneficio empresarial) respecto del riesgo estimado.
- Se puede aplicar distintos criterios de aceptacin del riesgo a distintas clases de

riesgo, por ejemplo, no se puede aceptar riesgos que podran resultar en el
incumplimiento de regulaciones o leyes, mientras que se puede permitir la
aceptacin de riesgos altos si esto se especifica como un requisito contractual.
- Los criterios de aceptacin del riesgo pueden incluir requisitos para un

tratamiento adicional futuro, por ejemplo se puede aceptar un riesgo si existe
aprobacin y compromiso de accionar para reducirlo a un nivel aceptable
dentro de un perodo definido.
PERUANA 14 de 95
Los criterios de aceptacin del riesgo pueden diferir de acuerdo a por cunto tiempo se
espera que el riesgo exista; por ejemplo, el riesgo se puede asociar con una actividad
temporal o de corto plazo. Se debe establecer los criterios de aceptacin del riesgo
considerando lo siguiente:
- Criterios empresariales
- Aspectos legales y regulatorios
- Operaciones
- Tecnologa
- Finanzas
- Factores sociales y humanitarios
NOTA: Los criterios de aceptacin del riesgo corresponden a criterios para aceptar riesgos e
identificar el nivel aceptable del riesgo, segn se especifica en la norma ISO/IEC 27001 Cpitulo
4.2.1 c) 2).
Se puede encontrar ms informacin en el Anexo A.
7.3 El alcance y los lmites
La organizacin debe definir el alcance y los lmites de la gestin del riesgo en seguridad
de la informacin.
El alcance del proceso de gestin del riesgo en seguridad de la informacin debe definirse
para asegurar que se tomen en cuenta todos los activos relevantes en la evaluacin del
riesgo. Adems se tiene que identificar los lmites [vase tambin la norma ISO/IEC 27001
Captulo 4.2.1 a)] para enfrentar los riesgos que puedan surgir dentro de esos lmites.
Se debe recolectar informacin sobre la organizacin para determinar el entorno en el que

opera y su relevancia para el proceso de gestin del riesgo en seguridad de la informacin.
Cuando se definen el alcance y los lmites, la organizacin debe considerar la informacin

siguiente:
- Los objetivos, estrategias y polticas empresariales estratgicas de la

organizacin.
PERUANA 15 de 95
- Procesos de negocios.
- Las funciones y estructura de la organizacin.
- Los requisitos legales regulatorios y contractuales aplicables a la organizacin.
- La poltica de seguridad de informacin de la organizacin.
- El enfoque general de la organizacin respecto de la gestin del riesgo.
- Activos de informacin.
- Ubicaciones de la organizacin y sus caractersticas geogrficas.
- Restricciones que afecten a la organizacin.
- Expectativa de los interesados.
- Entorno socio-cultural.
- Interfases (es decir, intercambio de informacin con el entorno).
Adicionalmente, la organizacin debe proporcionar justificacin para cualquier exclusin

del alcance.
Algunos ejemplos del alcance de la gestin del riesgo pueden ser una aplicacin de
Tecnologa de Informacin - TI, una infraestructura de TI, un proceso de negocio o una
parte definida de una organizacin.
NOTA: El alcance y lmites de la gestin del riesgo en seguridad de la informacin se relaciona al

alcance y lmites del ISMS que se requiere en la norma ISO/IEC 27001 4.2.1a).
Se puede encontrar ms informacin en el Anexo A.

PERUANA 16 de 95
7.4 Organizacin para la gestin del riesgo de seguridad en la informacin
Se debe establecer y mantener la organizacin y responsabilidades para el proceso de

gestin del riesgo en seguridad de la informacin. Los siguientes son los roles y
responsabilidades principales de esta organizacin:
- Desarrollo del proceso de gestin del riesgo en seguridad de la informacin

conveniente para la organizacin.
- Identificacin y anlisis de los interesados.
- Definicin de roles y responsabilidades de todas las partes tanto internas como

externas a la organizacin.
- Establecimiento de las relaciones requeridas entre la organizacin y los

interesados, as como las interfases con las funciones de gestin del riesgo en
las altas esferas de la organizacin (por ejemplo gestin del riesgo operativo),
as como las interfaces con otros proyectos o actividades relevantes.
- Definicin de los caminos para el escalamiento de las decisiones.
- Especificacin de los registros que deben mantenerse.
Los gerentes apropiados de la organizacin deben aprobar esta estructura.
NOTA: ISO/IEC 27001 requiere determinar y proveer los recursos necesarios para establecer,
implementar, operar, monitorear, revisar, mantener y mejorar un ISMS [5.2.1 a)]. Se puede considerar
la organizacin para las operaciones de gestin del riesgo como uno de los recursos requeridos por la
norma ISO/IEC 27001.
PERUANA 17 de 95
8. EVALUACIN DEL RIESGO EN SEGURIDAD DE LA

INFORMACIN
8.1 Descripcin general de la evaluacin del riesgo en seguridad de la

informacin
NOTA: La actividad de evaluacin del riesgo se conoce como el proceso en la norma ISO/IEC 27001.
Insumo: Determinacin de criterios bsicos, el alcance y los lmites, y la organizacin para

el proceso de gestin del riesgo en seguridad de la informacin.
Accin: Se debe identificar, cuantificar o describir cualitativamente, as como priorizar los

riesgos contra los criterios y objetivos de evaluacin del riesgo relevantes para la
organizacin.
Gua de implementacin:
Un riesgo es una combinacin de las consecuencias que se seguira de la ocurrencia de un

evento no deseado y de la posibilidad de la ocurrencia del evento. La evaluacin del riesgo
cuantifica o describe cualitativamente el riesgo y permite a los gerentes priorizar los riesgos
de acuerdo con la gravedad que perciben u otros criterios establecidos.
La evaluacin de riesgo consiste de las siguientes actividades:
- Anlisis del riesgo (vase el apartado 8.2) que comprende:
- Identificacin del riesgo (vase el apartado 8.2.1)

- Estimacin del riesgo (vase el apartado 8.2.2)
- Evaluacin del riesgo (vase el apartado 8.3)

PERUANA 18 de 95
La evaluacin del riesgo determina el valor de los activos de la informacin, identifica las
amenazas y vulnerabilidades aplicables que existen (o podran existir), identifica los
controles existentes y su efecto en el riesgo identificado, determina las consecuencias
potenciales y finalmente prioriza los riesgos derivados y los ordena respecto del conjunto
de criterios de evaluacin del riesgo establecidos en la determinacin del contexto.
La evaluacin del riesgo se conduce a menudo en dos (o ms) iteraciones. Primero se

realiza una evaluacin de alto nivel para identificar riesgos potencialmente altos que
implican una mayor evaluacin. La siguiente iteracin puede incluir otra consideracin
profunda de riesgos potencialmente altos revelados en la iteracin inicial. All donde esto
provea informacin insuficiente para evaluar el riesgo, se conducen ms anlisis detallados
probablemente en partes del alcance total y posiblemente utilizando un mtodo diferente.
La organizacin debe decidir la seleccin de su propio enfoque para la evaluacin del

riesgo en base a los objetivos y la meta de evaluacin del riesgo.
El Anexo E presenta enfoques sobre evaluacin del riesgo en seguridad de la informacin.

Producto: Una lista de riesgos evaluados priorizados de acuerdo con criterios de evaluacin
del riesgo.
8.2 Anlisis del riesgo
8.2.1 Identificacin del riesgo
8.2.1.1 Introduccin a la identificacin del riesgo
El propsito de la identificacin del riesgo es determinar qu podra suceder que cause una
prdida potencial y entender cmo, dnde y por qu podra ocurrir la prdida. Los pasos
escritos en los apartados que siguen al apartado 8.2.1 deben recolectar datos de insumos
para la actividad de estimacin del riesgo.
NOTA: Las actividades descritas en los captulos siguientes deben describirse en el siguiente orden
dependiendo de la metodologa aplicada.
PERUANA 19 de 95
8.2.1.2 Identificacin de activos
Insumo: Alcance y lmites para la evaluacin del riesgo a conducirse, lista de interesados
con propietarios, ubicacin, funcin, etc.
Accin: Se debe identificar los activos dentro del alcance establecido (se relaciona con la
norma ISO/IEC 27001, apartado 4.2.1 d) 1)).
Un activo es cualquier cosa que tenga valor para la organizacin y que por lo tanto
requiera proteccin. Para la identificacin de activos debe recordarse que un sistema de
informacin es ms que hardware y software.
La identificacin de activos debe realizarse a un nivel adecuado de detalle que proporcione

suficiente informacin para la evaluacin del riesgo. El nivel de detalle utilizado en la
identificacin de activos influenciar la cantidad general de informacin recolectada
durante la evaluacin del riesgo. El nivel puede refinarse en iteraciones posteriores de la
evaluacin del riesgo.
Se debe identificar al propietario de un activo para cada activo, para determinar las
disposiciones sobre responsabilidad y rendicin de cuentas por el activo. El propietario del
activo puede no tener derechos de propiedad sobre el activo, pero tiene responsabilidad
sobre su produccin, desarrollo, mantenimiento, uso y seguridad, segn corresponda. El
propietario del activo a menudo es la persona ms apropiada para determinar el valor que
el activo tiene para la organizacin (vase la valorizacin de activos en el apartado 8.2.2).
El lmite de revisin es el permetro de activos de la organizacin que el proceso de

gestin del riesgo en seguridad de la informacin debe administrar segn definicin.
El Anexo B contiene ms informacin sobre la identificacin y valorizacin de activos

relacionados con la seguridad de la informacin.
PERUANA 20 de 95
Producto: Una lista de activos a administrarse respecto de su riesgo y una lista de procesos
de negocio relativos a activos y su relevancia.
8.2.1.3 Identificacin de amenazas
Insumo: Informacin sobre amenazas obtenida a partir de la revisin de incidentes,

propietarios de activos, usuarios y otras fuentes, incluyendo catlogos externos de
amenazas.
Accin: Se debe identificar las amenazas y sus fuentes (relativas a la norma ISO/IEC
27001, apartado 4.2.1 d) 2)).
Una amenaza tiene el potencial de daar activos como la informacin, los procesos y los
sistemas y, por tanto, las organizaciones. Las amenazas pueden ser de origen natural o
humano y pueden ser accidentales o deliberadas. Deben identificarse tanto las fuentes de
amenazas accidentales como las deliberadas. Una amenaza puede surgir desde adentro o
desde afuera de la organizacin. Se debe identificar las amenazas de manera genrica y por
tipo (por ejemplo acciones no autorizadas, dao fsico, fallas tcnicas) y entonces cuando
sea apropiado, las amenazas individuales dentro de la clase genrica identificada. Esto
significa que no se desatiende ninguna amenaza, incluyendo las inesperadas, pero que el
volumen de trabajo requerido es limitado.
Algunas amenazas pueden afectar a ms de un activo. En dichos casos, pueden causar

distintos impactos dependiendo de qu activos sean afectados.
Se puede obtener insumos respecto de la identificacin de la amenaza y de la estimacin de

la posibilidad de ocurrencia (vase el apartado 8.2.2.3) que hacen los propietarios o
usuarios de activos, del personal de recursos humanos, de la gerencia de planta y de los
especialistas en seguridad de la informacin, expertos de seguridad fsica, departamento
legal y otras organizaciones, incluyendo organismos legales, autoridades meteorolgicas,
compaas de seguros y autoridades del gobierno nacional. Se debe considerar aspectos de
medioambiente y cultura cuando se enfrentan amenazas.
PERUANA 21 de 95
Se debe considerar la experiencia interna de incidentes y las evaluaciones de amenazas

pasadas en la evaluacin actual. Puede valer la pena consultar otros catlogos de amenazas
(quizs especficos a una organizacin o empresa) para completar la lista de amenazas
genricas, cuando sea relevante. Se dispone de catlogos y estadsticas de amenazas en
gremios industriales, gobiernos nacionales, organismos legales, compaas de seguros, etc.
Cuando se usa catlogos de amenazas o evaluaciones de los resultados de amenazas

pasadas, debemos ser conscientes de que hay un cambio continuo en las amenazas
relevantes, especialmente si el entorno empresarial o los sistemas de informacin cambian.
El Anexo C presenta ms informacin sobre tipos de amenazas.
Producto: Una lista de amenazas con la identificacin del tipo y fuente de la amenaza.
8.2.1.4 Identificacin de controles existentes
Insumo: Documentacin de controles, planes de implementacin de tratamiento de riesgos.
Accin: Se debe identificar los controles existentes y planificados.
Se debe identificar los controles existentes para evitar trabajo o costo innecesarios, por
ejemplo en la duplicacin de controles. Adems, a la vez que se identifican los controles
existentes, se debe hacer una verificacin para asegurar que los controles estn
funcionando correctamente una referencia a los informes de auditora ya existentes sobre
el ISMS limita el tiempo que se emplea en esta tarea. Si un control no funciona como se
esperaba, esto puede causar vulnerabilidades. Se debe considerar la situacin en la que un
control (o estrategia) seleccionado falle y, por lo tanto se requieran controles
complementarios para tratar de manera eficaz el riesgo identificado. En un ISMS, de
acuerdo con ISO/IEC 27001, esto se logra gracias a la medicin de la eficacia de los
controles. Una manera de estimar el efecto del control es ver cmo reduce la posibilidad de
amenaza y la facilidad de explotacin de la vulnerabilidad o impacto del incidente. Las
revisiones de la gerencia y los informes de auditora tambin proporcionan informacin
sobre la eficacia de los controles existentes.
PERUANA 22 de 95
Se debe considerar los controles que se ha planificado implementar de acuerdo con los
planes de implementacin de tratamiento de riesgo de la misma manera que aquellos que
ya se implementaron.
Un control existente y planificado puede identificarse como ineficaz, o no suficiente, o no

justificado. Si no es justificado ni suficiente, se debe verificar el control para determinar si
se le debe eliminar, si se le debe reemplazar por otro control ms adecuado o si debera
continuarse con el mismo, por ejemplo, por razones de costos.
Las siguientes actividades pueden ser tiles para la identificacin de controles existentes o
planeados:
- Revisin de documentos que tienen informacin sobre los controles (por

ejemplo, planes de implementacin de tratamiento del riesgo). Si los procesos
de gestin de seguridad de la informacin estn bien documentados, se debe
disponer de todos los controles existentes o planeados y de su situacin de
implementacin;
- Verificacin de la seguridad de la informacin con las personas responsables

(por ejemplo el funcionario encargado de la seguridad de la informacin y el
funcionario encargado de la seguridad del sistema de informacin, el gerente de
construccin o el gerente de operaciones) y los usuarios respecto de qu
controles se implementan realmente para el proceso de informacin o el
sistema de informacin que se est considerando;
- Conduccin de una revisin in-situ de los controles fsicos, comparando los

implementados con la lista de qu controles debera tenerse y verificando los
implementados respecto de si estn funcionando de manera correcta y eficaz, o
- Revisin de resultados de auditoras internas.
Producto: Una lista de todos los controles existentes y planeados, su implementacin y su

condicin de uso.
8.2.1.5 Identificacin de vulnerabilidades
Insumo: Una lista de amenazas conocidas, listas de activos y controles existentes.

PERUANA 23 de 95
Accin: Se debe identificar las vulnerabilidades que las amenazas pueden explotar para
causar dao a los activos o a la organizacin (se relaciona con la norma ISO/IEC 27001,
apartado 4.2.1 d) 3)).
Se puede identificar vulnerabilidades en las reas siguientes:
- Organizacin
- Procesos y procedimientos
- Rutinas administrativas
- Personal
- Entorno fsico
- Configuracin del sistema de informacin
- Hardware, software o equipo de comunicaciones
- Dependencia de partes externas
La presencia de una vulnerabilidad no causa dao en s misma, ya que se requiere una

amenaza para explotarla. Una vulnerabilidad que no tiene amenaza correspondiente puede
no requerir la implementacin de un control, pero se debera reconocer y monitorear para
observar sus cambios. Debe notarse que un control implementado de manera incorrecta o
que funcione mal puede ser en s mismo una vulnerabilidad. Un control puede ser eficaz o
ineficaz dependiendo del entorno en el que opera. Inversamente, una amenaza que no tiene
una vulnerabilidad correspondiente puede no resultar en un riesgo.
Las vulnerabilidades se pueden relacionar con propiedades del activo que se pueden utilizar
de una manera o por un propsito que el que se desea cuando se compr o hizo el activo.
Se tienen que considerar vulnerabilidades que surgen de distintas fuentes, por ejemplo, las
que son intrnsecas o extrnsecas al activo.
En el Anexo D se puede encontrar ejemplos de vulnerabilidades y mtodos para la

evaluacin de la vulnerabilidad.
Producto: Una lista de vulnerabilidades en relacin con los activos, amenazas y controles,
una lista de vulnerabilidades que no se relaciona a ninguna amenaza identificada para su
revisin.
PERUANA 24 de 95
8.2.1.6 Identificacin de las consecuencias
Insumo: Una lista de activos, una lista de procesos de negocios, y una lista de amenazas y
vulnerabilidades donde sea apropiado en relacin con los activos y su relevancia.
Accin: Se debe identificar las consecuencias que pueden tener las prdidas de
confidencialidad, integridad y disponibilidad (vase la norma ISO/IEC 27001, apartado
4.2.1 d) 4)).
Una consecuencia puede hacer perder eficacia, puede haber condiciones operativas
adversas, lucro cesante, dao a la reputacin, etc.
Esta actividad identifica el dao o las consecuencias a la organizacin que un incidente

podra causar. El escenario de un incidente es la descripcin de una amenaza que explota
una cierta vulnerabilidad o conjunto de vulnerabilidades en un incidente de vulnerabilidad
de la informacin (vase la norma ISO/IEC 27002, Captulo 13). El impacto de los
escenarios del incidente debe determinarse considerando criterios de impacto definidos
durante la actividad de determinacin del contexto. Puede afectar a uno o ms activos o a
parte de un activo. De esta manera, los activos pueden tener valores asignados para su
costo financiero y debido a las consecuencias para la empresa si se les daa o compromete.
Las consecuencias pueden ser de naturaleza temporal o permanente como en el caso de la
destruccin de un activo.
NOTA: La norma ISO/IEC 27001 describe la ocurrencia de escenarios de incidentes como fallas de
seguridad.
Las organizaciones deben identificar las consecuencias operativas de los escenarios de

incidentes en trminos de los siguientes elementos sin limitarse a los mismos:
- Tiempo de investigacin y reparacin

- Tiempo (trabajo) perdido
- Oportunidad perdida
- Salud y seguridad fsica
PERUANA 25 de 95
- Costo financiero de habilidades especficas para reparar el dao

- Reputacin de la imagen y buen nombre
En B3, Evaluacin de impacto, se puede encontrar detalles sobre la evaluacin de

vulnerabilidades tcnicas.
Producto: Una lista de escenarios de incidentes con sus consecuencias relacionadas a los
activos y procesos de negocios.
8.2.2 Estimacin del riesgo
8.2.2.1 Metodologas para la estimacin del riesgo
Se debe realizar el anlisis del riesgo en grados variables de detalle dependiendo del
carcter crucial de los activos, extensin de las vulnerabilidades conocidas e incidentes
previos que involucran a la organizacin. Una metodologa de estimacin puede ser
cualitativa o cuantitativa o una combinacin de ambas dependiendo de las circunstancias.
En la prctica, se usa a menudo la estimacin cualitativa para obtener primero una
indicacin general del nivel de riesgo y para revelar los riesgos ms importantes. Luego
puede ser necesario realizar anlisis ms especficos o cuantitativos sobre los riesgos ms
importantes porque a menudo es menos complejo y menos caro realizar anlisis
cualitativos que anlisis cuantitativos.
La forma del anlisis debe ser consistente con los criterios de evaluacin del riesgo
desarrollados como parte de la determinacin del contexto.
A continuacin se describe los detalles de las metodologas de estimacin:
(a) Estimacin cualitativa:
La estimacin cualitativa usa una escala de atributos calificadores para describir la

magnitud de las consecuencias potenciales (por ejemplo, baja, media y alta) y la posibilidad
de que esas consecuencias ocurran. Una ventaja de la estimacin cualitativa es su facilidad
de comprensin por todo el personal relevante, mientras que una ventaja es la dependencia
en una eleccin subjetiva de la escala.
PERUANA 26 de 95
Estas escalas pueden adaptarse o ajustarse para acomodarse a las circunstancias y se puede
usar distintas descripciones para distintos riesgos. Se puede usar estimacin cualitativa:
- Como una actividad de clasificacin inicial para identificar los riesgos que
requieran un anlisis ms detallado.
- Donde este tipo de anlisis sea apropiado para las decisiones.
- Donde los datos numricos o los recursos sean inadecuados para una
estimacin cuantitativa
El anlisis cualitativo debe usar informacin fctica y datos siempre que estn disponibles.
(b) Estimacin cuantitativa
La estimacin cuantitativa usa una escala con valores numricos (ms que escalas
descriptivas que se utilizan en la estimacin cualitativa) para las consecuencias y la
posibilidad, utilizando datos de una variedad de fuentes. La calidad del anlisis depende de
la exactitud y completitud de los valores numricos y de la validez de los modelos
utilizados. En la mayora de los casos la estimacin cuantitativa usa datos de incidentes
histricos, proveyendo la ventaja de que se puede relacionar directamente a los objetivos de
seguridad de la informacin y a las preocupaciones de la organizacin. Una desventaja es la
falta de dichos datos sobre nuevos riesgos o sobre las debilidades en la seguridad de la
informacin, Una desventaja del enfoque cuantitativo puede ocurrir donde no se disponga
de datos auditables, creando as una ilusin de valor y exactitud de la evaluacin del riesgo.
La manera en la que se expresan las consecuencias y la posibilidad y las maneras en las que
se combinan para proporcionar un nivel de riesgo variarn de acuerdo al tipo de riesgo y al
propsito para el cual se debe utilizar el producto de la evaluacin del riesgo. Se debe
considerar la incertidumbre y variabilidad de varias consecuencias y probabilidad en el
anlisis y comunicarse de manera eficaz.
PERUANA 27 de 95
8.2.2.2 Evaluacin de consecuencias
Insumo: Una lista identificada de escenarios de incidentes relevantes que incluya la

identificacin de amenazas, vulnerabilidades, activos aceptados, consecuencias a los
activos y procesos de negocio.
Accin: Se debe evaluar el impacto empresarial sobre la organizacin que podra resultar
de incidentes posibles o reales en torno a la seguridad de la informacin, tomando en
cuenta las consecuencias de una infraccin en la seguridad de la informacin tal como la
prdida de confidencialidad, integridad o disponibilidad de los activos (se relaciona con
ISO/IEC 27001, Captulo 4.2.1 e) 1)).
Luego de identificar todos los activos que se estn revisando, se debe tomar en cuenta los
valores asignados a estos activos a la vez que se evalan las consecuencias.
El valor de impacto sobre el negocio puede expresarse en formas cualitativas y

cuantitativas, pero cualquier mtodo de asignar valor monetario puede proveer
generalmente ms informacin para la toma de decisiones y por tanto facilitar un proceso
de toma de decisiones ms eficiente.
La valorizacin de activos comienza con la clasificacin de activos de acuerdo con su

carcter crucial en trminos de la importancia de los activos para satisfacer los objetivos de
negocio de la organizacin. Entonces se determina el valor utilizando dos medidas:
- El valor de reemplazo del activo: el costo de una limpieza, de la recuperacin y

de reemplazar la informacin (si es posible), y
- Las consecuencias para el negocio por prdida o compromiso del activo, como
consecuencias potenciales adversas para el negocio y/o legales o regulatorias
debido a la divulgacin, modificacin, no-disponibilidad y/o destruccin de
informacin, y otros activos de informacin.
PERUANA 28 de 95
Esta valorizacin se puede determinar desde el anlisis de impacto en el negocio. El valor,

determinado por la consecuencia para el negocio, es usualmente significativamente ms
alto que el simple costo de reemplazo, dependiendo de la importancia que tiene el activo
para que la organizacin logre sus objetivos de negocio.
La valorizacin del activo es un factor clave en la evaluacin de impacto de un escenario

de incidentes porque el incidente puede afectar a ms de un activo (por ejemplo activos
dependientes) o solamente a una parte de un activo. Las distintas amenazas y
vulnerabilidades tendrn diferentes impactos en los activos, como una prdida de
confidencialidad, integridad o disponibilidad. La evaluacin de consecuencias se relaciona
entonces a la valorizacin de los activos en base al anlisis de impacto sobre el negocio.
Las consecuencias o el impacto sobre el negocio pueden determinarse modelando los

resultados de un evento o conjunto de eventos o extrapolndolos de estudios
experimentales o datos pasados.
Se puede expresar las consecuencias en trminos de criterios monetarios, tcnicos o
humanos u otros criterios relevantes a la organizacin. En algunos casos se requiere ms de
un valor numrico para especificar las consecuencias de distintos momentos, lugares,
grupos o situaciones. Las consecuencias en el tiempo y las finanzas deben medirse con el
mismo enfoque que se utiliza para la posibilidad de amenazas y la vulnerabilidad. Se tiene
que mantener la consistencia sobre el enfoque cuantitativo o cualitativo.
En el Anexo B se puede encontrar mayor informacin sobre la valorizacin de los activos y

la evaluacin de impacto.
Producto: Una lista de consecuencias evaluadas de un escenario de incidentes expresada

con respecto a los activos y a criterios de impacto.
8.2.2.3 Evaluacin de la posibilidad de incidentes
Insumos: Una lista identificada de escenarios de incidentes relevantes, incluyendo la

identificacin de amenazas, los activos afectados, las vulnerabilidades explotadas y las
consecuencias para los activos y los procesos del negocio. Adems, listas de todos los
controles existentes y planeados, su eficacia, implementacin y condicin de uso.
PERUANA 29 de 95
Accin: La posibilidad de los escenarios de incidentes debe evaluarse (se relaciona con la
norma ISO/IEC 27001, apartado 4.2.1 e) 2)).
Luego de identificar los escenarios de incidentes, es necesario evaluar la posibilidad de que

ocurra cada escenario e impacto utilizando tcnicas de estimacin cualitativa y cuantitativa.
Esto debe tomar en cuenta cun a menudo ocurren las amenazas y con qu facilidad se
puede explotar las vulnerabilidades, considerando:
- la experiencia y las estadsticas aplicables para la posibilidad de amenazas.
- para fuentes de amenazas deliberadas: la motivacin y capacidades que

cambiarn en el tiempo y los recursos disponibles a los posibles atacantes, as
como la percepcin de la atraccin y la vulnerabilidad de los activos para un
posible atacante.
- para fuentes de amenazas accidentales: factores geogrficos, por ejemplo

proximidad a plantas qumicas o petroleras, la posibilidad de condiciones
climticas extremas y factores que podran influenciar los errores humanos y el
malfuncionamiento de los equipos.
- vulnerabilidades, tanto individualmente como de manera agregada.
- controles existentes y cun eficazmente reducen las vulnerabilidades.
Por ejemplo, un sistema de informacin puede tener una vulnerabilidad a las amenazas de
suplantacin de identidad de usuario y mal uso de recursos. La vulnerabilidad de
suplantacin de identidad de usuario puede ser alta debido a la falta de autentificacin de
usuario. Por otro lado, la posibilidad de un mal uso de recursos puede ser alta a pesar de la
falta de autentificacin de usuario porque las guas para utilizar mal los recursos son
limitadas.
Dependiendo de la necesidad de exactitud, los activos se pueden agrupar, o puede ser

necesario dividir los activos en sus elementos y relacionar los escenarios a los elementos.
Por ejemplo, a travs de sitios geogrficos la naturaleza de las amenazas a los mismos tipos
de activos puede cambiar o puede variar la eficacia de los controles existentes.
PERUANA 30 de 95
Producto: Posibilidad de escenarios de incidentes (cuantitativos o cualitativos).
8.2.2.4 Nivel de estimacin del riesgo
Insumos: Una lista de escenarios de incidentes con sus consecuencias relacionadas a

activos y procesos del negocio y su posibilidad (cuantitativa o cualitativa).
Accin: El nivel de riesgo debe estimarse para todos los escenarios de incidentes relevantes
(se relaciona con la norma ISO/IEC 27001, apartado 4.2.1 e) 4)).
La estimacin del riesgo asigna valores a la posibilidad y a las consecuencias de un riesgo.

Estos valores pueden ser cualitativos o cuantitativos. La estimacin del riesgo se basa en
las consecuencias evaluadas y en su posibilidad. Adicionalmente, puede considerar el
beneficio del costo, las preocupaciones de los intereses y otras variables, segn sea
apropiado para la evaluacin del riesgo. El riesgo estimado es una combinacin de la
posibilidad de un escenario de incidentes y sus consecuencias.
En el Anexo E se pueden encontrar ejemplos de distintos mtodos o enfoques de

estimacin del riesgo en seguridad de la informacin.
Producto: Una lista de riesgos con niveles asignados de valor.
8.3 Evaluacin del riesgo
Insumo: Una lista de riesgos con niveles asignados de valor y criterios de evaluacin del
riesgo.
Accin: El nivel de riesgo debe compararse contra los criterios de evaluacin del riesgo y
los criterios de aceptacin del riesgo (se relaciona con la norma ISO/IEC 27001, apartado
4.2.1 e) 4)).
PERUANA 31 de 95
La naturaleza de las decisiones que corresponden a la evaluacin del riesgo y a los criterios
de evaluacin del riesgo que se utilizarn para tomar esas decisiones se decidirn cuando se
establezca el contexto. Estas decisiones y el contexto deben volverse a revisar en ms
detalle en esta etapa cuando se sabe ms sobre los riesgos particulares identificados. Para
evaluar los riesgos, las organizaciones deben comparar los riesgos estimados (utilizando
mtodos o enfoques de seleccin tal como se menciona en el Anexo E) con los criterios de
evaluacin del riesgo definidos durante la determinacin del contexto.
Los criterios de evaluacin del riesgo utilizados para tomar la decisin deben ser
consistentes con el contexto de gestin del riesgo en seguridad de la informacin definido
externa e internamente y se debe tomar en cuenta los objetivos de la organizacin y el
punto de vista de los interesados, etc. Las decisiones que se toman en la actividad de
evaluacin del riesgo se basan principalmente en el nivel de riesgo aceptable. Sin embargo,
tambin se debe considerar las consecuencias, posibilidad y grado de confianza en el
riesgo, identificacin y anlisis. La agregacin de mltiples riesgos bajos o medios pueden
resultar en riesgos generales mucho ms altos que requieren tratarse de manera
correspondiente.
Las consideraciones deben incluir:
- Propiedades de la seguridad de la informacin: si un criterio no es relevante

para la organizacin (por ejemplo prdida de confidencialidad), entonces todos
los riesgos que impactan a este criterio pueden no ser relevantes.
- La importancia del proceso de negocio o actividad apoyada por un activo

particular o conjunto de activos: si se determina que el proceso es de baja
importancia, los riesgos asociados con l deben recibir una consideracin ms
baja que los riesgos que impactan a procesos o actividades ms importantes.
La evaluacin del riesgo utiliza la comprensin del riesgo obtenida por el anlisis del
riesgo para tomar decisiones sobre acciones futuras. Las decisiones deben incluir:
- Si una actividad debe realizarse.

- Las prioridades para el tratamiento del riesgo considerando niveles estimados
de riesgos.
PERUANA 32 de 95
Durante la etapa de evaluacin del riesgo, los requisitos contractuales legales y regulatorios
son factores que deben tomarse en cuenta adems de los riesgos estimados.
Producto: Una lista de riesgos priorizada de acuerdo con los criterios de evaluacin del
riesgo en relacin con los escenarios de incidentes que llevan a esos riesgos.
9. TRATAMIENTO DEL RIESGO EN SEGURIDAD DE LA

INFORMACIN
9.1 Descripcin general del tratamiento del riesgo
Insumo: Una lista de riesgos priorizada de acuerdo con criterios de evaluacin del riesgo en
relacin con los escenarios de incidentes que llevan a esos riesgos.
Accin: Se debe seleccionar controles para reducir, retener, evitar o transferir los riesgos y
un plan del tratamiento del riesgo definido.
Existen cuatro opciones disponibles para el tratamiento del riesgo: reduccin del riesgo
(vase el apartado 9.2), retencin del riesgo (vase el apartado 9.3), evitamiento del riesgo
(vase el apartado 9.4) y transferencia del riesgo (vase el apartado 9.5).
NOTA: La norma ISO/IEC 27001 4.2.1,f) 2) usa el trmino aceptar el riesgo en vez de retener el
riesgo.
La Figura 2 ilustra la actividad de tratamiento del riesgo dentro del proceso de gestin del
riesgo en seguridad de la informacin tal como se presenta en la Figura 1.
PERUANA 33 de 95
RESULTADOS DE LA
EVALUACION
SATISFACTORIA
Decisin sobre el
riesgo punto 1
Tratamiento del riesgo
OPCIONES DE TRATAMIENTO DEL RIESGO
REDUCCION RETENCION EVITAMIENTO TRANSFERENCIA

DEL RIESGO DEL RIESGO DEL RIESGO DEL RIESGO
RIESGOS RESIDUALES
Decisin sobre el
riesgo punto 2
TRATAMIENTO
SATISFACTORIO
FIGURA 2 Actividad de tratamiento del riesgo

PERUANA 34 de 95
Las opciones de tratamiento del riesgo deben seleccionarse en base al resultado de la

evaluacin del riesgo, el costo esperado de implementar esas opciones y el beneficio
esperado de esas opciones.
Cuando se puede obtener grandes reducciones en el riesgo con un gasto relativamente bajo,
dichas opciones deben implementarse. Las opciones adicionales para mejoras pueden ser
no econmicas y se tiene que utilizar el criterio para decidir si son justificables.
En general, las consecuencias adversas de los riesgos deben hacerse tan bajas como sea
practicable razonablemente y sin importar criterios absolutos. Los gerentes deben
considerar los riesgos poco frecuentes pero graves. En dichos casos, es posible que se tenga
que implementar controles que no son justificables desde el punto de vista estrictamente
econmico (por ejemplo, controles a la continuidad del negocio considerados para cubrir
riesgos altos especficos).
Las cuatros opciones para el tratamiento del riesgo no se excluyen mutuamente. A veces la
organizacin puede beneficiarse sustancialmente por una combinacin de opciones como la
reduccin de la posibilidad de riesgos, la reduccin de sus consecuencias, y la transferencia
o retencin de cualquier riesgo residual.
Algunos tratamientos del riesgo pueden enfrentar eficazmente ms de un riesgo (por

ejemplo, la capacitacin y concientizacin en seguridad de la informacin). Debe definirse
un plan de tratamiento del riesgo que identifique claramente la prioridad ordenando en
cules tratamientos del riesgo individual debe implementarse y su horizonte temporal. Se
puede establecer prioridades utilizando varias tcnicas, incluyendo puntajes de riesgo y
anlisis costo-beneficio. Es responsabilidad de los gerentes de la organizacin el decidir el
equilibrio entre los costos de implementar controles y la asignacin presupuestal.
La identificacin de controles existentes puede determinar que los controles existentes

excedan las necesidades corrientes en trminos de comparaciones de costos, incluyendo el
mantenimiento. Si se considera eliminar los controles redundantes e innecesarios
(especialmente si los controles tienen altos costos de mantenimiento), debe tomarse en
cuenta la seguridad de la informacin y los factores del costo. Debido a que los controles
pueden influenciar unos a otros, la eliminacin de los controles redundantes puede reducir
la seguridad general que existe. Adems, puede ser ms barato dejar en funcionamiento
controles redundantes o innecesarios que eliminarlos.
PERUANA 35 de 95
Se debe considerar las opciones de tratamiento del riesgo tomando en cuenta:
- Cmo las partes afectadas perciben el riesgo.
- Las maneras ms apropiadas de comunicarse con esas partes.
El establecimiento del contexto (vase el apartado 7.2 Criterios de valorizacin del

riesgo) provee informacin sobre requisitos legales y regulatorios sobre los cuales la
organizacin debe cumplir. El riesgo para las organizaciones es el no cumplimiento y
deben implementarse las opciones de tratamiento para limitar esta posibilidad. Todas las
restricciones organizativas, tcnicas, estructurales, etc. que se identifiquen durante la
actividad de determinacin del contexto deben tomarse en cuenta durante el tratamiento del
riesgo.
Una vez que el plan de tratamiento del riesgo se ha definido, se tiene que determinar los
riesgos residuales. Esto incluye una actualizacin o reiteracin de la evaluacin del riesgo,
tomando en cuenta los efectos esperados del tratamiento propuesto del riesgo. Si el riesgo
residual todava no cumple con los criterios de aceptacin del riesgo de la organizacin,
puede ser necesaria una nueva iteracin del tratamiento del riesgo antes de proceder a la
aceptacin del riesgo. Se puede encontrar ms informacin en la norma ISO/IEC 27002,
Captulo 0.3.
Producto: Plan de tratamiento del riesgo y riesgos residuales sujetos a la decisin de

aceptacin por parte de los gerentes de la organizacin.
9.2 Reduccin del riesgo
Accin: El nivel de riesgo debe reducirse a travs de la seleccin de controles de tal modo
que el riesgo residual se pueda re-evaluar como aceptable.
PERUANA 36 de 95
Se debe seleccionar controles apropiados y justificados para cumplir con los requisitos
identificados por la evaluacin y el tratamiento del riesgo. Esta seleccin debe tomar en
cuenta los criterios de aceptacin del riesgo as como los requisitos legales regulatorios y
contractuales Esta seleccin tambin debe tomar en cuenta el costo y el horizonte temporal
para la implementacin de controle sobre los aspectos tcnicos, ambientales y culturales. A
menudo es posible reducir el costo total de la propiedad de un sistema con controles de
seguridad de la informacin seleccionados apropiadamente.
En general, los controles pueden proporcionar uno o ms de los siguientes tipos de

proteccin: correccin, eliminacin, prevencin, minimizacin del impacto, disuasin,
recuperacin, monitoreo y conciencia. Durante la seleccin del control es importante
contrapesar el costo de adquisicin, implementacin, administracin, operacin, monitoreo
y mantenimiento de los controles contra el valor de los activos que se estn protegiendo.
Adems, se debe considerar el retorno sobre la inversin en trminos de reduccin del
riesgo y del potencial de explotar nuevas oportunidades de negocio que los controles
permitan. Adicionalmente, se debe considerar las habilidades especializadas que se pueden
requerir para definir e implementar nuevos controles o modificar los existentes.
La norma ISO/IEC 27002 provee informacin detallada sobre controles.
Existen muchas restricciones que pueden afectar la seleccin de controles. Las restricciones
tcnicas como los requisitos de desempeo, administrabilidad, requisitos de apoyo
operativo y cuestiones de compatibilidad pueden obstaculizar el uso de ciertos controles o
inducir a error humano ya sea anulando el control, dando una falsa sensacin de seguridad
o incluso incrementando el riesgo ms all del control. Por ejemplo, el requerir claves
complejas sin capacitacin adecuada lleva a los usuarios a escribir las claves. Ms an,
podra ser el caso que un control afecte el desempeo. Los gerentes deben tratar de
identificar una solucin que satisfaga los requisitos de desempeo y a la vez garantice
suficiente seguridad de la informacin. El resultado de este paso es una lista de controles
posible con su costo, beneficio y prioridad de implementacin.
Se debe tomar en cuenta varias restricciones cuando se selecciona controles y durante la

implementacin. Normalmente se consideran los siguientes:
- Restricciones de tiempo.
PERUANA 37 de 95
- Restricciones financieras.
- Restricciones tcnicas.
- Restricciones operativas.
- Restricciones culturales.
- Restricciones ticas.
- Restricciones ambientales.
- Restricciones legales.
- Facilidad de uso.
- Restricciones personales.
- Restricciones para integrar controles nuevos y existentes,
En el Anexo F se puede encontrar ms informacin sobre las restricciones a la reduccin

del riesgo.
9.3 Retencin del riesgo
Accin: La decisin de retener el riesgo sin acciones ulteriores debe tomarse dependiendo
de la evaluacin del riesgo.
NOTA: La norma ISO/IEC 27001, apartado 4.2.1 f) 2) aceptar riesgos a sabiendas y de manera
objetiva siempre y cuando cumplan claramente las polticas de la organizacin y los criterios para la
aceptacin de riesgos describe la misma actividad.
Si el nivel de riesgo satisface los criterios de aceptacin del riesgo no es necesario

implementar controles adicionales y se puede retener el riesgo.
PERUANA 38 de 95
9.4 Evitamiento del riesgo
Accin: Se debe evitar la actividad o condicin que ocasiona el riesgo particular.
Cuando los riesgos identificados se consideran demasiado altos o los costos de

implementar otras opciones de tratamiento del riesgo exceden los beneficios, se puede
tomar la decisin de evitar el riesgo completamente, retirndose de una actividad o
conjunto de actividades planeadas o existentes, o cambiando las condiciones bajo las
cuales se opera la actividad. Por ejemplo, para riesgos causados por la naturaleza puede ser
una alternativa ms econmica mudar las instalaciones de procesamiento de la informacin
a un lugar donde el riesgo no exista o este bajo control.
9.5 Transferencia del riesgo
Accin: El riesgo debe transferirse a otra parte que pueda administrar ms eficazmente el
riesgo particular dependiendo de la evaluacin del riesgo.
La transferencia del riesgo involucra una decisin de compartir ciertos riesgos con partes
externas. La transferencia del riesgo puede crear nuevos riesgos o modificar los riesgos
existentes identificados. Por lo tanto, puede ser necesario el tratamiento adicional del
riesgo.
Se puede hacer la transferencia por medio de un seguro que soporte las consecuencias o
subcontratando a un socio cuyo rol ser monitorear el sistema de informacin y tomar
acciones inmediatas para evitar un ataque antes de que logre un nivel de dao definido.
Se debe notar que puede ser posible transferir la responsabilidad de administrar el riesgo,
pero normalmente no es posible transferir los pasivos de un impacto. Los clientes
atribuirn usualmente un impacto adverso a una falta de la organizacin
PERUANA 39 de 95
10. ACEPTACIN DEL RIESGO EN SEGURIDAD DE LA

INFORMACIN
Insumo: El plan de tratamiento del riesgo y la evaluacin del riesgo residual estn sujetos a
la decisin de aceptacin de los gerentes de la organizacin.
Accin: Debe tomarse y registrarse de manera formal la decisin de aceptar los riesgos y
responsabilidades por esa decisin (esto se relaciona con la norma ISO/IEC 27001 apartado
4.2.1 h)).
Los planes de tratamiento del riesgo deben describir cmo se deben tratar los riesgos
evaluados para satisfacer los criterios de aceptacin del riesgo (vase el apartado 7.2
Criterios de aceptacin del riesgo). Es importante que los gerentes responsables revisen y
aprueben los planes de tratamiento del riesgo propuestos y los riesgos residuales resultantes
y registrar cualquier condicin que se asocie con dicha aprobacin.
Los criterios de aceptacin del riesgo pueden ser ms complejos que simplemente
determinar si un riesgo residual cae o no por encima o por debajo de un umbral especfico.
En algunos casos el nivel de riesgo residual puede no cumplir con los criterios de
aceptacin del riesgo porque los criterios que se estn aplicando no toman en cuenta las
circunstancias prevalecientes. Por ejemplo, se puede argir que es necesario aceptar riesgos
debido a que los beneficios que acompaan a los riesgos son muy atractivos, o porque el
costo de reduccin del riesgo es demasiado alto. Dichas circunstancias indican que los
criterios de aceptacin del riesgo son inadecuados y se deberan revisar si fuera posible. Sin
embargo, no siempre es posible revisar los criterios de aceptacin del riesgo de manera
oportuna. En dichos casos, quienes toman las decisiones pueden tener que aceptar los
riesgos que no satisfacen los criterios de aceptacin normal. Si esto es necesario, quien
toma las decisiones debera comentar explcitamente los riesgos e incluir una justificacin
para que la decisin pueda pasar por encima de los criterios normales de aceptacin del
riesgo.
PERUANA 40 de 95
11. COMUNICACIN DEL RIESGO EN SEGURIDAD DE LA

INFORMACIN
Insumo: Toda la informacin del riesgo que se obtiene de las actividades de gestin del
riesgo (vase la Figura 1).
Accin: La informacin sobre el riesgo debe intercambiarse y/o compartirse entre quienes
toman las decisiones y otros interesados.
La comunicacin del riesgo es una actividad para lograr acuerdos sobre cmo manejar los
riesgos intercambiando y/o compartiendo informacin sobre el riesgo entre quienes toman
las decisiones y otros interesados. La informacin incluye, pero no se limita a, la
existencia, naturaleza, forma, posibilidad, gravedad, tratamiento y aceptabilidad de los
riesgos.
La comunicacin eficaz entre los interesados es importante ya que esto puede tener un
impacto significativo en las decisiones que se deben tomar. La comunicacin asegurar que
los responsables de implementar la gestin del riesgo y aquellos que tienen intereses
particulares comprendan la base sobre la cual se toman las decisiones y las acciones
particulares que se requieren. La comunicacin es bi-direccional.
Las percepciones del riesgo pueden variar debido a las diferencias en los supuestos,
conceptos y a las necesidades, problemas y preocupaciones de los interesados segn se
relacionen ellos con el riesgo o los problemas en cuestin. Los interesados probablemente
consideren la aceptabilidad del riesgo en base a su percepcin del riesgo. Esto es
especialmente importante para asegurar que las percepciones del riesgo de los interesados,
as como sus percepciones de los beneficios se pueden identificar y documentar y las
razones subyacentes se pueden entender y resolver de manera clara.
Debe realizarse la comunicacin sobre el riesgo de manera que se logre lo siguiente:
- Proporcionar aseguramiento del resultado de la gestin del riesgo de la

organizacin.
PERUANA 41 de 95
- Recolectar informacin sobre el riesgo.
- Compartir los resultados de la evaluacin del riesgo y presentar el plan de

tratamiento del riesgo.
- Evitar o reducir la ocurrencia y consecuencia de las infracciones a la

seguridad de la informacin debido a la falta de comprensin mutua entre quienes
toman las decisiones y los interesados.
- Apoyar la toma de decisiones.
- Obtener nuevo conocimiento sobre seguridad de la informacin.
- Coordinar con otras partes y planificar las respuestas para reducir las
consecuencias de cualquier incidente.
- Darle a los que toman las decisiones y a los interesados un sentido de

responsabilidad sobre los riesgos.
- Mejorar la conciencia.
Una organizacin debe desarrollar planes de comunicacin del riesgo para operaciones
normales, as como para las situaciones de emergencia. Por lo tanto, la actividad de
comunicacin del riesgo debe realizarse de manera continua.
La coordinacin entre quienes toman las decisiones y los interesados ms importantes debe
lograrse por medio de la formulacin de un comit donde se debata los riesgos, su
priorizacin y su tratamiento apropiado y aceptacin.
Es importante cooperar con la unidad de relaciones pblicas o comunicaciones concernida

dentro de la organizacin para coordinar todas las tareas relacionadas con la comunicacin
del riesgo. Esto es crucial en el caso de acciones de comunicacin de la crisis, por ejemplo
en respuesta a incidentes particulares.
Producto: La comprensin continua del proceso de gestin del riesgo en seguridad de la

informacin de la organizacin y sus resultados.
PERUANA 42 de 95
12. MONITOREO Y REVISIN DEL RIESGO EN SEGURIDAD DE LA

INFORMACIN
12.1 Monitoreo y revisin de factores del riesgo
Insumo: Toda la informacin sobre el riesgo que se obtiene a travs de las actividades de
gestin del riesgo (Vase la Figura 1).
Accin: Se debe monitorear y revisar los riesgos y sus factores (es decir, valor de los
activos, impactos, amenazas, vulnerabilidades, posibilidad de ocurrencia) para identificar
cualquier cambio en el contexto de la informacin en una etapa temprana y para mantener
una visin general de toda la imagen del riesgo.
Los riesgos no son estticos. Las amenazas, vulnerabilidades, posibilidad o consecuencias

pueden cambiar abruptamente sin ninguna indicacin. Por lo tanto, es necesario el
monitoreo constante para detectar estos cambios. Esto lo pueden apoyar servicios externos
que provean informacin respecto a nuevas amenazas o vulnerabilidades.
Las organizaciones deben asegurar que se monitoree continuamente lo siguiente:
- Nuevos activos que hayan sido incluidos en el alcance de la gestin del riesgo.
- La modificacin necesaria de los valores de los activos, por ejemplo: debido a
las necesidades cambiantes del negocio.
- Nuevas amenazas que podran ser activas tanto fuera como dentro de la
organizacin y que no se han evaluado.
- La posibilidad de que las vulnerabilidades nuevas o aumentadas permitan que
haya amenazas que exploten estas vulnerabilidades nuevas o cambiadas.
- Vulnerabilidades identificadas para determinar las que se estn exponiendo a
amenazas nuevas o re-emergentes.
- El mayor impacto o las consecuencias de amenazas, vulnerabilidades y riesgos
evaluados resultan en un nivel de riesgo inaceptable cuando se agregan.
- Incidentes de seguridad de la informacin.
PERUANA 43 de 95
Las nuevas amenazas, vulnerabilidades o cambios en las posibilidades o las consecuencias

pueden incrementar los riesgos previamente evaluados como bajos. La revisin de riesgos
bajos y aceptados debe considerar cada riesgo por separado y todos los riesgos como un
agregado tambin para evaluar su impacto acumulado potencial. Si los riesgos no caen
dentro de la categora baja o aceptable, se les debe tratar utilizando una o ms de las
opciones consideradas en el Captulo 9.
Los factores que afectan las posibilidades y las consecuencias de que ocurran las amenazas
pueden cambiar, as como pueden cambiar los factores que afectan la conveniencia o el
costo de las distintas opciones de tratamiento.
Los factores que afectan la posibilidad y consecuencias de las amenazas que ocurren
pueden cambiar, como pueden hacerlo los factores que afectan la conveniencia o el costo
de las distintas opciones de tratamiento. Los cambios importantes que afectan a la
organizacin deben recibir una revisin ms especfica. Por lo tanto, las actividades de
monitoreo del riesgo deben repetirse regularmente y las opciones seleccionadas para el
tratamiento del riesgo deben revisarse peridicamente.
El resultado de las actividades de monitoreo del riesgo pueden ser un insumo para otras
actividades de revisin del riesgo.
La organizacin debe revisar todos los riesgos de manera regular y cuando ocurren cambios
importantes (de acuerdo con la norma ISO/IEC 27001, apartado 4.2.3)).
Producto: El alineamiento continuo de la gestin del riesgo con los objetivos de negocio de
la organizacin y con los criterios de aceptacin del riesgo.
12.2 Monitoreo, revisin y mejoramiento de gestin del riesgo
Insumo: Toda la informacin sobre el riesgo que se obtiene de las actividades de gestin
del riesgo (vase la figura 1).
Accin: El proceso de gestin del riesgo en seguridad de la informacin debe monitorearse,

revisarse y mejorarse continuamente segn sea necesario y apropiado.
PERUANA 44 de 95
Se necesita monitoreo y revisin constante para asegurar que el contexto, el resultado de la

evaluacin y el tratamiento del riesgo, as como los planes de manejo sigan siendo
relevantes y apropiados a las circunstancias.
La organizacin debe asegurarse de que el proceso y gestin del riesgo de seguridad de la

informacin y las actividades relacionadas sigan siendo apropiadas en las circunstancias
presentes y se cumplan. Cualquier mejora acordada al proceso con las acciones necesarias
para mejorar el cumplimiento con el proceso deben notificarse a los gerentes adecuados
para asegurarse de que no se pase por alto o subestime ningn riesgo o elemento riesgoso y
que se tomen acciones y decisiones necesarias para proveer una compresin realista del
riesgo y para tener la capacidad de responder.
Adems, la organizacin debe verificar regularmente que los criterios utilizados para medir
el riesgo y sus elementos siguen siendo vlidos y consistentes con los objetivos, estrategias
y polticas empresariales y que los cambios al contexto empresarial se toman en
consideracin de manera adecuada durante el proceso de gestin del riesgo en seguridad de
la informacin. Esta actividad de monitoreo y revisin debe ocuparse de, aunque no
limitarse a, lo siguiente:
Contexto legal y ambiental.

Contexto competitivo.
Enfoque de evaluacin del riesgo.
Valor y categoras del activo.
Criterios de impacto.
Criterios de evaluacin del riesgo.
Criterios de aceptacin del riesgo.
Costo total de propiedad.
Recursos necesarios.
La organizacin debe asegurar que los recursos para la evaluacin y el tratamiento del
riesgo estn disponibles continuamente para revisar el riesgo, resolver amenazas o
vulnerabilidades nuevas o modificadas, y para aconsejar a la gerencia de manera
correspondiente.
PERUANA 45 de 95
El monitoreo de la gestin del riesgo puede resultar en la modificacin o adicin de

enfoques, metodologas o herramientas utilizados dependiendo de:
Cambios identificados.
Integracin de la evaluacin del riesgo.
Objetivo del proceso de gestin del riesgo en seguridad de la informacin
(por ejemplo, continuidad del negocio, capacidad de recuperacin ante los incidentes,
cumplimiento).
Objetivo del proceso de gestin del riesgo en seguridad de la informacin
(por ejemplo, organizacin, unidad empresarial, proceso de la informacin,
implementacin tcnica, aplicacin, conexin a la Internet).
Producto: Relevancia continua del proceso de gestin del riesgo en seguridad de la

informacin para los objetivos de negocio de la organizacin o la actualizacin del
proceso.
13. ANTECEDENTES
13.1. ISO/IEC 27005: 2008 Information technology Security techniques

Information security risk management
PERUANA 46 de 95
ANEXO A
(INFORMATIVO)
DEFINICIN DEL ALCANCE Y LMITES DEL

PROCESO DE GESTIN DEL RIESGO EN SEGURIDAD
DE LA INFORMACIN
A.1 Estudio de la organizacin
Evaluar la organizacin. El estudio de la organizacin nos recuerda los elementos

caractersticos que definen la identidad de una organizacin. Esto tiene que ver con el
propsito, negocio, misiones, valores y estrategias de esta organizacin. Se debe identificar
estos elementos juntos con los que contribuyen a su desarrollo (por ejemplo, la
subcontratacin).
La dificultad de esta actividad reside en comprender exactamente cmo est estructurada la

organizacin. Identificar su estructura real proveer una comprensin del papel e
importancia de cada divisin en el logro de los objetivos de la organizacin.
Por ejemplo, el hecho de que el gerente de seguridad de la informacin reporte a los altos
gerentes en vez de a los gerentes de TI puede indicar la participacin de la alta gerencia
en la seguridad de la informacin.
El propsito principal de la organizacin. El propsito principal de una organizacin puede

definirse como las razones por las que existe (su campo de actividad, sus segmentos de
mercado, etc.).
Su negocio. El negocio de la organizacin, definido por las tcnicas y el know-how de sus

empleados le permite lograr sus misiones. Es especfico al campo de actividad de la
organizacin y a menudo define su cultura.
PERUANA 47 de 95
Su misin. La organizacin logra su propsito cumpliendo con su misin. La misin, los

servicios proporcionados y/o los productos manufacturados deben identificarse en relacin
con los usuarios finales.
Sus valores. Los valores, los principios importantes o un cdigo bien definido de conducta
que se aplica al ejercicio de un negocio. Esto puede referirse al personal, a las relaciones
con agentes externos (clientes, etc.), a la calidad de productos suministrados o servicios
proporcionados.
Tomar el ejemplo de una organizacin cuyo propsito es el servicio pblico, cuyo negocio
es el transporte y cuyas misiones incluyen el transporte de nios a y de la escuela. Sus
valores pueden ser la puntualidad y la seguridad del servicio durante el transporte.
Estructura de la organizacin. Existen distintos tipos de estructura:
- Estructura por divisiones: Cada divisin se coloca bajo la autoridad de un

gerente de divisin responsable por las decisiones estratgicas administrativas y
operativas que conciernen a su unidad.
- Estructura funcional: Se ejerce autoridad funcional sobre los

procedimientos, la naturaleza del trabajo y a veces las decisiones o el planeamiento
(por ejemplo, produccin, TI, recursos humanos, marketing, etc.)
Comentarios:
- Una divisin dentro de una organizacin con estructura por divisiones puede
organizarse como una estructura funcional y viceversa.
- Se puede decir que una organizacin tiene una estructura de matriz si tiene
elementos de ambos tipos de estructura.
- En cualquier estructura organizativa se pueden distinguir los siguientes

niveles:
- El nivel de toma de decisiones (definicin de orientaciones estratgicas);

- El nivel de liderazgo (coordinacin y gestin);
- El nivel operativo (actividades de produccin y apoyo).
PERUANA 48 de 95
Organigrama. La estructura de la organizacin se representa esquemticamente en un

organigrama. Esta representacin debe destacar las lneas jerrquicas y la delegacin de
autoridad, pero tambin debe incluir otras relaciones, las que incluso si no se basan en
ninguna autoridad formal, son no obstante lneas de flujo de la informacin.
La estrategia de la organizacin. Esto requiere una expresin formal de los principios gua
de la organizacin. La estrategia de la organizacin determina la direccin y el desarrollo
que se necesitan para beneficiarse de los temas en juego y de los cambios importantes que
estn planeandos.
A.2 Lista de restricciones que afectan a la organizacin
Deben tomarse en cuenta todas las restricciones que afectan a la organizacin y determinan
su orientacin en seguridad de la informacin. Su fuente puede estar dentro de la
organizacin, en cuyo caso tiene cierto control sobre ella o fuera de la organizacin y, por
lo tanto, generalmente no es negociable. Las restricciones a los recursos (presupuesto,
personal) y las restricciones de emergencia estn entre las ms importantes.
La organizacin fija sus objetivos (respecto de su negocio, comportamiento, etc.)

comprometindose con un cierto camino, posiblemente en un perodo largo. Define lo que
quiere ser y los medios que necesitar para implementarlo. Cuando se especifica este
camino, la organizacin toma en cuenta los desarrollos, la tcnica y el know-how, los
deseos que los usuarios, los clientes, etc. han expresado. Este objetivo se puede expresar en
la forma de estrategias operativas o de desarrollo con la finalidad, por ejemplo, de cortar
costos operativos, mejorar la calidad del servicio, etc.
Estas estrategias probablemente incluyen informacin y el sistema de informacin (SI) que

ayuda en su aplicacin. Consecuentemente, las caractersticas concernientes a la identidad,
misin y estrategias de la organizacin son elementos fundamentales en el anlisis del
problema, ya que el incumplimiento de un aspecto de la seguridad de la informacin puede
resultar en repensar estos objetivos estratgicos.
Adems, es esencial que las propuestas respecto de las necesidades de seguridad de la

informacin sigan siendo consistentes con las reglas, usos y medios vigentes en la
organizacin.
PERUANA 49 de 95
La lista de restricciones incluye pero no se limita a:
Restricciones de naturaleza poltica
Estas pueden referirse a administraciones gubernamentales, instituciones pblicas o ms

generalmente a cualquier organizacin que tenga que aplicar decisiones gubernamentales.
Normalmente son decisiones que conciernen a la orientacin estratgica u operativa que
una decisin gubernamental u rgano de toma de decisiones realiza y deben aplicarse.
Por ejemplo, la computarizacin de facturas o documentos administrativos introduce

problemas de seguridad de la informacin.
Restricciones de naturaleza estratgica
Las restricciones pueden surgir de los cambios planeados o posibles a las estructuras u
orientacin de la organizacin. Se expresa en los planes estratgicos u operativos de la
organizacin.
Por ejemplo, la cooperacin internacional al compartir informacin delicada puede

necesitar acuerdos concernientes al intercambio seguro.
Restricciones territoriales
La estructura y/o el propsito de la organizacin pueden introducir restricciones especficas

como la distribucin de sitios en todo el territorio nacional o en el extranjero.
Los ejemplos incluyen servicios postales, embajadas, bancos, subsidiarias de grandes

grupos industriales, etc.
PERUANA 50 de 95
Las restricciones surgen del clima econmico y poltico
La operacin de una organizacin puede cambiar profundamente debido a eventos

especficos como huelgas o crisis nacionales o internacionales.
Por ejemplo, algunos servicios pueden ser capaces de continuar incluso a pesar de una
seria crisis.
Restricciones estructurales
La naturaleza de la estructura de una organizacin (por divisiones, funcional u otra) puede

llevar a una poltica de seguridad de la informacin especifica y a la organizacin de
seguridad adaptada a la estructura.
Por ejemplo, una estructura internacional puede ser capaz de reconciliar las necesidades
especficas de seguridad para cada pas.
Restricciones funcionales
Las restricciones funcionales surgen directamente de las misiones generales o especificas

de la organizacin.
Por ejemplo, una organizacin que opera 24 horas al da debe asegurar que sus recursos
estn continuamente disponibles.
Restricciones respecto al personal
La naturaleza de estas restricciones vara considerablemente. Estn ligadas al nivel de

responsabilidad, reclutamiento, calificacin, capacitacin, conciencia de la seguridad,
motivacin, disponibilidad, etc.
PERUANA 51 de 95
Por ejemplo, todo el personal de una organizacin de defensa debe tener autorizacin
para manejar informacin altamente confidencial.
Restricciones que surgen del calendario de la organizacin
Estas restricciones pueden resultar de la reestructuracin o el establecimiento de polticas

nacionales o internacionales nuevas que imponen ciertos plazos.
Por ejemplo, la creacin de una divisin de seguridad.
Restricciones relacionadas a mtodos
Los mtodos apropiados al know-how de la organizacin tendrn que imponerse para

aspectos como el planeamiento, especificaciones, desarrollo, etc. de proyectos.
Por ejemplo, una restriccin tpica de este tipo es la necesidad de incorporar las
obligaciones legales de la organizacin a la poltica de seguridad.
Restricciones de naturaleza cultural
En algunas organizaciones los hbitos de trabajo o el negocio principal han llevado a una
cultura especfica dentro de la organizacin que puede ser incompatible con los controles
de seguridad. Esta cultura es el marco de referencia general del personal y se puede
determinar por muchos aspectos, incluyendo la educacin, la instruccin, la experiencia
personal, la experiencia fuera del trabajo, las opiniones, la filosofa, las creencias, el
estatus social, etc.
Restricciones presupuestales
Los controles de seguridad recomendados a veces pueden tener un costo muy alto.
Mientras que no siempre es apropiado basar las inversiones en seguridad en la economa,
generalmente se refiere a justificacin econmica del departamento financiero de la
organizacin.
PERUANA 52 de 95
Por ejemplo, en el sector privado y en algunas organizaciones pblicas, el costo total de

los controles de seguridad no debera exceder el costo de las consecuencias potenciales de
los riesgos. La alta gerencia debera por tanto evaluar y tomar riesgos calculados si desea
evitar excesivos costos de seguridad.
A.3 Lista de las referencias legislativas y regulatorias aplicables a la

organizacin
Se deben identificar los requisitos regulatorios aplicables a la organizacin. Estos pueden

ser leyes, decretos, regulaciones especficas en el campo de la organizacin o regulaciones
internas/externas. Esto tambin se refiere a contratos y acuerdos y ms generalmente a
cualquier obligacin de naturaleza legal o regulatoria.
A.4 Lista de restricciones que afectan el alcance
Al identificar las restricciones, es posible listar aqullas que tienen un impacto en el

alcance y determinar cules estn no obstante dispuestas para la accin. Se aaden a las
restricciones de la organizacin que se han determinado anteriormente y posiblemente las
reforman. Los prrafos siguientes presentan una lista no exhaustiva de tipos posibles de
restricciones.
Restricciones que surgen de procesos no existentes
Los proyectos de aplicacin no necesariamente se desarrollan simultneamente. Algunos

dependen de procesos preexistentes. A pesar de que un proceso se puede desglosar en
subprocesos, el proceso no est necesariamente influenciado por todos los subprocesos de
otro proceso.
Restricciones tcnicas
Las restricciones tcnicas relacionadas a la infraestructura surgen generalmente de

hardware y software instalados y de las habitaciones o lugares que albergan los procesos:
PERUANA 53 de 95
- Archivos (requisitos concernientes a la organizacin, la gestin de medios,

la gestin de reglas de acceso, etc.)
- La arquitectura general (requisitos concernientes a la topologa

(centralizada, distribuida, cliente servidor), arquitectura fsica, etc.)
- Software de aplicacin (requisitos concernientes al diseo especfico del

software, estndares del mercado, etc.);
- Software en paquetes (requisitos concernientes a los estndares, nivel de

evaluacin, calidad, cumplimiento con las normas, seguridad, etc.)
- Hardware (requisitos concernientes a los estndares, calidad, cumplimiento

con las normas, etc.)
- Redes de comunicacin (requisitos concernientes a la cobertura, estndares,

capacidad, confiabilidad, etc.)
- Construccin de infraestructura (requisitos concernientes a la ingeniera

civil, construccin, altos voltajes, bajos voltajes, etc.)
Restricciones financieras
El presupuesto restringe a menudo la implementacin de controles de seguridad con los

que la organizacin puede comprometerse. Sin embargo, la restriccin financiera debe ser
la ltima consideracin ya que la asignacin de presupuesto para seguridad puede
negociarse sobre la base del estudio de seguridad.
Restricciones ambientales
Las restricciones ambientales surgen del entorno geogrfico o econmico en el que se

implementan los procesos: pas, clima, riesgos naturales, situacin geogrfica, clima
econmico, etc.
PERUANA 54 de 95
Restricciones temporales
El tiempo requerido para implementar los controles de seguridad debe considerarse en

relacin con la capacidad de mejorar el sistema de informacin. Si el tiempo de
implementacin es muy largo, los riesgos para los que se disea el control pueden haber
cambiado. El tiempo es un factor determinante para seleccionar las soluciones y
prioridades.
Restricciones relacionadas a los mtodos
Se debe utilizar mtodos apropiados para el know-how de la organizacin en el

planeamiento de proyectos, las especificaciones, el desarrollo y otros.
Restricciones organizativas
Varias restricciones pueden deducirse de las necesidades organizativas:
- Operacin (necesidades referidas a los tiempos de espera, suministro de

servicios, vigilancia, monitoreo, planes de emergencia, operacin degradada, etc.)
- Mantenimiento (requisitos referidos a la solucin de incidentes, acciones

preventivas, correccin rpida, etc.).
- Administracin de recursos humanos (requisitos concernientes a la

capacitacin de operadores de usuarios, calificacin para puestos como el de
administrador de sistemas o administrador de datos, etc.).
- Gestin administrativa (requisitos concernientes a responsabilidades, etc.)
- Gestin del desarrollo (requisitos concernientes a herramientas de

desarrollo, ingeniera de software asistida por computadora, planes de aceptacin,
organizacin a establecerse, etc.)
- Manejo de relaciones externas (requisitos concernientes a la organizacin de

relaciones con terceros, contratos, etc.)
PERUANA 55 de 95
ANEXO B
(INFORMATIVO)
IDENTIFICACIN Y VALORIZACIN DE ACTIVOS Y

EVALUACIN DE IMPACTO
B.1 Ejemplos de identificacin de activos
Para realizar una valorizacin de activos, una organizacin necesita primero identificar sus
activos (a un nivel apropiado de detalle). Se puede distinguir dos tipos de activo:
- Los activos primarios:
- Procesos y actividades del negocio

- Informacin
- Los activos de apoyo (sobre los cuales descansan los elementos primarios
del alcance) de todo tipo:
- Hardware
- Software
- Red
- Personal
- Sitio
- Estructura de la organizacin
B.1.1 Identificacin de activos primarios
Para describir el alcance de manera ms exacta, esta actividad consiste en identificar los
activos primarios (procesos y actividades del negocio, informacin). Esta identificacin se
realiza por medio de un grupo de trabajo mixto que representa el proceso (gerentes,
especialistas en sistemas informticos y usuarios).
PERUANA 56 de 95
Los activos primarios son usualmente los procesos e informacin centrales de la actividad
en cuestin. Otros activos primarios como los procesos de la organizacin tambin pueden
considerarse, lo cual ser ms apropiado para disear una poltica de seguridad de la
informacin o un plan de continuidad del negocio. Dependiendo del propsito, algunos
estudios no requerirn un anlisis exhaustivo de todos los elementos que conforman el
alcance. En dicho caso, los lmites del estudio se pueden restringir a los elementos clave
del alcance.
Los activos primarios son de dos tipos:
1. Procesos (o subprocesos) y actividades del negocio, por ejemplo:
- Procesos cuya prdida o degradacin hace imposible llevar a cabo la misin

de la organizacin.
- Procesos que contienen procesos secretos o procesos que involucran

tecnologa propietaria
- Procesos que, si se modifican, pueden afectar grandemente el logro de la

misin de la organizacin
- Procesos que son necesarios para que la organizacin cumpla con los
requisitos contractuales, legales o regulatorios.
2. Informacin:
De manera ms general la informacin primaria comprende principalmente:
- Informacin vital para el ejercicio de la misin o los negocios de la

organizacin.
- Informacin personal que se puede definir especficamente en el sentido de

las leyes nacionales respecto a la privacidad.
- Informacin estratgica necesaria para lograr los objetivos determinados por

las orientaciones estratgicas
PERUANA 57 de 95
- Informacin de alto costo cuya recoleccin, almacenamiento, procesamiento

y transmisin requieren tiempo largo y/o involucran un alto costo de adquisicin.
- Los procesos y la informacin que no se identifican como sensibles no

tendrn luego de esta actividad clasificacin en el resto del estudio. Esto significa que
incluso si dichos procesos o informacin se encuentran comprometidos, la
organizacin seguir cumpliendo con la misin exitosamente.
Sin embargo, a menudo heredarn controles implementados para proteger los procesos y la
informacin identificados como sensibles.
B.1.2 Lista y descripcin de activos de apoyo
El alcance consiste de activos que deben identificarse y describirse. Estos activos tienen
vulnerabilidades que son explotables por amenazas que tienen como objetivo desactivar los
activos primarios del alcance (procesos e informacin). Son de varios tipos:
Hardware
El tipo de hardware consiste de todos los elementos fsicos que apoyan procesos.
Equipamiento de procesamiento de datos (activo)
El equipamiento automtico de procesamiento de la informacin incluye los artculos

requeridos para operar independientemente.
Equipo porttil
Equipo de cmputo porttil.
Ejemplos: computadora laptop, Asistente Digital Personal (PDA).

PERUANA 58 de 95
Equipo fijo
Equipo de cmputo utilizado en los locales de la organizacin.
Ejemplos: servidor, microcomputadora usada como estacin de trabajo.
Perifricos de procesamiento
Equipo conectado a una computadora por medio de un puerto de comunicacin

(serial, enlace paralelo, etc.) para ingresar, llevar o transmitir datos.
Ejemplos: impresora, disco removible.
Medio de datos (pasivo)
Estos son medios para almacenar datos o funciones.
Medio electrnico
Un medio de informacin que puede conectarse a una computadora o a una red de

computadoras para el almacenamiento de datos. A pesar de su tamao compacto,
estos medios pueden contener una gran cantidad de datos. Se pueden usar con equipo
de cmputo estndar.
Ejemplos: disco floppy, CD Rom, cartucho de respaldo, disco duro removible,

memoria USB, cinta.
Otros medios
Medios estticos no electrnicos que contienen datos.

PERUANA 59 de 95
Ejemplos: papel, diapositiva, transparencia, documentacin, fax.
Software
El software consiste de todos los programas que contribuyen con la operacin de un

conjunto de procesamiento de datos.
Sistema operativo
Esto incluye todos los programas de una computadora que constituye la base operativa
desde la cual se corren todos los dems programas (servicios o aplicaciones). Incluye un
kernel y funciones o servicios bsicos. Dependiendo de la arquitectura, un sistema
operativo puede ser monoltico o estar conformado de un microkernel y un conjunto de
servicios del sistema.
Los elementos principales del sistema operativo son todos los servicios de administracin
del equipo (CPU. memoria, disco e interfases de red), servicios de administracin de tareas
o procesos y servicios de manejo de derechos de usuario.
Software de servicio, mantenimiento o administracin
Software caracterizado por el hecho de que complementa los servicios del sistema
operativo y no est directamente al servicio de los usuarios o aplicaciones (aunque
usualmente es esencial o incluso indispensable para la operacin global del sistema de
operacin).
Software en paquetes o software estndar
El software estndar o el software en paquetes son productos completos que se

comercializan como tales (en vez de uno en su clase o desarrollos especficos) con medio,
versin y mantenimiento. Proporcionan servicios a los usuarios y aplicaciones pero no
estn personalizados o son especficos como son las aplicaciones de negocios.
Ejemplos: software de administracin de bases de datos, software de mensajera

electrnica, groupware, software de directorios, software para servidores de web, etc.
PERUANA 60 de 95
Aplicacin empresarial
Aplicacin empresarial estndar
Este es software comercial diseado para dar a los usuarios acceso directo a los
servicios y funciones que requieren de su sistema de informacin en su contexto
profesional. Existe un rango de campos muy amplio, tericamente ilimitado.
Ejemplo: software de cuentas, software de control metalmecnico, software de

atencin al cliente, software de administracin de competencias personales, software
administrativo, etc.
Aplicacin empresarial especfica
Este es software en el que varios aspectos (principalmente el soporte, el

mantenimiento, las mejoras, etc.) se han desarrollado especficamente para darle a los
usuarios acceso directo a los servicios y funciones que requieren de su sistema de
informacin. Existe un rango de campos muy amplio, tericamente ilimitado.
Ejemplos: administracin de facturas de clientes de operadores de

telecomunicaciones, aplicacin de monitoreo en tiempo real para el lanzamiento de
cohetes.
Red
El tipo red consiste de todos los dispositivos de telecomunicaciones que se usan para
interconectar varias computadoras fsicamente remotas o elementos de un sistema de
operacin.
PERUANA 61 de 95
Medio y soporte
Las comunicaciones y los medios o equipos de telecomunicaciones se caracterizan

principalmente por las propiedades fsicas y tcnicas del equipo (punto a punto,
transmisin) y por los protocolos de comunicacin (enlace o red niveles 2 y 3 de
modelo de capas OSI7).
Ejemplos: Red de Telefona Pblica Conmutada (PSTN), Ethernet, GigabitEthernet,

Lnea Digital Asimtrica de Suscriptor (ADSL), especificaciones de protocolos
inalmbricos (por ejemplo WiFi 802.11), Bluetooth o Wirefire.
Rel pasivo o activo
Este sub-tipo incluye todos los dispositivos que no son las terminaciones lgicas
de las comunicaciones (visin IS), sino que son dispositivos intermedios o rels.
Los rels se caracterizan por los protocolos de comunicacin de red soportados.
Adems del rel bsico, a menudo incluye el ruteo y/o funciones y servicios de
filtrado, empleando conmutadores de comunicacin y ruteadores con filtro. A
menudo se pueden administrar remotamente y son usualmente capaces de generar
registros.
Ejemplos: puente, ruteador, hub, conmutador, intercambio automtico.
Interfaz de comunicacin
Las interfaces de comunicacin de las unidades de procesamiento se conectan a

las unidades de procesamiento pero se caracterizan por los medios y los
protocolos soportados, por cualquier filtrado instalado, registro o funciones de
generacin de advertencias y sus capacidades y por la posibilidad y el requisito de
la administracin remota.
Ejemplos: Servicio General de Radio por Paquetes (GPRS), adaptador de

Ethernet.
PERUANA 62 de 95
Personal
El tipo personal consiste de todos los grupos de personas involucradas en el sistema

informtico.
Responsable de tomar decisiones
Los responsables de tomar decisiones son los propietarios de los activos

primarios (informacin y funciones) y los administradores de la organizacin o
del proyecto especfico.
Ejemplos: altos gerentes, lderes de proyectos.
Usuarios
Los usuarios son el personal que maneja elementos sensibles en el contexto de su

actividad y que tienen una responsabilidad especial en este sentido. Pueden tener
derechos especiales de acceso al sistema de informacin para realizar sus tareas
cotidianas.
Ejemplos: gerente de recursos humanos, gerente financiero, gerente de riesgos.
Personal de operaciones y mantenimiento
Este es el personal que est a cargo de operar y mantener el sistema de

informacin. Tienen derechos especiales de acceso al sistema de informacin
para realizar sus tareas cotidianas.
Ejemplos: administrador del sistema, administrador de datos, respaldo, escritorio

de ayuda, operador de despliegue de aplicaciones, funcionarios de seguridad.
PERUANA 63 de 95
Desarrolladores
Los desarrolladores estn a cargo de desarrollar las aplicaciones de la

organizacin. Tienen acceso a parte del sistema de operacin con derechos de
alto nivel pero no toman ninguna accin sobre los datos de produccin.
Ejemplos: desarrolladores de aplicaciones empresariales.

Sitio
El tipo sitio comprende todos los lugares que contienen el alcance o parte del alcance y los
medios fsicos requeridos para que opere.
Ubicacin
Entorno externo
Esto concierne a todos los lugares en los que los medios de seguridad de la
organizacin no se pueden aplicar.
Ejemplos: lugares del personal, locales de otra organizacin, ambientes fuera del
sitio (rea urbana, rea de peligro).
Locales
Este lugar est delimitado por el permetro de la organizacin que se encuentra

directamente en contacto con el exterior. Este puede ser un lindero protector
fsico obtenido por la creacin de barreras fsicas o medios de vigilancia
alrededor de los edificios.
Ejemplos: establecimientos, edificios.

PERUANA 64 de 95
Zona
Una zona est formada por un lindero protector fsico que forma divisiones
dentro del local de una organizacin. Se obtiene creando barreras fsicas
alrededor de las infraestructuras de procesamiento de informacin de la
organizacin.
Ejemplos: oficinas, zona de acceso reservado, zona segura.

Servicios esenciales
Todos los servicios requeridos para que opere el equipo de la organizacin.
Comunicacin
Los servicios de telecomunicaciones y equipamiento que provee un operador.
Ejemplos: lnea telefnica, PABX, redes de telefona internas.
Servicios pblicos
Servicios y medios (fuentes y cableado) requeridos para proveer energa al equipo

de tecnologa de la informacin y perifricos.
Ejemplos: suministro de energa elctrica de bajo voltaje, inversor, cabecera de

cable de circuito elctrico.
Suministro de agua.
Disposicin de residuos.
Servicios y medios (equipo, control) para enfriar y purificar el aire.

PERUANA 65 de 95
Ejemplos: tuberas de agua enfriadas, equipo de aire condicionado.
Organizacin
El tipo referente a organizacin describe el marco organizativo, consistente de

todas las estructuras de personal asignadas a una tarea y los procedimientos que
controlan estas estructuras.
Autoridades
Estas son organizaciones desde las cuales la institucin estudiada deriva su

autoridad. Pueden estar afiliadas legalmente o ser externas. Esto impone
restricciones en la organizacin estudiada en trminos de regulaciones,
decisiones y acciones.
Ejemplo: rgano administrativo, oficina central de una organizacin
Estructura de la organizacin
Esta consiste de las distintas sucursales de la organizacin, incluyendo sus

actividades funcionales trasversales, bajo el control de su gerencia.
Ejemplos: gerencia de recursos humanos, gerencia de TI, gerencia de

adquisiciones, gerencia de la unidad de negocio, servicio de seguridad de
edificios, servicio contra incendios, gerencia de auditoras.
Organizacin de proyecto o sistema
Esto se refiere a la accin que se establece para un proyecto o servicio

especfico.
PERUANA 66 de 95
Ejemplo: nueva aplicacin de un proyecto de desarrollo, proyecto de

migracin del sistema de informacin.
Subcontratistas / Proveedores / Practicantes
Estas son organizaciones que proveen a la organizacin con un servicio o

recursos y que estn ligadas a ella por contrato.
Ejemplos: compaa de administracin de locales, compaa subcontratista,

compaas consultoras.
B.2 Valorizacin de activos
El siguiente paso luego de la identificacin del activo es acordar la escala que se debe
utilizar y los criterios para asignar una ubicacin particular en esa escala a cada activo en
base a la valorizacin. Debido a la diversidad de activos que se encuentra en la mayor parte
de organizaciones, probablemente algunos activos que tienen un valor monetario conocido
se valorizarn en la unidad de moneda local, mientras que a otros que tienen un valor
cualitativo puede asignrseles un rango de valor, por ejemplo desde muy bajo a muy
alto. La decisin de usar una escala cuantitativa versus una escala cualitativa es en
realidad cuestin de preferencia de la organizacin, pero debe ser relevante a los activos
que se estn valorizando. Ambos tipos de valorizacin podran utilizarse para el mismo
activo.
Los trminos tpicos que se utilizan para la valorizacin cualitativa de activos incluyen
palabras como insignificante, muy bajo, bajo, medio, alto, muy alto y crucial. La eleccin y
rango de los trminos convenientes a una organizacin depende fuertemente de la
necesidad que tiene una organizacin de seguridad, del tamao de la organizacin y de
otros factores especficos a la organizacin.
PERUANA 67 de 95
Criterios
Los criterios utilizados como base para asignar un valor a cada activo deben escribirse en
trminos claros. Este es a menudo uno de los aspectos ms difciles de la valorizacin de
activos ya que los valores de algunos activos tendrn que determinarse subjetivamente y
debido a que muchos individuos probablemente harn la determinacin. Los criterios
posibles a utilizar para determinar el valor de un activo incluyen su costo original, su costo
de reemplazo y re-creacin o su valor puede ser abstracto, por ejemplo el valor de la
reputacin de una organizacin.
Otra base para la valorizacin de activos son los costos incurridos debido a la prdida de
confidencialidad, integridad y disponibilidad como resultado de un incidente. Tambin se
debe considerar como apropiados el no-repudio, la rendicin de cuentas, la autenticidad y
la confiabilidad. Una valoracin as proveera las dimensiones de elementos importantes
para el valor del activo, adems del costo de reemplazo, basndose en estimados de las
consecuencias adversas al negocio que resultaran de incidentes de seguridad con un
conjunto asumido de circunstancias. Se enfatiza que este enfoque da cuenta de las
consecuencias que es necesario factorizar en la evaluacin del riesgo.
Muchos activos pueden, durante el curso de la valorizacin, tener varios valores asignados.
Por ejemplo, un plan de negocios se puede valorizar en base a la mano de obra utilizada
para desarrollar el plan, se puede valorizar sobre la mano de obra respecto de los insumos y
se puede valorizar sobre su valor para un competidor. Cada uno de los valores asignados
probablemente diferir considerablemente. El valor asignado puede ser el mximo de todos
los valores posible o puede ser la suma de uno o todos los valores posibles. En el anlisis
final se debe determinar cuidadosamente cul valor o valores se asignan a un activo, ya que
el valor final asignado entra en la determinacin de los recursos que se emplearn para la
proteccin del activo.
Reduccin a la base comn
Finalmente, todas las valorizaciones de activos tienen que reducirse a una base comn.
Esto puede hacerse con la ayuda de criterios como los que siguen. Los criterios que se
pueden utilizar para evaluar las condiciones posibles que resultan de una prdida de
confidencialidad, integridad, disponibilidad, no-repudiacin, rendicin de cuentas,
autenticidad o confiabilidad de los activos son:
PERUANA 68 de 95
- Afectacin del desempeo empresarial.

- Prdida de buen nombre/ efecto negativo sobre la reputacin.
- Infraccin asociada con informacin personal.
- Puesta en peligro de la seguridad personal.
- Efectos adversos sobre la aplicacin de la ley.
- Ruptura de la confidencialidad.
- Ruptura del orden pblico.
- Prdida financiera.
- Interrupcin de las actividades empresariales.
- Puesta en peligro de la seguridad ambiental.
Otro enfoque para evaluar las consecuencias podra ser:
- Introduccin del servicio

- incapacidad de proveer el servicio
- Prdida de confianza por parte de los clientes

- prdida de credibilidad en el sistema de informacin interna
- dao a la reputacin
- Interrupcin de la operacin interna

- interrupcin en la organizacin misma
- costo interno adicional
- Interrupcin de la operacin de un tercero

- interrupcin en terceros que transan con la organizacin
- varios tipos de dao
- Infraccin de leyes/ regulaciones:

- incapacidad de cumplir con las obligaciones legales
- Ruptura de contrato:
- incapacidad de cumplir con las obligaciones contractuales
- Peligro a la seguridad del personal / usuario:

- peligro para el personal y/o los usuarios de la organizacin
- Ataque a la vida privada de los usuarios
- Prdidas financieras
PERUANA 69 de 95
- Costos financieros para emergencia o reparacin:

- en trminos del personal
- en trminos del equipo
- en trminos de los estudios, informes de expertos
- Prdida de bienes/fondos/activos
- Prdida de clientes, prdida de proveedores
- Procesos judiciales y sanciones
- Prdida de una ventaja competitiva
- Prdida del liderazgo tecnolgico/tcnico
- Prdida de eficacia/confianza
- Prdida de reputacin tcnica
- Debilitamiento de la capacidad de negociacin
- Crisis industrial (huelgas)
- Crisis gubernamental
- Despidos
- Dao material
Estos criterios son ejemplos de cuestiones a considerarse para la valorizacin de activos.

Para llevar a cabo las valorizaciones, una organizacin tiene que seleccionar criterios
relevantes para su tipo de negocio y necesidades de seguridad. Esto puede significar que
algunos de los criterios listados anteriormente no sean aplicables y que otros puedan
requerir aadirse a la lista.
Escala
Luego de establecer los criterios a considerarse, la organizacin deber ponerse de acuerdo

sobre una escala a ser utilizada en toda la organizacin. El primer paso es decidir sobre el
nmero de niveles a utilizarse. No existen reglas respecto al nmero de niveles ms
apropiado. Si hay ms niveles se provee una granularidad mayor, pero a veces una
diferenciacin muy fina hace que las asignaciones consistentes en toda la organizacin sean
difciles. Normalmente cualquier nmero de niveles entre tres (por ejemplo, bajo, medio y
alto) y diez puede utilizarse siempre y cuando sean consistentes con el enfoque que la
organizacin est utilizando para todo el proceso de evaluacin del riesgo.
PERUANA 70 de 95
Una organizacin puede definir sus propios lmites para la valorizacin de activos, como
bajo, medio, o alto. Estos lmites deben evaluarse de acuerdo con criterios
seleccionados (por ejemplo, para prdidas financieras posibles, deben darse en valores
monetarios, pero para consideraciones como la puesta en peligro de la seguridad del
personal, la valorizacin monetaria puede ser compleja y puede no ser apropiada para todas
las organizaciones). Finalmente, depende completamente de la organizacin el decidir qu
se considera como una consecuencia baja o alta. Una consecuencia que puede ser
desastrosa para una organizacin pequea puede ser baja o insignificante para una
organizacin pequea.
Dependencias
Cuanto ms relevantes y numerosos sean los procesos empresariales apoyados por un

activo, mayor ser el valor de este activo. Deben identificarse las dependencias de los
activos en los procesos empresariales y en otros activos tambin, ya que esto puede
influenciar los valores de los activos. Por ejemplo, la confidencialidad de datos debe
mantenerse a lo largo de su ciclo de vida, en todas las etapas, incluyendo el
almacenamiento y el procesamiento, es decir, la seguridad necesita de almacenamiento y
los programas y el procesamiento deben estar directamente relacionados con el valor que
representa la confidencialidad de los datos almacenados y procesados. Adems, si un
proceso empresarial depende de la integridad de que un programa produzca ciertos datos,
los datos insumo de este programa deben tener una confiabilidad apropiada. Adems, la
integridad de la informacin depender del hardware y el software que se utilice para el
almacenamiento y el procesamiento. El hardware tambin depender del suministro de
electricidad y posiblemente del aire acondicionado. De este modo, la informacin sobre las
dependencias ayudar a identificar las amenazas y particularmente las vulnerabilidades.
Por otro lado, ayudar a asegurar que se de a los activos el verdadero valor de los activos (a
travs de las relaciones de dependencias), indicando as el nivel apropiado de proteccin.
Los valores de los activos de los que otros activos dependen se pueden modificar de la
manera siguiente:
- Si los valores de los activos dependientes (por ejemplo datos) son ms bajos
o iguales a los valores del activo considerado (por ejemplo software), su
valor sigue siendo el mismo.
PERUANA 71 de 95
- Si los valores del activo dependiente (por ejemplo datos) es mayor, entonces
el valor del activo considerado (por ejemplo software) debe incrementarse
de acuerdo con:
- el grado de dependencia
- los valores de otros activos
Una organizacin puede tener algunos activos que estn disponibles ms de una vez, como
las copias de programas de software o del mismo tipo de computadora utilizado en la
mayor parte de oficinas. Es importante considerar este hecho cuando se hace la
valorizacin de activos. Por un lado, estos activos se desatienden fcilmente, por lo tanto se
debe tener cuidado en identificar a todos ellos. Por otro lado, se les podra utilizar para
reducir los problemas de disponibilidad.
Producto
El producto final de este paso es una lista de activos y sus valores relativos respecto de la
divulgacin (preservacin de confidencialidad), modificacin (preservacin de la
integridad, autenticidad, no-repudio y rendicin de cuentas), no-disponibilidad y
destruccin (preservacin de la disponibilidad y confiabilidad) y costo de reemplazo.
B.3 Evaluacin del impacto
Un incidente en la seguridad de la informacin puede impactar ms que un activo o slo

una parte de un activo. El impacto se relaciona con el grado de xito del incidente. Como
consecuencia, existe una diferencia importante entre el valor del activo y el impacto que
resulta del incidente. Se considera que el impacto tiene ya sea un efecto inmediato
(operativo) o futuro (empresarial) que incluye consecuencias financieras y de mercado.
El impacto operativo inmediato es ya sea directo o indirecto.

PERUANA 72 de 95
Directo:
a) El valor de reemplazo financiero de activos perdidos o parte de los mismos.
b) El costo de adquisicin, configuracin e instalacin del nuevo activo o

respaldo.
c) el costo de las operaciones suspendidas debido al incidente hasta que el

servicio proporcionado por el (los) activo (s) se restaure.
d) Resultados del impacto en una ruptura de la seguridad de la informacin.
Indirecto:
a) Costo de oportunidad (se tiene que usar recursos financieros para reemplazar
o reparar un activo que podra haber sido utilizado en otro lugar.
b) El costo de las operaciones interrumpidas.
c) Un mal uso potencial de la informacin obtenida a travs de una ruptura de

la seguridad.
d) Violacin de obligaciones estatutarias o regulatorias.
e) Violacin de cdigos de conducta ticos.
Como tal, la primera evaluacin (sin controles de ningn tipo) estimar un impacto como
muy cercano al (a los) valor (es) concernido (s) o a una combinacin de los mismos. Para
cualquier iteracin siguiente sobre este (estos) activo (s), el impacto ser diferente,
normalmente mucho ms bajo debido a la presencia y a la eficacia de los controles
implementados.
PERUANA 73 de 95
ANEXO C
(INFORMATIVO)
EJEMPLOS DE AMENAZAS TPICAS
La siguiente tabla da ejemplos de amenazas tpicas. La lista se puede usar durante el

proceso de valorizacin de amenazas. Las amenazas pueden ser deliberadas, accidentales o
ambientales (naturales) y pueden resultar, por ejemplo, en el dao o prdida de servicios
esenciales. La lista siguiente indica para cada tipo de amenaza donde D (deliberada), A
(accidental), M (medioambiental) es relevante. D se utiliza para todas las acciones
deliberadas que tienen como objetivos los activos de informacin. A se utiliza para todas
las acciones humanas que pueden daar accidentalmente los activos de la informacin y M
se utiliza para todos los incidentes que no se basan en acciones humanas. El grupo de
amenazas no est en orden de prioridad.
Tipo Amenazas Origen

Incendio A, D, M
Dao por agua A, D, M
Contaminacin A, D, M
Dao Fsico
Accidente mayor A, D, M
Destruccin del equipo o los medios A, D, M
Polvo, corrosin, congelacin A, D, M
Fenmeno climtico M
Fenmeno ssmico M
Eventos naturales Fenmeno volcnico M
Fenmeno meteorolgico M
Inundacin M
Fallas del sistema de aire acondicionado A, D
Prdida de servicios o del suministro de agua
esenciales Prdida del suministro de electricidad A, D, M
Falla del equipo de telecomunicaciones A, D
Radiacin electromagntica A, D, M
Perturbacin debido
Radiacin trmica A, D, M
a radiacin
Pulsos electromagnticos A, D, M
Compromiso de la Intercepcin de seales de interferencia D
informacin comprometedoras
Espionaje remoto D
Interceptacin de comunicaciones D
Robo de medios o documentos D
Robo de equipos D
Hallazgo de medios reciclados o D
PERUANA 74 de 95
descartados
Divulgacin
Datos de fuentes no confiables A, D
Adulteracin del hardware A, D
Adulteracin del software D
Deteccin de posicin A, D
Falla del equipo A
Mal funcionamiento del equipo A
Saturacin del sistema de informacin A, D
Fallas tcnicas
Mal funcionamiento del software A
Ruptura de la mantenibilidad del sistema A, D
de informacin
Uso no autorizado del equipo D
Copia fraudulenta del software D
Acciones no
Uso de software falsificado o copiado A, D
autorizadas
Corrupcin de datos D
Procesamiento ilegal de datos D
Error en el uso A
Abuso de derechos A, D
Compromiso de Falsificacin de derechos D
funciones Negacin de acciones D
Ruptura en la disponibilidad del A, D, M
personal
Se debe dar atencin particular a las fuentes de amenazas humanas. Estas se desglosan en
la tabla siguiente:
Origen de la amenaza Motivacin Consecuencias posibles

Desafo - Hacking
Ego - ingeniera social
Hacker, cracker Rebelin - intrusin en el sistema,
Estatus incursiones
Dinero - acceso no autorizado al sistema
Destruccin de informacin - Crimen informtico (acoso
Revelacin de informacin ciberntico)
ilegal - Acto fraudulento (reproduccin
Ganancia monetaria de archivos, suplantacin,
Criminal informtico Alteracin no autorizada de intercepcin)
datos - Soborno informtico
- Falsificacin o usurpacin de la
direccin
- Intrusin en el sistema
Chantaje - Bomba/Terrorismo
Terrorista
Destruccin - Equipo de guerra informtico
PERUANA 75 de 95
Explotacin - Ataque al sistema (por ejemplo

Venganza negacin distribuida del
Ganancia poltica servicio)
Cobertura meditica - Penetracin en el sistema
- Adulteracin del sistema
Ventaja competitiva - Ventaja de defensa
Espionaje econmico - Ventaja poltica
- Explotacin econmica
- Robo de informacin
Espionaje industrial - Intrusin en la privacidad
(inteligencia, compaas, personal
gobiernos extranjeros, otros - Ingeniera social
intereses gubernamentales) - Penetracin en el sistema
- Acceso no autorizado al
sistema (acceso a informacin
clasificada, propietaria, y/o
relacionada con tecnologa)
Curiosidad - Asalto a un empleado
Ego - Chantaje
Inteligencia - Bsqueda de informacin
Ganancia monetaria propietaria
Venganza - Abuso informtico
Errores y omisiones no - Fraude y robo
intencionales (por ejemplo - Soborno por informacin
error en el ingreso de datos, - Ingreso de datos falsificados o
Gente de adentro de la
error en la programacin) corruptos
institucin (empleados mal
- Intercepcin
capacitados, resentidos,
- Cdigos maliciosos (por
maliciosos, negligentes,
ejemplo virus, bomba lgica,
deshonestos o despedidos)
caballo troyano)
- Venta de informacin personal
- Disfunciones del sistema
(bugs)
- Intrusin en el sistema
- Sabotaje al sistema
- Acceso no autorizado al
sistema
PERUANA 76 de 95
ANEXO D
(INFORMATIVO)
VULNERABILIDADES Y MTODOS PARA LA

EVALUACIN DE LA VULNERABILIDAD
D.1 Ejemplos de vulnerabilidades
La siguiente tabla da ejemplos de vulnerabilidades en varias reas de seguridad, incluyendo

ejemplos de amenazas que pueden explotar estas vulnerabilidades. Las listas pueden
proveer ayuda durante la evaluacin de amenazas y vulnerabilidades para determinar
escenarios de incidentes relevantes. Se enfatiza que en algunos casos otras amenazas
tambin pueden explotar estas vulnerabilidades.
Tipos Ejemplos de vulnerabilidades Ejemplos de amenazas

Mantenimiento insuficiente / instalacin Ruptura de la mantenibilidad del
fallida de medios de almacenamiento sistema de informacin
Falta de esquemas de reemplazo Destruccin de equipo o medio
peridicos
Susceptibilidad a la humedad, al polvo y Polvo, corrosin, congelamiento
a la suciedad
Sensibilidad a la radiacin Radiacin electromagntica
electromagntica
Hardware
Falta de control eficiente del cambio de Error en el uso
configuracin
Susceptibilidad a variaciones de voltaje Prdida de suministro elctrico
Susceptibilidad a variaciones de Fenmeno meteorolgico
temperatura
Almacenamiento no protegido Robo de medios o documentos
Falta de cuidado al descartarlo Robo de medios o documentos
Copia no controlada Robo de medios o documentos
Pruebas al software inexistentes o Abuso de derechos
Software
insuficientes
Errores conocidos en el software Abuso de derechos
No hacer logout cuando se sale de la Abuso de derechos
estacin de trabajo
Disposicin o reutilizacin de medios de Abuso de derechos
almacenamiento sin borrar
apropiadamente
Falta de evidencias de auditoria Abuso de derechos
PERUANA 77 de 95
Asignacin equivocada de derechos de Abuso de derechos

acceso
Software ampliamente distribuido Corrupcin de datos
Aplicar programas de aplicacin a datos Corrupcin de datos
incorrectos en trminos del tiempo
Interfaz de usuario complicada Error en el uso
Falta de documentacin Error en el uso
Seteo incorrecto de parmetros Error en el uso
Fechas incorrectas Error en el uso
Falta de mecanismos de identificacin y Falsificacin de datos
autentificacin como la autentificacin
de usuarios.
Tablas de claves no protegidas. Falsificacin de datos
Mala administracin de claves. Falsificacin de datos
Habilitacin de servicios innecesarios. Procesamiento ilegal de datos
Software inmaduro o nuevo. Mal funcionamiento del software
Especificaciones no claras o Mal funcionamiento del software
incompletas para los desarrolladores.
Falta de control de cambios eficaz. Mal funcionamiento del software
Descarga y uso incontrolado de Adulteracin del software
software.
Falta de copias de respaldo. Adulteracin del software
Falta de proteccin fsica del edificio, Robo de medios o documentos
puertas y ventanas
No producir informes de gestin Uso no autorizado del equipo
Falta de prueba de envo o recepcin de Mediacin de acciones
un mensaje
Lneas de comunicacin no protegidas Intercepcin
Trfico delicado no protegido Intercepcin
Juntas malas en el cableado Falla del equipo de
telecomunicaciones
Punto de falla nico. Falla del equipo de
telecomunicaciones
Red
Falta de identificacin y autentificacin Falsificaciones de derechos
de destinador y destinatario.
Arquitectura de red insegura. Espionaje remoto
Transferencia de claves en claro. Espionaje remoto
Gestin inadecuada de la red (capacidad Saturacin del sistema de
de recuperacin del ruteo). informacin
Conexiones no protegidas de la red Uso no autorizado del equipo
pblica.
Ausencia de personal. Ruptura de la disponibilidad del
Personal
personal
Procedimientos inadecuados de Destruccin de equipo o medios
reclutamiento.
Capacitacin de seguridad insuficiente. Error en uso
Uso incorrecto del software y hardware. Error en uso
PERUANA 78 de 95
Falta de conciencia de seguridad. Error en uso

Falta de mecanismos de monitoreo. Procesamiento ilegal de datos
Trabajo no supervisado del personal Robo de medios o documentos
externo o de limpieza.
Falta de polticas para el uso correcto de Uso no autorizado del equipo
medios de telecomunicaciones y
mensajera.
Uso inadecuado o negligente del control Destruccin de equipo o de
de acceso fsico a edificios y medios
habitaciones.
Ubicaciones en un rea susceptible a las Inundacin
inundaciones.
Sitio
Red inestable de energa elctrica. Prdida de suministro de
electricidad
Falta de proteccin fsica del edificio, Robo de equipos
puertas y ventanas.
Falta de un procedimiento formal para el Abuso de derechos
Organizacin
registro y baja de los usuarios.
Falta de proceso formal para revisar el Abuso de derechos
derecho de acceso (supervisin).
Disposiciones inexistentes o Abuso de derechos
insuficientes (respecto de la seguridad)
en contratos con clientes y / o terceros.
Falta de procedimiento de monitoreo de Abuso de derechos
las instalaciones de procesamiento de la
informacin.
Falta de auditorias regulares Abuso de derechos
(supervisin).
Falta de procedimientos de Abuso de derechos
identificacin y evaluacin del riesgo
Falta de informes de fallas registradas Abuso de derechos
en los registros del administrador y del
operador.
Respuesta inadecuada del Ruptura de la mantenibilidad del
mantenimiento del servicio sistema de informacin
Inexistencia o insuficiencia de acuerdo Ruptura de la mantenibilidad del
sobre el nivel del servicio sistema de informacin
Falta de procedimiento de control de Ruptura de la mantenibilidad del
cambios sistema de informacin
Falta de procedimiento formal para el Corrupcin de datos
control de la documentacin del ISNS
Falta de procedimiento formal para la Corrupcin de datos
supervisin del registro del ISNS
Falta de proceso formal para Datos de fuentes no confiables
autorizacin de informacin pblica
disponible
PERUANA 79 de 95
Falta de asignacin apropiada de Negacin de acciones

responsabilidades de seguridad en la
informacin
Faltad de planes de continuidad Falla del equipo
Falta de una poltica de uso de correos Error en uso
electrnicos
Falta de procedimientos para introducir Error en uso
software en sistemas operativos
Faltas de registros en los historiales del Error en uso
administrador y del operador
Falta de procedimientos para manejo de Error en uso
la informacin clasificada
Falta de responsabilidades sobre la Error en uso
seguridad de la informacin en las
descripciones de puestos
Ausencia o insuficiencia de Procesamiento ilegal de datos
disposiciones (concernientes a la
seguridad de la informacin en contratos
con empleados)
Falta de proceso disciplinario definido Robo de equipos
en caso de incidentes en la seguridad de
la informacin
Falta de poltica formal sobre el uso de Robo de equipos
computadoras porttiles
Falta de control de activos que se Robo de equipos
encuentran fuera del local
Inexistencia o insuficiencia de la Robo de medios o documentos
poltica de Escritorio despejado y
pantalla despejada
Falta de autorizacin al acceso a las Robo de medios o documentos
instalaciones de procesamiento de la
informacin
Falta de mecanismos de monitoreo Robo de medios o documentos
establecidos para las rupturas de la
seguridad
Falta de revisiones regulares de la Uso no autorizado del equipo
gestin
Falta de procedimientos para reportar Uso no autorizado del equipo
debilidades en la seguridad
Falta de procedimientos sobre el Uso de software falsificado o
cumplimiento de disposiciones respecto copiado
de derechos intelectuales.
PERUANA 80 de 95
D.2 Mtodos para evaluar las vulnerabilidades tcnicas
Se puede usar mtodos proactivos como la verificacin del sistema de informacin para
identificar vulnerabilidades que dependen del carcter crucial de la informacin del sistema
de tecnologa de informacin y comunicaciones (TIC) as como los recursos disponibles
(por ejemplo: fondos asignados, tecnologa disponible, personas con experiencia para
conducir la prueba). Los mtodos de prueba incluyen los puntos siguientes:
- Herramienta automatizada para el escaneo de vulnerabilidades.

- Pruebas y evaluacin de seguridad.
- Prueba de penetracin.
- Revisin del cdigo.
La herramienta automatizada para escanear la vulnerabilidad se usa para escanear un grupo

de anfitriones o una red de servicios vulnerables conocidos (por ejemplo el sistema permite
un protocolo de transferencia de archivos (STP) annimo, y hacer rels en el envo de
correos). Debe notarse sin embargo, que algunas de las vulnerabilidades potenciales
identificadas por la herramienta automatizada de escaneo pueden no representar verdaderas
vulnerabilidades en el contexto del entorno del sistema. Por ejemplo, algunas de estas
herramientas de escaneo dan puntaje a vulnerabilidades potenciales sin considerar el
entorno y necesidades del sitio. Algunas de las vulnerabilidades que el software
automatizado de escaneo muestra con alertas, en realidad puede no ser vulnerable para un
sitio en particular, sino que estn consideradas de esa manera porque el ambiente as lo
requiere. Por tanto, este mtodo de pruebas puede producir falsos positivos.
Otra tcnica que se puede utilizar para identificar vulnerabilidades en el sistema TIC
durante el proceso de evaluacin del riesgo es la prueba de seguridad y evaluacin (STE,
por sus siglas en ingles). Incluye el desarrollo y ejecucin de un plan de pruebas (por
ejemplo libreto de la prueba, procedimientos de la prueba y resultados esperados de la
prueba). El propsito de las pruebas al sistema de seguridad es comprobar la eficacia de los
controles de seguridad de un sistema TIC tal como se han aplicado en un entorno
operativo. El objetivo es asegurar que los controles aplicados cumplan con la
especificacin aprobada de seguridad para el software y hardware e implementen la poltica
de seguridad de la organizacin o satisfagan los estndares de la industria.
PERUANA 81 de 95
La prueba de penetracin puede utilizarse para complementar la revisin de los controles

de seguridad y asegurar que los distintos factores del sistema TIC cuenten con seguridad.
Cuando se usa en el proceso de evaluacin del riesgo, la prueba de penetracin puede
utilizarse para evaluar la capacidad que tiene un sistema TIC de soportar intentos
intencionales de evitar cumplir con los sistemas de seguridad. Su objetivo es probar el
sistema del TIC desde el punto de vista de una fuente de amenazas e identificar las fallas
potenciales en los esquemas de proteccin de los sistemas TIC.
La revisin del cdigo es la manera ms exhaustiva de evaluacin de vulnerabilidad, pero

tambin puede ser la ms cara.
Los resultados de estos tipos de pruebas de seguridad ayudaran a identificar las

vulnerabilidades de un sistema. Es importante notar que las herramientas y tcnicas de
penetracin pueden dar resultados falsos salvo que se explote con xito la vulnerabilidad.
Para explotar vulnerabilidades particulares uno tiene que saber cules son los parches de
sistema-aplicacin exactos instalados en los sistemas que se prueban. Si esos datos no son
conocidos en el momento de realizar las pruebas, puede no ser posible explotar con xito
vulnerabilidades particulares (por ejemplo adquiriendo un remote reverse shell). Sin
embargo, todava es posible averiar o reiniciar un proceso o sistema probado. En tal caso,
el objeto probado debe considerarse tambin como vulnerable.
Los mtodos pueden incluir las siguientes actividades:
- Entrevistas a personas y usuarios.

- Cuestionarios.
- Inspeccin fsica.
- Anlisis de documentos.
PERUANA 82 de 95
ANEXO E
(INFORMATIVO)
ENFOQUES DE EVALUACIN DEL RIESGO EN

SEGURIDAD DE LA INFORMACIN
E.1 Evaluacin del riesgo en seguridad de la informacin de alto nivel
La evaluacin de alto nivel permite la definicin de prioridades y de la cronologa en las

acciones. Por varias razones, como el presupuesto, puede no ser posible implementar todos
los controles simultneamente y slo se pueden resolver los riesgos cruciales a travs del
proceso de tratamiento del riesgo. Asimismo, puede ser prematuro comenzar a hacer una
gestin detallada del riesgo si se avizora que la implementacin se debe realizar luego de
uno o dos aos. Para alcanzar este objetivo, la evaluacin de alto nivel puede comenzar con
una evaluacin de las consecuencias de alto nivel en vez de comenzar con un anlisis
sistemtico de amenazas, vulnerabilidades, activos y consecuencias.
Otra razn de comenzar con la evaluacin de alto nivel es sincronizar otros planes
relacionados con la gestin del cambio (o continuidad el negocio) por ejemplo, no hay que
asegurar completamente un sistema o aplicacin si se planea tercerizar en el futuro cercano,
aunque quizs todava vale la pena hacer la evaluacin del riesgo para definir el contrato de
tercerizacin.
Las caractersticas de la iteracin de la evaluacin del riesgo del alto nivel pueden incluir
las siguientes:
- La evaluacin del riesgo de alto nivel puede dirigirse a una visin ms

global de la organizacin y de sus sistemas de informacin, considerando los
aspectos de la tecnologa como independientes de las cuestiones empresariales. Al
hacer esto, el anlisis del contexto de concentra ms en el negocio y el entorno
operativo que en los elementos tecnolgicos.
- La evaluacin del riesgo de alto nivel puede resolver una lista ms limitada
de amenazas y vulnerabilidades agrupadas en dominios definidos o para hacer el
proceso ms expeditivo, puede centrarse en los escenarios de riesgo o ataque en vez
de sus elementos.
PERUANA 83 de 95
- Los riesgos que se presentan en una evaluacin del riesgo de alto nivel
frecuentemente son dominios de riesgo ms generales que los riesgos especficos
identificados.
- Como los escenarios o los riesgos se agrupan en dominios, el tratamiento del

riesgo propone listas de controles. En este campo, las actividades de tratamiento del
riesgo tratan entonces primero de proponer y seleccionar controles comunes que sean
vlidos en todo el sistema.
Sin embargo la evaluacin del riesgo de alto nivel, como pocas veces se refiere a detalles
de tecnologa, es ms apropiada para proveer controles organizacionales y no tcnicos y
aspectos de gestin de los controles tcnicos o salvaguardas tcnicas clave y comunes
como los respaldos y los antivirus.
Las ventajas de una evaluacin del riesgo de alto nivel son las siguientes:
- La incorporacin de un enfoque simple inicial probablemente gane

aceptacin del programa de evaluacin del riesgo.
- Debe ser posible construir una imagen estratgica de un programa de

informacin organizacional, es decir actuar como una buena ayuda a la
planificacin.
- Se puede aplicar recursos y dinero all donde sean ms beneficiosos y se

tratar primero los sistemas que tengan una mayor necesidad de proteccin.
- Como los anlisis de riesgo inicial estn en un alto nivel y son

potencialmente menos exactos, la nica desventaja potencial es que pueda no
identificarse que algunos procesos o sistemas no empresariales requieren una
segunda evaluacin detallada del riesgo. Esto se puede evitar si existe una
informacin adecuada sobre todos los aspectos de la organizacin y su informacin y
sistemas, incluyendo informacin adquirida a partir de la evaluacin de incidentes de
seguridad de la informacin.
La evaluacin del riesgo de alto nivel considera los valores empresariales de los activos de
informacin y los riesgos desde el punto de vista del negocio de la organizacin. En el
primer punto de decisin (vase la figura 1) varios factores ayudan a determinar si la
evaluacin de alto nivel es adecuada para tratar los riesgos. Estos factores pueden incluir
los siguientes:
PERUANA 84 de 95
- Los objetivos de negocio a lograrse utilizando varios activos de

informacin.
- El grado en el cual el negocio de la organizacin depende de cada activo de

informacin, es decir que funciones que la organizacin considera cruciales para su
supervivencia o para el control eficaz del negocio dependen de cada activo o de la
confidencialidad, integridad, disponibilidad, no repudio, rendicin de cuentas,
autenticidad y confiabilidad de la informacin almacenada y procesada en este activo.
- El nivel de inversin en cada activo de informacin en trminos de

desarrollo, mantenimiento o reemplazo del activo y los activos de informacin para
los cuales la organizacin asigna valor directamente.
Cuando se evala estos activos, la decisin se hace ms fcil. Si los objetivos de un activo
son extremadamente importantes para la conduccin del negocio de una organizacin, o si
los activos estn en grave riesgo entonces se debe conducir a una segunda evaluacin
detallada del riesgo para el activo de informacin particular (o parte del mismo).
Una regla general que debe aplicarse es si la falta de seguridad en la informacin puede
resultar en consecuencias adversas significativas para la organizacin, sus procesos
empresariales o sus activos, luego se hace necesaria una segunda iteracin de la evaluacin
del riesgo a nivel ms detallado para identificar los riesgos potenciales.
E.2 Evaluacin detallada del riesgo en seguridad de la informacin
El proceso de evaluacin detallada del riesgo en seguridad de la informacin incluye una

identificacin y valorizacin profunda de los activos, la evaluacin de amenazas a esos
activos y la evaluacin de vulnerabilidades. Los resultados de esas actividades se utilizan
entonces para evaluar los riesgos y luego identificar el tratamiento del riesgo.
El paso detallado generalmente requiere mucho tiempo, esfuerzo y experiencia y por lo

tanto debe ser conveniente para sistemas de informacin en alto riesgo.
La etapa final de la evaluacin detallada del riesgo en seguridad de la informacin es

evaluar los riesgos generales, lo cual es materia de este anexo.
PERUANA 85 de 95
Se puede evaluar las consecuencias de varias maneras, incluyendo el uso de medidas

cuantitativas, por ejemplo monetarias, y cualitativas (las que se pueden basar en el uso de
adjetivos como moderado o grave), o una combinacin de ambas. Para evaluar la
posibilidad de la ocurrencia de amenazas, se debe establecer el horizonte temporal sobre el
cual el activo tendr valor o requiera proteccin. La posibilidad de que ocurra una amenaza
especfica depende de lo siguiente:
- La atraccin del activo, o el posible impacto aplicable cuando se considera

una amenaza humana deliberada.
- La facilidad de conversin que explota una vulnerabilidad del activo en

recompensa, aplicable si se considera una amenaza humana deliberada.
- Las capacidades tcnicas del agente de la amenaza aplicables a amenazas

humanas deliberadas, y
- La susceptibilidad de la vulnerabilidad a la explotacin aplicable tanto a

vulnerabilidades tcnicas como no tcnicas.
Muchos mtodos utilizan tablas y combinan las medidas subjetivas y empricas. Es

importante que la organizacin utilice un mtodo con el que est cmoda, en el que la
organizacin tenga confianza y que produzca resultados repetibles. A continuacin se dan
algunos ejemplos de tcnicas basadas en tablas:
E.2.1 Ejemplo 1 Matriz con valores predefinidos
En los mtodos de evaluacin del riesgo de este tipo, se valoriza los activos fsicos, reales o
propuestos en trminos de los costos de reemplazo o reconstruccin (es decir, medidas
cuantitativas). Estos costos se convierten entonces a la misma escala cualitativa que la que
se utiliza para la informacin (vase a continuacin). Se valorizan activos de software
reales o propuestos de la misma manera que los activos fsicos con costos de compra o
reconstruccin que se identifican y luego se convierten a la misma escala cualitativa que se
utiliza para la informacin. Adicionalmente, si se encuentra que cualquier software de
aplicacin tiene sus necesidades intrnsecas de confidencialidad o integridad (por ejemplo
si el cdigo fuente por s mismo es delicado comercialmente) se valoriza de la misma
manera que para la informacin.
PERUANA 86 de 95
Los valores para la informacin se obtienen entrevistando a gerentes empresariales

seleccionados (los propietarios de los datos) que pueden hablar con autoridad sobre los
datos, para determinar el valor y sensibilidad de los datos que estn verdaderamente en uso
o que se deben almacenar, procesar o a los que se tiene que tener acceso. Las entrevistas
facilitan la evaluacin del valor y la sensibilidad de la informacin en trminos de los
escenarios del peor caso que se podra esperar razonablemente ocurra debido a
consecuencias adversas sobre el negocio por divulgacin no autorizada, modificacin no
autorizada, no disponibilidad para perodos variables y destruccin.
La valorizacin se logra utilizando lineamientos de valorizacin de la informacin que

cubren cuestiones como:
- Seguridad personal.
- Informacin personal.
- Obligaciones legales y regulatorias.
- Aplicacin de la ley.
- Intereses comerciales y econmicos .
- Prdida financiera/ interrupcin de actividades.
- Orden pblico.
- Poltica y operaciones empresariales.
- Prdida de buen nombre.
- Contrato o acuerdo con un cliente.
Los lineamientos facilitan identificacin de los valores en una escala numrica como la
escala de 0 a 4 que se muestra en la matriz del ejemplo a continuacin, permitiendo as el
reconocimiento de valores cuantitativos donde sea posible y lgico y de valores cualitativos
donde los valores cuantitativos no sean posibles, por ejemplo si se pone en peligro la vida
humana.
La siguiente actividad importante es completar las parejas de cuestionarios para cada tipo
de amenazas, para cada agrupamiento de activos a los que se relaciona un tipo de amenaza,
para permitir la evaluacin de los niveles de amenazas (probabilidad de ocurrencia) y los
niveles de vulnerabilidades (facilidad de explotacin por las amenazas para causar
consecuencias adversas). Cada respuesta a una pregunta implica un puntaje. Estos puntajes
se acumulan a travs de una base de conocimientos y se comparan con rangos. Esto
identifica niveles de amenaza en una escala de alta a baja y niveles de vulnerabilidad de
manera similar, tal como se muestra en la matriz del ejemplo siguiente, diferenciando entre
los tipos de consecuencias como relevantes. La informacin para completar los
cuestionarios debe reunirse a partir de entrevistas con personal tcnico apropiado y las
PERUANA 87 de 95
personas concernidas, as como inspecciones de la ubicacin fsica y revisiones de la

documentacin.
TABLA E.1 a)
Posibilidad de
ocurrencia Baja Media Alta
amenaza
Facilidad de
L H M L H M L H M
explotacin
0 0 1 2 1 2 3 2 3 4
Valor 1 1 2 3 2 3 4 3 4 5
del 2 2 3 4 3 4 5 4 5 6
Activo 3 3 4 5 4 5 6 5 6 7
4 4 5 6 5 6 7 6 7 8
Los valores de los activos y los niveles de amenaza y vulnerabilidad relevantes para cada
tipo de consecuencias se hacen corresponder en una matriz como la que se muestra a
continuacin de modo que se identifique para cada combinacin la medida relevante de
riesgo en una escala de 0 a 8. Los valores se colocan en la matriz de manera estructurada. A
continuacin se proporciona un ejemplo:
Para cada activo, se consideran las vulnerabilidades relevantes y sus amenazas

correspondientes. Si hay una vulnerabilidad sin amenaza correspondiente, o una amenaza
sin vulnerabilidad correspondiente, actualmente no hay riesgo (pero se debe tener cuidado
en el caso en que esta situacin cambie). Ahora la fila apropiada en la matriz se identifica
por el valor del activo y la columna apropiada se identifica por la posibilidad de que ocurra
la amenaza y la facilidad de explotacin. Por ejemplo, si el activo tiene el valor 3 la
amenaza es alta y la vulnerabilidad baja, la medicin de riesgo es 5. Asumamos que un
activo tiene un valor de 2, por ejemplo para modificacin, el nivel de amenaza es bajo y
la facilidad de explotacin es alta, entonces la medida del riesgo es 4. El tamao de la
matriz, en trminos del nmero de categoras con posibilidad de amenaza, facilidad de
categoras de explotacin y nmero de categoras de valorizacin de activos se puede
ajustar a las necesidades de la organizacin. Las columnas y filas adicionales necesitarn
medidas de riesgo adicional. El valor de este enfoque est en la calificacin de los riesgos a
resolverse.
PERUANA 88 de 95
Una matriz similar como la que se muestra en la matriz E.1 b) resulta de la consideracin
de la posibilidad de un escenario de incidentes, mapeado contra el impacto estimado sobre
el negocio. La posibilidad de un escenario de incidentes est dada por una amenaza que
explota una vulnerabilidad con una cierta posibilidad. La tabla mapea esta posibilidad
contra el impacto sobre el negocio relacionado al escenario de incidentes. El riesgo
resultante se mide en una escala de 0 a 8 que se puede evaluar contra los criterios de
aceptacin del riesgo. Esta escala de riesgos puede tambin mapearse a un puntaje general
de riesgo, por ejemplo del modo siguiente:
- Riesgo bajo: 0-2

- Riesgo medio: 3-5
- Riesgo alto: 6-8
TABLA E.1 b)
Posibilidad Muy baja

Baja Mediano Alta Muy Alta
de escenario (Muy poco
(Probable) (Posible) (Probable) (Frecuente)
de incidentes probable)
Muy bajo 0 1 2 3 4
Impacto Bajo 1 2 3 4 5
sobre el Medio 2 3 4 5 6
negocio Alto 3 4 5 6 7
Muy alto 4 5 6 7 8
E.2.2 Ejemplo 2 Calificacin de las amenazas por mediciones del riesgo
Se puede utilizar una matriz o tabla como la que se muestra en la tabla E.2 para relacionar
los factores de consecuencia (valor de activos) y la posibilidad de ocurrencia de las
amenazas (tomando en cuenta los aspectos de vulnerabilidad). El primer paso es evaluar las
consecuencias (valoracin de activos en una escala predefinida, por ejemplo de 1 a 5, de
cada activo amenazado (columna b en la tabla). El segundo paso es evaluar la posibilidad
de la ocurrencia de amenazas en una escala predefinida, por ejemplo 1 a 5, de cada
amenaza (columna c en la tabla). El tercer paso es calcular la medida del riesgo por
medio de la multiplicacin (b x c). Finalmente se puede calificar las amenazas en orden de
su medida del riesgo asociada. Ntese que en este ejemplo se toma 1 como la consecuencia
ms baja y como la posibilidad ms baja de ocurrencia.
PERUANA 89 de 95
TABLA E.2
Descriptor de la Valor de la Posibilidad de la Medida Calificacin de

amenaza consecuencia (activo) ocurrencia de amenaza del riesgo la amenaza
(a) (b) (c) (d) (e)
Amenaza A 5 2 10 2
Amenaza B 2 4 8 3
Amenaza C 3 5 15 1
Amenaza D 1 3 3 5
Amenaza E 4 1 4 4
Amenaza F 2 4 8 3
Tal como se muestra arriba, ste es un procedimiento que permite comparar distintas
amenazas con diferentes consecuencias y probabilidades de ocurrencia y colocarlas en
orden de prioridad tal como se muestra aqu. En algunas instancias ser necesario asociar
valores monetarios con las escalas empricas que se utilizan aqu.
E.2.3 Ejemplo 3 - Evaluacin del valor para la probabilidad y las

consecuencias posibles de los riesgos
En este ejemplo, se enfatiza las consecuencias de los incidentes en seguridad de la

informacin (es decir escenario de incidencias) y el determinar a cul sistema se debe dar
prioridad. Esto se hace evaluando dos valores para cada activo y riesgo, lo cual en
combinacin determinar el puntaje para cada activo. Cuando todos los puntajes activos
para el sistema se suman, se determina una medida de riesgo para ese sistema.
Primero, se asigna un valor a cada activo. Este valor se relaciona a las consecuencias
adversas potenciales que pueden surgir si se amenaza el activo. Para cada amenaza
aplicable al activo, este valor del activo se asigna al activo.
Luego se evala el valor de probabilidad. Esto se evala a partir de una combinacin de la

probabilidad de que la amenaza ocurra y la facilidad de explotacin de la vulnerabilidad.
Vase la tabla E.3 que expresa la probabilidad de un escenario de incidentes.
PERUANA 90 de 95
TABLA E.3
Probabilidades de la
Baja Media Alta
amenaza
Niveles de
L M H L M H L M H
Vulnerabilidad
Valor de vulnerabilidad
de un escenario de 0 1 2 1 2 3 2 3 4
incidentes
Luego, se asigna un puntaje de activo/amenaza encontrando la intercepcin del valor del

activo y el valor de probabilidad en la tabla E.4. Los puntajes de activo/amenaza se
totalizan para producir un puntaje total de activos. Esta figura se puede utilizar para
diferenciar entre los activos que forman parte de un sistema.
TABLA E.4
Valor del activo 0 1 2 3 4

Valor de la probabilidad
0 0 1 2 3 4
1 1 2 3 4 5
2 2 3 4 5 6
3 3 4 5 6 7
4 4 5 6 7 8
El paso final es totalizar todos los puntajes totales del activo para los activos del sistema,
produciendo un puntaje del sistema. Esto se puede utilizar para diferenciar entre sistemas y
para determinar a que proteccin del sistema debera drsele prioridad.
En los siguientes ejemplos se elige todos los valores de manera aleatoria.
Supongamos que el sistema S tiene tres activos A1, A2 y A3. Tambin supongamos que
hay dos amenazas T1 y T2 aplicables al sistema S. Digamos que el valor de A1 es 3, de
manera similar digamos que el valor del activo de A2 sea 2 y que el valor del activo de A3
sea 4.
PERUANA 91 de 95
Si para A1 y T1 la probabilidad de amenaza es baja y la facilidad de la explotacin de la

vulnerabilidad es media, entonces el valor de probabilidad es 1 (vase la tabla E.3).
El puntaje de activo/amenaza A1/T1 se puede derivar de la tabla E.4 como la intercepcin

del valor 3 del activo y el valor de probabilidad 1, es decir 4. De manera similar, para
A1/T2 digamos que la probabilidad de la amenaza es media y la facilidad de explotacin de
la vulnerabilidad es alta, dado un puntaje A1/T2 de 6.
Ahora el puntaje total del activo A1T se puede calcular, es decir, 10. El puntaje total del activo se
calcula para cada activo y amenaza aplicable. El puntaje total del sistema se calcula aadiendo A1
T + A2 T + A3 T para dar ST.
Ahora se puede comparar diferentes sistemas para establecer prioridades y distintos activos dentro
de un sistema tambin.
El ejemplo de arriba se plantea en trminos de sistemas de informacin. Sin embargo, se puede

aplicar un enfoque similar a los procesos empresariales.
PERUANA 92 de 95
ANEXO F
(INFORMATIVO)
RESTRICCIONES PARA LA REDUCCIN DEL RIESGO
Cuando se consideran las restricciones para la reduccin del riesgo, se debe tomar en
cuenta las siguientes restricciones:
Restricciones de tiempo
Pueden existir muchos tipos de restricciones de tiempo. Por ejemplo, se debe implementar
controles dentro de un perodo aceptable para los gerentes de la organizacin. Otro tipo de
restriccin de tiempo es si se puede implementar un control dentro del tiempo de vida de la
informacin o sistema. Un tercer tipo de restriccin de tiempo puede ser el perodo que los
gerentes de la organizacin deciden que es un perodo aceptable para exponerse a un riesgo
en particular.
Restricciones financieras
Los controles no deben ser ms caros de implementar o mantener que el valor de los
riesgos que van a proteger, excepto donde el cumplimiento sea obligatorio (por ejemplo
con la legislacin). Se debe hacer todos los esfuerzos para no exceder presupuestos
asignados y lograr ventaja financiera a travs de los controles. Sin embargo, en algunos
casos puede no ser posible lograr la seguridad deseada y el nivel de aceptacin del riesgo
debido a las restricciones del presupuesto. Por lo tanto, esto se convierte en una decisin de
los gerentes de la organizacin para la resolucin de esta situacin.
Se debe tener mucho cuidado si el presupuesto reduce el nmero o calidad de los controles
a implementarse ya que esto puede llevar a la retencin implcita de un mayor riesgo del
que se haba planeado. El presupuesto establecido para los controles debe utilizarse como
un factor limitante solamente con mucho cuidado.
PERUANA 93 de 95
Restricciones tcnicas
Se puede evitar fcilmente problemas tcnicos como la compatibilidad de los programas o

de hardware si se toman en cuenta durante la seleccin de controles. Adems, a menudo las
restricciones tcnicas retrasan la implementacin retrospectiva de controles a un proceso o
sistema existente. Estas dificultades pueden mover el equilibrio de controles hacia los
aspectos de procedimiento y fsicos de la seguridad. Puede ser necesario revisar el
programa de seguridad de la informacin para lograr objetivos de seguridad. Esto puede
ocurrir cuando los controles no satisfacen los resultados esperados en la reduccin de
riesgos sin reducir la productividad.
Restricciones operativas
Las restricciones operativas como la necesidad de operar 24 horas al da por 7 das a la

semana requiere realizar respaldos y puede resultar en una implementacin de controles
compleja y costosa salvo que estn incorporados en el diseo desde el inicio.
Restricciones culturales
Las restricciones culturales a la seleccin de controles pueden ser especficas a un pas, un

sector, una organizacin o incluso un departamento dentro de una organizacin. No se
puede aplicar todos los controles en todos los pases. Por ejemplo, puede ser posible
implementar bsquedas en carteras en partes de Europa, pero no en partes de Medio
Oriente. Los aspectos culturales no se pueden ignorar porque muchos controles se basan en
el apoyo activo del personal. Si el personal no comprende la necesidad del control o no lo
encuentra culturalmente aceptable, el control se har ineficaz con el tiempo.
Restricciones ticas
Las restricciones ticas pueden tener implicaciones importantes sobre los controles ya que
la tica cambia en base a las normas sociales. Esto puede impedir la implementacin de
controles como el escaneo de correos electrnicos en algunos pases. La privacidad de la
informacin tambin puede cambiar dependiendo de la tica de la regin o del gobierno.
Esto puede preocupar ms en algunos sectores industriales que en otros, por ejemplo el
gobierno y la atencin de salud.
PERUANA 94 de 95
Restricciones ambientales
Los factores ambientales pueden influir la seleccin de controles como la disponibilidad de

espacio, las condiciones climticas extremas, la geografa natural y urbana circundantes.
Por ejemplo, se puede requerir en algunos pases que las construcciones sean anti-ssmicas,
pero esto ser innecesario en otros.
Restricciones legales
Los factores legales como la proteccin de los datos personales o las disposiciones del
cdigo penal para el procesamiento de la informacin pueden afectar la seleccin de
controles. El cumplimiento legislativo regulatorio puede obligar a ciertos tipos de control
incluyendo la proteccin de datos y la auditoria financiera. Tambin pueden impedir el uso
de algunos controles, por ejemplo la encriptacin. Otras leyes y regulaciones como la
legislacin de las leyes laborales, el departamento de bomberos, la salud y la seguridad, as
como las regulaciones del sector econmico, etc. podran afectar tambin la seleccin de
controles.
Facilidad de uso
Una mala interfaz humano-tecnologa resultar en error humano y puede hacer que el
control sea intil. Los controles deben seleccionarse para proveer facilidad ptima de uso a
la vez que se logra un nivel aceptable de riesgo residual al negocio. Los controles que son
difciles de usar impactarn su eficacia, ya que los usuarios pueden tratar de evitarlos o
ignorarlos tanto como sea posible. Los controles de acceso complejo dentro de una
organizacin pueden alentar a los usuarios a encontrar mtodos de acceso alternativos y no
autorizados.
Restricciones del personal
El costo de la disponibilidad y de los salarios de personal especializado para implementar

los controles y la capacidad de movilizar personal entre lugares en condiciones operativas
adversas es algo que debe considerarse. Es posible que los expertos no estn disponibles de
inmediato para implementar controles planificados o que dichos expertos sean demasiado
costosos para la organizacin. Otros aspectos que pueden tener implicaciones importantes
para las polticas y prcticas de seguridad son la tendencia de cierto personal de discriminar
PERUANA 95 de 95
a otros miembros del personal que no pasan por un tamizaje de seguridad. Asimismo, la
seguridad de contratar a las personas correctas para el trabajo y tambin de encontrar a las
personas correctas puede resultar en que se culmine una contratacin antes de hacer la
seleccin por seguridad. El requisito de que la seleccin utilizando criterios de seguridad se
realice antes de la contratacin es la prctica normal y ms segura.
Restricciones de integrar controles nuevos y existentes
A menudo se pasa por alto la integracin de nuevos controles en la infraestructura existente

y las inter-dependencias entre controles. Los nuevos controles pueden no implementarse
fcilmente si existe incongruencia o incompatibilidad con los controles existentes. Por
ejemplo, un plan para utilizar elementos biomtricos para el control de acceso fsico puede
causar conflicto con un sistema existente basado en PINs para el control de acceso. El
costo de cambiar los controles de controles existentes a controles planeados debe incluir
los elementos a aadirse a los costos generales del tratamiento del riesgo. Quizs no sea
posible implementar un control seleccionado debido a la interferencia con los controles
actuales.

Bibliografia 04 ISO 27005 PDF

Загружено:

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

Оригинальное название

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

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

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

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

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

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

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

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

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

Bibliografia 04 ISO 27005 PDF

Загружено:

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

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

NORMA TCNICA NTP-ISO/IEC 27005

EDI. Tecnologa de la informacin. Tcnicas de seguridad.

R.029-2009/INDECOPI-CNB. Publicada el 2009-11-07 Precio basado en 95 pginas

4. ESTRUCTURA DE ESTA NORMA TCNICA 3

6. VISTA PANORMICA DEL PROCESO DE GESTIN DEL

7. DETERMINACIN DEL CONTEXTO 12

8. EVALUACIN DEL RIESGO EN SEGURIDAD

9. TRATAMIENTO DEL RIESGO EN SEGURIDAD

10. ACEPTACIN DEL RIESGO EN SEGURIDAD

11. COMUNICACIN DEL RIESGO EN SEGURIDAD

12. MONITOREO Y REVISIN DEL RIESGO EN SEGURIDAD

A.1 La presente Norma Tcnica Peruana ha sido elaborada por el Comit

A.2 El Comit Tcnico de Normalizacin de Codificacin e intercambio

A.3 Esta Norma Tcnica Peruana es una adopcin de la norma

B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIN

Secretara GS1 PERU

Presidente Roberto Puy

Secretaria Mary Wong

DISTRIBUIDORA MAYORISTA SYMBOL S.A. Adela Barcenas

E. WONG S.A. Marcela Aparicio

FOLIUM S.A.C. Roberto Huby

IBC SOLUTIONS PERU S.A.C. Oscar Velsquez

ITS CONSULTANTS S.A.C. Ricardo Dioses

OFICINA DE NORMALIZACION PREVISIONAL Roberto Puy

PONT. UNIV. CATOLICA DEL PERU Viktor Khlebnikov

PRESIDENCIA DEL CONSEJO Max Lzaro

PROCTER & GAMBLE DEL PERU S.A. Javier Kameya

SUPERINTENDENCIA DE ADMINISTRACION Daniel Llanos

TECNOLOGA FLEXOGRAFICA S.A. Luis Chvez Saavedra

TCI S.A. Renzo Alcntara

UNILEVER ANDINA PERU S.A. Rolando Rivadeneira

GS1 PERU Tatiana Pea

EDI. Tecnologa de la informacin. Tcnicas de seguridad.

Es importante conocer los conceptos, modelos, procesos y tecnologas descritos en las

2.1 Normas Tcnicas Internacionales

2.1.1 ISO/IEC 27001:2005 Information technology Security techniques

2.1.2 ISO/IEC 27002:2005 Information technology Security techniques

3.1 impacto: Cambio adverso en el nivel de objetivos empresariales logrados.

3.2 riesgo en la seguridad de la informacin: El potencial de que una

NOTA: Se mide en trminos de una combinacin de la probabilidad de un evento y su consecuencia.

3.3 evitamiento del riesgo: Decisin de no involucrarse en una accin para

3.4 comunicacin del riesgo: Intercambio o compartir informacin sobre el

3.5 estimacin del riesgo: Proceso para asignar valores a la probabilidad y

3.6 identificacin del riesgo: Proceso para encontrar, listar y caracterizar

3.8 retencin del riesgo: Aceptacin de la carga de la prdida o el beneficio de

NOTA: En el contexto de los riesgos para la seguridad de la informacin, slo se consideran

NOTA: En el contexto de los riesgos para la seguridad de la informacin, slo se consideran

4. ESTRUCTURA DE ESTA NORMA TCNICA PERUANA

El captulo 5 proporciona informacin sobre los antecedentes.

- Establecimiento del contexto en el captulo 7,

- Evaluacin del riesgo en el captulo 8,

- Tratamiento del riesgo en el captulo 9,

- Aceptacin del riesgo en el captulo 10,

- Comunicacin del riesgo en el captulo 11,

- Monitoreo y revisin del riesgo en el captulo 12.

En el Anexo E se presentan ejemplos sobre enfoques de evaluacin del riesgo en seguridad

El Anexo F presenta restricciones para la reduccin del riesgo.

Insumo: Identifica cualquier informacin requerida para realizar la actividad.

Accin: Describe la actividad.

Producto: Identifica toda informacin derivada luego de realizar la actividad.

Es necesario tener un enfoque sistemtico sobre la gestin del riesgo en seguridad de la

La gestin del riesgo en seguridad de la informacin debe ser un proceso continuo. El

La gestin del riesgo en seguridad de la informacin debe contribuir a lo siguiente: