ISO_IEC_NTP-27002[1]

PROYECTO DE NORMA TÉCNICA PERUANA

ENTP-ISO/IEC 27002 2016

Comisión de Normalización y de Fiscalización de Barreras Comerciales no ArancelariasCalle de La Prosa 138, San Borja (Lima 41) Apartado 145

INDECOPI Lima, Perú

TECNOLOGÍA DE LA INFORMACIÓN. Técnicas de seguridad. Código de prácticas para controles de seguridad de la información Information technology — Security techniques — Code of practice for information security controls

2016-XX-XX

“Este documento se encuentra en etapa de estudio, sujeto a posible cambio. No debe ser usado como Norma Técnica Peruana.” Precio basado en 100 páginas I.C.S.: 35.040 ESTA NORMA ES RECOMENDABLE Descriptores: Tecnología, información, técnicas, seguridad, sistema de gestión, requisitos

i

ÍNDICE Página ..................................................................................................................................... ............................................................................. .......iii INTRODUCCIÓN ............................................................... 0.1

Antecedentes Antecedentes y contexto contexto ............................................................ ................................................................................................................... ....................................................... iii

0.2

Requisitos de seguridad de la información...................................................................... ........................................................................................ .................. iv

0.3

Seleccionando controles............................................................. .................................................................................................................... ....................................................... iv

0.4

Desarrollando sus propias directrices................................................................... ................................................................................................. .............................. v

0.5

Consideraciones del ciclo de vida ........................................................... ....................................................................................................... ............................................ v

0.6

Normas relacionadas ................................................................... .......................................................................................................................... ....................................................... v

TECNOLOGÍ A DE LA L A INFORMACIÓN ― Técnicas Técnicas de seguridad. ― Código de práctica para los controles de Seguridad de la información............................................................ .............................................................................................................................. .................................................................. 7 1.

ALCANCE ................................................................... ......................................................................................................................................... ............................................................................. ....... 7

2.

REFERENCIAS NORMATIVAS NORMATIVAS ........................................................... .................................................................................................................. ....................................................... 7

3.

TÉRMINOS Y DEFINICIONES ............................................................ ................................................................................................................... ....................................................... 7

4.

ESTRUCTURA DE ESTA ESTA NORMA ................................................................... .............................................................................................................. ........................................... 7

5.

4.1

Cláusulas ........................................................... .............................................................................................................................. ............................................................................. .......... 8

4.2

Categorías de control.............................................................. ..................................................................................................................... ....................................................... 8

POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN INFORMACIÓN ............................................................. .................................................................................. ..................... 8 5.1

6.

7.

8.

Dirección de la gerencia para la seguridad de la información ....................................................... 8

ORGANIZACIÓN DE LA SEGURIDAD SEGURIDAD DE LA INFORMACIÓN.......................................................... .................................................................. ........ 11 6.1

Organización interna............................................................... .................................................................................................................... ..................................................... 11

6.2

Dispositivos móviles y teletrabajo teletrabajo ................................................................. ............................................................................................... .............................. 15

SEGURIDAD DE LOS RECURSOS HUMANOS ........................................................... ......................................................................................... .............................. 18 7.1

Antes del empleo ......................................................... ......................................................................................................................... ................................................................ 18

7.2

Durante el empleo ................................................................... ....................................................................................................................... .................................................... 21

7.3

Terminación y cambio de empleo.................................................................. ................................................................................................ .............................. 24

GESTIÓN DE ACTIVOS .......................................................... .......................................................................................................................... ................................................................ 25 8.1

Responsabilidad por los activos.......................................................... ................................................................................................... ......................................... 25

8.2

Clasificación de la información ........................................................... .................................................................................................... ......................................... 28

8.3

Manejo de los medios............................................................................................... medios.................................................................................................................. ................... 30

9.1

Requisitos de la empresa para el control de acceso. ........................................................... ................................................................... ........ 33

9.2.

Gestión de acceso de usuario ............................................................. ...................................................................................................... ......................................... 36

9.3.

Responsabilidades de los usuarios ................................................................... .............................................................................................. ........................... 41

9.4.

Responsabilidades de los usuarios ................................................................... .............................................................................................. ........................... 42 i

10. CRIPTOGRAFÍA ........................................................................................................................................4 ........................................................................................................................................47 7 10.1 11.

Controles criptográficos.......................................................... ................................................................................................................47 ......................................................47 SEGURIDAD FÍSICA Y AMBIENTAL AMBIENTAL ........................................................... .................................................................................................... ......................................... 50

11.1

Áreas seguras ........................................................... ........................................................................................................................... ................................................................ 50

11.2

Equipos ..................................................................... .................................................................................................................................... ............................................................... 55

12.

SEGURIDAD DE LAS OPERACIONES ......................................................... .................................................................................................. ......................................... 62

12.1

Procedimientos Procedimientos y responsabilidades responsabilidades operativas.............................................................. ...................................................................... ........ 62

12.2

Protección contra códigos maliciosos ...................................................................... ...................................................................................... ................ 66

12.3

Respaldo ................................................................... .................................................................................................................................. ............................................................... 68

12.4

Registros y monitoreo......................................................... .............................................................................................................. ..................................................... 69

12.5

Control del software operacional .............................................................. .............................................................................................72 ...............................72

12.6

Gestión de vulnerabilidad técnica ............................................................. ............................................................................................74 ...............................74

12.7

Consideraciones para la auditoría de los sistemas de información..........................................76

13

Seguridad de las Comunicaciones .......................................................... ................................................................................................... ......................................... 77

13.1

Gestión de seguridad de la red .................................................................. ................................................................................................ .............................. 77

13.2

Transferencia ransferencia de Información ......................................................... .................................................................................................. ......................................... 80

14.

ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE SISTEMAS................................................ SISTEMAS..................................................... ..... 84

14.1

Requisitos de seguridad de los sistemas de información ........................................................ 85

14.2

Seguridad en los procesos de desarrollo y soporte ......................................................... ................................................................. ........ 89

14.3

Datos de prueba .................................................................. ...................................................................................................................... .................................................... 96

15.

RELACIONES CON LOS PROVEEDORES ............................................................... ..............................................................................................97 ...............................97

15.1

Seguridad de la información en las relaciones con los proveedores proveedores ........................................97

15.2

Gestión de entrega de servicios del proveedor ............................................................... ..................................................................... ...... 102

16. 16.1 17.

GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN .................................................. 104 Gestión de incidentes de seguridad de la información y mejoras ......................................... 104 ASPECTOS DE SEGURIDAD DE LA INFORMACIÓN INFORMACIÓN EN LA GESTIÓN GESTIÓN DE CONTINUIDAD CONTINUIDAD DEL NEGOCIO 110

17.1

Continuidad de seguridad de la información........................................................ ......................................................................... ................. 110

17.2

Redundancias........................................................... ......................................................................................................................... .............................................................. 113

18.

CUMPLIMIENTO............................................................... ............................................................................................................................. .............................................................. 113

18.1

Cumplimiento con requisitos legales y contractuales contractuales ........................................................... 113

18.2

Revisiones de seguridad de la información .......................................................... ........................................................................... ................. 118

.............................................................................................................................................. ....................................... 121 Bibliography ........................................................................................................

ii

INTRODUCCIÓN

0.1

Antecedentes y contexto

Este Esquema de Norma Técnica Peruana 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 NTP-ISO/IEC 27001 o como un documento guía para las organizaciones que implementen controles de seguridad de la información comúnmente aceptados. Este esquema de norma técnica peruana también puede utilizarse en el desarrollo de lineamientos de gestión de seguridad de la información en industria y organizaciónespecí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, números e 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, redes, y personal que participan en su operación, manejo y la protección son activos que, al igual que otros activos importantes del negocio, 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, sistemas, redes y personas relacionados 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 la organización, los riesgos de seguridad de la información siempre se encuentran presentes. La seguridad de la información efectiva reduce estos riesgos mediante la protección de la organización frente a amenazas y vulnerabilidades, y luego reduce los impactos a sus activos. La seguridad de la información se logra mediante la implementación de un conjunto adecuado de controles, incluyendo políticas, procesos, procedimientos, estructuras organizacionales y las funciones de software y hardware. Estos controles necesitan ser establecidos, implementados, monitoreados, revisados y mejorados, donde sea necesario, para garantizar que los objetivos específicos de seguridad y de negocios 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 NTP-ISO/IEC 27001 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 iii

la NTP-ISO/IEC 27001 y de este esquema de norma técnica peruana. La seguridad que se puede lograr a través de medios técnicos es limitada y debería ser apoyada por una gestión y procedimientos adecuados. Identificar qué controles deberían estar en su lugar requiere una planificación cuidadosa y atención al detalle. Un sistema de gestión de seguridad de la información (SGSI) exitoso requiere el apoyo de todos los empleados de la organización. Puede requerir también la participación de las partes interesadas, los proveedores u otras partes externas. Asesoría especializada de partes externas puede también ser necesaria. En un sentido más general, la seguridad de la información efectiva asegura también a la gestión y otros interesados que los activos organizacionales están razonablemente seguros y protegidos contra daños, actuando así como un habilitador del negocio.

0.2

Requisitos de seguridad de la información

Es esencial que la organización identifique sus requisitos de seguridad. Hay tres fuentes principales de requisitos de seguridad: a)

la evaluación del riesgo para la organización, tomando en cuenta su estrategia global de negocios y sus objetivos. A través de una evaluación del riesgo, son identificadas las amenazas a los activos, la vulnerabilidad y probabilidad de ocurrencia son evaluadas y su impacto potencial es estimado;

b)

los requisitos legales, estatutarios, regulatorios y contractuales son satisfechos por la organización, sus socios comerciales, contratistas, proveedores de servicio, y su entorno socio-cultural;

c)

el conjunto de principios, objetivos y requisitos de negocio para el manejo, procesamiento, almacenamiento, comunicación y archivo de información que una organización ha desarrollado para apoyar sus operaciones.

Los recursos empleados en la implementación de los controles necesitan ser equilibrados con el daño comercial probablemente resultado de problemas de seguridad por ausencia de estos controles. Los resultados de una evaluación del riesgo ayudarán a orientar y a determinar las acciones y prioridades de gestión apropiadas para la gestión de los riesgos de seguridad de la información y para la implementación de los controles seleccionados para protegerse contra esos riesgos. La NTP-ISO/IEC 27005 proporciona orientación sobre la gestión del riesgo de seguridad de la información, incluyendo el asesoramiento sobre la evaluación del riesgo, el tratamiento del riesgo, la aceptación del riesgo, la comunicación del riesgo, el monitoreo del riesgo y la revisión del riesgo.

0.3

Seleccionando controles

Los controles pueden ser elegidos de este esquema de norma técnica peruana o de otro conjunto de controles, o nuevos controles pueden ser diseñados para cubrir adecuadamente necesidades específicas. iv

La selección de los controles depende de las decisiones organizacionales basadas en los criterios para la aceptación del riesgo, las opciones para el tratamiento del riesgo y el enfoque general a la gestión del riesgo aplicado a la organización, y debería también estar conforme a toda la legislación y regulaciones nacionales e internacionales relevantes. La selección de controles depende también de la manera en que interactúan los controles para proporcionar defensa en profundidad. Algunos de los controles de este esquema de norma técnica peruana 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 a continuación a lo largo de 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 NTP-ISO/IEC 27005.

0.4

Desarrollando sus propias directrices

Este esquema de norma técnica peruana puede ser considerado como un punto de partida para desarrollar directrices específicas de la organización. Pueden no ser aplicables todas las recomendaciones y controles de este código de práctica. Incluso, pueden requerirse controles y recomendaciones adicionales que este esquema de norma técnica peruana no incluye. Cuando sean desarrollados documentos que contengan controles y recomendaciones adicionales, puede ser útil incluir referencias cruzadas con las cláusulas de este esquema de norma técnica peruana donde sea aplicable para facilitar la verificación del cumplimiento por los auditores y socios del negocio.

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 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, testeados, 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 a los sistemas existentes presentan oportunidades para que las organizaciones actualicen y mejoren los controles de seguridad, tomando en cuenta los incidentes actuales y comunes y los riesgos proyectados de seguridad de la información.

0.6

Normas relacionadas

Mientras que este esquema de norma técnica peruana 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 asesoría complementaria o requisitos sobre otros aspectos del proceso v

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 miembro de la familia.

--- oooOooo ---

vi


PNTP-ISO/IEC 27001 7 de 124

TECNOLOGÍA DE LA INFORMACIÓN ― Técnicas de seguridad. ― Código de práctica para los controles de Seguridad de la información 1.

ALCANCE

Este esquema de norma técnica peruana proporciona lineamientos para normas organizacionales de seguridad de la información y prácticas de gestión de seguridad de la información, incluyendo la selección, implementación y gestión de controles tomando en consideración los riesgos del entorno de seguridad de la información de la organización. Este esquema de norma técnica peruana está diseñado para ser utilizado por las organizaciones que pretendan:

2.

a)

seleccionar los controles dentro del proceso de implementación del Sistema de Gestión de Seguridad de la Información basado en la NTP-ISO/IEC 27001;

b)

implementar los controles de seguridad de la información comúnmente aceptados;

c)

desarrollar sus propios lineamientos de gestión de seguridad de la información.

REFERENCIAS NORMATIVAS

Los siguientes documentos, en su totalidad o en parte, son normativamente referenciados en este esquema de norma técnica peruana y son indispensables para su aplicación. Para las referencias fechadas, solo se aplica la edición citada. Para las referencias sin fecha, se aplica la última edición del documento referenciado (incluyendo cualquier modificación). ISO/IEC 27000, Information technology - Security techniques – Information security management systems - Overview and vocabulary

3.

TÉRMINOS Y DEFINICIONES

Para los propósitos de este esquema de norma técnica peruana, se aplican los términos y definiciones de la norma ISO/IEC 27000.

4.

ESTRUCTURA DE ESTA NORMA

Este esquema de norma técnica peruana contiene 14 cláusulas de control de seguridad que en su conjunto contienen un total de 35 categorías principales de seguridad y 114 controles. 7


4.1


Cláusulas

Cada cláusula define controles de seguridad conteniendo una o más categorías principales de seguridad. El orden de las cláusulas en este esquema de norma técnica peruana no implica su importancia. Dependiendo de las circunstancias, los controles de seguridad de cualquiera o de todas las cláusulas podrían ser importantes, por lo tanto cada organización que aplica este esquema de norma técnica peruana debería identificar los controles aplicables, qué tan importantes son y su aplicación a los procesos individuales del negocio. Además, todas las listas en este esquema de norma técnica peruana no están en orden de prioridad.

