Seguridad de La Información

NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 2017
Dirección de Normalización - INACAL
Calle Las Camelias 817, San Isidro (Lima 27) Lima, Perú
Tecnología de la información. Técnicas de seguridad.

Código de prácticas para controles de seguridad de la
información
Information technology. Security techniques. Code of practice for information security controls
(EQV. ISO/IEC 27002:2013 Information technology - Security techniques - Code of practice for information
security controls, ISO/IEC 27002:2013/Cor.1:2014 and ISO/IEC 27002:2013/Cor.2:2015)
2017-12-27
1ª Edición
R.D. N° 056-2017-INACAL/DN. Publicada el 2017-12-29 Precio basado en 162 páginas

I.C.S.: 35.040 ESTA NORMA ES RECOMENDABLE
Descriptores: Tecnología, información, técnicas, seguridad, sistema de gestión, requisitos
© ISO/IEC 2013 - © INACAL 2017

© ISO/IEC 2013
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta publicación
podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia o
publicándolo en el Internet o intranet, sin permiso por escrito del INACAL, único representante de la ISO/IEC
en territorio peruano.
© INACAL 2017
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta publicación
podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia o
publicándolo en el internet o intranet, sin permiso por escrito del INACAL.
INACAL
Calle Las Camelias 817, San Isidro

Lima - Perú
Tel.: +51 1 640-8820
administracion@inacal.gob.pe
www.inacal.gob.pe
i
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
ÍNDICE
página
ÍNDICE ii
PRÓLOGO v
PRÓLOGO (ISO) vii
INTRODUCCIÓN viii
1 Objeto y campo de aplicación 1
2 Referencias normativas 1
3 Términos y definiciones 2
4 Estructura de esta norma 2
4.1 Capítulos 2
4.2 Categorías de control 2
5 Políticas de seguridad de la información 3
5.1 Dirección de la gerencia para la seguridad de la información 3
6 Organización de la seguridad de la información 7
6.1 Organización interna 7

6.2 Dispositivos móviles y teletrabajo 12
7 Seguridad de los recursos humanos 17
7.1 Antes del empleo 17

7.2 Durante el empleo 20
7.3 Terminación y cambio de empleo 25
8 Gestión de activos 26
8.1 Responsabilidad por los activos 26

8.2 Clasificación de la información 30
8.3 Manejo de los medios 34
ii
9 Control de acceso 38
9.1 Requisitos de la empresa para el control de acceso 38

9.2 Gestión de acceso de usuario 41
9.3 Responsabilidades de los usuarios 49
9.4 Control de acceso al sistema y aplicación 51
10 Criptografía 57
10.1 Controles criptográficos 57
11 Seguridad física y del entorno 62
11.1 Áreas seguras 62

11.2 Equipos 68
12 Seguridad de las operaciones 78
12.1 Procedimientos y responsabilidades operativas 78

12.2 Protección contra software malicioso (malware) 84
12.3 Respaldo 86
12.4 Registros y monitoreo 88
12.5 Control del software operacional 92
12.6 Gestión de vulnerabilidad técnica 94
12.7 Consideraciones para la auditoría de los sistemas de información 98
13 Seguridad de las comunicaciones 99
13.1 Gestión de seguridad de la red 99

13.2 Transferencia de información 102
14 Adquisición, desarrollo y mantenimiento de sistemas 109
14.1 Requisitos de seguridad de los sistemas de información 109

14.2 Seguridad en los procesos de desarrollo y soporte 115
14.3 Datos de prueba 125
15 Relaciones con los proveedores 126
15.1 Seguridad de la información en las relaciones con los proveedores 126

15.2 Gestión de entrega de servicios del proveedor 133
16 Gestión de incidentes de seguridad de la información 136
16.1 Gestión de incidentes de seguridad de la información y mejoras 136
iii
17 Aspectos de seguridad de la información en la gestión de 144
continuidad del negocio
17.1 Continuidad de seguridad de la información 144

17.2 Redundancias 148
18 Cumplimiento 149
18.1 Cumplimiento con requisitos legales y contractuales 149

18.2 Revisiones de seguridad de la información 156
BIBLIOGRAFÍA 160
iv
PRÓLOGO
A. RESEÑA HISTÓRICA
A.1 El Instituto Nacional de Calidad - INACAL, a través de la Dirección de

Normalización es la autoridad competente que aprueba las Normas Técnicas Peruanas a
nivel nacional. Es miembro de la Organización Internacional de Normalización (ISO), en
representación del país.
A.2 La presente Norma Técnica Peruana ha sido elaborada por el Comité

Técnico de Normalización de Codificación e intercambio electrónico de datos, mediante
el Sistema 1 o de Adopción, durante los meses de agosto de 2015 a octubre de 2017,
utilizando como antecedente a la norma ISO/IEC 27002:2013 Information technology -
Security techniques - Code of practice for information security controls,
ISO/IEC 27002:2013/Cor.1:2014 and ISO/IEC 27002:2013/Cor.2:2015.
A.3 El Comité Técnico de Normalización de Codificación e intercambio

electrónico de datos presentó a la Dirección de Normalización -DN-, con fecha
2017-11-20, el PNTP-ISO/IEC 27002:2017, para su revisión y aprobación, siendo
sometido a la etapa de discusión pública el 2017-11-27. No habiéndose recibido
observaciones, fue oficializada como Norma Técnica Peruana
NTP-ISO/IEC 27002:2017 Tecnología de la información. Técnicas de seguridad.
Código de prácticas para controles de seguridad de la información, 1ª Edición, el 29
de diciembre de 2017.
A.4 La presente Norma Técnica Peruana presenta cambios editoriales referidos

principalmente a terminología empleada propia del idioma español y ha sido estructurada de
acuerdo a las Guías Peruanas GP 001:2016 y GP 002:2016.
B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN

DE LA NORMA TÉCNICA PERUANA
Secretaría GS1 Perú
Presidente Ricardo Dioses Villanueva
Secretaria Mary Wong Suehiro
v
ENTIDAD REPRESENTANTE
Contraloría General de la República Marco Bermúdez Torres

Joel Mercado Rojas
Deloitte & Touche S. R. L. Diana Lagos Flores
DMS Perú S. A. C. Adela Barcenas Freyre

Walter Eguizabal Guzmán
GS1 Perú Milagros Dávila del Rio

Sara Carrión Castilla
Marita Hernandez Isuiza
IBM del Perú S. A. C. Ivan Ancco Peña
Instituto Nacional de Defensa de la Martha Arce Neyra

Competencia y de la Protección de la
Propiedad Intelectual - INDECOPI
International Analytical Services S. A. C. Raúl Miranda Mercado

Karla Leon Morán
ITSTK Perú S. A. C. Belén Alvarado Chau
Microsoft Perú S. R. L. Fernando Gebara Filho
Ministerio de Economía y Finanzas - Jennifer Ayllón Bulnes

Oficina de Normalización Previsional
Superintendencia Nacional de Aduanas y Daniel Llanos Panduro

de Administración Tributaria - SUNAT
Consultor Carlos Horna Vallejos
vi
PRÓLOGO
(ISO)
ISO (la Organización Internacional para la Normalización) e IEC (la Comisión

Electrotécnica Internacional) forman el sistema especializado para la normalización
mundial. Los órganos nacionales que son miembros de ISO o de IEC participan en el
desarrollo de las Normas Internacionales a través de comités técnicos establecidos por la
respectiva organización para ocuparse de campos particulares de actividad técnica. Los
comités técnicos de ISO e IEC colaboran en campos de interés mutuo. Otras
organizaciones internacionales, públicas y privadas, en enlace con ISO y con IEC,
también participan en el trabajo. En el campo de la tecnología de la información, ISO e
IEC han establecido un comité técnico conjunto, ISO/IEC JTC 1.
Se redactan las Normas Internacionales en concordancia con las reglas proporcionadas en

las Directivas ISO/IEC, Parte 2.
La tarea principal del comité técnico conjunto es preparar los proyectos de normas
internacionales adoptadas por el comité técnico conjunto, se circulan a los órganos
nacionales para su votación. La publicación como una Norma Internacional requiere la
aprobación de al menos 75% de los órganos nacionales que emiten un voto.
Se señala la posibilidad de que alguno de los elementos de este documento pueda estar
sujeto a derechos de patentes. No se hará responsable a ISO e IEC de identificar
cualquiera o todos los mencionados derechos de patentes.
ISO/IEC 27001 fue preparada por el Comité Técnico conjunto ISO/IEC JTC 1,
Tecnología de la información, Sub-comité SC 27, Técnicas de seguridad de la TI.
Esta segunda edición cancela y reemplaza la primera edición (ISO/IEC 27001:2005), la

cual se ha revisado técnicamente.
vii
INTRODUCCIÓN
0.1 Antecedentes y contexto
Esta Norma está diseñado para que las organizaciones lo utilicen como referencia en la
selección de controles dentro del proceso de implementación de un Sistema de Gestión
de Seguridad de la Información (SGSI) basado en la Norma ISO/IEC 27001[10] o como
un documento guía para las organizaciones que implementen controles de seguridad de
la información comúnmente aceptados. Esta norma también puede utilizarse en el
desarrollo de lineamientos de gestión de seguridad de la información en industria y
organización específica, tomando en consideración su(s) entorno(s) de riesgo específicos
de seguridad de la información.
Las organizaciones de todos los tipos y tamaños (incluyendo al sector público y privado,
comercial y sin fines de lucro) recolectan, procesan, almacenan y transmiten información
de muchas formas, incluidas la electrónica, física y verbal (por ejemplo, conversaciones
y presentaciones).
El valor de la información va más allá de las palabras escritas, los números y las imágenes:
el conocimiento, los conceptos, las ideas y las marcas son ejemplos de formas intangibles
de información. En un mundo interconectado, la información y los procesos relacionados,
los sistemas, las redes y el personal que participan en su operación, manejo y la protección
son activos que, al igual que otros activos importantes, son valiosos para el negocio de
una organización y por lo tanto merecen o requieren protección contra diversos peligros.
Los activos son objeto de amenazas, tanto deliberadas como accidentales mientras que
los procesos relacionados, los sistemas, las redes y las personas tienen vulnerabilidades
inherentes. Los cambios en los procesos y sistemas de negocios u otros cambios externos
(tales como nuevas leyes y regulaciones) pueden crear nuevos riesgos de seguridad de la
información. Por lo tanto, dada la multiplicidad de maneras en las que las amenazas
podrían tomar ventaja de las vulnerabilidades para perjudicar a la organización, los
riesgos de seguridad de la información siempre se encuentran presentes. La efectiva
seguridad de la información reduce estos riesgos mediante la protección de la
organización frente a amenazas y vulnerabilidades y en consecuencia reduce los impactos
en sus activos.
La seguridad de la información se logra mediante la implementación de un conjunto

adecuado de controles, incluyendo políticas, procesos, procedimientos, estructuras
organizacionales y funciones de software y hardware. Estos controles deberían ser
establecidos, implementados, monitoreados, revisados y mejorados, donde sea necesario,
viii
para asegurar que los objetivos específicos de seguridad y de negocio de la organización
son cumplidos. Un Sistema de Gestión de Seguridad de la Información (SGSI) como el
que es especificado en la Norma ISO/IEC 27001[10] tiene una visión holística y
coordinada de los riesgos de seguridad de la información de la organización a fin de
implementar un conjunto completo de controles de seguridad de la información en el
marco global de un sistema de gestión coherente.
Muchos sistemas de información no han sido diseñados para ser seguros en el sentido de
la Norma ISO/IEC 27001[10] y esta Norma. La seguridad que se puede lograr a través de
medios técnicos es limitada y debería estar apoyada por una gestión y procedimientos
adecuados. Identificar qué controles deberían estar en su lugar requiere una planificación
cuidadosa y atención al detalle.
Un sistema de gestión de seguridad de la información (SGSI) exitoso requiere el apoyo

de todos los trabajadores de la organización. Puede requerir también la participación de
las partes interesadas, los proveedores u otras partes externas. La asesoría especializada
de terceros puede también ser necesaria.
En un sentido más general, una seguridad de la información efectiva asegura también a

la gerencia y otros interesados que los activos de la organización están razonablemente
seguros y protegidos contra daños, actuando así como un facilitador del negocio.
0.2 Requisitos de seguridad de la información
Es esencial que la organización identifique sus requisitos de seguridad. Hay tres fuentes
principales de requisitos de seguridad:
a) la evaluación del riesgo para la organización, tomando en cuenta su

estrategia global de negocios y sus objetivos. A través de una evaluación
del riesgo, son identificadas las amenazas a los activos, la vulnerabilidad
y probabilidad de ocurrencia son evaluadas y su impacto potencial es
estimado;
b) los requisitos legales, estatutarios, regulatorios y contractuales que una

organización, sus socios comerciales, contratistas y proveedores de
servicio, tienen que satisfacer y su entorno socio-cultural;
c) el conjunto de principios, objetivos y requisitos de negocio para el manejo,

procesamiento, almacenamiento, comunicación y archivo de información
que una organización ha desarrollado para apoyar sus operaciones.
ix
Los recursos empleados en la implementación de los controles necesitan estar
equilibrados con el daño comercial probable que resultaría de problemas de seguridad por
ausencia de estos controles. Los resultados de una evaluación del riesgo ayudarán a
orientar y a determinar las acciones y prioridades de gestión apropiadas para la gestión
de los riesgos de seguridad de la información y para la implementación de los controles
seleccionados para protegerse contra esos riesgos.
La Norma ISO/IEC 27005[11] proporciona orientación sobre la gestión del riesgo de

seguridad de la información, incluyendo el asesoramiento sobre la evaluación del riesgo,
el tratamiento del riesgo, la aceptación del riesgo, la comunicación del riesgo, el
monitoreo del riesgo y la revisión del riesgo.
0.3 Seleccionando controles
Los controles pueden ser elegidos de esta norma o de otro conjunto de controles o pueden
ser diseñados nuevos controles para cubrir adecuadamente necesidades específicas.
La selección de los controles depende de las decisiones organizacionales basadas en los

criterios para la aceptación del riesgo, las opciones para el tratamiento del riesgo y el
enfoque general a la gestión del riesgo aplicado a la organización y debería también estar
conforme a toda la legislación y regulaciones nacionales e internacionales relevantes. La
selección de controles depende también de la manera en que interactúan los controles para
proporcionar defensa en profundidad.
Algunos de los controles de esta norma pueden considerarse como principios guía para la
gestión de la seguridad de la información y aplicables para la mayoría de las
organizaciones. Los controles son explicados con más detalle en su guía de
implementación. Se puede encontrar más información sobre la selección de controles y
otras opciones de tratamiento de riesgos en la Norma ISO/IEC 27005[11].
0.4 Desarrollando lineamientos propios
Esta norma puede ser considerada como un punto de partida para desarrollar lineamientos
específicos de la organización. Pueden no ser aplicables todas los lineamientos y controles
de este código de práctica. Incluso, pueden requerirse controles y lineamientos
adicionales que esta Norma no incluye. Cuando sean desarrollados documentos que
contengan controles y lineamientos adicionales, puede ser útil incluir referencias
cruzadas con los capítulos de esta norma, donde sea aplicable, para facilitar la
verificación del cumplimiento por los auditores y socios del negocio.
x
0.5 Consideraciones del ciclo de vida
La información tiene un ciclo de vida natural, desde su creación y origen a través del
almacenamiento, procesamiento, utilización y transmisión hasta su eventual destrucción
o deterioro. El valor y los riesgos para los activos pueden variar durante su tiempo de vida
(por ejemplo, la divulgación no autorizada o el robo de unas cuentas financieras de la
empresa es mucho menos significativo después de que han sido publicadas oficialmente)
pero la seguridad de la información sigue siendo importante en alguna medida en todas
las etapas.
Los sistemas de información tienen ciclos de vida dentro de los que son concebidos,
especificados, diseñados, desarrollados, probados, implementados, utilizados,
mantenidos y eventualmente retirados del servicio y puestos a disposición. La seguridad
de la información debería ser tomada en cuenta en cada etapa. Los nuevos sistemas
desarrollados y cambios en los sistemas existentes presentan oportunidades para que las
organizaciones actualicen y mejoren los controles de seguridad, tomando en cuenta los
incidentes actuales y comunes y los riesgos proyectados de seguridad de la información.
0.6 Normas relacionadas
Mientras que esta norma ofrece orientación sobre un amplio rango de controles de
seguridad de la información que son comúnmente aplicados en muchas organizaciones
diferentes, las partes restantes de la familia ISO/IEC 27000 proporcionan
recomendaciones complementarias o requisitos sobre otros aspectos del proceso global
de gestión de seguridad de la información.
Consulte la Norma ISO/IEC 27000 para una introducción general a los sistemas de
gestión de seguridad de la información (SGSI) y a la familia de normas. La Norma
ISO/IEC 27000 proporciona un glosario que define formalmente la mayor parte de los
términos utilizados en la familia de normas ISO/IEC 27000 y describe el alcance y los
objetivos para cada norma de la familia.
---oooOooo---
xi
PERUANA 1 de 162
Tecnología de la información. Técnicas de seguridad. Código

de práctica para los controles de seguridad de la información
1 Objeto y campo de aplicación
Esta Norma Técnica Peruana proporciona lineamientos para la seguridad de la información

en las organizaciones y prácticas de gestión para la seguridad de la información, incluyendo
la selección, la implementación y la gestión de controles tomando en consideración los
riesgos del entorno para la seguridad de la información de la organización.
Esta Norma Técnica Peruana está diseñada para ser utilizada por las organizaciones que
pretendan:
a) seleccionar los controles dentro del proceso de implementación del Sistema

de Gestión de Seguridad de la Información basado en la Norma
ISO/IEC 27001;
b) implementar los controles de seguridad de la información comúnmente

aceptados;
c) desarrollar sus propios lineamientos de gestión de seguridad de la

información.
2 Referencias normativas
Los siguientes documentos, en su totalidad o en parte, son normativamente referenciados en

esta norma y son indispensables para su aplicación. Para las referencias con fecha, solo se
aplica la edición citada. Para las referencias sin fecha, se aplica la última edición (incluyendo
cualquier modificación).
ISO/IEC 27000 Tecnología de la información. Técnicas de

seguridad. Sistemas de gestión de la
seguridad de la información. Visión general
y vocabulario
PERUANA 2 de 162
3 Términos y definiciones
Para los propósitos de esta Norma Técnica Peruana , se aplican los términos y definiciones
de la Norma ISO/IEC 27000.
4 Estructura de esta norma
Esta Norma Técnica Peruana contiene 14 capítulos de control de seguridad que en su

conjunto contienen un total de 35 categorías principales de seguridad y 114 controles.
4.1 Capítulos
Cada capítulo define controles de seguridad conteniendo una o más categorías principales
de seguridad.
El orden de los capítulos en esta Norma Técnica Peruana no implica su importancia.

Dependiendo de las circunstancias, los controles de seguridad de cualquiera o de todos los
capítulos podrían ser importantes, por lo tanto cada organización que aplica esta Norma
Técnica Peruana debería identificar los controles aplicables, qué tan importantes son y su
aplicación a los procesos individuales del negocio. Además, las listas en esta Norma Técnica
Peruana no están en orden de prioridad.
4.2 Categorías de control
Cada categoría principal de control de seguridad contiene:
a) un objetivo de control que establece que se quiere conseguir; y
b) uno o más controles que pueden ser aplicados para alcanzar el objetivo de
control.
Las descripciones del control se estructuran de la siguiente manera:

PERUANA 3 de 162
Control
Define la declaración específica del control, para alcanzar el objetivo de control.
Guía de implementación
Proporciona información más detallada para apoyar la implementación del control y el

cumplimiento del objetivo de control. La guía puede no ser del todo adecuada o suficiente
en todas las situaciones y puede no cumplir con los requisitos específicos de control de la
organización.
Información adicional
Proporciona información adicional que puede ser necesaria considerar, por ejemplo,
consideraciones legales y referencias a otras normas. Si no hay información adicional para
ser proporcionada, esta parte no se muestra.
5 Políticas de seguridad de la información
5.1 Lineamientos de gestión para la seguridad de la información
Objetivo: proporcionar orientación y apoyo a la gestión para la seguridad de la información

en concordancia con los requisitos del negocio y, las leyes y regulaciones relevantes.
5.1.1 Políticas para la seguridad de la información
Control
Un conjunto de políticas para la seguridad de la información debería ser definido, aprobado

por la gerencia, publicado y comunicado a los empleados y a las partes externas relevantes.

PERUANA 4 de 162
Al más alto nivel, las organizaciones deberían definir una “política de seguridad de la
información”, que sea aprobada por la dirección y que establezca el enfoque de la
organización para gestionar sus objetivos de seguridad de la información.
Las políticas de seguridad de la información deberían considerar los requisitos creados por:
a) la estrategia del negocio;
b) las regulaciones, las leyes y los contratos;
c) el entorno de amenazas para la seguridad de la información, actuales y

previstas.
La política de seguridad de la información debería contener declaraciones respecto a:
a) la definición de la seguridad de la información, sus objetivos y principios para

orientar todas las actividades relacionadas con la seguridad de la información;
b) la asignación de responsabilidades generales y específicas para la gestión de

seguridad de la información para los roles definidos;
c) los procesos para el manejo de desviaciones y excepciones.
En un nivel inferior, la política de seguridad de la información debería estar apoyada por las
políticas sobre temas específicos, las cuales exigen aún más la implementación de los
controles de seguridad de la información y se estructuran normalmente para guiar las
necesidades de determinados grupos dentro de una organización o para cubrir ciertos temas.
Algunos ejemplos de estos temas detallados en políticas son:
a) control de acceso (véase el capítulo 9);
b) clasificación (y manejo) de la información (véase 8.2);

PERUANA 5 de 162
c) seguridad física y del entorno (véase el capítulo 11);
d) temas orientados al usuario final, tales como:
i) uso aceptable de activos (véase 8.1.3);

ii) escritorio y pantalla limpios (véase 11.2.9);
iii) transferencia de información (véase 13.2.1);
iv) dispositivos móviles y teletrabajo (véase 6.2);
v) restricciones a las instalaciones y uso del software (véase 12.6.2);
e) respaldo (backup) (véase r 12.3);
f) transferencia de información (véase 13.2);
g) protección contra software malicioso (malware) (véase 12.2);
h) gestión de vulnerabilidades técnicas (véase 12.6.1);
i) controles criptográficos (véase el capítulo 10);
j) seguridad de las comunicaciones (véase el capítulo 13);
k) privacidad y protección de datos personales (véase 18.1.4);
l) relaciones con los proveedores (véase el capítulo 15).
Estas políticas deberían comunicarse a los empleados y a las partes externas relevantes de
forma que sea pertinente, accesible y comprensible para el lector previsto, por ejemplo, en
el contexto de una “creación de conciencia de seguridad de la información, educación y
programa de capacitación” (véase 7.2.2).
La necesidad de políticas internas de seguridad de la información varía en las organizaciones.

Las políticas internas son especialmente útiles en las organizaciones más grandes y más
complejas, donde, los que definen y aprueban los niveles de control esperados se encuentran
separados de los que implementan los controles o en situaciones en que una política aplica a
muchas personas o funciones dentro de la organización. Las políticas de seguridad de la
información se pueden incluir en un solo documento “política de seguridad de la
información” o como un conjunto de documentos individuales pero relacionados.

PERUANA 6 de 162
Si alguna de las políticas de seguridad de la información es distribuida fuera de la

organización, se debería tener cuidado de no revelar información confidencial.
Algunas organizaciones utilizan otros términos para estos documentos de políticas, tales
como “Normas”, “Directivas” o “Reglas”.
5.1.2 Revisión de las políticas para la seguridad de la información
Control
Las políticas para la seguridad de la información deberían ser revisadas a intervalos

planificados o si ocurren cambios significativos para asegurar su conveniencia, adecuación
y efectividad continua.
Cada política debería tener un propietario con responsabilidad de gestión aprobada para el
desarrollo, la revisión y la evaluación de las políticas. La revisión debería incluir la
evaluación de las oportunidades de mejora de las políticas de la organización y el enfoque a
la gestión de seguridad de la información en respuesta a cambios en el entorno de la
organización, a las circunstancias del negocio, a las condiciones legales o al entorno técnico.
La revisión de las políticas de seguridad de la información debería tener en cuenta los

resultados de las revisiones de la alta dirección.
La política revisada debería tener la aprobación de la gerencia.

PERUANA 7 de 162
6 Organización de la seguridad de la información
6.1 Organización interna
Objetivo: establecer un marco de referencia de la gestión para iniciar y controlar la

implementación y operación de la seguridad de la información dentro de la organización.
6.1.1 Roles y responsabilidades para la seguridad de la información
Control
Todas las responsabilidades de seguridad de la información deberían definirse y asignarse.
La asignación de las responsabilidades de seguridad de la información debería hacerse de

acuerdo con las políticas de seguridad de la información (véase 5.1.1). Deberían identificarse
las responsabilidades para la protección de los activos individuales y para la realización de
procesos específicos de seguridad de la información. Deberían definirse las
responsabilidades de las actividades de gestión de riesgos de seguridad de la información y
en particular, para la aceptación de riesgos residuales. Estas responsabilidades deberían
complementarse, cuando sea necesario, con una guía más detallada para sitios específicos y
para las instalaciones de procesamiento de información. Deberían definirse las
responsabilidades locales para la protección de activos y para llevar a cabo los procesos
específicos de seguridad.
Las personas con responsabilidades asignadas de seguridad de la información pueden

delegar tareas de seguridad a otras. Sin embargo, siguen siendo responsables y deberían
determinar si las tareas delegadas han sido correctamente realizadas.
Las áreas en donde las personas son responsables deberían establecerse. En particular,
debería ocurrir lo siguiente:

PERUANA 8 de 162
a) los activos y los procesos de seguridad de la información deberían

identificarse y definirse;
b) una entidad responsable de cada activo o proceso de seguridad de la

información debería ser asignada y los detalles de esta responsabilidad
deberían estar documentados (véase 8.1.2);
c) los niveles de autorización deberían definirse y documentarse;
d) para ser capaces de cumplir con las responsabilidades en el área de seguridad

de la información, las personas designadas deberían ser competentes en el
área y se les debería brindar oportunidades de estar actualizados
continuamente;
e) la coordinación y supervisión de los aspectos de seguridad de la información

de las relaciones con los proveedores debería identificarse y documentarse.
Muchas organizaciones designan un administrador de seguridad de la información para

asumir las responsabilidades globales del desarrollo y la implementación de la seguridad de
la información y para apoyar la identificación de los controles.
Sin embargo, la responsabilidad de proporcionar los recursos y la implementación de los

controles generalmente recae sobre administradores individuales. Una práctica común es
designar un propietario para cada activo, que luego se convierte en responsable de su
protección en el día a día.
6.1.2 Segregación de funciones
Control
Las funciones y áreas de responsabilidad en conflicto deberían estar segregadas para reducir
oportunidades de modificación no autorizada o no intencional o mal uso de los activos de la
organización.

PERUANA 9 de 162
Se debería tener cuidado en que ninguna persona pueda acceder, modificar o utilizar activos
sin autorización o sin detección. El inicio de un evento debería separarse de su autorización.
La posibilidad de colusión debería considerarse en el diseño de los controles.
Las organizaciones pequeñas pueden encontrar la segregación de funciones como algo difícil
de lograr, pero el principio debería ser aplicado en la medida de lo posible y practicable.
Siempre que sea difícil la segregación, deberían considerarse otros controles tales como el
monitoreo de las actividades, los registros de auditoría y la supervisión de la dirección.
La segregación de funciones es un método para reducir el riesgo del mal uso, sea accidental
o deliberado, de los activos de la organización.
6.1.3 Contacto con autoridades
Control
Contactos apropiados con autoridades relevantes deberían ser mantenidos.
Las organizaciones deberían tener procedimientos vigentes que especifiquen cuándo y con
qué autoridades (por ejemplo, las fuerzas policiales, organismos reguladores y autoridades
de supervisión) deberían contactarse y cómo identificar los incidentes de seguridad de la
información que deberían reportarse en el momento oportuno (por ejemplo, si se sospecha
que se está incumpliendo la ley).

PERUANA 10 de 162
Las organizaciones atacadas desde Internet pueden necesitar que las autoridades tomen
acciones contra el origen del ataque.
El mantenimiento de dichos contactos puede ser un requerimiento para apoyar la gestión de

incidentes de seguridad de la información (véase capítulo 16) o el proceso de continuidad
del negocio o el plan de contingencia (véase capítulo 17). Los contactos con instituciones
reguladoras son también útiles para anticiparse y prepararse para cambios próximos de la ley
o regulaciones, los cuales tienen que ser implementados por las organizaciones. Los
contactos con otras autoridades incluyen servicios públicos, servicios de emergencia,
proveedores de electricidad, salud y seguridad, por ejemplo departamento de bomberos (en
relación con la continuidad del negocio), los proveedores de telecomunicaciones (en relación
con el ruteo de líneas y su disponibilidad) y los proveedores de agua (en relación con las
instalaciones de refrigeración para el equipamiento).
6.1.4 Contacto con grupos especiales de interés
Control
Contactos apropiados con grupos especiales de interés u otros foros de especialistas en

seguridad y asociaciones profesionales deberían ser mantenidos.
La membresía en foros o grupos de interés especial debería considerarse como un medio

para:
a) incrementar el conocimiento sobre las mejores prácticas y mantenerse

actualizado sobre seguridad de la información relevante;
b) asegurar que la comprensión del entorno de seguridad de la información es

actual y completa;

PERUANA 11 de 162
c) recibir advertencias oportunas de alertas, avisos y parches referidos a ataques

y vulnerabilidades;
d) obtener acceso a asesoría especializada sobre seguridad de la información;
e) compartir e intercambiar información sobre nuevas tecnologías, productos,

amenazas o vulnerabilidades;
f) proveer puntos de coordinación adecuados para el manejo de incidentes de

seguridad de la información (véase el capítulo 16).
Pueden establecerse acuerdos para compartir la información a manera de mejorar la

cooperación y la coordinación de temas de seguridad. Tales acuerdos deberían identificar los
requisitos para la protección de información confidencial.
6.1.5 Seguridad de la información en la gestión de proyectos
Control
La seguridad de la información debería ser tratada en la gestión de proyectos, sin importar

el tipo de proyecto.
La seguridad de la información debería integrarse en el método de gestión de proyectos de

