Iso Sistemas de Informacion 2 Parcial

NORMA TÉCNICA NTP-ISO/IEC 27002
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.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

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.
Guía de implementación
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.
Información adicional
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

Iso Sistemas de Informacion 2 Parcial

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Iso Sistemas de Informacion 2 Parcial

Cargado por

Copyright:

Formatos disponibles

NORMA TÉCNICA NTP-ISO/IEC 27002

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

b) el código del programa fuente y las bibliotecas de programas fuente deberían

c) el personal de soporte no debería tener acceso sin restricciones a las

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

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

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

10.1 Controles criptográficos

Objetivo: asegurar el uso apropiado y efectivo de la criptografía para proteger la

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

10.1.1 Política sobre el uso de controles criptográficos

Una política sobre el uso de controles criptográficos para la protección de la información

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

b) basado en una evaluación de riesgos, el nivel requerido de protección debería

c) el uso de encriptación para proteger la información transportada por los

d) el enfoque de la gestión de claves, incluyendo los métodos para tratar con la

e) los roles y responsabilidades, por ejemplo, quien es responsable de:

f) los estándares que se adoptan para la implementación efectiva a lo largo de la

g) el impacto de usar información codificada en los controles que se basan en la

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

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

a) confidencialidad: uso de encriptación de la información para proteger la

b) integridad / autenticidad: uso de firmas digitales o códigos de autentificación

c) no repudio: uso de técnicas criptográficas para proveer evidencia de la

d) autentificación: uso de técnicas criptográficas para autenticar usuarios y otras

En la política sobre el uso de controles criptográficos es necesario maximizar los beneficios

El asesoramiento de un especialista se debería buscar en la selección de controles

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

10.1.2 Gestión de claves

Los algoritmos criptográficos, longitudes de clave y prácticas de uso deberían ser

Un sistema de gestión de claves debería basarse en un conjunto acordado de normas,

a) la generación de claves para los diferentes sistemas criptográficos y diferentes

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

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

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

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

f) tratar con claves comprometidas;

g) revocar claves incluyendo cómo deberían ser retiradas o desactivadas, por

h) recuperación de claves que están perdidas o corruptas;

i) copia de seguridad o archivamiento 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

El contenido de los acuerdos de nivel de servicio o contratos con proveedores externos de

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

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

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

11.1.1 Perímetro de seguridad física

Deberían considerarse e implantarse las siguientes recomendaciones sobre los perímetros de

a) los perímetros de seguridad deberían definirse y la ubicación y la resistencia

seguridad de los activos dentro del perímetro y de los resultados de una

b) los perímetros de un edificio o un lugar que contenga instalaciones de

c) debería existir un área de recepción atendida por personal u otros medios de

f) deberían instalarse sistemas de detección de intrusos adecuados según las

g) las instalaciones de procesamiento de información gestionadas por la

© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados

11.1.2 Controles de ingreso físico

Deberían considerarse las siguientes recomendaciones:

a) la fecha y hora de entrada y salida de visitantes deberían restringirse y todos