4.2

Categorías de control

Cada categoría principal de control de seguridad contiene: a)

un objetivo de control que indica lo que se va a lograr;

b)

uno o más controles que pueden ser aplicados para alcanzar el objetivo de control.

Las descripciones del control se estructuran de la siguiente manera: Control Define la declaración específica del control, para satisfacer el objetivo de control. Guía de implementación Proporciona información más detallada para apoyar la implementación del control y el cumplimiento del objetivo de control. La guía puede no ser del todo adecuada o suficiente en todas las situaciones y puede no cumplir con los requisitos específicos de control de la organización. Otra información Proporciona información adicional que puede ser necesario considerar, por ejemplo, consideraciones legales y referencias a otras normas. Si no hay más información para ser proporcionada, esta parte no se muestra.

5.

POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓN

5.1

Dirección de la gerencia para la seguridad de la información

Objetivo: Proporcionar dirección y apoyo de la gerencia para la seguridad de la información en concordancia con los requisitos del negocio y las leyes y regulaciones relevantes. 8


5.1.1


Políticas para la seguridad de la información

Control Un conjunto de políticas para la seguridad de la información debería ser definido, aprobado por la gerencia, publicado y comunicado a los empleados y a las partes externas relevantes. 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 es aprobada por la gere ncia y que establece el enfoque de la organización para gestionar los objetivos de seguridad de la información. Las políticas de seguridad de la información deberían abordar los requisitos creados por: a) la estrategia del negocio; b) las regulaciones, leyes y contratos; c) el entorno de amenazas de seguridad de la información actuales y previstas. La política de seguridad de la información debería contener declaraciones respecto a: a) definición de la seguridad de la información, objetivos y principios para orientar todas las actividades relacionadas con la seguridad de la información; b) asignación de responsabilidades generales y específicas para la gestión de seguridad de la información en los roles definidos; c) procesos para el manejo de desviaciones y excepciones. En un nivel inferior, la política de seguridad de la información debería ser apoyada por las políticas sobre temas específicos, las cuales exigen aún más la implementación de los controles de seguridad de la información y se estructuran normalmente para guiar las necesidades de determinados grupos dentro de una organización o para cubrir ciertos temas. Algunos ejemplos de estos temas detallados en políticas son: a) control de acceso (ver cláusula 9); b) clasificación (y manejo) de la información (ver 8.2); c) seguridad física y ambiental (ver cláusula 11); d) temas orientados al usuario final, tales como: 1.uso aceptable de activos (ver 8.1.3); 9



2.escritorio y pantalla limpios (ver 11.2.9); 3.transferencia de información (ver 13.2.1); 4.dispositivos móviles y teletrabajo (ver 6.2); 5.restricciones a las instalaciones y uso del software (ver 12.6.2); e) respaldo (backup) (ver 12.3); f) transferencia de información (ver 13.2); g) protección contra códigos maliciosos (ver 12.2); h) gestión de vulnerabilidades técnicas (ver 12.6.1); i) controles criptográficos (ver cláusula 10); j) seguridad de las comunicaciones (ver cláusula 13); k) privacidad y protección de datos personales (ver 18.1.4); l) relaciones con los proveedores (ver cláusula 15). Estas políticas deberían comunicarse a los empleados y a las partes externas relevantes de forma que sea pertinente, accesible y comprensible para el lector previsto, por ejemplo, en el contexto de una “creación de conciencia de seguridad de la información, educación y progr ama de capacitación” (ver 7.2.2). Otra información La necesidad de políticas internas de seguridad de la información varía en las organizaciones. Las políticas internas son especialmente útiles en las organizaciones más grandes y más complejas, donde, los que definen y aprueban los niveles de control esperados se encuentran separados de los que implementan los controles o en situaciones en que una política aplica a muchas personas o funciones dentro de la organización. Las políticas de seguridad de la información se pueden incluir en un solo documento “política de seguridad de la información”, o como un conjunto de documentos individuales pero relacionados. Si alguna de las políticas de seguridad de la información es distribuida fuera de la organización, se debería tener cuidado de no revelar información confidencial. Algunas organizaciones utilizan otros términos para estos documentos de políticas, tales como “Normas”, “Directivas” o “Reglas”.

5.1.2

Revisión de las políticas para la seguridad de la información

Control 10



Las políticas para la seguridad de la información deberían ser revisadas a intervalos planificados o si ocurren cambios significativos para asegurar su conveniencia, adecuación y efectividad continua. 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 ambiente de la organización, a las circunstancias del negocio, a las condiciones legales o al ambiente técnico. La revisión de las políticas de seguridad de la información debería tomar los resultados de las revisiones de la gerencia. Debería obtenerse la aprobación de la gerencia para la política r evisada.

6.

ORGANIZACIÓN DE LA SEGURIDAD DE LA INFORMACIÓN

6.1

Organización interna

Objetivo: establecer un marco de referencia de gestión para iniciar y controlar la implementación y operación de la seguridad de la información dentro de la organización.

6.1.1

Roles y responsabilidades para la seguridad de la información

Control Todas las responsabilidades de seguridad de la información deberían ser definidas y asignadas. Guía de implementación La asignación de las responsabilidades de seguridad de la información debería hacerse de acuerdo con las políticas de seguridad de la información (ver 5.1.1). Debería identificarse las responsabilidades para la protección de los activos individuales y para la realización de procesos específicos de seguridad de la información. Debería definirse las responsabilidades de las actividades de gestión de riesgos de seguridad de la información, y en particular, la aceptación de riesgos residuales. Estas responsabilidades deberían complementarse, cuando sea necesario, con directrices más detalladas para sitios específicos e instalaciones de procesamiento de información. Debería definirse las responsabilidades locales para la protección de activos y para llevar a cabo los procesos específicos de seguridad. Las personas con responsabilidades asignadas de seguridad de la información pueden delegar tareas de seguridad a otras. Sin embargo, siguen siendo responsables y deberían determinar que las tareas delegadas han sido correctamente realizadas. 11



Las áreas en que las personas son responsables deberían establecerse. En particular, debería ocurrir lo siguiente: a)

los activos y los procesos de seguridad de la información deberían identificarse y definirse;

b)

una entidad responsable de cada activo o proceso de seguridad de la información debería asignarse y los detalles de esta responsabilidad deberían ser documentados (ver 8.1.2);

c)

los niveles de autorización deberían definirse y documentarse ;

d)

para ser capaces de cumplir con las responsabilidades en el área de seguridad de la información, las personas designadas deberían ser competentes en el área y se les debería brindar oportunidades de estar actualizados continuamente;

e)

la coordinación y supervisión de los aspectos de seguridad de la información de las relaciones con los proveedores debería identificarse y documentarse.

Otra información Muchas organizaciones designan un administrador de seguridad de la información para asumir las responsabilidades globales del desarrollo y la implementación de la seguridad de la información y para apoyar la identificación de los controles. Sin embargo, la responsabilidad de proporcionar los recursos y de la implementación de los controles generalmente recae sobre los administradores. Una práctica común es designar un propietario para cada activo, que luego se convierte en responsable de su protección en el día a día.

6.1.2

Segregación de funciones

Control Las funciones y áreas de responsabilidad en conflicto deberían ser 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 Debería tenerse cuidado de que ninguna persona pueda acceder, modificar o utilizar activos sin autorización o 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 12



gerencia. Otra información La segregación de funciones es un método para reducir el riesgo del mal uso accidental o deliberado de los activos de la organización. or ganización.

6.1.3

Contacto con autoridades

Control Contactos apropiados con autoridades relevantes deberían ser mantenidos. Guía de implementación Las organizaciones deberían tener procedimientos vigentes que especifiquen cuándo y qué autoridades (por ejemplo, cumplimiento de leyes, 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 l a ley). Otra información Las organizaciones que están siendo atacadas desde Internet pueden necesitar que las autoridades tomen acciones contra el origen del ataque. El mantenimiento de dichos contactos puede ser un requerimiento para apoyar la gestión de incidentes de seguridad de la información (ver cláusula 16) o el proceso de continuidad del negocio o el plan de contingencia (ver cláusula 17). Los contactos con instituciones reguladoras son también útiles para anticiparse y prepararse para cambios próximos de la ley o regulaciones, los cuales tienen que ser implementados por las organizaciones. Los contactos con otras autoridades incluyen servicios públicos, servicios de emergencia, proveedores de electricidad, salud y seguridad, por ejemplo departamento de bomberos (en relación con la continuidad del negocio), los proveedores de telecomunicaciones (en relación con el ruteo de líneas y su disponibilidad) y los proveedores de agua (en relación con las instalaciones de refrigeración para el equipamiento).

6.1.4

Contacto con grupos especiales de interés

Control Contactos apropiados apropiados con grupos especiales de interés interés u otros foros de especialistas en en seguridad y asociaciones profesionales deberían ser mantenidos. Guía de implementación La membrecía en foros o grupos de interés especial debería considerarse como un medio para: a)

incrementar el conocimiento sobre las mejores prácticas y mantenerse al día 13



sobre seguridad de la información relevante; b)

garantizar que la comprensión del ambiente de seguridad seguridad de la información es actual y completa;

c)

recibir advertencias oportunas de alertas, avisos y parches referidos a ataques y vulnerabilidades;

d)

obtener acceso a asesoría especializada sobre seguridad de la información;

e)

compartir e intercambiar información sobre nuevas tecnologías, productos, amenazas o vulnerabilidades;

f)

proveer puntos de coordinación adecuados para el manejo de incidentes de seguridad de la información (ver cláusula 16).

Otra información Pueden establecerse acuerdos para compartir la información a manera de mejorar la cooperación y la coordinación de temas de seguridad. Tales acuerdos deberían identificar los requisitos para la protección de información confidencial.

6.1.5

Seguridad de la información en la gestión de proyectos

Control La seguridad de la información debería ser tratada en la gestión de proyectos, sin importar el tipo de proyecto. Guía de implementación La seguridad de la información debería integrarse en el método de gestión de proyectos de la organización para garantizar que los riesgos de seguridad de la información son identificados y tratados como parte de un proyecto. Esto se aplica en general a cualquier proyecto, independientemente de su carácter, por ejemplo, un proyecto para un proceso clave de negocios, TI, gestión de instalaciones y otros procesos de apoyo. Los métodos de gestión de proyectos en uso deberían exigir que: a)

los objetivos de seguridad de la información sean incluidos en los objetivos del proyecto;

b)

una evaluación de riesgos de seguridad seguridad de la información se lleve a cabo en una etapa temprana del proyecto para identificar los controles necesarios;

c)

la seguridad seguridad de la información es parte de todas las fases de la metodología del proyecto aplicada.

Las implicaciones de seguridad de la información deberían tratarse y revisarse regularmente en todos los proyectos. Las responsabilidades de seguridad de la información deberían definirse y asignarse a roles específicos definidos en los métodos de 14



gestión de proyectos.

6.2

Dispositivos móviles y teletrabajo

Objetivo: Asegurar Asegurar la seguridad del teletrabajo y el uso de los dispositivos móviles.

6.2.1

Política de dispositivos móviles

Control Una política y medidas de seguridad de soporte deberían ser adoptadas para gestionar 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 garantizar que la información del negocio no se vea comprometida. La política de dispositivos móviles debería tener en cuenta los riesgos de trabajar con dispositivos móviles en entornos desprotegidos. La política de dispositivos móviles debería considerar: a)

el registro de los dispositivos móviles;

b)

los requisitos de protección física;

c)

la restricción de instalación de software;

d)

los requisitos de las versiones de software de los dispositivos móviles y para la aplicación de parches;

e)

la restricción de la conexión a los servicios de información;

f)

los controles de acceso,

g)

técnicas criptográficas;

h)

protección contra software malicioso;

i)

desactivación, eliminación o bloqueo a distancia;

j)

copias de seguridad;

k)

uso de servicios web y aplicaciones web.

Debería tenerse cuidado al utilizar dispositivos móviles en lugares públicos, salas de reuniones y otras áreas no protegidas. Para evitar el acceso no autorizado o la divulgación de la información almacenada y procesada por estos dispositivos debería implantarse la protección, por ejemplo, utilizando técnicas criptográficas (ver cláusula 10) y forzando el uso de información secreta para la autenticación (ver 9.2.4). 15



Los dispositivos móviles deberían protegerse también físicamente contra el robo, especialmente cuando se dejan, por ejemplo, en autos y otras formas de transporte, habitaciones de hotel, centros de congresos y lugares de reunión. Debería establecerse un procedimiento teniendo en cuenta requisitos legales, del seguro y otros requisitos de seguridad de la organización para los casos de robo o pérdida de dispositivos móviles. Los dispositivos que llevan información importante, sensible o crítica de la empresa no deberían dejarse desatendidos y, cuando sea posible, deberían ser físicamente bloqueados o deberían utilizarse bloqueos especiales para asegurar los dispositivos. Debería proporcionarse capacitación al personal que utiliza dispositivos móviles para concientizarlos sobre los riesgos adicionales derivados de esta forma de trabajo y los controles que deberían implementarse. Cuando la política de dispositivos móviles permite el uso de dispositivos móviles de propiedad privada, la política y las medidas de seguridad relacionadas deberían considerar también: a)

la separación del uso privado y de negocios de los dispositivos, incluido el uso de software para apoyar dicha separación y proteger los datos de negocios en un dispositivo privado;

b)

proveer acceso a la información de negocios, solo después de que los usuarios han firmado un acuerdo de usuario final, reconociendo sus obligaciones (protección física, actualización de software, etc.), renunciando a la propiedad de los datos de negocios, lo que permite la eliminación remota de los datos por parte de la organización en caso de robo o pérdida del dispositivo o cuando ya no se encuentran autorizados a utilizar el servicio. Esta política debería tener en cuenta la legislación sobre pr ivacidad.

Otra información Las conexiones inalámbricas de los dispositivos móviles son similares a otros tipos de conexión de red, pero tienen diferencias importantes que deberían tenerse en cuenta al identificar los controles. Las diferencias típicas son: a)

algunos protocolos de seguridad inalámbrica son inmaduros y tienen debilidades conocidas;

b)

la información almacenada en los dispositivos móviles puede que no sea respaldada debido a la banda ancha limitada o a que los dispositivos móviles no se encuentren conectados en los momentos en que se programan los respaldos.