la organización para garantizar que los riesgos de seguridad de la información sean
identificados y tratados como parte de un proyecto. Esto se aplica en general a cualquier
proyecto, independientemente de su carácter, por ejemplo, un proyecto para un proceso clave
de negocios, TI, gestión de instalaciones y otros procesos de apoyo. Los métodos de gestión
de proyectos en uso deberían exigir que:
a) los objetivos de seguridad de la información sean incluidos en los objetivos

del proyecto;

PERUANA 12 de 162
b) una evaluación de riesgos de seguridad de la información se lleve a cabo en

una etapa temprana del proyecto para identificar los controles necesarios;
c) la seguridad de la información es parte de todas las fases de la metodología

del proyecto aplicada.
Las implicaciones de seguridad de la información deberían tratarse y revisarse regularmente

en todos los proyectos. Las responsabilidades de seguridad de la información deberían
definirse y asignarse a roles específicos definidos en los métodos de gestión de proyectos.
6.2 Dispositivos móviles y teletrabajo
Objetivo: asegurar la seguridad del teletrabajo y el uso de los dispositivos móviles.
6.2.1 Política de dispositivos móviles
Control
Una política y medidas de seguridad de soporte deberían ser adoptadas para manejar los
riesgos introducidos por el uso de dispositivos móviles.
Al utilizar dispositivos móviles, debería tenerse especial cuidado para asegurar que la
información del negocio no se vea comprometida. La política de dispositivos móviles
debería tener en cuenta los riesgos de trabajar con dispositivos móviles en entornos
desprotegidos.
La política de dispositivos móviles debería considerar:
a) el registro de los dispositivos móviles;
b) los requisitos de protección física;

PERUANA 13 de 162
c) la restricción de instalación de software;
d) los requisitos de las versiones de software de los dispositivos móviles y para

la aplicación de parches;
e) la restricción de la conexión a los servicios de información;
f) los controles de acceso,
g) las técnicas criptográficas;
h) la protección contra software malicioso;
i) la desactivación, la eliminación o el bloqueo a distancia;
j) las copias de seguridad;
k) el uso de servicios y aplicaciones web.
Debería tenerse cuidado al utilizar dispositivos móviles en lugares públicos, salas de

reuniones y otras áreas no protegidas. Para evitar el acceso no autorizado o la divulgación
de la información almacenada y procesada por estos dispositivos debería implantarse la
protección, por ejemplo, utilizando técnicas criptográficas (véase el capítulo10) y forzando
el uso de información secreta para la autentificación (véase 9.2.4).
Los dispositivos móviles deberían protegerse también físicamente contra el robo,

especialmente cuando se dejan, por ejemplo, en autos y otras formas de transporte,
habitaciones de hotel, centros de congresos y lugares de reunión. Debería establecerse un
procedimiento teniendo en cuenta los requisitos legales, del seguro y otros requisitos de
seguridad de la organización para los casos de robo o pérdida de dispositivos móviles. Los
dispositivos que llevan información importante, sensible o crítica de la empresa no deberían
dejarse desatendidos y, cuando sea posible, deberían ser físicamente bloqueados o deberían
utilizarse bloqueos especiales para asegurar los dispositivos.
Debería proporcionarse capacitación al personal que utiliza dispositivos móviles para

concientizarlos sobre los riesgos adicionales derivados de esta forma de trabajo y los
controles que deberían implementarse.

PERUANA 14 de 162
Cuando la política de dispositivos móviles permite el uso de dispositivos móviles de

propiedad privada, la política y las medidas de seguridad relacionadas deberían considerar
también:
a) la separación del uso privado y de negocios de los dispositivos, incluido el

uso de software para apoyar dicha separación y proteger los datos de negocios
en un dispositivo privado;
b) proponer acceso a la información de negocio, solo después de que los

usuarios han firmado un acuerdo de usuario final, reconociendo sus
obligaciones (protección física, actualización de software, entre otros),
renunciando a la propiedad de los datos de negocio, lo que permite la
eliminación remota de los datos por parte de la organización en caso de robo
o pérdida del dispositivo o cuando ya no se encuentran autorizados a utilizar
el servicio. Esta política debería tener en cuenta la legislación sobre
privacidad.
Las conexiones inalámbricas de los dispositivos móviles son similares a otros tipos de
conexión de red, pero tienen diferencias importantes que deberían tenerse en cuenta al
identificar los controles.
Las diferencias típicas son:
a) algunos protocolos de seguridad inalámbrica son inmaduros y tienen

debilidades conocidas;
b) la información almacenada en los dispositivos móviles puede que no sea

respaldada debido a la banda ancha limitada o a que los dispositivos móviles
no se encuentren conectados en los momentos en que se programan los
respaldos.
Generalmente, los dispositivos móviles comparten funciones comunes, por ejemplo, redes,
acceso a Internet, correo electrónico y manejo de archivos, con los dispositivos de uso fijo.
Los controles de seguridad de la información consisten generalmente, en los adoptados por
los dispositivos de uso fijo y en los que abordan las amenazas planteadas por su uso fuera de
los locales de la organización.
PERUANA 15 de 162
6.2.2 Teletrabajo
Control
Una política y medidas de seguridad de soporte deberían estar implementadas para proteger
información a la que se accede, se procesa o almacena en los sitios de teletrabajo.
Las organizaciones que permiten las actividades de teletrabajo deberían elaborar y publicar
una política que defina las condiciones y las restricciones para el uso del teletrabajo. Cuando
se considere aplicable y sea permitido por la ley, deberían considerarse los siguientes
aspectos:
a) la seguridad física existente en el sitio de teletrabajo, considerando la

seguridad física del edificio y del entorno local;
b) el entorno físico de teletrabajo propuesto;
c) los requisitos de seguridad de las comunicaciones, teniendo en cuenta la

necesidad de acceso remoto a los sistemas internos de la organización, la
sensibilidad de la información a ser accedida y pasada sobre el enlace de
comunicación y la sensibilidad del sistema interno;
d) la provisión de acceso al escritorio virtual que impide el procesamiento y el

almacenamiento de información sobre el equipo de propiedad privada;
e) la amenaza de acceso no autorizado a la información o a los recursos por parte

de otras personas que utilizan el ambiente, por ejemplo, acceso por familiares
y amigos;
f) el uso de redes domésticas y requisitos o restricciones de la configuración de

los servicios de red inalámbricos;
g) las políticas y los procedimientos para evitar conflictos relativos a los

derechos de propiedad intelectual desarrollados en los equipos de propiedad
privada;

PERUANA 16 de 162
h) el acceso a los equipos de propiedad privada (para verificar la seguridad del

equipo o durante la investigación), que puede estar impedido por la
legislación;
i) los acuerdos de licencia de software son tales que las organizaciones pueden
ser responsables de la concesión de licencias de software cliente en estaciones
de trabajo de propiedad privada de los empleados o de usuarios de terceras
partes;
j) la protección ante software malicioso y los requisitos de firewall.
Los lineamientos y las disposiciones a considerar deberían incluir:
a) el suministro de equipo adecuado y mobiliario de almacenamiento para las

actividades de teletrabajo, donde no se permite el uso de equipo de propiedad
privada, que no se encuentra bajo control de la organización;
b) una definición del trabajo permitido, las horas de trabajo, la clasificación de

la información que se puede realizar y los sistemas y servicios internos a los
que el teletrabajador se encuentra autorizado a acceder;
c) el suministro de equipo adecuado de comunicación, incluyendo los métodos

para asegurar el acceso remoto;
d) la seguridad física;
e) las reglas y lineamientos del acceso de la familia y visitas al equipo y la

información;
f) el suministro de soporte y mantenimiento de hardware y software;

g) la provisión de seguros;
h) los procedimientos para el respaldo y la continuidad del negocio;
i) la auditoría y el monitoreo de la seguridad;
j) la revocación de la autorización y de los derechos de acceso y la devolución

de los equipos cuando las actividades de teletrabajo finalizan.

PERUANA 17 de 162
El teletrabajo se refiere a todas las formas de trabajo fuera de la oficina, incluyendo los
ambientes de trabajo no tradicionales, tales como los ambientes denominados “trabajo a
distancia”, “trabajo flexible”, “trabajo remoto” y “trabajo virtual”.
7 Seguridad de los recursos humanos
7.1 Antes del empleo
Objetivo: asegurar que los empleados y contratistas entienden sus responsabilidades y son
convenientes para los roles para los que se les considera.
7.1.1 Selección
Control
Las verificaciones de los antecedentes de todos los candidatos a ser empleados deberían ser
llevadas a cabo en concordancia con las leyes, regulaciones y ética relevantes y debería ser
proporcional a los requisitos del negocio, la clasificación de la información a la que se tendrá
acceso y los riesgos percibidos.
La verificación debería tener en cuenta toda la legislación relevante sobre privacidad,

protección de datos personales y relativos al empleo, adicionalmente, donde sea permitido,
debería incluir lo siguiente:
a) disponibilidad de referencias satisfactorias, por ejemplo, una de negocio y

una personal;

PERUANA 18 de 162
b) una comprobación (de integridad y exactitud) del currículum vitae del

postulante;
c) confirmación de las calificaciones académicas y profesionales declaradas;
d) comprobación independiente de identidad (pasaporte o documento similar);
e) comprobaciones más detalladas, tales como verificación de crédito o

antecedentes criminales.
Cuando una persona es contratada para un rol específico en seguridad de la información, las
organizaciones deberían asegurarse que el candidato:
a) tenga las competencias necesarias para desempeñar el rol de seguridad;
b) pueda ser confiado para asumir el rol, especialmente si el rol es fundamental

para la organización.
Cuando una tarea, tanto en un nombramiento inicial o en un ascenso, involucre que la

persona tenga acceso a instalaciones de procesamiento de información, y, en particular, si
éstas están manejando información sensible, por ejemplo, información financiera o
altamente confidencial, la organización debería también considerar comprobaciones
adicionales más detalladas.
Los procedimientos deberían definir criterios y limitaciones para comprobaciones de

verificación, por ejemplo, quién es elegible para seleccionar personal y cómo, cuándo y por
qué se han de realizar las comprobaciones de verificación.
Debería también realizarse un proceso de selección para contratistas. En estos casos, el

acuerdo entre la organización y el contratista debería especificar las responsabilidades para
realizar la selección y los procedimientos de notificación que necesitan seguir si la selección
no ha sido completada o si los resultados ocasionan duda o preocupación.
Debería recopilarse la información de todos los candidatos a ser considerados para

posiciones dentro de la organización y debería manejarse de acuerdo con la legislación
apropiada existente en la jurisdicción relevante. Dependiendo de la legislación aplicable, los
candidatos deberían informarse con antelación sobre las actividades de selección.

PERUANA 19 de 162
7.1.2 Términos y condiciones del empleo
Control
Los acuerdos contractuales con los empleados y contratistas deberían estipular

responsabilidades de éstos y de la organización respecto de la seguridad de la información.
Las obligaciones contractuales de los empleados o contratistas deberían reflejar las políticas
de seguridad de la información de la organización, además de aclarar y enunciar:
a) que todos los empleados y contratistas a los cuales se les da acceso a

información sensible deberían firmar un acuerdo de confidencialidad o de no-
divulgación previamente a ser otorgado el acceso a las instalaciones de
procesamiento de información (véase 13.2.4);
b) las responsabilidades y derechos legales de los empleados y contratistas,

como por ejemplo, relativas a derecho de copia o legislación de protección de
datos (véase 18.1.2 y 18.1.4);
c) las responsabilidades para la clasificación de información y la gestión de la

información de la organización y otros activos asociados con la información,
las instalaciones de procesamiento de información y los servicios de
información manejados por el empleado o contratista (véase el capítulo 8);
d) responsabilidades del empleado o contratista por el manejo de información

de otras organizaciones o partes externas;
e) acciones a ser tomadas si el empleado o contratista desatiende los requisitos

de seguridad de la organización (véase 7.2.3);
Los roles y responsabilidades de seguridad de la información deberían comunicarse a los

candidatos durante el proceso de pre-empleo.

PERUANA 20 de 162
La organización debería asegurar que los empleados y contratistas acuerden en los términos
y condiciones concernientes a la seguridad de la información apropiada a la naturaleza y
extensión de acceso que ellos tendrán a los activos de la organización asociados con los
sistemas y servicios de información.
Cuando sea apropiado, las responsabilidades contenidas dentro de los términos y

condiciones de empleo deberían continuar por un período definido luego de la finalización
del empleo (véase 7.3).
Se puede usar un código de conducta para cubrir las responsabilidades de seguridad de la

información de los empleados o contratistas referentes a confidencialidad, protección de
datos, normas éticas, uso apropiado de los equipos e instalaciones de la organización, además
de prácticas honestas esperadas por la organización. La parte externa, con la que se asocia al
contratista, puede requerir acuerdos contractuales en nombre del individuo contratado.
7.2 Durante el empleo
Objetivo: asegurar que los empleados y contratistas sean conscientes y cumplan con sus
responsabilidades de seguridad de la información.
7.2.1 Responsabilidades de la gerencia
Control
La gerencia debería requerir a todos los empleados y contratistas aplicar la seguridad de la

información de acuerdo con las políticas y procedimientos establecidos por la organización.
Las responsabilidades de la gerencia deberían incluir asegurar que los empleados y

contratistas:

PERUANA 21 de 162
a) estén apropiadamente instruidos sobre sus roles y responsabilidades de

seguridad antes de que se les otorgue acceso a información confidencial o a
sistemas de información;
b) se les proporcione orientaciones para hacer constar las expectativas sobre la

seguridad de su rol dentro de la organización;
c) estén motivados a cumplir con las políticas de seguridad de la organización;
d) logren un nivel de conciencia sobre seguridad relevante a sus roles y

responsabilidades dentro de la organización (véase 7.2.2);
e) tengan conformidad con los términos y condiciones del empleo, lo cual

incluye la política de seguridad de la información de la organización y
métodos apropiados de trabajo;
f) continúen teniendo aptitudes y calificaciones apropiadas y sean capacitados

de manera regular;
g) estén provistos con un canal de denuncias anónimas para reportar violaciones

de políticas o procedimientos de seguridad de la información (“denuncia de
irregularidades”).
La gerencia debería demostrar el apoyo a las políticas, los procedimientos y controles de

seguridad de la información y actuar como un modelo a seguir.
Si los empleados y contratistas no son concientizados de sus responsabilidades de seguridad,

pueden causar un daño considerable a la organización. El personal motivado es probable que
sea más confiable y ocasione menos incidentes de seguridad de la información.
Una gestión pobre puede causar que el personal se sienta subvaluado resultando en un
impacto negativo en la seguridad de la información para la organización. Por ejemplo, una
gestión pobre puede conducir a negligencias en la seguridad o mal uso potencial de los
activos de la organización.

PERUANA 22 de 162
7.2.2 Conciencia, educación y capacitación sobre la seguridad de la información
Control
Todos los empleados de la organización y, cuando fuera relevante, los contratistas deberían
recibir educación y capacitación sobre la conciencia de la seguridad de la información, así
como actualizaciones regulares sobre políticas y procedimientos de la organización, según
sea relevante para la función del trabajo que cumplen.
Un programa de creación de conciencia en seguridad de la información debería tener como

objetivo que los empleados y cuando sea relevante, los contratistas sean conscientes de sus
responsabilidades en seguridad de la información y los medios para que esas
responsabilidades sean ejercidas.
Debería establecerse un programa de creación de conciencia en seguridad de la información

de acuerdo con las políticas de seguridad de la información de la organización y los
procedimientos pertinentes, teniendo en cuenta la información de la organización a ser
protegida y los controles que han sido implementados para proteger la información. El
programa de concientización debería incluir una serie de actividades para la creación de
conciencia, como las campañas (por ejemplo, día de seguridad de la información) y los
folletos o boletines informativos.
Debería planificarse el programa de creación de conciencia teniendo en cuenta los roles de

los empleados en la organización, y, cuando sea relevante, las expectativas de creación de
conciencia para los contratistas por parte de la organización. Las actividades en el programa
de creación de conciencia deberían calendarizarse en el tiempo, de preferencia con
regularidad, por lo que las actividades son repetitivas y cubren a los nuevos empleados y
contratistas. El programa de creación de conciencia también debería actualizarse con
regularidad de acuerdo con las políticas y los procedimientos organizacionales y debería
considerar las lecciones aprendidas de los incidentes de seguridad de la información.
Las actividades para lograr la creación de conciencia deberían realizarse según lo requiera
el programa de creación de conciencia en seguridad de la información. Se puede utilizar
diferentes medios en las actividades para lograr la creación de conciencia, incluyendo

PERUANA 23 de 162
presencial, educación a distancia, basado en la web, auto-aprendizaje a su propio ritmo y

otros.
La educación y la capacitación en seguridad de la información debería abarcar también

aspectos generales, tales como:
a) declaración del compromiso de la dirección con la seguridad de la

información en toda la organización;
b) la necesidad de conocer y cumplir con las reglas y obligaciones aplicables de

seguridad de la información, según se define en las políticas, normas, leyes,
reglamentos, contratos y acuerdos;
c) la responsabilidad personal por las propias acciones y omisiones y las

responsabilidades generales hacia la obtención o protección de la información
que pertenece a la organización y a las partes externas;
d) los procedimientos básicos de seguridad de la información (tales como el

reporte de incidentes de seguridad de la información) y los controles básicos
(tales como la contraseña de seguridad, los controles ante software malicioso
y los escritorios limpios);
e) los puntos de contacto y los recursos para obtener información adicional y

recomendaciones sobre cuestiones de seguridad de la información,
incluyendo información adicional para la educación y materiales de
capacitación en seguridad de la información.
La educación y capacitación en seguridad de la información deberían brindarse

periódicamente. La educación y capacitación inicial se aplica a quienes son transferidos a
nuevas posiciones o funciones con requisitos sustancialmente diferentes en seguridad de la
información, no solo a los nuevos empleados y debería brindarse antes del inicio de
funciones.
La organización debería desarrollar un programa de educación y formación para llevarlo a

cabo de manera eficaz. El programa debería estar alineado con las políticas de seguridad de
la información de la organización y los procedimientos relevantes, tomando en
consideración la información de la organización a ser protegida y los controles que han sido
implementados para proteger dicha información. El programa debería considerar las
diferentes formas de educación y entrenamiento, por ejemplo, lecturas o auto-estudio.

PERUANA 24 de 162
Al redactar un programa de concientización, es importante no solo centrarse en el “qué” y

“cómo”, sino también en el “por qué”. Es importante que los empleados entiendan el objetivo
de la seguridad de la información y el impacto potencial, positivo y negativo, sobre la
organización de su propio comportamiento.
La creación de conciencia, la educación y entrenamiento pueden ser parte o llevarse a cabo

en colaboración con otras actividades de entrenamiento, por ejemplo, TI en general o
capacitación genérica en seguridad. Las actividades de creación de conciencia, educación y
entrenamiento deberían ser adecuadas y relevantes a los roles, responsabilidades y
habilidades individuales.
Debería llevarse a cabo una evaluación de la comprensión de los empleados al finalizar un

curso de creación de conciencia, educación y capacitación para poner a prueba la
transferencia de conocimientos.
7.2.3 Proceso disciplinario
Control
Debería haber un proceso disciplinario formal y comunicado para tomar acción contra
empleados que hayan cometido una infracción a la seguridad de la información.
El proceso disciplinario no debería comenzar sin una verificación previa de que la violación
a la seguridad de la información ha ocurrido (véase 16.1.7).
El proceso disciplinario formal debería asegurar un tratamiento correcto y justo para los
empleados de quienes se sospecha que han infringido la seguridad de la información. El
proceso disciplinario formal debería proveer una respuesta gradual que tome en
consideración factores tales como la naturaleza y gravedad de la infracción y su impacto en
el negocio, si es la primera ofensa o una repetición, si el infractor fue apropiadamente
entrenado, legislación relevante, contratos del negocio y otros factores que se requieran.
PERUANA 25 de 162
El proceso disciplinario también debería usarse como disuasión para prevenir que los
empleados infrinjan las políticas y procedimientos de seguridad de la información de la
organización y cualquier otra infracción de seguridad de la información. Las infracciones
deliberadas pueden requerir acciones inmediatas.
El proceso disciplinario también puede convertirse en una motivación o incentivo si las

sanciones positivas son definidas por el comportamiento destacable en lo que respecta a la
seguridad de la información.
7.3 Terminación y cambio de empleo
Objetivo: proteger los intereses de la organización como parte del proceso de cambio o
terminación de empleo.
7.3.1 Terminación o cambio de responsabilidades del empleo
Control
Las responsabilidades y deberes de seguridad de la información que siguen siendo válidos

luego de la terminación o cambio de empleo deberían estar definidos, comunicados al
empleado o contratista y forzar su cumplimiento.
La comunicación de las responsabilidades en la desvinculación debería incluir los requisitos

de seguridad de la información y las responsabilidades legales en curso y, cuando sea
apropiado, las responsabilidades contenidas dentro de cualquier acuerdo de confidencialidad
(véase 13.2.4) y los términos y condiciones de empleo (véase 7.1.2) deberían continuar por
un período de tiempo definido luego de la desvinculación del empleado o contratista.

PERUANA 26 de 162
El contrato del empleado o contratista debería contener las responsabilidades y deberes que
permanecen válidos aún luego de la desvinculación (véase 7.1.2).
Deberían gestionarse los cambios en las responsabilidades o en la relación laboral y la

desvinculación de la nueva responsabilidad o relación laboral, combinada con el inicio de la
nueva responsabilidad o empleo.
La función de recursos humanos generalmente es responsable por el proceso completo de

desvinculación laboral y trabaja junto con el supervisor de la persona que egresa para
gestionar los aspectos de seguridad de la información de los procedimientos relevantes. En
el caso de un contratista, proporcionado por una tercera parte, este proceso de
responsabilidad en la terminación puede ser llevado a cabo por una tercera parte en
conformidad con el contrato entre la organización y la tercera parte.
Puede ser necesario informar a los empleados, clientes o contratistas de los cambios en los
acuerdos operativos y de personal.
8 Gestión de activos
8.1 Responsabilidad por los activos
Objetivo: Identificar los activos de la organización y definir las responsabilidades de

protección apropiadas.
8.1.1 Inventario de activos
Control
El control de la información, otros activos asociados con la información y las instalaciones

de procesamiento de información deberían ser identificadas y un inventario de estos activos
debería ser elaborado y mantenido.
PERUANA 27 de 162
Una organización debería identificar los activos relevantes en el ciclo de vida de la

información y documentar su importancia. El ciclo de vida de la información debería incluir
la creación, elaboración, almacenamiento, transmisión, eliminación y destrucción. La
documentación debería mantenerse en inventarios dedicados o existentes, según
corresponda.
El inventario de activos debería ser exacto, actualizado, consistente y alineado con otros
inventarios.
Para cada uno de los activos identificados, debería asignarse un propietario (véase 8.1.2) y
debería identificarse la clasificación (véase 8.2).
Los inventarios de activos ayudan a garantizar que se logra la protección eficaz, pero también
pueden ser requeridos para otros propósitos, como por ejemplo por razones de salud y
seguridad, financieras o de seguros (gestión de activos).
La Norma ISO/IEC 27005[11] proporciona ejemplos de activos que la organización puede

necesitar considerar en la identificación de los activos. El proceso de compilación de un
inventario de los activos es un prerrequisito importante de la gestión de riesgos (véase
también la Norma ISO/IEC 27000 e ISO/IEC 27005[11]).
8.1.2 Propiedad de los activos
Control
Los activos mantenidos en el inventario deberían tener un propietario.

PERUANA 28 de 162
Las personas, así como otras entidades que hayan aprobado la responsabilidad de gestión del
ciclo de vida de los activos, califican para ser asignadas como propietarios de activos.
Generalmente, se implementa un proceso para garantizar la asignación oportuna de la

propiedad de los activos. La propiedad debería asignarse cuando los activos son creados o
cuando son transferidos a la organización. El propietario de los activos debería ser
responsable de la correcta gestión de un activo durante todo el ciclo de vida de los activos.
El propietario del activo debería:
a) asegurar que los activos son inventariados;
b) asegurar que los activos son clasificados y protegidos adecuadamente;
c) definir y revisar periódicamente las restricciones de acceso y las

clasificaciones de activos importantes, teniendo en cuenta las políticas
aplicables de control de acceso;
d) garantizar el manejo adecuado cuando el activo es eliminado o destruido.
El propietario identificado puede ser un individuo o una entidad que ha aprobado la

responsabilidad de la dirección para el control de todo el ciclo de vida de un activo. El
propietario identificado no necesariamente tiene ningún derecho de propiedad sobre el
activo.
Las tareas rutinarias pueden ser delegadas, por ejemplo, a un custodio que vigile el activo
diariamente, pero la responsabilidad continúa siendo del propietario.
En sistemas de información complejos, puede resultar útil designar un grupo de activos, los
cuales actúan en forma conjunta para proveer un servicio particular. En este caso, el
propietario del servicio es responsable por la entrega del mismo, incluido el funcionamiento
de sus activos.
PERUANA 29 de 162
8.1.3 Uso aceptable de los activos
Control
Las reglas para el uso aceptable de la información y activos asociados con la información y
con las instalaciones de procesamiento de la información deberían estar identificadas,
documentadas e implementadas.
Los empleados y los usuarios externos que utilizan o tienen acceso a los activos de la
organización deberían concientizarse sobre los requisitos de la seguridad de la información
de la organización, de otros activos asociados a la información y de los recursos e
instalaciones de procesamiento de la información.
8.1.4 Retorno de activos
Control
Todos los empleados y usuarios de terceras partes deberían retornar todos los activos de la
organización en su posesión a la conclusión de su empleo, contrato o acuerdo.
Debería estar formalizado un proceso de desvinculación que incluya la devolución de todo

activo físico y electrónico que sea propiedad de la organización o estén bajo su custodia.
En los casos en que un empleado o usuario de tercera parte adquiere equipos de la

organización o utiliza su propio equipo, deberían seguirse procedimientos para garantizar
que toda la información pertinente sea transferida a la organización y borrada de forma
segura del equipo (véase 11.2.7).

PERUANA 30 de 162
En los casos en que un empleado o usuario de tercera parte tenga conocimiento de asuntos
importantes para las operaciones en curso, la información debería documentarse y
transferirse a la organización.
Durante el período de notificación de desvinculación de empleados y contratistas y la

materialización efectiva de la misma, la organización debería controlar la copia no
autorizada de la información pertinente (por ejemplo, propiedad intelectual).
8.2 Clasificación de la información
Objetivo: asegurar que la información recibe el nivel apropiado de protección en

concordancia con su importancia para la organización.
8.2.1 Clasificación de la información
Control
La información debería ser clasificada en términos de los requisitos legales, valor, criticidad
y sensibilidad respecto a una divulgación o modificación no autorizada.
La clasificación y los controles de protección asociados a la información deberían tener en

cuenta las necesidades del negocio para compartir o restringir la información, así como los
requisitos legales. Los activos que no son de información se pueden clasificar de
conformidad con la clasificación de información que es almacenada, procesada o
manipulada o protegida por el activo.
Los propietarios de los activos de información son responsables de su clasificación.
El esquema de clasificación debería incluir las convenciones para la clasificación y los

criterios para la revisión de la clasificación en el tiempo. El nivel de protección en el esquema
debería evaluarse mediante el análisis de la confidencialidad, integridad y disponibilidad y

PERUANA 31 de 162
cualquier otro requisito para la información considerada. El esquema debería estar alineado
con la política de control de acceso (véase 9.1.1).
Cada nivel debería tener un nombre que tenga sentido en el contexto de la aplicación del
esquema de clasificación.
El esquema debería ser consistente en toda la organización para que todos clasifiquen la
información y los activos relacionados de la misma manera, tengan un entendimiento común
de los requisitos de protección y apliquen la protección adecuada.
La clasificación debería incluirse en los procesos de la organización y debería ser consistente

y coherente en toda la organización. Los resultados de la clasificación deberían indicar el
valor de los activos en función de su sensibilidad y criticidad para la organización, por
ejemplo, en términos de confidencialidad, integridad y disponibilidad. Los resultados de la
clasificación deberían actualizarse de acuerdo con los cambios de su valor, sensibilidad y
criticidad durante su ciclo de vida.
La clasificación les ofrece a las personas que tratan con información, una indicación concisa
de cómo manejarla y protegerla. La creación de grupos de información con necesidades de
protección similares y la especificación de los procedimientos de seguridad de la
información que se aplican a toda la información en cada grupo, facilitan esto. Este enfoque
reduce la necesidad de una evaluación de riesgos caso por caso y el diseño personalizado de
los controles.
La información suele dejar de tener importancia o criticidad tras cierto tiempo, por ejemplo,
cuando se ha hecho pública. Estos aspectos deberían considerarse, puesto que una sobre-
clasificación conllevaría a la implementación de controles innecesarios que resultan en
gastos adicionales o, por el contrario, en una baja clasificación, que puede poner en peligro
el logro de los objetivos del negocio.
Un ejemplo de un esquema de clasificación de confidencialidad de la información se podría

basar en cuatro niveles, de la siguiente manera:

PERUANA 32 de 162
a) la divulgación no causa ningún daño;
b) la divulgación causa menor incomodidad o inconveniencia operativa menor;
c) la divulgación tiene un impacto significativo a corto plazo en las operaciones

o los objetivos tácticos;
d) la divulgación tiene un grave impacto en los objetivos estratégicos a largo

plazo o pone en riesgo la supervivencia de la organización.
8.2.2 Etiquetado de la información
Control
Un conjunto apropiado de procedimientos para el etiquetado de la información debería estar

desarrollado e implementado en concordancia con el esquema de clasificación de la
información adoptado por la organización.
Los procedimientos para el etiquetado de la información necesitan cubrir la información y

sus activos relacionados en formato físico y electrónico. El etiquetado debería reflejar el
esquema de clasificación establecido en 8.2.1. Las etiquetas deberían reconocerse
fácilmente. Los procedimientos deberían proporcionar orientación sobre dónde y cómo se
adjuntan las etiquetas, considerando cómo se accede a la información o se gestionan los
activos, en función de los tipos de medios. Los procedimientos pueden definir casos en los
que se omite el etiquetado, por ejemplo, el etiquetado de información no confidencial para
reducir las cargas de trabajo. Los empleados y los contratistas deberían estar al tanto de los
procedimientos del etiquetado.
La salida de los sistemas que contienen información clasificada como sensible o crítica
debería llevar una etiqueta adecuada de clasificación.
El etiquetado de la información clasificada es un requisito clave para acuerdos que impliquen

