Documentos de Académico
Documentos de Profesional
Documentos de Cultura
NTP Iso-Iec 27002 2017
NTP Iso-Iec 27002 2017
PERUANA 2017
Dirección de Normalización - INACAL
Calle Las Camelias 817, San Isidro (Lima 27) Lima, Perú
(EQV. ISO/IEC 27002:2013 Information technology - Security techniques - Code of practice for information
security controls, ISO/IEC 27002:2013/Cor.1:2014 and ISO/IEC 27002:2013/Cor.2:2015)
2017-12-27
1ª Edición
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta publicación
podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia o
publicándolo en el Internet o intranet, sin permiso por escrito del INACAL, único representante de la ISO/IEC
en territorio peruano.
© INACAL 2017
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta publicación
podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia o
publicándolo en el internet o intranet, sin permiso por escrito del INACAL.
INACAL
i
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
ÍNDICE
página
ÍNDICE ii
PRÓLOGO v
INTRODUCCIÓN viii
2 Referencias normativas 1
3 Términos y definiciones 2
4.1 Capítulos 2
4.2 Categorías de control 2
8 Gestión de activos 26
ii
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
9 Control de acceso 38
10 Criptografía 57
iii
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
17 Aspectos de seguridad de la información en la gestión de 144
continuidad del negocio
18 Cumplimiento 149
BIBLIOGRAFÍA 160
iv
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
PRÓLOGO
A. RESEÑA HISTÓRICA
v
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
ENTIDAD REPRESENTANTE
vi
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
PRÓLOGO
(ISO)
La tarea principal del comité técnico conjunto es preparar los proyectos de normas
internacionales adoptadas por el comité técnico conjunto, se circulan a los órganos
nacionales para su votación. La publicación como una Norma Internacional requiere la
aprobación de al menos 75% de los órganos nacionales que emiten un voto.
Se señala la posibilidad de que alguno de los elementos de este documento pueda estar
sujeto a derechos de patentes. No se hará responsable a ISO e IEC de identificar
cualquiera o todos los mencionados derechos de patentes.
ISO/IEC 27001 fue preparada por el Comité Técnico conjunto ISO/IEC JTC 1,
Tecnología de la información, Sub-comité SC 27, Técnicas de seguridad de la TI.
vii
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
INTRODUCCIÓN
Esta Norma está diseñado para que las organizaciones lo utilicen como referencia en la
selección de controles dentro del proceso de implementación de un Sistema de Gestión
de Seguridad de la Información (SGSI) basado en la Norma ISO/IEC 27001[10] o como
un documento guía para las organizaciones que implementen controles de seguridad de
la información comúnmente aceptados. Esta norma también puede utilizarse en el
desarrollo de lineamientos de gestión de seguridad de la información en industria y
organización específica, tomando en consideración su(s) entorno(s) de riesgo específicos
de seguridad de la información.
Las organizaciones de todos los tipos y tamaños (incluyendo al sector público y privado,
comercial y sin fines de lucro) recolectan, procesan, almacenan y transmiten información
de muchas formas, incluidas la electrónica, física y verbal (por ejemplo, conversaciones
y presentaciones).
El valor de la información va más allá de las palabras escritas, los números y las imágenes:
el conocimiento, los conceptos, las ideas y las marcas son ejemplos de formas intangibles
de información. En un mundo interconectado, la información y los procesos relacionados,
los sistemas, las redes y el personal que participan en su operación, manejo y la protección
son activos que, al igual que otros activos importantes, son valiosos para el negocio de
una organización y por lo tanto merecen o requieren protección contra diversos peligros.
Los activos son objeto de amenazas, tanto deliberadas como accidentales mientras que
los procesos relacionados, los sistemas, las redes y las personas tienen vulnerabilidades
inherentes. Los cambios en los procesos y sistemas de negocios u otros cambios externos
(tales como nuevas leyes y regulaciones) pueden crear nuevos riesgos de seguridad de la
información. Por lo tanto, dada la multiplicidad de maneras en las que las amenazas
podrían tomar ventaja de las vulnerabilidades para perjudicar a la organización, los
riesgos de seguridad de la información siempre se encuentran presentes. La efectiva
seguridad de la información reduce estos riesgos mediante la protección de la
organización frente a amenazas y vulnerabilidades y en consecuencia reduce los impactos
en sus activos.
viii
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
para asegurar que los objetivos específicos de seguridad y de negocio de la organización
son cumplidos. Un Sistema de Gestión de Seguridad de la Información (SGSI) como el
que es especificado en la Norma ISO/IEC 27001[10] tiene una visión holística y
coordinada de los riesgos de seguridad de la información de la organización a fin de
implementar un conjunto completo de controles de seguridad de la información en el
marco global de un sistema de gestión coherente.
Muchos sistemas de información no han sido diseñados para ser seguros en el sentido de
la Norma ISO/IEC 27001[10] y esta Norma. La seguridad que se puede lograr a través de
medios técnicos es limitada y debería estar apoyada por una gestión y procedimientos
adecuados. Identificar qué controles deberían estar en su lugar requiere una planificación
cuidadosa y atención al detalle.
Es esencial que la organización identifique sus requisitos de seguridad. Hay tres fuentes
principales de requisitos de seguridad:
ix
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
Los recursos empleados en la implementación de los controles necesitan estar
equilibrados con el daño comercial probable que resultaría de problemas de seguridad por
ausencia de estos controles. Los resultados de una evaluación del riesgo ayudarán a
orientar y a determinar las acciones y prioridades de gestión apropiadas para la gestión
de los riesgos de seguridad de la información y para la implementación de los controles
seleccionados para protegerse contra esos riesgos.
Los controles pueden ser elegidos de esta norma o de otro conjunto de controles o pueden
ser diseñados nuevos controles para cubrir adecuadamente necesidades específicas.
Algunos de los controles de esta norma pueden considerarse como principios guía para la
gestión de la seguridad de la información y aplicables para la mayoría de las
organizaciones. Los controles son explicados con más detalle en su guía de
implementación. Se puede encontrar más información sobre la selección de controles y
otras opciones de tratamiento de riesgos en la Norma ISO/IEC 27005[11].
Esta norma puede ser considerada como un punto de partida para desarrollar lineamientos
específicos de la organización. Pueden no ser aplicables todas los lineamientos y controles
de este código de práctica. Incluso, pueden requerirse controles y lineamientos
adicionales que esta Norma no incluye. Cuando sean desarrollados documentos que
contengan controles y lineamientos adicionales, puede ser útil incluir referencias
cruzadas con los capítulos de esta norma, donde sea aplicable, para facilitar la
verificación del cumplimiento por los auditores y socios del negocio.
x
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
0.5 Consideraciones del ciclo de vida
La información tiene un ciclo de vida natural, desde su creación y origen a través del
almacenamiento, procesamiento, utilización y transmisión hasta su eventual destrucción
o deterioro. El valor y los riesgos para los activos pueden variar durante su tiempo de vida
(por ejemplo, la divulgación no autorizada o el robo de unas cuentas financieras de la
empresa es mucho menos significativo después de que han sido publicadas oficialmente)
pero la seguridad de la información sigue siendo importante en alguna medida en todas
las etapas.
Los sistemas de información tienen ciclos de vida dentro de los que son concebidos,
especificados, diseñados, desarrollados, probados, implementados, utilizados,
mantenidos y eventualmente retirados del servicio y puestos a disposición. La seguridad
de la información debería ser tomada en cuenta en cada etapa. Los nuevos sistemas
desarrollados y cambios en los sistemas existentes presentan oportunidades para que las
organizaciones actualicen y mejoren los controles de seguridad, tomando en cuenta los
incidentes actuales y comunes y los riesgos proyectados de seguridad de la información.
Mientras que esta norma ofrece orientación sobre un amplio rango de controles de
seguridad de la información que son comúnmente aplicados en muchas organizaciones
diferentes, las partes restantes de la familia ISO/IEC 27000 proporcionan
recomendaciones complementarias o requisitos sobre otros aspectos del proceso global
de gestión de seguridad de la información.
Consulte la Norma ISO/IEC 27000 para una introducción general a los sistemas de
gestión de seguridad de la información (SGSI) y a la familia de normas. La Norma
ISO/IEC 27000 proporciona un glosario que define formalmente la mayor parte de los
términos utilizados en la familia de normas ISO/IEC 27000 y describe el alcance y los
objetivos para cada norma de la familia.
---oooOooo---
xi
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 1 de 162
Esta Norma Técnica Peruana está diseñada para ser utilizada por las organizaciones que
pretendan:
2 Referencias normativas
3 Términos y definiciones
Para los propósitos de esta Norma Técnica Peruana , se aplican los términos y definiciones
de la Norma ISO/IEC 27000.
4.1 Capítulos
Cada capítulo define controles de seguridad conteniendo una o más categorías principales
de seguridad.
b) uno o más controles que pueden ser aplicados para alcanzar el objetivo de
control.
Control
Guía de implementación
Información adicional
Proporciona información adicional que puede ser necesaria considerar, por ejemplo,
consideraciones legales y referencias a otras normas. Si no hay información adicional para
ser proporcionada, esta parte no se muestra.
Control
Guía de implementación
Al más alto nivel, las organizaciones deberían definir una “política de seguridad de la
información”, que sea aprobada por la dirección y que establezca el enfoque de la
organización para gestionar sus objetivos de seguridad de la información.
Las políticas de seguridad de la información deberían considerar los requisitos creados por:
En un nivel inferior, la política de seguridad de la información debería estar apoyada por las
políticas sobre temas específicos, las cuales exigen aún más la implementación de los
controles de seguridad de la información y se estructuran normalmente para guiar las
necesidades de determinados grupos dentro de una organización o para cubrir ciertos temas.
Estas políticas deberían comunicarse a los empleados y a las partes externas relevantes de
forma que sea pertinente, accesible y comprensible para el lector previsto, por ejemplo, en
el contexto de una “creación de conciencia de seguridad de la información, educación y
programa de capacitación” (véase 7.2.2).
Información adicional
Algunas organizaciones utilizan otros términos para estos documentos de políticas, tales
como “Normas”, “Directivas” o “Reglas”.
Control
Guía de implementación
Cada política debería tener un propietario con responsabilidad de gestión aprobada para el
desarrollo, la revisión y la evaluación de las políticas. La revisión debería incluir la
evaluación de las oportunidades de mejora de las políticas de la organización y el enfoque a
la gestión de seguridad de la información en respuesta a cambios en el entorno de la
organización, a las circunstancias del negocio, a las condiciones legales o al entorno técnico.
Control
Guía de implementación
Las áreas en donde las personas son responsables deberían establecerse. En particular,
debería ocurrir lo siguiente:
Información adicional
Control
Las funciones y áreas de responsabilidad en conflicto deberían estar segregadas para reducir
oportunidades de modificación no autorizada o no intencional o mal uso de los activos de la
organización.
Guía de implementación
Se debería tener cuidado en que ninguna persona pueda acceder, modificar o utilizar activos
sin autorización o sin detección. El inicio de un evento debería separarse de su autorización.
La posibilidad de colusión debería considerarse en el diseño de los controles.
Las organizaciones pequeñas pueden encontrar la segregación de funciones como algo difícil
de lograr, pero el principio debería ser aplicado en la medida de lo posible y practicable.
Siempre que sea difícil la segregación, deberían considerarse otros controles tales como el
monitoreo de las actividades, los registros de auditoría y la supervisión de la dirección.
Información adicional
La segregación de funciones es un método para reducir el riesgo del mal uso, sea accidental
o deliberado, de los activos de la organización.
Control
Guía de implementación
Las organizaciones deberían tener procedimientos vigentes que especifiquen cuándo y con
qué autoridades (por ejemplo, las fuerzas policiales, organismos reguladores y autoridades
de supervisión) deberían contactarse y cómo identificar los incidentes de seguridad de la
información que deberían reportarse en el momento oportuno (por ejemplo, si se sospecha
que se está incumpliendo la ley).
Información adicional
Las organizaciones atacadas desde Internet pueden necesitar que las autoridades tomen
acciones contra el origen del ataque.
Control
Guía de implementación
Información adicional
Control
Guía de implementación
Control
Una política y medidas de seguridad de soporte deberían ser adoptadas para manejar los
riesgos introducidos por el uso de dispositivos móviles.
Guía de implementación
Al utilizar dispositivos móviles, debería tenerse especial cuidado para asegurar que la
información del negocio no se vea comprometida. La política de dispositivos móviles
debería tener en cuenta los riesgos de trabajar con dispositivos móviles en entornos
desprotegidos.
Información adicional
Las conexiones inalámbricas de los dispositivos móviles son similares a otros tipos de
conexión de red, pero tienen diferencias importantes que deberían tenerse en cuenta al
identificar los controles.
Generalmente, los dispositivos móviles comparten funciones comunes, por ejemplo, redes,
acceso a Internet, correo electrónico y manejo de archivos, con los dispositivos de uso fijo.
Los controles de seguridad de la información consisten generalmente, en los adoptados por
los dispositivos de uso fijo y en los que abordan las amenazas planteadas por su uso fuera de
los locales de la organización.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 15 de 162
6.2.2 Teletrabajo
Control
Una política y medidas de seguridad de soporte deberían estar implementadas para proteger
información a la que se accede, se procesa o almacena en los sitios de teletrabajo.
Guía de implementación
Las organizaciones que permiten las actividades de teletrabajo deberían elaborar y publicar
una política que defina las condiciones y las restricciones para el uso del teletrabajo. Cuando
se considere aplicable y sea permitido por la ley, deberían considerarse los siguientes
aspectos:
i) los acuerdos de licencia de software son tales que las organizaciones pueden
ser responsables de la concesión de licencias de software cliente en estaciones
de trabajo de propiedad privada de los empleados o de usuarios de terceras
partes;
d) la seguridad física;
Información adicional
El teletrabajo se refiere a todas las formas de trabajo fuera de la oficina, incluyendo los
ambientes de trabajo no tradicionales, tales como los ambientes denominados “trabajo a
distancia”, “trabajo flexible”, “trabajo remoto” y “trabajo virtual”.
Objetivo: asegurar que los empleados y contratistas entienden sus responsabilidades y son
convenientes para los roles para los que se les considera.
7.1.1 Selección
Control
Las verificaciones de los antecedentes de todos los candidatos a ser empleados deberían ser
llevadas a cabo en concordancia con las leyes, regulaciones y ética relevantes y debería ser
proporcional a los requisitos del negocio, la clasificación de la información a la que se tendrá
acceso y los riesgos percibidos.
Guía de implementación
Cuando una persona es contratada para un rol específico en seguridad de la información, las
organizaciones deberían asegurarse que el candidato:
Control
Guía de implementación
Las obligaciones contractuales de los empleados o contratistas deberían reflejar las políticas
de seguridad de la información de la organización, además de aclarar y enunciar:
La organización debería asegurar que los empleados y contratistas acuerden en los términos
y condiciones concernientes a la seguridad de la información apropiada a la naturaleza y
extensión de acceso que ellos tendrán a los activos de la organización asociados con los
sistemas y servicios de información.
Información adicional
Objetivo: asegurar que los empleados y contratistas sean conscientes y cumplan con sus
responsabilidades de seguridad de la información.
Control
Guía de implementación
Información adicional
Una gestión pobre puede causar que el personal se sienta subvaluado resultando en un
impacto negativo en la seguridad de la información para la organización. Por ejemplo, una
gestión pobre puede conducir a negligencias en la seguridad o mal uso potencial de los
activos de la organización.
Control
Todos los empleados de la organización y, cuando fuera relevante, los contratistas deberían
recibir educación y capacitación sobre la conciencia de la seguridad de la información, así
como actualizaciones regulares sobre políticas y procedimientos de la organización, según
sea relevante para la función del trabajo que cumplen.
Guía de implementación
Las actividades para lograr la creación de conciencia deberían realizarse según lo requiera
el programa de creación de conciencia en seguridad de la información. Se puede utilizar
diferentes medios en las actividades para lograr la creación de conciencia, incluyendo
Información adicional
Control
Debería haber un proceso disciplinario formal y comunicado para tomar acción contra
empleados que hayan cometido una infracción a la seguridad de la información.
Guía de implementación
El proceso disciplinario no debería comenzar sin una verificación previa de que la violación
a la seguridad de la información ha ocurrido (véase 16.1.7).
El proceso disciplinario formal debería asegurar un tratamiento correcto y justo para los
empleados de quienes se sospecha que han infringido la seguridad de la información. El
proceso disciplinario formal debería proveer una respuesta gradual que tome en
consideración factores tales como la naturaleza y gravedad de la infracción y su impacto en
el negocio, si es la primera ofensa o una repetición, si el infractor fue apropiadamente
entrenado, legislación relevante, contratos del negocio y otros factores que se requieran.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 25 de 162
El proceso disciplinario también debería usarse como disuasión para prevenir que los
empleados infrinjan las políticas y procedimientos de seguridad de la información de la
organización y cualquier otra infracción de seguridad de la información. Las infracciones
deliberadas pueden requerir acciones inmediatas.
Información adicional
Objetivo: proteger los intereses de la organización como parte del proceso de cambio o
terminación de empleo.
Control
Guía de implementación
El contrato del empleado o contratista debería contener las responsabilidades y deberes que
permanecen válidos aún luego de la desvinculación (véase 7.1.2).
Información adicional
Puede ser necesario informar a los empleados, clientes o contratistas de los cambios en los
acuerdos operativos y de personal.
8 Gestión de activos
Control
Guía de implementación
El inventario de activos debería ser exacto, actualizado, consistente y alineado con otros
inventarios.
Para cada uno de los activos identificados, debería asignarse un propietario (véase 8.1.2) y
debería identificarse la clasificación (véase 8.2).
Información adicional
Los inventarios de activos ayudan a garantizar que se logra la protección eficaz, pero también
pueden ser requeridos para otros propósitos, como por ejemplo por razones de salud y
seguridad, financieras o de seguros (gestión de activos).
Control
Guía de implementación
Las personas, así como otras entidades que hayan aprobado la responsabilidad de gestión del
ciclo de vida de los activos, califican para ser asignadas como propietarios de activos.
Información adicional
Las tareas rutinarias pueden ser delegadas, por ejemplo, a un custodio que vigile el activo
diariamente, pero la responsabilidad continúa siendo del propietario.
En sistemas de información complejos, puede resultar útil designar un grupo de activos, los
cuales actúan en forma conjunta para proveer un servicio particular. En este caso, el
propietario del servicio es responsable por la entrega del mismo, incluido el funcionamiento
de sus activos.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 29 de 162
Control
Las reglas para el uso aceptable de la información y activos asociados con la información y
con las instalaciones de procesamiento de la información deberían estar identificadas,
documentadas e implementadas.
Guía de implementación
Los empleados y los usuarios externos que utilizan o tienen acceso a los activos de la
organización deberían concientizarse sobre los requisitos de la seguridad de la información
de la organización, de otros activos asociados a la información y de los recursos e
instalaciones de procesamiento de la información.
Control
Todos los empleados y usuarios de terceras partes deberían retornar todos los activos de la
organización en su posesión a la conclusión de su empleo, contrato o acuerdo.
Guía de implementación
En los casos en que un empleado o usuario de tercera parte tenga conocimiento de asuntos
importantes para las operaciones en curso, la información debería documentarse y
transferirse a la organización.
Control
La información debería ser clasificada en términos de los requisitos legales, valor, criticidad
y sensibilidad respecto a una divulgación o modificación no autorizada.
Guía de implementación
cualquier otro requisito para la información considerada. El esquema debería estar alineado
con la política de control de acceso (véase 9.1.1).
Cada nivel debería tener un nombre que tenga sentido en el contexto de la aplicación del
esquema de clasificación.
El esquema debería ser consistente en toda la organización para que todos clasifiquen la
información y los activos relacionados de la misma manera, tengan un entendimiento común
de los requisitos de protección y apliquen la protección adecuada.
Información adicional
La clasificación les ofrece a las personas que tratan con información, una indicación concisa
de cómo manejarla y protegerla. La creación de grupos de información con necesidades de
protección similares y la especificación de los procedimientos de seguridad de la
información que se aplican a toda la información en cada grupo, facilitan esto. Este enfoque
reduce la necesidad de una evaluación de riesgos caso por caso y el diseño personalizado de
los controles.
La información suele dejar de tener importancia o criticidad tras cierto tiempo, por ejemplo,
cuando se ha hecho pública. Estos aspectos deberían considerarse, puesto que una sobre-
clasificación conllevaría a la implementación de controles innecesarios que resultan en
gastos adicionales o, por el contrario, en una baja clasificación, que puede poner en peligro
el logro de los objetivos del negocio.
Control
Guía de implementación
La salida de los sistemas que contienen información clasificada como sensible o crítica
debería llevar una etiqueta adecuada de clasificación.
Información adicional
compartir información. Las etiquetas físicas y los metadatos suelen ser las formas más
comunes de etiquetado.
Control
Guía de implementación
a) las restricciones de acceso que soportan los requisitos de protección para cada
nivel de clasificación;
e) borrar el marcado de todas las copias de los medios para la atención del
destinario autorizado.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 34 de 162
Los acuerdos con otras organizaciones que incluyen el intercambio de información deberían
incluir procedimientos para identificar la clasificación de la información y para interpretar
las etiquetas de clasificación de otras organizaciones.
Control
Guía de implementación
h) las unidades de medios extraíbles solo deberían habilitarse si hay una razón
comercial para hacerlo;
Control
Guía de implementación
Los procedimientos para la eliminación segura de los medios que contienen información
confidencial deberían ser proporcionales a la sensibilidad de esa información.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 36 de 162
c) puede ser más fácil organizar que todos los elementos de los medios sean
recopilados y eliminados de forma segura, en lugar de tratar de separar los
elementos sensibles;
Información adicional
Los dispositivos dañados que contienen datos sensibles pueden requerir una evaluación de
riesgos para determinar si los elementos deberían ser destruidos físicamente en lugar de ser
enviados para su reparación o descarte (véase 11.2.7).
Control
Los medios que contienen información deberían ser protegidos contra el acceso no
autorizado, el mal uso o la corrupción durante el transporte.
Guía de implementación
Deberían considerarse los siguientes lineamientos para proteger a los medios que contienen
información que es transportada:
Información adicional
La información puede ser vulnerable al acceso no autorizado, mal uso o corrupción durante
el transporte físico, por ejemplo, al enviar los medios a través del servicio postal o por
mensajería.
9 Control de acceso
Control
Una política de control de acceso debería estar establecida, documentada y revisada basada
en requisitos del negocio y de seguridad de la información.
Guía de implementación
Los propietarios de activos deberían determinar las reglas de control de acceso apropiadas,
los derechos de acceso y restricciones para las funciones específicas de los usuarios con
respecto a sus activos, con el nivel de detalle y el rigor de los controles que reflejan los
riesgos de seguridad de información asociados.
Los controles de acceso son lógicos y físicos (véase el capítulo 11) y estos deberían ser
considerados en conjunto. Los usuarios y los proveedores de servicios deberían tener una
declaración clara de los requisitos del negocio que deberían cumplir los controles de acceso.
Información adicional
Se debería tener cuidado cuando se especifica las reglas de control de acceso, para ello
considerar:
c) los cambios en los permisos del usuario que son iniciados automáticamente
por el sistema de información y aquellos iniciados por un administrador;
Las reglas de control de acceso deberían estar soportadas por procedimientos formales
(véase 9.2, 9.3 y 9.4) y responsabilidades definidas (véase 6.1.1 y 9.3).
El control de acceso basado en roles es un enfoque utilizado con éxito por muchas
organizaciones para vincular los derechos de acceso con las funciones de negocio.
Dos de los principios frecuentes que dirigen la política de control de acceso son:
Control
Los usuarios deberían tener acceso solamente a la red y a servicios de red que hayan sido
específicamente autorizados a usar.
Guía de implementación
Una política debería ser formulada en relación con el uso de redes y servicios de red. Esta
política debería cubrir:
a) las redes y los servicios de red que están permitidos a ser accedidos;
d) los medios utilizados para acceder a las redes y servicios de red (por ejemplo,
uso de VPN o red inalámbrica);
La política sobre el uso de los servicios de red debería ser coherente con la política de control
de acceso de la organización (véase 9.1.1).
Información adicional
Control
Un proceso formal de registro y baja de usuarios debería estar implementado para permitir
la asignación de derechos de acceso.
Guía de implementación
a) utilizar la identificación única de usuario (ID´s) para que los usuarios puedan
estar vinculados y sean responsable de sus acciones; el uso de identificaciones
compartidas debería sólo ser permitido cuando sean necesarios por razones
de negocios o de funcionamiento y debería estar aprobados y documentados;
Información adicional
Control
Guía de implementación
c) asegurar que los derechos de acceso no estén activados (por ejemplo, por los
proveedores de servicios) antes de que los procedimientos de autorización
sean completados;
Información adicional
Control
Guía de implementación
Información adicional
Control
Guía de implementación
a) los usuarios deberían ser requeridos a firmar una declaración personal para
mantener confidencial la información de autentificación secreta y para
mantener el grupo (es decir, compartida) de información de autentificación
secreta únicamente con los miembros del grupo; esta declaración firmada se
puede incluir en los términos y condiciones de empleo (véase 7.1.2);
Información adicional
Control
Los propietarios de los activos deberían revisar los derechos de acceso de usuario a intervalos
regulares.
Guía de implementación
Información adicional
Este control compensa las posibles debilidades en la ejecución de los controles 9.2.1, 9.2.2
y 9.2.6.
Control
Guía de implementación
Información adicional
En determinadas circunstancias, los derechos de acceso pueden ser asignados sobre la base
de estar disponible a más gente que el empleado o usuario de tercera parte que sale, por
ejemplo, ID de grupo. En tales circunstancias, las personas que salen deberían ser retiradas
de las listas de acceso de grupo y se debería hacer una recomendación a todos los demás
empleados y usuarios de partes externas involucrados a no compartir esta información con
las personas que salen.
En los casos de terminación iniciada por la gerencia, los empleados descontentos o usuarios
de parte externa, pueden deliberadamente corromper información o sabotear las
instalaciones de procesamiento de información. En los casos de personas que renuncian o
son despedidos, ellos pueden tener la tentación de recoger información para su uso futuro.
Control
Los usuarios deberían ser exigidos a que sigan las prácticas de la organización en el uso de
información de autentificación secreta.
Guía de implementación
1) fácil de recordar;
Otra información
Control
El acceso a la información y a las funciones del sistema de aplicación debería ser restringido
en concordancia con la política de control de acceso.
Guía de implementación
Debería considerarse lo siguiente para dar soporte a los requisitos de restricción de acceso:
b) controlar los datos que pueden ser accedidos por un usuario en particular;
c) controlar los derechos de acceso de los usuarios, por ejemplo, leer, escribir,
borrar y ejecutar;
Control
Guía de implementación
Una técnica de autentificación adecuada debería ser elegida para justificar la identidad
reclamada de un usuario.
El procedimiento para iniciar una sesión en un sistema o aplicación debería estar diseñado
para minimizar la oportunidad de un acceso no autorizado. Por tanto, el procedimiento de
conexión debería revelar el mínimo de información sobre el sistema o aplicación, con el fin
de evitar proporcionar a un usuario no autorizado alguna asistencia innecesaria. Un buen
procedimiento de ingreso debería:
2) detalles de cualquier intento de ingreso sin éxito desde el último ingreso con
éxito;
j) no transmitir las contraseñas en texto claro (sin cifrar) a través de una red;
Información adicional
Las contraseñas son una forma común de proveer identificación y autentificación basada en
un secreto que sólo el usuario conoce. Lo mismo también se puede lograr con medios
criptográficos y protocolos de autentificación. La fortaleza de la autentificación de usuario
debería ser apropiado para la clasificación de la información a ser accedida.
Si las contraseñas se transmiten en texto claro durante la sesión de ingreso a través de una
red, pueden ser capturadas por un programa "sniffer" de red.
Control
Los sistemas de gestión de contraseñas deberían ser interactivos y asegurar que las
contraseñas sean de calidad.
Guía de implementación
Información adicional
Algunas aplicaciones requieren que las contraseñas de usuario se asignen por una autoridad
independiente; en tales casos, los puntos b), d) y e) de la guía anteriormente no se aplican.
En la mayoría de los casos las contraseñas son seleccionadas y mantenidas por los usuarios.
Control
El uso de programas utilitarios que podrían ser capaces de pasar por alto los controles del
sistema y de las aplicaciones debería estar restringido y controlarse estrictamente.
Guía de implementación
Las siguientes pautas para el uso de programas utilitarios que podrían ser capaces de pasar
por alto los controles del sistema y de las aplicaciones se deberían considerar:
Información adicional
La mayoría de instalaciones de cómputo tienen uno o más programas utilitarios que podrían
ser capaces de anular controles de sistemas y aplicaciones.
Control
Guía de implementación
El acceso al código de los programas fuente y elementos asociados (tales como diseños,
especificaciones, planos de verificación y planos de validación) deberían estar estrictamente
controlados, con el fin de prevenir la introducción de funcionalidades no autorizadas y evitar
cambios no intencionales, así como para mantener la confidencialidad de la propiedad
intelectual de valor. Para el código del programa fuente, esto se puede lograr por el
almacenamiento central controlado de dicho código, preferiblemente en las bibliotecas de
programas fuente. Los siguientes lineamientos deberían tomarse en consideración para
controlar el acceso a este tipo de bibliotecas de programas fuente, con el fin de reducir las
posibilidades de corrupción de los programas del computador:
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
Control
Guía de implementación
Los controles criptográficos pueden ser usados para lograr diferentes objetivos de seguridad
de la información, por ejemplo:
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.
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.
Guía de implementación
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.
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.
j) destrucción de claves;
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.
Información adicional
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.
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.
Guía de implementación
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;
Información adicional
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
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.
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.
Guía de implementación
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).
Control
La seguridad física para oficinas, áreas e instalaciones debería ser diseñada e implementada.
Guía de implementación
Control
La protección física contra desastres naturales, ataque malicioso o accidentes debería estar
diseñada y aplicada.
Guía de implementación
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.
Control
Los procedimientos para el trabajo en áreas seguras deberían estar diseñados y aplicados.
Guía de implementación
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í.
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.
Guía de implementación
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;
c) las puertas externas del área de entrega y carga deberían cerrarse cuando las
internas estén abiertas;
11.2 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.
d) los elementos que requieran protección especial deberían aislarse para reducir
el nivel general de protección requerida;
Control
Los equipos deberían estar protegidos contra fallas de electricidad y otras alteraciones
causadas por fallas en los servicios de suministro.
Guía de implementación
Información adicional
Control
Control
Guía de implementación
e) se debería cumplir con todos los requisitos impuestos por pólizas de seguros;
Control
Guía de implementación
b) se debería fijar los límites de tiempo para el retiro del equipamiento y verificar
el cumplimiento del retorno;
Información adicional
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.
Guía de implementació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);
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.
Información adicional
Puede encontrarse en 6.2 más información sobre otros aspectos de la protección de equipos
móviles.
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;
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.
Guía de implementació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.
Información adicional
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:
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).
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.
Control
Guía de implementación
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;
Control
Guía de implementación
Información adicional
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.
Control
Guía de implementación
Control
Guía de implementación
Información adicional
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.
Guía de implementació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.
Información adicional
Este control también se refiere a la capacidad de los recursos humanos, así como a las
oficinas e instalaciones.
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.
Guía de implementación
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;
Información adicional
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.
Control
Guía de implementación
Información adicional
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
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.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 87 de 162
Guía de implementación
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.
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.
Control
Guía de implementación
a) identificador de usuario;
c) fechas, horas y detalles de los eventos clave, por ejemplo, inicio y cierre de
sesión;
h) uso de privilegios;
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.
Información adicional
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).
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).
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.
Guía de implementación
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).
Información adicional
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.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
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.
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.
Guía de implementación
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.
Información adicional
Control
Guía de implementación
Información adicional
Control
Guía de implementación
e) debería existir una estrategia de “vuelta atrás” antes de que los cambios sean
implementados;
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).
Control
Guía de implementación
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);
Información adicional
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.
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.
Control
Reglas que gobiernen la instalación de software por parte de los usuarios deberían ser
establecidas e implementadas.
Guía de implementación
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.
Información adicional
Control
Guía de implementación
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;
Control
Las redes deberían ser gestionadas y controladas para proteger la información en los sistemas
y las aplicaciones.
Guía de implementación
Información adicional
Control
Guía de implementación
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.
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 101 de 162
Información adicional
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.
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;
Control
Guía de implementación
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.
Información adicional
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.
Control
Guía de implementación
Los servicios de transferencia de la información deberían cumplir con todos los requisitos
legales pertinentes (véase 18.1).
Información adicional
Control
Los acuerdos deberían dirigir la transferencia segura de información del negocio entre la
organización y partes externas.
Guía de implementación
i) cualquier control especial que se requiera para proteger items sensibles, como
la criptografía (véase el capítulo 10);
Información adicional
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.
Control
Guía de implementación
f) los niveles más fuertes de autenticación para controlar el acceso desde las
redes de acceso público.
Información adicional
Control
Guía de implementació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).
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.
Información adicional
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.
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.
Control
Guía de implementación
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.
e) los requisitos derivados de los procesos del negocio, tales como el registro de
transacciones y monitoreo, requisitos de no-repudio;
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.
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.
Información adicional
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.
Control
Guía de implementación
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;
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.
Información adicional
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.
Control
Guía de implementación
d) el protocolo utilizado para comunicarse entre todas las partes implicadas está
asegurado;
Información adicional
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.
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.
Control
Guía de implementación
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.
Información adicional
El desarrollo también puede tener lugar dentro de las aplicaciones, tales como las
aplicaciones de oficina, scripting, navegadores y bases de datos.
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.
Guía de implementación
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
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.
Información adicional
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.
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.
Guía de implementación
Información adicional
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.
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.
Guía de implementación
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.
Control
Guía de implementación
Información adicional
Control
Guía de implementación
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:
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.
Control
Guía de implementación
Información adicional
Se puede encontrar más información sobre las relaciones con los proveedores en la Norma
ISO/IEC 27036.
Control
Guía de implementación
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.
Control
Guía de implementación
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.
Control
Guía de implementación
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:
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 126 de 162
Información adicional
Objetivo: asegurar protección a los activos de la organización que son accesibles por 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.
Guía de implementación
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;
Información adicional
Control
Guía de implementación
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:
k) los socios con acuerdos relevantes, incluyendo a una persona de contacto para
los asuntos de seguridad de la información;
p) las obligaciones del proveedor para cumplir con los requisitos de seguridad
de la organización.
Información adicional
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.
Guía de implementación
Deberían considerarse los siguientes temas para su inclusión en acuerdos con proveedores
en materia de seguridad en la cadena de suministro:
Información adicional
Control
Guía de implementación
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:
b) revisar los reportes del servicio producidos por los proveedores y organizar
reuniones regulares de progreso según los requisitos de los acuerdos;
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;
Control
Guía de implementación
6) cambio de proveedores;
Control
Guía de implementación
Información adicional
Control
Guía de implementación
Información adicional
Control
Guía de implementación
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.
Información adicional
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.
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.
Guía de implementación
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.
Control
Los incidentes de seguridad de la información deberían ser respondidos de acuerdo con los
procedimientos documentados.
Guía de implementación
Debería realizarse un análisis post-incidente, cuando sea necesario, para identificar el origen
del incidente.
Información adicional
Control
Guía de implementación
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.
Información adicional
Control
Guía de implementación
Deberían desarrollarse y seguirse procedimientos internos cuando se trate con evidencia para
los propósitos de acción disciplinaria y legal.
a) la cadena de custodia;
b) la protección de la evidencia;
f) la documentación;
g) la reunión informativa.
Información adicional
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.
Control
Guía de implementación
Información adicional
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.
Control
Guía de implementación
Información adicional
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.
Control
Guía de implementación
Información adicional
17.2 Redundancias
Control
Guía de implementación
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.
Información adicional
18 Cumplimiento
Control
Guía de implementación
Los controles específicos y responsabilidades individuales para cumplir con estos requisitos,
deberían también definirse y documentarse.
Control
Guía de implementación
Deberían considerarse los siguientes lineamientos para proteger cualquier material que
pueda ser considerado propiedad intelectual:
Información adicional
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.
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.
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.
Guía de implementación
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.
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.
Para alcanzar los objetivos de resguardo de registros, deberían tomarse los siguientes pasos
en la organización:
Información adicional
Algunos registros podrían necesitar ser retenidos de manera segura para cumplir con
requisitos normativos, regulatorios o contractuales, así como para soportar las actividades
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
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.
Control
Guía de implementación
Información adicional
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.
Control
Controles criptográficos deberían ser utilizados en cumplimiento con todos los acuerdos,
legislación y regulación relevantes.
Guía de implementación
Los siguientes elementos deberían considerarse para el cumplimiento de los acuerdos, las
leyes y las regulaciones relevantes:
Control
Guía de implementación
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.
Información adicional
Control
Guía de implementación
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.
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.
Información adicional
Control
Guía de implementación
Cualquier revisión del cumplimiento técnico sólo debería realizarse por personas
competentes, autorizadas o bajo la supervisión de estas personas.
Información adicional
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.
BIBLIOGRAFÍA
[5] ISO 15489-11, Information and documentation. Records management. Part 1: General
[8] ISO 22301, Societal security. Business continuity management systems. Requirements
[9] ISO 22313, Societal security. Business continuity management systems. Guidance
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
La NTP-ISO/IEC 27005 es equivalente a la ISO/IEC 27005
6
La NTP-ISO/IEC 27007 es equivalente a la ISO/IEC 27007
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 161 de 162
7
La NTP-ISO/IEC 27008 es equivalente a la ISO/IEC 27008
8
La NTP-ISO/IEC 27031 es equivalente a la ISO/IEC 27031
9
La NTP-ISO/IEC 27035 es equivalente a la ISO/IEC 27035
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 27002
PERUANA 162 de 162
10
La NTP-ISO 31000 es equivalente a la ISO 31000
© ISO/IEC 2013 - © INACAL 2017 - Todos los derechos son reservados