Generalmente, los dispositivos móviles comparten funciones comunes, por ejemplo, redes, acceso a Internet, correo electrónico y manejo de archivos, con los dispositivos de uso fijo. Los controles de seguridad de la información consisten generalmente, en los adoptados por los dispositivos de uso fijo y en los que abordan las amenazas planteadas 16



por su uso fuera de los locales de la organización.

6.2.2

Teletrabajo

Control Una política y medidas de seguridad de apoyo deberían ser implementadas para proteger información a la que se accede, se procesa o almacena en 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: a)

la seguridad física existente en el sitio de teletrabajo, considerando la seguridad física del edificio y del entorno local;

b)

el entorno físico de teletrabajo propuesto;

c)

los requisitos de seguridad de las comunicaciones, teniendo en cuenta la necesidad de acceso remoto a los sistemas internos de la organización, la sensibilidad de la información a ser accedida y pasada sobre el enlace de comunicación y la sensibilidad del sistema interno;

d)

la provisión de acceso al escritorio virtual que impide el procesamiento y el almacenamiento de información sobre el equipo de propiedad privada;

e)

la amenaza de acceso no autorizado a la información o a los recursos por parte de otras personas que utilizan el ambiente, por ejemplo, acceso por familiares y amigos;

f)

el uso de redes domésticas y requisitos o restricciones de la configuración de los servicios de red inalámbricos;

g)

las políticas y los procedimientos para evitar conflictos relativos a los derechos de propiedad intelectual desarrollados en los equipos de propiedad privada;

h)

el acceso a los equipos de propiedad privada (para verificar la seguridad del equipo o durante la investigación), que puede ser impedido por la legislación;

i)

los acuerdos de licencia de software son tales que las organizaciones pueden ser responsables de la concesión de licencias de software cliente en estaciones de trabajo de propiedad privada de los empleados o de usuarios de terceras partes;

j)

la protección ante software malicioso y los requisitos de firewall. 17



Las directrices y las disposiciones a considerar deberían incluir: a)

el suministro de equipo adecuado y mobiliario de almacenamiento para las actividades de teletrabajo, donde no se permite el uso de equipo de propiedad privada, que no se encuentra bajo control de la organización;

b)

una definición del trabajo permitido, las horas de trabajo, la clasificación de la información que se puede realizar y los sistemas y servicios internos a los que el teletrabajador se encuentra autorizado a acceder;

c)

el suministro de equipo adecuado de comunicación, incluyendo los métodos para asegurar el acceso remoto;

d)

la seguridad física;

e)

las reglas y directrices del acceso de la familia y visitas al equipo y la información;

f)

el suministro de soporte y mantenimiento de hardware y software;

g)

la provisión de seguros;

h)

los procedimientos para el respaldo y la continuidad del negocio;

i)

la auditoría y el monitoreo de la seguridad;

j)

la revocación de la autoridad y de los derechos de acceso, y la devolución de los equipos cuando las actividades de teletrabajo finalizan.

Otra información El teletrabajo se refiere a todas las formas de trabajo fuera de la oficina, incluyendo los ambientes de trabajo no tradicionales, tales como los ambientes denominados “trabajo a distancia”, “trabajo flexible”, “trabajo remoto” y “trabajo virtual”.

7.

SEGURIDAD DE LOS RECURSOS HUMANOS

7.1

Antes del empleo

Objetivo: Asegurar que los empleados y contratistas entienden sus responsabilidades y son convenientes para los roles para los que se les considera.

7.1.1

Selección

Control Las verificaciones de los antecedentes de todos los candidatos a ser empleados deberían ser llevadas a cabo en concordancia con las leyes, regulaciones y ética relevantes, y debería ser proporcional a los requisitos del negocio, la clasificación de la información a la 18



que se tendrá acceso y los riesgos percibidos. Guía de implementación La verificación debería tener en cuenta toda la legislación relevante sobre privacidad, protección de datos personales y/o relativa al empleo y, debería, donde sea permitido, incluir lo siguiente: a)

disponibilidad de referencias satisfactorias, por ejemplo, una de negocios y una personal;

b)

una verificación (para integridad y exactitud) del currículum vitae del postulante;

c)

confirmación de las calificaciones académicas y profesionales declaradas;

d)

verificación independiente de identidad (pasaporte o documento similar);

e)

verificaciones más detalladas, tales como revisión de crédito o antecedentes criminales.

Cuando una persona es contratada para un rol específico en seguridad de la información, las organizaciones deberían asegurarse que el candidato: a)

tenga las competencias necesarias para desempeñar el rol de seguridad;

b)

pueda ser confiable para asumir el rol, especialmente si el rol es crítico para la organización.

Cuando una tarea, tanto en un nombramiento inicial o en un ascenso, involucre que la persona tenga acceso a instalaciones de procesamiento de información, y, en particular, si éstas están manejando información confidencial, por ejemplo, información financiera o altamente confidencial, la organización debería también considerar verificaciones adicionales más detalladas. Los procedimientos deberían definir criterios y limitaciones para revisiones de verificación, por ejemplo, quién es elegible para seleccionar personal, y cómo, cuándo y por qué se han de realizar las revisiones de verificación. Debería también realizarse un proceso de selección para contratistas. En estos casos, el acuerdo entre la organización y el contratista debería especificar las responsabilidades para conducir la selección y los procedimientos de notificación que necesitan seguir si la selección no ha sido completada o si los resultados ocasionan duda o preocupación. Debería recopilarse la información de todos los candidatos a ser considerados para posiciones dentro de la organización y debería manejarse de acuerdo con la legislación apropiada existente en la jurisdicción relevante. Dependiendo de la legislación aplicable, los candidatos deberían informarse con antelación sobre las actividades de selección.

7.1.2

Términos y condiciones del empleo 19



Control Los acuerdos contractuales con los empleados y contratistas deberían estipular responsabilidades de estos y de la organización respecto de la seguridad de la información. Guía de implementación Las obligaciones contractuales de los empleados o contratistas deberían reflejar las políticas de la organización para seguridad de la información, además de aclarar y enunciar: a)

que todos los empleados y contratistas a los cuales se les da acceso a información confidencial deberían firmar un acuerdo de confidencialidad o de no-divulgación previamente a ser otorgado el acceso a las instalaciones de procesamiento de información (ver 13.2.4);

b)

las responsabilidades y derechos legales de los empleados y contratistas, como por ejemplo, relativas a derecho de copia o legislación de protección de datos (ver 18.1.4);

c)

responsabilidades para la clasificación de información y gestión de activos de la organización asociados con la información, las instalaciones de procesamiento de información y los servicios de información manejados por el empleado o contratista (ver cláusula 8);

d)

responsabilidades del empleado o contratista por el manejo de información recibida de otras organizaciones o partes externas;

e)

acciones a ser tomadas si el empleado o contratista desatiende los requisitos de seguridad de la organización (ver 7.2.3);

Los roles y responsabilidades en seguridad de la información deberían comunicarse a los candidatos durante el proceso de pre-empleo. La organización debería garantizar que los empleados y contratistas acuerden en los términos y condiciones concernientes a la seguridad de la información, apropiada a la naturaleza y extensión de acceso que ellos tendrán a los activos de la organización asociados con los sistemas y servicios de información. Cuando sea apropiado, las responsabilidades contenidas dentro de los términos y condiciones de empleo deberían continuar por un período definido luego de la finalización del empleo (ver 7.3). Otra información Se puede usar un código de conducta para cubrir las responsabilidades de seguridad de la información de los empleados o contratistas referentes a confidencialidad, protección de datos, normas éticas, uso apropiado de los equipos e instalaciones de la organización, 20



además de prácticas honestas esperadas por la organización. La parte externa, con la que el contratista esta asociado, puede requerir ingresar en acuerdos contractuales en nombre del individuo contratado.

7.2

Durante el empleo

Objetivo: Asegurar que los empleados y contratistas sean conscientes y cumplan con sus responsabilidades de seguridad de la información.

7.2.1

Responsabilidades de la gerencia

Control La gerencia debería requerir a todos los empleados y contratistas aplicar la seguridad de la información en concordancia con las políticas y procedimientos establecidos por la organización. Guía de implementación Las responsabilidades de la gerencia deberían incluir el asegurar que los empleados y contratistas: a)

sean apropiadamente instruidos sobre sus roles y responsabilidades de seguridad antes de que se les otorgue acceso a información confidencial o a sistemas de información;

b)

se les proporcione orientaciones para hacer constar las expectativas sobre la seguridad de su rol dentro de la organización;

c)

sean motivados a cumplir con las políticas de seguridad de la organización;

d)

logren un nivel de conciencia sobre seguridad relevante a sus roles y responsabilidades dentro de la organización (ver 7.2.2);

e)

se ajusten a los términos y condiciones del empleo, lo cual incluye la política de seguridad de la información de la organización y métodos apropiados de trabajo;

f)

continúen teniendo habilidades y calificaciones apropiadas y sean capacitados de manera regular;

g)

estén provistos con un canal de reportes anónimos para reportar violaciones de políticas o procedimientos de seguridad de la información (“alerta de irregularidades”).

La gerencia debería demostrar el apoyo a las políticas, los procedimientos y controles de seguridad de la información, y actuar como un modelo a seguir. Otra información 21



Si los empleados y contratistas no son concientizados de sus responsabilidades de seguridad, pueden causar un daño considerable a la organización. El personal motivado es probable que sea más confiable y ocasione menos incidentes de seguridad de la información. Una gestión pobre puede causar que el personal se sienta subvaluado resultando en un impacto negativo en la seguridad 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.

7.2.2 Conciencia, educación y capacitación sobre la seguridad de la información Control Todos los empleados de la organización y, cuando fuera relevante, los contratistas deberían recibir educación y capacitación sobre la conciencia de la seguridad de la información, así como actualizaciones regulares sobre políticas y procedimientos de la organización, según sea relevante para la función del trabajo que cumplen. Guía de implementación Un programa de concienciación en seguridad de la información debería tener como objetivo que los empleados, y cuando sea relevante, los contratistas sean conscientes de sus responsabilidades en seguridad de la información y los medios para que esas responsabilidades sean liberadas. Debería establecerse un programa de concienciación en seguridad de la información de acuerdo con las políticas de seguridad de la información de la organización y los procedimientos relevantes, tomando en consideración la información de la organización a ser protegida, y los controles que han sido implementados para proteger la información. El programa de concienciación debería incluir un número de actividades de sensibilización, tales como campañas (por ejemplo, día de seguridad de la información) y los folletos o boletines informativos. Debería planificarse el programa de concienciación tomando en consideración los roles de los empleados en la organización, y, cuando sea relevante, las expectativas de la organización en la concienciación de los contratistas. Las actividades en el programa de concienciación deberían planificarse en el tiempo, de preferencia con regularidad, por lo que las actividades se repiten y abarcan los nuevos empleados y contratistas. El programa de concienciación también debería actualizarse regularmente de acuerdo con las políticas y los procedimientos organizacionales, y debería basarse en las lecciones aprendidas de los incidentes de seguridad de la información. La creación de conciencia debería realizarse según lo requiera el programa de concienciación en seguridad de la información de la organización. Se pueden utilizar diferentes medios para la creación de conciencia, incluyendo presencial, educación a distancia, basado en la web, auto-aprendizaje a su propio ritmo y otros. La educación y la capacitación en seguridad de la información debería abarcar también 22



aspectos generales, tales como: a)

declaración del compromiso de la gerencia con la seguridad de la información en toda la organización;

b)

la necesidad de familiarizarse y cumplir con las reglas y obligaciones aplicables en seguridad de la información, según se define en las políticas, normas, leyes, regulaciones, contratos y acuerdos;

c)

la responsabilidad personal por las propias acciones y omisiones, y las responsabilidades generales hacia garantizar o proteger la información que pertenece a la organización y a las partes externas;

d)

los procedimientos básicos de seguridad de la información (tales como el reporte de incidentes de seguridad de la información) y los controles básicos (tales como la contraseña de seguridad, los controles ante software malicioso y los escritorios limpios);

e)

los puntos de contacto y los recursos de información y asesoramiento en materia de seguridad de la información, incluyendo otros materiales de educación y capacitación en seguridad de la información .

La educación y capacitación en seguridad de la información debería tener lugar periódicamente. La educación y capacitación inicial se aplica a quienes son transferidos a nuevas posiciones o roles con requisitos sustancialmente diferentes en seguridad de la información, no solo a los nuevos empleados y debería llevarse a cabo antes de que el rol este activo. La organización debería desarrollar un programa de educación y capacitación con el fin de llevar a cabo la educación y capacitación de manera efectiva. El programa debería estar alineado con las políticas de seguridad de la información de la organización y los procedimientos relevantes, tomando en consideración la información de la organización a ser protegida y los controles que han sido implementados para proteger la información. El programa debería considerar las diferentes formas de educación y capacitación, por ejemplo, lecturas o auto-estudio. Otra información Al redactar un programa de concienciación, es importante no solo centrarse en el “qué” y “cómo”, sino también en el “por qué”. Es importante que los empleados comprendan el objetivo de la seguridad de la información y el impacto potencial, positivo y negativo, sobre la organización de su propio comportamiento. La concienciación, la educación y la capacitación pueden ser parte de, o llevarse a cabo con la colaboración de otras actividades de capacitación, por ejemplo, TI en general o capacitación general en seguridad. Las actividades de concienciación, educación y capacitación deberían adecuarse y ser relevantes a los roles individuales, las responsabilidades y las habilidades . Debería llevarse a cabo una evaluación de la comprensión de los empleados al final de un 23



curso de concienciación, educación y capacitación para poner a prueba la transferencia de conocimientos.

7.2.3

Proceso disciplinario

Control Debería haber un proceso disciplinario formal y comunicado para tomar acción contra empleados que hayan cometido una infracción a la seguridad de la información. Guía de implementación El proceso disciplinario no debería comenzar sin una verificación previa de que una infracción a la seguridad de la información ha ocurrido (ver 16.1.7). El proceso disciplinario formal debería garantizar un tratamiento correcto y justo para los empleados de quienes se sospecha que han cometido infracción a 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 fue la primera ofensa o una repetición, si el violador fue o no apropiadamente capacitado, legislación relevante, contratos de negocio y otros factores que se requieran. El proceso disciplinario también debería usarse como disuasión para prevenir que los empleados violen las políticas y procedimientos de seguridad de la información organizacionales, y cualquier otra infracción a la seguridad de la información. Las infracciones deliberadas pueden requerir acciones inmediatas. Otra información El proceso disciplinario también puede convertirse en una motivación o incentivo si las sanciones positivas son definidas para el comportamiento destacable con respecto a la seguridad de la información.