PERUANA 33 de 162
compartir información. Las etiquetas físicas y los metadatos suelen ser las formas más
comunes de etiquetado.
El etiquetado de la información y sus activos relacionados, a veces, pueden tener efectos

negativos. Los activos clasificados son más fáciles de identificar y por lo tanto, objeto de
robo por parte de los atacantes internos o externos.
8.2.3 Manejo de activos
Control
Los procedimientos para el manejo de activos deberían ser desarrollados e implementados

en concordancia con el esquema de clasificación de la información adoptado por la
organización.
Deberían elaborarse procedimientos para el manejo, procesamiento, almacenamiento y

comunicación de la información, de acuerdo con su clasificación (véase 8.2.1).
Deberían considerarse los siguientes elementos:
a) las restricciones de acceso que soportan los requisitos de protección para cada
nivel de clasificación;
b) el mantenimiento de un registro formal de los destinatarios autorizados de los

activos;
c) la protección de las copias temporales o permanentes de información a un

nivel consistente con la protección de la información original;
d) el almacenamiento de los activos de TI de acuerdo con las especificaciones

del fabricante;
e) borrar el marcado de todas las copias de los medios para la atención del
destinario autorizado.
PERUANA 34 de 162
El esquema de clasificación utilizado en la organización puede no ser equivalente a los

sistemas utilizados por otras organizaciones, incluso si los nombres de los niveles son
similares; además, la información que se mueve entre organizaciones puede variar en la
clasificación dependiendo de su contexto en cada organización, incluso si los esquemas de
clasificación son idénticos.
Los acuerdos con otras organizaciones que incluyen el intercambio de información deberían
incluir procedimientos para identificar la clasificación de la información y para interpretar
las etiquetas de clasificación de otras organizaciones.
8.3 Manejo de los medios
Objetivo: prevenir la divulgación no autorizada, modificación, eliminación o destrucción de

la información almacenada en medios.
8.3.1 Gestión de medios removibles
Control
Se debería implementar procedimientos para la gestión de medios removibles de acuerdo

con el esquema de clasificación adoptado por la organización.
Deberían considerarse los siguientes lineamientos para la gestión de medios extraíbles:
a) si ya no son necesarios, los contenidos de los medios reutilizables que

deberían retirarse de la organización, deberían hacerse irrecuperables;
b) cuando sea necesario y práctico, debería requerirse autorización para retirar

los medios de la organización y debería mantenerse un registro de dichos
retiros , a fin de mantener un registro de auditoría;
c) todos los medios deberían almacenarse en un ambiente seguro, de acuerdo

con las especificaciones del fabricante;
PERUANA 35 de 162
d) si la confidencialidad o la integridad de los datos son consideraciones

importantes, deberían utilizarse técnicas criptográficas para proteger los datos
en los medios extraíbles;
e) para mitigar el riesgo de degradación de los medios mientras se necesiten los

datos almacenados, los datos deberían transferirse a medios nuevos antes de
convertirse en ilegibles;
f) deberían almacenarse varias copias de los datos valiosos en un medio

independiente para reducir aún más el riesgo del daño o pérdida de los datos
coincidentes;
g) debería considerarse el registro de los medios extraíbles para limitar la

posibilidad de pérdida de datos;
h) las unidades de medios extraíbles solo deberían habilitarse si hay una razón
comercial para hacerlo;
i) cuando existe la necesidad de utilizar los medios extraíbles, la transferencia

de información a tales medios debería controlarse.
Deberían documentarse los procedimientos y los niveles de autorización.
8.3.2 Eliminación de medios
Control
Los medios deberían eliminarse de manera segura cuando ya no se requieran, utilizando

procedimientos formales.
Deberían establecerse procedimientos formales para la eliminación segura de los medios

para minimizar el riesgo de fuga de información confidencial a personas no autorizadas.
Los procedimientos para la eliminación segura de los medios que contienen información
confidencial deberían ser proporcionales a la sensibilidad de esa información.
PERUANA 36 de 162
Deberían considerarse los siguientes elementos:
a) los medios que contienen información confidencial deberían almacenarse y

eliminarse de forma segura, por ejemplo, mediante incineración o trituración
o el borrado de datos para su uso por otra aplicación dentro de la organización;
b) establecer procedimientos para identificar los elementos que puedan requerir

la eliminación segura;
c) puede ser más fácil organizar que todos los elementos de los medios sean
recopilados y eliminados de forma segura, en lugar de tratar de separar los
elementos sensibles;
d) muchas organizaciones ofrecen servicios de recopilación y eliminación de los

medios; se debería tener cuidado en la selección de una tercera parte adecuada
con los controles y experiencia adecuados;
e) la eliminación de los elementos sensibles debería registrarse a fin de mantener

un registro de auditoría.
Cuando se acumulan medios para la eliminación, debería tenerse en cuenta el efecto de

agregación, que puede causar que una gran cantidad de información no sensible se convierta
en sensible.
Los dispositivos dañados que contienen datos sensibles pueden requerir una evaluación de
riesgos para determinar si los elementos deberían ser destruidos físicamente en lugar de ser
enviados para su reparación o descarte (véase 11.2.7).
8.3.3 Transferencia de medios físicos
Control
Los medios que contienen información deberían ser protegidos contra el acceso no
autorizado, el mal uso o la corrupción durante el transporte.

PERUANA 37 de 162
Deberían considerarse los siguientes lineamientos para proteger a los medios que contienen
información que es transportada:
a) deberían utilizarse transportes o mensajeros confiables;
b) debería acordarse con la dirección una lista de mensajeros autorizados;
c) deberían desarrollarse procedimientos para verificar la identificación de los

mensajeros;
d) el embalaje debería ser suficiente como para proteger el contenido de

cualquier daño físico que pueda producirse durante el tránsito y de acuerdo
con las especificaciones del fabricante, por ejemplo, la protección contra los
factores ambientales que puede reducir la eficacia de restauración de los
medios, tales como la exposición al calor, la humedad o los campos
electromagnéticos;
e) deberían mantenerse registros para identificar el contenido de los medios, la

protección aplicada así como el registro de los tiempos de transferencia a los
guardias y la recepción en el destino.
La información puede ser vulnerable al acceso no autorizado, mal uso o corrupción durante
el transporte físico, por ejemplo, al enviar los medios a través del servicio postal o por
mensajería.
En este control, los medios incluyen los documentos en papel.
Cuando la información confidencial en los medios no se encuentra cifrada, debería

considerarse la protección física adicional de los medios.

PERUANA 38 de 162
9 Control de acceso
9.1 Requisitos de la empresa para el control de acceso
Objetivo: limitar el acceso a la información y a las instalaciones de procesamiento de la

información.
9.1.1 Política de control de acceso
Control
Una política de control de acceso debería estar establecida, documentada y revisada basada
en requisitos del negocio y de seguridad de la información.
Los propietarios de activos deberían determinar las reglas de control de acceso apropiadas,
los derechos de acceso y restricciones para las funciones específicas de los usuarios con
respecto a sus activos, con el nivel de detalle y el rigor de los controles que reflejan los
riesgos de seguridad de información asociados.
Los controles de acceso son lógicos y físicos (véase el capítulo 11) y estos deberían ser
considerados en conjunto. Los usuarios y los proveedores de servicios deberían tener una
declaración clara de los requisitos del negocio que deberían cumplir los controles de acceso.
La política debería tener en cuenta lo siguiente:
a) los requisitos de seguridad de las aplicaciones de negocio;
b) políticas para la difusión y autorización de la información, por ejemplo, la

necesidad de conocer los principios y niveles seguridad de la información y
clasificación de la información (véase 8.2);

PERUANA 39 de 162
c) la coherencia entre los derechos de acceso y políticas de clasificación de la

información de los sistemas y redes;
d) la legislación relevante y obligaciones contractuales respecto a la limitación

de acceso a datos o servicios (véase 18.1);
e) la gestión de los derechos de acceso en un ambiente distribuido y en red que

reconoce todos los tipos de conexiones disponibles;
f) la segregación de roles de control de acceso, por ejemplo petición de acceso,

la autorización de acceso, administración de acceso;
g) los requisitos para la autorización formal de las solicitudes de acceso (véase

9.2.1 y 9.2.2);
h) los requisitos para la revisión periódica de los derechos de acceso (véase

9.2.5);
i) la eliminación de los derechos de acceso (véase 9.2.6);
j) el archivo de los expedientes de todos los eventos importantes concernientes

al uso y la gestión de identidades de los usuarios y la información de
autentificación secreta;
k) los roles con acceso privilegiado (véase 9.2.3).
Se debería tener cuidado cuando se especifica las reglas de control de acceso, para ello
considerar:
a) el establecimiento de reglas basadas en la premisa "Todo está generalmente

prohibido a menos que sea expresamente permitido" y no la regla más débil
"Todo está generalmente permitido a menos que sea expresamente
prohibido";
b) cambios en las etiquetas de información (véase 8.2.2) que son iniciadas

automáticamente por las instalaciones de procesamiento de la información y
aquellas iniciadas a discreción de un usuario;

PERUANA 40 de 162
c) los cambios en los permisos del usuario que son iniciados automáticamente
por el sistema de información y aquellos iniciados por un administrador;
d) las normas que requieren la aprobación específica antes de la promulgación y

las que no lo hacen.
Las reglas de control de acceso deberían estar soportadas por procedimientos formales
(véase 9.2, 9.3 y 9.4) y responsabilidades definidas (véase 6.1.1 y 9.3).
El control de acceso basado en roles es un enfoque utilizado con éxito por muchas
organizaciones para vincular los derechos de acceso con las funciones de negocio.
Dos de los principios frecuentes que dirigen la política de control de acceso son:
a) necesidad de conocer: sólo se le concede acceso a la información que necesita

para llevar a cabo sus tareas (diferentes tareas / roles significan diferente
necesidad a conocer y por lo tanto diferente perfil de acceso);
b) necesidad de usar: sólo se le concede acceso a las instalaciones de

procesamiento de información (equipos informáticos, aplicaciones,
procedimientos, ambientes) que necesita para llevar a cabo su tarea / trabajo
/ rol.
9.1.2 Acceso a redes y servicios de red.
Control
Los usuarios deberían tener acceso solamente a la red y a servicios de red que hayan sido
específicamente autorizados a usar.
Una política debería ser formulada en relación con el uso de redes y servicios de red. Esta
política debería cubrir:

PERUANA 41 de 162
a) las redes y los servicios de red que están permitidos a ser accedidos;
b) los procedimientos de autorización para determinar quién está permitido

acceder a que redes y a que servicios en red;
c) los controles de gestión y procedimientos para proteger el acceso a las

conexiones de red y servicios de red;
d) los medios utilizados para acceder a las redes y servicios de red (por ejemplo,
uso de VPN o red inalámbrica);
e) requisitos de autentificación del usuario para acceder a varios servicios de

red;
f) la supervisión del uso de los servicios de red.
La política sobre el uso de los servicios de red debería ser coherente con la política de control
de acceso de la organización (véase 9.1.1).
Conexiones no autorizadas e inseguras a servicios de red pueden afectar a toda la

organización. Este control es particularmente importante para las conexiones de red a las
aplicaciones de negocio sensibles o críticos o para los usuarios en lugares de alto riesgo, por
ejemplo, zonas comunes o externos que están fuera del control y gestión de seguridad de la
información de la organización.
9.2. Gestión de acceso de usuario
Objetivo: asegurar el acceso de usuarios autorizados y prevenir el acceso no autorizado a los

sistemas y servicios.

PERUANA 42 de 162
9.2.1 Registro y baja de usuarios
Control
Un proceso formal de registro y baja de usuarios debería estar implementado para permitir
la asignación de derechos de acceso.
El proceso de gestión de los ID de usuario debería incluir:
a) utilizar la identificación única de usuario (ID´s) para que los usuarios puedan
estar vinculados y sean responsable de sus acciones; el uso de identificaciones
compartidas debería sólo ser permitido cuando sean necesarios por razones
de negocios o de funcionamiento y debería estar aprobados y documentados;
b) deshabilitar o quitar inmediatamente los ID de usuario a los usuarios que han

dejado la organización (véase 9.2.6);
c) periódicamente identificar y eliminar o desactivar los ID de usuario

redundantes;
d) asegurarse de que los ID de usuario redundantes no se otorguen a otros

usuarios.
Proporcionar o revocar el acceso a la información o a las instalaciones de procesamiento de

información, usualmente es un procedimiento de dos pasos:
a) la asignación y habilitación o revocación, de un ID de usuario;
b) el proporcionar o revocar derechos de acceso a dicho ID de usuario (véase

9.2.2).

PERUANA 43 de 162
9.2.2 Aprovisionamiento de acceso a usuario
Control
Un proceso formal de aprovisionamiento de acceso a usuarios debería ser implementado

para asignar o revocar los derechos de acceso para todos los tipos de usuarios a todos los
sistemas y servicios.
El proceso de aprovisionamiento para asignar o revocar los derechos de acceso concedido a

ID de usuario debería incluir:
a) obtener la autorización del propietario del sistema o servicio de información

para el uso del sistema o servicio de información (véase el control 8.1.2); la
aprobación separada para los derechos de acceso de administración también
puede ser apropiado;
b) verificar que el nivel de acceso concedido sea apropiado a las políticas de

acceso (véase 9.1) y es consistente con otros requisitos, tales como la
segregación de funciones (véase 6.1.2);
c) asegurar que los derechos de acceso no estén activados (por ejemplo, por los
proveedores de servicios) antes de que los procedimientos de autorización
sean completados;
d) el mantenimiento de un registro central de los derechos de acceso concedidos

a un ID de usuario para acceder a los sistemas y servicios de información;
e) la adaptación de los derechos de acceso de los usuarios que han cambiado

roles o trabajo y la inmediata eliminación o bloqueo de los derechos de acceso
de los usuarios que dejaron la organización;
f) el revisar periódicamente los derechos de acceso con los propietarios de los

sistemas o servicios de información (véase 9.2.5).

PERUANA 44 de 162
Se debería considerar la posibilidad de establecer los roles de acceso de usuario basado en

los requisitos del negocio que resumen un número de derechos de acceso en perfiles típicos
de acceso de usuario. Las solicitudes de acceso y las revisiones (véase 9.2.4) son más fácil
gestionadas a nivel de esos roles que a nivel de los derechos particulares.
Se debería considerar la posibilidad de incluir cláusulas en los contratos de personal y

contratos de servicio que especifican sanciones si el acceso no autorizado se intenta por
personal o contratistas (véase 7.1.2, 7.2.3, 13.2.4 y 15.1.2).
9.2.3 Gestión de derechos de acceso privilegiados
Control
La asignación y uso de derechos de acceso privilegiado debería estar restringida y

controlada.
La asignación de derechos de acceso privilegiado debería ser controlada a través de un

proceso formal de autorización, de conformidad con la política de control de acceso
correspondiente (véase el control 9.1.1). Los siguientes pasos deberían ser considerados:
a) los derechos de acceso privilegiados asociados con cada sistema o proceso,

por ejemplo, sistema operativo, sistema de gestión de base de datos y cada
aplicación y los usuarios a quienes necesitan ser asignados, deberían ser
identificados;
b) los derechos de acceso privilegiados deberían ser asignados a los usuarios en

base a la necesidad de uso y sobre una base de caso por caso en línea con la
política de control de acceso (véase 9.1.1), es decir, basado en el requisito
mínimo para sus roles funcionales;

PERUANA 45 de 162
c) un proceso y registro de autorización de todos los privilegios asignados

debería ser mantenido. Los derechos de acceso privilegiados no deberían
concederse hasta que el proceso de autorización se haya completado;
d) los requisitos para expiración de los derechos de acceso privilegiados

deberían estar definidos;
e) los derechos de acceso privilegiados deberían estar asignados a un ID de

usuario diferente de las usadas para las actividades de trabajo regulares.
Actividades de trabajo regulares no deberían ser desempeñadas desde un ID
privilegiado;
f) las competencias de los usuarios con derechos de acceso privilegiados

deberían ser revisadas periódicamente a fin de verificar si están alineadas con
sus funciones;
g) los procedimientos específicos deberían establecerse y mantenerse para evitar

el uso no autorizado de ID de usuario de administración genéricos, de acuerdo
a las capacidades de configuración de los sistemas;
h) para los ID de usuario de administración genéricos, la confidencialidad de la

información de autentificación secreta debería mantenerse cuando es
compartida (por ejemplo, cambiar las contraseñas con frecuencia y tan pronto
como sea posible cuando un usuario privilegiado deja o cambia de trabajo,
comunicando entre ellos a los usuarios privilegiados con mecanismos
adecuados).
El uso inadecuado de los privilegios de administración del sistema (cualquier característica

o instalación de un sistema de información que habilite al usuario anular sistemas o controles
de aplicaciones) es un importante factor de contribución a las fallas o infracciones a los
sistemas.

PERUANA 46 de 162
9.2.4 Gestión de información de autentificación secreta de usuarios
Control
La asignación de información de autentificación secreta debería ser controlada a través de

un proceso de gestión formal.
El proceso debería incluir los siguientes requisitos:
a) los usuarios deberían ser requeridos a firmar una declaración personal para
mantener confidencial la información de autentificación secreta y para
mantener el grupo (es decir, compartida) de información de autentificación
secreta únicamente con los miembros del grupo; esta declaración firmada se
puede incluir en los términos y condiciones de empleo (véase 7.1.2);
b) cuando los usuarios están requeridos a mantener su propia información de

autentificación secreta se les debería proporcionar inicialmente con seguridad
temporal la información de autentificación secreta, que se ven obligados a
cambiar a partir del primer uso;
c) se debería establecer procedimientos para verificar la identidad de un usuario

antes de proporcionar información de autentificación secreta nueva, de
reemplazo o temporal;
d) la información de autentificación secreta temporal se debería dar a los

usuarios de manera segura; el uso de partes externas o mensajes de correo
electrónico sin protección (texto claro) debería evitarse;
e) la información de autentificación secreta temporal debería ser única para un

individuo y no debería ser adivinable;
f) los usuarios deberían reconocer la recepción de la información de

autentificación secreta;
g) la información de autentificación secreta predeterminada del proveedor

debería cambiarse después de la instalación de sistemas o software.

PERUANA 47 de 162
Las contraseñas son un tipo de información de autentificación secreta comúnmente utilizadas

y son un medio común para verificar la identidad de un usuario. Otros tipos de información
de autentificación secreta son claves criptográficas y otros datos almacenados en dispositivos
tokens (por ejemplo, tarjetas inteligentes) que produzcan códigos de autentificación.
9.2.5 Revisión de derechos de acceso de usuarios
Control
Los propietarios de los activos deberían revisar los derechos de acceso de usuario a intervalos
regulares.
La revisión de los derechos de acceso deberían considerar lo siguiente:
a) los derechos de acceso de los usuarios deberían ser revisados en intervalos

regulares y después de cualquier cambio, tal como la promoción, la
degradación o la terminación del empleo (véase el capítulo 7);
b) los derechos de acceso de usuario deberían ser revisados y reasignados al

pasar de un rol a otro dentro de la misma organización;
c) las autorizaciones de los derechos de acceso privilegiados deberían revisarse

a intervalos más frecuentes;
d) las asignaciones de privilegios deberían ser chequeados en intervalos

regulares para asegurar que no se han obtenido privilegios no autorizados;
e) cambios en las cuentas privilegiadas deberían ser registrados para su revisión

periódica.

PERUANA 48 de 162
Este control compensa las posibles debilidades en la ejecución de los controles 9.2.1, 9.2.2
y 9.2.6.
9.2.6 Retiro o ajuste de derechos de acceso
Control
Los derechos de acceso a información e instalaciones de procesamientos de información de

todos los empleados y de los usuarios de partes externas deberían retirarse al término de su
empleo, contrato o acuerdo, o ajustarse según el cambio.
Tras la desvinculación, los derechos de acceso de un individuo a la información y los activos

asociados a las instalaciones y servicios de procesamiento de información deberían ser
retirados o suspendidos. Esto determinará si es necesario eliminar los derechos de acceso.
Los cambios de empleo deberían reflejarse en la eliminación de todos los derechos de acceso
que no fueron aprobados para el nuevo empleo. Los derechos de acceso que deberían ser
eliminados o ajustados incluyen los de acceso físico y lógico. La eliminación o el ajuste se
pueden hacer mediante la eliminación, la revocación o reemplazo de las claves, tarjetas de
identificación, instalaciones de procesamiento de información o suscripciones. Cualquier
documentación que identifique los derechos de acceso de los empleados y contratistas
debería reflejar la eliminación y el ajuste de los derechos de acceso. Si un empleado o usuario
de parte externa que se marcha conoce contraseñas de ID de usuario que permanecen activas,
éstas se deberían cambiar a la terminación o cambio de empleo, contrato o acuerdo.
Derechos de acceso para la información y los activos asociados a las instalaciones de

procesamiento de información deberían ser reducidos o eliminados antes del término o
cambio de empleo, dependiendo de la evaluación de factores de riesgo tales como:
a) si la desvinculación o el cambio se inicia por el empleado, el usuario de parte

externa o por la administración y, la razón de la terminación;

PERUANA 49 de 162
b) las responsabilidades actuales del empleado, usuario de parte externo o

cualquier otro usuario;
c) el valor de los activos actualmente accesibles.
En determinadas circunstancias, los derechos de acceso pueden ser asignados sobre la base
de estar disponible a más gente que el empleado o usuario de tercera parte que sale, por
ejemplo, ID de grupo. En tales circunstancias, las personas que salen deberían ser retiradas
de las listas de acceso de grupo y se debería hacer una recomendación a todos los demás
empleados y usuarios de partes externas involucrados a no compartir esta información con
las personas que salen.
En los casos de terminación iniciada por la gerencia, los empleados descontentos o usuarios
de parte externa, pueden deliberadamente corromper información o sabotear las
instalaciones de procesamiento de información. En los casos de personas que renuncian o
son despedidos, ellos pueden tener la tentación de recoger información para su uso futuro.
9.3 Responsabilidades de los usuarios
Objetivo: hacer que los usuarios respondan por la salvaguarda de su información de

autentificación.
9.3.1 Uso de información de autentificación secreta
Control
Los usuarios deberían ser exigidos a que sigan las prácticas de la organización en el uso de
información de autentificación secreta.

PERUANA 50 de 162
Todos los usuarios deberían estar advertidos de:
a) mantener la confidencialidad de la información secreta de autentificación,

asegurando que no es divulgada a otras partes, incluidas las personas de
autoridad;
b) evitar se mantenga registros (por ejemplo, en papel, archivo de software o

dispositivo de mano) de información secreta de autentificación, a menos que
pueda ser almacenada de forma segura y el método de almacenamiento haya
sido aprobado (por ejemplo repositorio de contraseñas);
c) cambiar la información secreta de autentificación siempre que exista

cualquier indicio de que esté comprometida;
d) cuando las contraseñas son usadas como información secreta de

autentificación, seleccione contraseñas de calidad con longitud mínima
suficiente que sean:
1) fácil de recordar;
2) no basada en cualquier cosa que alguien más podría adivinar fácilmente u

obtener utilizando información personal relacionada, por ejemplo, nombres,
números de teléfono y fecha de nacimiento, entre otros.
3) no vulnerable a ataques de diccionario (es decir, no consistan en palabras

incluidas en los diccionarios);
4) libre de caracteres idénticos consecutivos, totalmente numérica o totalmente

alfabética;
5) si es temporal, cambiado en el primer inicio de sesión;
e) no compartir información secreta de autentificación de usuario individual;
f) garantizar una apropiada protección de las contraseñas cuando las contraseñas

se utilizan como información secreta de autentificación en procedimientos de
inicio de sesión automatizado y son almacenados;

PERUANA 51 de 162
g) no utilizar la misma información secreta de autentificación para propósitos

comerciales y no comerciales.
Otra información
La disposición de la “Autentificación única” (Single Sign On - SSO) u otras herramientas

de gestión de información secreta de autentificación, reduce la cantidad de información
secreta de autentificación que los usuarios están requeridos a proteger y por lo tanto puede
aumentar la eficacia de este control. Sin embargo, estas herramientas también pueden
aumentar el impacto de la divulgación de información secreta de autentificación.
9.4. Control de acceso al sistema y aplicación
Objetivo: prevenir el acceso no autorizado a los sistemas y aplicaciones.
9.4.1 Restricción de acceso a la información
Control
El acceso a la información y a las funciones del sistema de aplicación debería ser restringido
en concordancia con la política de control de acceso.
Restricciones de acceso deberían basarse en los requisitos individuales de aplicaciones de

negocio y de acuerdo con la política de control de acceso definida.
Debería considerarse lo siguiente para dar soporte a los requisitos de restricción de acceso:
a) proporcionar menús para controlar el acceso a las funciones del sistema de

aplicación;

PERUANA 52 de 162
b) controlar los datos que pueden ser accedidos por un usuario en particular;
c) controlar los derechos de acceso de los usuarios, por ejemplo, leer, escribir,
borrar y ejecutar;
d) controlar los derechos de acceso de otras aplicaciones;
e) limitar la información contenida en las salidas;
f) proporcionar controles de acceso físicos o lógicos para el aislamiento de

aplicaciones sensibles, datos de aplicación o sistemas.
9.4.2 Procedimientos de ingreso seguro
Control
Donde la política de control de acceso lo requiera, el acceso a los sistemas y a las

aplicaciones debería ser controlado por un procedimiento de ingreso seguro.
Una técnica de autentificación adecuada debería ser elegida para justificar la identidad
reclamada de un usuario.
Donde se requiera una fuerte autentificación y verificación de identidad, deberían utilizar

métodos de autentificación alternativa a las contraseñas, tales como medios de cifrado,
tarjetas inteligentes, tokens o medios biométricos.
El procedimiento para iniciar una sesión en un sistema o aplicación debería estar diseñado
para minimizar la oportunidad de un acceso no autorizado. Por tanto, el procedimiento de
conexión debería revelar el mínimo de información sobre el sistema o aplicación, con el fin
de evitar proporcionar a un usuario no autorizado alguna asistencia innecesaria. Un buen
procedimiento de ingreso debería:

PERUANA 53 de 162
a) no mostrar identificadores de sistemas o aplicaciones hasta que el proceso de

entrada haya sido completado exitosamente;
b) mostrar un aviso general de advertencia de que el computador debería ser

accedido sólo por usuarios autorizados;
c) no proveer mensajes de ayuda durante el procedimiento de ingreso que

ayudaría a un usuario no autorizado;
d) validar la información de inicio de sesión sólo al completar todos los datos de

entrada. Si se surge una condición de error, el sistema no debería indicar qué
parte de los datos son correctos o incorrectos;
e) proteger contra intentos de ingreso por fuerza bruta;
f) registrar los intentos fallidos y exitosos;
g) plantear un evento de seguridad si un posible intento o una violación exitosa

de ingreso es detectado por los controles;
h) mostrar la siguiente información al completar un ingreso con éxito:
1) fecha y hora del anterior ingreso con éxito;
2) detalles de cualquier intento de ingreso sin éxito desde el último ingreso con
éxito;
i) no mostrar una contraseña que está siendo introducida;
j) no transmitir las contraseñas en texto claro (sin cifrar) a través de una red;
k) terminar sesiones inactivas después de un período definido de inactividad,

especialmente en ubicaciones de alto riesgo, tales como áreas públicas o
externos fuera de la gestión de la seguridad de la organización o en los
dispositivos móviles;
l) restringir los tiempos de conexión para proveer seguridad adicional para

aplicaciones de alto riesgo y reducir las ventanas de oportunidad para el
acceso no autorizado.

PERUANA 54 de 162
Las contraseñas son una forma común de proveer identificación y autentificación basada en
un secreto que sólo el usuario conoce. Lo mismo también se puede lograr con medios
criptográficos y protocolos de autentificación. La fortaleza de la autentificación de usuario
debería ser apropiado para la clasificación de la información a ser accedida.
Si las contraseñas se transmiten en texto claro durante la sesión de ingreso a través de una
red, pueden ser capturadas por un programa "sniffer" de red.
9.4.3 Sistema de gestión de contraseñas
Control
Los sistemas de gestión de contraseñas deberían ser interactivos y asegurar que las
contraseñas sean de calidad.
Un sistema de gestión de contraseñas debería:
a) imponer el uso de ID de usuario y contraseñas individuales para mantener la

responsabilidad;
b) permitir a los usuarios seleccionar y cambiar sus propias contraseñas e incluir

un procedimiento de confirmación para tener en cuenta errores de entrada;
c) imponer la elección de contraseñas de calidad;
d) forzar a los usuarios a cambiar sus contraseñas en el primer ingreso;
e) imponer cambios regulares de contraseña y cuando sea necesario;
f) mantener un registro de las contraseñas utilizadas anteriormente y evitar su

reutilización;

PERUANA 55 de 162
g) no mostrar las contraseñas en la pantalla cuando están ingresándolas;
h) almacenar archivos de contraseñas separadamente de los datos del sistema de

aplicación;
i) almacenar y transmitir las contraseñas en forma protegida.
Algunas aplicaciones requieren que las contraseñas de usuario se asignen por una autoridad
independiente; en tales casos, los puntos b), d) y e) de la guía anteriormente no se aplican.
En la mayoría de los casos las contraseñas son seleccionadas y mantenidas por los usuarios.
9.4.4 Uso de programas utilitarios privilegiados
Control
El uso de programas utilitarios que podrían ser capaces de pasar por alto los controles del
sistema y de las aplicaciones debería estar restringido y controlarse estrictamente.
Las siguientes pautas para el uso de programas utilitarios que podrían ser capaces de pasar
por alto los controles del sistema y de las aplicaciones se deberían considerar:
a) uso de identificación, procedimientos de autentificación y autorización de los

programas utilitarios;
b) segregación de programas utilitarios de software de aplicaciones;
c) limitación del uso de programas utilitarios a un número prácticamente

mínimo de confianza, de usuarios autorizados (véase 9.2.3);
d) autorización para el uso especial de los programas utilitarios;

PERUANA 56 de 162
e) limitación de la disponibilidad de programas utilitarios, por ejemplo, para la

duración de un cambio autorizado;
f) registro completo del uso de los programas utilitarios;
g) definición y documentación de los niveles de autorización para los programas

utilitarios;
h) eliminación o desactivación de todos los programas utilitarios innecesarios;
i) no preparación de programas utilitarios disponibles para usuarios que tienen

acceso a aplicaciones en sistemas donde se requiere la separación de
funciones.
La mayoría de instalaciones de cómputo tienen uno o más programas utilitarios que podrían
ser capaces de anular controles de sistemas y aplicaciones.
9.4.5 Control de acceso al código fuente de los programas
Control
El acceso al código fuente de los programas debería estar restringido.
El acceso al código de los programas fuente y elementos asociados (tales como diseños,
especificaciones, planos de verificación y planos de validación) deberían estar estrictamente
controlados, con el fin de prevenir la introducción de funcionalidades no autorizadas y evitar
cambios no intencionales, así como para mantener la confidencialidad de la propiedad
intelectual de valor. Para el código del programa fuente, esto se puede lograr por el
almacenamiento central controlado de dicho código, preferiblemente en las bibliotecas de
programas fuente. Los siguientes lineamientos deberían tomarse en consideración para
controlar el acceso a este tipo de bibliotecas de programas fuente, con el fin de reducir las
posibilidades de corrupción de los programas del computador:

PERUANA 57 de 162
a) donde sea posible, las bibliotecas de programas fuente no deberían ser

retenidos en sistemas operacionales;
b) el código del programa fuente y las bibliotecas de programas fuente deberían

ser gestionados de acuerdo a los procedimientos establecidos;
c) el personal de soporte no debería tener acceso sin restricciones a las

bibliotecas de programas fuente;
d) la actualización de las bibliotecas de programas fuente y elementos asociados

y la emisión de programas fuente a los programadores sólo debería realizarse
después de que la autorización apropiada ha sido recibida;
e) las listas de programas deberían retenerse en un entorno seguro;
f) un registro de auditoría debería ser mantenido de todos los accesos a las

bibliotecas de fuente de programas;
g) el mantenimiento y la copia de las bibliotecas de programas fuente deberían

estar sujetos en estricto al procedimiento de control de cambios (véase
14.2.2).
Si el código del programa fuente está destinado a ser publicado, controles adicionales
deberían ser considerados para ayudar a conseguir garantías sobre su integridad (por
ejemplo, la firma digital).
10 Criptografía
10.1 Controles criptográficos
Objetivo: asegurar el uso apropiado y efectivo de la criptografía para proteger la

confidencialidad, autenticidad y/o integridad de la información.

PERUANA 58 de 162
10.1.1 Política sobre el uso de controles criptográficos
Control
Una política sobre el uso de controles criptográficos para la protección de la información

debería ser desarrollada e implementada.
En el desarrollo de una política criptográfica lo siguiente debería ser considerado:
a) el enfoque de gestión hacia el uso de controles criptográficos en toda la

organización, incluyendo los principios generales bajo la cual la información
de negocios debería ser protegida;
b) basado en una evaluación de riesgos, el nivel requerido de protección debería

ser identificado tomando en cuenta el tipo, la fortaleza y la calidad del
algoritmo de encriptación requerido;
c) el uso de encriptación para proteger la información transportada por los

dispositivos de medios móviles o removibles o a través de líneas de
comunicación;
d) el enfoque de la gestión de claves, incluyendo los métodos para tratar con la

protección de claves criptográficas y la recuperación de la información
encriptada en el caso de claves perdidas, comprometidas o dañadas;
e) los roles y responsabilidades, por ejemplo, quien es responsable de:

1) la implementación de la política;
2) la gestión de claves, incluyendo la generación de claves (véase 10.1.2);
f) los estándares que se adoptan para la implementación efectiva a lo largo de la

organización (que solución es utilizada para que procesos de negocio);
g) el impacto de usar información codificada en los controles que se basan en la

inspección de contenido (por ejemplo, la detección de software malicioso).

PERUANA 59 de 162
Cuando la organización implementa política criptográfica, se debería considerar las

regulaciones y restricciones nacionales que podrían aplicarse al uso de técnicas
criptográficas en diferentes partes del mundo y para los problemas de flujo transfronterizo
de información encriptada (véase 18.1.5).
Los controles criptográficos pueden ser usados para lograr diferentes objetivos de seguridad
de la información, por ejemplo:
a) confidencialidad: uso de encriptación de la información para proteger la

información sensible o crítica, ya sea almacenada o transmitida;
b) integridad / autenticidad: uso de firmas digitales o códigos de autentificación

de mensajes para verificar la autenticidad o integridad de la información
sensible o crítica almacenada o transmitida;
c) no repudio: uso de técnicas criptográficas para proveer evidencia de la

ocurrencia o no ocurrencia de un evento o acción;
d) autentificación: uso de técnicas criptográficas para autenticar usuarios y otras

entidades del sistema que soliciten el acceso o que realicen transacciones con
los usuarios, entidades y recursos del sistema.
Tomar una decisión en cuanto a si una solución criptográfica es apropiada debería ser visto
como parte de un proceso más amplio de evaluación de riesgos y selección de controles. Esta
evaluación se puede utilizar para determinar si un control criptográfico es apropiado, qué
tipo de control debería ser aplicado y para qué propósito y procesos de negocios.
En la política sobre el uso de controles criptográficos es necesario maximizar los beneficios

y minimizar los riesgos usando técnicas criptográficas y para evitar el uso inadecuado o
incorrecto.
El asesoramiento de un especialista se debería buscar en la selección de controles

criptográficos apropiados para satisfacer los objetivos de la política de seguridad de la
información.

PERUANA 60 de 162
10.1.2 Gestión de claves
Control
Una política sobre el uso, protección y tiempo de vida de las claves criptográficas debería
ser desarrollada e implementada a través de todo su ciclo de vida.
La política debería incluir los requisitos para la gestión de claves criptográficas en todo su
ciclo de vida incluyendo la generación, almacenamiento, archivamiento, recuperación,
distribución, retiro y destrucción de las claves.
Los algoritmos criptográficos, longitudes de clave y prácticas de uso deberían ser

seleccionados de acuerdo a las mejores prácticas. La apropiada gestión de claves requiere de
procesos seguros para generar, almacenar, archivar, recuperar, distribuir, retirar y destruir las
claves criptográficas.
Todas las claves criptográficas deberían estar protegidas contra la modificación y pérdida.
Además, las claves secretas y privadas necesitan protección contra el uso no autorizado, así
como la divulgación. El equipo utilizado para generar, almacenar y archivar claves debería
estar protegido físicamente.
Un sistema de gestión de claves debería basarse en un conjunto acordado de normas,

procedimientos y métodos seguros para:
a) la generación de claves para los diferentes sistemas criptográficos y diferentes

aplicaciones;
b) la emisión y obtención de certificados de clave pública;
c) la distribución de claves para entidades destinadas, incluyendo cómo deberían

activarse las claves cuando se reciben;

PERUANA 61 de 162
d) almacenamiento de claves, incluyendo cómo los usuarios autorizados obtener

acceso a las claves;
e) cambiar o actualizar las claves incluyendo reglas acerca de cuándo se

deberían cambiar y cómo se haría;
f) tratar con claves comprometidas;
g) revocar claves incluyendo cómo deberían ser retiradas o desactivadas, por

ejemplo, cuando las claves se han comprometido o cuando un usuario sale de
una organización (en cuyo caso las claves deberían ser archivadas);
h) recuperación de claves que están perdidas o corruptas;
i) copia de seguridad o archivamiento de claves;
j) destrucción de claves;
k) registro y la auditoría de las actividades relacionadas con la gestión de claves.
Con el fin de reducir la probabilidad de un uso inadecuado, fechas de activación y

desactivación de claves deberían estar definidas para que las claves se puedan utilizar
solamente para el período de tiempo definido en la política de gestión de claves asociada.
Además de gestionar de forma segura las claves secretas y privadas, la autenticidad de las
claves públicas también debería ser considerada. Este proceso de autentificación se puede
hacer utilizando certificados de clave pública, que normalmente son emitidos por una
autoridad certificadora, que debería ser una organización reconocida con los controles y
procedimientos adecuados en el lugar para proporcionar el grado necesario de confianza.
El contenido de los acuerdos de nivel de servicio o contratos con proveedores externos de

servicios criptográficos, por ejemplo, con una autoridad certificadora, debería abarcar
cuestiones de responsabilidad, fiabilidad de los servicios y tiempos de respuesta para la
prestación de servicios (véase 15.2).

PERUANA 62 de 162
La gestión de claves criptográficas es esencial para el uso eficaz de técnicas criptográficas.

La Norma ISO / IEC 11770 [2] [3] [4] proporciona más información sobre la gestión de
claves.
Las técnicas criptográficas también pueden ser utilizadas para proteger las claves
criptográficas. Puede ser necesario considerar procedimientos para manejar demandas
legales por el acceso a claves criptográficas, por ejemplo información cifrada puede tener
que estar disponible en forma no cifrada como prueba en un caso judicial.
11 Seguridad física y del entorno
11.1 Áreas seguras
Objetivo: impedir el acceso físico no autorizado, daño e interferencia de la información y a

las instalaciones de procesamiento de la información de la organización.
11.1.1 Perímetro de seguridad física
Control
Los perímetros de seguridad deberían estar definidos y utilizados para proteger áreas que
contienen información sensible o crítica e instalaciones de procesamiento de la información.
Deberían considerarse e implantarse las siguientes recomendaciones sobre los perímetros de

seguridad física, según corresponda:
a) los perímetros de seguridad deberían definirse y la ubicación y la resistencia

de cada uno de los perímetros deberían depender de los requisitos de la
PERUANA 63 de 162
seguridad de los activos dentro del perímetro y de los resultados de una

evaluación de riesgos;
b) los perímetros de un edificio o un lugar que contenga instalaciones de

procesamiento de información debería tener solidez física (por ejemplo no
tendrá zonas que puedan derribarse fácilmente); los muros, paredes y pisos
externos del lugar deberían ser sólidos y todas las puertas exteriores deberían
estar convenientemente protegidas contra accesos no autorizados mediante
mecanismos de control, (por ejemplo alarmas, cerraduras, entre otros);
puertas y ventanas deberían bloquearse cuando se encuentren descuidadas y
debería considerarse protección externa para las ventanas, particularmente en
niveles bajos;
c) debería existir un área de recepción atendida por personal u otros medios de

control de acceso físico al área o edificio; dicho acceso debería restringirse
sólo al personal autorizado;
d) donde sea aplicable, deberían construirse barreras físicas para evitar el acceso
físico no autorizado y la contaminación del entorno;
e) todas las puertas contra incendios del perímetro de seguridad deberían tener
alarma, estar supervisadas y probadas conjuntamente con las paredes para
establecer el nivel requerido de resistencia de acuerdo a las normas nacionales
e internacionales apropiadas; deberían funcionar de acuerdo con las
disposiciones locales de protección contra el fuego de modo de garantizar la
seguridad;
f) deberían instalarse sistemas de detección de intrusos adecuados según las

normas nacionales o internacionales y probar regularmente para cubrir todas
las puertas externas y ventanas accesibles; las áreas no ocupadas deberían
contar con alarmas siempre; también debería proporcionarse protección para
otras áreas, por ejemplo, sala de computadoras o cuartos de comunicaciones;
g) las instalaciones de procesamiento de información gestionadas por la

organización deberían separarse físicamente de aquellas gestionadas por
terceras partes.
La protección física puede ser alcanzada creando una o más barreras físicas alrededor de las
premisas de la organización y de las instalaciones de procesamiento de la información. El

PERUANA 64 de 162
uso de múltiples barreras brinda protección adicional, mientras que la falta de una barrera
no significa que la seguridad se vea comprometida inmediatamente.
Un área segura puede ser una oficina bloqueable o varios cuartos rodeados por una barrera
física continua interna de seguridad. Las barreras adicionales y los perímetros para controlar
el acceso físico pueden ser necesarios entre áreas con diferentes requisitos de seguridad
dentro del perímetro de seguridad. Deberían tenerse consideraciones especiales de seguridad
de acceso físico en los edificios donde funcionan múltiples organizaciones.
La aplicación de los controles físicos, especialmente para las áreas de seguridad, debería
adaptarse a las circunstancias técnicas y económicas de la organización, según se establezca
en la evaluación de riesgos.
11.1.2 Controles de ingreso físico
Control
Las áreas seguras deberían estar protegidas por medio de controles apropiados de ingreso
para asegurar que se le permite el acceso sólo al personal autorizado.
Deberían considerarse las siguientes recomendaciones:
a) la fecha y hora de entrada y salida de visitantes deberían restringirse y todos

los visitantes deberían supervisarse a menos que su acceso se haya aprobado
previamente; el acceso debería concederse sólo para propósitos específicos y
autorizados, proporcionándoles instrucciones sobre los requisitos de
seguridad del área y los procedimientos de emergencia. La identidad de los
visitantes debería ser autenticada por un medio adecuado;
b) el acceso a las áreas donde se procesa o se almacena la información sensible

debería estar restringido sólo a las personas autorizadas mediante la
implementación de controles de autentificación, por ejemplo, mediante la
implementación de un mecanismo de autentificación de dos factores, tales

PERUANA 65 de 162
como tarjetas de acceso o tarjetas con número de identificación personal

(PIN);
c) debería mantenerse y supervisarse de manera segura una bitácora de registro

físico o registro electrónico de auditoría;
d) todos los empleados, contratistas y partes externas deberían ser obligados a

utilizar algún tipo de identificación visible y deberían notificar
inmediatamente al personal de seguridad si encuentran a visitantes no
acompañados y a cualquier persona que no lleve la identificación visible;
e) debería concederse el acceso restringido del personal de soporte de terceras

partes a las áreas seguras o a las instalaciones sensibles de procesamiento de
la información sólo cuando sea requerido; este acceso debería ser autorizado
y supervisado;
f) los derechos de acceso a las áreas seguras deberían ser regularmente revisados
y actualizados y revocados cuando sea necesario (véase 9.2.4 y 9.25).
11.1.3 Asegurar oficinas, áreas e instalaciones
Control
La seguridad física para oficinas, áreas e instalaciones debería ser diseñada e implementada.
Deberían considerarse las siguientes recomendaciones para asegurar oficinas, despachos, e

instalaciones:
a) las instalaciones claves deberían situarse de manera que evite el acceso

público;
b) cuando corresponda, los edificios deberían ser discretos y dar el mínimo

indicio de su propósito, cuando sea posible, sin dar muestras obvias, fuera o
dentro del edificio, que identifiquen la presencia de las actividades de
procesamiento de la información;

PERUANA 66 de 162
c) las instalaciones deberían estar configuradas para evitar que la información

confidencial o las actividades sean visibles y audibles desde el exterior.
Cuando corresponda, debería considerarse el blindaje electromagnético como
adecuado;
d) los directorios y libros de teléfonos internos que identifican ubicaciones de

instalaciones sensibles de procesamiento de la información no deberían ser
fácilmente accesibles por el público.
11.1.4 Protección contra amenazas externas y ambientales
Control
La protección física contra desastres naturales, ataque malicioso o accidentes debería estar
diseñada y aplicada.
Debería obtenerse asesoramiento especializado sobre cómo evitar los daños causados por
incendios, inundaciones, terremotos, explosiones, disturbios civiles y otras formas de
desastres naturales o producido por el hombre.
11.1.5 Trabajo en áreas seguras
Control
Los procedimientos para el trabajo en áreas seguras deberían estar diseñados y aplicados.

PERUANA 67 de 162
a) el personal debería conocer la existencia de un área segura o de sus

actividades, únicamente en el caso de que sea necesario para su trabajo.
b) debería evitarse el trabajo no supervisado en áreas seguras tanto por motivos

de seguridad como para evitar ocasiones de actividades maliciosas;
c) las áreas seguras desocupadas deberían cerrarse y controlarse

periódicamente;
d) no debería permitirse la presencia de equipos de fotografía, video, audio u

otras formas de registro, salvo autorización expresa.
Los acuerdos para trabajar en áreas seguras incluyen controles para los empleados y los
usuarios de terceras partes que trabajan en el área segura, así como otras actividades de
terceros que ocurren allí.
11.1.6 Áreas de despacho y carga
Control
Los puntos de acceso, como las áreas de despacho, carga y otros puntos en donde personas
no autorizadas pueden ingresar al local deberían estar controlados y si fuera posible, aislarlos
de las instalaciones de procesamiento de la información para evitar el acceso no autorizado.
a) debería restringirse el acceso al área de entrega y carga desde el exterior

únicamente al personal autorizado e identificado;
b) el área de entrega y carga debería diseñarse para que los suministros puedan
cargarse y descargarse sin que el personal de depósito tenga acceso a otras
zonas del edificio;

PERUANA 68 de 162
c) las puertas externas del área de entrega y carga deberían cerrarse cuando las
internas estén abiertas;
d) el material entrante debería inspeccionarse y examinarse en busca de

explosivos, químicos u otros materiales peligrosos, antes de que se lleven al
área de entrega y carga;
e) el material entrante debería registrarse de acuerdo con el procedimiento de

gestión de activos (véase el capítulo 8) al entrar en el lugar;
f) cuando sea posible, los envíos entrantes y salientes deberían segregarse

físicamente;
g) el material entrante debería inspeccionarse para saber si hay pruebas de

manipulación indebida. Si se descubre tal manipulación, el personal de
seguridad debería ser inmediatamente notificado.
11.2 Equipos
Objetivo: prevenir la pérdida, daño, robo o compromiso de activos e interrupción de las

operaciones de la organización.
11.2.1 Ubicación y protección de los equipos
Control
Los equipos deberían estar ubicados y protegidos para reducir los riesgos de amenazas y
peligros ambientales, así como las oportunidades para el acceso no autorizado.
Guía de implementación.
Deberían considerarse las siguientes recomendaciones para proteger el equipamiento:
a) el equipamiento debería situarse de manera que minimice el acceso

innecesario a las áreas de trabajo;

PERUANA 69 de 162
b) las instalaciones de procesamiento de la información que manejan datos

sensibles deberían colocarse cuidadosamente para reducir el riesgo de que la
información sea vista por personas no autorizadas durante su uso;
c) las instalaciones de almacenamiento deberían asegurarse para evitar el acceso

no autorizado;
d) los elementos que requieran protección especial deberían aislarse para reducir
el nivel general de protección requerida;
e) deberían adoptarse controles para reducir al mínimo el riesgo de amenazas

físicas potenciales, como: hurto, fuego, explosivos, humo, inundaciones (o
falta de suministro de agua), polvo, vibraciones, efectos químicos,
interferencias en el suministro eléctrico, interferencia de las comunicaciones,
radiación electromagnética y vandalismo;
f) deberían establecerse pautas para comer, beber y fumar en proximidad de las

instalaciones de procesamiento de la información;
g) las condiciones ambientales, tales como temperatura y humedad, deberían

supervisarse para verificar que las mismas no afectan negativamente el
funcionamiento de las instalaciones de procesamiento de la información;
h) deberían colocarse pararrayos sobre todos los edificios y deberían aplicarse

filtros de protección contra rayos a todas las líneas entrantes de energía y de
comunicaciones;
i) debería considerarse el uso de métodos de protección especial, como las

cubiertas de teclados, para el equipamiento ubicado en ambientes industriales;
j) debería protegerse el equipamiento que procese información sensible para

reducir al mínimo el riesgo de filtración de información debido a la
emanación electromagnética.
11.2.2 Servicios de suministro
Control
Los equipos deberían estar protegidos contra fallas de electricidad y otras alteraciones
causadas por fallas en los servicios de suministro.

PERUANA 70 de 162
Los elementos de soporte (por ejemplo, la electricidad, las telecomunicaciones, el agua

potable, el gas, el alcantarillado, la ventilación y el aire acondicionado) deberían:
a) cumplir con las especificaciones del fabricante de los equipamientos y con

los requisitos legales locales;
b) ser evaluados regularmente por su capacidad para cumplir con el crecimiento

del negocio y las interacciones con otros elementos de soporte;
c) ser inspeccionados y probados regularmente para asegurar su buen

funcionamiento;
d) si es necesario, contar con alarmas, para detectar fallos de funcionamiento;
e) si es necesario, tener múltiples canales con diversos enrutamientos físicos.
Deberían proporcionarse alumbrado de emergencia. Los interruptores y las válvulas de

emergencia para cortar el suministro de energía, agua, gas u otros servicios públicos deberían
ubicarse cerca de las salidas de emergencia o de las salas de máquinas.
Se puede obtener redundancia adicional para la conectividad de redes mediante múltiples

rutas de más de un proveedor de servicios públicos.
11.2.3 Seguridad del cableado
Control
El cableado de energía y telecomunicaciones que llevan datos o servicios de información de

soporte debería ser protegido de la interceptación, interferencia o daño.

PERUANA 71 de 162
Guía para la implementación
Deberían considerarse las siguientes recomendaciones para la seguridad en el cableado:
a) las líneas de energía y telecomunicaciones en instalaciones de procesamiento

de la información deberían ser subterráneas, siempre que sea posible o sujetas
a una adecuada protección alternativa;
b) los cables de energía deberían separarse de los cables de comunicaciones para

evitar interferencias;
c) entre los controles adicionales a considerar para los sistemas sensibles o

críticos se incluyen:
1) instalación de conductos blindados y recintos o cajas con cerradura en los

puntos terminales y de inspección;
2) uso de escudos electromagnéticos para proteger los cables;
3) iniciar barridos técnicos e inspecciones físicas contra dispositivos no

autorizados conectados a los cables;
4) acceso controlado a los paneles de conexión (patch panel) y a las salas de

cable.
11.2.4 Mantenimiento de equipos
Control
Los equipos deberían mantenerse de manera correcta para asegurar su continua

disponibilidad e integridad.
Deberían considerarse las siguientes recomendaciones para el mantenimiento del

equipamiento:

PERUANA 72 de 162
a) el equipamiento debería mantenerse de acuerdo a las recomendaciones de

intervalos y especificaciones de servicio del proveedor;
b) sólo el personal de mantenimiento debidamente autorizado debería realizar

reparaciones y realizar el mantenimiento a los equipos;
c) se debería mantener registros de todos los fallos, reales o sospechados, así

como de todo el mantenimiento preventivo y correctivo;
d) se debería implantar controles apropiados cuando el equipamiento sea

dispuesto para mantenimiento, considerando si este mantenimiento es
realizado por personal interno o externo a la organización; la información
sensible debería removerse del equipo, cuando sea necesario o el personal de
mantenimiento debería ser suficientemente transparente;
e) se debería cumplir con todos los requisitos impuestos por pólizas de seguros;
f) antes de poner el equipamiento nuevamente en funcionamiento, debería ser

inspeccionado para asegurar que el equipamiento no ha sido manipulado y no
tiene un mal funcionamiento.
11.2.5 Retiro de activos
Control
Los equipos, la información o el software no deberían ser retirados de su lugar sin

autorización previa.
a) se debería identificar aquellos empleados y usuarios de terceras partes que

tengan autoridad para permitir el retiro de activos fuera de los locales de la
organización;

PERUANA 73 de 162
b) se debería fijar los límites de tiempo para el retiro del equipamiento y verificar
el cumplimiento del retorno;
c) cuando sea necesario y procedente, debería registrarse tanto la salida del

equipamiento del local, como el retorno del mismo;
d) se debería documentar la identidad, la función y la afiliación de cualquier

persona que gestiona o utiliza bienes y esta documentación debería
devolverse junto con el equipamiento, la información o el software.
Las instancias de inspección, emprendidas para detectar el retiro de bienes no autorizados,

se pueden también realizar para detectar y prevenir el ingreso no autorizado a las
instalaciones, de dispositivos de grabación, armas, entre otros. Tales instancias de inspección
deberían realizarse de acuerdo con la legislación y las regulaciones relevantes. Los
individuos deberían estar en conocimiento de que estas instancias de inspección serán
llevadas a cabo y las mismas deberían realizarse solamente con la autorización apropiada
según los requisitos legales y reguladores.
11.2.6 Seguridad de equipos y activos fuera de las instalaciones
Control
La seguridad debería ser aplicada a los activos que están fuera de su lugar tomando en cuenta
los distintos riesgos de trabajar fuera de las instalaciones de la organización.
El uso de cualquier equipamiento que almacene o procese información fuera de las

instalaciones de la organización, debería autorizarse por la dirección. Esto se aplica a los
equipamientos de la organización y al equipamiento de propiedad privada utilizado en
nombre de la organización.

PERUANA 74 de 162
Deberían considerarse las siguientes recomendaciones para la protección del equipamiento

fuera de los locales de la organización:
a) los equipos y soportes que contengan datos con información y sean sacados
de su entorno habitual no deberían dejarse desatendidos en sitios públicos;
b) se deberían observar siempre las instrucciones del fabricante para proteger los
equipos, por ejemplo, contra exposiciones a campos electromagnéticos
intensos;
c) los controles para las ubicaciones fuera de los locales, tales como el trabajo
en el domicilio, el teletrabajo y los sitios temporales deberían determinarse
mediante una evaluación de los riesgos y aplicarse los controles convenientes
según sea apropiado, por ejemplo, gabinetes para archivos con cerradura, una
política de escritorios limpios, controles de acceso a las computadoras y
comunicaciones seguras con la oficina (véase la Norma ISO/IEC 27033
Network Security);
d) cuando el equipamiento fuera de las instalaciones es transferido entre

diferentes personas o partes externas, debería mantenerse un registro que
defina la cadena de custodia para el equipamiento, incluyendo como mínimo,
los nombres y las organizaciones de aquellos que son responsables del
equipamiento.
Los riesgos, por ejemplo, de daños, hurto o espionaje, pueden variar considerablemente entre
las locaciones y deberían tenerse en cuenta para determinar los controles más adecuados.
El equipamiento de almacenamiento y procesamiento de la información comprende todo tipo

de computadoras personales, organizadores, teléfonos móviles, tarjetas inteligentes,
documentos u otros, que se lleven al domicilio o fuera del lugar habitual de trabajo.
Puede encontrarse en 6.2 más información sobre otros aspectos de la protección de equipos
móviles.

PERUANA 75 de 162
Puede ser apropiado para evitar el riesgo, disuadir a ciertos empleados de trabajar fuera de
las instalaciones o mediante la restricción de uso de equipos informáticos portátiles;
11.2.7 Disposición o reutilización segura de equipos
Control
Todos los elementos del equipo que contengan medios de almacenamiento deberían ser
verificados para asegurar que cualquier dato sensible y software con licencia se haya
eliminado o se haya sobre escrito de manera segura antes de su disposición o reutilización.
Los equipamientos deberían revisarse para asegurar que los medios de almacenamiento estén
contenidos antes de su puesta a disposición o reutilización.
Los dispositivos de almacenamiento con información sensible o con derechos de autor

deberían destruirse físicamente o la información debería destruirse, suprimirse o
sobrescribirse usando técnicas para hacer que la información original no sea recuperable, en
lugar de utilizar las funciones de borrado o formateado estándar.
Los dispositivos de almacenamiento dañados que contengan datos sensibles pueden requerir
una evaluación de riesgo para determinar si estos deberían destruirse físicamente, antes que
ser enviados para su reparación o desecho. La información puede verse comprometida si la
reutilización o eliminación de los equipos se realiza de manera descuidada.
Además del borrado seguro del disco, todo el cifrado del disco reduce el riesgo de
divulgación de información confidencial cuando los equipamientos son eliminados o
redistribuidos, siempre que:

PERUANA 76 de 162
a) el proceso de cifrado sea lo suficientemente fuerte y cubra todo el disco

(incluyendo el espacio libre, los archivos de intercambio, entre otros);
b) las claves del cifrado son lo suficientemente largas como para resistir los
ataques de fuerza bruta;
c) las claves del cifrado se mantienen confidenciales (por ejemplo, nunca son
almacenadas en el mismo disco).
Para más información sobre encriptación, véase el capítulo 10.
Las técnicas para los medios de almacenamiento seguros de sobrescritura difieren de acuerdo
a la tecnología de los medios de almacenamiento. Las herramientas de sobrescritura deberían
revisarse para garantizar que son aplicables a la tecnología de los medios de
almacenamiento.
11.2.8 Equipos de usuario desatendidos
Control
Los usuarios deberían asegurarse de que el equipo desatendido tenga la protección

apropiada.
Todos los usuarios deberían estar advertidos de los requisitos y procedimientos de seguridad
para proteger equipamiento desatendido, así como de su responsabilidad de implementar tal
protección. Debería advertirse a los usuarios sobre:
a) terminar sesiones activas cuando son finalizadas, salvo que se les pueda
asegurar por un mecanismo de bloqueo apropiado, por ejemplo un protector
de pantalla protegido con contraseña;
b) desconectarse de aplicaciones o de servicios de red cuando ya no sea

necesario;

PERUANA 77 de 162
c) asegurar a las computadoras o dispositivos móviles de uso no autorizado

mediante una clave de bloqueo o un control equivalente, por ejemplo
contraseña de acceso cuando no se encuentra en uso.
11.2.9 Política de escritorio limpio y pantalla limpia
Control
Una política de escritorio limpio de papeles y de medios de almacenamiento removibles, así

como una política de pantalla limpia para las instalaciones de procesamientos de la
información debería ser adoptada.
Una política de escritorio limpio debería tener en cuenta la clasificación de la información

(véase 8.2), requisitos legales y contractuales (véase 18.1) y los aspectos culturales y de
riesgo de la organización correspondientes. Deberían considerarse las siguientes
recomendaciones:
a) cuando no se requiere la información sensible o crítica del negocio, contenida

por ejemplo en medios de almacenamiento electrónicos o en papel, debería
asegurarse bajo llave (idealmente una caja fuerte, un gabinete u otro mueble
de seguridad), especialmente cuando la oficina está vacía;
b) las computadoras y terminales deberían desconectarse o protegerse con un

mecanismo de bloqueo de pantalla y teclado controlado por contraseña, un
token o mecanismo de autentificación de usuario similar cuando está
desatendida y debería protegerse por claves de bloqueo o contraseñas u otros
controles cuando no está en uso;
c) debería prevenirse el uso no autorizado de fotocopiadoras y otras tecnologías

de reproducción (por ejemplo cámaras digitales);
d) documentación conteniendo información clasificada o sensible debería

retirarse de las impresoras inmediatamente.