7.3

Terminación y cambio de empleo

Objetivo: Proteger los intereses de la organización como parte del proceso de cambio o terminación de empleo.

7.3.1

Terminación o cambio de responsabilidades del empleo.

Control Las responsabilidades y deberes de seguridad de la información que siguen siendo válidos luego de la terminación o cambio de empleo deberían ser definidos, comunicados al empleado o contratista y forzar su cumplimiento. Guía de implementación La comunicación de las responsabilidades en la desvinculación debería incluir los 24



requisitos de seguridad de la información y las responsabilidades legales en curso y, cuando sea apropiado, las responsabilidades contenidas dentro de cualquier acuerdo de confidencialidad (ver 13.2.4), y los términos y condiciones de empleo (ver 7.1.2) deberían continuar por un período de tiempo definido luego de la desvinculación del empleado o el empleado del contratista. El contrato del empleado o contratista debería contener las responsabilidades y deberes que permanecen válidos aún luego de la desvinculación (ver 7.1.2). Deberían gestionarse los cambios en las responsabilidades o en la relación laboral y la desvinculación de la nueva responsabilidad o relación laboral, combinada con el inicio de la nueva responsabilidad o empleo. Otra información La función de recursos humanos generalmente es responsable por el proceso completo de desvinculación laboral y trabaja junto con el supervisor de la persona desvinculada para gestionar los aspectos de seguridad de la información de los procedimientos relevantes. En el caso de un contratista, proporcionado a través de un tercero, este proceso de desvinculación puede ser llevado a cabo por el tercero en conformidad con el contrato entre la organización y este tercero. Puede ser necesario informar a los empleados, clientes, o contratistas de los cambios en los acuerdos operativos y de personal.

8.

GESTIÓN DE ACTIVOS

8.1

Responsabilidad por los activos

Objetivo: Identificar los activos de la organización y definir las responsabilidades de protección apropiadas.

8.1.1

Inventario de activos

Control La información, otros activos asociados con la información y las instalaciones de procesamiento de la información deberían ser identificados y un inventario de estos debería ser realizado y mantenido. Guía de implementación Una organización debería identificar los activos relevantes en el ciclo de vida de la información y documentar su importancia. El ciclo de vida de la información debería incluir la creación, elaboración, almacenamiento, transmisión, eliminación y destrucción. La documentación debería mantenerse en inventarios dedicados o existentes, según corresponda. El inventario de activos debería ser preciso, actualizado, consistente y alineado con otros 25



inventarios. Para cada uno de los activos identificados, debería asignarse un propietario (ver 8.1.2) y debería identificarse la clasificación (ver 8.2). Otra información Los inventarios de activos ayudan a garantizar que se logre la protección eficaz, pero también pueden ser requeridos para otros propósitos, como por ejemplo por razones de salud y salubridad, financieras o de seguros (gestión de activos). La Norma ISO/IEC 27005 proporciona ejemplos de activos que podrían necesitar ser considerados por la organización cuando se identifican los activos. El proceso de compilación de un inventario de los activos es un prerrequisito importante de la gestión de riesgos (ver también la Norma ISO/IEC 27000 e ISO/IEC 27005).

8.1.2

Propiedad de los activos

Control Los activos mantenidos en el inventario deberían tener un propietario. 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 propietarias de activos. Generalmente, se implementa un proceso para garantizar la asignación oportuna de la propiedad de los activos. La propiedad debería asignarse cuando los activos son creados o cuando son transferidos a la organización. El propietario de los activos debería ser responsable de la correcta gestión de un activo durante todo el ciclo de vida de ese activo. El propietario del activo debería: a)

garantizar que los activos son inventariados;

b)

garantizar que los activos son clasificados y protegidos adecuadamente;

c)

definir y revisar periódicamente las restricciones de acceso y las clasificaciones de activos importantes, teniendo en cuenta las políticas aplicables de control de acceso;

d)

garantizar el manejo adecuado cuando el activo es eliminado o destruido.

Otra información El propietario identificado puede ser un individuo o una entidad que tiene aprobada la responsabilidad por la gerencia para el control de todo el ciclo de vida de un activo. El propietario identificado no necesariamente tiene derecho de propiedad sobre el activo. 26



Las tareas rutinarias pueden ser delegadas, por ejemplo, a un guardia 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, incluyendo la operación de sus activos.

8.1.3

Uso aceptable de los activos

Control Las reglas para el uso aceptable de la información y activos asociados con la información y con las instalaciones de procesamiento de la información deberían ser identificadas, documentadas e implementadas. Guía de implementación Los empleados y los usuarios de la parte externa que utilizan o tienen acceso a los activos de la organización deberían ser conscientes de los requisitos de la seguridad de la información de la organización, otros activos asociados a la información y con los recursos e instalaciones de procesamiento de la información. Deberían responsabilizarse del uso de los recursos de procesamiento de la información y de cualquier uso llevados a cabo bajo su responsabilidad.

8.1.4

Retorno de activos

Control Todos los empleados y usuarios de terceras partes deberían retornar todos los activos de la organización en su posesión a la conclusión de su empleo, contrato o acuerdo. Guía de implementación El proceso de finalización debería formalizarse para incluir la devolución de todos los activos físicos y electrónicos previamente emitidos pertenecientes o confiados a la organización. En los casos en que un empleado o usuario de parte externa adquiere equipos de la organización o utiliza su propio equipo, deberían seguirse los procedimientos para garantizar que toda la información pertinente sea transferida a la organización y borrada de forma segura del equipo (ver 11.2.7). En los casos en que un empleado o usuario de parte externa tenga conocimiento que es importante para las operaciones en curso, la información debería documentarse y transferirse a la organización. Durante el período de aviso de finalización, la organización debería controlar la copia no autorizada de la información pertinente (por ejemplo, propiedad intelectual) por los 27



empleados y contratistas que desean renunciar.

8.2

Clasificación de la información

Objetivo: Asegurar que la información recibe el nivel apropiado de protección en concordancia con su importancia para la organización.

8.2.1

Clasificación de la información

Control La información debería ser clasificada en términos de los requisitos legales, valor, criticidad y sensibilidad respecto a una divulgación o modificación no autorizada. Guía de implementación La clasificación y los controles de protección asociados a la información deberían tener en cuenta que el negocio necesita compartir o restringir la información, así como los requisitos legales. Los activos que no son de información se pueden clasificar de conformidad con la clasificación de información que es almacenada, procesada o manipulada o protegida por el activo. Los propietarios de los activos de información son responsables de su clasificación. El esquema de clasificación debería incluir las convenciones para la clasificación y los criterios para la revisión de la clasificación en el tiempo. El nivel de protección en el esquema debería evaluarse mediante el análisis de la confidencialidad, integridad y disponibilidad y cualquier otro requisito para la información considerada. El esquema debería estar alineado con la política de control de acceso (ver 9.1.1). Cada nivel debería tener un nombre que tenga sentido en el contexto de la aplicación del esquema de clasificación. El esquema debería ser consistente en toda la organización para que todos clasifiquen la información y los activos relacionados de la misma manera, tengan un entendimiento común de los requisitos de protección y apliquen la protección adecuada. La clasificación debería incluirse en los procesos de la organización y debería ser consistente y coherente en toda la organización. Los resultados de la clasificación deberían indicar el valor de los activos en función de su sensibilidad y criticidad para la organización, por ejemplo, en términos de confidencialidad, integridad y disponibilidad. Los resultados de la clasificación deberían actualizarse de acuerdo con los cambios de su valor, sensibilidad y criticidad durante su ciclo de vida. Otra información 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 28



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 clasificación insuficiente, que puede poner en peligro el logro de los objetivos del negocio. Un ejemplo de un esquema de clasificación de confidencialidad de la información se podría basar en cuatro niveles, de la siguiente manera:

8.2.2

a)

la divulgación no causa ningún daño;

b)

la divulgación causa menor incomodidad o inconveniencia operativa menor;

c)

la divulgación divulgación tiene un impacto significativo por un corto plazo en las operaciones o en los objetivos tácticos;

d)

la divulgación divulgación tiene un grave impacto en los objetivos estratégicos a largo largo plazo o pone en riesgo la supervivencia de la organización.

Etiquetado de la información

Control Un conjunto apropiado de procedimientos para el etiquetado de la información debería ser desarrollado e implementado en concordancia con el esquema de clasificación de la información adoptado por la organización. Guía de implementación Los procedimientos para el etiquetado de la información necesitan cubrir la información y sus activos relacionados relacionados en formato físico y electrónico. electrónico. El etiquetado etiquetado debería reflejar el esquema de clasificación establecido en 8.2.1. Las etiquetas etiquetas deberían deberían reconocerse reconocerse fácilmente. Los procedimientos deberían proporcionar proporcionar orientación sobre sobre dónde y cómo se adjuntan las etiquetas, etiquetas, considerando cómo cómo se accede a la información o se manipulan los activos, en función de los tipos de medios. Los procedimientos pueden definir casos en los que se omite el etiquetado, etiquetado, por ejemplo, el etiquetado etiquetado de información no confidencial confidencial para reducir las cargas de trabajo. Los empleados y los contratistas deberían deberían estar al tanto de los procedimientos del etiquetado. La salida de los sistemas que contienen información clasificada como sensible o crítica debería llevar una etiqueta etiqueta adecuada de de clasificación. Otra información El etiquetado de la información clasificada es un requisito clave para acuerdos que impliquen compartir información. información. Las etiquetas físicas y los los metadatos suelen ser las formas más más comunes comunes de etiquetado. etiquetado. 29



El etiquetado de la información y sus activos relacionados, a veces, pueden tener efectos negativos. Los activos clasificados son fáciles de identificar y por lo tanto ser objeto de robo por parte de los atacantes internos o externos.

8.2.3

Manejo de activos

Control Los procedimientos para el manejo de activos deberían ser desarrollados e implementados en concordancia con el esquema de clasificación de la información adoptado por la organización. Guía de implementación Deberían elaborarse procedimientos para el manejo, procesamiento, almacenamiento y comunicación de la información, de acuerdo con su clasificación (ver 8.2.1). Deberían considerarse los siguientes elementos: a)

las restricciones de acceso que soportan los requisitos de protección para cada nivel de clasificación;

b)

el mantenimiento de un registro formal de los destinatarios autorizados de los activos;

c)

la protección de las copias temporales o permanentes de información a un nivel consistente con la protección de la información original; or iginal;

d)

el almacenamiento de los activos de TI de acuerdo con las especificaciones del fabricante;

e)

borrar el etiquetado de todas las copias copias de los medios medios para la atención atención del destinario autorizado.

El esquema de clasificación utilizado en la organización puede no ser equivalente a los utilizados por otras organizaciones, incluso si los nombres de los niveles son similares; además, la información que se mueve entre organizaciones puede variar en su clasificación dependiendo de su contexto en cada organización, incluso si los esquemas de clasificación son idénticos. Los acuerdos con otras organizaciones que incluyen el intercambio de información deberían incluir procedimientos para identificar la clasificación de la información y para interpretar las etiquetas de clasificación de otras organizaciones.

8.3

Manejo de los medios

Objetivo: Prevenir la divulgación no autorizada, modificación, eliminación o destrucción de la información almacenada en medios. 30


8.3.1


Gestión de medios removibles

Control Se debería implementar procedimientos para la gestión de medios removibles de acuerdo con el esquema de clasificación adoptado por la organización. Guía de implementación Deberían considerarse las siguientes directrices para la gestión de medios removibles: a)

si ya no son requeridos, los contenidos de los medios reutilizables que deberían removerse de la organización, deberían hacerse irrecuperables;

b)

cuando sea necesario y práctico, debería requerirse autorización para remover los medios de la organización y debería mantenerse un registro de dichas remociones, a fin de mantener un registro de auditoría;

c)

todos los medios deberían almacenarse en un ambiente protegido y seguro, de acuerdo con las especificaciones del fabricante;

d)

si la confidencialidad o la integridad de los los datos son consideraciones consideraciones importantes, deberían utilizarse técnicas criptográficas para proteger los datos en los medios removibles;

e)

para mitigar el riesgo de degradación de los medios mientras se necesiten los datos almacenados, los datos deberían transferirse a medios nuevos antes de convertirse en ilegibles;

f)

deberían almacenarse varias copias de los datos valiosos en un medio independiente para reducir aún más el riesgo del daño o pérdida de los datos coincidentes;

g)

debería considerarse el registro de los medios removibles para limitar la posibilidad de pérdida de datos;

h)

las unidades de medios removibles solo deberían habilitarse si hay una razón comercial para hacerlo;

i)

cuando existe la necesidad de utilizar los medios removibles, la transferencia de información a tales medios debería ser monitoreada.

Deberían documentarse los procedimientos y los niveles ni veles de autorización.

8.3.2

Disposición de medios

Control Se debería poner a disposición los medios de manera segura cuando ya no se requieran, utilizando procedimientos formales. 31



Guía de implementación Deberían establecerse procedimientos formales para la disposición segura de los medios para minimizar el riesgo de fuga de información confidencial a personas no autorizadas. Los procedimientos para la disposición segura de los medios que contienen información confidencial deberían ser proporcionales a la sensibilidad de esa información. Deberían considerarse los siguientes elementos: a)

los medios que contienen información confidencial deberían almacenarse y disponerse de forma segura, por ejemplo, mediante incineración o trituración, o el borrado de datos para su uso por otra aplicación dentro de la organización;

b)

establecer procedimientos para identificar los elementos que puedan requerir la disposición segura;

c)

puede ser más fácil organizar que todos los elementos de los medios sean recopilados y dispuestos de forma segura, en lugar de tratar de separar los elementos sensibles;

d)

muchas organizaciones ofrecen servicios de recopilación y disposición de los medios; se debería tener cuidado en la selección de una parte externa apropiada con los controles y experiencia adecuados;

e)

los elementos sensibles puestos a disposición deberían registrarse a fin de mantener una pista de auditoría.

Cuando se acumulan medios para la disposición, debería tenerse en cuenta el efecto de agregación, que puede causar que una gran cantidad de información no sensible se convierta en sensible. Otra información 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 (ver 11.2.7).

8.3.3

Transferencia de medios físicos

Control Los medios que contienen información deberían ser protegidos contra el acceso no autorizado, el mal uso o la corrupción durante el transporte. Guía de implementación Deberían considerarse las siguientes directrices para proteger a los medios que contienen información que es transportada: 32