PERUANA 78 de 162
Una política de escritorio y pantalla limpios, reduce los riesgos de acceso no autorizado,
pérdida o daño a la información durante y fuera de las horas normales de trabajo. Cajas
fuertes u otras formas de almacenamiento seguro pueden también proteger información
almacenada dentro de ellas, contra desastres tales como incendios, terremotos, inundaciones
o explosiones.
Considerar el uso de impresoras con una función de código de uso (PIN), de modo que los
generadores sean los únicos que puedan obtener sus impresos y solamente estando parados
al lado de la impresora.
12 Seguridad de las operaciones
12.1 Procedimientos y responsabilidades operativas
Objetivo: asegurar que las operaciones de instalaciones de procesamiento de la información

sean correctas y seguras.
12.1.1 Procedimientos operativos documentados
Control
Los procedimientos operativos deberían estar documentados y puestos a disposición de todos

los usuarios que los necesitan.
Deberían elaborarse procedimientos documentados para las actividades del sistema

asociadas con las instalaciones de comunicaciones y de procesamiento de información, tales
como procedimientos de arranque y apagado del computador, respaldo, mantenimiento de
equipos, gestión y seguridad de la sala de cómputo y el manejo del correo.

PERUANA 79 de 162
Los procedimientos operacionales deberían especificar las instrucciones de funcionamiento,

incluyendo:
a) la instalación y configuración de los sistemas;
b) el procesamiento y manejo de la información, tanto automatizada como

manual;
c) respaldo (véase 12.3);
d) requisitos programables de tareas (Jobs), incluyendo interdependencias con

otros sistemas, tiempos de inicio temprano y finalización tardía de tareas;
e) instrucciones para el manejo de errores u otras condiciones excepcionales,

que pudieran presentarse durante la ejecución de tareas (job), incluyendo
restricciones en el uso de las utilidades de sistema (véase 9.4.4);
f) contactos de soporte y escalamiento incluyendo soporte externo en caso de

inesperadas dificultades operacionales o técnicas;
g) instrucciones para salida de información y manejo de medios, tales como la

utilización de papelería especial o la gestión de salidas confidenciales
incluyendo los procedimientos para la disposición segura de la salida de
trabajos fallidos (véase 8.3 y 11.2.7);
h) procedimientos de reinicio y recuperación para usar en caso de falla del

sistema;
i) la gestión de las pistas de auditoría y de la información del registro del sistema

(véase 12.4);
j) procedimientos de monitoreo (véase 12.4).
Los procedimientos de operación y los procedimientos documentados para las actividades

del sistema, deberían ser tratados como documentos formales y los cambios autorizados por
la dirección. Cuando sea técnicamente posible, los sistemas de información deberían
gestionarse de forma consistente, usando los mismos procedimientos, herramientas y
utilidades.

PERUANA 80 de 162
12.1.2 Gestión del cambio
Control
Los cambios en la organización, procesos de negocio, instalaciones de procesamiento de la

información y sistemas que afecten la seguridad de la información deberían ser controlados.
En particular deberían considerarse los siguientes elementos:
a) identificación y registro de cambios significativos;
b) planificación y pruebas de los cambios;
c) evaluación de los impactos potenciales, incluyendo los impactos en la

seguridad de la información de tales cambios;
d) procedimiento formal de aprobación para los cambios propuestos;
e) verificación de que se han cumplido los requisitos de seguridad de la

información;
f) comunicación de los detalles del cambio a todas las personas relevantes;
g) procedimientos de vuelta atrás (fallback), incluyendo procedimientos y

responsabilidades para abortar y recuperarse de los cambios sin éxito y
eventos imprevistos.
h) provisión de un proceso de cambio de emergencia para permitir la aplicación

rápida y controlada de los cambios necesarios para resolver un incidente
(véase 16.1).
Deberían establecerse las responsabilidades y los procedimientos formales de gestión para

asegurar el control satisfactorio de todos los cambios. Cuando se realizan los cambios,
debería retenerse un registro de auditoría conteniendo toda la información relevante.

PERUANA 81 de 162
El control inadecuado de cambios en las instalaciones y los sistemas de procesamiento de la

información es una causa común de las fallas del sistema o de la seguridad. Cambios en el
ambiente operacional, especialmente al transferir un sistema en desarrollo a producción,
pueden impactar la confiabilidad de las aplicaciones (véase 14.2.2).
12.1.3 Gestión de la capacidad
Control
El uso de recursos debería ser monitoreado, afinado y se debería hacer proyecciones de los
futuros requisitos de capacidad para asegurar el desempeño requerido del sistema.
Deberían identificarse los requisitos de capacidad, teniendo en cuenta la criticidad del

negocio del sistema en cuestión. Deberían aplicarse ajustes del sistema y monitoreo para
asegurar y cuando sea necesario, mejorar la disponibilidad y la eficiencia de los sistemas.
Deberían colocarse controles detectivos para indicar problemas a su debido tiempo. Las
proyecciones de los requisitos futuros de capacidad deberían tomar en cuenta los nuevos
requisitos del negocio y del sistema, así como las tendencias actuales y proyectadas en las
capacidades de procesamiento de la información de la organización.
Es necesario poner atención a los recursos cuya adquisición toma mucho tiempo o requiere
costos elevados; por lo tanto los gerentes deberían monitorear la utilización de los recursos
clave del sistema. Ellos deberían identificar las tendencias en el uso, particularmente en lo
referente a las aplicaciones del negocio o las herramientas de administración de los sistemas
de información.
Los gerentes deberían utilizar esta información para identificar y evitar posibles cuellos de
botella y dependencias de personal clave que pudiera presentar una amenaza a la seguridad
del sistema o a los servicios y planificar la acción apropiada.

PERUANA 82 de 162
Se puede proporcionar suficiente capacidad mediante el incremento de la misma o

reduciendo la demanda. Ejemplos de la gestión de la demanda de capacidad incluye:
a) la eliminación de datos obsoletos (espacio en disco);
b) el desmantelamiento de aplicaciones, sistemas, bases de datos o ambientes;
c) la optimización y calendarización de los procesos en lote.;
d) la optimización de la lógica de la aplicación o de las consultas a la base de

datos.
e) la negación o restricción del ancho de banda para los servicios ávidos de

recursos, si no son críticos para el negocio (por ejemplo, trasmisión de
videos).
Debería considerarse un plan documentado de gestión de capacidad para los sistemas de

misión crítica.
Este control también se refiere a la capacidad de los recursos humanos, así como a las
oficinas e instalaciones.
12.1.4 Separación de los entornos de desarrollo, pruebas y operaciones
Control
Los entornos de desarrollo, pruebas y operaciones deberían estar separados para reducir los
riesgos de acceso no autorizado o cambios al entorno operativo.
Debería identificarse e implementarse el grado de separación entre los ambientes de

desarrollo, prueba y operación que es necesario para prevenir problemas operacionales.
PERUANA 83 de 162
Los siguientes puntos deberían considerarse:
a) las reglas para transferir el software del ambiente de desarrollo al de

operación deberían estar definidas y documentadas;
b) el software de desarrollo y el de producción deberían, si es posible, funcionar

en sistemas y procesadores diferentes y en dominios o directorios distintos;
c) los cambios en los sistemas y aplicaciones operacionales deberían probarse

en un ambiente de pruebas o ensayos, antes de ser aplicados a los sistemas
operacionales;
d) salvo en circunstancias excepcionales, las pruebas no deberían hacerse en los

sistemas operacionales;
e) los compiladores, editores y otras herramientas de desarrollo o utilidades del

sistema no deberían accederse desde los sistemas operacionales, cuando no
sea requerido;
f) los usuarios deberían usar perfiles de usuario diferentes para los sistemas
operaciones y de prueba y los menús deberían exhibir mensajes de
identificación apropiados para reducir el riesgo a error;
g) los datos sensibles no deberían copiarse en el entorno de prueba del sistema,

a menos que se proporcionen controles equivalentes para el sistema de prueba
(véase 14.3).
Las actividades de desarrollo y prueba pueden causar serios problemas, por ejemplo
modificación indeseada de archivos o del entorno del sistema, o fallo del sistema. Hay una
necesidad de mantener un ambiente estable y conocido en el cual realizar pruebas
significativas y prevenir el inadecuado acceso del desarrollador al entorno operacional.
Donde el personal de desarrollo y de pruebas tiene acceso al sistema operacional y a su

información, puede introducir código no autorizado y no comprobado o alterar datos
operacionales. En algunos sistemas, esta capacidad podría ser mal utilizada para realizar
fraude o introducir código no comprobado o malicioso, que puede causar problemas
operacionales serios.

PERUANA 84 de 162
El personal de desarrollo y de pruebas también supone una amenaza a la confidencialidad

de la información operacional. Las actividades de desarrollo y de pruebas pueden causar
cambios involuntarios al software o a la información si comparten el mismo entorno. Por lo
tanto, es deseable separar los entornos de desarrollo, prueba y operacional para reducir el
riesgo de cambio accidental o acceso no autorizado al software operacional y a los datos del
negocio (véase 14.3 para la protección de los datos de prueba).
12.2 Protección contra software malicioso (malware)
Objetivo: asegurar que la información y las instalaciones de procesamiento de la información

estén protegidas contra el software malicioso (malware).
12.2.1 Controles contra software malicioso (malware)
Control
Controles de detección, prevención y recuperación para proteger contra el software

malicioso deberían estar implementados, en combinación con una concientización apropiada
de los usuarios.
La protección contra software malicioso debería basarse en el empleo de software de

detección de código malicioso y reparación, en la creación de conciencia de la seguridad de
información y en apropiados controles de acceso al sistema y gestión de cambios. Los
siguientes lineamientos deberían considerarse:
a) establecimiento de una política formal que prohibida el uso de software no

autorizado (véase 12.6.2 y 14.2);
b) implementación de controles que previenen o detectan el uso de software no

autorizado (por ejemplo, lista blanca de aplicaciones);
c) implementación de controles que previenen o detectan el uso de sitios web

maliciosos conocidos o sospechosos (por ejemplo, listas negras);

PERUANA 85 de 162
d) establecimiento de una política formal de protección contra los riesgos

asociados a la obtención de archivos y software por redes externas o cualquier
otro medio, indicando qué medidas protectoras se deberían tomar;
e) reducción de las vulnerabilidades que podrían ser explotadas por el software

malicioso, por ejemplo, a través de la gestión vulnerabilidades técnicas (véase
12.6);
f) revisiones regulares del contenido de datos y el software de los sistemas que

soportan los procesos críticos del negocio; la presencia de cualquier archivo
no aprobado o arreglos no autorizados debería investigarse formalmente;
g) la instalación y actualización regular de software para detección y reparación

de software malicioso que explore las computadoras y los medios de forma
rutinaria o como un control preventivo; el escaneo realizado debería incluir:
1) el escaneo de los archivos recibidos a través de redes o por cualquier tipo de

medio de almacenamiento, en busca de software malicioso antes de su uso;
2) el escaneo de los archivos adjuntos de correo electrónico o descargas para

buscar software malicioso, antes de usarlo; este escaneo debería realizarse en
distintos lugares, por ejemplo, en los servidores de correo electrónico, en las
computadoras de escritorio o a la entrada en la red de la organización;
3) el escaneo de páginas web para buscar software malicioso;
h) definición de procedimientos y responsabilidades para tratar con la protección

contra software malicioso de los sistemas, la capacitación para su uso,
presentación de reportes y la recuperación de ataques de software malicioso;
i) preparación de planes de continuidad del negocio apropiados para la

recuperación ante los ataques de software malicioso, incluyendo todos los
datos y software necesarios de respaldo y las disposiciones para la
recuperación (véase 12.3);
j) implementación de procedimientos para recoger regularmente la

información, tales como suscripción a listas de correo o verificación de los
sitios web que brindan información sobre nuevo software malicioso;
k) implementación de procedimientos para verificar toda la información relativa

al software malicioso y asegurarse que los boletines de alerta son precisos e
informativos; los gerentes deberían asegurarse que se diferencian los software
maliciosos reales de los falsos avisos de software malicioso, usando fuentes
calificadas, por ejemplo, revistas de prestigio, sitios de Internet confiables o
PERUANA 86 de 162
proveedores de software contra software malicioso; todos los usuarios

deberían ser conscientes sobre el problema de los falsos avisos de software
malicioso y qué hacer en caso de recibirlos.
l) aislar entornos en los que se pueden producir impactos catastróficos.
El uso de dos o más productos de software que protegen contra software malicioso en el
entorno de procesamiento de información de diferentes vendedores y tecnología, puede
mejorar la eficacia de la protección contra el software malicioso.
Debería tenerse cuidado para protegerse contra la introducción de código malicioso durante
los procedimientos de mantenimiento y de emergencia, los cuales pueden saltear los
controles normales contra software malicioso.
Bajo ciertas condiciones, la protección contra el código malicioso puede causar trastornos
en las operaciones.
El uso de software de detección y reparación contra código malicioso como único control
contra el software malicioso no suele ser suficiente y comúnmente necesita ser acompañado
por procedimientos operativos que impidan la introducción del software malicioso.
12.3 Respaldo
Objetivo: proteger contra la pérdida de datos
12.3.1 Respaldo de la información
Control
Copias de respaldo de la información, del software y de las imágenes del sistema deberían
ser realizadas y verificadas regularmente en concordancia con una política de respaldo
acordada.
PERUANA 87 de 162
Debería establecerse una política de respaldo para definir los requisitos de la organización
para los respaldos de la información, software y sistemas.
La política de respaldo debería definir los requisitos de retención y protección.
Deberían proporcionarse instalaciones adecuadas de respaldo para garantizar que toda la

información y software esenciales se pueden recuperar después de un desastre o falla de
medios.
Al diseñar un plan de respaldo, deberían considerarse los siguientes elementos:
a) deberían producirse registros exactos y completos de las copias de respaldo y

procedimientos documentados de restauración;
b) el grado (por ejemplo, respaldo completo o diferencial) y la frecuencia de los

respaldos deberían reflejar los requisitos del negocio, los requisitos de la
seguridad de la información implicada y la criticidad de la información para
la operación continua de la organización;
c) los respaldos deberían almacenarse en lugar remoto, a una distancia suficiente

como para evitar cualquier daño en caso de desastre en el sitio principal;
d) la información de respaldo debería tener un nivel apropiado de protección

ambiental y física (véase el capítulo 11) consistente con las normas aplicadas
en el sitio principal;
e) los soportes de respaldo deberían probarse regularmente para asegurarse que

pueden ser confiables para uso de emergencia cuando sea necesario; esto se
debería combinar con una prueba de los procedimientos de restauración y
comprobados con el tiempo de restauración requerido. Las pruebas de la
capacidad para restaurar los datos de respaldo deberían realizarse en medios
de prueba dedicados y no sobrescribir los medios originales en caso de que el
respaldo o el proceso de restauración fallen y ocasione daños o pérdida de
datos irreparable;

PERUANA 88 de 162
f) en situaciones donde la confidencialidad es de importancia, los respaldos

deberían protegerse por medio del cifrado.
Los procedimientos operacionales deberían monitorear la ejecución de los respaldos y

abordar las fallas de los respaldos programados para garantizar la integridad de los respaldos
de acuerdo con la política de respaldo.
Los arreglos de respaldo para los sistemas y servicios individuales deberían probarse
regularmente para garantizar que cumplen los requisitos de los planes para la continuidad
del negocio. Para los sistemas y servicios críticos, los arreglos de respaldo deberían cubrir
todos los sistemas de información, aplicaciones y datos necesarios para recuperar
completamente el sistema en caso de un desastre.
El periodo de retención para la información esencial de la organización debería determinarse,

tomando en cuenta cualquier requisito de copias archivadas que deberían retenerse
permanentemente.
12.4 Registros y monitoreo
Objetivo: registrar eventos y generar evidencia
12.4.1 Registro de eventos
Control
Registros (logs) de eventos de actividades de usuarios, excepciones, fallas y eventos de

seguridad de la información deberían ser producidos, mantenidos y regularmente revisados.
Los registros de eventos deberían incluir, cuando corresponda:

PERUANA 89 de 162
a) identificador de usuario;
b) actividades del sistema;
c) fechas, horas y detalles de los eventos clave, por ejemplo, inicio y cierre de
sesión;
d) identidad o ubicación del dispositivo, si es posible y el identificador del

sistema;
e) registros de intentos de accesos exitosos y fallidos del sistema;
f) registros de intentos exitosos y fallidos de accesos a datos y a otros recursos;
g) cambios en la configuración del sistema;
h) uso de privilegios;
i) uso de utilidades y aplicaciones del sistema;
j) archivos accedidos y tipo de acceso;
k) direcciones y protocolos de red;
l) alarmas levantadas por el sistema de control de acceso;
m) activación y desactivación de los sistemas de protección, tales como sistemas

antivirus y sistemas de detección de intrusos;
n) registros de las transacciones ejecutadas por los usuarios en las aplicaciones.
El registro de eventos establece las bases para los sistemas automatizados de monitoreo, que
son capaces de generar reportes consolidados y alertas en la seguridad del sistema.
Los registros de eventos pueden contener datos sensibles y datos personales. Deberían
tomarse medidas adecuadas de protección de la privacidad (véase 18.1.4).

PERUANA 90 de 162
Siempre que sea posible, los administradores de los sistemas no deberían tener permiso para
borrar o desactivar los registros de eventos de sus propias actividades (véase 12.4.3).
12.4.2 Protección de información de registros.
Control
Las instalaciones para registros (logs) y la información de los registros (logs) deberían estar
protegidas contra la adulteración y el acceso no autorizado.
Los controles deberían proteger contra cambios no autorizados y problemas operativos en

los medios de registro, incluyendo:
a) alteración a los tipos de mensajes que son registrados;
b) archivos de registros (logs) editados o eliminados;
c) capacidad de almacenamiento excedida en los medios de archivo de registro,

resultando en el registro fallido de eventos o en la sobrescritura de eventos
pasados registrados.
Algunos registros de auditoría pueden ser requeridos para ser archivados como parte de la
política de retención de registros o debido a requisitos para recolectar y retener evidencia
(véase 16.1.7).
Los registros del sistema a menudo contienen un vasto volumen de información, mucha de
la cual no tiene relación con el monitoreo de seguridad de información. Para ayudar a la
identificación de eventos significativos para el monitoreo de seguridad de la información,
debería considerarse el copiado automático de los tipos de mensajes apropiados a un registro
secundario o el uso de utilidades del sistema o herramientas de auditoría adecuadas para
realizar la consulta y racionalización de los archivos.
PERUANA 91 de 162
Los registros del sistema necesitan ser protegidos, debido a que si la información puede ser
modificada o eliminada, su existencia puede crear una falsa sensación de seguridad. Las
copias en tiempo real de los registros a un sistema fuera del control de un administrador u
operador del sistema, se pueden utilizar para proteger los registros.
12.4.3 Registros del administrador y del operador
Control
Las actividades del administrador del sistema y del operador del sistema deberían ser
registradas y los registros (logs) deberían estar protegidos y revisados regularmente.
Los titulares de las cuentas de usuario privilegiadas pueden ser capaces de manipular los
registros en las instalaciones de procesamiento de información bajo su control directo, por
lo tanto, es necesario proteger y revisar los registros mantenidos bajo la responsabilidad de
los usuarios privilegiados.
Un sistema de detección de intrusión, gestionado fuera del control de los administradores de

sistema y de red, puede ser utilizado para monitorear el cumplimiento de actividades de
administración del sistema y de la red.
12.4.4 Sincronización de reloj
Control
Los relojes de todos los sistemas de procesamiento de la información relevantes dentro de

una organización o dominio de seguridad deberían estar sincronizados a una fuente de
tiempo de referencia única.

PERUANA 92 de 162
Deberían documentarse los requisitos internos y externos de representación, sincronización

y precisión del tiempo. Tales requisitos pueden ser legales, regulatorios, contractuales, de
cumplimiento de las normas o requisitos para el monitoreo interno. Debería definirse un
estándar de tiempo de referencia para el uso dentro de la organización.
El enfoque de la organización para obtener un tiempo de referencia de una fuente externa y

la forma de sincronizar los relojes internos de manera fiable, debería estar documentado e
implementado.
La configuración correcta de relojes de las computadoras es importante para garantizar la

exactitud de los registros de auditoría, que pueden requerirse para investigaciones o como
evidencias en casos legales o disciplinarios. Los registros inexactos de auditoría pueden
dificultar tales investigaciones y restar credibilidad a tales evidencias. Un reloj vinculado a
una emisión de tiempo por ondas radiales desde un reloj nacional atómico puede ser usado
como el reloj maestro para los registros (logs) de los sistemas. Un protocolo de tiempo de
red puede utilizarse para mantener a todos los servidores en sincronización con el reloj
maestro.
12.5 Control del software operacional
Objetivo: asegurar la integridad de los sistemas operacionales
12.5.1 Instalación de software en sistemas operacionales
Control
Se deberían implementar procedimientos para controlar la instalación de software en

sistemas operacionales.

PERUANA 93 de 162
Deberían considerarse los siguientes lineamientos , en el control de cambio de software en

los sistemas en producción:
a) la actualización de software en producción, aplicaciones y bibliotecas de

programas sólo debería realizarse por administradores entrenados con la
apropiada autorización de la gerencia (véase 9.4.5);
b) los sistemas en producción deberían tener sólo código ejecutable aprobado y

no código de desarrollo o compiladores.
c) el software de aplicaciones y el de sistemas operativos deberían implantarse

sólo después de pruebas extensas y exitosas; las pruebas deberían cubrir
pruebas sobre usabilidad, seguridad, los efectos sobre otros sistemas y las
facilidades de usuario y deberían realizarse sobre sistemas separados (véase
12.1.4); debería asegurarse que todas las bibliotecas de programas fuentes
correspondientes han sido actualizadas;
d) debería utilizarse un sistema de control de configuración para mantener el

control de todo el software implementado así como la documentación del
sistema;
e) debería existir una estrategia de “vuelta atrás” antes de que los cambios sean
implementados;
f) debería mantenerse un registro de auditoría de todas las actualizaciones a las

bibliotecas de programa en producción;
g) debería retenerse la versión anterior de software de aplicación como una

medida de contingencia;
h) deberían archivarse las versiones antiguas de software, junto con toda la

información y parámetros requeridos, procedimientos, detalles de
configuración y el software de soporte mientras los datos son retenidos en el
archivo.
El software utilizado en producción suministrado por vendedores debería mantener un nivel

de soporte por el proveedor. Con el tiempo, los vendedores de software dejarán de dar
soporte a las versiones más antiguas de software. La organización debería considerar los
riesgos de confiar en el software sin soporte.
PERUANA 94 de 162
Cualquier decisión de actualización a una nueva versión debería tener en cuenta los
requisitos del negocio y la seguridad de la nueva versión, por ejemplo, la introducción de
una nueva funcionalidad de seguridad de la información o el número y severidad de
problemas de seguridad de la información que afectan dicha versión. Los parches de
software deberían aplicarse cuando puedan ayudar a quitar o reducir debilidades de
seguridad de la información (véase 12.6).
El acceso físico o lógico únicamente se debería proporcionar a los proveedores para

propósitos de soporte, cuando sea necesario y con aprobación de la gerencia. Las actividades
del proveedor deberían monitorearse (véase 15.2.1).
El software de computador puede depender de software y módulos suministrados

externamente, los cuales deberían ser monitoreados y controlados para evitar cambios no
autorizados que puedan introducir debilidades de seguridad.
12.6 Gestión de vulnerabilidad técnica
Objetivo: prevenir la explotación de vulnerabilidades técnicas
12.6.1 Gestión de vulnerabilidades técnicas
Control
Información sobre vulnerabilidades técnicas de los sistemas de información utilizados

debería ser obtenida de manera oportuna, la exposición de la organización a dichas
vulnerabilidades debería ser evaluada y las medidas apropiadas deberían ser tomadas para
resolver el riesgo asociado.
Un requisito previo para la gestión eficaz de vulnerabilidades técnicas es un inventario actual

y completo de activos (véase el capítulo 8). Información específica necesaria para apoyar la
gestión de vulnerabilidades técnicas, incluye al vendedor de software, números de versión,
el estado actual de despliegue (por ejemplo, qué software está instalado sobre qué sistemas)
y la(s) persona(s) responsable(s) del software dentro de la organización.
PERUANA 95 de 162
Acciones oportunas y apropiadas deberían tomarse en respuesta a la identificación de

potenciales vulnerabilidades técnicas. Las siguientes recomendaciones deberían seguirse
para establecer un proceso eficaz de gestión de vulnerabilidades técnicas:
a) la organización debería definir y establecer los roles y responsabilidades

asociados con la gestión de vulnerabilidades técnicas, incluyendo el
monitoreo de vulnerabilidades, la evaluación del riesgo de las
vulnerabilidades, la aplicación de parches, el seguimiento de activo y
cualquier responsabilidad de coordinación requerida;
b) los recursos de información que se van a utilizar para identificar las

vulnerabilidades técnicas relevantes y para mantener la concientización sobre
ellas deberían identificarse para el software y otra tecnología (basado en la
lista de inventario de activos, véase 8.1.1), estos recursos de información
deberían estar actualizados basándose en cambios del inventario o cuando son
encontrados otros recursos nuevos o útiles;
c) debería definirse un cronograma para reaccionar a las notificaciones de

vulnerabilidades técnicas potencialmente relevantes;
d) una vez que ha sido detectada una potencial vulnerabilidad técnica, la

organización debería identificar los riesgos asociados y las acciones a ser
tomadas; tal acción podría implicar el parchado de sistemas vulnerables o la
aplicación de otros controles;
e) dependiendo de cuan urgente tiene que ser abordada una vulnerabilidad

técnica, la acción a tomar debería realizarse según controles relacionados a la
gestión de cambio (véase 12.1.2) o según procedimientos de gestión de
incidentes de seguridad de la información (véase 16.1.5);
f) si está disponible un parche de una fuente legítima, los riesgos asociados con
la instalación del parche deberían evaluarse (los riesgos planteados por la
vulnerabilidad deberían compararse con el riesgo de instalar el parche);
g) los parches deberían probarse y evaluarse antes de ser instalados para

asegurarse que son eficaces y no causan efectos secundarios que no pueden
ser tolerados; si no está disponible ningún parche, deberían considerarse otros
controles, como:
1) desactivar servicios o capacidades relacionadas con la vulnerabilidad;

PERUANA 96 de 162
2) adaptar o agregar controles de acceso, por ejemplo: firewalls, en los

perímetros de la red (véase 13.1);
3) aumentar el monitoreo para descubrir ataques actuales;
4) fomentar conciencia de la vulnerabilidad;
h) debería mantenerse un registro de auditoría para todos los procedimientos

emprendidos;
i) debería monitorearse y evaluarse con regularidad el proceso de gestión de

vulnerabilidades técnicas para garantizar su eficacia y eficiencia;
j) debería abordarse primero los sistemas de alto riesgo;
k) un proceso eficaz de gestión de vulnerabilidades técnicas debería estar

alineado con las actividades de gestión de incidentes, para comunicar los
datos de las vulnerabilidades a la función de respuesta a incidentes y brindar
procedimientos técnicos a ser ejecutados en caso ocurra un incidente;
l) definir un procedimiento para abordar la situación donde ha sido identificada

la vulnerabilidad, pero no existe ninguna contramedida adecuada. En esta
situación, la organización debería evaluar los riesgos relacionados con la
vulnerabilidad conocida y definir las acciones de detección y las correctivas
adecuadas.
La gestión de vulnerabilidades técnicas puede ser vista como una sub-función de la gestión
de cambio y como tal puede aprovechar los procesos y procedimientos de gestión de cambio
(véase 12.1.2 y 14.2.2).
Los vendedores están a menudo bajo presión significativa de liberar parches cuanto antes.
Por lo tanto, un parche puede no gestionar el problema adecuadamente y puede tener efectos
secundarios negativos. También, en algunos casos, una vez que el parche es aplicado, puede
no ser fácilmente efectuada la desinstalación del mismo.

PERUANA 97 de 162
Si no son posibles las pruebas adecuadas de los parches, por ejemplo, debido a los costos o
carencia de recursos, puede considerarse, una demora en aplicar el parche, para evaluar los
riesgos asociados, basados en la experiencia reportada por otros usuarios. El uso de la Norma
ISO/IEC 27031 puede ser beneficioso.
12.6.2 Restricciones sobre la instalación de software
Control
Reglas que gobiernen la instalación de software por parte de los usuarios deberían ser
establecidas e implementadas.
La organización debería definir y hacer cumplir una política estricta sobre qué tipos de
software pueden instalar los usuarios.
Debería aplicarse el principio del menor privilegio. Si se les concede ciertos privilegios, los
usuarios pueden tener la capacidad de instalar software. La organización debería identificar
qué tipos de instalaciones de software son las permitidas (por ejemplo, actualizaciones y
parches de seguridad al software existente) y qué tipos de instalaciones se encuentran
prohibidas (por ejemplo, software que es sólo para uso personal y software cuyo origen
pueda ser potencialmente dañino, desconocido o sospechoso). Estos privilegios se deberían
conceder teniendo en cuenta los roles de los usuarios afectados.
La instalación no controlada de software en los dispositivos informáticos puede conducir a

la introducción de vulnerabilidades y luego a la fuga de información, pérdida de integridad
o de otros incidentes de seguridad de la información, o a la violación de los derechos de
propiedad intelectual.

PERUANA 98 de 162
12.7 Consideraciones para la auditoría de los sistemas de información
Objetivo: minimizar el impacto de las actividades de auditoría en los sistemas operacionales.
12.7.1 Controles de auditoría de sistemas de información
Control
Requisitos de las auditorías y las actividades que involucran la verificación de sistemas

operacionales deberían ser cuidadosamente planificados y acordados para minimizar la
interrupción a los procesos del negocio.
Las siguientes recomendaciones deberían tenerse en cuenta:
a) deberían acordarse los requisitos de auditoría para el acceso a los sistemas y

datos con la gerencia apropiada;
b) debería acordarse y controlarse el alcance de las pruebas técnicas de

auditorías;
c) las pruebas de auditoria debería hacerse limitando los accesos a sólo lectura
al software y a los datos;
d) otro acceso distinto a sólo lectura, solamente debería permitirse para copias
aisladas de archivos del sistema, que deberían borrarse cuando se complete la
auditoría o bien brindar la adecuada protección si hay obligación de mantener
tales archivos como requisito de documentación de la auditoría;
e) los requisitos para procesamientos especiales o adicionales deberían

identificarse y acordarse;
f) las pruebas de auditoria que podrían afectar la disponibilidad del sistema

deberían ejecutarse fuera de horario de trabajo;

PERUANA 99 de 162
g) todo acceso debería monitorearse y registrarse para producir trazabilidad.
13 Seguridad de las comunicaciones
13.1 Gestión de seguridad de la red
Objetivo: asegurar la protección de la información en las redes y sus instalaciones de

procesamiento de la información de apoyo.
13.1.1 Controles de la red
Control
Las redes deberían ser gestionadas y controladas para proteger la información en los sistemas
y las aplicaciones.
Se deberían implementar controles para garantizar la seguridad de la información en las

redes y la protección de los servicios conectados contra accesos no autorizados. En
particular, deberían considerarse los siguientes elementos:
a) las responsabilidades y procedimientos para la gestión de equipos de red

debería estar establecida;
b) la responsabilidad operacional de las redes debería separarse de las

operaciones de computo donde sea apropiado (véase 6.1.2);
c) deberían establecerse controles especiales para resguardar la confidencialidad

e integridad de los datos que pasan a través de redes públicas o sobre las redes
inalámbricas y para proteger los sistemas conectados y aplicaciones (véase
10 y 13.2); controles especiales también pueden ser necesarios para mantener
la disponibilidad de los servicios de red y computadoras conectadas;

PERUANA 100 de 162
d) el registro de ingresos y monitoreo adecuado debería aplicarse para permitir

la grabación y detección de acciones que pueden afectar o son relevantes para
la seguridad de la información;
e) las actividades de gestión deberían coordinarse estrechamente tanto para

optimizar el servicio a la organización como para garantizar que los controles
son aplicados consistentemente a través de la infraestructura de
procesamiento de la información;
f) los sistemas en la red deberían estar autenticados;
g) la conexión de sistemas a la red debería ser restringida.
Información adicional sobre seguridad de la red puede encontrarse en la norma

ISO/IEC 27033. [15] [16] [17] [18] [19]
13.1.2 Seguridad de servicios de red
Control
Mecanismos de seguridad, niveles de servicio y requisitos de gestión de todos los servicios

de red deberían ser identificados e incluidos en acuerdos de servicios de red, ya sea que estos
servicios se provean internamente o sean tercerizados.
La capacidad del proveedor del servicio de red para gestionar los servicios acordados de una
manera segura debería ser determinada y regularmente monitoreada y el derecho a auditar
debería ser acordado.
Las medidas de seguridad necesarias para los servicios particulares, tales como
características de seguridad, niveles de servicio y los requisitos de gestión, deberían estar
identificadas. La organización debería asegurarse que los proveedores de los servicios de red
implementan estas medidas.
PERUANA 101 de 162
Los servicios de red incluyen la provisión de conexiones, servicios de red privada y redes
con valor agregado y soluciones de seguridad de redes gestionadas como los firewalls y
sistemas de detección de intrusiones. Estos servicios pueden ir desde un simple ancho de
banda no gestionado hasta complejas ofertas con valor agregado.
Las características de seguridad de los servicios de red podrían ser:
a) tecnología aplicada para la seguridad de los servicios de red, como la

autenticación, encriptación y controles de conexión de red;
b) los parámetros técnicos necesarios para la conexión segura con los servicios
de red en concordancia con las reglas de seguridad y conexión a la red;
c) los procedimientos en el uso de servicios de red para restringir el acceso a los

servicios de red o aplicaciones, donde sea necesario.
13.1.3 Segregación en redes
Control
Grupos de servicios de información, usuarios y sistemas de información deberían estar

segregados en redes.
Un método para gestionar la seguridad de grandes redes es dividirlas en dominios de red

separados. Los dominios pueden ser elegidos basados en niveles de confianza (por ejemplo,
dominio de acceso público, dominio de escritorio de trabajo, dominio de servidor), a lo largo
de unidades organizativas (por ejemplo, recursos humanos, finanzas, marketing) o alguna
combinación (por ejemplo, el dominio servidor está conectado a múltiples unidades
organizacionales). La segregación puede hacerse utilizando redes físicamente diferentes o
mediante el uso de diferentes redes lógicas (por ejemplo, redes privadas virtuales).

PERUANA 102 de 162
El perímetro de cada dominio debería estar bien definido. Se permite el acceso entre
dominios de la red, pero debería ser controlado en el perímetro utilizando una puerta de
enlace (por ejemplo, cortafuegos, router con capacidad de filtrado). Los criterios para
segregación de redes en dominios y el acceso permitido a través de las puertas de enlace,
deberían basarse en una evaluación de los requisitos de seguridad de cada dominio. La
evaluación debería estar en concordancia con la política de control de acceso (véase 9.1.1),
los requisitos de acceso, el valor y clasificación de la información procesada y también tomar
en cuenta el impacto relativo de costos y rendimiento de incorporar tecnología adecuada de
puerta de enlace.
Las redes inalámbricas requieren un tratamiento especial debido a la deficiente definición

del perímetro de la red. Para ambientes sensibles, debería considerarse tratar todos los
accesos inalámbricos como conexiones externas y para segregar este acceso desde las redes
internas hasta que el acceso haya pasado a través de una puerta de enlace en concordancia
con la política controles de red (véase 13.1.1) antes de otorgar acceso a los sistemas internos.
Las tecnologías de control de acceso de autenticación, cifrado y de red a nivel de usuario de

las redes inalámbricas modernas basadas en estándares, pueden ser suficientes para la
conexión directa a la red interna de la organización cuando se implementa apropiadamente.
Las redes a menudo se extienden más allá de los límites de la organización, como a los
asociados de negocio formados para interconectarse o compartir las instalaciones de
procesamiento de información y redes. Tales extensiones pueden incrementar el riesgo de
acceso no autorizado a los sistemas de información de la organización que utilizan la red,
algunos de los cuales requieren protección de otros usuarios de la red debido a su sensibilidad
o criticidad.
13.2 Transferencia de información
Objetivo: mantener la seguridad de la información transferida dentro de una organización y

con cualquier entidad externa.

PERUANA 103 de 162
13.2.1 políticas y procedimientos de transferencia de la información
Control
Políticas, procedimientos y controles de transferencia formales deberían aplicarse para

proteger la transferencia de información a través del uso de todo tipo de instalaciones de
comunicación.
Los procedimientos y los controles a ser seguidos cuando utilizamos instalaciones de

comunicación para transferencia de información deberían considerar los siguientes puntos:
a) los procedimientos diseñados para proteger la información transferida de

interceptación, copia, modificación, rutas erróneas y la destrucción;
b) los procedimientos para la detección y protección contra software malicioso

que puede ser transmitido a través del uso de las comunicaciones electrónicas
(véase 12.2.1);
c) procedimientos para proteger la información electrónica sensible comunicada

que está en la forma de un archivo adjunto;
d) la política o lineamientos que describen el uso aceptable de instalaciones de

comunicación (véase 8.1.3);
e) las responsabilidades del personal, terceros y cualquier otro usuario que no

comprometa a la organización, por ejemplo a través de difamación, el acoso,
la suplantación, el reenvío de mensajes en cadena, compras no autorizadas,
entre otros;
f) el uso de técnicas criptográficas, por ejemplo para proteger la

confidencialidad, integridad y autenticidad de la información (véase el
capítulo 10);
g) los lineamientos de retención y eliminación para toda la correspondencia

comercial, incluyendo los mensajes, en concordancia con la legislación y
regulación nacional y local pertinentes;

PERUANA 104 de 162
h) los controles y restricciones asociadas con el uso de las instalaciones de

comunicación, por ejemplo, el reenvío automático del correo electrónico a las
direcciones de correo externas;
i) asesorar al personal a tomar las precauciones adecuadas para no revelar

información confidencial;
j) no dejar los mensajes que contienen información confidencial sobre los

contestadores automáticos dado que pueden ser reproducido por personas no
autorizadas, almacenar en sistemas comunitarios o almacenar de forma
incorrecta como el resultado de un marcado erróneo;
k) asesorar al personal sobre los problemas del uso de máquinas o servicios de

fax, como:
i) 1 el acceso no autorizado al almacenamiento de mensajes integrados

(embebidos) para recuperar los mensajes;
ii) 2 la programación deliberada o accidental de las máquinas para enviar

mensajes a números específicos;
iii) 3 el envío de documentos y mensajes a un número erróneo, ya sea por

marcar de forma equivocada o usar un número erróneo almacenado.
Además, el personal debería recordar que no deberían tener conversaciones confidenciales

en lugares público o sobre canales de comunicación inseguros, oficinas abiertas y lugares de
reunión.
Los servicios de transferencia de la información deberían cumplir con todos los requisitos
legales pertinentes (véase 18.1).
La transferencia de información se puede producir mediante el uso de un número de

diferentes tipos de medios de comunicación, incluyendo el correo electrónico, voz, fax y
video.

PERUANA 105 de 162
La transferencia de software puede ocurrir a través de un número de diferentes medios,

incluyendo la descarga desde el Internet y la adquisición a vendedores que venden productos
en caja.
Las implicaciones de negocio, legales y de seguridad asociados con el intercambio

electrónico de datos, el comercio electrónico y las comunicaciones electrónicas y deberían
considerarse los requisitos para sus controles.
13.2.2 Acuerdo sobre transferencia de información
Control
Los acuerdos deberían dirigir la transferencia segura de información del negocio entre la
organización y partes externas.
Los acuerdos de transferencia de información deberían incorporar lo siguiente:
a) las responsabilidades de gestión para el control y la notificación de

transmisión, despacho y recepción;
b) los procedimientos para garantizar la trazabilidad y el no repudio;
c) las normas técnicas mínimas para el empaquetado y transporte;
d) los acuerdos de fideicomiso;
e) las normas de identificación de mensajería;
f) las responsabilidades y obligaciones en caso de incidentes de seguridad de la

información, como la pérdida de datos;
g) el uso de un sistema de etiquetado acordado para la información sensible o

crítica, asegurando que el significado de las etiquetas se entiende de
inmediato y que la información está protegida adecuadamente (véase 8.2);

PERUANA 106 de 162
h) las normas técnicas para la grabación y lectura de la información y del

software;
i) cualquier control especial que se requiera para proteger items sensibles, como
la criptografía (véase el capítulo 10);
j) mantener una cadena de custodia para la información en tránsito;
k) los niveles aceptables de control de acceso.
Las políticas, procedimientos y normas deberían establecerse y mantenerse para proteger la

información y medios físicos en tránsito (véase 8.3.3) y se debería hacer referencia en cada
acuerdo de transferencia.
La seguridad de la información contenida en cualquier acuerdo debería reflejar la

sensibilidad de la información del negocio involucrada.
Los acuerdos pueden ser electrónicos o manuales y pueden adoptar la forma de contratos
formales. Para información confidencial, los mecanismos específicos usados para la
transferencia de cada información deberían ser coherentes para todas las organizaciones y
tipos de acuerdos.
13.2.3 Mensajes electrónicos
Control
La información involucrada en mensajería electrónica debería estar protegida

apropiadamente.
Las consideraciones de seguridad de la información para la mensajería electrónica deberían

incluir lo siguiente:
PERUANA 107 de 162
a) proteger los mensajes de acceso no autorizado, modificación o denegación de

servicio acorde con el sistema de clasificación adoptado por la organización;
b) garantizar la dirección correcta y el transporte del mensaje;
c) la fiabilidad y disponibilidad del servicio;
d) las consideraciones legales, por ejemplo, la obligación para las firmas

electrónicas;
e) obtener la aprobación previa a la utilización de los servicios públicos externos

como la mensajería instantánea, redes sociales o de archivos compartidos;
f) los niveles más fuertes de autenticación para controlar el acceso desde las
redes de acceso público.
Hay muchos tipos de mensajería electrónica como el correo electrónico, el intercambio

electrónico de datos y redes sociales que juegan un rol en las comunicaciones del negocio.
13.2.4 Acuerdos de confidencialidad o no divulgación
Control
Requisitos para los acuerdos de confidencialidad o no divulgación que reflejan las

necesidades de la organización para la protección de la información deberían estar
identificados, revisados regularmente y documentados.
Los acuerdos de confidencialidad o de no divulgación deberían abordar la necesidad de

proteger la información confidencial usando términos legalmente exigibles. Los acuerdos de
confidencialidad o de no divulgación son aplicables a las partes externas o empleados de la
organización. Sus elementos deberían ser seleccionados o añadidos teniendo en cuenta el
tipo de la otra parte y su acceso permisible o el manejo de información confidencial. Para

PERUANA 108 de 162
identificar los requisitos de los acuerdos de confidencialidad o de no divulgación, los

siguientes elementos deberían ser considerados:
a) una definición de la información a proteger (por ejemplo, información

confidencial);
b) la duración prevista de un acuerdo, incluyendo los casos en que la

confidencialidad podría necesitar ser mantenida indefinidamente;
c) las acciones requeridas cuando se termina un acuerdo;
d) las responsabilidades y las acciones de los firmantes para evitar la divulgación

no autorizada de la información;
e) la propiedad de la información, los secretos comerciales y la propiedad

intelectual y cómo esto se relaciona con la protección de la información
confidencial;
f) el uso permitido de la información confidencial y los derechos de los

firmantes para utilizar la información;
g) el derecho de auditar y monitorear las actividades que involucran información

confidencial;
h) el proceso para la notificación y reporte de la divulgación no autorizada o

fuga de información confidencial;
i) los términos para la devolución o destrucción de la información al cese del

acuerdo;
j) las acciones esperadas a ser tomadas en caso de incumplimiento del acuerdo.
Sobre la base de los requisitos de seguridad de la información de una organización, pueden

ser necesarios otros elementos en un acuerdo de confidencialidad o de no divulgación.
Los acuerdos de confidencialidad y no divulgación deberían cumplir con todas las leyes y
regulaciones aplicables para la jurisdicción a la que se aplican (véase 18.1).

PERUANA 109 de 162
Los requisitos para los acuerdos de confidencialidad y no divulgación deberían ser revisados
periódicamente y cuando se producen cambios que influencien estos requisitos.
Los acuerdos de confidencialidad y no divulgación protegen la información de la

organización e informan a los firmantes de sus responsabilidades para proteger, usar y
divulgar información de manera responsable y autorizada.
Puede haber una necesidad de una organización en utilizar diferentes formas para sus
acuerdos de confidencialidad o de no divulgación en diferentes circunstancias.
14 Adquisición, desarrollo y mantenimiento de sistemas
14.1 Requisitos de seguridad de los sistemas de información
Objetivo: garantizar que la seguridad de la información es una parte integral de los sistemas
de información a través del ciclo de vida completo. Esto también incluye los requisitos para
sistemas de información que proporcionen servicios sobre redes públicas.
14.1.1 Análisis y especificación de requisitos de seguridad de la información
Control
Requisitos relacionados a la seguridad de la información deberían ser incluidos dentro de los

requisitos para nuevos sistemas de información o mejoras a los sistemas de información
existentes.

PERUANA 110 de 162
Los requisitos de seguridad de la información deberían identificarse utilizando varios

métodos, tales como los requisitos derivados del cumplimiento de las políticas y
reglamentos, modelado de amenazas, revisiones de incidentes o el uso de umbrales de
vulnerabilidad. Los resultados de la identificación deberían documentarse y revisarse por
todas las partes interesadas.
Los requisitos y controles de seguridad deberían reflejar el valor para el negocio del activo
de información involucrado (véase 8.2) y el potencial impacto negativo para el negocio, que
podría ser resultado de una ausencia de seguridad adecuada.
La identificación y gestión de los requisitos de seguridad de la información y los procesos

asociados deberían ser integrados en las etapas tempranas de proyectos de sistema de
información. La consideración temprana de los requisitos de seguridad de la información,
por ejemplo, en la etapa de diseño, puede dar lugar a soluciones más eficaces y eficientes en
costos.
Los requisitos de seguridad de la información deberían considerar también:
a) el nivel de confianza requerido hacia la identidad declarada por el usuario, a

fin de derivar los requisitos de autenticación del usuario;
b) la provisión del acceso y procesos de autorización, para los usuarios del

negocio así como para los usuarios privilegiados o técnicos;
c) informar a los usuarios y operadores de sus deberes y responsabilidades;
d) las necesidades de protección requeridas de los activos involucrados, en

particular en relación con la disponibilidad, la confidencialidad y la
integridad;
e) los requisitos derivados de los procesos del negocio, tales como el registro de
transacciones y monitoreo, requisitos de no-repudio;
f) los requisitos ordenados por otros controles de seguridad, por ejemplo,

interfaces para el registro y monitoreo o los sistemas de detección de fuga de
datos.

PERUANA 111 de 162
Para las aplicaciones que proporcionan servicios sobre redes públicas o que implementan
transacciones, deberían considerarse controles dedicados véase14.1.2 y 14.1.3.
Si se adquieren productos, debería seguirse un proceso de pruebas y adquisición formal. Los

contratos con el proveedor deberían abordar los requisitos de seguridad identificados. Donde
la funcionalidad de seguridad en un producto propuesto no satisface el requisito
especificado, entonces el riesgo introducido y los controles asociados deberían
reconsiderarse antes de la compra del producto.
Deberían evaluarse e implantarse guías disponibles para la configuración de seguridad de

productos alineadas con el sistema final que incluye software/servicio.
Deberían definirse los criterios para la aceptación de productos, por ejemplo, en términos de
su funcionalidad, que garanticen que se cumplen los requisitos de seguridad identificados.
Los productos deberían evaluarse en relación con estos criterios antes de la adquisición. La
funcionalidad adicional debería ser revisada para asegurarse que no presenta riesgos
adicionales inaceptables.
Las Normas ISO/IEC 27005 e ISO 31000 proporcionan orientación sobre el uso de los
procesos de gestión del riesgo para identificar los controles que cumplan con los requisitos
de seguridad de la información.
14.1.2 Aseguramiento de servicios de aplicaciones sobre redes públicas
Control
La información involucrada en servicios de aplicaciones que pasa sobre redes públicas

debería estar protegida de actividad fraudulenta, disputa de contratos o divulgación no
autorizada y modificación.

PERUANA 112 de 162
Las consideraciones de seguridad de la información para los servicios de aplicación que

pasan a través de las redes públicas deberían incluir lo siguiente:
a) el nivel de confianza requerido por cada parte en cada una de las otras
identidades declaradas, por ejemplo, a través de la autenticación;
b) los procesos de autorización asociados con quién puede aprobar el contenido

de, emitir o firmar los documentos transaccionales clave;
c) garantizar que los socios de comunicaciones son plenamente informados de

sus autorizaciones para la prestación o uso del servicio;
d) determinar y cumplir los requisitos de confidencialidad, integridad, prueba de

envío y recepción de documentos clave y el no repudio de contratos, por
ejemplo, asociados con los procesos de licitación y contratos;
e) el nivel de confianza requerido en la integridad de los documentos clave;
f) los requisitos de protección de la información confidencial;
g) la confidencialidad y la integridad de las transacciones de pedidos,

información de pago, detalles de la dirección de entrega y la confirmación de
recibos;
h) el grado de verificación adecuado para verificar la información de pago

suministrada por el cliente;
i) la selección del formulario de liquidación de pago más adecuado para evitar

el fraude;
j) el nivel de protección requerido para mantener la confidencialidad y la

integridad de la información del pedido;
k) la prevención de la pérdida o duplicación de la información de transacción;
l) la responsabilidad asociada con cualquier transacción fraudulenta;
m) los requisitos del seguro.

PERUANA 113 de 162
Muchas de las consideraciones anteriores pueden ser abordadas mediante la aplicación de

controles criptográficos (véase el capítulo 10), teniendo en cuenta el cumplimiento de los
requisitos legales (véase el capítulo 18, especialmente véase 18.1.5 para legislación sobre
criptografía).
Los acuerdos de servicios de aplicaciones entre socios deberían estar respaldados por un
acuerdo documentado que compromete a ambas partes a los términos acordados de servicios,
incluyendo los detalles de la autorización (véase b anterior).
Deberían considerarse los requisitos de resiliencia frente a ataques, que pueden incluir
requisitos para la protección de los servidores de aplicación involucrados o garantizar la
disponibilidad de las interconexiones de red requeridas para prestar el servicio.
Las aplicaciones accesibles a través de redes públicas están sujetas a una serie de amenazas
relacionadas con las redes, tales como las actividades fraudulentas, disputas contractuales o
divulgación de la información al público. Por lo tanto, las evaluaciones de riesgo detalladas
y la selección adecuada de controles son indispensables. Los controles requeridos a menudo
incluyen, métodos criptográficos para autenticación y asegurar la transferencia de datos.
Los servicios de aplicación pueden hacer uso de los métodos de autenticación seguros, por
ejemplo, utilizando criptografía pública clave y firmas digitales (véase el capítulo 10) para
reducir los riesgos. Además, se puede usar tercerización confiable, donde sea necesario para
cada servicio.
14.1.3 Protección de transacciones en servicios de aplicación
Control
La información involucrada en las transacciones de servicios de aplicación debería estar

protegida para prevenir transmisión incompleta, ruteo incorrecto, alteración no autorizada
de mensajes, divulgación no autorizada, duplicación o respuesta no autorizada de mensajes.

PERUANA 114 de 162
Las consideraciones de seguridad de la información para transacciones de servicios de

aplicación deberían incluir lo siguiente:
a) el uso de firmas electrónicas por cada una de las partes implicadas en la

transacción;
b) todos los aspectos de la transacción, es decir garantizar que:
1) la información secreta de autenticación de usuario de todas las partes son

válidas y verificadas;
2) la transacción permanece confidencial;
3) la privacidad asociada con todas las partes involucradas es retenida;
c) el canal de comunicación entre todas las partes involucradas está cifrado;
d) el protocolo utilizado para comunicarse entre todas las partes implicadas está
asegurado;
e) garantizar que el almacenamiento de los detalles de transacción es localizado

fuera de cualquier ambiente de acceso público, por ejemplo en una plataforma
de almacenamiento que existe en la Intranet de la organización, no retenido y
expuesto en un medio de almacenamiento directamente accesible desde
Internet;
f) cuando se emplea una autoridad confiable (por ejemplo, para propósitos de

emitir y mantener firmas digitales y/o certificados digitales) la seguridad se
integra e incorpora a través de todo el proceso completo de gestión del
certificado / firma.
La extensión de los controles adoptados necesita ser proporcional con el nivel del riesgo
asociado con cada formulario de transacción del servicio de aplicación.

PERUANA 115 de 162
Las transacciones pueden necesitar cumplir con los requisitos legales y regulatorios de la
jurisdicción en la cual la transacción es generada, procesada, completada, y/o almacenada.
14.2 Seguridad en los procesos de desarrollo y soporte
Objetivo: garantizar que la seguridad de la información esté diseñada e implementada dentro

del ciclo de vida de desarrollo de los sistemas de información.
14.2.1 Política de desarrollo seguro
Control
Reglas para el desarrollo de software y sistemas deberían estar establecidas y aplicadas a

desarrollos dentro de la organización.
El desarrollo seguro es un requisito para construir un servicio, arquitectura, software y

sistema seguros. Dentro de una política de desarrollo seguro, los siguientes aspectos deberían
someterse a consideración:
a) la seguridad del ambiente de desarrollo;
b) la orientación sobre la seguridad en el ciclo de vida del desarrollo de software:
1) seguridad en la metodología de desarrollo de software;
2) fijar los lineamientos de codificación segura para cada lenguaje de

programación utilizado;
c) los requisitos de seguridad en la etapa de diseño;
d) los puntos de control de seguridad dentro de los hitos del proyecto;
e) los repositorios seguros;

PERUANA 116 de 162
f) la seguridad en el control de versiones;
g) el conocimiento requerido de seguridad de las aplicaciones;
h) la capacidad de los desarrolladores para evitar, encontrar y corregir

vulnerabilidades.
Las técnicas de programación segura deberían utilizarse tanto para los nuevos desarrollos
como en escenarios de reutilización de código donde las normas aplicables al desarrollo
pudieron no ser conocidas o no fueron consistentes con las mejoras prácticas actuales. Las
normas de codificación segura deberían considerarse y cuando corresponda, utilizadas. Los
desarrolladores deberían ser capacitados en su uso y pruebas y cuando se revise el código se
debería verificar su uso.
Si el desarrollo es subcontratado, la organización debería obtener garantías de que el tercero

cumpla con estas reglas de desarrollo seguro (véase 14.2.7).
El desarrollo también puede tener lugar dentro de las aplicaciones, tales como las
aplicaciones de oficina, scripting, navegadores y bases de datos.
14.2.2 Procedimientos de control de cambio del sistema
Control
Cambios a los sistemas dentro del ciclo de vida del desarrollo deberían estar controlados por
medio del uso de procedimientos formales de control de cambios.
Para garantizar la integridad del sistema, las aplicaciones y los productos, desde las primeras
etapas de diseño y a través de todos los esfuerzos de mantenimiento posteriores, deberían
documentarse y hacerse cumplir los procedimientos formales de control de cambio. La

PERUANA 117 de 162
introducción de nuevos sistemas y cambios importantes a sistemas existentes deberían seguir

un proceso formal de documentación, especificación, pruebas, control de calidad y de
gestión de la implementación.
Este proceso debería incluir una evaluación de riesgo, el análisis de los impactos de los
cambios y la especificación de los controles de seguridad necesarios. Este proceso también
debería garantizar que los procedimientos existentes de seguridad y control no son
comprometidos, que a los programadores de apoyo se les da el acceso sólo a aquellas partes
del sistema necesario para su trabajo y que un acuerdo formal y la aprobación para cualquier
cambio son obtenidos.
De ser practicable, los procedimientos de control de cambio operacionales y de aplicación

deberían integrarse (véase 12.1.2). Los procedimientos de control de cambio deberían
incluir, pero no limitarse a:
a) el mantenimiento de un registro de niveles de autorización acordados;
b) garantizar que los cambios son efectuados por usuarios autorizados;
c) la revisión de los controles y procedimientos de integridad para garantizar que

no serán comprometidos por los cambios;
d) identificar todo el software, la información, entidades de base de datos y el

hardware que requieran enmienda;
e) identificar y verificar el código crítico de seguridad para reducir al mínimo la

probabilidad de las debilidades de seguridad conocidas;
f) obtener la aprobación formal para propuestas detalladas antes de que

comience el trabajo;
g) garantizar que los usuarios autorizados acepten los cambios antes de la

implementación;
h) garantizar que al terminar cada cambio la documentación de sistema es

actualizada y que la antigua documentación está archivada o puesta a
disposición;
i) el mantenimiento de un control de versiones de todas las actualizaciones de

software;

PERUANA 118 de 162
j) el mantenimiento de una pista de auditoría de todo cambio solicitado;
k) garantizar que la documentación de operaciones (véase 12.1.1) y los

procedimientos de usuario son cambiados según sea necesario para
permanecer adecuados;
l) garantizar que la implementación de cambios ocurra en el momento adecuado

y no interfiera los procesos de negocio involucrados.
El cambio del software puede afectar el ambiente de producción y viceversa.
Las buenas prácticas incluyen las pruebas del software nuevo en un ambiente segregado
tanto del ambiente de producción como del ambiente de desarrollo (véase 12.1.4). Esto
proporciona un medio para tener el control sobre el nuevo software y permitir protección
adicional a la información de producción que es utilizada para hacer pruebas. Esto debería
incluir parches, service packs y otras actualizaciones.
Cuando se consideran actualizaciones automáticas, el riesgo para la integridad y

disponibilidad del sistema debería sopesarse frente al beneficio del rápido despliegue de las
actualizaciones. Las actualizaciones automatizadas no deberían usarse sobre sistemas
críticos, ya que algunas actualizaciones pueden hacer que fallen aplicaciones críticas.
14.2.3 Revisión técnica de aplicaciones después de cambios a la plataforma

operativa
Control
Cuando se cambian las plataformas operativas, las aplicaciones críticas para el negocio
deberían ser revisadas y probadas para asegurar que no haya impacto adverso en las
operaciones o en la seguridad de la organización.

PERUANA 119 de 162
Este proceso debería cubrir:
a) la revisión de los controles de aplicación y procedimientos de integridad para

garantizar que ellos no han sido comprometidos por los cambios en la
plataforma operativa;
b) garantizar que la notificación de cambios a la plataforma operativa es

proporcionada a tiempo para permitir que ocurran pruebas y revisiones
apropiadas antes de la implementación;
c) garantizar que los cambios apropiados son hechos en los planes de

continuidad de negocio (véase el capítulo 17).
Las plataformas operativas incluyen a los sistemas operativos, las bases de datos y
plataformas de middleware. El control debería aplicarse a los cambios en las aplicaciones.
14.2.4 Restricciones sobre cambios a los paquetes de software
Control
Modificaciones a los paquetes de software deberían ser disuadidas, limitadas a los cambios
necesarios y todos los cambios deberían ser estrictamente controlados.
En la medida de lo posible y practicable, los paquetes de software, suministrados por

vendedores, deberían utilizarse sin modificación. Cuando un paquete de software necesite
ser modificado deberían considerarse los siguientes puntos:

PERUANA 120 de 162
a) el riesgo de comprometer los controles integrados () y los procesos de

integridad;
b) si el consentimiento del proveedor debería ser obtenido;
c) la posibilidad de obtener los cambios requeridos del vendedor como

actualizaciones estándar del programa;
d) el impacto ocasionado, si la organización se hace responsable por el futuro

mantenimiento del software como consecuencia de los cambios;
e) la compatibilidad con otro software en uso.
Si los cambios son necesarios el software original debería retenerse y los cambios aplicados
a una copia claramente identificada. Un proceso de gestión de actualización de software
debería implementarse para garantizar que los parches más actualizados aprobados y
actualizaciones de aplicación son instalados para todo el software autorizado (véase 12.6.1).
Todos los cambios deberían ser totalmente probados y documentados, de modo que ellos
puedan ser vueltos a aplicar si fuera necesario a futuras mejoras de software. De ser
requerido, las modificaciones deberían probarse y validarse por un equipo de evaluación
independiente.
14.2.5 Principios de ingeniería de sistemas seguros
Control
Principios para la ingeniería de sistemas seguros deberían ser establecidos, documentados,

mantenidos y aplicados a cualquier esfuerzo de implementación de sistemas de información.
Los procedimientos de la ingeniería de sistemas de información seguros basados en los