a)

deberían utilizarse transporte o servicio de mensajería confiable;

b)

debería acordarse con la gerencia una lista de servicios de mensajería autorizados;

c)

deberían desarrollarse procedimientos para verificar la identificación de los servicios de mensajería;

d)

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

e)

deberían mantenerse registros para identificar el contenido de los medios, la protección aplicada así como el registro de los tiempos de transferencia a los custodios y la recepción en el destino.

Otra información 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 de mensajería. En este control, los medios incluyen los documentos en papel. Cuando la información confidencial en los medios no se encuentra cifrada, debería considerarse la protección física adicional de los medios.

9.

CONTROL DE ACCESO

9.1

Requisitos de la empresa para el control de acceso.

Objetivo: Limitar el acceso a la información y a las instalaciones de procesamiento de la información.

9.1.1

Política de control de acceso

Control Una política de control de acceso debería ser establecida, documentada y revisada basada en requisitos del negocio y de seguridad de la información. Guía de implantación Los propietarios de activos deberían determinar las reglas de control de acceso, los derechos de acceso y restricciones apropiados para los roles específicos de los usuarios con respecto a sus activos, con el nivel de detalle y el rigor de los controles que reflejen los riesgos de seguridad de información asociados. Los controles de acceso son lógicos y físicos (véase la cláusula 11) y estos deberían ser 33



considerados en conjunto. Los usuarios y los proveedores de servicios deberían tener una declaración clara de los requisitos del negocio que deberían cumplir los controles de acceso. La política debería tener en cuenta lo siguiente: a) los requisitos de seguridad de las aplicaciones de negocio; b)

políticas para la difusión y autorización de la información, por ejemplo, la necesidad de conocer los principios y niveles de seguridad de la información y clasificación de la información (véase 8.2);

c)

la consistencia entre los derechos de acceso y políticas de clasificación de la información de los sistemas y redes;

d)

la legislación relevante y cualquier obligación contractual respecto a la limitación de acceso a datos o servicios (véase 18.1);

e)

la gestión de los derechos de acceso en un ambiente distribuido y en red que reconoce todos los tipos de conexiones disponibles;

f)

la segregación de roles de control de acceso, por ejemplo petición de acceso, la autorización de acceso, administración de acceso;

g)

los requisitos para la autorización formal de las solicitudes de acceso (véase 9.2.1 y 9.2.2);

h)

los requisitos para la revisión periódica de los derechos de acceso (ver 9.2.5);

i)

la eliminación de los derechos de acceso (véase 9.2.6);

j)

el archivo de los expedientes de todos los eventos importantes concernientes al uso y la gestión de identidades de los usuarios y la información de autenticación secreta;

k)

los roles con acceso privilegiado (ver 9.2.3).

Otra información Se debería tener cuidado cuando se especifica las reglas de control de acceso a considerar: a)

el establecimiento de reglas basadas en la premisa "Todo está generalmente prohibido a menos que sea expresamente permitido" y no la regla más débil "Todo está generalmente permitido a menos que sea expresamente prohibido";

b)

cambios en las etiquetas de información (véase 8.2.2) que son iniciadas automáticamente por las instalaciones de procesamiento de la información y aquellas iniciadas a discreción de un usuario; 34



c)

los cambios en los permisos del usuario que son iniciados automáticamente por el sistema de información y aquellos iniciados por un administrador;

d)

las reglas que requieren la aprobación específica antes de la promulgación y las que no lo requieren.

Reglas de control de acceso deberían ser soportadas por procedimientos formales (ver 9.2, 9.3, 9.4) y definir responsabilidades (ver 6.1.1, 9.3). Control de acceso basado en roles es un enfoque utilizado con éxito por muchas organizaciones para vincular los derechos de acceso con los roles en el negocio. Dos de los principios frecuentes que dirigen la política de control de acceso son: a)

Necesidad de conocer: sólo se le concede acceso a la información que necesita para llevar a cabo sus tareas (diferentes tareas / roles significan diferente necesidad de conocimiento y por lo tanto diferente perfil de acceso);

b)

Necesidad de usar: sólo se le concede acceso a las instalaciones de procesamiento de información (equipos informáticos, aplicaciones, procedimientos, ambientes) que necesita para llevar a cabo su tarea / trabajo / rol.

9.1.2

Acceso a redes y servicios de red.

Control Los usuarios deberían tener acceso solamente a la red y a servicios de red que hayan sido específicamente autorizados a usar. 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;

b)

los procedimientos de autorización para determinar quién está permitido a acceder a que redes y a que servicios en red;

c)

los controles de gestión y procedimientos para proteger el acceso a las conexiones de red y servicios de red;

d)

los medios utilizados para acceder a las redes y servicios de red (por ejemplo, uso de VPN o red inalámbrica);

e)

requisitos de autenticación del usuario para acceder a varios servicios de 35



red; f)

el monitoreo del uso de los servicios de red.

La política sobre el uso de los servicios de red debería ser consistente con la política de control de acceso de la organización (ver 9.1.1). Otra información Conexiones no autorizadas e inseguras a servicios de red pueden afectar a toda la organización. Este control es particularmente importante para las conexiones de red a las aplicaciones de negocio sensibles o críticos, o para los usuarios en lugares de alto riesgo, por ejemplo, zonas públicas o externas que están fuera del control y gestión de seguridad de la información de la organización.

9.2.

Gestión de acceso de usuario

Objetivo: Asegurar el acceso de usuarios autorizados y prevenir el acceso no autorizado a los sistemas y servicios.

9.2.1

Registro y baja de usuarios

Control Un proceso formal de registro y baja de usuarios debería ser implementado para permitir la asignación de derechos de acceso. Guía de implementación El proceso de gestión de los ID de los usuarios debería incluir: a) utilizar la identificación única de usuario (ID) para que los usuarios puedan estar vinculados y sean responsables de sus acciones; el uso de los ID compartidos debería sólo ser permitido cuando sean necesarios por razones de negocios o de funcionamiento y deberían ser aprobados y documentados; b)

deshabilitar o remover inmediatamente los ID de los usuarios que han dejado la organización (véase 9.2.6);

c)

periódicamente identificar y eliminar o desactivar los ID redundantes;

d)

asegurarse de que los ID redundantes no se otorguen a otros usuarios.

Otra información Proporcionar o revocar el acceso a la información o a las instalaciones de procesamiento de información, usualmente es un procedimiento de dos pasos: a) asignación y habilitación, o revocación, de un ID de usuario; b)

proporcionar, o revocar derechos de acceso a dicho ID de usuario (véase 36



9.2.2).

9.2.2

Aprovisionamiento de acceso a usuario

Control Un proceso formal de aprovisionamiento de acceso a usuarios debería ser implementado para asignar o revocar los derechos de acceso para todos los tipos de usuarios a todos los sistemas y servicios. Guía de implementación El proceso de aprovisionamiento para asignar o revocar los derechos de accesos concedidos a un ID de usuario debería incluir: a) la obtención de la autorización del propietario del sistema o servicio de información para su uso (véase el control 8.1.2); la aprobación por separado de los derechos de acceso para la administración también puede ser apropiada; b)

la verificación de que el nivel de acceso concedido es apropiado a las políticas de acceso (véase 9.1) y es consistente con otros requisitos, tales como la segregación de funciones (véase 6.1.2);

c)

el aseguramiento de que los derechos de acceso no estén activados (por ejemplo, por los proveedores de servicios) antes de que se completen los procedimientos de autorización;

d)

el mantenimiento de un registro central de los derechos de acceso concedidos a un ID de usuario para acceder a los sistemas y servicios de información;

e)

la adaptación de los derechos de acceso de los usuarios que han cambiado roles o trabajo y la inmediata remoción o bloqueo de los derechos de acceso de los usuarios que dejaron la organización;

f)

la revisión periódica de los derechos de acceso con los propietarios de los sistemas o servicios de información (véase 9.2.5).

Otra información Se debería considerar la posibilidad de establecer los roles de acceso de usuario basado en los requerimientos del negocio que resumen un número de derechos de acceso en perfiles típicos de acceso de usuario. Las solicitudes de acceso y las revisiones (véase 9.2.4) son más fácil de gestionar a nivel de esos roles que a nivel de los derechos particulares. Se debería considerar la posibilidad de incluir cláusulas en los contratos de personal y contratos de servicio que especifiquen sanciones, si se intenta el acceso no autorizado por personal o contratistas (ver 7.1.2, 7.2.3, 13.2.4, 15.1.2). 37


9.2.3


Gestión de derechos de acceso privilegiados

Control La asignación y uso de derechos de acceso privilegiado debería ser restringida y controlada. Guía de implementación La asignación de derechos de acceso privilegiado debería ser controlada a través de un proceso formal de autorización, de acuerdo con la política de control de acceso correspondiente (véase el control 9.1.1). Los siguientes pasos deberían ser considerados: a)

los derechos de acceso privilegiados asociados con cada sistema o proceso; por ejemplo, sistema operativo, sistema de gestión de base de datos y cada aplicación; y los usuarios a los que necesitan ser asignados deberían ser identificados;

b)

los derechos de acceso privilegiados deberían ser asignados a los usuarios en base a la necesidad de uso y sobre una base de caso por caso en línea con la política de control de acceso (ver 9.1.1), es decir, basado en el requisito mínimo para sus roles funcionales;

c)

un proceso y registro de autorización de todos los privilegios asignados debería ser mantenido. Los derechos de acceso privilegiados no deberían concederse hasta que el proceso de autorización se ha completado;

d)

los requisitos para expiración de los derechos de acceso privilegiados deberían ser definidos;

e)

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

f)

las competencias de los usuarios con derechos de acceso privilegiados deberían ser revisadas periódicamente a fin de verificar si están alineadas con sus funciones;

g)

los procedimientos específicos deberían establecerse y mantenerse para evitar el uso no autorizado de ID de usuario de administración genéricos, de acuerdo a las capacidades de configuración de los sistemas;

h)

para los ID de usuario de administración genéricos, la confidencialidad de la información de autenticación secreta debería mantenerse cuando se comparte (por ejemplo, cambiar las contraseñas con frecuencia y tan pronto como sea posible cuando un usuario privilegiado deja o cambia de trabajo, comunicando entre ellos a los usuarios privilegiados con mecanismos adecuados).

38



Otra información El uso inadecuado de los privilegios de administración del sistema (cualquier característica o instalación de un sistema de información que habilite al usuario anular sistemas o controles de aplicaciones) es un importante factor de contribución a las fallas o infracciones a los sistemas.

9.2.4

Gestión de información de autentificación secreta de usuarios

Control La asignación de información de autentificación secreta debería ser controlada a través de un proceso de gestión formal. Guía de implementación El proceso debería incluir los siguientes requisitos: a) a los usuarios se les debería requerir firmar una declaración personal para mantener confidencial la información de autenticación secreta y para mantener la información del grupo (es decir, compartida) únicamente con los miembros del grupo; esta declaración firmada se puede incluir en los términos y condiciones de empleo (véase 7.1.2); b)

cuando los usuarios están requeridos a mantener su propia información de autenticación secreta se les debería proporcionar inicialmente la información de autenticación secreta temporal, que se ven obligados a cambiar en el primer uso;

c)

se debería establecer procedimientos para verificar la identidad de un usuario antes de proporcionar información de autenticación secreta nueva, reemplazo o temporal;

d)

la información de autenticación secreta temporal se debería dar a los usuarios de manera segura; el uso de terceros o mensajes de correo electrónico sin protección (texto claro) debería evitarse;

e)

la información de autenticación secreta temporal debería ser única para un individuo y no debería ser adivinable;

f)

los usuarios deberían reconocer la recepción de la información de autenticación secreta;

g)

la información de autenticación secreta por defecto del proveedor debería ser modificada después de la instalación de los sistemas o aplicaciones.

Otra información Las contraseñas son un tipo de información de autenticación secreta comúnmente utilizadas y son un medio común para verificar la identidad de un usuario. Otros tipos de información de autenticación secreta son claves criptográficas y otros datos almacenados 39



en dispositivos tokens (por ejemplo, tarjetas inteligentes) que producen códigos de autenticación.

9.2.5

Revisión de derechos de acceso de usuarios

Control Los propietarios de los activos deberían revisar los derechos de acceso de usuario a intervalos regulares. Guía de implementación La revisión de los derechos de acceso debería considerar lo siguiente: a) los derechos de acceso de los usuarios deberían ser revisados en intervalos regulares y después de cualquier cambio, tal como el ascenso, el descenso o la terminación del empleo (véase la cláusula 7); b)

los derechos de acceso de usuario deberían ser revisados y reasignados al pasar de un rol a otro dentro de la misma organización;

c)

las autorizaciones de los derechos de acceso privilegiados deberían revisarse a intervalos más frecuentes;

d)

las asignaciones de privilegios deberían ser chequeados en intervalos regulares para garantizar que no se han obtenido privilegios no autorizados;

e)

cambios en las cuentas privilegiadas deberían ser registrados para su revisión periódica.

Otra información Este control compensa las posibles debilidades en la ejecución de los controles 9.2.1, 9.2.2 y 9.2.6.

9.2.6

Remoción o ajuste de derechos de acceso

Control Los derechos de acceso a información e instalaciones de procesamientos de información de todos los empleados y de los usuarios de partes externas deberían removerse al término de su empleo, contrato o acuerdo, o ajustarse según el cambio. Guía de implementación Tras la desvinculación, los derechos de acceso de un individuo a la información y los activos asociados a las instalaciones y servicios de procesamiento de información deberían ser removidos o suspendidos. Esto determinará si es necesario eliminar los derechos de acceso. Los cambios de empleo deberían reflejarse en la remoción de todos los derechos de acceso que no fueron aprobados para el nuevo empleo. Los derechos de acceso que deberían ser removidos o ajustados incluyen los de acceso físico y lógico. La 40



remoción o el ajuste se pueden hacer mediante la remoción, la revocación o reemplazo de las claves, tarjetas de identificación, instalaciones de procesamiento de información o suscripciones. Cualquier documentación que identifique los derechos de acceso de los empleados y contratistas debería reflejar la remoción y el ajuste de los derechos de acceso. Si un empleado o usuario externo que se marcha conoce contraseñas para ID de usuario que permanecen activas, éstas se deberían cambiar a la terminación o cambio de empleo, contrato o acuerdo. Los derechos de acceso para la información y los activos asociados a las instalaciones de procesamiento de información deberían ser reducidos o removidos antes del cambio o término del empleo, dependiendo de la evaluación de factores de riesgo tales como: a)