principios de ingeniería de seguridad, deberían establecerse, documentarse y aplicarse a las
actividades internas de ingeniería de sistemas de información. La seguridad debería
diseñarse en todas las capas de arquitectura (negocios, datos, aplicaciones y tecnología)
equilibrando la necesidad de seguridad de la información con la necesidad de accesibilidad.
Debería analizarse la nueva tecnología para los riesgos de seguridad y el diseño debería
revisarse contra patrones de ataque conocidos.
PERUANA 121 de 162
Estos principios y procedimientos de ingeniería establecidos deberían revisarse

regularmente, para garantizar que están contribuyendo eficazmente a mejorar las normas de
seguridad dentro del proceso de ingeniería. Estos también deberían revisarse periódicamente
para garantizar que permanezcan actualizados en cuanto a la lucha contra las nuevas
amenazas potenciales y que sigan siendo aplicables a los avances en las tecnologías y
soluciones a ser aplicadas.
Los principios establecidos de ingeniería de la seguridad deberían aplicarse, cuando

corresponda, a los sistemas de información subcontratados a través de contratos y de otros
acuerdos vinculantes entre la organización y el proveedor que contrata la organización. La
organización debería confirmar que el rigor de los principios de ingeniería de seguridad de
los proveedores es comparable con el propio.
Los procedimientos de desarrollo de aplicaciones deberían aplicar técnicas seguras de

ingeniería en el desarrollo de aplicaciones con interfaces de entrada y salida. Las técnicas
seguras de ingeniería proporcionan una orientación sobre las técnicas de autenticación, el
control seguro de sesión y la validación de datos, la limpieza y la eliminación de códigos
depurables.
14.2.6 Ambiente de desarrollo seguro
Control
Las organizaciones deberían establecer y proteger apropiadamente los ambientes de

desarrollo seguros para los esfuerzos de desarrollo e integración de sistemas que cubren todo
el ciclo de vida del desarrollo del sistema.
Un ambiente de desarrollo seguro incluye personas, procesos y tecnología asociados con el

desarrollo y la integración de los sistemas.

PERUANA 122 de 162
Las organizaciones deberían evaluar los riesgos asociados con los esfuerzos individuales de
desarrollo del sistema y establecer ambientes de desarrollo seguro para esfuerzos de
desarrollo de sistemas específicos, considerando:
a) sensibilidad de los datos a ser procesados, almacenados y transmitidos por el

sistema;
b) requisitos externos e internos aplicables, por ejemplo, de regulaciones o

políticas;
c) los controles de seguridad ya implementados por la organización que apoyan

el desarrollo del sistema;
d) la confiabilidad del personal que trabaja en el ambiente (véase 7.1.1);
e) el grado de contratación externa asociado con el desarrollo del sistema;
f) la necesidad de segregación entre los diferentes ambientes de desarrollo;
g) el control de acceso al ambiente de desarrollo;
h) monitoreo del cambio al ambiente y el código almacenado en el mismo;
i) los respaldos son almacenados en locaciones seguras fuera de las

instalaciones;
j) el control sobre el movimiento de los datos desde y hacia éste ambiente.
Una vez que el nivel de protección es determinado para un ambiente de desarrollo específico,
las organizaciones deberían documentar los procesos correspondientes de los
procedimientos de desarrollo seguro y proporcionarlos a todas las personas que los necesiten.
14.2.7 Desarrollo contratado externamente
Control
La organización debería supervisar y monitorear la actividad de desarrollo de sistemas

contratado externamente.

PERUANA 123 de 162
Cuando el desarrollo del sistema es subcontratado, deberían considerarse los siguientes

puntos en toda la cadena de suministro externa de la organización:
a) los acuerdos de licencias, la propiedad del código y los derechos de propiedad

intelectual relacionado con el contenido tercerizado (véase 18.1.2);
b) los requisitos contractuales para el diseño, la codificación y las prácticas de

pruebas seguros (véase 14.2.1);
c) el suministro del modelo de amenazas aprobado para el desarrollador externo;
d) aceptación de pruebas de calidad y precisión de los entregables;
e) la provisión de evidencia de que se utilizaron umbrales de seguridad para

establecer los niveles mínimos aceptables de seguridad y calidad de la
privacidad;
f) la provisión de evidencia de que se han aplicado suficientes pruebas para

proteger contra la ausencia de contenido maliciosos intencional y no
intencional en la entrega;
g) la presentación de evidencia de que se han realizado suficientes pruebas para

proteger contra la presencia de vulnerabilidades conocidas;
h) los acuerdos de custodia (escrow), por ejemplo, si el código fuente ya no está

disponible;
i) el derecho contractual de auditar procesos y controles de desarrollo;
j) la documentación efectiva del ambiente construido utilizado para crear los

entregables;
k) la organización mantiene la responsabilidad de cumplir con las leyes

aplicables y la verificación de la eficacia del control.

PERUANA 124 de 162
Se puede encontrar más información sobre las relaciones con los proveedores en la Norma
ISO/IEC 27036.
14.2.8 Pruebas de seguridad del sistema
Control
Pruebas de funcionalidad de la seguridad deberían ser llevadas a cabo durante el desarrollo.
Los sistemas nuevos y actualizados requieren pruebas exhaustivas y verificación durante los
procesos de desarrollo, incluyendo la preparación de un programa detallado de actividades
y los insumos de pruebas y los resultados esperados bajo una serie de condiciones. En cuanto
a los desarrollos internos, cada prueba debería realizarse inicialmente por parte del equipo
de desarrollo. Las pruebas de aceptación independientes deberían realizarse (tanto para el
desarrollo interno como para el subcontratado) para garantizar que el sistema funciona como
se esperaba y sólo como se esperaba (véase 14.1.1 y 14.2.9). La extensión de las pruebas
debería ser proporcional a la importancia y naturaleza del sistema.
14.2.9 Pruebas de aceptación del sistema
Control
Programas de pruebas de aceptación y criterios relacionados deberían ser establecidos para

nuevos sistemas de información, actualizaciones y nuevas versiones.

PERUANA 125 de 162
Las pruebas de aceptación del sistema deberían incluir las pruebas de los requisitos de
seguridad de la información (véase 14.1.1 y 14.1.2) y la adherencia para asegurar las
prácticas de desarrollo del sistema (véase 14.2.1). Las pruebas deberían también ser llevadas
a cabo en los componentes recibidos y a los sistemas integrados. Las organizaciones pueden
aprovechar las herramientas automatizadas, tales como las herramientas de análisis de
códigos o escáneres de vulnerabilidad y deberían verificar que los defectos relacionados con
la seguridad son corregidos.
Las pruebas deberían realizarse en un ambiente de prueba real para asegurarse que el sistema
no va a introducir vulnerabilidades en el ambiente de la organización y que las pruebas son
confiables.
14.3 Datos de prueba
Objetivo: asegurar la protección de datos utilizados para las pruebas
14.3.1 Protección de datos de prueba
Control
Los datos de prueba deberían ser seleccionados cuidadosamente, protegidos y controlados.
Debería evitarse el uso de los datos para producción que contengan información de datos
personales o cualquier otra información confidencial para fines de prueba. Si se utiliza
información de datos personales o cualquier otra información confidencial para hacer
pruebas, todo el contenido y detalles sensibles deberían protegerse contra eliminación o
modificación (véase ISO/IEC 29101).
Los siguientes lineamientos deberían aplicarse para proteger los datos para producción
cuando son utilizados para propósitos de pruebas:
PERUANA 126 de 162
a) los procedimientos de control de acceso, que se aplican a sistemas de

aplicaciones de producción, deberían aplicarse también a los sistemas de
prueba de aplicaciones;
b) debería autorizarse por separado, cada vez que se copie la información de

producción a un ambiente de prueba;
c) debería borrarse la información de producción de un sistema de prueba de

aplicación inmediatamente después de que las pruebas sean completadas;
d) debería registrarse la copia y uso de información de producción para

proporcionar una pista de auditoría.
Las pruebas de sistema y de aceptación requieren, por lo general, volúmenes sustanciales de

datos de prueba que sean tan cercanos como sea posible a datos de producción.
15 Relaciones con los proveedores
15.1 Seguridad de la información en las relaciones con los proveedores
Objetivo: asegurar protección a los activos de la organización que son accesibles por los
proveedores
15.1.1 Política de seguridad de la información para las relaciones con los

proveedores
Control
Requisitos de seguridad de la información para mitigar los riesgos asociados con el acceso
por parte del proveedor a los activos de la organización deberían ser acordados con el
proveedor y documentados.

PERUANA 127 de 162
Las organizaciones deberían identificar y ordenar los controles de seguridad de la

información para abordar específicamente en una política el acceso del proveedor a la
información de la organización. Estos controles deberían abordar los procesos y
procedimientos a ser implementados por la organización, así como aquellos procesos y
procedimientos que la organización debería requerir que el proveedor implemente,
incluyendo:
a) identificar y documentar los tipos de proveedores, por ejemplo, servicios de

TI, servicios de logística, servicios financieros, componentes de la
infraestructura de TI, a quien la organización permitirá acceder a su
información;
b) un proceso estandarizado y el ciclo de vida para la gestión de relaciones con

los proveedores;
c) definir los tipos de acceso a la información al que van a tener los diferentes
tipos de proveedores, así como supervisar y controlar el acceso;
d) los requisitos de seguridad de la información mínimos para cada tipo de

información y tipo de acceso para servir como base para los acuerdos
individuales con los proveedores basados en las necesidades y requisitos de
negocios de la organización y su perfil de riesgo;
e) los procesos y procedimientos para el seguimiento de la adherencia a los

requisitos de seguridad de la información establecidos para cada tipo de
proveedor y tipo de acceso, incluyendo la revisión a terceros y la validación
de los productos;
f) los controles sobre exactitud y completitud para garantizar la integridad de la

información o del procesamiento de información proporcionado por cualquier
tercero;
g) los tipos de obligaciones aplicables a los proveedores para proteger la

información de la organización;
h) el manejo de incidentes y contingencias asociadas con el acceso de los

proveedores, incluyendo las responsabilidades tanto de la organización como
de los proveedores;

PERUANA 128 de 162
i) la resiliencia, y, si es necesario, los acuerdos de recuperación y contingencia

para garantizar la disponibilidad de la información o del procesamiento de
información proporcionado por cualquiera de los terceros;
j) la capacitación para generar conciencia en el personal de la organización

involucrado en las adquisiciones respecto a políticas, procesos y
procedimientos aplicables;
k) la capacitación para generar conciencia en el personal de la organización que

interactúa con el personal de los proveedores, respecto a las reglas apropiadas
de compromiso y comportamiento basado en el tipo de proveedor y en el nivel
de acceso de los proveedores a los sistemas e información de la organización;
l) las condiciones sobre cuales requisitos y controles de seguridad de la

información estarán documentados en un acuerdo firmado por ambas partes;
m) la gestión de las transiciones necesarias de información, instalaciones de

procesamiento de información y de cualquier otra cosa que necesite ser
movida y la garantía de que la seguridad de la información se mantiene
durante todo el período de transición.
Los proveedores con inadecuada gestión de seguridad de la información pueden poner en

riesgo la información. Deberían identificarse y aplicarse los controles para administrar el
acceso del proveedor a las instalaciones de procesamiento de información. Por ejemplo, si
hay una necesidad especial de confidencialidad de la información, se pueden utilizar
acuerdos de no divulgación. Otro ejemplo son los riesgos de protección de datos cuando el
acuerdo con el proveedor involucra la transferencia de o el acceso a, información a través de
las fronteras. La organización necesita ser consciente de que la responsabilidad legal o
contractual para proteger la información permanece dentro de la misma.
15.1.2 Abordar la seguridad dentro de los acuerdos con proveedores
Control
Todos los requisitos relevantes de seguridad de la información deberían ser establecidos y

acordados con cada proveedor que pueda acceder, procesar, almacenar, comunicar o proveer
componentes de infraestructura de TI para la información de la organización
PERUANA 129 de 162
Deberían establecerse y documentarse acuerdos con los proveedores para garantizar que no
hay malentendidos entre la organización y los proveedores respecto a las obligaciones de
ambas partes para cumplir con los requisitos relevantes de seguridad de la información.
Deberían considerarse la inclusión de los siguientes términos en los acuerdos con el fin de
satisfacer los requisitos de seguridad identificados:
a) descripción de la información a ser proporcionada o accedida y los métodos

para proporcionar o acceder a la información;
b) clasificación de la información de acuerdo con el esquema de clasificación de

la organización (véase 8.2); si es necesario también, el mapeo entre el
esquema de clasificación propio de la organización y el esquema de
clasificación del proveedor;
c) los requisitos legales y regulatorios, incluyendo la protección de datos, los

derechos de propiedad intelectual y los derechos de autor y una descripción
de cómo se va a garantizar que se cumplan;
d) la obligación de cada parte contractual para implementar un conjunto

acordado de controles incluyendo el control de acceso, la revisión del
desempeño, monitoreo, reporte y auditoría;
e) reglas para el uso aceptable de la información, incluyendo el uso inaceptable

si es necesario;
f) cualquier lista explícita del personal autorizado del proveedor a acceder o

recibir información de la organización o procedimientos o condiciones para
la autorización, el retiro de la autorización, para el acceso o para recibir
información de la organización por parte del personal del proveedor;
g) las políticas de seguridad de la información relevante para contratos

específicos;
h) los requisitos y procedimientos de gestión de incidentes (especialmente

notificación y colaboración durante la remediación de incidentes);

PERUANA 130 de 162
i) los requisitos de capacitación y creación de conciencia para procedimientos

específicos y requisitos de seguridad de la información, por ejemplo, para la
respuesta ante incidentes, procedimientos de autorización;
j) las regulaciones relevantes para la subcontratación, incluyendo los controles

que necesiten implementarse;
k) los socios con acuerdos relevantes, incluyendo a una persona de contacto para
los asuntos de seguridad de la información;
l) si cualquier requisito de selección, para el personal de los proveedores

incluyen responsabilidades para conducir la selección y los procedimientos
de notificación si la selección no ha sido completada o si los resultados son
motivo de duda o preocupación;
m) el derecho a auditar los procesos y controles de los proveedores relacionados

con el acuerdo;
n) la resolución de defectos y los procesos de resolución de conflictos;
o) la obligación del proveedor de suministrar periódicamente un reporte

independiente sobre la efectividad de los controles y un acuerdo sobre la
corrección oportuna de las cuestiones relevantes planteadas en el reporte;
p) las obligaciones del proveedor para cumplir con los requisitos de seguridad
de la organización.
Los acuerdos pueden variar considerablemente para diferentes organizaciones y entre

distintos tipos de proveedores. Por lo tanto, debería tenerse cuidado con incluir todos los
riesgos y requisitos de seguridad de la información relevantes. Los acuerdos con proveedores
también pueden involucrar a otras partes (por ejemplo, a subcontratistas).
Los procedimientos para continuar el procesamiento en el caso de que el proveedor se vuelva

incapaz de suministrar sus productos o servicios necesitan ser considerados en el acuerdo
para evitar cualquier retraso en ordenar los productos o servicios de reemplazo.

PERUANA 131 de 162
15.1.3 Cadena de suministro de tecnología de información y comunicación
Control
Los acuerdos con proveedores deberían incluir requisitos para abordar los riesgos de
seguridad de la información asociados con los servicios de tecnología de la información y
comunicaciones y la cadena de suministro de productos.
Deberían considerarse los siguientes temas para su inclusión en acuerdos con proveedores
en materia de seguridad en la cadena de suministro:
a) definir los requisitos de seguridad de la información para aplicarlos a la

información y a la adquisición del producto o servicio de tecnología de la
información y comunicaciones además de los requisitos generales de
seguridad de la información para las relaciones con los proveedores;
b) para servicios de tecnología de la información y comunicaciones, se requiere

que los proveedores propaguen los requisitos de seguridad a través de toda la
cadena de suministro si los proveedores subcontratan para partes de servicios
de tecnologías de la información y comunicaciones proporcionadas a la
organización;
c) para productos de tecnología de la información y comunicaciones, se requiere

que los proveedores propaguen las prácticas de seguridad apropiadas a través
de toda la cadena de suministro si estos productos incluyen componentes
adquiridos desde otros proveedores;
d) la implementación de un proceso de monitoreo y métodos aceptables para la

validación que la entrega de los productos y servicios de tecnologías de la
información y comunicaciones se adhieren a los requisitos de seguridad
establecidos;
e) la implementación de un proceso para identificar productos o componentes

del servicio que son críticos para el mantenimiento de la funcionalidad y por
lo tanto, requieren más atención y escrutinio cuando son construidos fuera de
la organización, especialmente si el proveedor de primer nivel subcontrata
aspectos del producto o componentes del servicio con otros proveedores;
PERUANA 132 de 162
f) la obtención de garantías de que los componentes críticos y sus orígenes

pueden ser rastreados a lo largo de la cadena de suministro;
g) la obtención de garantías de que la información entregada y los productos de

tecnología de la información y comunicaciones funcionan tal como se
esperaba, sin características inesperadas o indeseadas;
h) la definición de reglas para el intercambio de información sobre la cadena de

suministro y cualquier asunto y compromiso potencial entre la organización
y los proveedores;
i) la implementación de procesos específicos para gestionar el ciclo de vida de

componentes de tecnologías de la información y comunicaciones, su
disponibilidad y los riesgos de seguridad asociados. Esto incluye la gestión
de riesgos de los componentes que ya no se encuentran disponibles debido a
que los proveedores no se encuentran más en el negocio o a que los
proveedores ya no proporcionan estos componentes debido a los avances
tecnológicos.
Las prácticas específicas de gestión de riesgos de la cadena de suministro de tecnología de

la información y comunicaciones se construyen sobre las más altas prácticas de seguridad
de la información, calidad, gestión de proyectos e ingeniería de sistemas pero no las
reemplazan.
Se recomienda a las organizaciones trabajar con proveedores para comprender la cadena de

suministro de tecnología de la información y comunicaciones y cualquier aspecto que tenga
un impacto importante sobre los productos y servicios proporcionados. Las organizaciones
pueden influir en las prácticas de seguridad de la información de la cadena de suministro de
tecnologías de la información y comunicaciones, dejando en claro en los acuerdos con sus
proveedores los asuntos que deberían abordarse por otros proveedores en la cadena de
suministro de tecnologías de la información y comunicaciones.
La cadena de suministro de tecnologías de información y comunicaciones abordada aquí

incluye los servicios informáticos en la “nube” (cloud computing).

PERUANA 133 de 162
15.2 Gestión de entrega de servicios del proveedor
Objetivo: mantener un nivel de seguridad de la información y entrega de servicios acordado

en línea con los acuerdos con proveedores.
15.2.1 Monitoreo y revisión de servicios del proveedor
Control
Las organizaciones deberían monitorear, revisar y auditar regularmente la entrega de

servicios por parte de los proveedores.
El monitoreo y la revisión de los proveedores de servicios deberían garantizar el

cumplimiento de los términos y condiciones de seguridad de la información de los acuerdos
y que los incidentes y problemas de seguridad de la información estén gestionados
correctamente.
Esto debería involucrar un proceso de gestión de las relaciones de la gestión del servicio
entre la organización y el proveedor para:
a) monitorear los niveles de desempeño del servicio para verificar la adhesión a

los acuerdos;
b) revisar los reportes del servicio producidos por los proveedores y organizar
reuniones regulares de progreso según los requisitos de los acuerdos;
c) conducir auditorías de proveedores, en conjunción con la revisión de reportes

de auditores independientes, si se encuentran disponibles y el seguimiento de
los problemas identificados;
d) proporcionar información sobre incidentes de seguridad de la información y

revisión de esta información según los requisitos de los acuerdos así como de
cualquier pauta y procedimiento de soporte;

PERUANA 134 de 162
e) revisar del lado del proveedor, las pistas de auditoría y registros de eventos
de seguridad de la información, problemas operacionales, fallas, rastreo de
fallas y de interrupciones relacionadas con el servicio entregado;
f) resolver y gestionar cualquier problema identificado;
g) revisar los aspectos de seguridad de la información de las relaciones del

proveedor con sus propios proveedores;
h) garantizar que el proveedor mantiene la suficiente capacidad de servicio junto

con los planes realizables diseñados para garantizar que los niveles de
continuidad de servicio acordados se mantendrán después de fallas
importantes en el servicio o desastres (véase el capítulo 17).
La responsabilidad por gestionar la relación con los proveedores debería asignarse a un

individuo o a un equipo de gestión del servicio. Además, la organización debería garantizar
que los proveedores asignan responsabilidades para la revisión de conformidad y de hacer
cumplir los requisitos de los acuerdos. Los recursos y las habilidades técnicas suficientes
deberían estar disponibles para monitorear que los requisitos del acuerdo, en particular los
requisitos de seguridad de la información, se estén cumpliendo. Deberían tomarse las
acciones apropiadas cuando se observen deficiencias en la entrega del servicio.
La organización debería retener suficiente control y visibilidad generales en todos los

aspectos de la seguridad para la información crítica o sensible o del acceso a las instalaciones
de procesamiento de la información, procesadas o gestionadas por un proveedor. La
organización debería retener la visibilidad sobre actividades de seguridad tales como gestión
del cambio, identificación de vulnerabilidades, reporte y respuesta ante incidentes de
seguridad de la información mediante un proceso de reporte definido.
15.2.2 Gestión de cambios a los servicios de proveedores
Control
Los cambios a la provisión de servicios por parte de proveedores, incluyendo el

mantenimiento y mejoramiento de políticas, procedimientos y controles existentes de
seguridad de la información, deberían ser gestionados tomando en cuenta la criticidad de la
información del negocio, sistemas y procesos involucrados y una reevaluación de riesgos.

PERUANA 135 de 162
Deberían considerarse los siguientes aspectos:
a) cambios en los acuerdos con proveedores;
b) cambios realizados por la organización para implementar:
1) mejoras a los servicios actuales ofrecidos;
2) desarrollo de cualquier nueva aplicación y sistemas;
3) modificaciones o actualizaciones de las políticas y procedimientos de la

organización;
4) controles nuevos o modificados para resolver incidentes de seguridad de la

información y para mejorar la seguridad;
c) cambios en servicios de los proveedores para implementar:
1) cambios y mejoras en las redes;
2) uso de nuevas tecnologías;
3) adopción de nuevos productos o versiones/lanzamientos;
4) nuevas herramientas y ambientes de desarrollo;
5) cambios a la localización física de las instalaciones del servicio;
6) cambio de proveedores;
7) subcontratación de otro proveedor.

PERUANA 136 de 162
16 Gestión de incidentes de seguridad de la información
16.1 Gestión de incidentes de seguridad de la información y mejoras
Objetivo: asegurar un enfoque consistente y efectivo a la gestión de incidentes de seguridad

de la información, incluyendo la comunicación sobre eventos de seguridad y debilidades.
16.1.1 Responsabilidades y procedimientos
Control
Las responsabilidades de gestión y los procedimientos deberían ser establecidos para

asegurar una respuesta rápida, efectiva y ordenada a los incidentes de seguridad de la
información.
Las siguientes recomendaciones para gestionar las responsabilidades y procedimientos con

respecto a la gestión de incidentes de seguridad de la información deberían considerarse:
a) deberían establecerse responsabilidades de gestión para garantizar que los

siguientes procedimientos son desarrollados y comunicados adecuadamente
dentro de la organización:
1) procedimientos para la planificación y preparación de la respuesta ante

incidentes;
2) procedimientos para monitorización, detección, análisis y reporte de eventos

e incidentes de seguridad de la información;
3) procedimientos para el registro de las actividades de gestión de incidentes;
4) procedimientos para el manejo de evidencia forense;

PERUANA 137 de 162
5) procedimientos para la evaluación y la decisión sobre los eventos de

seguridad de la información y la evaluación de las debilidades de seguridad
de la información;
6) procedimientos para la respuesta, incluyendo el de escalamiento,

recuperación controlada ante un incidente y la comunicación a personas u
organizaciones internas o externas;
b) los procedimientos establecidos deberían asegurar que:
1) personal competente maneja los asuntos relacionados con los incidentes de

seguridad de la información dentro de la organización;
2) se implementa un punto de contacto para la detección y reporte de incidentes

de seguridad;
3) se mantienen los contactos apropiados con las autoridades, los grupos de

interés externos o los foros que se encargan de los asuntos relacionados con
incidentes de seguridad de la información;
c) los procedimientos de reporte deberían incluir:
1) la preparación de formularios de reporte de eventos de seguridad de la

información para apoyar la acción de reporte y para ayudar a la persona que
reporta a recordar todas las acciones necesarias en el caso de un evento de
seguridad de la información;
2) el procedimiento a ser llevado a cabo en el caso de un evento de seguridad de

la información, por ejemplo, observando todos los detalles inmediatamente,
como son tipo de incumplimiento o violación, fallas que ocurren, mensajes
en la pantalla y reporte inmediato al punto de contacto y tomando solo
acciones coordinadas;
3) la referencia a un proceso disciplinario formalmente establecido para tratar

con los empleados que cometen violaciones de la seguridad;
4) procesos de retroalimentación adecuados para garantizar que las personas

reportan los eventos de seguridad de la información son notificados de los
resultados después de que el problema ha sido bien abordado y cerrado.

PERUANA 138 de 162
Los objetivos para la gestión de incidentes de seguridad de la información deberían acordarse

con la gerencia y debería asegurarse que aquellos responsables para la gestión de incidentes
de seguridad de la información entienden las prioridades de la organización para el manejo
de incidentes de seguridad de la información.
Los incidentes de seguridad de la información pueden superar los límites organizacionales y

nacionales. Para responder a tales incidentes existe una necesidad creciente de coordinar
respuesta y compartir la información sobre estos incidentes con organizaciones externas
como sea apropiado.
Se proporciona orientación detallada sobre la gestión de incidentes de seguridad de la

información en la Norma ISO/IEC 27035.
16.1.2 Reporte de eventos de seguridad de la información
Control
Los eventos de seguridad de la información deberían ser reportados a través de canales de

gestión apropiados tan rápido como sea posible.
Todos los empleados y contratistas deberían ser puestos en conocimiento de su

responsabilidad de reportar cualquier evento de seguridad de la información lo más
rápidamente posible. Deberían también conocer el procedimiento para reportar los eventos
de seguridad de la información y el punto de contacto al que los eventos deberían reportarse.
Las situaciones a ser consideradas para el reporte de eventos de seguridad de la información

incluyen:
a) el control ineficaz de seguridad;

PERUANA 139 de 162
b) la violación de las expectativas de integridad, confidencialidad y

disponibilidad de la información;
c) los errores humanos;
d) los incumplimientos de las políticas o los lineamientos;
e) las violaciones de los acuerdos de seguridad física;
f) los cambios no controlados en el sistema;
g) el mal funcionamiento de software o hardware;
h) las violaciones de acceso.
El mal funcionamiento u otros comportamientos anómalos del sistema pueden ser un

indicador de un ataque a la seguridad o de una violación actual a la seguridad y por lo tanto,
debería siempre reportarse como un evento de seguridad de la información.
16.1.3 Reporte de debilidades de seguridad de la información
Control
Empleados y contratistas que usan los sistemas y servicios de información de la organización

deberían ser exigidos a advertir y reportar cualquier debilidad observada o de la que se
sospecha en cuanto a seguridad de la información en los sistemas o servicios.
Todos los empleados y contratistas deberían reportar estos asuntos al punto de contacto tan
pronto como sea posible a fin de prevenir incidentes de seguridad de la información. El
mecanismo de reporte debería ser tan fácil, accesible y tan disponible como sea posible.

PERUANA 140 de 162
Los empleados y los contratistas deberían ser advertidos de no intentar probar presuntas
debilidades de seguridad. Las pruebas de las debilidades pueden ser interpretadas como un
posible mal uso del sistema y podrían causar daños también al sistema o servicio de
información y resultar en la responsabilidad legal para la persona que realiza la prueba.
16.1.4 Evaluación y decisión sobre eventos de seguridad de la información
Control
Los eventos de seguridad de la información deberían ser evaluados y debería decidirse si son
clasificados como incidentes de seguridad de la información.
El punto de contacto debería evaluar cada evento de seguridad de la información utilizando

la escala acordada de clasificación de eventos e incidentes de seguridad de la información y
decidir si el evento debería ser clasificado como un incidente de seguridad de la información.
La clasificación y la priorización de incidentes pueden ayudar a identificar el impacto y
extensión de un incidente.
En los casos donde la organización tiene un equipo de respuesta ante incidentes de seguridad
de la información (ISIRT, por sus siglas en inglés, information security incident response
team), la evaluación y la decisión pueden ser enviadas al ISIRT para su confirmación o
reevaluación.
Los resultados de la evaluación y la decisión deberían registrarse en detalle con el fin de

futura referencia y verificación.

PERUANA 141 de 162
16.1.5 Respuesta a incidentes de seguridad de la información
Control
Los incidentes de seguridad de la información deberían ser respondidos de acuerdo con los
procedimientos documentados.
Los incidentes de seguridad de la información deberían responderse por un punto de contacto

designado y otras personas relevantes de la organización o partes externas (véase 16.1.1).
La respuesta debería incluir lo siguiente:
a) la recopilación de evidencia tan pronto como sea posible después de la

ocurrencia;
b) conducir un análisis forense de seguridad de la información, cuando sea

requerido (véase 16.1.7);
c) escalamiento, cuando sea requerido;
d) garantizar que todas las actividades de respuesta involucradas son registradas

adecuadamente para su posterior análisis;
e) comunicar la existencia del incidente de seguridad de la información o

cualquier detalle relevante del mismo a otras personas u organizaciones
internas y externas que necesiten conocerlo;
f) tratar las debilidades de seguridad de la información encontradas que causan

o contribuyen al incidente;
g) una vez que el incidente ha sido exitosamente tratado, cerrarlo y registrarlo

formalmente.

PERUANA 142 de 162
Debería realizarse un análisis post-incidente, cuando sea necesario, para identificar el origen
del incidente.
El primer objetivo de la respuesta ante incidentes es reanudar el “nivel de seguridad normal”

y luego iniciar la recuperación necesaria.
16.1.6 Aprendizaje de los incidentes de seguridad de la información
Control
El conocimiento adquirido a partir de analizar y resolver los incidentes de seguridad de la

información debería ser utilizado para reducir la probabilidad o el impacto de incidentes
futuros.
Deberían existir mecanismos locales para permitir que los tipos, volúmenes y costos de los
incidentes de seguridad de la información sean cuantificados y monitoreados. La
información obtenida de evaluación de los incidentes de seguridad de la información debería
utilizarse para identificar los incidentes recurrentes o de alto impacto.
La evaluación de incidentes de seguridad de la información puede indicar la necesidad de

mejorar o agregar controles adicionales para limitar la frecuencia, daño y costo de futuras
ocurrencias o para ser tomada en cuenta en el proceso de revisión de la política de seguridad
(véase 5.1.2).
Con el debido cuidado de los aspectos de confidencialidad, se pueden utilizar anécdotas de

incidentes actuales de seguridad de la información en la capacitación de la sensibilización
del usuario (véase 7.2.2) como ejemplos de lo que podría suceder, como responder a estos
incidentes y cómo evitarlos en el futuro.
PERUANA 143 de 162
16.1.7 Recolección de evidencia
Control
La organización debería definir y aplicar procedimientos para la identificación, recolección,

adquisición y preservación de información que pueda servir como evidencia.
Deberían desarrollarse y seguirse procedimientos internos cuando se trate con evidencia para
los propósitos de acción disciplinaria y legal.
En general, estos procedimientos para evidencia deberían proporcionar procesos de

identificación, recolección, adquisición y conservación de evidencia de acuerdo con los
diferentes tipos de medios, dispositivos y estado de los dispositivos, por ejemplo, encendido
o apagado. Los procedimientos deberían tener en cuenta:
a) la cadena de custodia;
b) la protección de la evidencia;
c) la protección del personal;
d) las funciones y responsabilidades del personal involucrado;
e) la competencia del personal;
f) la documentación;
g) la reunión informativa.
Cuando se disponga, debería buscarse la certificación u otros medios pertinentes de la

calificación del personal y las herramientas, con el fin de fortalecer el valor de la evidencia
preservada.

PERUANA 144 de 162
La evidencia forense puede trascender los límites organizacionales o jurisdiccionales. En

tales casos, debería asegurarse que la organización tiene derecho a recopilar la información
requerida como evidencia forense. Deberían considerarse también los requisitos de las
distintas jurisdicciones para maximizar las posibilidades de su admisión en todas las
jurisdicciones relevantes.
La identificación es el proceso que implica la búsqueda, el reconocimiento y la

documentación de las evidencias potenciales. La recolección es el proceso de reunir los
elementos físicos que podrían contener evidencia potencial. La adquisición es el proceso de
crear una copia de los datos dentro de un conjunto definido. La preservación es el proceso
de mantener y salvaguardar la integridad y la condición original de la evidencia potencial.
Cuando se detecta un evento de seguridad de la información por primera vez, puede que no
sea obvio si el evento va a resultar o no en una acción judicial. Por lo tanto, existe el peligro
de que las evidencias necesarias sean destruidas intencionalmente o accidentalmente antes
de que se dé cuenta de la gravedad del incidente. Es recomendable involucrar a un abogado
o la policía rápidamente en cualquier acción legal contemplada y tener asesoramiento sobre
las evidencias requeridas.
La Norma ISO/IEC 27037 proporciona lineamientos para la identificación, recolección,

adquisición y preservación de evidencia digital.
17 Aspectos de seguridad de la información en la gestión de continuidad del

negocio
17.1 Continuidad de seguridad de la información
Objetivo: la continuidad de seguridad de la información debería formar parte en los sistemas

de gestión de continuidad del negocio de la organización

PERUANA 145 de 162
17.1.1 Planificación de continuidad de seguridad de la información
Control
La organización debería determinar sus requisitos de seguridad de la información y

continuidad de la gestión de seguridad de la información en situaciones adversas, por
ejemplo durante una crisis o desastre.
Una organización debería determinar si la continuidad de la seguridad de la información está

incluida dentro del proceso de gestión de continuidad del negocio o en el proceso de gestión
de recuperación ante desastres. Deberían determinarse los requisitos de seguridad de la
información cuando se planifique la continuidad del negocio y la recuperación ante
desastres.
En ausencia de un plan formal de continuidad del negocio y de recuperación ante desastres,

la gestión de seguridad de la información debería asumir que los requisitos de seguridad de
la información siguen siendo los mismos en situaciones adversas, en comparación con las
condiciones de funcionamiento normales. Alternativamente, una organización puede realizar
un análisis de impacto en el negocio para que los aspectos de seguridad de la información
determinen los requisitos de seguridad de la información aplicables a las situaciones
adversas.
Con el fin de reducir el tiempo y el esfuerzo de un análisis de impacto en el negocio

“adicional” para la seguridad de la información, se recomienda captar los aspectos de
seguridad de la información dentro de la gestión normal de continuidad del negocio o del
análisis de impacto en el negocio de la gestión de recuperación ante desastres. Esto implica
que los requisitos de continuidad de seguridad de la información sean explícitamente
formulados en la gestión de continuidad del negocio o en los procesos de gestión de
recuperación ante desastres.

PERUANA 146 de 162
Puede encontrar más información sobre gestión de la continuidad del negocio en las
NormasISO/IEC 27031, ISO/IEC 22313 e ISO/IEC 22301.
17.1.2 Implementación de continuidad de seguridad de la información
Control
La organización debería establecer, documentar, implementar y mantener los procesos,

procedimientos y controles para asegurar el nivel requerido de continuidad de seguridad de
la información durante una situación adversa.
Una organización debería garantizar que:
a) se establezca una estructura de gestión adecuada para estar preparados para,

mitigar y responder a un evento disruptivo utilizando personal con la
autoridad, experiencia y competencia necesarias;
b) se designe personal de respuesta a incidentes con la responsabilidad,

autoridad y competencia necesarias para gestionar un incidente y mantener la
c) se desarrollen y aprueben los planes documentados, procedimientos de

respuesta y recuperación, detallando cómo la organización va a gestionar un
evento disruptivo y mantener su seguridad de la información en un nivel
predeterminado, basado en los objetivos de continuidad de seguridad de la
información aprobados por la gestión (véase 17.1.1).
De acuerdo con los requisitos de continuidad de la seguridad de la información, la

organización debería establecer, documentar, implementar y mantener:
a) los controles de seguridad de la información dentro de los procesos,

procedimientos y sistemas de apoyo y herramientas de continuidad del
negocio o de recuperación ante desastres;

PERUANA 147 de 162
b) los procesos, procedimientos y cambios en la implementación para mantener

los controles de seguridad de la información existente durante una situación
adversa;
c) los controles de compensación para los controles de seguridad de la

información que no pueden ser mantenidos durante una situación adversa.
Dentro del contexto de continuidad del negocio o de recuperación ante desastres, los
procesos y procedimientos específicos pueden haber sido definidos. La información que es
manejada en estos procesos y procedimientos o en los sistemas de información dedicados
para apoyarla debería protegerse. Por lo tanto, una organización debería involucrar a
especialistas en seguridad de la información cuando establezca, implemente y mantenga los
procesos y procedimientos de continuidad del negocio o de recuperación ante desastres.
Los controles de seguridad de la información que han sido implementados deberían

continuar operando durante una situación adversa. Si los controles de seguridad no son
capaces de continuar asegurando la información, deberían establecerse, implantarse y
mantenerse otros controles para mantener un nivel aceptable de seguridad de la información.
17.1.3 Verificación, revisión y evaluación de continuidad de seguridad de la

información
Control
La organización debería verificar los controles de continuidad de seguridad de la

información que han establecido e implementado a intervalos regulares para asegurarse que
son válidos y efectivos durante situaciones adversas.
Los cambios organizacionales, técnicos, de procedimiento y de proceso, ya sea en un

contexto operacional o de continuidad, pueden conducir a cambios en los requisitos de
continuidad de seguridad de la información. En estos casos, la continuidad de los procesos,

PERUANA 148 de 162
procedimientos y controles para la seguridad de la información deberían revisarse frente a

estos requisitos cambiados.
Las organizaciones deberían verificar su gestión de la continuidad de la seguridad de la

información:
a) ejercitando y probando la funcionalidad de los procesos, procedimientos y

controles de continuidad de la seguridad de la información para garantizar
que su desempeño es consistente con los objetivos de continuidad de
b) ejercitando y probando el conocimiento y la rutina para operar los procesos,

procedimientos y controles de continuidad de la seguridad de la información
para garantizar que su desempeño es consistente con los objetivos de
continuidad de seguridad de la información;
c) revisando la validez y eficacia de las mediciones de continuidad de la

seguridad de la información cuando los sistemas de información, los
procesos, procedimientos y controles de seguridad de la información o los
procesos de gestión de continuidad del negocio/gestión de recuperación ante
desastres y las soluciones cambien.
La verificación de los controles de continuidad de la seguridad de la información son

diferentes de las pruebas y verificación generales de seguridad de la información y debería
llevarse a cabo fuera de las pruebas de los cambios. Si es posible, es preferible integrar la
verificación de los controles de continuidad de la seguridad de la información con las pruebas
de continuidad del negocio o de recuperación ante desastres de la organización.
17.2 Redundancias
Objetivo: asegurar la disponibilidad de las instalaciones y procesamiento de la información

PERUANA 149 de 162
17.2.1 Instalaciones de procesamiento de la información
Control
Las instalaciones de procesamiento de la información deberían ser implementadas con

redundancia suficiente para cumplir con los requisitos de disponibilidad.
Las organizaciones deberían identificar los requisitos de negocio para la disponibilidad de

los sistemas de información. Donde la disponibilidad no puede ser garantizada mediante la
arquitectura de los sistemas existentes, deberían considerarse componentes o arquitecturas
redundantes.
Donde sea aplicable, los sistemas de información redundantes deberían probarse para
garantizar que el cambio ante el fallo (failover) de un componente a otro trabaje según lo
previsto.
La implementación de redundancia puede introducir riesgos a la integridad o

confidencialidad de la información y de los sistemas de información, los cuales deberían ser
considerados cuando se diseñan los sistemas de información.
18 Cumplimiento
18.1 Cumplimiento con requisitos legales y contractuales
Objetivo: evitar infracciones de las obligaciones legales, estatutarias, regulatorias o

contractuales relacionadas a la seguridad de la información y a cualquier requisito de
seguridad.

PERUANA 150 de 162
18.1.1 Identificación de requisitos contractuales y de legislación aplicable
Control
Todos los requisitos legislativos, estatutarios, regulatorios y contractuales relevantes así

como el enfoque de la organización para cumplir con estos requisitos deberían ser
explícitamente identificados, documentados y mantenidos al día para cada sistema de
información y para la organización.
Los controles específicos y responsabilidades individuales para cumplir con estos requisitos,
deberían también definirse y documentarse.
Los gerentes deberían identificar toda la legislación aplicable a su organización a fin de

cumplir con los requisitos para su tipo de negocio. Si la organización realiza negocios en
otros países, los gerentes deberían considerar el cumplimento en todos los países relevantes.
18.1.2 Derechos de propiedad intelectual
Control
Procedimientos apropiados deberían ser implementados para asegurar el cumplimiento de

requisitos legislativos, regulatorios y contractuales, relacionados a los derechos de propiedad
intelectual y uso de productos de software propietario.
Deberían considerarse los siguientes lineamientos para proteger cualquier material que
pueda ser considerado propiedad intelectual:

PERUANA 151 de 162
a) publicar una política de cumplimiento de los derechos de propiedad

intelectual que defina el uso legal de los productos de software y de
información;
b) adquirir software sólo de fuentes conocidas y de buena reputación, para

garantizar que los derechos de autor no se violen;
c) mantener conciencia de las políticas de protección los derechos de propiedad

intelectual y advertir de la intención de adoptar medidas disciplinarias contra
el personal que los viole;
d) mantener los apropiados registros de activos e identificar todos los activos

con requisitos de protección de derechos de la propiedad intelectual;
e) mantener prueba y evidencia de la propiedad de las licencias, discos maestros,

manuales, entre otros;
f) implantar controles para garantizar que no se sobrepase el número máximo

de usuarios con licencias permitidos;
g) llevar a cabo revisiones de que solo están instalados productos de software

autorizados y con licencia;
h) proporcionar una política para el mantenimiento apropiado de las condiciones

de licenciamiento;
i) establecer una política de puesta a disposición del software o de su

transferencia a terceros;
j) cumplir con los términos y condiciones del software y de la información

obtenidas de redes públicas;
k) no duplicar ni convertir a otro formato o extraer información de registros

comerciales (película, audio) que no estén permitidos por la ley de derechos
de autor;
l) no copiar total o parcialmente, libros, artículos, reportes u otros documentos,

con excepción de lo permitido por la ley de derechos de autor.

PERUANA 152 de 162
Los derechos de propiedad intelectual incluyen los derechos de autor sobre software o
documentos, derechos de diseño, marcas registradas, patentes y licencias de código fuente.
Los productos de software propietario se suelen proporcionar bajo un contrato de licencia

que especifica términos y condiciones del licenciamiento, por ejemplo, limitar el uso de los
productos a máquinas específicas o copias limitadas sólo para la generación de copias de
respaldo. La importancia y la conciencia de los derechos de propiedad intelectual deberían
comunicarse al personal para el software desarrollado por la organización.
Las normas legales, regulaciones y los requisitos contractuales pueden plantear restricciones
sobre la copia de material propietario. En particular, pueden requerir que sólo el material
desarrollado por la organización o que está licenciado o proporcionado por el desarrollador
para la organización, se puedan utilizar. La infracción del derecho de autor puede conducir
a una acción legal, que puede implicar multas y procesos penales.
18.1.3 Protección de registros
Control
Los registros deberían ser protegidos de cualquier pérdida, destrucción, falsificación, acceso
no autorizado y divulgación no autorizada, de acuerdo con los requisitos legislativos,
regulatorios, contractuales y del negocio.
Cuando se decide sobre la protección de registros específicos de la organización, debería

considerarse la clasificación correspondiente basada en el esquema de clasificación de la
organización. Los registros se deberían categorizar según el tipo, como por ejemplo:
registros contables, registros de bases de datos, registros de transacciones, registros de
auditoría y procedimientos operativos, cada uno de los cuales con los detalles del periodo de
retención y el tipo de medios de almacenamiento, como por ejemplo, papel, microfichas,
medios magnéticos u ópticos. Cualquiera de las claves criptográficas y los programas
asociados con archivos cifrados o firmas digitales (véase el capítulo 10), también debería

PERUANA 153 de 162
guardarse para permitir el descifrado de los registros durante el tiempo en que los mismos
son retenidos.
Debería considerarse la posibilidad de deterioro de los medios utilizados para almacenar los
registros. Procedimientos de almacenamiento y manipulación deberían implementarse de
acuerdo con las recomendaciones del fabricante.
Cuando se eligen los medios de almacenamiento electrónico, se deberían establecer

procedimientos para garantizar la capacidad de acceder a los datos (tanto al medio como a
la lectura de los formatos en sí) a través de todo el período de retención para resguardarlos
contra la pérdida ante el futuro cambio de la tecnología.
Los sistemas de almacenamiento de datos deberían elegirse de manera tal que los datos
requeridos puedan recuperarse en un plazo y formato aceptable, dependiendo de los
requisitos a satisfacer.
El sistema de almacenamiento y manejo debería garantizar la identificación de los registros

y su período de retención según lo definido por las normas o las regulaciones nacionales o
regionales, si es aplicable. Este sistema debería permitir la destrucción apropiada de los
registros tras dicho período, cuando ya no sean necesarios para la organización.
Para alcanzar los objetivos de resguardo de registros, deberían tomarse los siguientes pasos
en la organización:
a) deberían emitirse lineamientos sobre la retención, almacenamiento, manejo y

puesta a disposición de los registros y de la información;
b) debería elaborarse un calendario de retención que identifique los registros y

sus períodos de tiempo en que deberían ser retenidos;
c) debería mantenerse un inventario de fuentes de información clave.
Algunos registros podrían necesitar ser retenidos de manera segura para cumplir con
requisitos normativos, regulatorios o contractuales, así como para soportar las actividades
PERUANA 154 de 162
esenciales del negocio. Los ejemplos incluyen los registros que pueden ser requeridos como
evidencia de que una organización opere dentro de las reglas estatutarias o regulatorias, para
garantizar una defensa adecuada contra una posible acción civil o penal, o para confirmar el
estado financiero de una organización respecto a los accionistas, terceros y auditores. La
legislación o la regulación nacional podrían establecer el periodo de tiempo y datos
contenidos de la información a retener.
Información adicional sobre la gestión de registros de una organización se puede encontrar

en la Norma ISO 15489-1.
18.1.4 Privacidad y protección de datos personales.
Control
La privacidad y la protección de datos personales deberían estar aseguradas tal como se

requiere en la legislación y regulación relevantes donde sea aplicable.
Una política de datos organizacionales para la privacidad y protección de datos personales,

debería desarrollarse e implementarse. Esta política debería comunicarse a todas las personas
involucradas en el procesamiento de datos personales.
El cumplimiento de esta política y de toda la legislación y regulaciones concernientes a la

protección de la privacidad de las personas y de protección de los datos personales requiere
una apropiada estructura de gestión y control. Este objetivo a menudo suele alcanzarse mejor
designando una persona responsable, como un oficial de privacidad, quien debería
proporcionar orientación a los gerentes, usuarios y proveedores de servicios sobre sus
responsabilidades individuales y los procedimientos específicos que deberían seguirse. La
responsabilidad de manejar la información de datos personales y de garantizar la creación
de conciencia sobre los principios de privacidad debería establecerse de acuerdo con la
legislación y regulación relevante. Debería implementarse medidas técnicas y
organizacionales apropiadas para proteger la información de datos personales.

PERUANA 155 de 162
La Norma ISO/IEC 29100 proporciona un marco de alto nivel para la protección de los datos
personales dentro de los sistemas de tecnologías de la información y comunicaciones. Un
número de países han introducido en su legislación local, controles para la recolección,
procesamiento y transmisión de datos personales (generalmente, información de personas
vivas que pueden ser identificadas a raíz de dicha información). Dependiendo de la
respectiva legislación nacional, cada control puede imponer obligaciones a quien recolecte,
procese y transmita información de datos personales y pueden también restringir la
posibilidad de transferir información de datos personales hacia otros países.
18.1.5 Regulación de controles criptográficos
Control
Controles criptográficos deberían ser utilizados en cumplimiento con todos los acuerdos,
legislación y regulación relevantes.
Los siguientes elementos deberían considerarse para el cumplimiento de los acuerdos, las
leyes y las regulaciones relevantes:
a) restricciones en la importación o hardware y software para realizar funciones

criptográficas;
b) restricciones en la importación o exportación de equipo de cómputo y

programas están diseñados para tener funciones criptográficas incluidas en
ellos;
c) restricciones en el uso de cifrado;
d) métodos obligatorios o discrecionales de acceso por parte de las autoridades

de los países para la información encriptada que mediante equipamiento o
software proporcionan confidencialidad del contenido.

PERUANA 156 de 162
Mediante el asesoramiento jurídico debería intentarse garantizar el cumplimiento con la

legislación y regulación relevante. Antes que la información encriptada o que los controles
criptográficos crucen fronteras jurisdiccionales, también debería tenerse en cuenta el
asesoramiento jurídico.
18.2 Revisiones de seguridad de la información
Objetivo: asegurar que la seguridad de la información está implementada y es operada de

acuerdo con las políticas y procedimientos organizativos.
18.2.1 Revisión independiente de la seguridad de la información
Control
El enfoque de la organización para manejar la seguridad de la información y su

implementación (por ejemplo objetivos de control, controles, políticas, procesos y
procedimientos para la seguridad de la información) debería ser revisado
independientemente a intervalos planeados o cuando ocurran cambios significativos.
La gerencia debería iniciar la revisión independiente. Dicha revisión independiente es

necesaria para garantizar la conveniencia, adecuación y eficacia continuas del enfoque de la
organización para gestionar la seguridad de la información. La revisión debería incluir las
oportunidades de la evaluación para la mejora y la necesidad de cambios en el enfoque de
seguridad, incluyendo las políticas y los objetivos de control.
Dicha revisión debería llevarse a cabo por personas independientes del área bajo revisión,
por ejemplo, la función de auditoría interna, un administrador independiente o una
organización externa especializada en ese tipo de revisiones. Las personas que llevan a cabo
estas revisiones deberían tener las habilidades y experiencia apropiadas.
Los resultados de una revisión independiente deberían registrarse y reportarse a la gerencia

que inició la revisión. Estos registros deberían mantenerse.

PERUANA 157 de 162
Si la revisión independiente identifica que el enfoque de la organización y la implementación

para gestionar la seguridad de la información son inadecuadas, por ejemplo, los objetivos y
requisitos documentados no se cumplen o no cumplen con la dirección para la seguridad de
la información establecida en las políticas de seguridad de la información (véase 5.1.1), la
gerencia debería considerar acciones correctivas.
La Norma ISO/IEC 27007 “Lineamientos para la auditoría de sistemas de gestión de

seguridad de la información” y la Norma ISO/IEC TR 27008 “Lineamientos para auditores
sobre controles de seguridad de la información” también proporcionan lineamientos para
realizar la revisión independiente.
18.2.2 Cumplimiento de políticas y normas de seguridad
Control
Los gerentes deberían revisar regularmente el cumplimiento del procesamiento de la

información y de los procedimientos, dentro de su área de responsabilidad con las políticas,
normas y otros requisitos de seguridad apropiados.
Los gerentes deberían identificar cómo revisar que se cumplan los requisitos de seguridad
de la información definidos en las políticas, normas y otras regulaciones aplicables. Deberían
considerarse herramientas de medición y reporte automático para una revisión periódica
eficiente.
Si cualquier incumplimiento es encontrado como resultado de la revisión, los gerentes

deberían:
a) identificar las causas del incumplimiento;
b) evaluar la necesidad de tomar medidas para lograr el cumplimiento;

PERUANA 158 de 162
c) implementar las acciones correctivas apropiadas;
d) revisar la acción correctiva tomada para verificar su eficacia e identificar

cualquier deficiencia ó debilidad.
Los resultados de las revisiones y de las acciones correctivas realizadas por los gerentes
deberían registrarse y estos registros deberían mantenerse. Los gerentes deberían reportar
los resultados a las personas que realizan las revisiones independientes (véase 18.2.1) cuando
una revisión independiente se realice en el área de sus responsabilidades.
El monitoreo operacional del sistema utilizado se trata en el subcapítulo 12.4.
18.2.3 Revisión del cumplimiento técnico
Control
Los sistemas de información deberían ser revisados regularmente respecto al cumplimiento

de las políticas y normas de seguridad de la información de la organización.
El cumplimiento técnico debería revisarse preferentemente con la ayuda de herramientas

automatizadas que generen reportes técnicos para su posterior interpretación por parte de un
especialista técnico. Alternativamente, un ingeniero de sistemas experimentado podría
realizar revisiones manuales (con el apoyo de herramientas de software apropiadas, si es
necesario).
Si se utilizan pruebas de intrusión o evaluaciones de vulnerabilidad, debería tenerse cuidado

pues estas actividades podrían comprometer la seguridad del sistema. Tales pruebas deberían
ser planificadas, documentadas y repetibles.

PERUANA 159 de 162
Cualquier revisión del cumplimiento técnico sólo debería realizarse por personas
competentes, autorizadas o bajo la supervisión de estas personas.
La revisión del cumplimiento técnico involucra el examen de los sistemas operacionales a

fin de garantizar que los controles de hardware y software hayan sido correctamente
implementados. Este tipo de revisión del cumplimiento requiere pericia técnica
especializada.
La revisión del cumplimiento también cubre, por ejemplo, pruebas de intrusión y evaluación
de vulnerabilidades, las cuales podrían ser realizadas por expertos independientes
contratados específicamente para este propósito. Esto puede resultar útil para la detección
de vulnerabilidades en el sistema y para inspeccionar la eficacia de los controles para
prevenir los accesos no autorizados posibilitados por dichas vulnerabilidades.
Las pruebas de intrusión y la evaluación de vulnerabilidades proporcionan una muestra

actual de un sistema en un estado y momento específico. La muestra se limita a esas
porciones del sistema realmente probado durante los intentos de penetración. Las pruebas de
intrusión y la evaluación de vulnerabilidades no son un substituto para la evaluación del
riesgo.
La Norma ISO/IEC TR 27008 proporciona orientación específica con respecto a las

revisiones de cumplimiento técnico.

PERUANA 160 de 162
BIBLIOGRAFÍA
[1] ISO/IEC Directives, Part 2
[2] ISO/IEC 11770-1, Information technology Security techniques. Key management.

Part 1: Framework
[3] ISO/IEC 11770-2, Information technology. Security techniques. Key management.

Part 2: Mechanisms using symmetric techniques
[4] ISO/IEC 11770-3, Information technology. Security techniques. Key management.

Part 3: Mechanisms using asymmetric techniques
[5] ISO 15489-11, Information and documentation. Records management. Part 1: General
[6] ISO/IEC 20000-12, Information technology. Service management. Part 1: Service

management system requirements
[7] ISO/IEC 20000-23, Information technology. Service management. Part 2: Guidance on

the application of service management systems
[8] ISO 22301, Societal security. Business continuity management systems. Requirements
[9] ISO 22313, Societal security. Business continuity management systems. Guidance
[10] ISO/IEC 270014, Information technology. Security techniques. Information security

management systems. Requirements

risk management
[12] ISO/IEC 270076, Information technology. Security techniques. Guidelines for

information security management systems auditing
1
La NTP-ISO 15489-1 es equivalente a la ISO 15489-1
2
La NTP-ISO/IEC 20000-1 es equivalente a la ISO/IEC 20000-1
3
La NTP-ISO/IEC 20000-2 es equivalente a la ISO/IEC 20000-2
4
La NTP-ISO/IEC 27001 es equivalente a la ISO/IEC 27001
5
6
PERUANA 161 de 162
[13] ISO/IEC TR 270087, Information technology. Security techniques. Guidelines for

auditors on information security controls

information and communication technology readiness for business continuity
[15] ISO/IEC 27033-1, Information technology. Security techniques. Network security.

Part 1: Overview and concepts

Part 2: Guidelines for the design and implementation of network security

Part 3: Reference networking scenarios. Threats, design techniques and control issues

Part 4: Securing communications between networks using security gateways

Part 5: Securing communications across networks using Virtual Private Network
(VPNs)

incident Management
[21] ISO/IEC 27036-1, Information technology. Security techniques. Information security

for supplier relationships. Part 1: Overview and concepts

for supplier relationships. Part 2: Common requirements

for supplier relationships. Part 3: Guidelines for ICT supply chain security

identification, collection, acquisition and preservation of digital evidence
[25] ISO/IEC 29100, Information technology. Security techniques. Privacy framework
7
8
9
PERUANA 162 de 162
[26] ISO/IEC 29101, Information technology. Security techniques. Privacy architecture

framework
[27] ISO 3100010, Risk management. Principles and guidelines
10
La NTP-ISO 31000 es equivalente a la ISO 31000

Seguridad de La Información

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Seguridad de La Información

Încărcat de

Drepturi de autor:

Formate disponibile

NORMA TÉCNICA NTP-ISO/IEC 27002

Tecnología de la información. Técnicas de seguridad.

R.D. N° 056-2017-INACAL/DN. Publicada el 2017-12-29 Precio basado en 162 páginas

© ISO/IEC 2013 - © INACAL 2017

Calle Las Camelias 817, San Isidro

PRÓLOGO (ISO) vii

1 Objeto y campo de aplicación 1

4 Estructura de esta norma 2

5 Políticas de seguridad de la información 3

5.1 Dirección de la gerencia para la seguridad de la información 3

6 Organización de la seguridad de la información 7

6.1 Organización interna 7

7 Seguridad de los recursos humanos 17

7.1 Antes del empleo 17

8.1 Responsabilidad por los activos 26

9.1 Requisitos de la empresa para el control de acceso 38

10.1 Controles criptográficos 57

11 Seguridad física y del entorno 62

11.1 Áreas seguras 62

12 Seguridad de las operaciones 78

12.1 Procedimientos y responsabilidades operativas 78

13 Seguridad de las comunicaciones 99

13.1 Gestión de seguridad de la red 99

14 Adquisición, desarrollo y mantenimiento de sistemas 109

14.1 Requisitos de seguridad de los sistemas de información 109

15 Relaciones con los proveedores 126

15.1 Seguridad de la información en las relaciones con los proveedores 126

16 Gestión de incidentes de seguridad de la información 136

16.1 Gestión de incidentes de seguridad de la información y mejoras 136

17.1 Continuidad de seguridad de la información 144

18.1 Cumplimiento con requisitos legales y contractuales 149

A.1 El Instituto Nacional de Calidad - INACAL, a través de la Dirección de

A.2 La presente Norma Técnica Peruana ha sido elaborada por el Comité

A.3 El Comité Técnico de Normalización de Codificación e intercambio

A.4 La presente Norma Técnica Peruana presenta cambios editoriales referidos

B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN

Secretaría GS1 Perú

Presidente Ricardo Dioses Villanueva

Secretaria Mary Wong Suehiro

Contraloría General de la República Marco Bermúdez Torres

Deloitte & Touche S. R. L. Diana Lagos Flores

DMS Perú S. A. C. Adela Barcenas Freyre

GS1 Perú Milagros Dávila del Rio

IBM del Perú S. A. C. Ivan Ancco Peña

Instituto Nacional de Defensa de la Martha Arce Neyra

International Analytical Services S. A. C. Raúl Miranda Mercado

ITSTK Perú S. A. C. Belén Alvarado Chau

Microsoft Perú S. R. L. Fernando Gebara Filho

Ministerio de Economía y Finanzas - Jennifer Ayllón Bulnes

Superintendencia Nacional de Aduanas y Daniel Llanos Panduro

Consultor Carlos Horna Vallejos

ISO (la Organización Internacional para la Normalización) e IEC (la Comisión

Se redactan las Normas Internacionales en concordancia con las reglas proporcionadas en

Esta segunda edición cancela y reemplaza la primera edición (ISO/IEC 27001:2005), la

0.1 Antecedentes y contexto

La seguridad de la información se logra mediante la implementación de un conjunto

Un sistema de gestión de seguridad de la información (SGSI) exitoso requiere el apoyo

En un sentido más general, una seguridad de la información efectiva asegura también a

0.2 Requisitos de seguridad de la información

a) la evaluación del riesgo para la organización, tomando en cuenta su

b) los requisitos legales, estatutarios, regulatorios y contractuales que una

c) el conjunto de principios, objetivos y requisitos de negocio para el manejo,

La Norma ISO/IEC 27005[11] proporciona orientación sobre la gestión del riesgo de