si la desvinculación o el cambio se inicia por el empleado, el usuario externo o la administración, y la razón de la terminación;

b)

las responsabilidades actuales del empleado, usuario externo o cualquier otro usuario;

c)

el valor de los activos actualmente accesibles.

Otra información 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 externo 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 debería hacer una recomendación a todos los demás empleados y usuarios externos involucrados a no compartir esta información con la persona que sale. En los casos de terminación de la gestión iniciada, empleados descontentos o usuarios externos 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 recopilar información para su uso futuro.

9.3.

Responsabilidades de los usuarios

Objetivo: Hacer que los usuarios respondan por la salvaguarda de su información de autentificación.

9.3.1

Uso de información de autentificación secreta

Control Los usuarios deberían ser exigidos a que sigan las prácticas de la organización en el uso de información de autentificación secreta. Guía de implementación Todos los usuarios deberían ser advertidos de: 41



a)

mantener la confidencialidad de la información secreta de autenticación, asegurando que no sea divulgada a otras partes, incluidas las autoridades;

b)

evitar se mantenga registros (por ejemplo, en papel, archivo digital o dispositivo móvil) de información de autenticación secreta, a menos que pueda ser almacenada de forma segura y el método de almacenamiento haya sido aprobado (por ejemplo repositorio de contraseñas);

c)

cambiar la información de autenticación secreta siempre que exista cualquier indicio de su posible compromiso;

d)

cuando las contraseñas son usadas como información de autenticación secreta, seleccione contraseñas de calidad con longitud mínima suficiente que sean: 1)

fácil de recordar;

2)

no basado en cualquier cosa que alguien más podría adivinar fácilmente u obtener utilizando información personal relacionada, por ejemplo, nombres, números de teléfono y fecha de nacimiento, etc.

3)

no vulnerable a ataques de diccionario (es decir, no consistan en palabras incluidas en los diccionarios);

4)

libre de caracteres idénticos consecutivos, totalmente numérica o totalmente alfabética;

5)

si es temporal, cambiado en el primer inicio de sesión;

e)

no compartir información de autenticación secreta de usuario individual;

f)

garantizar una apropiada protección de las contraseñas cuando las contraseñas se utilizan como información de autenticación secreta en procedimientos de inicio de sesión automatizado y son almacenados;

g)

No utilizar la misma información secreta de autenticación para propósitos comerciales y no comerciales.

Otra información La disposición de la “Autenticación única” (Single Sign On (SSO)) u otras herramientas de gestión de información de autenticación secretos, reduce la cantidad de información de autenticación secreta que los usuarios están requeridos a proteger y por lo tanto puede aumentar la eficacia de este control. Sin embargo, estas herramientas también pueden aumentar el impacto de la divulgación de información de autenticación secreta.

9.4.

Responsabilidades de los usuarios

Objetivo: Prevenir el acceso no autorizado a los sistemas y aplicaciones.

9.4.1

Restricción de acceso a la información 42



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 Las restricciones de acceso deberían basarse en los requisitos individuales de aplicaciones de negocio y de acuerdo con la política de control de acceso definida. Debería considerarse lo siguiente para dar soporte a los requisitos de restricción de acceso: a) proporcionar menús para controlar el acceso a las funciones del sistema de aplicación;

9.4.2

b)

controlar los datos que pueden ser accedidos por un usuario en particular;

c)

controlar los derechos de acceso de los usuarios, por ejemplo, leer, escribir, borrar y ejecutar;

d)

controlar los derechos de acceso de otras aplicaciones;

e)

limitar la información contenida en las salidas;

f)

proporcionar controles de acceso físicos o lógicos para el aislamiento de aplicaciones sensibles, datos de aplicación, o sistemas.

Procedimientos de ingreso seguro

Control Donde la política de control de acceso lo requiera, el acceso a los sistemas y a las aplicaciones debería ser controlado por un procedimiento de ingreso seguro. Guía de implementación Una técnica de autenticación adecuada debería ser elegida para justificar la identidad reclamada de un usuario. Cuando se requiere una fuerte autenticación y verificación de identidad, deberían utilizar métodos de autenticación alternativa a las contraseñas, tales como medios de cifrado, tarjetas inteligentes, tokens o medios biométricos. El procedimiento para iniciar 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 el proporcionar un usuario no autorizado con cualquier asistencia innecesaria. Un buen procedimiento de ingreso debería: a) no mostrar identificadores de sistemas o aplicaciones hasta que el proceso de entrada ha sido completado exitosamente; 43



b)

mostrar un aviso general de advertencia de que el computador debería ser accedido sólo por usuarios autorizados;

c)

no proveer mensajes de ayuda durante el procedimiento de ingreso que facilite el acceso a un usuario no autorizado;

d)

validar la información de inicio de sesión sólo al completar todos los datos de entrada. Si surge una condición de error, el sistema no debería indicar que parte de los datos son correctos o incorrectos;

e)

proteger contra intentos de ingreso por fuerza bruta;

f)

registrar los intentos fallidos y exitosos;

g)

plantear un evento de seguridad si un intento potencial o infracción exitosa de ingreso es detectado por los controles;

h)

muestra la siguiente información sobre al completar un ingreso con éxito: 1)

Fecha y hora del anterior ingreso con éxito;

2)

detalles de cualquier intento de ingreso sin éxito desde el último ingreso con éxito;

i)

no mostrar una contraseña siendo introducida;

j)

no transmitir las contraseñas en texto claro (sin cifrar) a través de una red;

k)

terminar sesiones inactivas después de un período definido de inactividad, especialmente ubicaciones de alto riesgo, tales como áreas públicas o externas fuera de la gestión de seguridad de la organización o en los dispositivos móviles;

l)

restringir los tiempos de conexión para proveer seguridad adicional para aplicaciones de alto riesgo y reducir la ventana de oportunidad para accesos no autorizados.

Otra información Las contraseñas son una forma común de proveer identificación y autenticació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 autenticación. La fortaleza de la autenticación de usuario debería ser apropiada para la clasificación de la información a ser accedida. Si las contraseñas son transmitidas en texto claro durante el inicio de sesión a través de una red, pueden ser capturadas por un programa de red "sniffer".

9.4.3

Sistema de gestión de contraseñas

Control 44



Los sistemas de gestión de contraseñas deberían ser interactivos y deberían asegurar contraseñas de calidad. Guía de implementación Un sistema de gestión de contraseñas debería: a) imponer el uso de ID de usuario y contraseñas individuales para mantener la responsabilidad; b)

permitir a los usuarios seleccionar y cambiar sus propias contraseñas e incluir un procedimiento de confirmación para permitir errores de entrada;

c)

imponer la elección de contraseñas de calidad;

d)

Forzar a los usuarios a cambiar sus contraseñas en el primer inicio de sesión;

e)

imponer los cambios regulares de contraseña y, según sea necesario;

f)

mantener un registro de las contraseñas utilizadas anteriormente y evitar su reutilización;

g)

No mostrar las contraseñas en la pantalla cuando son ingresadas;

h)

almacenar archivos de contraseñas separadamente de los datos del sistema de aplicación;

i)

almacenar y transmitir las contraseñas en forma protegida.

Otra información 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 anterior no se aplican. En la mayoría de los casos las contraseñas son seleccionadas y mantenidas por los usuarios.

9.4.4

Uso de programas utilitarios Privilegiados

Control El uso de programas utilitarios que podrían ser capaces de pasar por alto los controles del sistema y de las aplicaciones debería ser 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 deberían considerarse: a) el uso de identificación, procedimientos de autenticación y autorización de los programas utilitarios; 45



b)

segregación de los programas utilitarios de los de aplicaciones;

c)

Limitación del uso de programas utilitarios a un número mínimo práctico de confianza y de usuarios autorizados (véase 9.2.3);

d)

autorización para el uso ad hoc de los programas utilitarios;

e)

limitación de la disponibilidad de programas utilitarios, por ejemplo, para la duración de un cambio autorizado;

f)

registro de todo el uso de los programas utilitarios;

g)

definición y documentación de los niveles de autorización para los programas utilitarios;

h)

remoción o desactivación de todos los programas utilitarios innecesarios;

i)

no habilitar programas utilitarios para usuarios que tienen acceso a aplicaciones en sistemas donde se requiere la separación de funciones.

Otra información La mayoría de instaladores de software tienen uno o más programas utilitarios que podrían ser capaces de anular controles de sistemas y aplicaciones.

9.4.5

Control de acceso al código fuente de los programas

Control El acceso al código fuente de los programas debería ser restringido. Guía de implementación El acceso al código fuente de programas y elementos asociados (tales como diseños, especificaciones, planes de verificación y de validación) deberían ser 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 valiosa. Para el código fuente de programas, esto se puede lograr por el almacenamiento centralizado y controlado de dicho código, preferiblemente en las bibliotecas fuentes de programas. Las siguientes guías deberán tomarse en consideración para controlar el acceso a este tipo de bibliotecas fuentes de programas con el fin de reducir las posibilidades de corrupción de los programas del computador: a)

donde sea posible, las bibliotecas fuentes de programas no deberían ser mantenidos en sistemas en producción;

b)

el código y las bibliotecas fuentes de programas 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 fuentes de programas; 46



d)

la actualización de las bibliotecas fuentes de programas y elementos asociados y la entrega de programas fuentes a los programadores sólo debería realizarse después de haberse recibido la autorización apropiada;

e)

las listas de programas deberían mantenerse en un entorno seguro;

f)

un registro de auditoría debería mantenerse para todos los accesos a las bibliotecas fuente de programas;

g)

el mantenimiento y la copia de las bibliotecas fuentes de programas deberían estar sujetos en estricto a procedimientos de control de cambios (véase 14.2.2). Si el código fuente del programa está destinado a ser publicado, debería considerarse controles adicionales 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.

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 debería ser considerado lo siguiente: 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 negocio 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 fuerza y la calidad del algoritmo de encriptación requerido;

c)

el uso de encriptación para proteger la información transportada por los dispositivos 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 pérdida, compromiso o daño de las claves;

e)

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



1)

la implementación de la política;

2)

la gestión de claves, incluyendo su generación (ver 10.1.2);

f)

los estándares a ser adoptados para la implementación efectiva en toda la organización (que solución es utilizada para cada proceso 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 malware).

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 (ver 18.1.5). 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 autenticació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)

Autenticación: uso de técnicas criptográficas para autenticar usuarios y otras entidades del sistema que soliciten acceso o que realicen transacciones con los usuarios, entidades y recursos del sistema.

Otra información 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 puede ser utilizada 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 negocio. Una política sobre el uso de controles criptográficos es necesaria para maximizar los beneficios y minimizar los riesgos de usar técnicas criptográficas y para evitar el uso inadecuado o incorrecto. El asesoramiento especializado se debería buscar en la selección de controles criptográficos apropiados para cumplir los objetivos de la política de seguridad de la información.

10.1.2

Gestión de claves

Control 48



Una política sobre el uso, protección y tiempo de vida de las claves criptográficas deberían 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. Los algoritmos criptográficos, longitudes de clave y prácticas de uso deberían ser seleccionados de acuerdo a las mejores prácticas. La gestión de claves apropiada requiere de procesos seguros para generar, almacenar, archivar, recuperar, distribuir, retirar y destruir claves criptográficas. Todas las claves criptográficas deberían ser 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 ser protegido físicamente. Un sistema de gestión de claves debería basarse en un conjunto establecido de estándares, procedimientos y métodos seguros para: a) generación de claves para los diferentes sistemas criptográficos y diferentes aplicaciones; b)

emisión y obtención de certificados de clave pública;

c)

distribución de claves para entidades destinadas, incluyendo cómo deberían activarse las claves cuando se reciben;

d)

almacenamiento de claves, incluyendo cómo los usuarios autorizados obtienen acceso a las claves;

e)

cambiar o actualizar las claves incluyendo reglas sobre cuando 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 las claves, por ejemplo, cuando las claves han sido comprometidas o cuando un usuario sale de una organización (en qué caso las claves deberían también archivarse);

h)

recuperación de claves perdidas o corruptas;

i)

copia de seguridad o archivamiento de claves;

j)

destrucción de claves;

k) registro y auditoría de las actividades relacionadas a la gestión de claves. Con el fin de reducir la probabilidad de un uso inadecuado, fechas de activación y 49



desactivación de claves deberían ser 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 autenticació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 controles y procedimientos adecuados para proporcionar el grado necesario de confianza en el lugar. 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 y tiempos de respuesta para la prestación de los servicios (véase 15.2). Otra información La gestión de claves criptográficas es esencial para el uso eficaz de técnicas criptográficas. ISO/IEC 11770 [2] [3] [4] proporciona información adicional 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 AMBIENTAL

11.1

Áreas seguras

Objetivo: Impedir el acceso físico no autorizado, daño e interferencia a 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 ser 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 Las siguientes guías deberían ser consideradas e implementadas según corresponda para los perímetros de seguridad física: a)

los perímetros de seguridad deberían definirse, y la ubicación y resistencia de cada uno de los perímetros deberían depender de los requisitos de seguridad de los activos dentro del perímetro y de los resultados de una evaluación de riesgos; 50



b)

los perímetros de un edificio o lugar que contenga instalaciones de procesamiento de información deberían tener solidez física (por ejemplo no tendrá zonas que puedan vulnerarse 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 barras, alarmas, cerraduras); puertas y ventanas deberían bloquearse cuando se encuentren sin vigilancia 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, ser supervisadas y probadas conjuntamente con las paredes para establecer el nivel requerido de resistencia de acuerdo a los estándares regionales, nacionales, e internacionales apropiados; 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 los estándares nacional, regional o internacional y probarlos regularmente para cubrir todas las puertas externas y ventanas accesibles; las áreas no ocupadas deberían alarmar 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 terceros.

Otra información La protección física puede ser alcanzada creando una o más barreras físicas alrededor del local y de las instalaciones de procesamiento de información de la organizació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 ambientes 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 darse especial atención a la seguridad de acceso físico en los edificios donde funcionan múlt iples organizaciones. La aplicación de los controles físicos, especialmente para las áreas seguras, debería adaptarse a las circunstancias técnicas y económicas de la organización, según se establece en la evaluación de riesgos. 51


11.1.2


Controles de ingreso físico

Control Las áreas seguras deberían ser 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 Deberían considerarse las siguientes recomendaciones:

11.1.3

a)

la fecha y hora de entrada y salida de visitantes debería 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 ser restringido sólo a las personas autorizadas mediante la implementación de controles de acceso, por ejemplo, mediante la implementación de un mecanismo de autenticación de dos factores, tales 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 externos 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 externo a las áreas seguras o a las instalaciones de procesamiento de la información sensible sólo cuando sea requerido; este acceso debería ser autorizado y monitoreado;

f)

los derechos de acceso a las áreas seguras deberían ser regularmente revisados y actualizados, y revocados cuando sea necesario (ver 9.2.5 y 9.2.6).

Asegurar oficinas, áreas e instalaciones

Control Seguridad física para oficinas, áreas e instalaciones debería ser diseñada e implementada. 52



Guía de implementación Deberían considerarse las siguientes recomendaciones para asegurar oficinas, áreas, e instalaciones: a)

las instalaciones clave deberían situarse de manera de evitar 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;

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 sea apropiado, debería considerarse el blindaje electromagnético como adecuado;

d)

los directorios y libros de teléfonos internos que identifican ubicaciones de instalaciones de procesamiento de la información confidencial no deberían ser fácilmente accesibles por el público.

11.1.4

Protección contra amenazas externas y ambientales

Control Protección física contra desastres naturales, ataque malicioso o accidentes debería ser diseñada y aplicada. Guía de implementación Debería obtenerse asesoramiento especializado sobre cómo evitar los daños causados por fuego, inundaciones, terremotos, explosiones, disturbios civiles y otras formas de desastres naturales o artificiales.

11.1.5

Trabajo en áreas seguras

Control Procedimientos para el trabajo en áreas seguras deberían ser diseñados y aplicados. Guía de implementación Deberían considerarse las siguientes recomendaciones: a)

el personal sólo debería conocer la existencia de un área segura, o de sus actividades, si lo necesitara para su trabajo.

b)

debería evitarse el trabajo no supervisado en áreas seguras tanto por motivos de seguridad como para evitar oportunidades de actividades 53



maliciosas; c)

las áreas seguras periódicamente;

desocupadas

deberían

cerrarse

y

revisarse

d)

no debería permitirse la presencia de equipos de fotografía, video, audio u otras formas de registro, como cámaras en dispositivos móviles, sin autorización.

Los acuerdos para trabajar en áreas seguras incluyen controles para los empleados y los usuarios de partes externas que trabajan en el área segura, así como otras actividades 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 ser 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 Deberían considerarse las siguientes recomendaciones: a)

debería restringirse el acceso al área de entrega y carga desde el exterior del edificio únicamente al personal identificado y autorizado;

b)

el área de entrega y carga debería diseñarse para que los suministros puedan cargarse y descargarse sin que el personal de entrega 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;

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 (ver 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 en el trayecto. Si se descubre tal manipulación, el personal de seguridad debería ser inmediatamente notificado. 54


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

Emplazamiento y protección de los equipos

Control Los equipos deberían ser 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 de minimizar el acceso innecesario a las áreas de trabajo;

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 resguardarse 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 y ambientales potenciales, por ejemplo: 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 confidencial 55



para reducir al mínimo el riesgo de fuga de información debido a la emanación electromagnética.

11.2.2

Servicios de suministro

Control Los equipos deberían ser protegidos contra fallas de electricidad y otras alteraciones causadas por fallas en los servicios de suministro. Guía de implementación Los servicios de suministro (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 servicios de suministro;

c)

ser inspeccionados y probados regularmente para garantizar su buen funcionamiento;

d)

si es necesario, ser alarmados para detectar fallos de funcionamiento;

e)

si es necesario, tener múltiples canales con diversos enrutamientos físicos.

Debería proporcionarse alumbrado y comunicaciones de emergencia. Los interruptores y las válvulas de emergencia para cortar el suministro de energía, agua, gas u otros servicios deberían ubicarse cerca de las salidas de emergencia o de las salas de máquinas. Otra información Se puede obtener redundancia adicional para la conectividad de redes mediante múlti ples rutas de más de un proveedor de servicios.

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. Guía de implementación Deberían considerarse las siguientes recomendaciones para la seguridad en el cableado: 56



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:

11.2.4

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 cableado.

Mantenimiento de equipos

Control Los equipos deberían mantenerse de manera correcta para asegurar su continua disponibilidad e integridad. Guía de implementación Deberían considerarse las siguientes recomendaciones para el mantenimiento del equipamiento: a)

el equipamiento debería mantenerse de acuerdo a las recomendaciones de intervalos de servicio y especificaciones del proveedor;

b)

sólo el personal de mantenimiento debidamente autorizado debería realizar reparaciones y realizar el mantenimiento a los equipos;

c)

deberían mantenerse registros de todos los fallos, reales o sospechados, así como de todo el mantenimiento preventivo y correctivo;

d)

deberían implantarse controles apropiados cuando el equipamiento sea calendarizado 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)

debería cumplirse con todos los requisitos de mantenimiento impuestos por pólizas de seguros; 57


f)

11.2.5


antes de poner el equipamiento nuevamente en operación después de su mantenimiento, debería ser inspeccionado para garantizar que el equipamiento no ha sido alterado y no tiene un mal funcionamiento.

Remoción de activos

Control Los equipos, la información o el software no deberían ser retirados de su lugar sin autorización previa. Guía de implementación Deberían considerarse las siguientes recomendaciones: a)

deberían identificarse aquellos empleados y usuarios de partes externas que tengan autoridad para permitir el retiro de activos fuera de los locales de la organización;

b)

debería fijarse los límites de tiempo para el equipamiento retirado y verificar el cumplimiento del retorno;

c)

donde sea necesario y procedente, debería registrarse tanto la salida del equipamiento del local, como el retorno del mismo;

d)

debería documentarse la identidad, el rol y la afiliación de cualquier persona que gestiona o utiliza activos y esta documentación debería devolverse junto con el equipamiento, la información o el software.

Otra información Las instancias de inspección, emprendidas para detectar el retiro de activos no autorizados, se pueden también realizar para detectar y prevenir el ingreso y la salida no autorizada a las instalaciones, de dispositivos de grabación, armas, etc. 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 regulatorios.

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. Guía de implementación El uso de cualquier equipamiento que almacene o procese información fuera de las 58



instalaciones de la organización, debería ser autorizado por la gerencia. Esto se aplica a los equipamientos de la organización y al equipamiento de propiedad privada utilizado en nombre de la organización. Deberían considerarse las siguientes recomendaciones para la protección del equipamiento fuera de los locales de la organización: a)

los equipos y medios que contengan datos con información y sean sacados de su entorno habitual no deberían dejarse desatendidos en lugares públicos;

b)

debería observarse 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 (ver la Norma ISO/IEC 27033 Network Security [15][16][17][18][19]);

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, los daños, hurto o espionaje, pueden variar considerablemente entre las locaciones y deberían tenerse en cuenta para determinar los controles más adecuados. Otra información El equipamiento de almacenamiento y procesamiento de la información comprende todo tipo de computadoras personales, organizadores, teléfonos móviles, tarjetas inteligentes, papeles u otras formas, 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. 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 59



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 ser verificados para asegurar si contienen o no medios de almacenamiento antes de su eliminación o reutilización. Los dispositivos de almacenamiento que contienen información confidencial 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. Otra información El equipamiento dañado que contenga medios de almacenamiento pueden requerir una evaluación de riesgo para determinar si estos deberían destruirse físicamente, en lugar de 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: a)

el proceso de encriptación sea lo suficientemente fuerte y cubra todo el disco (incluyendo el espacio libre, área de intercambio (swap), etc.);

b)

las llaves de encriptación sean suficientemente largas como para resistir los ataques de fuerza bruta;

c)

las llaves de encriptación sean mantenidas confidenciales (por ejemplo, nunca sean almacenadas en el mismo disco).

Para más recomendaciones sobre encriptación, ver 10. Las técnicas de sobre escritura segura para los medios de almacenamiento difieren de acuerdo a la tecnología de los medios de almacenamiento. Las herramientas de sobre escritura 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. Guía de implementación Todos los usuarios deberían ser advertidos de los requisitos y procedimientos de 60



seguridad para proteger equipamiento desatendido, así como de su responsabilidad de implementar tal protección. Debería recomendarse a los usuarios: a)

terminar sesiones activas al finalizar, salvo que se les pueda asegurar por un mecanismo de bloqueo apropiado, por ejemplo un protector de pantalla protegido con contraseña;

b)

cerrar aplicaciones o servicios de red cuando ya no sean necesarios;

c)

asegurar a las computadoras o dispositivos móviles contra 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. Guía de implementación Una política de escritorio limpio y pantalla limpia debería tener en cuenta la clasificación de la información (ver 8.2), requisitos legales y contractuales (ver 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, una señal (token), o mecanismo de autenticació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 escáner, cámaras digitales);

d)

medios conteniendo información clasificada o sensible debería retirarse de las impresoras inmediatamente.

Otra información Una política de escritorio y pantalla limpios, reduce los riesgos de acceso no autorizado, 61



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 ser documentados y puestos a disposición de todos los usuarios que los necesitan. Guía de implementación 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, manejo de medios, gestión y seguridad de la sala de cómputo y el manejo del correo. Los procedimientos operacionales funcionamiento, incluyendo:

deberían

especificar

las

instrucciones

de

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 (ver 12.3);

d)

programación de requerimientos, incluyendo interdependencias con otros sistemas, tareas con tiempos de inicio temprano y finalización tardía;

e)

instrucciones para el manejo de errores u otras condiciones excepcionales, que pudieran presentarse durante la ejecución de tareas, incluyendo restricciones en el uso de las utilidades del sistema (ver 9.4.4);

f)

contactos de soporte y escalamiento incluyendo soporte externo en caso de dificultades operacionales o técnicas inesperadas; 62



g)

instrucciones especiales para salida 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 (ver 8.3 y 11.2.7);

h)

procedimientos de reinicio y recuperación para usar en caso de un evento o fallo del sistema;

i)

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

j)

procedimientos de monitoreo.

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

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. Guía de implementación 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 retorno (fall-back), 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 63



(ver 16.1). Deberían establecerse las responsabilidades y los procedimientos formales de gestión para garantizar el control satisfactorio de todos los cambios. Cuando se realizan los cambios, debería conservarse un registro de auditoría conteniendo toda la información relevante. Otra información 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 al ambiente operacional, especialmente cuando se transfiere un sistema en desarrollo a producción, pueden impactar la confiabilidad de las aplicaciones (ver 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. Guía de implementación 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 de detección para indicar problemas oportunamente. 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 particular a cualquier recurso cuya adquisición tome mucho tiempo o requiera costos elevados; por lo tanto los gestores deberían monitorear la utilización de los recursos clave del sistema. Ellos deberían identificar l as 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 gestores 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. Proporcionar capacidad suficiente se puede lograr mediante el aumento de la capacidad o mediante la reducción de la demanda. Algunos ejemplos de la gestión de la capacidad demandada son: a)

la eliminación de datos obsoletos (espacio en disco);

b)

el retiro de aplicaciones, sistemas, bases de datos o ambientes;

c)

la optimización de procesos por lote y calendarización; 64



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 de alto consumo de recursos, si no son críticos pare 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. Otra información 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 ser separados para reducir los riesgos de acceso no autorizado o cambios al entorno operativo. Guía de implementación 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 operativos. Los siguientes puntos deberían considerarse: a)

las reglas para transferir el software desde el ambiente de desarrollo al de producción deberían estar definidas y documentadas;

b)

el software de desarrollo y el de producción deberían, si es posible, funcionar en diferentes sistemas o equipos de procesamiento, y en dominios o directorios distintos;

c)

los cambios en los sistemas y aplicaciones en producción deberían probarse en un ambiente de pruebas o ensayos, antes de ser aplicados a los sistemas en producción;

d)

salvo en circunstancias excepcionales, las pruebas no deberían hacerse en los sistemas en producción;

e)

los compiladores, editores y otras herramientas de desarrollo o utilidades del sistema no deberían accederse desde los sistemas en producción, cuando no sea requerido;

f)

los usuarios deberían usar perfiles de usuario diferentes para los sistemas en producción y de prueba, y los menús deberían exhibir mensajes de identificación apropiados para reducir el riesgo a error; 65


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 (ver 14.3).

Otra información 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 en pr oducción. Donde el personal de desarrollo y de pruebas tiene acceso al sistema en producción y a su información, puede introducir código no autorizado y no comprobado o alterar datos en producción. 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. El personal de desarrollo y de pruebas puede ser una amenaza a la confidencialidad de la información en producción. 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 producción para reducir el riesgo de cambio accidental o acceso no autorizado al software en producción y a los datos del negocio (ver 14.3 para la protección de los datos de prueba).

12.2

Protección contra códigos maliciosos

Objetivo: Asegurar que la información y las instalaciones de procesamiento de la información estén protegidas contra códigos maliciosos.

12.2.1

Controles contra códigos maliciosos

Control Controles de detección, prevención y recuperación para proteger contra códigos maliciosos deberían ser implementados, en combinación con una concientización apropiada de los usuarios. Guía de implementación 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 concientización de la seguridad de información, y en apropiados controles de acceso al sistema y gestión de cambios. Las siguientes directrices deberían considerarse: a)

establecimiento de una política formal que prohibida el uso de software no autorizado (ver 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); 66



c)

implementación de controles que previenen o detectan el uso de sitios web maliciosos conocidos o sospechosos (por ejemplo, listas negras);

d)

establecimiento de una política formal de protección contra los riesgos asociados a la obtención de archivos y software desde o vía 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 de vulnerabilidades técnicas (ver 12.6);

f)

conducir 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 modificaciones no autorizadas 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 cualquier archivo recibido a través de redes o 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 y cuando ingrese a la red de la organización;

3)

el escaneo de páginas web en busca de software malicioso;

h)

definición de procedimientos y responsabilidades para tratar y proteger contra software malicioso a los sistemas, la capacitación para su uso, 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 necesarios, software de respaldo y las disposiciones para la recuperación (ver 12.3);

j)

implementación de procedimientos para recibir regularmente 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 información relativa a software malicioso y asegurarse que los boletines de alerta son adecuados e informativos; los gestores deberían asegurarse que las fuentes de esta información son de calidad, por ejemplo, revistas de prestigio, sitios de Internet confiables o proveedores de software de protección contra software malicioso; todos los usuarios deberían ser conscientes sobre el problema de 67



los falsos avisos de software malicioso (HOAXES) y qué hacer en caso de recibirlos. l)

aislar entornos en los que se pueden producir impactos catastróficos.

Otra información 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 escapar a los controles normales contra software malicioso. Bajo ciertas condiciones, la protección contra el código malicioso puede causar interferencias en las operaciones. El uso de software de detección y reparación contra software malicioso como único control 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 tomadas y probadas regularmente en concordancia con una política de respaldo acordada. Guía de implementación Debería establecerse una política de respaldo para definir los requisitos de la or ganizació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; 68



b)

la extensión (por ejemplo, respaldo completo o diferencial) y la frecuencia de los respaldos deberían reflejar los requerimientos del negocio, los requisitos de seguridad de la información comprometida, 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 respaldada debería tener un nivel apropiado de protección ambiental y física (ver cláusula 11) consistente con las normas aplicadas en el sitio principal;

e)

los medios 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 verificados contra 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 sobrescribiendo los medios originales en caso de que el respaldo o el proceso de restauración falle y ocasione daños irreparables o pérdida de datos;

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 completitud 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 conservarse 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. 69



Guía de implementación Los registros de eventos deberían incluir, cuando corresponda: 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 acceso al sistema exitosos y rechazados;

f)

registros de intentos de acceso a datos y otros recursos exitosos y rechazados;

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 planteadas 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. Otra información Los registros de eventos pueden contener datos sensibles y datos personales. Deberían tomarse medidas adecuadas de protección de la privacidad (ver 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 (ver 12.4.3).

12.4.2

Protección de información de registros. 70



Control Las instalaciones para registros (logs) y la información de los registros (logs) deberían ser protegidas contra la adulteración y el acceso no autorizado. Guía de implementación 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 de los medios de archivo de registro excedida, resultando en la falla en el registro 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 (ver 16.1.7). Otra información 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. 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 ser 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. 71



Otra información 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 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. Guía de implementación Deberían documentarse los requisitos internos y externos de representación, sincronización y precisión del tiempo. Tales requisitos pueden ser requisitos legales, regulatorios, contractuales, de cumplimiento de las normas o requisitos para el monitoreo interno. Debería definirse un estándar de tiempo para referencia de uso dentro de la organización. El enfoque de la organización para obtener un tiempo para referencia de una fuente externa y la forma de sincronizar los relojes internos de manera fiable, debería estar documentado e implementado. Otra información 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 de 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 Procedimientos deberían ser implementados para controlar la instalación de software en sistemas operacionales. Guía de implementación 72



Deberían considerarse las siguientes directrices, 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 (ver 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, efectos sobre otros sistemas y facilidades de usuario, y deberían realizarse sobre sistemas separados (ver 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 conservarse 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 apoyo mientras los datos son conservados 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. 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 (ver 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 (ver 15.2.1). 73



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. Guía de implementación Un requisito previo para la gestión eficaz de vulnerabilidades técnicas es un inventario actual y completo de activos (ver cláusula 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. 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, ver 8.1.1), estos recursos de información deberían ser 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; 74



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 (ver 12.1.2) o según procedimientos de gestión de incidentes de seguridad de la información (ver 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;

2)

adaptar o agregar controles de acceso, por ejemplo: firewalls, en los perímetros de la red (ver 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 detectivas y correctivas adecuadas.

Otra información 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 (ver 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 75



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 NTP-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. 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. Otra información 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.

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. Guía de implementación Las siguientes recomendaciones deberían tenerse en cuenta: 76



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ían limitarse a accesos de 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 identificarse y acordarse;

f)

las pruebas de auditoria que podrían afectar la disponibilidad del sistema deberían ejecutarse fuera de horario de trabajo;

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

especiales o adicionales deberían

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



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 (ver Cláusulas 10 y 13.2); controles especiales también pueden ser necesarios para mantener la disponibilidad de los servicios de red y computadoras conectadas; 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;

g)

los sistemas en la red deberían ser autenticados;

h)

la conexión de sistemas a la red debería ser restringida.

Otra información 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. 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 ser identificadas. La organización debería asegurarse que los proveedores de los servicios de red implementan estas medidas. Otra información 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. 78



Las características de seguridad de los servicios de red podrían ser:

13.1.3

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.

Segregación en redes

Control Grupos de servicios de información, usuarios y sistemas de información deberían ser segregados en redes. Guía de implementación 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). 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 (ver 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 (ver 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. 79



Otra información 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 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. 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. Guía de implementación Los procedimientos y los controles a ser seguidos cuando utilizamos instalaciones de comunicación para transferencia de información debería 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 (ver 12.2.1);

c)

procedimientos para proteger la información electrónica comunicada que está en la forma de un archivo adjunto;

d)

la política o directrices 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, etc.;

f)

el uso de técnicas criptográficas, por ejemplo para proteger la confidencialidad, integridad y autenticidad de la información (véase la cláusula 10);

g)

los lineamientos de conservación y eliminación para toda la correspondencia

sensible

80



comercial, incluyendo los mensajes, en concordancia con la legislación y regulación nacional y local pertinentes; 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 almacenada de f orma incorrecta como resultado de marcado incorrecto;

k)

asesorar al personal sobre los problemas del uso de máquinas o servicios de fax, a saber: 1. el acceso no autorizado a almacenes de mensajes embebidos para recuperar los mensajes; 2. la programación deliberada o accidental de las máquinas para enviar mensajes a números específicos; 3. el envío de documentos y mensajes a un número equivocado, ya sea por marcar de forma equivocada o usar un número equivocado 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). Otra información La transferencia de información se puede producir mediante el uso de un número de diferentes tipos instalaciones de comunicación, incluyendo el correo electrónico, voz, fax y video. 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 desde los vendedores que venden productos en caja. Las implicaciones de negocio, legales y de seguridad asociados con el intercambio electrónico de datos, 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 81



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 Los acuerdos de transferencia de información debería 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 (ver 8.2);

h)

las normas técnicas para la grabación y lectura de la información y software;

i)

cualquier control especial que se requiera para proteger items sensibles, como la criptografía (ver cláusula 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. Otra información 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 82



La información involucrada en mensajería electrónica debería ser protegida apropiadamente. Guía de implementación Las consideraciones de seguridad de la información para la mensajería electrónica deberían incluir lo siguiente: 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.

Otra información 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 ser identificados, revisados y regularmente y documentados. Guía de implementación 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 identificar los requisitos de los acuerdos de confidencialidad o de no divulgación, los siguientes elementos deberían ser considerados: 83



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 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 sean aplicables (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. Otra información 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 84


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. Guía de implementación 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 de seguridad y controles deberían reflejar el valor para el negocio del activo de información involucrado (ver 8.2) y el potencial impacto negativo para el negocio, que podría ser resultado de una ausencia de seguridad adecuada. Los requisitos de identificación y de la gestión de los requisitos de seguridad de la información y los procesos deberían integrarse 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 85



de datos. Para las aplicaciones que proporcionan servicios sobre redes públicas o que implementan transacciones, deberían considerar controles dedicados 14.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. Otra información Las Normas ISO/IEC 27005 e ISO/IEC 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 ser protegida de actividad fraudulenta, disputa de contratos o divulgación no autorizada y modificación. Guía de implementación 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 otra identidad declarada, por ejemplo, a través de la autenticación;

b)

los procesos de autorización asociados con quién puede aprobar el contenidos 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 86



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.

Muchas de las consideraciones anteriores pueden ser abordadas mediante la aplicación de controles criptográficos (ver clausula 10), teniendo en cuenta el cumplimiento de los requisitos legales (ver clausula 18, especialmente ver 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 (ver 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. Otra información 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 (ver clausula 10) para reducir los riesgos. Además, se puede usar tercerización confiable, donde sea necesario para cada servicio. 87


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 ser 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. Guía de implementación 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 es 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, y 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.

Otra información 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 regulatrios de la jurisdicción en la cual la transacción es generada, procesada, completada, y/o 88



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 ser establecidas y aplicadas a desarrollos dentro de la organización. Guía de implementació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 las directrices 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;

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 pueden 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 89



tercero cumpla con estas reglas de desarrollo seguro (ver 14.2.7). Otra información 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 ser 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 procedimientos formales de control de cambio. La 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 gestión de 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 de aplicación y operacionales deberían integrarse (ver 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; 90



h)

garantizar que al terminar cada cambio la documentación de sistema es actualizada y que la vieja documentación es archivada o eliminada;

i)

el mantenimiento de un control de versiones de todas las actualizaciones de software;

j)

el mantenimiento de una pista de auditoría de todo cambio solicitado;

k)

garantizar que la documentación de operaciones (ver 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.

Otra información 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 (ver 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 operativa

Revisión técnica de aplicaciones después de cambios a la plataforma

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 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 91



apropiadas antes de la implementación; c)

garantizar que los cambios apropiados son hechos en los planes de continuidad de negocio (ver cláusula 17).

Otra información 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. Guía de implementación 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: a)

el riesgo de comprometer los controles embebidos y 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 (ver 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 92



sistemas de información. Guía de implementación Los procedimientos de la ingeniería de sistemas seguros de información 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. 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. Otra información 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. Guía de implementación Un ambiente de desarrollo seguro incluye personas, procesos y tecnología asociados con el desarrollo y la integración de los sistemas. 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 93



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 (ver 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. Guía de implementación 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 tercerizados (ver 18.1.2); b) los requisitos contractuales para el diseño, la codificación y las prácticas de pruebas seguros (ver 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 94



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 provisión de evidencia de se han aplicado 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. Otra información Se puede encontrar más información sobre el 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. 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 cronograma 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 solo como se esperaba (ver 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. 95



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 (ver 14.1.1 y 14.1.2) y la adherencia para asegurar las prácticas de desarrollo del sistema (ver 14.2.1). Las pruebas deberían también ser llevadas a cabo en los componentes recibidos y 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. 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 (ver ISO/IEC 29101). Las directrices siguientes deberían aplicarse para proteger los datos para producción cuando son utilizados para propósitos de pruebas: 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. 96



Otra información 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. Guía de implementación Las organizaciones deberían identificar y ordenar los controles de seguridad de la información para abordar específicamente el acceso del proveedor a la información de la organización en una política. 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 acceso 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 97



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;

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.

Otra informació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 98



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 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: a)

descripción de la información a ser proporcionada o accesada 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 (ver 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 relevantes 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);

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; 99



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.

Otra informació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 sub-proveedores). 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.

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. 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: 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 100



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 proporcionados 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;

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.

Otra información 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. 101



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 de computación en la nube (cloud computing).

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

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; 102



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 (ver cláusula 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 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. Guía de implementación 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; 103


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.

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. Guía de implementació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; 104


b)


4)

procedimientos para el manejo de evidencia forense;

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;

los procedimientos establecidos deberían asegurarse de: 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 asunto ha sido bien abordados y cerrados.

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. Otra información Los incidentes de seguridad de la información pueden superar los límites organizacionales 105



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 NTP-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. Guía de implementación 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; 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 directrices;

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.

Otra información 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 i nformación.

16.1.3

Reporte de debilidades de seguridad de la información

Control 106



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. 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. Otra información 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 r ealiza 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. Guía de implementació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.

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. 107



Guía de implementación 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 (ver 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 (ver 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. Debería realizarse un análisis post-incidente, cuando sea necesario, para identificar el origen del incidente. Otra información 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. 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. 108



Otra información 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 (ver 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 (ver 7.2.2) como ejemplos de lo que podría suceder, como responder a estos incidentes y cómo evitarlos en el futuro.

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. 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. 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. 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 109



requisitos de las distintas jurisdicciones para maximizar las posibilidades de su admisión en todas las jurisdicciones relevantes. Otra información 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 directrices 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 estar embebida en los sistemas de gestión de continuidad del negocio de la organización

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. Guía de implementación 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 una continuidad del negocio formal y planificación 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 110



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. Otra información 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. Puede encontrar más información sobre gestión de la continuidad del negocio en las NTPISO/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. Guía de implementación 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 seguridad de la información;

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 (ver 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; 111



b)

los procesos, procedimientos y cambios en la implementación para mantener los controles de seguridad de la información existentes 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.

Otra información 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ían 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. Guía de implementación 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, 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 seguridad de la información;

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 112



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.

Otra información La verificación de los controles de continuidad de la seguridad de la información son diferente 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

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. Guía de implementación 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. Otra información 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 113



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.

18.1.1

Identificación de requisitos contractuales 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. Guía de implementació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. Guía de implementación Deberían considerarse los siguientes lineamientos para proteger cualquier material que pueda ser considerado propiedad intelectual: a) publicar una una política 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 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 las licencias, licencias, discos 114



maestros, manuales, etc. 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 una política política para el mantenimiento mantenimiento apropiado 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 por la ley de derechos de autor. autor.

Otra información Los derechos de propiedad intelectual incluyen los derechos del 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, 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 m ultas 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. Guía de implementación implementación 115



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 (ver clausula 10), también debería 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 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. 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: or ganización: a)

deberían emitirse directrices 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 conservació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.

Otra información Algunos registros podrían necesitar ser conservados de manera segura para cumplir con requisitos normativos, regulatorios o contractuales, así como para soportar las actividades 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 116



establecer el periodo de tiempo y datos contenidos de la información a conservar. Información adicional sobre la gestión de registros de una organización se puede encontrar en la 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. Guía de implementación 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 ersonales 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 implemetarse medidas técnicas y organizacionales apropiadas para proteger la información de datos personales. Otra información La 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. Guía de implementación 117



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 para proporcionan confidencialidad del contenido.

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



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 (ver 5.1.1), la gerencia debería considerar acciones correctivas. Otra información Las NTP ISO/IEC 27007 “Lineamientos para la auditoría de sistemas de gestión de seguridad de la información” y NTP RT ISO/IEC TR 27008 “Lineamientos para auditores sobre controles de seguridad de la información” también proporcionan directrices 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. 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. 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;

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 (ver 18.2.1) cuando una revisión independiente se realice en el área de sus responsabilidades. Otra información El monitoreo operacional del sistema utilizado se cubre en el apartado 12.4.

18.2.3

Revisión del cumplimiento técnico 119



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. Guía de implementació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 planificados, documentados y repetibles. Cualquier revisión del cumplimiento técnico sólo debería realizarse por personas competentes, autorizadas, o bajo la supervisión de estas personas. Otra información 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 NTP RT ISO/IEC TR 27008 proporciona orientación específica con respecto a las revisiones de cumplimiento técnico.

120

ISO_IEC_NTP-27002[1]

Recommend Documents