UNE-ISO(IEC_27002=2009
120
norma español TÍTULO Tecno Técni Códig la info Informatio Technolog de l'inform CORRESPONDENCIA Esta nor OBSERVACIONES Esta nor ANTECEDENTES Esta no informa Editada e impresa por AENOR Depósito legal: M 51764:2009 LAS OBSE AENOR 2009 Reproducción prohibida Génova, 6 28004 MADRID-Españ la UNE-ISO ología de la Información cas de seguridad go de buenas prácticas para la gestión d ormación on technology. Security techniques. Code of practice for information s gies de l'information. Techniques de sécurité. Code de bonne pratique mation. rma es idéntica a la Norma Internacional ISO/IEC 2700 rma anula y sustituye a la Norma UNE-ISO/IEC 17799: rma ha sido elaborada por el comité técnico AEN/CT ación cuya Secretaría desempeña AETIC. ERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A: [email protected] ña www.aenor.es Tel.: 902 Fax: 913 O/IEC 27002 Diciembre 2009 de la seguridad de security management. e pour la gestion de la sécurité 2:2005. :2002. TN 71 Tecnología de la 118 Páginas 102 201 104 032 Grupo 64
Transcript of UNE-ISO(IEC_27002=2009
norma español
TÍTULO Tecno
Técni Códigla info Informatio Technologde l'inform
CORRESPONDENCIA Esta nor
OBSERVACIONES Esta nor
ANTECEDENTES Esta no
informa
Editada e impresa por AENOR Depósito legal: M 51764:2009
LAS OBSE
AENOR 2009
Reproducción prohibida Génova, 6
28004 MADRID-Españ
la UNE-ISO
ología de la Información
cas de seguridad
go de buenas prácticas para la gestión dormación
on technology. Security techniques. Code of practice for information s
gies de l'information. Techniques de sécurité. Code de bonne pratiquemation.
rma es idéntica a la Norma Internacional ISO/IEC 2700
rma anula y sustituye a la Norma UNE-ISO/IEC 17799:
rma ha sido elaborada por el comité técnico AEN/CTación cuya Secretaría desempeña AETIC.
ERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:
ña www.aenor.esTel.: 902 Fax: 913
O/IEC 27002
Diciembre 2009
de la seguridad de
security management.
e pour la gestion de la sécurité
2:2005.
:2002.
TN 71 Tecnología de la
118 Páginas
102 201 104 032
Grupo 64
S
- 3 - ISO/IEC 27002:2005
ÍNDICE
Página
PRÓLOGO .............................................................................................................................................. 8
0 INTRODUCCIÓN .................................................................................................................. 9 0.1 ¿Qué es la seguridad de la información? .............................................................................. 9 0.2 ¿Por qué es necesaria la seguridad de la información? ....................................................... 9 0.3 Cómo establecer los requisitos de seguridad ........................................................................ 9 0.4 Evaluación de los riesgos de seguridad ............................................................................... 10 0.5 Selección de controles ........................................................................................................... 10 0.6 Punto de partida para la seguridad de la información ..................................................... 10 0.7 Factores críticos de éxito ...................................................................................................... 11 0.8 Desarrollo de directrices propias ........................................................................................ 12
1 OBJETO Y CAMPO DE APLICACIÓN ........................................................................... 12
2 TÉRMINOS Y DEFINICIONES ........................................................................................ 12
3 ESTRUCTURA DE ESTA NORMA .................................................................................. 14 3.1 Capítulos ............................................................................................................................... 14 3.2 Categorías principales de seguridad ................................................................................... 14
4 EVALUACIÓN Y TRATAMIENTO DEL RIESGO ........................................................ 15 4.1 Evaluación de los riesgos de seguridad ............................................................................... 15 4.2 Tratamiento de los riesgos de seguridad ............................................................................ 15
5 POLÍTICA DE SEGURIDAD ............................................................................................. 16 5.1 Política de seguridad de la información ............................................................................. 16 5.1.1 Documento de política de seguridad de la información .................................................... 16 5.1.2 Revisión de la política de seguridad de la información ..................................................... 17
6 ASPECTOS ORGANIZATIVOS DE LA SEGURIDAD DE LA INFORMACIÓN ...... 18 6.1 Organización interna ........................................................................................................... 18 6.1.1 Compromiso de la Dirección con la seguridad de la información .................................... 19 6.1.2 Coordinación de la seguridad de la información ............................................................... 19 6.1.3 Asignación de responsabilidades relativas a la seguridad de la información .................. 20 6.1.4 Proceso de autorización de recursos para el tratamiento de la información .................. 21 6.1.5 Acuerdos de confidencialidad .............................................................................................. 21 6.1.6 Contacto con las autoridades ............................................................................................... 22 6.1.7 Contacto con grupos de especial interés ............................................................................. 22 6.1.8 Revisión independiente de la seguridad de la información ............................................... 23
6.2 Terceros ................................................................................................................................. 23 6.2.1 Identificación de los riesgos derivados del acceso de terceros .......................................... 24 6.2.2 Tratamiento de la seguridad en la relación con los clientes .............................................. 25 6.2.3 Tratamiento de la seguridad en contratos con terceros .................................................... 27
7 GESTIÓN DE ACTIVOS .................................................................................................... 29 7.1 Responsabilidad sobre los activos ....................................................................................... 29 7.1.1 Inventario de activos ............................................................................................................ 29 7.1.2 Propiedad de los activos ....................................................................................................... 30 7.1.3 Uso aceptable de los activos ................................................................................................. 31
7.2 Clasificación de la información ........................................................................................... 31 7.2.1 Directrices de clasificación .................................................................................................. 31 7.2.2 Etiquetado y manipulado de la información ...................................................................... 32
ISO/IEC 27002:2005 - 4 -
8 SEGURIDAD LIGADA A LOS RECURSOS HUMANOS .............................................. 32 8.1 Antes del empleo ................................................................................................................... 32 8.1.1 Funciones y responsabilidades ............................................................................................ 33 8.1.2 Investigación de antecedentes .............................................................................................. 33 8.1.3 Términos y condiciones de contratación ............................................................................ 34
8.2 Durante el empleo ................................................................................................................. 35 8.2.1 Responsabilidades de la Dirección ...................................................................................... 35 8.2.2 Concienciación, formación y capacitación en seguridad de la información .................... 36 8.2.3 Proceso disciplinario ............................................................................................................ 36
8.3 Cese del empleo o cambio de puesto de trabajo ................................................................. 37 8.3.1 Responsabilidad del cese o cambio ..................................................................................... 37 8.3.2 Devolución de activos ........................................................................................................... 37 8.3.3 Retirada de los derechos de acceso ..................................................................................... 38
9 SEGURIDAD FÍSICA Y DEL ENTORNO ....................................................................... 38 9.1 Áreas seguras ........................................................................................................................ 38 9.1.1 Perímetro de seguridad física .............................................................................................. 39 9.1.2 Controles físicos de entrada ................................................................................................. 40 9.1.3 Seguridad de oficinas, despachos e instalaciones ............................................................... 40 9.1.4 Protección contra las amenazas externas y de origen ambiental ..................................... 40 9.1.5 Trabajo en áreas seguras ..................................................................................................... 41 9.1.6 Áreas de acceso público y de carga y descarga .................................................................. 41
9.2 Seguridad de los equipos ...................................................................................................... 42 9.2.1 Emplazamiento y protección de equipos ............................................................................ 42 9.2.2 Instalaciones de suministro .................................................................................................. 43 9.2.3 Seguridad del cableado ........................................................................................................ 43 9.2.4 Mantenimiento de los equipos ............................................................................................. 44 9.2.5 Seguridad de los equipos fuera de las instalaciones .......................................................... 44 9.2.6 Reutilización o retirada segura de equipos ........................................................................ 45 9.2.7 Retirada de materiales propiedad de la empresa .............................................................. 45
10 GESTIÓN DE COMUNICACIONES Y OPERACIONES .............................................. 46 10.1 Responsabilidades y procedimientos de operación ............................................................ 46 10.1.1 Documentación de los procedimientos de operación ......................................................... 46 10.1.2 Gestión de cambios ............................................................................................................... 47 10.1.3 Segregación de tareas ........................................................................................................... 47 10.1.4 Separación de los recursos de desarrollo, prueba y operación ......................................... 48
10.2 Gestión de la provisión de servicios por terceros ............................................................... 49 10.2.1 Provisión de servicios ........................................................................................................... 49 10.2.2 Supervisión y revisión de los servicios prestados por terceros ......................................... 49 10.2.3 Gestión del cambio en los servicios prestados por terceros .............................................. 50
10.3 Planificación y aceptación del sistema ................................................................................ 51 10.3.1 Gestión de capacidades ........................................................................................................ 51 10.3.2 Aceptación del sistema ......................................................................................................... 51
10.4 Protección contra el código malicioso y descargable ......................................................... 52 10.4.1 Controles contra el código malicioso .................................................................................. 52 10.4.2 Controles contra el código descargado en el cliente .......................................................... 53
10.5 Copias de seguridad ............................................................................................................. 54 10.5.1 Copias de seguridad de la información .............................................................................. 54
10.6 Gestión de la seguridad de las redes ................................................................................... 55 10.6.1 Controles de red ................................................................................................................... 55 10.6.2 Seguridad de los servicios de red ........................................................................................ 56
- 5 - ISO/IEC 27002:2005
10.7 Manipulación de los soportes .............................................................................................. 56 10.7.1 Gestión de soportes extraíbles ............................................................................................. 56 10.7.2 Retirada de soportes ............................................................................................................. 57 10.7.3 Procedimientos de manipulación de la información .......................................................... 58 10.7.4 Seguridad de la documentación del sistema ....................................................................... 58
10.8 Intercambio de información ................................................................................................ 59 10.8.1 Políticas y procedimientos de intercambio de información .............................................. 59 10.8.2 Acuerdos de intercambio ..................................................................................................... 61 10.8.3 Soportes físicos en tránsito .................................................................................................. 61 10.8.4 Mensajería electrónica ......................................................................................................... 62 10.8.5 Sistemas de información empresariales .............................................................................. 62
10.9 Servicios de comercio electrónico ........................................................................................ 63 10.9.1 Comercio electrónico ............................................................................................................ 63 10.9.2 Transacciones en línea ......................................................................................................... 65 10.9.3 Información públicamente disponible ................................................................................ 65
10.10 Supervisión ............................................................................................................................ 66 10.10.1 Registros de auditoría .......................................................................................................... 66 10.10.2 Supervisión del uso del sistema ........................................................................................... 67 10.10.3 Protección de la información de los registros .................................................................... 68 10.10.4 Registros de administración y operación ............................................................................ 69 10.10.5 Registro de fallos .................................................................................................................. 69 10.10.6 Sincronización del reloj........................................................................................................ 70
11 CONTROL DE ACCESO .................................................................................................... 70 11.1 Requisitos de negocio para el control de acceso ................................................................. 70 11.1.1 Política de control de acceso ................................................................................................ 70
11.2 Gestión de acceso de usuario ............................................................................................... 71 11.2.1 Registro de usuario ............................................................................................................... 72 11.2.2 Gestión de privilegios ........................................................................................................... 72 11.2.3 Gestión de contraseñas de usuario ...................................................................................... 73 11.2.4 Revisión de los derechos de acceso de usuario ................................................................... 74
11.3 Responsabilidades de usuario .............................................................................................. 74 11.3.1 Uso de contraseñas ............................................................................................................... 74 11.3.2 Equipo de usuario desatendido ........................................................................................... 75 11.3.3 Política de puesto de trabajo despejado y pantalla limpia ................................................ 76
11.4 Control de acceso a la red .................................................................................................... 76 11.4.1 Política de uso de los servicios en red ................................................................................. 77 11.4.2 Autenticación de usuario para conexiones externas .......................................................... 77 11.4.3 Identificación de los equipos en las redes ........................................................................... 78 11.4.4 Diagnóstico remoto y protección de los puertos de configuración ................................... 78 11.4.5 Segregación de las redes ....................................................................................................... 78 11.4.6 Control de la conexión a la red ............................................................................................ 79 11.4.7 Control de encaminamiento (routing) de red ..................................................................... 80
11.5 Control de acceso al sistema operativo ............................................................................... 80 11.5.1 Procedimientos seguros de inicio de sesión ........................................................................ 81 11.5.2 Identificación y autenticación de usuario ........................................................................... 82 11.5.3 Sistema de gestión de contraseñas ....................................................................................... 82 11.5.4 Uso de los recursos del sistema ............................................................................................ 83 11.5.5 Desconexión automática de sesión ...................................................................................... 83 11.5.6 Limitación del tiempo de conexión ..................................................................................... 84
11.6 Control de acceso a las aplicaciones y a la información .................................................... 84 11.6.1 Restricción del acceso a la información .............................................................................. 85 11.6.2 Aislamiento de sistemas sensibles ........................................................................................ 85
ISO/IEC 27002:2005 - 6 -
11.7 Ordenadores portátiles y teletrabajo .................................................................................. 85 11.7.1 Ordenadores portátiles y comunicaciones móviles ............................................................ 86 11.7.2 Teletrabajo ............................................................................................................................ 87 12 ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE LOS SISTEMAS DE INFORMACIÓN ........................................................................................................... 88 12.1 Requisitos de seguridad de los sistemas de información ................................................... 88 12.1.1 Análisis y especificación de los requisitos de seguridad .................................................... 88
12.2 Tratamiento correcto de las aplicaciones ........................................................................... 89 12.2.1 Validación de los datos de entrada ...................................................................................... 89 12.2.2 Control del procesamiento interno ..................................................................................... 90 12.2.3 Integridad de los mensajes ................................................................................................... 91 12.2.4 Validación de los datos de salida ......................................................................................... 91
12.3 Controles criptográficos ....................................................................................................... 91 12.3.1 Política de uso de los controles criptográficos .................................................................... 92 12.3.2 Gestión de claves ................................................................................................................... 93
12.4 Seguridad de los archivos del sistema ................................................................................. 94 12.4.1 Control del software en explotación ................................................................................... 94 12.4.2 Protección de los datos de prueba del sistema ................................................................... 95 12.4.3 Control de acceso al código fuente de los programas ........................................................ 96
12.5 Seguridad en los procesos de desarrollo y soporte ............................................................ 96 12.5.1 Procedimientos de control de cambios ............................................................................... 96 12.5.2 Revisión técnica de las aplicaciones tras efectuar cambios en el sistema operativo ....... 98 12.5.3 Restricciones a los cambios en los paquetes de software ................................................... 98 12.5.4 Fugas de información ........................................................................................................... 98 12.5.5 Externalización del desarrollo de software ........................................................................ 99
12.6 Gestión de la vulnerabilidad técnica ................................................................................... 99 12.6.1 Control de las vulnerabilidades técnicas .......................................................................... 100
13 GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN ................ 101 13.1 Notificación de eventos y puntos débiles de seguridad de la información ..................... 101 13.1.1 Notificación de eventos de seguridad de la información ................................................. 101 13.1.2 Notificación de puntos débiles de seguridad .................................................................... 103
13.2 Gestión de incidentes de seguridad de la información y mejoras ................................... 103 13.2.1 Responsabilidades y procedimientos ................................................................................ 103 13.2.2 Aprendizaje de los incidentes de seguridad de la información ....................................... 104 13.2.3 Recopilación de evidencias ................................................................................................ 105
14 GESTIÓN DE LA CONTINUIDAD DEL NEGOCIO ................................................... 106 14.1 Aspectos de seguridad de la información en la gestión de la continuidad del negocio . 106 14.1.1 Inclusión de la seguridad de la información en el proceso de gestión de la continuidad del negocio...................................................................................................... 106 14.1.2 Continuidad del negocio y evaluación de riesgos ............................................................. 107 14.1.3 Desarrollo e implantación de planes de continuidad que incluyan la seguridad de la información ................................................................................................................ 107 14.1.4 Marco de referencia para la planificación de la continuidad del negocio ..................... 108 14.1.5 Pruebas, mantenimiento y reevaluación de los planes de continuidad del negocio ...... 109
15 CUMPLIMIENTO ............................................................................................................. 110 15.1 Cumplimiento de los requisitos legales ............................................................................. 110 15.1.1 Identificación de la legislación aplicable .......................................................................... 110 15.1.2 Derechos de propiedad intelectual (IPR).......................................................................... 111 15.1.3 Protección de los documentos de la organización ............................................................ 112
- 7 - ISO/IEC 27002:2005
15.1.4 Protección de datos y privacidad de la información de carácter personal .................... 113 15.1.5 Prevención del uso indebido de los recursos de tratamiento de la información ........... 113 15.1.6 Regulación de los controles criptográficos ....................................................................... 114
15.2 Cumplimiento de las políticas y normas de seguridad y cumplimiento técnico ............ 114 15.2.1 Cumplimiento de las políticas y normas de seguridad .................................................... 114 15.2.2 Comprobación del cumplimiento técnico ......................................................................... 115
15.3 Consideraciones sobre la auditoría de los sistemas de información ............................... 116 15.3.1 Controles de auditoría de los sistemas de información ................................................... 116 15.3.2 Protección de las herramientas de auditoría de los sistemas de información ............... 116
BIBLIOGRAFIA ............................................................................................................................... 1177
ANEXO A (Informativo) NOTA NACIONAL ................................................................................ 118
ISO/IEC 27002:2005 - 8 -
PRÓLOGO
ISO (la Organización Internacional de Normalización) e IEC (la Comisión Electrotécnica Internacional) constituyen el sistema especializado para la normalización a nivel mundial. Los organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de normas internacionales a través de comités técnicos establecidos por las organizaciones respectivas para realizar acuerdos en los campos específicos de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en campos de interés mutuo. Otras organizaciones internacionales, públicas y privadas, en coordinación con ISO e IEC, también participan en el trabajo. En el campo de tecnologías de la información, ISO e IEC han establecido un comité técnico conjunto, el denominado ISO/IEC JTC 1. Las normas internacionales se redactan de acuerdo con las reglas establecidas en la Parte 2 de las Directivas ISO/IEC La tarea principal de los comités técnicos es preparar normas internacionales. Los proyectos de normas internacionales adoptados por los comités técnicos se envían a los organismos miembros para su votación. La publicación como norma internacional requiere la aprobación por al menos el 75% de los organismos miembros que emiten voto. Se llama la atención sobre la posibilidad de que algunos de los elementos de esta norma internacional puedan estar sujetos a derechos de patente. ISO e IEC no asumen la responsabilidad por la identificación de cualquiera o todos los derechos de patente. La Norma ISO/IEC 27002 ha sido elaborada por el Comité Técnico conjunto ISO/IEC JTC 1 Tecnología de la Información, SC 27, IT Técnicas de seguridad. Esta primera edición de la Norma ISO/IEC 27002 consta de las Normas Internacionales ISO/IEC 17799:2005 e ISO/IEC 17799:2005/Cor.1:2007. Su contenido técnico es idéntico a la Norma ISO/IEC 17799:2005. La Norma ISO/IEC 17799:2005/Cor.1:2007 cambia el código de la norma de 17799 a 27002. Las Normas ISO/IEC 17799:2005 e ISO/IEC 17799:2005/Cor.1:2007 se conservan provisionalmente hasta que se produzca la publicación de la segunda edición de la Norma ISO/IEC 27002. Se está desarrollando una familia de normas internacionales sobre Sistemas de Gestión de la Seguridad de la Información (SGSI). Esta familia incluye normas internacionales sobre requisitos, gestión del riesgo, métricas y mediciones así como una guía de implantación de los sistemas de gestión de la seguridad de la información. Dicha familia de normas adoptará un esquema de numeración que utilizará los números de la serie 27000 y siguientes.
- 9 - ISO/IEC 27002:2005
0 INTRODUCCIÓN
0.1 ¿Qué es la seguridad de la información?
La información es un activo que, como otros activos importantes de la empresa, es esencial para las operaciones de la organización, y en consecuencia necesita ser adecuadamente protegida. Esto cobra especial importancia en el entorno actual de creciente interconectividad de los negocios. Como resultado de esta creciente interconectividad, la información está en la actualidad, expuesta a un número creciente y a una gran variedad de amenazas y vulnerabilidades (véanse la Directrices de la OCDE1) para la Seguridad de Sistemas y Redes de Información). La información adopta diversas formas: puede estar impresa o escrita en papel, almacenada electrónicamente, transmitida por correo postal o por medios electrónicos, mostrada en videos o hablada en las conversaciones. Cualquiera que sea la forma que tome la información o los medios por los que se comparta o almacene, debería protegerse adecuadamente. La seguridad de la información es la protección de la información frente a un amplio elenco de amenazas con el fin de asegurar la continuidad del negocio, minimizar sus riesgos, y maximizar el retorno de las inversiones y las oportunidades de negocio. La seguridad de la información se consigue implantando un conjunto adecuado de controles, que incluyen políticas, procesos, procedimientos, estructuras organizativas y funciones de software y de hardware. Es necesario establecer, implantar, revisar y mejorar estos controles allá donde sea necesario, para asegurar que se cumplen los objetivos específicos de seguridad y de negocio de la organización. Esto debería hacerse de manera conjunta con otros procesos de gestión de negocio.
0.2 ¿Por qué es necesaria la seguridad de la información?
La información y los procesos, sistemas y redes que la soportan, son activos importantes de la empresa. La definición, consecución, mantenimiento, y mejora de la seguridad de la información pueden ser esenciales para mantener su competitividad, tesorería, rentabilidad, cumplimiento con la legislación e imagen comercial. Las organizaciones junto con sus sistemas de información y sus redes se enfrentan con amenazas de seguridad procedentes de una amplia variedad de fuentes, que incluyen fraudes basados en la utilización de la informática, espionaje, sabotaje, vandalismo, incendios o inundaciones. Las causas de daños tales como ataques por código malicioso, intrusión y denegación de servicio se están volviendo cada vez más comunes, ambiciosos y sofisticados. La seguridad de la información es importante tanto para las organizaciones del sector público como del sector privado, así como para proteger las infraestructuras críticas. En ambos sectores, la seguridad de la información funcionará como facilitador, por ejemplo para la Administración electrónica (e-goverment) o para los negocios electrónicos (e-business), así como para evitar o reducir riesgos importantes. La interconexión de las redes públicas y privadas, así como la compartición de los recursos de información incrementan la dificultad de conseguir un control de accesos adecuado. La tendencia hacia la informática distribuida debilita también la eficacia de un control central y especializado. Muchos sistemas de información no se han diseñado para ser seguros. La seguridad que puede lograrse a través de medios técnicos es limitada, y debería apoyarse en una gestión y unos procedimientos adecuados. La identificación de los controles que deberían instalarse requiere una planificación cuidadosa y una atención al detalle. La gestión de la seguridad de la información necesita, como mínimo, la participación de todos los empleados de la organización. También puede requerir la participación de los accionistas, proveedores, clientes, terceras partes u otras partes externas. La asesoría especializada por parte de organizaciones externas también puede ser necesaria.
0.3 Cómo establecer los requisitos de seguridad
Es esencial que una organización identifique sus requisitos de seguridad. Existen tres fuentes principales de dónde obtener los requisitos de seguridad. 1) Directrices de la OCDE para la Seguridad de los Sistemas y Redes de Información � Hacia una cultura de la seguridad. París: OCDE, julio de
2002. www.oecd.prg.
ISO/IEC 27002:2005 - 10 -
1 Una de las fuentes procede de la evaluación de los riesgos de la organización, teniendo en cuenta los objetivos y estrategia de negocio globales de la organización. A través de una evaluación de los riesgos se identifican las amenazas de los activos, se evalúa la vulnerabilidad y la probabilidad de su ocurrencia y se estima su impacto potencial.
2 Otra fuente es el conjunto de requisitos legales, estatutarios, reglamentarios y contractuales que debería satisfacer la
organización, sus socios comerciales, contratistas y proveedores de servicios, así como su entorno socio-cultural. 3 Una tercera fuente procede del conjunto de principios, objetivos y requisitos de negocio que la organización ha
desarrollado para el tratamiento de la información que da soporte a sus operaciones.
0.4 Evaluación de los riesgos de seguridad
Los requisitos de seguridad se identifican por una evaluación metódica de los riesgos de seguridad. El gasto derivado de la implantación de los controles debería equilibrarse con el posible impacto económico resultante de los fallos de seguridad. Los resultados de ésta evaluación ayudarán a encauzar y determinar una adecuada acción por parte de la Dirección así como las prioridades para gestionar los riesgos de seguridad de la información, y para la implantación de los controles seleccionados para proteger contra dichos riesgos. El proceso de evaluación del riesgo debería realizarse de manera periódica para contemplar cualquier cambio que pudiera tener influencia en los resultados de la evaluación del riesgo. Se puede encontrar más información sobre evaluación de los riesgos de seguridad en el apartado 4.1 �Evaluación de los riesgos de seguridad�
0.5 Selección de controles
Una vez que se han identificado los requisitos de seguridad y los riesgos, y se han tomado las decisiones sobre el tratamiento de los mismos, deberían elegirse e implantarse los controles apropiados que aseguren la reducción de los riesgos a un nivel aceptable. Pueden elegirse los controles de esta norma o de otros conjuntos de controles, o bien se pueden diseñar nuevos controles para cubrir adecuadamente las necesidades específicas. La selección de los controles de seguridad está sujeta a las decisiones de carácter organizativo basadas en los criterios de aceptación del riesgo, las opciones de tratamiento del riesgo y en los enfoques generales de gestión del riesgo aplicados a la organización, y debería depender también de toda la legislación y reglamentación nacional e internacional aplicable. Algunos de los controles expuestos en esta norma, pueden considerarse como principios que guían la gestión de la seguridad de la información, siendo aplicables a la mayoría de las organizaciones. Estos se explican con más detalle en el siguiente apartado denominado �Punto de partida para la seguridad de la información�. Se puede encontrar más información sobre selección de controles y otras posibilidades de tratamiento del riesgo en el apartado 4.2 �Tratamiento de los riesgos de seguridad�.
0.6 Punto de partida para la seguridad de la información
Un cierto número de controles pueden ser considerados como un punto de partida adecuado para implantar la seguridad de la información. Estos controles se basan en requisitos reglamentarios esenciales o bien son considerados como la mejor práctica habitual para la seguridad de la información. Los controles que se consideran esenciales para una organización desde un punto de vista legal incluyen, en función de la legislación aplicable:
a) la protección y privacidad de la información de carácter personal (véase 15.1.4);
b) la protección de los registros de la organización (véase 15.1.3);
c) los derechos sobre propiedad intelectual (véase 15.1.2).
- 11 - ISO/IEC 27002:2005
Los controles que se consideran la mejor práctica habitual para conseguir la seguridad de la información incluyen: a) el documento de política de seguridad de la información (véase 5.1.1); b) la asignación de responsabilidades de seguridad de la información (véase 6.1.3); c) la concienciación, formación y capacitación en seguridad de la información (véase 8.2.2); d) el procesado correcto en las aplicaciones (véase 12.2); e) la gestión de las vulnerabilidades técnicas (véase 12.6); f) la gestión de la continuidad del negocio (véase el capítulo 14); g) la gestión de los incidentes y las mejoras en seguridad de la información (véase 13.2).
Estos controles pueden aplicarse a la mayoría de las organizaciones y entornos. Debería tenerse en cuenta que aunque en esta norma se da importancia a todos los controles, la importancia de cualquier control debería determinarse a la luz de los riesgos específicos que afronta la organización. Por tanto y aunque el enfoque anterior se considere un buen punto de partida, no sustituye la selección de controles basada en una evaluación del riesgo.
0.7 Factores críticos de éxito
La experiencia muestra que los siguientes factores suelen ser críticos para el éxito de la implantación de la seguridad de la información en una organización: a) una política, objetivos y actividades de seguridad de la información que reflejen los objetivos de negocio; b) un enfoque y un marco para implantar, mantener, revisar y mejorar la seguridad de la información que sea
consistente con la cultura de la organización; c) el apoyo visible y el compromiso de todos los niveles de la Dirección; d) una buena comprensión de los requisitos de seguridad, de la evaluación del riesgo y de la gestión del riesgo; e) una difusión y comunicación eficaces sobre la seguridad de la información a todos los directores, empleados y
terceras partes, para conseguir la concienciación; f) la distribución de guías sobre la política de seguridad de la organización y de las normas a todos los directivos,
empleados y terceras partes; g) la existencia de recursos para financiar las actividades de gestión de seguridad de la información; h) el proporcionar una concienciación, formación y aprendizaje adecuados; i) el establecimiento de un proceso eficaz de gestión de incidentes de seguridad de la información; j) el establecimiento de un sistema de medición para evaluar el comportamiento del sistema de gestión de la seguridad
de la información y proporcionar sugerencias de mejora.
NOTA Las mediciones de seguridad de la información quedan fuera del alcance de esta norma. Los controles considerados como esenciales desde el punto de vista reglamentario dependen de la legislación que sea de aplicación.
ISO/IEC 27002:2005 - 12 -
0.8 Desarrollo de directrices propias
Este código de buenas prácticas puede verse como punto de partida para desarrollar unas guías específicas en la organización. Pueden no ser aplicables todas las recomendaciones y controles de este código de buenas prácticas. Incluso, pueden requerirse controles adicionales que esta norma no incluye. Cuando esto suceda puede ser útil mantener referencias cruzadas de los capítulos de esta norma con otros documentos que contengan guías adicionales de controles, que faciliten la comprobación del cumplimiento a los auditores y a otros socios de la organización. 1 OBJETO Y CAMPO DE APLICACIÓN
Esta norma internacional establece directrices y principios generales para el comienzo, la implantación, el mantenimiento y la mejora de la gestión de la seguridad de la información en una organización. Los objetivos descritos en esta norma internacional proporcionan una guía general basada en objetivos comúnmente aceptados para la gestión de la seguridad de la información. Los objetivos de control y los controles de esta norma internacional están diseñados para ser implantados conforme a los requisitos identificados a partir de una evaluación del riesgo. Esta norma internacional puede servir de guía práctica para el desarrollo de normas de seguridad dentro de una organización, y de prácticas efectivas de gestión de la seguridad, y así ayudar a construir la confianza en las actividades entre diferentes organizaciones. 2 TÉRMINOS Y DEFINICIONES
Para los fines de este documento se aplican los siguientes términos y definiciones.
2.1 activo: Cualquier cosa o bien que tiene valor para la organización. (ISO/IEC 13335-1:2004)
2.2 control: Medio de gestión del riesgo, que incluye políticas, procedimientos, directrices, prácticas o estructuras de la organización, y que pueden ser de naturaleza administrativa, técnica, de gestión o legal. NOTA En esta norma internacional el término �control� se utiliza como sinónimo de �salvaguarda o contramedida�.
2.3 directriz: Una descripción que clarifica lo que se debería hacer y cómo debería hacerse, para conseguir los objetivos establecidos en las políticas. (ISO/IEC 13335-1:2004)
2.4 recursos de tratamiento de la información: Cualquier sistema, servicio o infraestructura de tratamiento de la información, o bien las localizaciones físicas que alojan dicho sistema, servicio o infraestructura.
2.5 seguridad de la información: La preservación de la confidencialidad, la integridad y la disponibilidad de la información, pudiendo, además, abarcar otras propiedades, como la autenticidad, la responsabilidad, la fiabilidad y el no repudio.
2.6 evento de seguridad de la información: La ocurrencia detectada en un estado de un sistema, servicio o red que indica una posible violación de la política de seguridad de la información, un fallo de las salvaguardas o una situación desconocida hasta el momento y que puede ser relevante para la seguridad. (ISO/IEC TR 18044:2004)
- 13 - ISO/IEC 27002:2005
2.7 incidente de seguridad de la información: Un único evento o una serie de eventos de seguridad de la información, inesperados o no deseados, que tienen una probabilidad significativa de comprometer las operaciones empresariales y de amenazar la seguridad de la información. (ISO/IEC TR 18044:2004)
2.8 política: Intención e instrucción global en la manera que formalmente ha sido expresada por la Dirección de la organización.
2.9 riesgo: Combinación de la probabilidad de un suceso y de su consecuencia. (Guía ISO/IEC 73:2002)
2.10 análisis de riesgos: Utilización sistemática de la información disponible para identificar peligros y estimar los riesgos. (Guía ISO/IEC 73:2002)
2.11 evaluación de riesgos: El proceso general de análisis y estimación de los riesgos. (Guía ISO/IEC 73:2002)
2.12 estimación de riesgos: El proceso de comparación del riesgo estimado con los criterios de riesgo, para así determinar la importancia del riesgo. (Guía ISO/IEC 73:2002)
2.13 gestión de riesgos: Actividades coordinadas para dirigir y controlar una organización con respecto a los riesgos. NOTA La gestión de riesgos habitualmente engloba la evaluación, el tratamiento, la aceptación y la comunicación de los riesgos. (Guía ISO/IEC 73:2002)
2.14 tratamiento de riesgos: El proceso de selección e implantación de las medidas encaminadas a modificar los riesgos. (Guía ISO/IEC 73:2002)
2.15 terceros Aquella persona o entidad que está reconocida como independiente de las partes implicadas para el asunto en cuestión.
2.16 amenaza: Posible causa de un incidente no deseado, el cual puede ocasionar un daño a un sistema o a una organización. (ISO/IEC 13335-1:2004)
2.17 vulnerabilidad Debilidad de un activo o grupo de activos que puede ser explotada por una o más amenazas. (ISO/IEC 13335-1:2004)
ISO/IEC 27002:2005 - 14 -
3 ESTRUCTURA DE ESTA NORMA
Esta norma consta de 11 capítulos de controles de seguridad que contienen un total de 39 categorías principales de seguridad y un capítulo introductorio sobre evaluación y tratamiento de los riesgos.
3.1 Capítulos
Cada capítulo contiene un número de categorías principales de seguridad. Los once capítulos (junto con el número de categorías principales de seguridad incluidas dentro de cada capítulo) son los siguientes: a) Política de seguridad (1); b) Aspectos organizativos de la seguridad de la información (2); c) Gestión de activos (2); d) Seguridad ligada a los recursos humanos (3); e) Seguridad física y ambiental (2); f) Gestión de comunicaciones y operaciones (10); g) Control de acceso (7); h) Adquisición, desarrollo y mantenimiento de los sistemas de información. (6); i) Gestión de incidentes de seguridad de la información (2); j) Gestión de la continuidad del negocio (1); k) Cumplimiento (3). NOTA El orden de los capítulos de esta norma no implica un orden de importancia. En función de las circunstancias, todos los capítulos pueden ser
importantes, por lo tanto cada organización que aplique esta norma debería identificar qué capítulos le son aplicables, cómo son de importantes y su aplicación a cada proceso de negocio. Además, el orden de la lista de controles de esta norma no implica orden de prioridad a menos que así se indique.
3.2 Categorías principales de seguridad
Cada categoría principal de seguridad contiene: a) un objetivo del control que establece qué es lo que se quiere conseguir; y b) uno o más controles que pueden ser aplicados para conseguir el objetivo del control. Las descripciones de cada control se estructuran de la siguiente manera: Control Define la declaración del control específico para conseguir el objetivo del control. Guía de implantación Proporciona información más detallada para dar apoyo a la implantación del control y la consecución del objetivo del control. Algunas de estas directrices pueden no ser apropiadas para todos los casos, pudiendo ser más adecuadas otras vías de implantación del control.
- 15 - ISO/IEC 27002:2005
Información adicional Proporciona información adicional, cuya consideración puede ser necesaria, por ejemplo consideraciones legales y referencias a otras normas. 4 EVALUACIÓN Y TRATAMIENTO DEL RIESGO
4.1 Evaluación de los riesgos de seguridad
Las evaluaciones del riesgo deberían identificar, cuantificar y priorizar los riesgos según los criterios establecidos para la aceptación del riesgo y según los objetivos relevantes para la organización. Los resultados deberían guiar y determinar las acciones y las prioridades para la dirección de cara a la gestión de los riesgos de seguridad de la información y la implantación de los controles seleccionados, para proteger a la organización contra dichos riesgos. Puede ser necesario que los procesos de evaluación del riesgo y de selección de controles se lleven a cabo un número determinado de veces para cubrir las diferentes partes de la organización, o bien sistemas de información individuales. La evaluación del riesgo incluye la aproximación sistemática para estimar la magnitud de los riesgos (análisis de riesgos) y el proceso de comparación de los riesgos estimados contra criterios de riesgo para determinar la importancia de los riesgos (estimación de los riesgos). Las evaluaciones de los riesgos deberían realizarse también de manera periódica para contemplar los cambios en los requisitos de seguridad y en la situación del riesgo, por ejemplo cambios en los activos, las amenazas, las vulnerabilidades, los impactos, la estimación del riesgo, y cuando se produzcan cambios significativos. Las evaluaciones del riesgo deberían llevarse a cabo de una manera metódica y capaz de producir unos resultados comparables y reproducibles. Para que la información de la evaluación de los riesgos de seguridad sea efectiva, debería tener un ámbito de aplicación claramente definido, e incluir relaciones con evaluaciones del riesgo en otras áreas, cuando sea apropiado. El ámbito de aplicación de la evaluación de los riesgos puede ser la toda la organización, partes de la organización, sistemas de información individuales, componentes de sistemas específicos, o servicios siempre que este ámbito sea factible, realista, y útil. Ejemplos de metodologías de evaluaciones del riesgo se proponen en la Norma ISO/IEC TR 13335 (Directrices para la gestión de la seguridad de las TI. Técnicas para la gestión de la seguridad de las TI).
4.2 Tratamiento de los riesgos de seguridad
Previo a la consideración del tratamiento del riesgo, la organización debería decidir un criterio para determinar cuando un riesgo es o no es aceptable. Por ejemplo, establecer que los riesgos pueden aceptarse cuando el riesgo sea bajo o el coste del tratamiento no sea rentable para la organización. Tales decisiones se deberían registrar. Para cada uno de los riesgos identificados después de la evaluación del riesgo, es necesario llevar a cabo un tratamiento de dichos riesgos. Las posibles opciones para el tratamiento del riesgo incluyen: a) la aplicación de controles apropiados para reducir los riesgos; b) la aceptación consciente y objetiva de los riesgos, proporcionando evidencias claras del cumplimiento con la política
de la organización y con los criterios de aceptación de los riesgos; c) el evitar los riesgos mediante la prohibición de las acciones que pudieran dar lugar a que se produjeran tales riesgos; d) la transferencia de los riesgos asociados a otras partes, por ejemplo a aseguradoras o a proveedores.
ISO/IEC 27002:2005 - 16 -
Para aquellos riesgos dónde la decisión sobre el tratamiento de los mismos ha sido la aplicación de los controles apropiados, dichos controles deberían ser seleccionados e implantados para ser conformes con los requisitos identificados en la evaluación del riesgo. Los controles deberían garantizar que los riesgos se reducen a un nivel aceptable, teniendo en cuenta lo siguiente: a) los requisitos y obligaciones de las legislaciones y reglamentaciones nacionales e internacionales aplicables; b) los objetivos de la organización; c) los requisitos de operación y las obligaciones; d) el coste de la implantación y operación en relación a los riesgos a reducir, manteniendo la proporcionalidad con los
requisitos y obligaciones de la organización; e) la necesidad de compensar la inversión en la implantación y operación de los controles con los posibles daños
resultantes de los fallos de seguridad. Los controles pueden seleccionarse de esta norma o de otros conjuntos de controles, o bien diseñarse nuevos controles para responder a necesidades específicas de la organización. Es necesario admitir que algunos controles pueden no ser aplicables a todos los sistemas de información o a todos los entornos, y podría no ser factible su aplicación para todas las organizaciones. A modo de ejemplo, el apartado 10.1.3 describe cómo se pueden segregar las tareas para prevenir el fraude y el error. Para organizaciones pequeñas puede no ser posible tal segregación de tareas y son necesarios otros caminos para conseguir el mismo objetivo de control. Otro ejemplo, el apartado 10.10 describe como puede ser monitorizado el uso de un sistema y como recoger las evidencias. Algunos de los controles descritos como por ejemplo el registro de eventos, pueden estar en conflicto con la legislación aplicable, como por ejemplo la relativa a la protección de la privacidad de los clientes o de los trabajadores. Los controles de seguridad de la información deberían ser considerados en la fase de diseño y de especificación de los requisitos, de los sistemas y de los proyectos. Si esto no se hace así, puede dar lugar a costes adicionales y soluciones menos efectivas y pueden, en el peor de los casos, imposibilitar la consecución de un nivel adecuado de seguridad. Debería tenerse presente que ningún conjunto de controles puede garantizar una seguridad completa, debiéndose implantar acciones de gestión adicionales para monitorizar, estimar y mejorar la eficiencia y eficacia de los controles de seguridad que dan apoyo a los objetivos de la organización. 5 POLÍTICA DE SEGURIDAD
5.1 Política de seguridad de la información
Objetivo: La Dirección proporcionará indicaciones y dará apoyo a la seguridad de la información de acuerdo con los requisitos del negocio y con la legislación y las normativas aplicables. La Dirección debería establecer de forma clara la política de actuación en línea con los objetivos de negocio y poner de manifiesto su apoyo y compromiso con la seguridad de la información, publicando y manteniendo una política de seguridad de la información en toda la organización.
5.1.1 Documento de política de seguridad de la información
Control La Dirección debería aprobar un documento de política de seguridad de la información, publicarlo y distribuirlo a todos los empleados y terceros afectados.
- 17 - ISO/IEC 27002:2005
Guía de implantación El documento de política de seguridad de la información debería establecer el compromiso de la Dirección así como el enfoque de la organización para gestionar la seguridad de la información. El documento de política debería contener declaraciones relativas a: a) una definición de la seguridad de la información y sus objetivos globales, el alcance de la seguridad y su
importancia como mecanismo que permite compartir la información (véase el capítulo de Introducción); b) el establecimiento de las intenciones de la Dirección en base a los objetivos y principios de la seguridad de la
información, en línea con los objetivos y la estrategia del negocio; c) un marco para el establecimiento de los controles y objetivos de cada control, incluyendo la estructura de la
evaluación y de la gestión del riesgo; d) una breve explicación de las políticas, principios, normas y cumplimiento de los requisitos más importantes para la
organización, por ejemplo:
1) cumplimiento de los requisitos legales, reglamentarios y contractuales; 2) requisitos de capacitación, formación, y concienciación en seguridad; 3) gestión de la continuidad del negocio; 4) consecuencias de las violaciones de la política de seguridad;
e) una definición de las responsabilidades generales y específicas en materia de gestión de la seguridad de la información, incluyendo la comunicación de los incidentes de seguridad de la información;
f) las referencias a documentación que pueda sustentar la política; por ejemplo, políticas y procedimientos más
detallados para sistemas de información específicos o las reglas de seguridad que los usuarios deberían cumplir. Esta política de seguridad de la información debería ser comunicada a toda la organización, llegando hasta los destinatarios en una forma que sea apropiada, entendible y accesible al lector al que va dirigida. Información adicional La política de seguridad de la información debería formar parte de un documento de política general. Si la política de seguridad de la información es distribuida al exterior de la organización, se debería tener cuidado en no revelar información sensible. Más información sobre este tema puede encontrarse en la Norma ISO/IEC 13335-1:2004. 5.1.2 Revisión de la política de seguridad de la información
Control La política de seguridad de la información debería revisarse a intervalos planificados o siempre que se produzcan cambios significativos, a fin de asegurar que se mantenga su idoneidad, adecuación y eficacia. Guía de implantación La política de seguridad de la información debería tener un propietario a quien se le ha asignado la gestión de las responsabilidades para su desarrollo, revisión y evaluación. La revisión debería incluir la evaluación de oportunidades de mejora de la política de seguridad y un enfoque de cómo gestionar la seguridad de la información en respuesta a los cambios del entorno de la organización, de las circunstancias del negocio, de las condiciones legales reglamentarias o contractuales o del entorno técnico. La revisión de la política de seguridad de la información debería tener en cuenta los resultados de las revisiones por la Dirección. Deberían definirse procedimientos para las revisiones por la Dirección, incluyendo un calendario o los periodos de revisión.
ISO/IEC 27002:2005 - 18 -
Los datos de entrada para la revisión por la Dirección deberían incluir información sobre: a) respuestas y aportaciones de las partes interesadas; b) resultados de revisiones independientes (véase 6.1.8); c) estado de las acciones preventivas y correctivas (véase 6.1.8 y 15.2.1); d) resultados de las anteriores revisiones por la Dirección; e) resultado del proceso y cumplimiento de la política de seguridad de la información; f) cambios que pudieran afectar al enfoque de la organización para la gestión de la seguridad de la información,
incluyendo cambios del entorno de la organización, de las circunstancias del negocio, en la disponibilidad de los recursos, en las condiciones legales, reglamentarias o contractuales o del entrono técnico;
g) tendencias relativas a amenazas y vulnerabilidades; h) informe de los incidentes de seguridad de la información (véase 13.1); i) recomendaciones proporcionadas por las autoridades competentes (véase 6.1.6). Los resultados del proceso de revisión por la Dirección deberían incluir cualquier decisión y actuación relativas a: a) la mejora del enfoque de la organización para la gestión de la seguridad de la información y sus procesos; b) la mejora de los controles y objetivos de cada control; c) la mejora de la localización de los recursos y/o las responsabilidades. Se debería mantener un registro de las revisiones de la Dirección llevadas a cabo. Se debería obtener la aprobación de la política revisada por parte de la Dirección. 6 ASPECTOS ORGANIZATIVOS DE LA SEGURIDAD DE LA INFORMACIÓN
6.1 Organización interna
Objetivo: Gestionar la seguridad de la información dentro de la organización. Debería establecerse una estructura de gestión para iniciar y controlar la implantación de la seguridad de la información dentro de la organización. La Dirección debería aprobar la política de seguridad de la información, asignando roles o funciones de seguridad, así como coordinar y revisar la implantación de la seguridad en toda la organización. Si fuera necesario, debería establecerse el asesoramiento de especialistas en seguridad de la información y que este asesoramiento estuviera disponible en la organización. Deberían desarrollarse contactos con grupos o especialistas externos en seguridad, incluidas las autoridades competentes, para mantenerse al día de las tendencias de la industria, la evolución de las normas y los métodos de evaluación, que proporcionen un punto de enlace adecuado para tratar las incidencias de seguridad de la información. Debería fomentarse un enfoque multidisciplinario de la seguridad de la información.
- 19 - ISO/IEC 27002:2005
6.1.1 Compromiso de la Dirección con la seguridad de la información
Control La Dirección debería prestar un apoyo activo a la seguridad dentro de la organización a través de directrices claras, un compromiso demostrado, asignaciones explícitas y el reconocimiento de las responsabilidades de seguridad de la información. Guía de implantación La Dirección debería: a) asegurarse de que se han identificado los objetivos de seguridad de la información, conforme a los requisitos de la
organización y que están integrados en los procesos correspondientes; b) formular, revisar y aprobar la política de seguridad de la información; c) revisar la eficacia de la implantación de la política de seguridad de la información; d) proporcionar una orientación clara y un apoyo visible a las iniciativas de seguridad; e) proporcionar los recursos necesarios para la seguridad de la información; f) aprobar la asignación de roles o funciones y responsabilidades específicos para la seguridad de la información en
toda la organización; g) iniciar planes y programas para mantener la concienciación en seguridad de la información; h) asegurarse de que la implantación de los controles de seguridad de la información se coordina a través de toda la
organización (véase 6.1.2). La Dirección debería identificar las necesidades de asesoramiento por parte de especialistas en seguridad de la información internos o externos, así como revisar y coordinar los resultados del asesoramiento a través de toda la organización. Dependiendo del tamaño de la organización, tales responsabilidades deberían ser desempeñadas por un órgano de gestión especialmente dedicado a esa labor o bien por un órgano directivo ya existente, como por ejemplo el consejo de Dirección. Información adicional Información adicional se encuentra en la Norma ISO/IEC 13335-1:2004 6.1.2 Coordinación de la seguridad de la información
Control Las actividades relativas a la seguridad de la información deberían ser coordinadas entre los representantes de las diferentes partes de la organización con sus correspondientes roles y funciones de trabajo. Guía de implantación Normalmente la coordinación de la seguridad de la información debería involucrar la cooperación y colaboración de directivos, usuarios, administradores, diseñadores de aplicaciones, auditores y personal de seguridad, así como otros perfiles específicos en áreas como seguros, departamento jurídico, recursos humanos, TI o gestión del riesgo. Esta actividad debería: a) asegurar que las actividades de seguridad se ejecutan de acuerdo con la política de seguridad de la información; b) identificar como manejar las no conformidades;
ISO/IEC 27002:2005 - 20 -
c) aprobar metodologías y procesos para la seguridad de la información, por ejemplo, la evaluación del riesgo, la clasificación de la información;
d) identificar cambios significativos en las amenazas y en la exposición de la información y en los recursos de
tratamiento para las amenazas; e) evaluar la adecuación y coordinar la implantación de los controles de seguridad de la información; f) promover de una manera efectiva el aprendizaje, formación y la concienciación en seguridad de la información en
toda la organización; g) evaluar la información recibida de la supervisión y revisión de los incidentes de seguridad de la información y
recomendar acciones adecuadas en respuesta a los incidentes de seguridad que se han identificado. Si la organización no utiliza un grupo separado formado por representantes de diferentes funciones dentro de la organización, por ejemplo debido a que tal grupo no es apropiado por el tamaño de la organización, las acciones descritas arriba deberían ser llevadas a cabo por otro órgano de la Dirección adecuado o bien por un director de manera individual.
6.1.3 Asignación de responsabilidades relativas a la seguridad de la información
Control Deberían definirse claramente todas las responsabilidades relativas a la seguridad de la información. Guía de implantación La asignación de responsabilidades relativas a seguridad de la información debería realizarse de acuerdo con la política de seguridad de la información (véase el capítulo 4). Deberían definirse claramente las responsabilidades para la protección de activos individuales así como las responsabilidades para llevar a cabo procesos de seguridad específicos. Estas responsabilidades deberían completarse, dónde sea necesario, con una guía más detallada para ubicaciones, o recursos específicos. Se deberían definir de una manera clara las responsabilidades locales para la protección de los activos y para llevar a cabo procesos de seguridad específicos, tales como planes de continuidad de negocio. Aquellos individuos a los que se les han asignado responsabilidades de seguridad pueden delegar estas tareas de seguridad en otros. Sin embargo, los primeros mantienen la responsabilidad y deberían comprobar que todas las tareas delegadas han sido correctamente realizadas. Aquellas áreas para las que los individuos tienen asignadas responsabilidades deberían quedar claramente establecidas, en particular en relación a los siguientes aspectos: a) deberían identificarse y definirse claramente los activos y los procesos de seguridad asociados con cada sistema
específico; b) debería asignarse una entidad responsable para cada activo y deberían documentarse los detalles de esta
responsabilidad (véase 7.1.2); c) deberían definirse y documentarse claramente los niveles de autorización. Información adicional En muchas organizaciones se nombra un responsable de seguridad de la información para asumir la responsabilidad completa del desarrollo e implantación de la seguridad y para dar soporte a la identificación de los controles. Sin embargo, la responsabilidad de la provisión e implantación de los controles a menudo permanece en directivos a título individual. Una práctica común es nombrar un propietario para cada activo quien se hace responsable de la protección del día a día.
- 21 - ISO/IEC 27002:2005
6.1.4 Proceso de autorización de recursos para el tratamiento de la información
Control Para cada nuevo recurso de tratamiento de la información, debería definirse e implantarse un proceso de autorización por parte de la Dirección. Guía de implantación Deberían considerarse las siguientes directrices para el proceso de autorización: a) los nuevos recursos deberían tener la aprobación de la gestión de usuario adecuada, autorizando su propósito y su
uso. La autorización también debería obtenerse del director responsable del mantenimiento del entorno de seguridad del sistema de información local, asegurando que cumple con todas las políticas y requisitos de seguridad correspondientes;
b) dónde sea necesario, se debería comprobar que el hardware y el software son compatibles con los demás
componentes del sistema; c) el uso de medios informáticos personales o privados para el tratamiento de la información por ejemplo dispositivos
portátiles, ordenadores de uso doméstico, dispositivos de mano, para el tratamiento de la información relativa al negocio de la organización puede introducir nuevas vulnerabilidades, por lo que se deberían identificar e implantar los controles necesarios.
6.1.5 Acuerdos de confidencialidad
Control Debería determinarse y revisarse periódicamente la necesidad de establecer acuerdos de confidencialidad o no revelación, que reflejen las necesidades de la organización para la protección de la información. Guía de implantación Los acuerdos de confidencialidad o no revelación deberían recoger los requisitos de protección de la información confidencial a través de términos legales ejecutables. Para identificar los requisitos para los acuerdos de confidencialidad o no revelación, se deberían tener en cuenta los siguientes elementos: a) una definición de la información que se ha de proteger (por ejemplo información confidencial); b) la duración esperada del acuerdo, incluidos los casos donde pueda ser necesario mantener la confidencialidad
indefinidamente; c) las acciones requeridas cuando finalice el acuerdo; d) las responsabilidades y acciones de los firmantes para evitar la revelación no autorizada de la información (en inglés
�need to know�); e) el propietario de la información, secretos comerciales y propiedad intelectual, y cuál es su relación con la protección
de la información confidencial; f) el uso permitido de la información confidencial y los derechos del firmante para el uso de la información; g) el derecho de auditar y controlar las actividades que implican el uso de información confidencial; h) los procesos para la notificación e informe de cualquier revelación no autorizada o infracciones sobre información
confidencial; i) las condiciones para la devolución o destrucción de la información una vez cesa el acuerdo, y j) las acciones que se han de tomar en caso de ruptura del acuerdo.
ISO/IEC 27002:2005 - 22 -
Puede ser necesario incluir en los acuerdos de confidencialidad o no revelación otros elementos basados en los requisitos de seguridad de la organización. Los acuerdos de confidencialidad y no revelación deberían cumplir con la legislación y reglamentación aplicable en la jurisdicción donde aplican (véase 15.1.1). Los requisitos de los acuerdos de confidencialidad y no revelación deberían revisarse periódicamente y siempre que se produzcan cambios que tengan influencia en dichos requisitos. Información adicional Los acuerdos de confidencialidad y no revelación protegen la información de la organización e informan a los firmantes del acuerdo de sus responsabilidades relativas a la protección, utilización y revelación de información de una manera responsable y autorizada. Dentro de una misma organización, puede ser necesario el utilizar diferentes formas de acuerdos de confidencialidad o no revelación para diferentes circunstancias. 6.1.6 Contacto con las autoridades
Control Deberían mantenerse los contactos adecuados con las autoridades competentes. Guía de implantación Las organizaciones deberían tener implantados procedimientos que especifiquen cuándo y con qué autoridades se debería contactar (por ejemplo autoridades encargadas de vigilar el cumplimiento de la legislación (cuerpo de policía, agencias de protección de datos, cuerpo de bomberos, autoridades de supervisión) y la manera adecuada de cómo se debería informar de los incidentes de seguridad de la información si se sospecha que se puede haber infringido la ley. Las organizaciones que han sufrido un ataque a través de Internet pueden necesitar de terceros (por ejemplo de un proveedor de servicios de Internet o de un operador de telecomunicaciones) para emprender alguna acción contra la fuente del ataque. Información adicional Puede requerirse el mantenimiento de tales contactos para dar soporte a la gestión de los incidentes de seguridad de la información (véase 13.2) o a la continuidad del negocio y a los planes de contingencia (véase el capítulo 14). Los contactos con las autoridades encargadas de vigilar el cumplimiento de la legislación son también útiles de cara a anticiparse y prepararse para los cambios que vendrán en nuevas leyes o reglamentaciones y que la organización tendrá que cumplir. Los contactos con otras autoridades, incluyen las empresas de servicios públicos, servicios de emergencias, de seguridad y sanidad como por ejemplo cuerpos de bomberos (en relación a la continuidad del negocio), proveedores de telecomunicación (en relación con la disponibilidad del servicio y la selección de rutas), compañías de suministro de agua (en relación con las instalaciones de refrigeración para los equipos). 6.1.7 Contacto con grupos de especial interés
Control Deberían mantenerse los contactos adecuados con grupos de interés especial, u otros foros, y asociaciones profesionales especializadas en seguridad. Guía de implantación La participación como miembro en grupos de interés especial o foros deberían ser considerados como medio para: a) mejorar el conocimiento sobre las mejores prácticas y mantenerse actualizado sobre información relevante de seguridad; b) asegurar que el entendimiento del entorno de seguridad de la información es actual y correcto; c) recibir avisos tempranos de alertas, asesoramiento y parches correspondientes a los ataques y las vulnerabilidades;
- 23 - ISO/IEC 27002:2005
d) obtener acceso a asesoramiento especialista en seguridad de la información; e) compartir e intercambiar información sobre nuevas tecnologías, productos, amenazas o vulnerabilidades; f) proporcionar adecuados puntos de enlace relacionados con incidentes de seguridad de la información (véase 13.2.1). Información adicional Se pueden establecer acuerdos de intercambio de información para mejorar la cooperación y coordinación en los asuntos de seguridad. Tales acuerdos deberían identificar los requisitos para proteger la información sensible. 6.1.8 Revisión independiente de la seguridad de la información
Control El enfoque de la organización para la gestión de la seguridad de la información y su implantación (es decir, los objetivos de control, los controles, las políticas, los procesos y los procedimientos para la seguridad de la información), debería someterse a una revisión independiente a intervalos planificados o siempre que se produzcan cambios significativos en la implantación de la seguridad. Guía de implantación La revisión independiente debería comenzar por la Dirección. Esta revisión independiente es necesaria para asegurar la idoneidad, adecuación y eficacia del enfoque de la organización para la gestión de la seguridad de la información. La revisión debería incluir la evaluación de oportunidades de mejora así como cuando sean necesarios, cambios en el enfoque de seguridad incluyendo la política y los objetivos del control. Tal revisión debería llevarse a cabo por personal independiente del área que está bajo revisión, por ejemplo por auditoría interna, por un director independiente, o por una tercera parte especializada en ese tipo de revisiones. El personal encargado de llevar a cabo tales revisiones debería tener la experiencia y el perfil adecuados. Los resultados de la revisión independiente deberían registrarse e informar de los mismos a la Dirección que inició la revisión. Esos registros deberían mantenerse. En el caso de que la revisión independiente identifique que el enfoque para implantar la gestión de la seguridad de la información no es el adecuado o no es conforme con la línea establecida en el documento de política de seguridad de la información (véase 5.1.1), la Dirección debería considerar el adoptar las acciones correctivas que correspondan. Información adicional El área que los directores deberían revisar de manera periódica (véase 15.2.1) también podría estar sujeta a una revisión independiente. Las técnicas de revisión pueden incluir entrevistas con la Dirección, comprobación de los registros o revisión de los documentos de política de seguridad. La Norma ISO 19011:2002 �Directrices para la auditoria de los sistemas de gestión de la calidad y/o ambiental� proporciona una guía de ayuda para llevar a cabo la revisión independiente, incluyendo el establecimiento y la implantación de un programa de revisión. El apartado 15.3 especifica los controles importantes para la revisión independiente de la operación de los sistemas de información y la utilización de las herramientas de auditoría del sistema.
6.2 Terceros
Objetivo: Mantener la seguridad de la información de la organización y de los dispositivos de tratamiento de la información que son objeto de acceso, procesado, comunicación o gestión por terceros. La seguridad de la información de la organización, así como la de los dispositivos de tratamiento de la información, no debería verse reducida por la introducción de productos o servicios de terceros. Debería controlarse cualquier acceso a los dispositivos de tratamiento de la información así como al tratamiento y comunicación de la información por terceros.
ISO/IEC 27002:2005 - 24 -
Cuando por motivos del negocio se necesita trabajar con terceros para lo que se requiere el acceso de éstos a la información de la organización, así como a los dispositivos de tratamiento de la información, o la obtención o suministro de un producto o servicio por parte de un tercero, se debería llevar a cabo una evaluación del riesgo para determinar las implicaciones de seguridad y los requisitos de control. Los controles deberían decidirse y definirse en un acuerdo con el tercero. 6.2.1 Identificación de los riesgos derivados del acceso de terceros
Control Deberían identificarse los riesgos para la información y para los dispositivos de tratamiento de la información de la organización derivados de los procesos de negocio que requieran de terceros, e implantar los controles apropiados antes de otorgar el acceso. Guía de implantación Dónde haya necesidad de permitir el acceso a terceros a los dispositivos de tratamiento de la información o a la información de una organización, debería llevarse a cabo una evaluación del riesgo (véase también el capítulo 4), para identificar cualquier requisito para los controles específicos. La identificación de los riesgos relativos al acceso de terceros debería tener en cuenta los siguientes aspectos: a) los dispositivos de tratamiento de la información que requieren acceso por parte del tercero; b) el tipo de acceso que el tercero tendrá a la información y a los dispositivos de tratamiento de la información, por
ejemplo:
1) acceso físico, por ejemplo, a despachos, centros de proceso de datos, bibliotecas, archivadores; 2) acceso lógico, por ejemplo, a bases de datos o a sistemas de información de la organización; 3) conectividad entre la(s) red(es) del tercero y la red de la organización, por ejemplo una conexión permanente, un
acceso remoto; 4) si el acceso tiene lugar dentro de las instalaciones de la organización o desde en el exterior (in-site/off-site);
c) el valor y la sensibilidad de la información involucrada y su criticidad para el funcionamiento del negocio; d) los controles necesarios para proteger la información que se pretende que no sea accesible por terceros; e) el personal del tercero involucrado en el tratamiento de la información de la organización; f) como se puede identificar a la organización o al personal al que se ha autorizado el acceso, cómo se verifica la
autorización y con qué frecuencia tiene que ratificarse; g) los diferentes medios y controles que el tercero emplea cuando almacena, procesa, comunica, comparte e intercambia
información; h) el impacto de que al acceso no esté disponible para el tercero cuando es requerido, así como el impacto producido
por qué el tercero introduzca o reciba información inexacta o engañosa; i) las prácticas y procedimientos para tratar los incidentes de seguridad de la información y los peligros potenciales, así
como los términos y las condiciones para mantener la continuidad del acceso del tercero en caso de producirse un incidente de seguridad;
j) los requisitos legales y reglamentarios y otras obligaciones contractuales aplicables al tercero que deberían ser
tenidos en cuenta; k) como pueden verse afectados los intereses de las partes interesadas por los acuerdos.
- 25 - ISO/IEC 27002:2005
No se debería autorizar el acceso a la información de la organización a terceros hasta que se hayan implantado los controles adecuados, y cuando sea posible, hasta que no se haya firmado un contrato que defina los términos y condiciones para la conexión o el acceso y los acuerdos de trabajo. Generalmente, todos los requisitos de seguridad o los controles internos resultantes de trabajar con terceros, deberían reflejarse en el contrato con el tercero (véanse 6.2.2 y 6.2.3). La organización debería asegurarse de que el tercero conoce y es consciente de sus obligaciones y acepta las responsabilidades y limitaciones que lleva implícitas el acceso, procesado, comunicación o gestión de la información y de los recursos de tratamiento de la información de la organización. Información adicional La información podría ponerse en situación de riesgo por parte de terceros debido a una gestión inadecuada de la seguridad. Se deberían identificar y aplicar controles para la administración del acceso a partes externas a los recursos de tratamiento de la información. Por ejemplo, en el caso de que exista una necesidad especial de confidencialidad de la información, se podrían utilizar acuerdos de no divulgación. En el caso de existir un alto grado de externalización, o donde existan varias partes externas implicadas, las organizaciones pueden enfrentarse con riesgos asociados a los procesos, a la gestión y a la comunicación inter organizacionales. Los controles 6.2.2 y 6.2.3 cubren acuerdos con distintos tipos de terceros, por ejemplo incluyen: a) proveedores de servicio tales como proveedores de servicios de Internet (ISPs), proveedores de red, de servicios
telefónicos, de mantenimiento y soporte de servicios; b) servicios de seguridad gestionada; c) clientes; d) externalización de recursos y/o operaciones, por ejemplo sistemas de TI, servicios de recogida de datos, centros de
atención de llamadas; e) consultores de gestión y de negocio, y auditores; f) desarrolladores y suministradores, por ejemplo de productos y sistemas de software y TI; g) servicios de limpieza, catering y otros servicios de apoyo que estén externalizados; h) personal de carácter temporal, contratación de estudiantes y otros nombramientos eventuales a corto plazo. Tales acuerdos pueden ayudar a reducir los riesgos asociados a terceros. 6.2.2 Tratamiento de la seguridad en la relación con los clientes
Control Deberían tratarse todos los requisitos de seguridad identificados, antes de otorgar acceso a los clientes a los activos o a la información de la organización. Guía de implantación Antes de dar acceso a los clientes a cualquier activo de la organización deberían considerarse los siguientes términos para abordar la seguridad (en función del tipo y alcance del acceso dado pueden no ser aplicables todos los términos): a) protección de activos, incluyendo:
1) procedimientos para proteger los activos de la organización, incluyendo la información y el software, así como la gestión de las vulnerabilidades conocidas;
ISO/IEC 27002:2005 - 26 -
2) procedimientos para determinar si ha ocurrido algún hecho que comprometa a los activos, por ejemplo pérdida o modificación de los datos;
3) integridad; 4) restricciones en el copiado y revelación de la información;
b) descripción del producto o servicio que se va a proporcionar: c) las diferentes razones, requisitos y beneficios del acceso del cliente; d) política de control de acceso, incluyendo:
1) métodos de acceso permitidos, así como el control y uso de identificadores únicos tales como contraseñas e identificadores de usuario;
2) un procedimiento de autorización de accesos y de asignación de privilegios de usuario; 3) una declaración que establezca que está prohibido cualquier acceso que no esté explícitamente autorizado; 4) un proceso de revocación derechos de acceso o de interrupción de la conexión entre los sistemas;
e) acuerdos para el informe, la notificación y la investigación de inexactitudes de información (por ejemplo de detalles personales), de incidentes de seguridad de la información y de infracciones de seguridad;
f) una descripción de cada servicio que ha de estar disponible; g) el nivel de servicio objetivo y los niveles de servicio inaceptables; h) el derecho de control y revocación de cualquier actividad relacionada con los activos de la organización; i) las responsabilidades respectivas de las partes del acuerdo; j) las responsabilidades relativas a cuestiones legales y cómo se garantiza el cumplimiento de los requisitos legales,
por ejemplo la legislación en protección de datos (especialmente si los acuerdos contemplan la cooperación con clientes en otros países se deberían tener en cuenta los diferentes sistemas legales);
k) derechos de propiedad intelectual (IPRs) y protección del copyright (véase 15.1.2) y protección de cualquier trabajo
u obra colectiva (véase 6.1.5). Información adicional Los requisitos de seguridad relativos al acceso de los clientes a los activos de la organización pueden variar considerablemente en función de los recursos de tratamiento de la información y de la información a la que se accede. Estos requisitos de seguridad pueden ser establecidos a través de acuerdos con el cliente, que contengan todos los riesgos identificados y los requisitos de seguridad (véase 6.2.1). Los acuerdos con terceros pueden también involucrar a otras partes. Los acuerdos que conceden los accesos a terceros deberían incluir complementos para designar a otras partes con derecho así como las condiciones para su acceso y participación.
- 27 - ISO/IEC 27002:2005
6.2.3 Tratamiento de la seguridad en contratos con terceros
Control Los acuerdos con terceros que conlleven acceso, procesado, comunicación o gestión, bien de la información de la organización, o de los recursos de tratamiento de la información, o bien la incorporación de productos o servicios a los recursos de tratamiento de la información, deberían cubrir todos los requisitos de seguridad pertinentes. Guía de implantación Los acuerdos deberían asegurar que no hay malentendidos entre la organización y los terceros. Las organizaciones deberían verse compensadas hasta la indemnización, por parte del tercero. Con objeto de satisfacer los requisitos de seguridad identificados (véase 6.2.1), deberían considerarse los siguientes aspectos de cara a su inclusión en el acuerdo, con objeto de satisfacer los requisitos de seguridad identificados (véase 6.2.1): a) la política sobre seguridad de la información; b) los controles para asegurar la protección de los activos, incluyendo:
1) procedimientos para proteger los activos de la organización, incluida la información, el software y el hardware; 2) cualquier control o mecanismo de protección física requerido; 3) controles para asegurar la protección contra el software malicioso (véase 10.4.1); 4) procedimientos para determinar si se ha producido algún hecho que comprometa a los activos, por ejemplo,
pérdida o modificación de información, software o hardware; 5) controles para asegurar la recuperación o destrucción de la información y los activos al finalizar el acuerdo o en
algún momento acordado dentro del periodo de vigencia del acuerdo; 6) la confidencialidad, integridad, disponibilidad, y cualquier otra propiedad importante de los activos (véase 2.1.5); 7) restricciones en la copia o revelación de la información; junto con la utilización de acuerdos de confidencialidad
(véase 6.1.5);
c) formación a los usuarios y al administrador en métodos, procedimientos y seguridad; d) asegurar la concienciación del usuario en las responsabilidades y asuntos relativos a seguridad de la información; e) disposiciones para los traslados de personal cuando sea oportuno; f) responsabilidades relativas a la instalación y mantenimiento del hardware y del software; g) una estructura clara de los informes y de los formatos de informe acordados; h) un proceso especificado y claro de la gestión del cambio; i) la política de control de acceso, incluyendo:
1) las diferentes razones, requisitos y beneficios que hacen necesario el acceso por el tercero; 2) los métodos de acceso permitidos, así como el control y uso de identificadores únicos, tales como el identificador
de usuario (ID) y las contraseñas; 3) el procedimiento de autorización del acceso y de asignación de privilegios a los usuarios;
ISO/IEC 27002:2005 - 28 -
4) el requisito de mantener actualizada y disponible la lista de usuarios autorizados para utilizar los servicios disponibles, así como los correspondientes derechos y privilegios con respecto a tal uso;
5) una declaración que establezca que está prohibido cualquier acceso que no esté explícitamente autorizado; 6) un proceso de revocación de derechos de acceso o de interrupción de la conexión entre los sistemas;
j) disposiciones para el reporte, notificación e investigación de los incidentes de seguridad de la información e infracciones de seguridad, así como violaciones de los requisitos establecidos en el acuerdo;
k) una descripción del producto o servicio que se va a proporcionar, y una descripción de la información que se hará
accesible, con su clasificación de seguridad (véase 7.2.1); l) el nivel de servicio objetivo y los niveles de servicio inaceptables; m) la definición de los criterios de verificación del desempeño, su control y reporte; n) el derecho de control, y revocación de, cualquier actividad relacionada con los activos de la organización; o) el derecho de auditar las responsabilidades definidas en el acuerdo, teniéndose que llevar a cabo tales auditorias por
una tercera parte, y de enumerar las obligaciones y derechos legales de los auditores; p) el establecimiento de un procedimiento de escalado para la resolución de los problemas; q) requisitos de continuidad de servicio, incluyendo los de disponibilidad y fiabilidad, de acuerdo con las prioridades
de negocio de la organización; r) las responsabilidades respectivas de las partes del acuerdo; s) las responsabilidades relativas a cuestiones legales y cómo se garantiza el cumplimiento de los requisitos legales,
por ejemplo la legislación de protección de datos, especialmente teniendo en cuenta los diferentes sistemas legales, si los acuerdos contemplan la cooperación con organizaciones de otros países (véase 15.1);
t) los derechos de propiedad intelectual (IPRs), y protección del copyright (véase 15.1.2.) y protección de cualquier
trabajo u obra colectiva (véase 6.1.5); u) la implicación del tercero con subcontratistas, y los controles de seguridad que estos subcontratistas necesitan
implantar; v) condiciones para la renegociación/terminación de los acuerdos:
1) se debería establecer un plan de contingencia en el caso de que una de las partes desee terminar la relación antes de la finalización del acuerdo;
2) la renegociación de los acuerdos si los requisitos de seguridad de la organización cambian; 3) documentación actualizada de listas de activos, licencias, acuerdos o derechos relativos a los mismos.
Información adicional Los acuerdos pueden variar considerablemente para las distintas organizaciones y entre los diferentes tipos de terceros. Por tanto se debería cuidar la inclusión en los acuerdos de todos los riesgos y requisitos de seguridad identificados (véase 6.2.1). Cuando sea necesario, los controles y procedimientos requeridos se pueden ampliar en un plan de gestión de la seguridad.
- 29 - ISO/IEC 27002:2005
Si la gestión de la seguridad de la información está externalizada, los acuerdos deberían contemplar cómo va a garantizar el tercero que la seguridad requerida, tal y como se define en la evaluación del riesgo, va a ser mantenida, y cómo se adaptará la seguridad para identificar y tratar los cambios en los riesgos. Algunas de las diferencias entre la externalización y otras formas de provisión de servicio por un tercero incluyen la cuestión de la responsabilidad, la planificación del periodo transitorio y los posibles problemas en las operaciones durante este periodo, acuerdos de planes de contingencia y las debidas revisiones de las diligencias, así como la recopilación y la gestión de los incidentes de seguridad de la información. Por consiguiente es importante que la organización planifique y gestione la transición a un acuerdo de externalización y tenga implantados los procesos adecuados para gestionar los cambios y las renegociaciones/terminaciones de los acuerdos. Es necesario considerar en el acuerdo los procedimientos a seguir en el caso que el tercero sea incapaz de suministrar sus servicios, para evitar cualquier retraso en las gestiones de la sustitución de los servicios. Los acuerdos con terceros pueden también involucrar a otras partes. Los acuerdos que conceden los accesos a terceros deberían incluir complementos para designar a otras partes con derecho así como las condiciones para su acceso y participación. Generalmente, los acuerdos son principalmente elaborados por la organización. En algunas ocasiones pueden darse circunstancias donde un acuerdo puede ser elaborado e impuesto a una organización por el tercero. La organización necesita asegurarse de que sus propia seguridad no se ve innecesariamente afectada por los requisitos del tercero estipulados en los acuerdos impuestos. 7 GESTIÓN DE ACTIVOS
7.1 Responsabilidad sobre los activos
Objetivo: Conseguir y mantener una protección adecuada de los activos de la organización. Todos los activos deberían estar registrados y tener un propietario designado para cada uno. Se deberían identificar los propietarios para todos los activos y asignar la responsabilidad del mantenimiento de los controles apropiados. La implantación de los controles específicos puede ser delegada por el propietario según éste considere, pero la responsabilidad de la protección adecuada de los activos permanece en el propietario. 7.1.1 Inventario de activos
Control Todos los activos deberían estar claramente identificados y debería elaborarse y mantenerse un inventario de todos los activos importantes. Guía de implantación Una organización debería identificar todos los activos y documentar la importancia de estos activos. El inventario de activos debería incluir toda la información necesaria para poderse recuperar ante un desastre, incluyendo el tipo de activo, el formato, la localización, la información sobre las copias de respaldo, la información sobre las licencias, y su valor para el negocio. El inventario no debería duplicar otros inventarios de manera innecesaria, pero debería asegurar que el contenido está alineado. Además, se debería acordar y documentar para cada uno de los activos, la propiedad (véase 7.1.2) y la clasificación de la información (véase 7.2). Basándose en la importancia del activo, su valor para el negocio y en la clasificación de su seguridad, se deberían identificar los niveles de protección acorde con la importancia de los activos (más información de cómo valorar los activos para representar su importancia se puede encontrar en la Norma ISO/IEC TR 13335-3).
ISO/IEC 27002:2005 - 30 -
Información adicional Hay muchos tipos de activos, incluyendo:
a) activos de información: ficheros y bases de datos, contratos y acuerdos, documentación del sistema, información de investigación, manuales de los usuarios, material de formación, procedimientos de operación o de soporte, planes de continuidad, acuerdos de recuperación, pistas de auditoría e información archivada;
b) activos de software: software de aplicaciones, software del sistema, herramientas de desarrollo y utilidades;
c) activos físicos: equipamiento informático, equipamiento de comunicaciones, medios extraíbles y otro equipamiento;
d) servicios: servicios informáticos y de comunicaciones, suministros e instalaciones generales, por ejemplo calefacción, iluminación, energía y aire acondicionado;
e) personas y sus cualificaciones, perfiles y experiencia;
f) activos intangibles, tales como la reputación e imagen de la organización. Los inventarios de activos ayudan a asegurar que se lleva a cabo su protección efectiva, pero también se requiere para otros propósitos de la organización, por razones de salud e higiene (protección laboral), por pólizas de seguros o razones financieras (valoración de activos). El proceso de recopilar el inventario de activos es un requisito previo importante de la gestión de riesgos. 7.1.2 Propiedad de los activos
Control Toda la información y activos asociados con los recursos para el tratamiento de la información deberían tener un propietario2) que forme parte de la organización y haya sido designado como propietario. Guía de implantación El propietario del activo debería ser responsable de:
a) asegurar que toda la información y los activos asociados con los recursos para el tratamiento de la información están adecuadamente clasificados;
b) definir y revisar periódicamente las restricciones de acceso y las clasificaciones, teniendo en cuenta las políticas de control de acceso aplicables.
La propiedad se podría asignar a:
a) un proceso de negocio;
b) un conjunto de actividades definido;
c) una aplicación; o
d) un conjunto de datos definido. Información adicional Las tares rutinarias pueden delegarse, por ejemplo a un encargado de velar del activo en el día a día, pero la responsabilidad permanece en el propietario. En sistemas complejos de información puede ser útil identificar grupos de activos, que actúan de manera conjunta para proporcionar una función particular como �servicios�. En este caso, el propietario del servicio es responsable de la entrega del servicio, incluyendo el funcionamiento de los activos que lo proporcionan.
2) El término "propietario" se requiere a la persona o entidad a la que se le ha asignado la responsabilidad administrativa del control de la
producción, desarrollo, mantenimiento, uso y seguridad de los activos. El término "propietario" no significa que la persona tenga realmente algún derecho de propiedad sobre el activo.
- 31 - ISO/IEC 27002:2005
7.1.3 Uso aceptable de los activos
Control Se deberían identificar, documentar e implantar las reglas para el uso aceptable de la información y de los activos asociados con los recursos para el tratamiento de la información. Guía de implantación Todos los empleados, contratistas y terceros deberían seguir las reglas de uso aceptable de la información y de los activos asociados con los recursos para el tratamiento de la información, incluyendo:
a) reglas para el uso del correo electrónico e Internet (véase 10.8);
b) directrices para el uso de dispositivos móviles, especialmente para el uso fuera de las instalaciones de la organización (véase 11.7.1).
Se deberían proporcionar las reglas o directrices específicas por parte de la Dirección que corresponde. Los empleados, contratistas y terceros que utilicen o tengan acceso a los activos de la organización deberían ser conscientes de las limitaciones existentes en el uso de la información y de los activos asociados con los recursos para el tratamiento de la información. Deberían ser responsables del uso de cualquier recurso de tratamiento de la información y de cualquier uso que se lleve a cabo bajo su responsabilidad.
7.2 Clasificación de la información
Objetivo: Asegurar que la información recibe un nivel adecuado de protección. La información debería ser clasificada para indicar la necesidad, las prioridades y el grado esperado de protección cuando se maneja dicha información. La información tiene varios grados de sensibilidad y criticidad. Algunos elementos pueden requerir un nivel de protección adicional o un manejo especial. Se debería utilizar un esquema de clasificación de la información para definir un conjunto adecuado de niveles de protección y comunicar la necesidad de medidas especiales para su manipulación. 7.2.1 Directrices de clasificación
Control La información debería ser clasificada según su valor, los requisitos legales, su sensibilidad y criticidad para la organización. Guía de implantación La clasificación de la información y los controles de protección asociados deberían tener en cuenta las necesidades del negocio en cuanto a intercambio y restricción de información, así como los impactos en el negocio asociados a tales necesidades. Las directrices para la clasificación deberían incluir indicaciones para una clasificación inicial y para una reclasificación posterior; de acuerdo con alguna de las políticas de control de acceso predeterminadas (véase 11.1.1). Debería ser responsabilidad del propietario del activo (véase 7.1.2) definir la clasificación del activo, su revisión periódica, y asegurar que se mantiene actualizada y en el nivel adecuado. La clasificación debería tener en cuenta el efecto de agregación mencionado en el apartado 10.7.2. Debería considerarse el número de categorías de clasificación y los beneficios obtenidos con su uso. Los esquemas demasiado complejos pueden ser poco prácticos al resultar molestos o costosos. Se debería cuidar la interpretación de las etiquetas de clasificación en documentos de otras organizaciones, que pueden tener definiciones distintas para niveles de clasificación que tengan un nombre igual o similar al de la organización. Información adicional El nivel de protección puede ser establecido en base a un análisis de la confidencialidad, la integridad y la disponibilidad, y cualquier otro requisito que se considere de la información.
ISO/IEC 27002:2005 - 32 -
A menudo, la información deja de ser sensible o crítica después de un cierto periodo de tiempo, por ejemplo, cuando la información se hace pública. Deberían tenerse en cuenta estos aspectos, así como el hecho de que una sobre-clasificación puede conllevar la implantación de controles innecesarios y ocasionar un gasto adicional. El considerar conjuntamente los documentos con requisitos de seguridad similares cuando se asignan los niveles de clasificación podría ser de ayuda para simplificar la tarea de la clasificación. En general, la clasificación asignada a la información es un camino adecuado para determinar cómo debe ser manejada y protegida dicha información. 7.2.2 Etiquetado y manipulado de la información
Control Se debería desarrollar e implantar un conjunto adecuado de procedimientos para etiquetar y manejar la información, de acuerdo con el esquema de clasificación adoptado por la organización. Guía de implantación Los procedimientos de marcado de la información han de cubrir los activos en formato físico y electrónico. La salida procedente de los sistemas que contienen información clasificada como sensible o crítica debería llevar una etiqueta de clasificación adecuada (en la salida). El marcado debería reflejar la clasificación de acuerdo con las reglas establecidas en el apartado 7.2.1. Los elementos a ser considerados incluyen los informes impresos, las pantallas, los medios de almacenamiento (cintas, discos, CDs), los mensajes electrónicos y las transferencias de ficheros. Para cada nivel de clasificación, deberían definirse los procedimientos de manejo incluyendo el procesamiento seguro, el almacenamiento, la transmisión, la desclasificación y la destrucción seguros. También deberían incluirse los procedimientos para la cadena de custodia y registro (logging) de cualquier evento de seguridad relevante. Los acuerdos con otras organizaciones que conlleven intercambio de información deberían incluir los procedimientos para identificar la clasificación de dicha información y para interpretar los niveles de clasificación de las otras organizaciones. Información adicional El etiquetado y el manipulado seguro de la información clasificada es un requisito clave para los compromisos de intercambio de la información. Las etiquetas físicas son una forma habitual de etiquetado. Sin embargo, algunos activos de información, tales como documentos en formato electrónico, no pueden ser etiquetados de una manera física y es necesario utilizar medios electrónicos de etiquetado. Por ejemplo, puede aparecer la notificación del etiquetado en la pantalla o en el visualizador. Dónde no sea posible el etiquetado, se pueden aplicar otros medios de designación para la clasificación de la información, por ejemplo mediante procedimientos o metadatos. 8 SEGURIDAD LIGADA A LOS RECURSOS HUMANOS
8.1 Antes del empleo3)
Objetivo: Asegurar que los empleados, los contratistas y los terceros conocen y comprenden sus responsabilidades, y son adecuados para llevar a cabo las funciones que les corresponden, así como para reducir el riesgo de robo, fraude o de uso indebido de los recursos. Deberían asignarse las responsabilidades sobre seguridad previamente a la contratación y quedar reflejadas en una descripción adecuada del trabajo y de los términos y condiciones de la contratación.
3) Explicación: La palabra "contratación" se utiliza en este documento para cubrir todas las diferentes situaciones siguientes: contratación de
personal (temporal o de larga duración), nombramiento de funciones de puesto de trabajo, cambio de puesto de trabajo, asignación de contratistas, y terminación de cualquiera de los acuerdos o compromisos.
- 33 - ISO/IEC 27002:2005
Todos los candidatos para un puesto de trabajo, los contratistas y terceros deberían ser adecuadamente investigados, especialmente para trabajos sensibles. Los empleados, contratistas y terceros que tengan relación directa con los recursos de tratamiento de la información deberían firmar un compromiso relativo a sus funciones y responsabilidades en lo que a seguridad se refiere. 8.1.1 Funciones y responsabilidades
Control Las funciones y responsabilidades de seguridad de los empleados, contratistas y terceros se deberían definir y documentar de acuerdo con la política de seguridad de la información de la organización. Guía de implantación Las funciones y responsabilidades de seguridad deberían incluir requisitos para: a) implantar las políticas de seguridad de la información de la organización y actuar de acuerdo a ellas (véase 5.1); b) proteger a los activos de accesos no autorizados, revelación, modificación, destrucción o interferencia; c) ejecutar procesos o actividades específicos de seguridad; d) garantizar que la responsabilidad por las acciones realizadas es asignada a individuos; e) informar de eventos o posibles eventos de seguridad u otros riesgos de seguridad para la organización. Las funciones y responsabilidades de seguridad deberían ser definidas y comunicadas de una forma clara a los candidatos al puesto de trabajo durante el proceso de selección del candidato. Información adicional Las descripciones de un puesto de trabajo pueden ser utilizadas para documentar las funciones y responsabilidades de seguridad. Las funciones y responsabilidades de seguridad para individuos no contratados a través del proceso de contratación de la organización, por ejemplo contratados por un tercero, deberían estar claramente definidas y haber sido comunicadas. 8.1.2 Investigación de antecedentes
Control La comprobación de los antecedentes de todos los candidatos a un puesto de trabajo, de los contratistas o de los terceros, se debería llevar a cabo de acuerdo con las legislaciones, normativas y códigos éticos que sean de aplicación y de una manera proporcionada a los requisitos del negocio, la clasificación de la información a la que se accede y a los riesgos considerados. Guía de implantación Las comprobaciones deberían tener en cuenta la legislación relativa a privacidad, protección de datos personales y/o contratación, y deberían, cuando esté permitido, incluir lo siguiente: a) la disponibilidad de referencias satisfactorias, por ejemplo, una de tipo personal y otra profesional; b) la comprobación (de la completitud y precisión) del curriculum vitae del candidato; c) la confirmación de las cualificaciones académicas y profesionales alegadas; d) una comprobación independiente de la identificación (con el DNI, pasaporte o documento similar); e) otras comprobaciones de detalle, tales como comprobaciones crediticias y de antecedentes criminales.
ISO/IEC 27002:2005 - 34 -
Cuando un puesto de trabajo, un nombramiento inicial o una promoción, involucre a una persona que tenga acceso a los recursos de tratamiento de la información, y en particular si se trata del manejo de información sensible, por ejemplo información financiera o información altamente confidencial, la organización debería considerar el realizar además otras comprobaciones de detalle. Los procedimientos deberían definir los criterios y limitaciones de las comprobaciones, por ejemplo quién es candidato a una investigación de sus antecedentes, y cómo, cuándo y porqué se llevan a cabo las comprobaciones. Debería llevarse a cabo un proceso de investigación de antecedentes de los contratistas y de los terceros. Cuando los contratistas son proporcionados a través de una agencia, el contrato con la agencia debería especificar de una manera clara las responsabilidades de la agencia en cuanto a investigación de antecedentes así como los procedimientos de notificación que es necesario seguir si la investigación no ha sido completada o si los resultados originan duda o inquietud. De igual manera el contrato con un tercero (véase 6.2.3) debería especificar de una manera clara todas las responsabilidades y la notificación de los procedimientos relativos a la investigación de los antecedentes. La información de todos los candidatos que están siendo considerados para ocupar puestos dentro de la organización debería ser recopilada y tratada de acuerdo con la legislación aplicable existente en la jurisdicción correspondiente. Dependiendo de la legislación aplicable, los candidatos deberían ser informados con antelación sobre las actividades de investigación. 8.1.3 Términos y condiciones de contratación
Control Como parte de sus obligaciones contractuales, los empleados, los contratistas y los terceros deberían aceptar y firmar los términos y condiciones de su contrato de trabajo, que debería establecer sus responsabilidades y las de la organización en lo relativo a seguridad de la información. Guía de implantación Los términos y condiciones del contrato de trabajo deberían reflejar la política de seguridad de la organización, además de establecer y clarificar lo siguiente: a) que los empleados, contratistas y terceros que tengan acceso a información sensible, deberían firmar un compromiso de
confidencialidad y no revelación previamente a que se les de el acceso a los recursos de tratamiento de la información; b) las responsabilidades y los derechos de los empleados, contratistas y terceros, por ejemplo la legislación relativa a
derechos de propiedad intelectual o legislación de protección de datos (véanse 15.1.1 y 15.1.2); c) las responsabilidades para la clasificación de la información y la gestión de los activos asociados con los sistemas y
servicios de información manejados por el empleado, contratista o tercero (véanse 7.2.1 y 10.7.3); d) las responsabilidades del empleado, contratista y tercero, relativas al manejo de la información recibida de otras
compañías o de partes externas; e) las responsabilidades de la organización para el manejo de la información personal, incluida la información personal
creada como resultado de, o durante el transcurso, de una contratación por parte de la organización (véase 15.1.4); f) las responsabilidades que se extienden fuera de las instalaciones de la organización y fuera del horario habitual de
trabajo, por ejemplo en el caso de trabajo en casa (véanse 9.2.5 y 11.7.1); g) las acciones a tomar en caso de hacer caso omiso de los requisitos de seguridad de la organización por parte del
empleado, contratista o tercero (véase 8.2.3). La organización debería asegurar que los empleados, contratistas o terceros aceptan los términos y condiciones concernientes a la seguridad de la información que serán adecuadas a la naturaleza y extensión del acceso que ellos tendrán a los activos de información asociados con los sistemas y servicios de información.
- 35 - ISO/IEC 27002:2005
Cuando sea apropiado, las responsabilidades contenidas en los términos y condiciones del puesto de trabajo debería continuar durante un periodo de tiempo definido después de la finalización de la contratación (véase 8.3). Información adicional Se puede utilizar un código de conducta para cubrir las responsabilidades del empleado, contratista o tercero, relativas a la confidencialidad, protección de datos, ética, uso adecuado de los equipos y recursos de la organización, así como las prácticas profesionales que se esperan por la organización. El contratista o el tercero pueden estar vinculados con una organización externa que puede a su vez, requerir el establecer compromisos contractuales en nombre del individuo contratado.
8.2 Durante el empleo
Objetivo: Asegurar que todos los empleados, contratistas y terceros son conscientes de las amenazas y problemas que afectan a la seguridad de la información y de sus responsabilidades y obligaciones, y de que están preparados para cumplir la política de seguridad de la organización, en el desarrollo habitual de su trabajo, y para reducir el riesgo de error humano. Las responsabilidades de la Dirección deberían estar definidas para asegurar que la seguridad se aplica a la contratación de personas dentro de la organización. Se debería proporcionar a todos los empleados, contratistas y terceros, un nivel adecuado de concienciación, formación y capacitación en los procedimientos de seguridad así como en el uso correcto de los recursos de tratamiento de la información, para minimizar los posibles riesgos de seguridad. Se debería establecer un proceso disciplinario de manera formal. 8.2.1 Responsabilidades de la Dirección
Control La Dirección debería exigir a los empleados, contratistas y terceros, que apliquen la seguridad de acuerdo con las políticas y procedimientos establecidos en la organización. Guía de implantación La gestión de las responsabilidades debería incluir las siguientes garantías por parte de los empleados, contratistas y terceros: a) están debidamente informados sobre sus roles y responsabilidades relativas a seguridad de la información
previamente a serles concedido el acceso a información sensible o a los sistemas de información; b) se les proporcionan directrices para establecer las expectativas en cuanto a seguridad en lo relativo a su función
dentro de la organización; c) están motivados para cumplir las políticas de seguridad de la organización; d) alcanzan un nivel de concienciación en seguridad adecuado a sus funciones y responsabilidades dentro de la
organización (véase 8.2.2); e) aceptan los términos y condiciones de su contratación, lo que incluye la política de seguridad de la información de la
organización y los métodos de trabajo apropiados; f) continúan teniendo el perfil profesional y las cualificaciones apropiados. Información adicional Si los empleados, contratistas y terceros, no son conscientes de sus responsabilidades en cuanto a seguridad, podrían causar un daño considerable a la organización. El personal motivado es probablemente más fiable y causa menos incidentes de seguridad de la información.
ISO/IEC 27002:2005 - 36 -
Una gestión deficiente puede provocar que el personal se sienta infravalorado lo que tendría como resultado un impacto negativo en la seguridad de la organización. Por ejemplo, una gestión deficiente puede provocar descuidos en la seguridad o un posible mal uso de los activos de la organización. 8.2.2 Concienciación, formación y capacitación en seguridad de la información
Control Todos los empleados de la organización y, cuando corresponda, los contratistas y terceros, deberían recibir una adecuada concienciación y formación, con actualizaciones periódicas, sobre las políticas y procedimientos de la organización, según corresponda con su puesto de trabajo. Guía de implantación La concienciación y la formación deberían comenzar con un proceso formal de acogida diseñado a modo de introducción de las políticas y expectativas de la organización en cuanto a seguridad, antes de conceder el acceso a la información o a los servicios. La formación debería incluir requisitos de seguridad, responsabilidades legales y controles orientados al negocio, así como formación en el uso correcto de los recursos de tratamiento de la información, por ejemplo, el procedimiento de registro en el sistema informático (log-on), el uso de paquetes de software así como información sobre el proceso disciplinario (véase 8.2.3). Información adicional Las actividades de concienciación, formación y capacitación en seguridad deberían ser adecuadas y corresponderse con la función de cada persona, sus responsabilidades y su perfil profesional, y deberían incluir información sobre amenazas conocidas, así como con quién contactar para asesoramiento adicional sobre seguridad y sobre los canales adecuados para informar sobre los incidentes en seguridad de la información (véase 13.1). La formación para mejorar la concienciación está dirigida a hacer posible que los individuos puedan reconocer los problemas e incidentes de seguridad de la información, y responder de acuerdo a las necesidades de su puesto de trabajo. 8.2.3 Proceso disciplinario
Control Debería existir un proceso disciplinario formal para los empleados que hayan provocado alguna violación de la seguridad. Guía de implantación El proceso disciplinario no debería comenzar sin una previa verificación de que se ha producido una violación de la seguridad (véase también 13.2.3 para recopilación de evidencias). El proceso disciplinario formal debería asegurar un tratamiento correcto e imparcial para los empleados de los que se sospeche hayan cometido alguna violación de la seguridad. El proceso disciplinario formal debería proporcionar una respuesta graduada que tenga en cuenta factores tales como la naturaleza y gravedad de la violación de la seguridad y su impacto en el negocio, si es la primera vez o se trata de una infracción repetida, si el causante fue adecuadamente formado en la legislación aplicable, los compromisos del negocio u otros factores según se requiera, o no lo fue. En casos serios de conducta inadecuada, el proceso debería permitir una retirada instantánea de tareas, de derechos de acceso y privilegios, así como una escolta inmediata hasta salir fuera de las instalaciones de la organización, si fuese necesario. Información adicional El proceso disciplinario debería ser también utilizado como un procedimiento disuasorio para prevenir que los empleados, contratistas y terceros cometan violaciones de las políticas y procedimientos de seguridad de la organización, o cualquier otra infracción de la seguridad.
- 37 - ISO/IEC 27002:2005
8.3 Cese del empleo o cambio de puesto de trabajo
Objetivo: Asegurar que los empleados, contratistas y terceros abandonan la organización o cambian de puesto de trabajo de una manera ordenada. Las responsabilidades deberían asignarse de modo que aseguren que la salida del empleado, contratista o tercero sea gestionada, y que se completa tanto la devolución de todo el equipamiento, como la retirada de todos los derechos de acceso. Los cambios en las responsabilidades y en el puesto de trabajo dentro de una organización deberían gestionarse de igual manera que la finalización de la responsabilidad o del contrato correspondiente en línea con lo establecido en este apartado, y cualquier nueva contratación debería gestionarse según se describe en el apartado 8.1. 8.3.1 Responsabilidad del cese o cambio
Control Las responsabilidades para proceder al cese en el empleo o al cambio de puesto de trabajo deberían estar claramente definidas y asignadas. Guía de implantación La comunicación de la finalización de las responsabilidades debería incluir los requisitos de seguridad y las responsabilidades legales en curso, y dónde sea apropiado, las responsabilidades que conlleven algún acuerdo de confidencialidad (véase 6.1.5), así como los términos y condiciones del empleo (véase 8.1.3) que continúen durante un periodo definido después de la finalización del contrato del empleado, contratista y tercero. Las responsabilidades y funciones que son válidas después de la finalización del empleo deberían estar contenidas en los contratos de los empleados, contratistas y terceros. Los cambios de responsabilidad o de puesto de trabajo deberían ser gestionados de igual manera que la finalización de la responsabilidad o del empleo correspondiente, y la nueva responsabilidad o nuevo puesto de trabajo debería ser controlada como se describe en el apartado 8.1. Información adicional El departamento de Recursos Humanos generalmente es responsable del proceso completo de finalización y trabaja conjuntamente con el supervisor de la persona que deja su puesto para gestionar los aspectos de seguridad de los respectivos procedimientos. En el caso de un contratista, este proceso de terminación de la responsabilidad puede ser llevado a cabo por una agencia responsable del contrato, y en caso de terceros, esto puede ser manejado por sus organizaciones. Puede ser necesario el informar a los empleados, clientes, contratistas o terceros, de los cambios del personal y los acuerdos de funcionamiento. 8.3.2 Devolución de activos
Control Todos los empleados, contratistas y terceros deberían devolver todos activos de la organización que estén en su poder al finalizar su empleo, contrato o acuerdo. Guía de implantación El proceso de finalización debería formalizarse para incluir la devolución de todos los componentes de software, documentos corporativos y equipos. También es necesario devolver otros activos de la organización, tales como ordenadores portátiles, tarjetas de crédito, tarjetas de acceso, software, manuales así como la información almacenada en soporte electrónico. En los casos dónde un empleado, contratista o tercero adquiera equipos de la organización o también en el caso de que utilice su equipo personal, se deberían seguir los procedimientos que aseguren que toda la información importante es transferida a la organización y eliminada de una forma segura de los equipos (véase 10.7.1).
ISO/IEC 27002:2005 - 38 -
En los casos dónde un empleado, contratista o tercero tenga conocimiento de que están puestas en marcha operaciones importantes, esta información debería ser documentada y transferida a la organización. 8.3.3 Retirada de los derechos de acceso
Control Los derechos de acceso a la información y a los recursos de tratamiento de la información de todos los empleados, contratistas y terceros deberían ser retirados a la finalización del empleo, del contrato o del acuerdo, o bien deberían ser adaptados a los cambios producidos. Guía de implantación A la finalización, los derechos de acceso de un individuo a los activos asociados con los sistemas y servicios de información deberían ser reconsiderados. Esto determinará si es necesario retirar dichos derechos de acceso. Los cambios en un puesto de trabajo deberían dar lugar a la retirada de todos los derechos de acceso que no hayan sido aprobados para el nuevo puesto. Los derechos de acceso que deberían ser retirados o adaptados incluyen accesos físicos y lógicos, claves, tarjetas de identificación, recursos de tratamiento de la información (véase 11.2.4), suscripciones, así como la retirada de cualquier documentación que les identifique como un miembro actual de la organización. Si un empleado, contratista o tercero que se marcha de la organización, ha tenido conocimiento de las contraseñas para cuentas que continúan en activo, estas deberían ser cambiadas a la finalización o cambio del puesto de trabajo, contrato o acuerdo. Los derechos de acceso a los activos de información y a los recursos de tratamiento de la información, deberían ser reducidos o retirados antes de la finalización o cambio de la contratación, dependiendo de la evaluación de factores de riesgo tales como: a) si la finalización o cambio es a iniciativa del empleado, contratista o tercero, o por iniciativa de la Dirección, así
como la razón de la finalización; b) las actuales responsabilidades del empleado, contratista o cualquier otro usuario; c) el valor de los activos a los que actualmente tiene acceso. Información adicional En ciertas circunstancias los derechos de acceso pueden ser reasignados para poder estar disponibles para otras personas además del empleado, contratista o tercero que se marcha, por ejemplo identificadores de usuario (IDs) de grupo. En tales circunstancias, los individuos salientes deberían ser eliminados de todas las listas de grupos de acceso y deberían establecerse acuerdos para asesorar al resto de empleados, contratistas y terceros que no van a seguir implicados en la compartición de información con la persona saliente. En los casos en que la terminación haya sido a iniciativa de la Dirección, los empleados, contratistas o terceros descontentos podrían corromper la información de una manera deliberada o sabotear los recursos de tratamiento de la información. En los casos de personas que hayan presentado su dimisión, podrían haber recopilado información para su uso en el futuro. 9 SEGURIDAD FÍSICA Y DEL ENTORNO
9.1 Áreas seguras
Objetivo: Prevenir los accesos físicos no autorizados, los daños y las intromisiones en las instalaciones y en la información de la organización. Los recursos de tratamiento de la información crítica y sensible deberían estar situados en áreas seguras y protegidos por perímetros de seguridad definidos mediante barreras de seguridad y controles de entrada adecuados. Deberían estar físicamente protegidos de accesos no autorizados, de daños y de interferencias. La protección proporcionada debería ser proporcional a los riesgos identificados.
- 39 - ISO/IEC 27002:2005
9.1.1 Perímetro de seguridad física
Control Se deberían utilizar perímetros de seguridad (barreras, muros, puertas de entrada con control de acceso a través de tarjeta, o puestos de control) para proteger las áreas que contienen la información y los recursos de tratamiento de la información. Guía de implantación Se deberían considerar e implantar, cuando sea adecuado, las siguientes directrices para los perímetros de seguridad física: a) los perímetros de seguridad deberían estar claramente definidos, y la situación y fortaleza de cada perímetro debería
depender de los requisitos de seguridad de los activos dentro del perímetro y de los resultados de la evaluación de los riesgos;
b) los perímetros de un edificio o instalación que contiene los recursos de tratamiento de la información deberían ser
físicamente sólidos (por ejemplo: no deberían existir huecos en el perímetro o áreas dónde pudieran producirse rupturas fácilmente); los muros externos del lugar deberían ser de construcción sólida y todas las puertas externas deberían estar adecuadamente protegidas contra los accesos no autorizados a través de mecanismos de control, por ejemplo barras, alarmas, cerraduras etc; las puertas y ventanas deberían estar bloqueadas cuando no estén atendidas y se debería considerar una protección externa para las ventanas, en especial para las que se encuentran a nivel del suelo;
c) deberían situarse un área de recepción u otros controles de acceso físico a las instalaciones o al edificio; se deberían
restringir los accesos a las instalaciones y al edificio únicamente al personal autorizado; d) las barreras físicas deberían, cuando sea aplicable, ser construidas para prevenir los accesos físicos no autorizados y
la contaminación del entorno; e) todas las puertas del perímetro de seguridad que actúen como cortafuegos deberían estar dotadas de un sistema de
alarma, monitorizadas y probadas conjuntamente con las paredes, para establecer el nivel requerido de resistencia de acuerdo a las normas regionales, nacionales e internacionales; se debería operar de acuerdo a los códigos locales de protección contra incendios en un modo seguro;
f) se deberían instalar sistemas de detección de intrusión adecuados conforme a las normas regionales, nacionales e
internacionales y ser probados periódicamente para dar cobertura a todas las puertas externas y ventanas accesibles; las áreas no ocupadas deberían estar dotadas de un sistema de alarma en todo momento; se deberían también cubrir otras áreas por ejemplo la sala de ordenadores o las salas de comunicaciones;
g) los recursos de tratamiento de la información gestionados por la organización deberían estar físicamente separados
de aquellos gestionados por terceras partes. Información adicional La protección física puede alcanzarse a través de la creación de una o más barreras físicas alrededor de las instalaciones de la organización y de los recursos de tratamiento de la información. El uso de barreras múltiples proporciona protección adicional, de manera que el fallo de una barrera en particular no significa que se comprometa inmediatamente la seguridad. Un área segura puede ser una oficina que se pueda cerrar con llave o varias salas rodeadas por una barrera interna y continua de seguridad física. Pueden ser necesarias barreras adicionales y perímetros de control de acceso físico entre áreas dentro del perímetro de seguridad que tengan diferentes requisitos de seguridad. Se deberían proporcionar consideraciones especiales relativas a la seguridad de los accesos físicos, para edificios que albergan a diferentes organizaciones.
ISO/IEC 27002:2005 - 40 -
9.1.2 Controles físicos de entrada
Control Las áreas seguras deberían estar protegidas por controles de entrada adecuados, para asegurar que únicamente se permite el acceso al personal autorizado. Guía de implantación Deberían considerarse las siguientes directrices: a) se debería registrar la fecha y la hora de entrada y salida de los visitantes, y todos los visitantes deberían ser
supervisados a menos que su acceso haya sido previamente aprobado; únicamente se debería conceder el acceso para propósitos específicos y autorizados, y junto con el acceso se deberían proporcionar las instrucciones de los requisitos de seguridad del área y los procedimientos de emergencia;
b) el acceso a las áreas dónde se procesa o se almacena información sensible debería estar controlado y restringido
únicamente a personal autorizado; se deberían utilizar controles de autenticación para autorizar y validar todos los accesos, por ejemplo tarjetas de control de acceso con número de identificación personal (PIN); deberían mantenerse de una manera segura registros de auditoría de todos los accesos;
c) debería requerirse a todos los empleados, contratistas y terceros y a todos los visitantes, el llevar una identificación
visible y debería notificarse inmediatamente al personal de seguridad si se encuentran visitantes sin acompañamiento o alguna persona sin llevar visible la identificación;
d) para el personal proveniente del tercero que presta servicios de apoyo se debería proporcionar acceso restringido a
las áreas seguras o a los recursos de tratamiento de la información únicamente cuando sea requerido; este acceso debería estar autorizado y controlado;
e) los derechos de acceso a las áreas seguras deberían ser revisados y actualizados regularmente, y revocados cuando
sea necesario (véase 8.3.3). 9.1.3 Seguridad de oficinas, despachos e instalaciones
Control Se deberían diseñar y aplicar las medidas de seguridad física para las oficinas, despachos e instalaciones. Guía de implantación Deberían aplicarse las siguientes directrices para asegurar las oficinas, los despachos y los recursos. a) se debería tener en cuenta la legislación y las normas relativas a salud y seguridad; b) se deberían situar los recursos clave de manera que se evite el acceso por el público en general; c) dónde sea aplicable, los edificios deberían proporcionar de una manera discreta una mínima indicación de su
función, con señales no obvias, que identifiquen la existencia de actividades de tratamiento de la información, ya sea fuera o dentro del edificio;
d) los directorios y las guías telefónicas internas que identifiquen los emplazamientos de los recursos de tratamiento de
la información sensible, no deberían ser de fácil acceso a la lectura por el público en general. 9.1.4 Protección contra las amenazas externas y de origen ambiental
Control Se debería diseñar y aplicar una protección física contra el daño causado por fuego, inundación, terremoto, explosión, revueltas sociales y otras formas de desastres naturales o provocados por el hombre.
- 41 - ISO/IEC 27002:2005
Guía de implantación Se deberían aportar consideraciones para cualquier amenaza de seguridad proveniente de locales vecinos, por ejemplo por fuego en edificios colindantes, fugas de agua en el techo o en plantas bajo el nivel del suelo o explosiones en la calle. Se deberían considerar las siguientes directrices para evitar el daño por fuego, inundación, terremoto, explosión, revueltas sociales y otras formas de desastres naturales o provocados por el hombre: a) los materiales peligrosos o inflamables deberían almacenarse a una distancia de seguridad con respecto a las áreas
seguras. No se almacenarán dentro de un área segura los suministros a granel -como material de escritorio- hasta que se necesiten;
b) el equipamiento y los soportes de respaldo deberían estar a una distancia de seguridad conveniente para evitar que se
dañen por un desastre en el emplazamiento principal; c) se debería disponer del equipamiento contra incendios apropiado y estar situado en los lugares adecuados. 9.1.5 Trabajo en áreas seguras
Control Se deberían diseñar e implantar una protección física y una serie de directrices para trabajar en las áreas seguras. Guía de implantación Deberían considerarse las siguientes directrices: a) el personal debería conocer la existencia de un área segura, o de sus actividades, únicamente en el caso de que sea
necesario para su trabajo; b) se debería evitar el trabajo no supervisado en áreas seguras tanto por motivos de seguridad como para evitar
oportunidades de actividades maliciosas; c) las áreas seguras deberían estar físicamente cerradas y ser comprobadas periódicamente; d) no se deberían permitir equipos de fotografía, video, audio u otros equipos de grabación, salvo autorización especial; Las disposiciones para trabajar en áreas seguras incluyen los controles para los empleados, contratistas y terceros que trabajan en el área segura, así como para otras actividades de terceros que tengan lugar allí. 9.1.6 Áreas de acceso público y de carga y descarga
Control Deberían controlarse los puntos de acceso tales como las áreas de carga y descarga y otros puntos, a través de los que personal no autorizado pueda acceder a las instalaciones, y si es posible, dichos puntos se deberían aislar de las instalaciones de tratamiento de la información para evitar accesos no autorizados. Guía de implantación Se deberían considerar las siguientes directrices: a) se deberían restringir los accesos al área de carga y descarga desde el exterior sólo para el personal autorizado e
identificado; b) el área de carga y descarga se debería diseñar de tal manera que los suministros puedan descargarse sin que el
personal de descarga tenga que acceder a otras zonas del edificio; c) la puertas externas de un área de carga y descara deberían estar cerradas cuando las puertas internas estén abiertas;
ISO/IEC 27002:2005 - 42 -
d) el material entrante debería ser inspeccionado para evitar amenazas potenciales [véase 9.2.1 d)] antes de trasladarlo desde el área de carga y descarga hasta su lugar de utilización;
e) el material entrante debería registrarse de acuerdo a los procedimientos de gestión de activos (véase 7.1.1) al entrar
en la instalación; f) cuando sea posible, se debería separar físicamente la entrada y la salida de envíos.
9.2 Seguridad de los equipos
Objetivo: Evitar pérdidas, daños, robos o circunstancias que pongan en peligro los activos, o que puedan provocar la interrupción de las actividades de la organización. Los equipos deberían estar protegidos de las amenazas físicas y del entorno. La protección de los equipos (incluidos el que se utiliza fuera de la oficina y la extracción de pertenencias) es necesaria para reducir el riesgo de acceso no autorizado a la información y para protegerlo contra la pérdida o robo. Esto también debería tenerse en cuenta para la instalación y retirada del equipamiento. Pueden requerirse controles especiales para proteger contra amenazas físicas y para salvaguardar las instalaciones de apoyo tales como el suministro eléctrico y la infraestructura del cableado. 9.2.1 Emplazamiento y protección de equipos
Control Los equipos deberían situarse o protegerse de forma que se reduzcan los riesgos derivados de las amenazas y peligros de origen ambiental así como las ocasiones de que se produzcan accesos no autorizados. Guía de implantación Se deberían considerar las siguientes directrices para proteger los equipos: a) los equipos deberían situarse de tal manera que se minimicen los accesos innecesarios a las áreas de trabajo. b) los equipos de tratamiento y almacenamiento de información que manejen datos sensibles se deberían instalar donde
se reduzca el riesgo de que la información sea vista durante su uso por personas no autorizadas, y las instalaciones de almacenamiento deberían asegurarse para evitar los accesos no autorizados;
c) los elementos que requieran protección especial se deberían aislar para reducir el nivel de protección general requerido; d) se deberían adoptar controles para minimizar el riesgo de posibles amenazas físicas como por ejemplo, robo, fuego,
explosivos, humo, agua (o fallo de suministro de agua), polvo, vibración, agentes químicos, interferencias en el suministro eléctrico, interferencias en las comunicaciones, radiaciones electromagnéticas y vandalismo;
e) deberían establecerse directrices para comer, beber y fumar en las proximidades de las instalaciones de tratamiento
de información; f) se deberían controlar las condiciones ambientales, tales como la temperatura y la humedad, que puedan afectar
negativamente al funcionamiento de los equipos de tratamiento de información; g) se deberían aplicar sistemas de protección contra rayos en todos los edificios y colocar filtros de protección contra
rayos en todas las entradas de corriente eléctrica y en todas las líneas de comunicación; h) se debería considerar el uso de métodos de protección especial, por ejemplo cubiertas para teclados, en el caso de los
equipos situados en entornos industriales; i) se deberían proteger los equipos que procesen la información sensible para minimizar el riesgo de fugas de
información debidas a una emanación.
- 43 - ISO/IEC 27002:2005
9.2.2 Instalaciones de suministro
Control Los equipos deberían estar protegidos contra fallos de alimentación y otras anomalías causadas por fallos en las instalaciones de suministro. Guía de implantación Todas las instalaciones de suministro, como electricidad, agua, aguas residuales, calefacción/ventilación y aire acondicionado, deberían ser adecuadas a los equipos a los que tienen que dar soporte. Dichas instalaciones deberían ser revisadas regularmente y mediante los ensayos apropiados que aseguren su correcto funcionamiento, así como para reducir el riesgo provocado por funcionamiento incorrecto o fallo. Se debería disponer de una fuente de alimentación de electricidad que sea conforme a las especificaciones del fabricante de los equipos. Se debería instalar un Sistema de Alimentación Ininterrumpida (SAI) para dar soporte a un apagado ordenado o al funcionamiento continuo de los equipos que soporten operaciones críticas de la organización. Las acciones a adoptar en caso de fallo del SAI deberían ser cubiertas mediante planes de contingencia. Si el tratamiento de la información tiene que continuar en caso de un fallo prolongado en el suministro de energía eléctrica, se debería instalar un generador de respaldo. Se debería disponer de una reserva suficiente de combustible para asegurar el funcionamiento del generador durante un periodo prolongado. Los equipos del SAI y los generadores se deberían revisar regularmente para asegurar que tienen la capacidad adecuada y que están probados de acuerdo con las recomendaciones del fabricante. Adicionalmente se debería considerar la utilización de fuentes múltiples de alimentación, o si el lugar es grande, de una subestación de alimentación independiente. Se deberían instalar desconectadores de emergencia cerca de las salidas de emergencia de las salas donde están los equipos para facilitar una desconexión rápida en caso de emergencia. Se debería disponer de un alumbrado de emergencia por si falla la fuente principal de alimentación de energía. El suministro de agua debería ser estable y adecuado a la alimentación de los equipos de aire acondicionado, humidificación y sistemas de extinción de incendios (donde sean utilizados). Un mal funcionamiento en el sistema de suministro de agua podría dañar los equipos o producir una falta de eficacia en los equipos de extinción de incendios. Se debería evaluar e instalar, si así se requiere, un sistema de alarma para detectar el mal funcionamiento en las instalaciones de suministro. Los equipos de telecomunicaciones deberían estar conectados al proveedor de servicios a través de, al menos, dos rutas diferentes, para prevenir que el fallo en una de las conexiones provoque la falta de disponibilidad de los servicios de voz. Los servicios de voz deberían ser adecuados para cumplir con los requisitos legales locales para comunicaciones de emergencia. Información adicional Otras opciones para conseguir la continuidad de los sistemas de suministro de energía incluyen el disponer, de múltiples puntos de alimentación, para evitar un único punto de fallo en el suministro de energía. 9.2.3 Seguridad del cableado
Control El cableado eléctrico y de telecomunicaciones que transmite datos o que da soporte a los servicios de información debería estar protegido frente a interceptaciones o daños. Guía de implantación Se deberían considerar las siguientes directrices para la seguridad del cableado: a) las líneas de energía y telecomunicaciones en las zonas de tratamiento de información, deberían ser soterradas,
cuando sea posible, o adoptarse medidas alternativas de protección;
ISO/IEC 27002:2005 - 44 -
b) el cableado de la red debería protegerse contra interceptaciones no autorizadas o daños, por ejemplo, usando una conducción y evitando rutas a través de áreas públicas;
c) se deberían separar los cables de energía de los de comunicaciones para evitar interferencias; d) se debería utilizar un marcado claro de identificación de los equipos y de los cables para minimizar los errores en su
manejo, tales como el parcheo accidental de cables de red erróneos; e) se debería utilizar una lista documentada de parcheo para reducir la posibilidad de errores; f) se deberían considerar medidas adicionales para sistemas sensibles o críticos, como:
1) instalación de conductos blindados y cajas o salas cerradas en los puntos de inspección y terminación; 2) uso de rutas o de medios de transmisión alternativos que proporcionen un nivel de seguridad adecuado; 3) uso de cableado de fibra óptica; 4) uso de apantallamiento electromagnético para proteger los cables; 5) implantación de barreras técnicas e inspecciones físicas para detectar la conexión al cableado de dispositivos no
autorizados; 6) accesos controlados a los paneles de parcheo y a las salas de cableado.
9.2.4 Mantenimiento de los equipos
Control Los equipos deberían recibir un mantenimiento correcto que asegure su disponibilidad y su integridad. Guía de implantación Se deberían considerar las siguientes directrices para el mantenimiento de los equipos: a) los equipos se deberían mantener 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 la reparación y el servicio de los equipos; c) se deberían mantener registros de todos las fallos, reales o sospechados, así como de todo el mantenimiento
preventivo y correctivo; d) se deberían adoptar los controles adecuados cuando se programen los equipos para su mantenimiento, teniendo en
cuenta si el mantenimiento se lleva a cabo por personal propio o externo a la organización; cuando sea necesario, la información sensible debería ser borrada del equipo;
e) se debería cumplir con todos los requisitos que exijan las pólizas de seguros. 9.2.5 Seguridad de los equipos fuera de las instalaciones
Control Teniendo en cuenta los diferentes riesgos que conlleva trabajar fuera de las instalaciones de la organización, deberían aplicarse medidas de seguridad a los equipos situados fuera de dichas instalaciones. Guía de implantación La Dirección debería autorizar el uso fuera de los locales de la organización de cualquier equipo para tratamiento de la información, sea quien sea su propietario.
- 45 - ISO/IEC 27002:2005
Se deberían considerar las siguientes directrices para la protección de los equipos fuera de los locales de la organización: a) los equipos y soportes de datos sacados de las instalaciones no se deberían dejar desatendidos en lugares públicos.
Cuando viajen, los ordenadores portátiles se deberían transportar en una bolsa de mano de manera que no llamen la atención;
b) se deberían respetar en todo momento las instrucciones del fabricante relativas a la protección de los equipos, por
ejemplo la protección contra exposiciones a campos electromagnéticos intensos); c) se deberían determinar los controles para el trabajo en el domicilio personal, mediante una evaluación del riesgo y
cuando corresponda, aplicarse los controles convenientes, por ejemplo, archivadores que se puedan cerrar, una política de puesto de trabajo despejado, controles de acceso a los ordenadores y comunicación segura con la oficina (véase también la Norma ISO/IEC 18028 Seguridad de la red);
d) se deberían cubrir con un seguro adecuado los equipos fuera del lugar de trabajo. Los riesgos de seguridad, por ejemplo, de daño, robo y escucha, pueden variar considerablemente según la ubicación y deberían tenerse en cuenta al determinar los controles que sean más adecuados. Información adicional Los equipos de tratamiento y de almacenamiento de la información comprenden todo tipo de ordenadores personales, organizadores, teléfonos móviles, tarjetas inteligentes, documentos en formato papel o en otros formatos, que se lleven al domicilio personal o fuera del lugar habitual de trabajo. Más información sobre otros aspectos de protección de los equipos móviles puede encontrarse en el apartado 11.7.1. 9.2.6 Reutilización o retirada segura de equipos
Control Todos los soportes de almacenamiento deberían ser comprobados para confirmar que todo dato sensible y todas las licencias de software se han eliminado o bien se han borrado o sobreescrito de manera segura, antes de su retirada. Guía de implantación Los dispositivos que contengan información sensible deberían ser destruidos físicamente o bien la información debería ser destruida, borrada o sobrescrita mediante técnicas que hagan imposible la recuperación de la información original, en lugar de utilizar un borrado o un formateado normal. Información adicional Los dispositivos de almacenamiento dañados que contengan datos sensibles pueden requerir una evaluación del riesgo para determinar si deberían ser destruidos físicamente en lugar de repararse o eliminarse. La información puede verse comprometida a través de la eliminación o reutilización no cuidadosa de los equipos (véase 10.7.2). 9.2.7 Retirada de materiales propiedad de la empresa
Control Los equipos, la información o el software no deberían sacarse de las instalaciones, sin una autorización previa. Guía de implantación Se deberían considerar las siguientes directrices: a) los equipos, la información o el software no deberían sacarse fuera de las instalaciones sin previa autorización; b) los empleados, contratistas y usuarios de tercera parte que tienen permiso para sacar los activos fuera de las
instalaciones, deberían estar claramente identificados;
ISO/IEC 27002:2005 - 46 -
c) se deberían establecer limitaciones al tiempo que el equipo puede estar fuera de las instalaciones y comprobar su retorno para verificar que se cumple;
d) dónde sea necesario y adecuado, se debería registrar la salida de equipos cómo sacados fuera de los locales de la
organización, así como su retorno. Información adicional También se pueden realizar inspecciones al azar llevadas a cabo para detectar extracciones de propiedad no autorizadas, para detectar dispositivos de grabación no autorizados, armas, etc. y para prevenir su introducción en las instalaciones. Tales inspecciones al azar deberían llevarse a cabo de acuerdo con la legislación y regulación aplicable. Los individuos deberían tener conocimiento de que se están llevando a cabo tales inspecciones al azar, y las comprobaciones deberían realizarse únicamente con la adecuada autorización conforme con los requisitos legales y reglamentarios. 10 GESTIÓN DE COMUNICACIONES Y OPERACIONES
10.1 Responsabilidades y procedimientos de operación
Objetivo: Asegurar el funcionamiento correcto y seguro de los recursos de tratamiento de la información. Deberían establecerse las responsabilidades y los procedimientos para la gestión y operación de todos los recursos de información. Esto incluye el desarrollo de procedimientos de funcionamiento adecuados. Dónde se considere apropiado se debería implantar una segregación de tareas, para reducir el riesgo de negligencia o de uso incorrecto intencionado. 10.1.1 Documentación de los procedimientos de operación
Control Deberían documentarse y mantenerse los procedimientos de operación y ponerse a disposición de todos los usuarios que los necesiten. Guía de implantación Se deberían preparar procedimientos documentados para las actividades del sistema asociadas a los recursos de tratamiento y comunicación de la información, tales como procedimientos de encendido y apagado de ordenadores, copias de respaldo, mantenimiento de los equipos, gestión de soportes, gestión de salas de ordenadores, gestión del correo, y seguridad. Los procedimientos operacionales deberían especificar las instrucciones para la ejecución detallada de cada puesto de trabajo, incluyendo: a) el tratamiento y manipulación de la información; b) las copias de respaldo (véase 10.5); c) los requisitos de planificación, incluyendo las interdependencias con otros sistemas, con los tiempos más tempranos
de comienzo y más tardíos de finalización posibles de cada tarea; d) las instrucciones para manejar errores u otras condiciones excepcionales que puedan ocurrir durante la ejecución del
trabajo, incluyendo restricciones en el uso de las utilidades del sistema (véase 11.5.4.); e) los contactos del soporte para el caso de dificultades operacionales o técnicas inesperadas; f) las instrucciones para el manejo de resultados especiales y soportes, como el uso de papel especial o como la gestión
de resultados confidenciales, incluyendo procedimientos de destrucción segura de resultados producidos como consecuencia de tareas fallidas (véanse 10.7.2 y 10.7.3);
- 47 - ISO/IEC 27002:2005
g) el reinicio del sistema y los procedimientos de recuperación a utilizar en caso de fallo del sistema; h) la gestión de pistas de auditoría y de la información del registro de sistemas (véase 10.10). Los procedimientos operacionales, y los procedimientos documentados para las actividades del sistema deberían tratarse como documentos formales y los cambios deberían ser autorizados por la Dirección. Dónde sea técnicamente posible, los sistemas de información deberían gestionarse de una manera sistemática, utilizando los mismos procedimientos, herramientas y recursos. 10.1.2 Gestión de cambios
Control Deberían controlarse los cambios en los recursos y en los sistemas de tratamiento de la información. Guía de implantación Los sistemas operacionales y las aplicaciones de software deberían estar sometidos a un estricto control de la gestión de cambios. En particular, se deberían considerar los siguientes puntos: a) la identificación y registro de los cambios significativos; b) la planificación y pruebas de los cambios; c) la evaluación de los impactos potenciales, incluyendo los impactos en la seguridad de dichos cambios; d) el procedimiento de aprobación formal de los cambios propuestos; e) la comunicación de los detalles de los cambios a las personas correspondientes; f) los procedimientos de vuelta atrás, incluyendo los procedimientos y responsabilidades para abortar y recuperar los
cambios infructuosos y los eventos imprevistos. Los procedimientos y las responsabilidades formales de gestión deberían asegurar de una manera satisfactoria el control de todos los cambios en los equipos, en el software o en los procedimientos. Cuando se efectúen los cambios, se debería conservar un registro de auditoría que contenga toda la información importante. Información adicional Una causa común de fallos de seguridad de los sistemas es el control inadecuado de los cambios en los recursos y en los sistemas de tratamiento de la información. Los cambios en el entorno operacional pueden impactar en la fiabilidad de las aplicaciones, especialmente cuando se transfiere un sistema desde la fase de desarrollo a la de operación (véase 12.5.1). Los cambios en los sistemas operacionales deberían hacerse únicamente cuando haya una razón válida para hacerlo desde el punto de vista del negocio, tal como un incremento en el riesgo del sistema. La actualización de los sistemas con las últimas versiones de los sistemas operativos o de las aplicaciones no está siempre en línea con el interés del negocio, y podría introducir más vulnerabilidades e inestabilidad que las versiones actuales. Pueden existir también necesidades adicionales de formación, de costes de licencias, de soporte, de mantenimiento y de administración, así como de un nuevo hardware, especialmente durante la migración. 10.1.3 Segregación de tareas
Control Las tareas y áreas de responsabilidad deberían segregarse para reducir la posibilidad de que se produzcan modificaciones no autorizadas o no intencionadas o usos indebidos de los activos de la organización.
ISO/IEC 27002:2005 - 48 -
Guía de implantación La segregación de tareas es un método para reducir el riesgo de uso incorrecto del sistema, ya sea accidental o intencionado. Se debería cuidar el hecho de que una persona por sí sola no pueda acceder, modificar o utilizar los activos sin autorización o sin que se detecte. El lanzamiento de un evento debería separarse de su autorización. Se debería considerar la posibilidad de colusión en el diseño de los controles. Las organizaciones pequeñas podrían considerar que la segregación de tareas es difícil de conseguir, pero el principio debería aplicarse en la medida en que sea posible y practicable. Cuando la segregación sea difícil, se deberían considerar otros controles como la monitorización de las actividades, las pistas de auditoría y la supervisión por la Dirección. Es importante que la auditoría de seguridad permanezca independiente. 10.1.4 Separación de los recursos de desarrollo, prueba y operación
Control Deberían separarse los recursos de desarrollo, de pruebas y de operación, para reducir los riesgos de acceso no autorizado o los cambios en el sistema en producción. Guía de implantación Se debería identificar el nivel de segregación entre los entornos operacionales, de prueba y de desarrollo que es necesario para prevenir los problemas operacionales e implantarse los controles apropiados. Se deberían considerar los siguientes puntos: a) se deberían definir y documentar las reglas para la transferencia de software desde el estado de desarrollo hasta el
estado de operación; b) el software de desarrollo y operación debería ejecutarse en diferentes sistemas o procesadores de ordenador y en
diferentes dominios o directorios; c) los compiladores, editores y otras herramientas de desarrollo o recursos del sistema no deberían ser accesibles desde
los sistemas operativos cuando no sean requeridos; d) el entorno de prueba del sistema debería emular el entorno del sistema operativo tan cercanamente como sea posible; e) los usuarios deberían utilizar diferentes perfiles para los sistemas operativos y de prueba, y los menús deberían
mostrar mensajes de identificación adecuados para reducir el riesgo de error; f) los datos sensibles no deberían ser copiados en el entorno del sistema de prueba (véase 12.4.2). Otra información Las actividades de desarrollo y de prueba pueden causar problemas serios, por ejemplo la modificación no deseada de ficheros o del entorno del sistema, o fallo del sistema. En este caso, es necesario mantener un entorno conocido y estable para llevar a cabo pruebas determinantes, así como para prevenir el acceso inapropiado a desarrolladores. Cuando el personal de desarrollo y de prueba tiene acceso al sistema operativo y a su información, pueden introducir código no autorizado y que no ha sido probado o datos operativos modificados. En algunos sistemas, esta capacidad podría utilizarse para cometer fraude o para introducir un código malicioso o no probado, que puede causar problemas operacionales serios. El personal de desarrollo y de prueba puede suponer también una amenaza para la confidencialidad de la información. Si las actividades de desarrollo y de prueba comparten el mismo entorno informático puede causar cambios no intencionados en el software o en la información. La separación de los recursos de desarrollo, prueba y de operación es por tanto deseable para reducir el riesgo de cambios accidentales o accesos no autorizados en el software operacional y en los datos de negocio (véase 12.4.2 en lo relativo a la protección de los datos de prueba).
- 49 - ISO/IEC 27002:2005
10.2 Gestión de la provisión de servicios por terceros
Objetivo: Implantar y mantener el nivel apropiado de seguridad de la información en la provisión del servicio, en consonancia con los acuerdos de provisión de servicios por terceros. La organización debería comprobar el cumplimiento de los acuerdos, vigilar la conformidad con los acuerdos, así como gestionar los cambios necesarios para asegurar que los servicios entregados son conformes con todos los requisitos acordados con los terceros. 10.2.1 Provisión de servicios
Control Se debería comprobar que los controles de seguridad, las definiciones de los servicios y los niveles de provisión, incluidos en el acuerdo de provisión de servicios por terceros, han sido implantados, puestos en operación y son mantenidos por parte de un tercero. Guía de implantación La provisión de servicios por terceros debería incluir las disposiciones de seguridad, las definiciones del servicio y los aspectos de gestión del servicio acordados. En el caso de acuerdos de externalización (outsourcing), la organización debería planificar las transferencias necesarias (de información, de recursos de tratamiento de la información, y de todo lo demás que sea necesario mover), y debería también asegurar que la seguridad se mantiene durante el periodo de transición. La organización debería asegurar que el tercero mantiene una capacidad de servicio suficiente junto con planes de viabilidad diseñados para asegurar que se mantiene la continuidad de los niveles de servicio acordados después de fallos graves en el servicio o después de un desastre (véase 14.1). 10.2.2 Supervisión y revisión de los servicios prestados por terceros
Control Los servicios, informes y registros proporcionados por un tercero deberían ser objeto de supervisión y revisión periódicas, y también deberían llevarse a cabo auditorias periódicas. Guía de implantación El control y la revisión de los servicios proporcionados por terceros deberían asegurar que se cumple con los términos y condiciones sobre seguridad de la información establecidos en los acuerdos, y que se gestionan de una manera adecuada los incidentes y problemas de seguridad de la información. Esto debería implicar una actuación conjunta en lo que respecta a la gestión del servicio y el proceso entre la organización y el tercero para: a) controlar los niveles de rendimiento del servicio para comprobar el cumplimiento de los acuerdos; b) revisar los informes del servicio elaborados por el tercero y convocar reuniones para controlar el progreso del
trabajo, según sea requerido por los acuerdos; c) proporcionar información sobre los incidentes de seguridad de la información y la revisión de esta información por
el tercero y por la organización según sea requerido por los acuerdos y por cualquier procedimiento o directrices de apoyo;
d) revisar las pistas de auditoría del tercero así como los registros de eventos de seguridad, de problemas operacionales,
de fallos, de trazabilidad de defectos y problemas relacionados con la provisión del servicio; e) resolver y gestionar cualquier problema que se identifique.
ISO/IEC 27002:2005 - 50 -
Debería asignarse la responsabilidad para dirigir las relaciones con un tercero a una persona de manera individual o bien a un equipo de gestión del servicio. Además, la organización debería asegurar que el tercero asigna las responsabilidades necesarias para comprobar la conformidad y el cumplimiento con los requisitos de los acuerdos. Se debería disponer de las habilidades técnicas y los recursos suficientes para controlar que se cumplen los requisitos del acuerdo (véase 6.2.3), en particular los requisitos de seguridad de la información. Cuando se observen deficiencias en la provisión del servicio, se deberían llevar a cabo las acciones adecuadas. La organización debería mantener un control global y una visibilidad suficiente de todos los aspectos de seguridad para la información crítica o sensible, o para los recursos de tratamiento de la información a los que el tercero tiene acceso, procesa o gestiona. La organización debería asegurar que conserva la visibilidad de las actividades de seguridad tales como gestión del cambio, identificación de vulnerabilidades y reporte/ respuesta de los incidentes de seguridad de la información a través de un proceso, formato y estructura de informe claramente definidos. Información adicional En caso de externalización (outsourcing), la organización necesita ser consciente que la responsabilidad última sobre la información tratada por una parte externa, permanece dentro de la organización. 10.2.3 Gestión del cambio en los servicios prestados por terceros
Control Se deberían gestionar los cambios en la provisión de los servicios, incluyendo el mantenimiento y la mejora de las políticas, los procedimientos y los controles de seguridad de la información existentes, teniendo en cuenta la criticidad de los procesos y sistemas del negocio afectados así como la reevaluación de los riesgos. Guía de implantación El proceso de gestión de cambios de los servicios prestados por terceros necesita tener en cuenta lo siguiente: a) los cambios hechos por la organización para implantar:
1) las mejoras de los servicios ofrecidos actualmente; 2) el desarrollo de cualquier aplicación y sistema nuevos; 3) modificaciones o actualizaciones de las políticas y procedimientos de la organización; 4) nuevos controles para resolver los incidentes de seguridad de la información y para mejorar la seguridad;
b) los cambios en los servicios prestados por terceros para implantar:
1) los cambios y las mejoras de las redes; 2) el uso de nuevas tecnologías; 3) la adopción de nuevos productos o versiones/ediciones nuevas; 4) nuevos desarrollos de herramientas y entornos; 5) cambios en los emplazamientos físicos de las instalaciones de los servicios; 6) cambio de proveedores.
- 51 - ISO/IEC 27002:2005
10.3 Planificación y aceptación del sistema
Objetivo: Minimizar el riesgo de fallos de los sistemas. Se requiere una planificación y una preparación por adelantado para asegurar la disponibilidad de una capacidad y unos recursos adecuados para proporcionar el rendimiento requerido del sistema. Se deberían hacer proyecciones de los requisitos futuros de capacidad, para reducir el riesgo de sobrecarga del sistema. Se deberían establecer, documentar y probar los requisitos operacionales de los sistemas nuevos previamente a su aceptación y uso. 10.3.1 Gestión de capacidades
Control La utilización de los recursos se debería supervisar y ajustar así como realizar proyecciones de los requisitos futuros de capacidad, para garantizar el rendimiento requerido del sistema. Guía de implantación Se deberían identificar los requisitos de capacidad para cada nueva actividad y para las actividades en marcha. Se deberían aplicar sistemas de control y de ajuste para asegurar, donde sea necesario, la mejora de la disponibilidad y de la eficiencia de los sistemas. Se deberían implantar controles de detección para indicar la existencia de problemas a su debido tiempo. Las proyecciones de requisitos futuros de capacidad debería tener en cuenta nuevas líneas de negocio y nuevos sistemas, así como las tendencias actuales y las previstas para las capacidades de procesado de la información de la organización. Es necesario poner una atención especial en aquellos recursos que tengan un periodo de adquisición o plazos de entrega largos o sean de costes elevados; por consiguiente los directores deberían controlar la utilización de los recursos claves del sistema. Deberían identificar las tendencias de uso, particularmente en lo que respecta a las aplicaciones de negocio o a las herramientas del sistema de gestión de la información. Los directores deberían utilizar esta información para identificar y evitar posibles cuellos de botella o dependencias de personal clave que pudieran representar una amenaza para el sistema de seguridad o para los servicios y planificar las acciones adecuadas. 10.3.2 Aceptación del sistema
Control Se deberían establecer los criterios para la aceptación de nuevos sistemas de información, de las actualizaciones y de nuevas versiones de los mismos, y se deberían llevar a cabo pruebas adecuadas de los sistemas durante el desarrollo y previamente a la aceptación. Guía de implantación Los directores deberían asegurarse de que los requisitos y los criterios de aceptación de los nuevos sistemas están claramente definidos, acordados, documentados y probados. Los nuevos sistemas de información, las actualizaciones y las nuevas versiones, únicamente deberían migrarse a producción después de haber obtenido una aceptación formal. Se deberían considerar los siguientes puntos previamente a proporcionar la aceptación formal: a) el rendimiento y los requisitos de capacidad de los sistemas informáticos o de los ordenadores; b) los procedimientos de recuperación de errores y procedimientos de reinicio, así como los planes de contingencia; c) la preparación y prueba de los procedimientos de funcionamiento rutinario para normas definidas; d) un conjunto acordado de controles de seguridad implantados; e) procedimientos manuales efectivos;
ISO/IEC 27002:2005 - 52 -
f) acuerdos de continuidad de negocio (véase 14.1); g) la evidencia de que la instalación de un nuevo sistema no afectará de manera adversa a los sistemas existentes, en
particular los momentos de picos de tratamiento, tales como finales de mes; h) la evidencia de que se ha considerado el efecto que el nuevo sistema tiene en el conjunto de la seguridad de la
organización; i) la formación en operación o uso de los nuevos sistemas; j) la facilidad de uso, puesto que afecta al rendimiento del usuario y evita el error humano. Para grandes desarrollos nuevos se debería consultar a la función de operaciones y a los usuarios, en todas las fases del proceso de desarrollo, para asegurar la eficiencia operacional del diseño del sistema propuesto. Se deberían llevar a cabo las pruebas adecuadas para comprobar que todos los criterios de aceptación han sido completamente satisfechos. Información adicional La aceptación puede incluir un proceso formal de acreditación y certificación para verificar que los requisitos de seguridad han sido adecuadamente abordados.
10.4 Protección contra el código malicioso y descargable
Objetivo: Proteger la integridad del software y de la información. Se deberían establecer los criterios para la aceptación de nuevos sistemas de información, de las actualizaciones y de nuevas versiones de los mismos, y se deberían llevar a cabo pruebas adecuadas de los sistemas durante el desarrollo y previamente a la aceptación. Los recursos de tratamiento de la información y del software son vulnerables a la introducción de código malicioso, como virus de ordenador, gusanos de red, caballos troyanos y bombas lógicas. Los usuarios deberían ser conscientes del daño del código malicioso. La Dirección debería, dónde sea apropiado, introducir controles para prevenir, detectar y eliminar el código malicioso y controlar el código descargable. 10.4.1 Controles contra el código malicioso
Control Se deberían implantar controles de detección, prevención y recuperación que sirvan como protección contra el código malicioso y se deberían implantar procedimientos adecuados de concienciación del usuario. Guía de implantación La protección contra el código malicioso debería estar basada en un software de detección de código malicioso y de reparación, la concienciación en seguridad, y los controles adecuados para el acceso a los sistemas y para la gestión del cambio. Se deberían considerar las siguientes directrices: a) el establecimiento de una política formal prohibiendo el uso de software no autorizado (véase 15.1.2); b) el establecimiento de una política formal para proteger contra los riesgos asociados a la obtención de ficheros y
software, ya sea a través de redes externas, o de cualquier otro medio, indicando las medidas de protección que deberían tomarse;
c) llevar a cabo revisiones regulares del software y contenido de los datos de los sistemas que soportan los procesos
críticos del negocio; la presencia de cualquier fichero no aprobado o modificación no autorizada debería ser formalmente investigada;
- 53 - ISO/IEC 27002:2005
d) la instalación y actualización regular de software de detección y reparación de código malicioso para escanear los ordenadores y medios como control preventivo o rutinario; las comprobaciones llevadas a cabo deberían incluir: 1) la comprobación frente a código malicioso antes de su uso de cualquier fichero en soporte electrónico u óptico,
así como los ficheros recibidos a través de redes; 2) la comprobación frente a código malicioso antes de su uso de los adjuntos al correo electrónico y las descargas;
esta comprobación debería llevarse a cabo en diferentes lugares, por ejemplo, en los servidores de correo electrónico, los ordenadores de sobremesa y en la entrada de las redes de la organización;
3) la comprobación de las páginas web frente al código malicioso;
e) definir procedimientos y responsabilidades de gestión para tratar la protección de los sistemas contra el código
malicioso, la formación en su uso, así como en el informe y recuperación de los ataques de código malicioso (véanse 13.1 y 13.2);
f) preparar planes adecuados de continuidad de negocio para la recuperación de los ataques de código malicioso,
incluyendo todos los datos y software de respaldo y disposiciones de recuperación necesarios (véase el capítulo 14); g) implantar procedimientos para recogida de información de manera regular, tales como suscripción a listas de correo
y/o revisión de páginas web que contengan información sobre nuevos códigos maliciosos; h) implantar procedimientos para verificar la información relativa al código malicioso, y asegurar que los boletines de
alerta son precisos e informativos; los Directores deberían asegurarse de que se están utilizando fuentes de confianza, tales como publicaciones acreditadas, sitios de Internet o suministradores que producen software de protección contra código malicioso fiables, para diferenciar entre correos electrónicos engañosos (hoaxes) y código malicioso real; todos los usuarios deberían ser conscientes del problema de los correos electrónicos engañosos (hoaxes) y qué hacer cuando se reciban.
Información adicional El uso de dos o más productos de software de protección contra código malicioso proveniente de diferentes suministradores puede mejorar la eficacia de la protección contra el código malicioso. El software para proteger contra el código malicioso puede instalarse de manera que proporcione actualizaciones automáticas de la definición de ficheros y motores de búsqueda para garantizar que la protección se actualiza. Debería tenerse cuidado para proteger contra la entrada de código malicioso durante los procedimientos de mantenimiento y de emergencia, durante los que pueden evitarse los controles normales de protección contra el código malicioso. 10.4.2 Controles contra el código descargado en el cliente
Control Cuando se autorice el uso de código descargado en el cliente, la configuración debería garantizar que dicho código autorizado funciona de acuerdo con una política de seguridad claramente definida, y se debería evitar que se ejecute el código no autorizado. Guía de implantación Se deberían considerar las siguientes acciones para proteger contra acciones no autorizadas del código descargable no autorizado: a) ejecutar el código descargable en un entorno lógicamente aislado; b) bloquear cualquier uso de código descargable; c) bloquear la recepción de código descargable;
ISO/IEC 27002:2005 - 54 -
d) activar en un sistema específico las medidas técnicas que se encuentren disponibles para asegurar que se gestiona el código descargable;
e) controlar los recursos disponibles para el acceso del código descargable; f) controles criptográficos para autenticar de manera inequívoca el código descargable. Información adicional El código descargable es un código de software que se transfiere de un ordenador a otro y se ejecuta automáticamente y cumple una función específica con una pequeña o ninguna interacción al usuario. El código descargable está asociado con un número de servicios de middleware. Además, para asegurar que el código descargable no contiene software malicioso, es esencial controlar el código descargable para evitar un uso no autorizado o un problema en el sistema, en la red o en los recursos de la aplicación, así como otras infracciones de la seguridad de la información.
10.5 Copias de seguridad
Objetivo: Mantener la integridad y disponibilidad de la información y de los recursos de tratamiento de la información. Deberían establecerse procedimientos rutinarios para implantar la política de copias de seguridad acordada y la estrategia (véase 14.1) para realizar las copias de seguridad de los datos y ensayar periódicamente sus tiempos de recuperación. 10.5.1 Copias de seguridad de la información
Control Se deberían realizar copias de seguridad de la información y del software, y se deberían probar periódicamente conforme a la política de copias de seguridad acordada. Guía de implantación Deberían proporcionarse los recursos adecuados para las copias de seguridad para asegurar que toda la información y software esencial puede ser recuperada después de un desastre o fallo de los soportes. Deberían considerarse los siguientes aspectos para las copias de seguridad de la información: a) debería definirse el nivel necesario de copias de seguridad de la información; b) se deberían producir registros precisos y completos de las copias de seguridad así como procedimientos de
recuperación documentados; c) la extensión (por ejemplo copias totales o diferenciales) y frecuencia de las copias de seguridad deberían reflejar los
requisitos del negocio de la organización, los requisitos de seguridad de la información implicada, y la criticidad de la información para el funcionamiento continuo de la organización;
d) las copias de seguridad deberían ser almacenadas en un emplazamiento alejado, a una distancia suficiente para
salvarse de cualquier daño proveniente de un desastre en el emplazamiento principal; e) la información de las copias de seguridad debería tener un nivel adecuado de protección tanto física como ambiental
(véase el capitulo 9), consistente con las normas aplicadas en el emplazamiento principal; los controles aplicados a los soportes del emplazamiento principal deberían ser extendidos para cubrir el emplazamiento de respaldo;
f) los soportes de las copias de seguridad deberían ser comprobados periódicamente para asegurarse de que pueden
responder en caso de uso de emergencia cuando sea necesario;
- 55 - ISO/IEC 27002:2005
g) los procedimientos de recuperación deberían ser comprobados regularmente y probados para asegurar que son efectivos y que pueden ser cumplidos dentro del tiempo asignado en los procedimientos operacionales para recuperación;
h) en las situaciones donde es importante la confidencialidad, las copias de seguridad deberían ser protegidas mediante
medios de cifrado. Las disposiciones de copias de seguridad para los sistemas individuales deberían ser regularmente probadas para asegurarse de que son conformes a los requisitos de los planes de continuidad de negocio (véase el capítulo 14). Para los sistemas críticos, las disposiciones de copias de seguridad deberían cubrir todos los sistemas de información así como las aplicaciones y los datos necesarios para la recuperación del sistema completo en el caso de desastre. Deberían ser determinados el periodo de conservación para la información esencial del negocio, y también cualquier requisito para las copias de archivo que han de ser conservadas de manera permanente (véase 15.1.3). Información adicional Las disposiciones de copias de seguridad pueden estar automatizadas para facilitar los procesos de copiado de seguridad y de recuperación. Dichas soluciones automatizadas deberían estar suficientemente probadas previamente a su implantación y a intervalos regulares.
10.6 Gestión de la seguridad de las redes
Objetivo: Asegurar la protección de la información en las redes y la protección de la infraestructura de soporte. La gestión segura de las redes, que puede extenderse hasta las fronteras de la organización, requiere consideraciones cuidadosas relativas a las implicaciones legales, al control y a la protección del flujo de datos. Pueden requerirse controles adicionales para proteger la información sensible que pase a través de redes públicas. 10.6.1 Controles de red
Control Las redes deberían estar adecuadamente gestionadas y controladas, para que estén protegidas frente a posibles amenazas y para mantener la seguridad de los sistemas y de las aplicaciones que utilizan estas redes, incluyendo la información en tránsito. Guía de implantación Los gestores de las redes deberían implantar controles para asegurar la seguridad de la información en las redes, y la protección de los servicios conectados desde accesos no autorizados. En particular, deberían ser considerados los siguientes aspectos: a) la responsabilidad operacional para las redes debería estar separada de las operaciones de los sistemas informáticos
donde sea apropiado (véase 10.1.3); b) deberían establecerse las responsabilidades y los procedimientos para la gestión de los equipos remotos, incluyendo
los equipos en áreas de usuario; c) se deberían establecer controles especiales para salvaguardar la confidencialidad y la integridad de los datos que
pasan a través de las redes públicas y a través de las redes inalámbricas, para proteger las aplicaciones y los sistemas conectados (véanse 11.4 y 12.3); pueden requerirse controles especiales para mantener la disponibilidad de los servicios de red y los ordenadores conectados;
d) se debería aplicar el registro (logging) y la monitorización adecuados para hacer posible el que las acciones de
seguridad relevantes queden registradas;
ISO/IEC 27002:2005 - 56 -
e) las actividades de gestión deberían estar estrechamente coordinadas tanto para la optimización del servicio a la organización como para asegurar que los controles son aplicados consistentemente a través de la infraestructura de tratamiento de la información.
Información adicional Se puede encontrar información adicional sobre seguridad de las redes en la Norma ISO/IEC 18028 Tecnología de la información. Técnicas de seguridad. Seguridad de las redes de TI. 10.6.2 Seguridad de los servicios de red
Control Se deberían identificar las características de seguridad, los niveles de servicio, y los requisitos de gestión de todos los servicios de red y se deberían incluir en todos los acuerdos relativos a servicios de red, tanto si estos servicios se prestan dentro de la organización como si se subcontratan. Guía de implantación La capacidad del proveedor del servicio de red para gestionar los servicios acordados de una manera segura, debería estar determinado y monitorizado de manera regular, de igual manera debería quedar acordado el derecho a ser auditado. Las disposiciones de seguridad necesarias para servicios particulares, tales como características de seguridad, niveles de servicio y requisitos de gestión deberían estar identificados. La organización debería asegurar que los proveedores de servicios de red implantan estas medidas. Información adicional Los servicios de red incluyen la provisión de conexiones, los servicios de red privada, y redes de valor añadido, así como las soluciones de seguridad de red gestionadas, tales como cortafuegos y sistemas de detección de intrusiones. Estos servicios pueden comprender desde el simple ancho de banda no gestionado hasta complejas ofertas de valor añadido. Las características de seguridad de los servicios de red pueden ser: a) tecnología aplicada a la seguridad de los servicios de red, tal como autenticación, cifrado y controles de conexión de
red; b) parámetros técnicos requeridos para conexiones seguras con los servicios de red de acuerdo a las reglas de seguridad
y de conexión de las redes; c) procedimientos para el uso de los servicios de red para restringir el acceso a los mismos o a las aplicaciones, dónde
sea necesario.
10.7 Manipulación de los soportes
Objetivo: Evitar la revelación, modificación, retirada o destrucción no autorizada de los activos, y la interrupción de las actividades de la organización. Los soportes deberían ser controlados y protegidos físicamente. Deberían establecerse procedimientos operativos apropiados para proteger los documentos, los soportes informáticos (por ejemplo: cintas, discos), los datos de entrada y salida, y la documentación del sistema, contra la revelación, modificación, eliminación o destrucción no autorizada. 10.7.1 Gestión de soportes extraíbles
Control Se deberían establecer procedimientos para la gestión de los soportes extraíbles.
- 57 - ISO/IEC 27002:2005
Guía de implantación Deberían considerarse las siguientes directrices para la gestión de los soportes extraíbles: a) cuando los contenidos de cualquier soporte reutilizable no se requieran por más tiempo, tienen que ser retirados de
la organización y deberían quedar irrecuperables; b) dónde sea necesario y práctico, se debería requerir la autorización para la retirada de los soportes de la organización
y se debería mantener un registro de tales retiradas para mantenerlo como pista de auditoría; c) todos los soportes deberían ser almacenados en un entorno seguro, de acuerdo con las especificaciones del
fabricante; d) la información almacenada en los soportes que necesite estar disponible durante un periodo de tiempo superior al
tiempo de vida medio del soporte (de acuerdo con las especificaciones del fabricante) debería ser almacenada en algún otro sitio para evitar la pérdida de la información debida al deterioro del soporte;
e) se debería considerar el registro de los soportes extraíbles para limitar las posibilidades de pérdida de datos; f) las unidades de soportes extraíbles (drives) únicamente deberían estar habilitadas si existen razones de negocio para
hacerlo. Deberían estar claramente documentados todos los procedimientos y niveles de autorización. Información adicional Los soportes extraíbles incluyen cintas, discos, discos de flash, unidades de disco duro (drives), CDs, DVDs y soportes impresos. 10.7.2 Retirada de soportes
Control Los soportes deberían ser retirados de forma segura cuando ya no vayan a ser necesarios, mediante los procedimientos formales establecidos. Guía de implantación La existencia de procedimientos formales para deshacerse de una manera segura de los soportes debería minimizar el riesgo de fugas de información sensible a personas no autorizadas. Los procedimientos para deshacerse de una manera segura de los soportes que contienen información sensible deberían ser proporcionales a la sensibilidad de dicha información. Se deberían considerar los siguientes aspectos: a) los soportes que contienen información sensible deberían ser almacenados y retirados de manera segura y fuera de
peligro, por ejemplo mediante incineración o destrucción, o borrado de los datos para impedir su uso por otra aplicación dentro de la organización;
b) los procedimientos deberían posibilitar la identificación de los elementos que puedan requerir una eliminación
segura; c) puede ser más fácil solicitar que todos los elementos sean recogidos y eliminados de una manera segura, en lugar de
tratar de separar los elementos sensibles; d) muchas organizaciones ofrecen servicios de recogida y retirada de papel, equipos y soportes; se debería tener
cuidado en seleccionar un contratista apropiado que tenga los controles y experiencia adecuados; e) la retirada de los elementos sensibles debería ser registrada cuando sea posible para mantener una pista de auditoría. Cuando se acumulen soportes para su retirada, se debería tener en cuenta el efecto de agregación, que puede causar que una gran cantidad de información no sensible se convierta en sensible.
ISO/IEC 27002:2005 - 58 -
Información adicional La información sensible podría ser desvelada a través de una retirada descuidada de los soportes (véase 9.2.6 para información sobre retirada de los equipos). 10.7.3 Procedimientos de manipulación de la información
Control Deberían establecerse procedimientos para la manipulación y el almacenamiento de la información, de modo que se proteja dicha información contra la revelación no autorizada o el uso indebido. Guía de implantación Se deberían establecer procedimientos para el tratamiento, procesado, almacenamiento y comunicación de la información de manera consistente con su clasificación (véase 7.2). Se deberían considerar los siguientes aspectos: a) la manipulación y etiquetado de todos los soportes tal como indica su nivel de clasificación; b) las restricciones de acceso para prevenir el acceso del personal no autorizado; c) el mantenimiento de un registro formal de los destinatarios autorizados de los datos; d) asegurarse que la entrada de datos está completa, que el procesado se ha completado adecuadamente y que se aplica
una validación de la salida; e) un nivel de protección de las colas de datos en espera en la salida, consistente con su sensibilidad; f) el almacenamiento de los soportes de acuerdo con las especificaciones del fabricante; g) el mantenimiento de la distribución de los datos en un mínimo; h) el marcado claro de todas las copias de los soportes para llamar la atención de los destinatarios autorizados; i) la revisión a intervalos regulares de las listas de distribución y de las listas de destinatarios autorizados. Información adicional Estos procedimientos se aplican a la información contenida en documentos, sistemas informáticos, redes, ordenadores portátiles, comunicaciones móviles, correo, transmisión de voz, comunicaciones por voz en general, multimedia, servicios o instalaciones postales, uso de máquinas de fax, y cualquier otro elemento sensible, por ejemplo cheques en blanco, facturas. 10.7.4 Seguridad de la documentación del sistema
Control La documentación del sistema debería estar protegida contra accesos no autorizados. Guía de implantación Para salvaguardar el sistema de documentación, se deberían considerar los siguientes puntos: a) la documentación del sistema debería estar almacenada de una manera segura; b) la lista de acceso a la documentación del sistema debería mantenerse en un mínimo de autorizaciones y ser
autorizada por el propietario de la aplicación; c) la documentación del sistema guardada en una red pública, o suministrada a través de una red pública, debería estar
protegida de una manera adecuada.
- 59 - ISO/IEC 27002:2005
Información adicional La documentación del sistema puede contener campos de información sensible, por ejemplo las descripciones de las aplicaciones de los procesos, las estructuras de datos y los procesos de autorización.
10.8 Intercambio de información
Objetivo: Mantener la seguridad de la información y del software intercambiados dentro de una organización y con un tercero. Los intercambios de información y de software entre organizaciones deberían estar basados en una política de intercambio formal, llevada a cabo de acuerdo con los acuerdos de intercambio, y debería ser conforme con cualquier legislación aplicable (véase el capítulo 15). Se deberían establecer procedimientos y normas para proteger la información y los soportes físicos en tránsito que contienen información.
10.8.1 Políticas y procedimientos de intercambio de información
Control Deberían establecerse políticas, procedimientos y controles formales que protejan el intercambio de información mediante el uso de todo tipo de recursos de comunicación. Guía de implantación Los procedimientos y controles a seguir cuando se utilicen medios de comunicación electrónicos para el intercambio de información, deberían considerar los siguientes puntos: a) los procedimientos diseñados para proteger la información intercambiada de la interceptación, copiado,
modificación, pérdida de ruta y destrucción; b) los procedimientos para la detección y la protección contra código malicioso que pueda transmitirse aprovechando
el uso de comunicaciones electrónicas (véase 10.4.1); c) los procedimientos para proteger la información sensible comunicada de manera electrónica que se encuentra en
forma de archivo adjunto; d) las políticas o directrices que indican el uso aceptable de los recursos de comunicación electrónica (véase 7.1.3); e) los procedimientos para el uso de las comunicaciones inalámbricas, teniendo en cuenta los riesgos implicados; f) que las responsabilidades del empleado, contratista y cualquier otro usuario no comprometa a la organización, por
ejemplo a través de difamación, hostigamiento, suplantación de identidad, envío en cadena de cartas, o compra no autorizada, etc.;
g) el uso de técnicas de cifrado, por ejemplo para proteger la confidencialidad, integridad y autenticidad de la
información (véase 12.3); h) directrices de conservación y retirada para toda la correspondencia de la organización, incluyendo mensajes, de
acuerdo a la legislación y regulaciones de carácter nacional o local que sea de aplicación; i) no dejar información crítica o sensible en los dispositivos de impresión, por ejemplo en impresoras, fotocopiadora; j) controles y restricciones asociados con los envíos por parte de dispositivos de comunicación, por ejemplo, envíos
automáticos de un correo electrónico a buzones externos;
ISO/IEC 27002:2005 - 60 -
k) recordatorios al personal relativos a tomar las debidas precauciones, por ejemplo no revelar información sensible o evitar ser escuchados o interceptados cuando se hace una llamada telefónica por:
1) personas en las intermediaciones, especialmente cuando se usan teléfonos móviles;
2) escuchas telefónicas y otras formas de escucha a través del acceso físico al auricular del teléfono o a la línea telefónica, o mediante el uso de receptores de escáner;
3) personas en el extremo del receptor;
l) no dejar mensajes que contengan información sensible en contestadores ya que estos pueden ser escuchados por personas no autorizadas, o quedar almacenados en sistemas comunitarios o almacenados en lugar incorrecto como resultado de una marcación errónea;
m) recordatorios al personal sobre los problemas derivados del uso de faxes, señalando:
1) acceso no autorizado para acceder a almacenes de mensajes y recuperar mensajes; 2) programación deliberada o accidental de máquinas para enviar mensajes a números específicos; 3) envío de documentos y mensajes a un número equivocado o marcación errónea utilizando un número
almacenado erróneo;
n) recordatorios al personal sobre el no registrar datos demográficos, tales como de correo electrónico, u otra información personal en ningún software para evitar recopilaciones para uso no autorizado;
o) recordatorios al personal relativos al hecho de que los faxes y las fotocopiadoras actuales tienen memoria de páginas
y almacenan las páginas en caso de fallo de la alimentación de papel o en la transmisión de un mensaje, que se imprimirán una vez se ha resuelto el fallo.
Además, se debería recordar al personal que no deben mantener conversaciones confidenciales en lugares públicos o en lugares de encuentro que no tengan paredes insonorizadas. Los recursos de intercambio de información deberían cumplir con los requisitos legales correspondientes (véase el capítulo 15). Otra información: El intercambio de información puede producirse a través de diferentes tipos de dispositivos de comunicación, incluyendo correo electrónico, voz, fax y vídeo. El intercambio de software puede producirse a través de diferentes medios, incluyendo descargas desde Internet así como la compra a suministradores de productos comerciales. Deberían considerarse las implicaciones de negocio, las legales y las de seguridad asociadas con el intercambio electrónico de datos, el comercio electrónico, las comunicaciones electrónicas así como los requisitos para los controles. La información puede verse comprometida debido a la falta de concienciación, de la existencia de una política o de procedimientos para el uso de recursos de intercambio de información, por ejemplo si es escuchada la conversación a través de un teléfono móvil que se realiza en un lugar público, enviando a una dirección errónea un correo electrónico, dejando mensajes en dispositivos que tienen escucha telefónica, mediante marcación directa por parte de accesos no autorizados a buzones de voz o mediante el envío accidental de faxes a un equipo erróneo. Las operaciones de negocio de la organización pueden ser interrumpidas y la información verse comprometida si los dispositivos de comunicación fallan, se sobrecargan o interrumpen (véase 10.3 y el capítulo 14). La información puede verse comprometida si es accesible a usuarios no autorizados (véase el capítulo 11).
- 61 - ISO/IEC 27002:2005
10.8.2 Acuerdos de intercambio
Control Deberían establecerse acuerdos para el intercambio de información y de software entre la organización y los terceros. Guía de implantación Los acuerdos de intercambio deberían considerar las siguientes condiciones de seguridad: a) responsabilidades de gestión para el control y la notificación de transmisiones, el envío y la recepción; b) procedimientos para la notificación del remitente de la transmisión, el envío y la recepción; c) procedimientos para asegurar la trazabilidad y el no repudio; d) un mínimo de normas técnicas para el empaquetado y la transmisión; e) acuerdos de fideicomiso; f) normas para la identificación del mensajero; g) las responsabilidades y exigencias en el caso de incidentes de seguridad de la información, tales como pérdida de
datos; h) el uso de un sistema acordado de etiquetado para la información sensible o crítica, que garantice que el significado
de las etiquetas es comprendido de manera inmediata y que la información está adecuadamente protegida; i) la propiedad y las responsabilidades para la protección de los datos, el copyright y la conformidad de las licencias de
software y consideraciones similares; j) las normas técnicas para el registro y lectura de la información y del software; k) cualquier control especial que se pueda requerir para proteger los elementos sensibles, tales como claves
criptográficas (véase 12.3). Se deberían establecer y mantener las políticas, los procedimientos y las normas para proteger la información y los soportes físicos en tránsito (véase 10.8.3) y deberían referenciarse en los acuerdos de intercambio. El contenido relativo a la seguridad de cualquier acuerdo debería reflejar la sensibilidad de la información empresarial implicada. Información adicional Los acuerdos pueden ser electrónicos o manuales y pueden tener la forma de contratos formales o condiciones de empleo. Para la información sensible, los mecanismos específicos usados para el intercambio de tal información deberían ser consistentes para todas las organizaciones y tipos de acuerdos. 10.8.3 Soportes físicos en tránsito
Control Durante el transporte fuera de los límites físicos de la organización, los soportes que contengan información deberían estar protegidos contra accesos no autorizados, usos indebidos o deterioro. Guía de implantación Se deberían considerar las siguientes directrices para proteger los soportes de información que están siendo transportados entre diferentes lugares: a) se deberían utilizar un transporte y unos transportistas de confianza;
ISO/IEC 27002:2005 - 62 -
b) se debería acordar con la Dirección una lista de transportistas autorizados; c) se deberían desarrollar procedimientos para comprobar la identificación de los transportistas; d) el embalaje debería ser suficiente para proteger los contenidos de cualquier daño físico que pudiera ocurrir durante
el transporte y de acuerdo con las especificaciones del fabricante (por ejemplo: para el software), por ejemplo la protección contra los factores ambientales que pueden reducir la eficacia de restauración del soporte, tales como la exposición al calor, a la humedad o a campos electromagnéticos;
e) se deberían adoptar controles, dónde sea necesario, para proteger la información sensible de la modificación o
revelación no autorizada; algunos ejemplos incluyen:
1) el uso de contenedores cerrados; 2) la entrega manual; 3) embalajes con evidencia de forzado (que revelen cualquier intento de conseguir acceso); 4) en casos excepcionales, la separación de los envíos en más de un envío y la entrega a través de diferentes rutas.
Información adicional La información puede ser vulnerable a accesos no autorizados, mal uso o corrupción durante el transporte físico, por ejemplo cuando los soportes se envían por correo postal o por transportista. 10.8.4 Mensajería electrónica
Control La información que sea objeto de mensajería electrónica debería estar adecuadamente protegida. Guía de implantación Las consideraciones relativas a la seguridad para mensajería electrónica deberían incluir los siguientes aspectos: a) proteger los mensajes del acceso no autorizado, la modificación o denegación del servicio; b) una garantía del direccionamiento y transporte correctos del mensaje; c) fiabilidad y disponibilidad generalizadas del servicio; d) consideraciones legales, por ejemplo los requisitos para firma electrónica; e) una aprobación previa a la utilización de servicios públicos externos tales como mensajes instantáneos o compartición
de ficheros; f) fuertes niveles de autenticación del control de acceso para redes públicamente accesibles. Información adicional La mensajería electrónica, como los correos electrónicos, el intercambio electrónico de datos (EDI), y los mensajes instantáneos juegan un papel cuya importancia está creciendo en las comunicaciones empresariales. La mensajería electrónica tiene asociados riesgos diferentes de los derivados de las comunicaciones basadas en el uso del papel. 10.8.5 Sistemas de información empresariales
Control Deberían formularse e implantarse políticas y procedimientos para proteger la información asociada a la interconexión de los sistemas de información empresariales.
- 63 - ISO/IEC 27002:2005
Guía de implantación Las consideraciones dadas a las implicaciones en lo relativo a la seguridad y al negocio derivadas de la interconexión de los dispositivos de las organizaciones deberían incluir: a) el conocimiento de las vulnerabilidades en los sistemas administrativos y contables donde la información es
compartida por diferentes partes de la organización; b) las vulnerabilidades de la información en los sistemas de comunicación empresariales, por ejemplo la grabación de
las llamadas telefónicas o las conferencias, la confidencialidad de las llamadas, el almacenamiento de los faxes, la apertura de correo, la distribución de correo;
c) la política y los controles apropiados para la gestión de la compartición de la información; d) la exclusión de las categorías de la información de negocio sensible y los documentos clasificados si el sistema no
proporciona un nivel apropiado de protección (véase 7.2); e) la restricción del acceso a la información de las agendas de personas seleccionadas, por ejemplo para el personal que
trabaja en proyectos sensibles; f) la categorías del personal, contratistas o socios de la organización a los que se les permite el uso del sistema y las
localizaciones desde las que se puede acceder (véanse 6.2 y 6.3); g) la restricción de las instalaciones seleccionadas a categorías específicas de usuarios; h) la identificación del estatus de los usuarios, por ejemplo directorios de empleados de la organización o contratistas
para el beneficio de otros usuarios; i) la conservación y copiado de seguridad de la información mantenida en el sistema (véase 10.5.1); j) los requisitos y acuerdos necesarios de vuelta atrás (véase el capítulo 14). Información adicional Los sistemas de información de las oficinas son oportunidades para la rápida diseminación y compartición de la información de las organizaciones utilizando una combinación de: documentos, ordenadores, ordenadores portátiles, comunicaciones móviles, envío de voz, y comunicaciones por voz en general, multimedia, servicios postales y máquinas de fax.
10.9 Servicios de comercio electrónico
Objetivo: Garantizar la seguridad de los servicios de comercio electrónico, y el uso seguro de los mismos. Deberían considerase las implicaciones de seguridad asociadas al uso de los servicios de comercio electrónico, incluyendo las transacciones en línea, y los requisitos para los controles. También debería tenerse en cuenta la integridad y disponibilidad de la información publicada electrónicamente a través de sistemas públicamente disponibles. 10.9.1 Comercio electrónico
Control La información incluida en el comercio electrónico que se transmita a través de redes públicas debería protegerse contra las actividades fraudulentas, las disputas contractuales, y la revelación o modificación no autorizada de dicha información.
ISO/IEC 27002:2005 - 64 -
Guía de implantación Las consideraciones de seguridad para el comercio electrónico deberían incluir lo siguiente: a) el nivel de confianza de la identidad que cada parte requiere solicitar a la otra, por ejemplo a través de la
autenticación; b) los procesos de autorización asociados con quién puede establecer los precios, o asuntos relacionados con la firma
de documentos comerciales; c) asegurar que los socios comerciales están completamente informados de sus autorizaciones; d) la determinación y cumplimiento de los requisitos de confidencialidad, integridad, evidencia de envío y recepción de
documentos claves, y el no repudio de contratos, por ejemplo asociado con los procesos de licitaciones y contratos; e) el nivel de confianza requerido en la integridad de listas de precios anunciados; f) la confidencialidad de cualquier dato o información sensible; g) la confidencialidad e integridad de cualquier orden de transacciones, información de pago, y confirmación de
recepción; h) el grado de verificación apropiado para comprobar la información de pago suministrada por un cliente; i) la selección de las formas de pago más adecuadas 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) evitar la pérdida o duplicación de la información de la transacción; l) la responsabilidad asociada con cualquier transacción fraudulenta; m) los requisitos de los seguros. Muchas de las consideraciones anteriormente expuestas pueden ser llevadas a cabo mediante la aplicación de los controles criptográficos (véase 12.3), teniendo en cuenta el cumplimiento con los requisitos legales (véase 15.1, especialmente 15.1.6 para la legislación relativa a criptografía). Los acuerdos relativos al comercio electrónico entre los socios comerciales debería estar soportada por un acuerdo documentado que compromete a ambas partes con los términos comerciales acordados, incluyendo los detalles de autorización [véase b) arriba]. Pueden ser necesarios otros acuerdos con proveedores de servicios de información y de redes de valor añadido. Los sistemas públicos de comercio deberían publicitar sus términos de negocio a los clientes. Se deberían proporcionar consideraciones relativas a la capacidad de recuperación con respecto a los ataques al servidor (host) utilizado para el comercio electrónico, y las implicaciones de seguridad de cualquier red de interconexión requerida para la implantación de los servicios de comercio electrónico (véase 11.4.6). Información adicional El comercio electrónico es vulnerable a numerosas amenazas de la red que pueden provocar una actividad fraudulenta, un litigio al contrato, y la revelación o modificación de la información. El comercio electrónico puede hacer uso de métodos seguros de autenticación, por ejemplo utilizando criptografía de clave pública y firmas electrónicas (véase 12.3) para reducir los riesgos. También se pueden utilizar terceras partes de confianza, cuando sean necesarios tales servicios.
- 65 - ISO/IEC 27002:2005
10.9.2 Transacciones en línea
Control La información contenida en las transacciones en línea debería estar protegida para evitar transmisiones incompletas, errores de direccionamiento, alteraciones no autorizadas de los mensajes, la revelación, la duplicación o la reproducción no autorizadas del mensaje. Guía de implantación Las consideraciones sobre la seguridad de las transacciones en línea 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, de tal manera que se garantice que:
1) las credenciales usadas por todas las partes son válidas y están verificadas; 2) se mantiene la confidencialidad durante la transacción; y 3) se conserva la privacidad de todas las partes implicadas
c) las rutas de comunicación entre todas las partes están cifradas; d) los protocolos utilizados para la comunicación entre todas las partes está securizado; e) asegurar que el almacenamiento de los detalles de las transacciones se sitúa fuera de cualquier entorno público y
accesible, por ejemplo en una plataforma de almacenamiento existente en la Intranet de la organización, y no se conserva ni se expone en un medio de almacenamiento accesible de manera directa a través de Internet;
f) dónde se utilice una autoridad de confianza (por ejemplo para los fines de emisión y mantenimiento de firmas
electrónicas o certificados digitales), la seguridad está integrada y embebida de principio a fin en todo el proceso de gestión del certificado/firma.
Información adicional La extensión de los controles adoptados necesitará estar en proporción con el nivel de riesgo asociado a cada forma de transacción on-line. Las transacciones pueden necesitar ser conformes con legislaciones, reglas, y reglamentaciones de la jurisdicción en la que la transacción se genera, se procesa, completa o almacena. Existen muchas formas de transacciones que pueden llevarse a cabo de manera on-line, por ejemplo contractuales, financieras etc. 10.9.3 Información públicamente disponible
Control La integridad de la información puesta a disposición pública se debería proteger para evitar modificaciones no autorizadas. Guía de implantación El software, los datos y cualquier Información adicional que requiera un alto nivel de integridad, que esté disponible en un sistema públicamente accesible debería estar protegida mediante los mecanismos apropiados, por ejemplo firmas electrónicas (véase 12.3). El sistema públicamente accesible debería ser probado contra debilidades y fallos previamente a hacer accesible la información. Debería existir un proceso formal de aprobación antes de hacer públicamente accesible la información. Además todas las entradas provenientes de fuera del sistema deberían ser verificadas y aprobadas.
ISO/IEC 27002:2005 - 66 -
Los sistemas electrónicos de publicidad, especialmente aquellos que permiten retroalimentación y entrada directa de información, deberían ser cuidadosamente controlados para que: a) la información se obtenga conforme a la legislación de protección de datos (véase 15.1.4); b) la información proveniente del, y procesada por, el sistema de publicidad sea procesada completamente y de una
manera precisa y adecuada de forma oportuna; c) la información sensible sea protegida durante su recogida, procesamiento y almacenamiento; d) el acceso al sistema de publicidad no permita el acceso no intencionado a las redes a las que el sistema está
conectado. Información adicional La información que está en un sistema públicamente accesible, por ejemplo la información en un servidor web accesible a través de Internet, puede requerir el cumplimiento con legislaciones, reglas y reglamentaciones de la jurisdicción en la que se sitúa el sistema, donde la comercialización tiene lugar o dónde reside el propietario. La modificación no autorizada de la información publicada puede dañar la reputación de la organización.
10.10 Supervisión
Objetivo: Detectar las actividades de tratamiento de la información no autorizadas. Los sistemas deberían ser monitorizados y los eventos de seguridad de la información deberían ser registrados. Se deberían utilizar diarios de los registros de fallos para asegurar que se identifican los problemas del sistema de información. Una organización debería cumplir con todos los requisitos legales que le son de aplicación para las actividades de seguimiento y de registro. La monitorización del sistema debería utilizarse para comprobar la eficacia de los controles adoptados y para verificar la conformidad con el modelo de política de accesos. 10.10.1 Registros de auditoría
Control Se deberían generar registros de auditoría de las actividades de los usuarios, las excepciones y eventos de seguridad de la información, y se deberían mantener estos registros durante un periodo acordado para servir como prueba en investigaciones futuras y en la supervisión del control de acceso. Guía de implantación Los registros de auditoría deberían incluir, cuando sea aplicable: a) identificadores de usuario (IDs); b) fechas, tiempos, y detalles de eventos clave, por ejemplo conexión (log-on) y desconexión (log-off); c) identidad o localización del terminal, si es posible; d) registro de intentos de acceso a los sistemas exitosos y rechazados; e) registro de intentos de acceso a los recursos y a los datos exitosos y rechazados; f) cambios en la configuración del sistema; g) uso de privilegios;
- 67 - ISO/IEC 27002:2005
h) uso de utilidades y aplicaciones del sistema; i) ficheros a los que se ha accedido y el tipo de acceso; j) direcciones de red y protocolos; k) alarmas generadas por el sistema de control de acceso; l) activación y desactivación de los sistemas de protección, tales como sistemas de antivirus y de detección de intrusión. Información adicional Los registros de auditoría pueden contener datos personales intrusivos y confidenciales. Se deberían tomar las medidas adecuadas de protección de la privacidad (véase 15.1.4). Dónde sea posible, los administradores del sistema no deberían tener permiso para borrar o desactivar los registros de sus propias actividades (véase 10.1.3). 10.10.2 Supervisión del uso del sistema
Control Se deberían establecer procedimientos para supervisar el uso de los recursos de tratamiento de la información y se deberían revisar periódicamente los resultados de las actividades de supervisión. Guía de implantación El nivel de seguimiento requerido para los dispositivos individuales debería ser determinado mediante un análisis de riesgos. Una organización debería cumplir con todos los requisitos legales que le son de aplicación en lo relativo al seguimiento de las actividades. Las áreas que deberían considerarse incluyen: a) acceso autorizado, incluyendo detalles como:
1) identificador de usuario (ID); 2) la fecha y el tiempo de los eventos clave; 3) los tipos de eventos; 4) los ficheros a los que se ha accedido; 5) el programa o los servicios usados;
b) todas las operaciones realizadas utilizando privilegios, tales como:
1) uso de cuentas con privilegios, por ejemplo, supervisor, raíz, administrador; 2) arranques y paradas del sistema; 3) conexión / desconexión de dispositivos de entrada/salida (I/O);
c) intentos de acceso no autorizado, tales como:
1) acciones de usuario fallidas o rechazadas; 2) acciones fallidas o rechazadas que implican datos y otros recursos; 3) violaciones de la política de acceso y notificaciones para pasarelas de red y cortafuegos; 4) alertas provenientes de los sistemas propietarios de detección de intrusión;
ISO/IEC 27002:2005 - 68 -
d) sistema de alertas por fallos tales como:
1) alertas o mensajes de consola; 2) excepciones al registro del sistema; 3) alarmas de gestión de la red; 4) alarmas activadas por el sistema de control de accesos;
e) cambios, o intentos de cambio en las configuraciones y los controles de seguridad del sistema. La frecuencia con que se revisan los resultados de las actividades de seguimiento, debería depender de los riesgos implicados. Los factores de riesgo que deberían considerarse incluyen: a) la criticidad de los procesos y las aplicaciones; b) valor, sensibilidad y criticidad de la información implicada; c) experiencia anterior relativa a la infiltración y mal uso del sistema, así como la frecuencia con que son explotadas
las vulnerabilidades; d) extensión de la interconexión del sistema (particularmente a redes públicas); e) dispositivos de registro que están siendo desactivados. Información adicional La utilización de procedimientos de seguimiento es necesaria para asegurar que los usuarios únicamente llevan a cabo actividades para las que han sido explícitamente autorizados. Una revisión del registro (log) implica el entendimiento de las amenazas a las que se enfrenta el sistema y la manera en la que se producen esas amenazas. Ejemplos de incidencias que pueden requerir una investigación más profunda en el caso de que ocurra un incidente de seguridad se proporcionan en el apartado 13.1.1. 10.10.3 Protección de la información de los registros
Control Los dispositivos de registro y la información de los registros deberían estar protegidos contra manipulaciones indebidas y accesos no autorizados. Guía de implantación Los controles deberían dirigirse a proteger contra los cambios no autorizados y los problemas operacionales relativos a los dispositivos de registro, incluyendo: a) alteraciones en los caracteres de los mensajes que son registrados; b) edición o borrado del fichero de registro; c) capacidad de almacenamiento de los soportes de registro de ficheros que está siendo excedida, provocando o bien un
fallo del registro de eventos o sobrescribiendo los registros de eventos pasados. Algunos registros de auditoría pueden requerir el ser archivados como parte del procedimiento de conservación de registros o debido a requisitos para recopilar y conservar evidencias (véase 13.2.3).
- 69 - ISO/IEC 27002:2005
Información adicional Los registros del sistema a menudo contienen un gran volumen de información, mucha de la cual no tiene relación con la monitorización de la seguridad. Se deberían considerar, para ayudar a la identificación de las incidencias significativas para los fines de monitorización de la seguridad, el copiado de manera automática de los tipos de mensajes apropiados a un segundo registro, y/o el uso de los recursos adecuados del sistema o de herramientas de auditoria para realizar la interrogación y la racionalización del fichero. Los registros del sistema necesitan estar protegidos, porque si los datos que contienen pueden modificarse o borrarse, su existencia puede crear una falsa sensación de seguridad. 10.10.4 Registros de administración y operación
Control Se deberían registrar las actividades del administrador y del operador del sistema. Guía de implantación Los registros deberían incluir: a) el momento en que ocurre un evento (exitoso o fallido); b) la información sobre el evento (por ejemplo los ficheros manejados) o el fallo (por ejemplo el error ocurrido y la
acción correctiva tomada); c) que cuenta de usuario y que administrador u operador estuvieron implicados; d) que procesos estuvieron implicados. Los registros del administrador del sistema y del operador del sistema deberían ser revisados regularmente. Información adicional Se pueden utilizar sistemas de detección de intrusión gestionados fuera del control de los administradores del sistema y de la red, para controlar el cumplimiento de las actividades de los administradores del sistema y de la red. 10.10.5 Registro de fallos
Control Los fallos deberían ser registrados y analizados y se deberían tomar las correspondientes acciones. Guía de implantación Deberían registrarse los fallos informados por los usuarios o por los programas del sistema relativos a los problemas con la información procesada o con el sistema de comunicaciones. Deberían existir reglas claras para el tratamiento de los informes de fallos, incluyendo: a) la revisión de los registros de fallos para asegurar que los fallos han sido resueltos de manera satisfactoria; b) la revisión de las medidas correctivas para asegurar que los controles no han quedado comprometidos, y que la
acción tomada ha sido totalmente autorizada. Se debería asegurar que el registro de los fallos está habilitado, en caso de que esta función del sistema esté disponible. Información adicional Los registros de errores y fallos pueden impactar en el comportamiento del sistema. Tal registro debería ser habilitado por el personal competente, y se debería determinar mediante un análisis de riesgos, el nivel de registro requerido para sistemas individuales, teniendo en cuenta la degradación del comportamiento.
ISO/IEC 27002:2005 - 70 -
10.10.6 Sincronización del reloj
Control Los relojes de todos los sistemas de tratamiento de la información dentro de una organización o de un dominio de seguridad, deberían estar sincronizados con una única fuente precisa y acordada de tiempo. Guía de implantación Cuando un ordenador o dispositivo de comunicaciones tiene la capacidad de funcionar con un reloj a tiempo real, dicho reloj debería establecerse según una norma aceptada, por ejemplo el Tiempo Universal Coordinado (UCT) o un tiempo normalizado local. Como se sabe que algunos relojes se dispersan con el paso del tiempo, debería existir un procedimiento que compruebe y corrija cualquier variación significativa. La interpretación correcta del formato fecha/hora es importante para garantizar que el sellado de tiempo refleja la fecha/hora reales. Se deberían tener en cuenta las especificaciones locales (por ejemplo el horario de verano). Información adicional La correcta configuración de los relojes de un ordenador es importante para garantizar la precisión de los registros de auditoría, que pueden requerirse para investigaciones o como evidencia en casos legales o disciplinarios. Un reloj enlazado con la radiodifusión de información horaria desde un reloj nacional atómico puede utilizarse como reloj maestro para los sistemas de registro. Un protocolo de red de tiempo puede ser usado para mantener todos los servidores sincronizados con el reloj maestro. 11 CONTROL DE ACCESO
11.1 Requisitos de negocio para el control de acceso
Objetivo: Controlar el acceso a la información. El acceso a la información, los recursos de tratamiento de la información y los procesos de negocio deberían ser controlados sobre la base de los requisitos de negocio y de seguridad. Las reglas de control de acceso deberían tener en cuenta las políticas para la diseminación y autorización de la información. 11.1.1 Política de control de acceso
Control Se debería establecer, documentar y revisar una política de control de acceso basada en los requisitos del negocio y de seguridad para el acceso. Guía de implantación Los derechos y reglas de control de acceso para cada usuario o grupo de usuarios deberían estar claramente establecidos en una política de control de acceso. Los controles de acceso se refieren tanto al acceso lógico como al acceso físico (véase también el capítulo 9) y deberían ser considerados de manera conjunta. Se debería proporcionar a los usuarios y proveedores de servicio una declaración clara de los requisitos de negocio que puedan satisfacerse mediante los controles de acceso. La política debería tener en cuenta lo siguiente: a) los requisitos de seguridad de las aplicaciones individuales del negocio; b) la identificación de toda la información relativa a las aplicaciones del negocio y los riesgos de la información a la
vista; c) las políticas para la diseminación y autorización de la información, por ejemplo la necesidad de conocer los
principios y niveles de seguridad y la clasificación de la información (véase 7.2);
- 71 - ISO/IEC 27002:2005
d) la consistencia entre el control de acceso y las políticas de clasificación de la información de los diferentes sistemas y redes;
e) la legislación aplicable y cualquier obligación contractual relativa a la protección del acceso a los datos y a los
servicios (véase 15.1); f) perfiles de acceso de usuario normalizados para puestos de trabajo comunes dentro de la organización; g) la gestión de los derechos de acceso en un entorno distribuido e interconectado que reconozca todos los tipos de
conexiones disponibles; h) la segregación de las funciones para el control de acceso, por ejemplo requerimiento de acceso, autorización de
acceso, administración de acceso; i) los requisitos para la autorización formal de los requerimientos de acceso (véase 11.2.1); j) los requisitos para la revisión periódica de los controles de acceso (véase 11.2.4); k) la retirada de los controles de acceso (véase 8.3.3). Información adicional Se debería tener cuidado cuando se especifiquen las reglas de control de acceso para considerar: a) la diferenciación entre las reglas que deberían ser siempre cumplidas y las directrices que son opcionales o
condicionales; b) el establecimiento de reglas basadas en la premisa de �En general, todo está prohibido a menos que esté
expresamente permitido� en lugar de la regla más floja �En general todo está permitido a menos que esté expresamente prohibido�;
c) los cambios en las etiquetas de la información (véase 7.2) que se ponen en marcha automáticamente mediante
recursos de tratamiento de la información y aquellos iniciados a discreción del usuario; d) los cambios en los permisos de usuario que son puestos en marcha automáticamente por el sistema de información y
aquellos iniciados por un administrador; e) las reglas que requieren la aprobación específica antes de su promulgación, y aquellas que no. Las reglas de control de acceso deberían estar soportadas por procedimientos formales y responsabilidades claramente definidas (véase por ejemplo, 6.3.1, 11.3, 10.4.1, 11.6).
11.2 Gestión de acceso de usuario
Objetivo: Asegurar el acceso de un usuario autorizado y prevenir el acceso no autorizado a los sistemas de información. Se deberían establecer procedimientos formales para controlar la localización de los derechos de acceso a los sistemas de información y los servicios. Los procedimientos deberían cubrir todas las fases del ciclo de vida del acceso de usuario, desde el registro inicial de nuevos usuarios al registro final de los usuarios que no requieren el acceso a los sistemas de información y a los servicios por más tiempo. Se debería poner especial atención, dónde corresponda, a la necesidad de localización de los privilegios de derechos de acceso, que permiten a los usuarios invalidar los controles del sistema.
ISO/IEC 27002:2005 - 72 -
11.2.1 Registro de usuario
Control Debería establecerse un procedimiento formal de registro y de anulación de usuarios para conceder y revocar el acceso a todos los sistemas y servicios de información. Guía de implantación El procedimiento de control de acceso para el registro y retirada del registro de usuarios debería incluir: a) la utilización de un único identificador de usuario (ID) para posibilitar la conexión de los usuarios y para hacerles
responsables de sus acciones; la utilización del grupo de identificadores de usuario (IDs) debería permitirse únicamente cuando sea necesario por razones de negocio u operacionales, y debería ser aprobado y estar documentado;
b) la comprobación de que el usuario tiene autorización del propietario del sistema para el uso del sistema o del
servicio de información; puede ser adecuado separar la aprobación de los derechos de acceso de la gestión; c) la comprobación de que el nivel de acceso concedido es adecuado al objetivo del negocio (véase 11.1) y es
consistente con la política de seguridad de la organización, por ejemplo que no compromete la segregación de funciones (véase 10.1.3);
d) dar a los usuarios una declaración por escrito de sus derechos de acceso; e) requerir a los usuarios la firma de declaraciones indicando que entienden las condiciones de acceso; f) asegurarse que los proveedores de servicio no proporcionan ningún acceso hasta que se han completado los
procedimientos de autorización; g) el mantenimiento de un registro formal de todas las personas registradas para el uso del servicio; h) la inmediata retirada o el bloqueo de los derechos de acceso a los usuarios que han cambiado de puesto o han
abandonado la organización; i) la comprobación periódica, incluida la retirada o el bloqueo, de los identificadores de usuario (IDs) y las cuentas
redundantes (véase 11.2.4); j) asegurar que los identificadores de usuario (IDs) redundantes no son dados a otros usuarios. Información adicional Se deberían proporcionar consideraciones para establecer las funciones de acceso de usuario basadas en los requisitos del negocio que resumen un número de derechos de acceso para unos perfiles típicos de acceso de usuario. Los accesos requeridos y las revisiones (véase 11.2.4) son más fáciles de gestionar al nivel de dichas funciones que a un nivel de derechos particulares. Se deberían proporcionar consideraciones para incluir capítulos en los contratos personales y los contratos de servicio que especifiquen las sanciones si se intenta un acceso no autorizado por el personal o por los agentes de servicio (véanse 6.1.5, 8.1.3 y 8.2.3) 11.2.2 Gestión de privilegios
Control La asignación y el uso de privilegios deberían estar restringidos y controlados.
- 73 - ISO/IEC 27002:2005
Guía de implantación Los sistemas de usuario múltiple que requieran protección contra el acceso no autorizado deberían tener controlada la asignación de los privilegios a través de un proceso formal de autorización. Se deberían considerar los siguientes pasos: a) deberían identificarse los privilegios de acceso asociados a cada producto del sistema, por ejemplo el sistema de
operaciones, el sistema de gestión de la base de datos y cada aplicación, así como los usuarios a quienes hay que asignarlos;
b) los privilegios deberían asignarse a los usuarios en base a la necesidad de uso, y caso por caso, en línea con la
política de control de acceso (véase 11.1.1), por ejemplo, el requisito mínimo para su rol funcional únicamente cuando sea necesario;
c) se debería mantener un proceso de autorización y un registro de todos los privilegios asignados. No se deberían
conceder privilegios hasta que se complete el proceso de autorización; d) se debería fomentar el desarrollo y el uso de un sistema de rutinas para evitar la necesidad de conceder privilegios a
los usuarios; e) se debería fomentar el desarrollo y el uso de programas que eviten la necesidad de ser ejecutados con privilegios; f) los privilegios se deberían asignar a diferentes identificadores de usuario IDs, a partir de los utilizados para el uso
normal del negocio. Información adicional El uso inadecuado de privilegios de administrador del sistema (cualquier característica o servicio de un sistema de información que permite al usuario la anulación de los controles del sistema o de la aplicación) puede ser un factor que contribuya a los fallos o infracciones de los sistemas. 11.2.3 Gestión de contraseñas de usuario
Control La asignación de contraseñas debería ser controlada a través de un proceso de gestión formal. Guía de implantación El proceso debería incluir los siguientes requisitos: a) se debería requerir a los usuarios la firma de una declaración para mantener la confidencialidad de las contraseñas
personales y mantener un grupo de contraseñas exclusivamente para los miembros del grupo; esta declaración firmada podría estar incluida en los términos y condiciones del puesto de trabajo (véase 8.1.3);
b) cuando se requiera a los usuarios el mantener sus propias contraseñas, se les debería proporcionar inicialmente una
contraseña segura y provisional (véase 11.3.1) la cual se vean obligados a cambiar inmediatamente; c) establecer requisitos para verificar la identidad de un usuario previamente a proporcionarle una contraseña ya sea
nueva, de sustitución o provisional; d) las contraseñas provisionales deberían proporcionarse a los usuarios de una manera segura; debería evitarse el uso
de terceras partes o de mensajes de correo electrónico sin protección (texto limpio); e) las contraseñas provisionales deberían ser únicas e individuales y no adivinables; f) los usuarios deberían dar acuse de recibo de las contraseñas; g) las contraseñas nunca deberían ser almacenadas en los ordenadores de una manera no protegida; h) las contraseñas por defecto del vendedor deberían ser modificadas en el proceso de instalación de los sistemas o del software.
ISO/IEC 27002:2005 - 74 -
Información adicional Las contraseñas son un medio habitual de verificar la identidad de los usuarios antes del acceso al sistema o al servicio de información de acuerdo al proceso de autorización del usuario. Hay disponibles otras tecnologías para identificación de usuarios y autenticación, como técnicas biométricas, por ejemplo la verificación de la huella dactilar, la verificación de la firma o bien el uso de dispositivos de hardware como tarjetas inteligentes, que también deberían considerarse cuando sea apropiado. 11.2.4 Revisión de los derechos de acceso de usuario
Control La Dirección debería revisar los derechos de acceso de usuario a intervalos regulares y utilizando un proceso formal. Guía de implantación La revisión de los derechos de acceso debería considerar las siguientes directrices: a) los derechos de acceso de usuario deberían revisarse a intervalos regulares, por ejemplo, en periodos de 6 meses, y
después de cualquier cambio, tal como promoción, degradación o terminación del empleo (véase 11.2.1); b) los derechos de acceso de usuario deberían revisarse y reasignarse cuando se traspasan de un empleado a otro dentro
de la misma organización; c) las autorizaciones para derechos de acceso con privilegios especiales (véase 11.2.2) deberían revisarse a intervalos
más frecuentes, como por ejemplo en periodos de 3 meses; d) las asignaciones de privilegios deberían comprobarse a intervalos regulares para asegurar que no se han obtenido
privilegios no autorizados; e) los cambios en las cuentas de privilegios deberían ser registrados para su revisión periódica. Información adicional Es necesaria la revisión de los derechos de acceso de usuario para mantener un control efectivo sobre el acceso a los datos y a los servicios de información.
11.3 Responsabilidades de usuario
Objetivo: Prevenir el acceso de usuarios no autorizados, así como evitar el que se comprometa o se produzca el robo de información o de recursos de tratamiento de la información. La cooperación entre los usuarios autorizados es esencial para una seguridad efectiva. Los usuarios deberían ser conscientes de sus responsabilidades de cara a un mantenimiento eficaz de los controles de acceso, particularmente en lo que se refiere al uso de contraseñas y al uso seguro del equipo. Debería implantarse una política de puesto de trabajo despejado y pantalla limpia, para reducir el riesgo de acceso no autorizado o el daño a los papeles, soportes y recursos de tratamiento de la información. 11.3.1 Uso de contraseñas
Control Se debería requerir a los usuarios el seguir las buenas prácticas de seguridad en la selección y el uso de las contraseñas. Guía de implantación Se debería aconsejar a todos los usuarios lo siguiente: a) mantener la confidencialidad de las contraseñas;
- 75 - ISO/IEC 27002:2005
b) evitar el guardar un registro de la claves (por ejemplo en papel, en un fichero de software o en un dispositivo manual), a menos que este pueda ser almacenado de forma segura y el método de almacenamiento haya sido aprobado;
c) cambiar las contraseñas siempre que haya cualquier indicación de que hayan podido quedar comprometidos el
sistema o la contraseña; d) seleccionar contraseñas de calidad con una mínima longitud pero suficiente para:
1) ser fáciles de recordar;
2) que no estén basadas en algo que alguien más pueda adivinar fácilmente u obtener usando la información relativa a la persona, por ejemplo nombres, números de teléfono, fechas de nacimiento etc.;
3) no ser vulnerables a ataques de diccionario (por ejemplo, que no consistan en palabras incluidas en diccionarios);
4) no contengan caracteres consecutivos, idénticos, todos numéricos o todos alfanuméricos.
e) cambiar las contraseñas a intervalos regulares o a intervalos basados en el número de accesos (las contraseñas para cuentas privilegiadas deberían cambiarse más frecuentemente que las contraseñas normales), y evitar la reutilización o utilización cíclica de las antiguas contraseñas;
f) cambiar las contraseñas provisionales en la primera entrada; g) no incluir contraseñas en ningún proceso de registro automático, por ejemplo almacenamiento en una macro o en
una función llave; h) no compartir contraseñas de usuario de carácter individual; i) no usar la misma contraseña para propósitos profesionales que para no profesionales. Si los usuarios necesitan acceder a múltiples servicios, sistemas o plataformas, y se requiere mantener múltiples contraseñas por separado, los usuarios deberían ser asesorados del posible uso de una única contraseña de calidad [véase d), arriba] para todos los servicios donde el usuario esté seguro que se ha establecido un nivel razonable de protección para el almacenamiento de la contraseña dentro de cada servicio, sistema o plataforma. Información adicional La gestión del sistema del servicio de ayuda para la pérdida u olvido de contraseñas necesita ser especialmente cuidadoso, dado que este es un medio de ataque al sistema de contraseñas. 11.3.2 Equipo de usuario desatendido
Control Los usuarios deberían asegurarse de que el equipo desatendido tiene la protección adecuada. Guía de implantación Todos los usuarios deberían ser conscientes de los requisitos de seguridad y los procedimientos de protección para el equipo desatendido, así como de sus responsabilidades para la implantación de dicha protección. Los usuarios deberían ser asesorados para: a) terminar las sesiones activas cuando se acaben, a menos que estén aseguradas a través de un mecanismo de bloqueo
adecuado, por ejemplo protector de pantalla con contraseña; b) apagado de los ordenadores centrales, de los servidores y de los ordenadores personales de oficina cuando la sesión
haya terminado (por ejemplo, no sólo el apagado de la pantalla del ordenador o del terminal); c) asegurar los ordenadores personales o los terminales de accesos no autorizados a través de un bloqueo de clave o un
control equivalente, por ejemplo, contraseñas de acceso cuando no están en uso (véase 11.3.3).
ISO/IEC 27002:2005 - 76 -
Información adicional El equipo instalado en áreas de usuario, por ejemplo en puestos de trabajo o servidores de fichero, pueden requerir una protección específica contra accesos no autorizados cuando se deje desatendido por un periodo largo. 11.3.3 Política de puesto de trabajo despejado y pantalla limpia
Control Debería adoptarse una política de puesto de trabajo despejado de papeles y de soportes de almacenamiento extraíbles junto con una política de pantalla limpia para los recursos de tratamiento de la información. Guía de implantación La política de puesto de trabajo despejado y pantalla limpia debería tener en cuenta las clasificaciones de la información (véase 7.2), los requisitos legales y contractuales (véase 15.1), y los correspondientes riesgos y aspectos culturales de la organización. Se deberían considerar las siguientes directrices: a) la información del negocio sensible o crítica, por ejemplo en papel o en soportes de almacenamiento electrónico,
debería estar guardada (idealmente en una caja fuerte, armario u otro tipo de mueble de seguridad), cuando no se necesite, especialmente cuando la oficina está vacía;
b) los ordenadores y terminales deberían quedarse apagados o protegidos mediante un mecanismo de bloqueo de
pantalla y teclado controlado mediante una contraseña, dispositivo o mecanismo similar de autenticación de usuario cuando estén desatendidos y deberían estar protegidos mediante claves de bloqueo, contraseñas u otros controles cuando no están en uso;
c) deberían protegerse los puntos de entrada y salida de correo y las máquinas de fax desatendidas; d) debería prevenirse el uso por usuarios no autorizados de fotocopias y otros dispositivos de reproducción (por
ejemplo escáneres, cámaras digitales); e) los documentos que contienen información sensible o información clasificada deberían retirarse de manera
inmediata de las impresoras. Información adicional Una política de puesto de trabajo despejado y pantalla limpia reduce los riesgos de accesos no autorizados, pérdida o daño de la información tanto durante las horas normales de trabajo como fuera de ellas. Las cajas fuertes u otras formas de almacenamiento seguro pueden proteger la información almacenada también contra desastres tales como el fuego, un terremoto, una inundación o una explosión. Considerar el uso de impresoras con función de código pin, de esta manera los originarios son los únicos que pueden obtener copias, y además hacerlo únicamente cuando estén próximos a la impresora.
11.4 Control de acceso a la red
Objetivo: Prevenir el acceso no autorizado a los servicios en red. Se debería controlar el acceso a los servicios en red, tanto internos como externos. El acceso de usuarios a redes y a servicios en red no debería comprometer la seguridad de los servicios en red, garantizando los siguientes aspectos: a) la colocación de interfaces adecuados entra las redes de la organización y las redes de otras organizaciones o las
redes públicas; b) que se aplican mecanismos de autenticación adecuados tanto para los usuarios como para los equipos; c) se respectan los controles de acceso de usuario a los servicios de información.
- 77 - ISO/IEC 27002:2005
11.4.1 Política de uso de los servicios en red
Control Se debería proporcionar a los usuarios únicamente el acceso a los servicios para que los que hayan sido específicamente autorizados. Guía de implantación Se debería elaborar una política relativa al uso de las redes y los servicios en red. Esta política debería cubrir lo siguiente: a) las redes y servicios de red a los que está permitido el acceso; b) los procedimientos de autorización para determinar a quién se le permite el acceso y a qué redes y a qué servicios en
red; c) los procedimientos de gestión y los controles para proteger el acceso a las conexiones de red y a los servicios en red; d) los medios utilizados para acceder a las redes y a los servicios en red (por ejemplo, las condiciones para permitir el
acceso telefónico a un proveedor de servicios de Internet o a un sistema remoto). La política para el uso de los servicios en red debería ser consistente con la política de control de acceso al negocio (véase 11.1). Información adicional Las conexiones a los servicios en red no autorizadas e inseguras pueden afectar al conjunto de la organización. Este control es particularmente importante para las conexiones de red a aplicaciones del negocio sensibles o críticas o para los usuarios en posiciones de alto riesgo, por ejemplo en las áreas públicas o externas que están fuera del control y de la gestión de la seguridad de la información de la organización. 11.4.2 Autenticación de usuario para conexiones externas
Control Se deberían utilizar los métodos apropiados de autenticación para controlar el acceso de los usuarios remotos. Guía de implantación La autenticación de los usuarios en remoto puede conseguirse usando por ejemplo, técnicas basadas en criptografía, dispositivos de hardware, protocolo de pregunta/respuesta. Las posibles implantaciones de tales técnicas pueden encontrarse en varias soluciones de red privada virtual (VPN). Las líneas privadas dedicadas pueden también utilizarse para proporcionar seguridad de la fuente de conexiones. Los procedimientos y controles de re-llamada, por ejemplo utilizando módems de re-llamada, pueden proporcionar protección contra las conexiones no autorizadas y no deseadas a los recursos de tratamiento de la información de la organización. Este tipo de controles autentica a los usuarios que intentan establecer una conexión a una red de la organización desde una posición remota. Cuando se utilice este control, la organización no debería usar servicios en red, que incluyan desvío de llamada, o, si lo hace se debería deshabilitar el uso de tales características para evitar las debilidades asociadas al desvío de llamadas. El proceso de re-llamada debería asegurar que se ha efectuado una desconexión real del lado de la organización. En otro caso, el usuario remoto podría mantener la línea abierta entendiendo que se ha producido la verificación de la re-llamada. Los procedimientos y los controles de re-llamada deberían ser rigurosamente probados para evitar esta posibilidad. La autenticación del nodo puede servir como medio alternativo para la autenticación de grupos de usuarios en remoto cuando estén conectados a un ordenador compartido y seguro. Las técnicas criptográficas, basadas por ejemplo en certificados, pueden utilizarse para la autenticación del nodo. Esto forma parte de las diversas soluciones que ofrece la red privada virtual (VPN).
ISO/IEC 27002:2005 - 78 -
Se deberían implantar controles adicionales de autenticación para el acceso a redes inalámbricas. En particular, se necesita tener un cuidado especial en la selección de controles para redes inalámbricas debido a la existencia de mayores oportunidades para la interceptación inadvertida y la inserción en el tráfico de la red. Información adicional Las conexiones externas proporcionan una vía de acceso no autorizado a la información del negocio, por ejemplo el acceso a través de métodos de acceso telefónico. Existen diferentes tipos de métodos de autenticación, algunos de estos proporcionan un mayor nivel de protección que otros, por ejemplo los métodos basados en el uso de técnicas criptográficas pueden proporcionar una fuerte autenticación. Es importante determinar el nivel de protección requerido a partir de una evaluación del riesgo. Esto es necesario para la selección adecuada del método de autenticación. La posibilidad de conexión automática a un ordenador remoto podría proporcionar una vía de obtención de la autorización de acceso a una aplicación del negocio. Esto es especialmente importante si la conexión utiliza una red que está fuera del control y de la gestión de la seguridad de la organización. 11.4.3 Identificación de los equipos en las redes
Control La identificación automática de los equipos se debería considerar como un medio de autenticación de las conexiones provenientes de localizaciones y equipos específicos. Guía de implantación Se puede utilizar la identificación del equipo si es importante que la comunicación sea iniciada únicamente desde una posición o equipo específicos. Se puede utilizar un identificador dentro o anexo al equipo, para indicar si se permite a este equipo la conexión a la red. Estos identificadores deberían indicar claramente a que red se permite la conexión del equipo, si existe más de una red y en particular si estas redes tienen distinto grado de sensibilidad. Puede ser necesario considerar la protección física del equipo para mantener la seguridad del identificador del equipo. Información adicional Este control puede completarse con otras técnicas de autenticación de usuario del equipo (véase 11.4.2). Se puede aplicar la identificación del equipo adicionalmente a la identificación de usuario. 11.4.4 Diagnóstico remoto y protección de los puertos de configuración
Control Se debería controlar el acceso físico y lógico a los puertos de diagnóstico y de configuración. Guía de implantación Los posibles controles para el acceso al diagnóstico y a la configuración de los puertos incluye el uso de un bloqueo y de un procedimiento de apoyo para el control del acceso físico al puerto. Un ejemplo de procedimiento de apoyo es el asegurar que el diagnóstico y la configuración de los puertos es únicamente accesible a través de un acuerdo entre el gestor del servicio de cálculo y el personal de soporte del hardware/software que requiere el acceso. Deberían desabilitarse o retirarse los puertos, los servicios y los dispositivos similares instalados en un ordenador o dispositivo en red, que no se requieren específicamente para una funcionalidad del negocio. Información adicional Muchos sistemas de ordenadores, de red y de comunicaciones están instalados a través de un diagnóstico remoto o a través de una configuración para su uso por ingenieros de mantenimiento. Si el diagnóstico de los puertos está desprotegido, proporciona una vía de acceso no autorizado. 11.4.5 Segregación de las redes
Control Los grupos de servicios de información, usuarios y sistemas de información deberían estar segregados en redes.
- 79 - ISO/IEC 27002:2005
Guía de implantación Un método de controlar la seguridad de redes grandes es dividirlas en dominios de red lógica, por ejemplo, en dominios de red interna y dominios de red externa de una organización, cada dominio protegido por un perímetro de seguridad definido. Se puede aplicar un conjunto escalonado de controles en los diferentes dominios de la red lógica para una posterior segregación de entornos de seguridad de red, por ejemplo sistemas públicamente accesibles, redes internas, y activos críticos. Los dominios deberían estar definidos en base a una evaluación del riesgo y de los diferentes requisitos de seguridad dentro de cada dominio. Un perímetro de red de este tipo puede implantarse mediante la instalación de pasarelas seguras entre dos redes para ser interconectadas con el control de acceso y el flujo de información entre los dos dominios. Esta pasarela debería estar configurada para filtrar el tráfico entre estos dominios (véase 11.4.6 y 11.4.7) y para bloquear el acceso no autorizado de acuerdo con la política de control de acceso de la organización (véase 11.1). Un ejemplo de este tipo de pasarela es a lo que comúnmente se conoce como un cortafuegos. Otro método de segregación en dominios lógicos separados para restringir el acceso a la red, es el uso de redes privadas virtuales para grupos de usuarios dentro de la organización. Las redes también pueden ser segregadas usando la funcionalidad de los dispositivos de red, por ejemplo, la conexión IP (Internet Protocol). Los dominios separados pueden ser implantados mediante el control de los flujos de datos usando capacidades de direccionamiento/conexión, tales como listas de control de acceso. Los criterios de segregación de las redes en dominios deberían estar basados en la política de control de acceso y los requisitos de acceso (véase 10.1), y también tener en cuenta el coste relativo y el impacto en el comportamiento, de incorporar el direccionamiento de red adecuado o la tecnología de pasarelas (véase 11.4.6 y 11.4.7). Además, la segregación de las redes debería estar basada en el valor y la clasificación de la información almacenada o procesada en la red, los niveles de confianza, o las líneas de negocio, para reducir el impacto global de una interrupción del servicio. Se debería considerar la segregación de las redes inalámbricas en redes internas y privadas. Cuando los perímetros de las redes inalámbricas no están bien definidos, se debería llevar a cabo una evaluación del riesgo para identificar los controles (por ejemplo una fuerte autenticación, métodos criptográficos y selección de la frecuencia) para mantener la segregación de la red. Información adicional Las redes están aumentando su extensión fuera de las fronteras tradicionales de la organización, dado que los socios del negocio se organizan de tal manera que pueden requerir la interconexión o la compartición de la información procesada y los servicios de red. Tales extensiones pueden incrementar el riesgo de acceso no autorizado a los sistemas de información existentes que usan la red, algunos de los cuales pueden requerir la protección de otros usuarios de red debido a su sensibilidad o criticidad. 11.4.6 Control de la conexión a la red
Control En redes compartidas, especialmente en aquellas que traspasen las fronteras de la organización, debería restringirse la capacidad de los usuarios para conectarse a la red, esto debería hacerse de acuerdo a la política de control de acceso y a los requisitos de las aplicaciones empresariales (véase 11.1). Guía de implantación Los derechos de acceso a la red de los usuarios deberían ser mantenidos y actualizados según sea requerido por la política de control de acceso (véase 11.1.1). Información adicional La capacidad de conexión de los usuarios puede ser restringida a través de pasarelas de red que filtran el tráfico a través de tablas o reglas predefinidas. Ejemplos de aplicaciones a las que dichas restricciones deberían aplicarse son: a) mensajería, por ejemplo correo electrónico;
ISO/IEC 27002:2005 - 80 -
b) transferencia de ficheros; c) acceso interactivo; d) acceso a las aplicaciones. Se deberían considerar los derechos de acceso a las redes a ciertas horas del día o en ciertas fechas. Otra información: La política de control de acceso para redes compartidas puede requerir la incorporación de controles para restringir la capacidad de conexión de los usuarios, especialmente para redes que se extienden por fuera de las fronteras de la organización. 11.4.7 Control de encaminamiento (routing) de red
Control Se deberían implantar controles de encaminamiento (routing) de redes para asegurar que las conexiones de los ordenadores y los flujos de información no violan la política de control de acceso de las aplicaciones empresariales. Guía de implantación Los controles de direccionamiento deberían estar basados en mecanismos de comprobación de direcciones de origen y destino verdaderas. Las pasarelas de seguridad pueden usarse para validar las direcciones de origen y destino y las direcciones de destino a puntos de control de redes internas y externas, si se emplean tecnologías proxy y/o direcciones de red. Los implantadores deberían ser conscientes de las fortalezas y deficiencias de cualquier mecanismo utilizado. Los requisitos de control de direccionamiento de red deberían estar basados en la política de control de acceso (véase 11.1). Información adicional Las redes compartidas, especialmente aquellas que se extienden fuera de las fronteras de la organización, pueden requerir controles de direccionamiento adicionales. Esto se aplica en particular cuando las redes se comparten con terceros (que no son de la organización).
11.5 Control de acceso al sistema operativo
Objetivo: Prevenir el acceso no autorizado a los sistemas operativos. Se deberían utilizar recursos de seguridad para restringir el acceso de usuarios autorizados a los sistemas operativos. Los recursos deberían ser capaces de lo siguiente: a) autenticar a los usuarios autorizados, de acuerdo a una política de control de acceso definida; b) registrar los intentos exitosos y fallidos de autenticación del sistema; c) registrar el uso de sistemas especiales de privilegios; d) disparar alarmas cuando se infrinjan las políticas de seguridad; e) proporcionar los medios adecuados de autenticación; f) cuando sea apropiado, restringir el tiempo de conexión a los usuarios.
- 81 - ISO/IEC 27002:2005
11.5.1 Procedimientos seguros de inicio de sesión
Control El acceso a los sistemas operativos se debería controlar por medio de un procedimiento seguro de inicio de sesión. Guía de implantación Se debería diseñar un procedimiento de entrada en el sistema operativo para minimizar las posibilidades de acceso no autorizado. El procedimiento de entrada debería revelar la información mínima del sistema, para evitar el proporcionar esta a un usuario no autorizado a través de una ayuda innecesaria. Un buen procedimiento de entrada debería: a) no mostrar identificadores del sistema o de la aplicación hasta que se hayan completado de manera satisfactoria los
procesos de entrada; b) mostrar un aviso general de que únicamente deberían acceder al ordenador los usuarios autorizados; c) no proporcionar mensajes de ayuda durante el proceso de entrada que pudieran ayudar a un usuario no autorizado; d) validar la información de entrada únicamente cuando se hayan completado todos los datos de entrada. Si ocurre
alguna condición de error, el sistema no debería indicar la parte del dato que es correcta o incorrecta; e) limitar el número de intentos de entrada no satisfactorios que se permiten, por ejemplo a 3 intentos, y considerar:
1) el registro de los intentos satisfactorios e insatisfactorios; 2) forzar un tiempo de retraso antes de permitir los siguientes intentos de entrada o rechazar cualquier intento sin
autorización específica; 3) desconectar las conexiones a los enlaces de datos; 4) enviar un mensaje de alarma a la consola del sistema si se ha alcanzado el número máximo de intentos de
entrada; 5) establecer el número de intentos de contraseña en función de la longitud mínima de las contraseñas y el valor del
sistema que se protege; f) limitar el tiempo máximo y mínimo permitido para el procedimiento de entrada. Si se excede, el sistema debería
finalizar la entrada; g) mostrar la siguiente información al completarse satisfactoriamente la entrada:
1) la fecha y la hora de la entrada satisfactoria anterior;
2) detalles de cualquier intento no satisfactorio desde la última entrada satisfactoria; h) no mostrar la contraseña que se está introduciendo, o considerar la posibilidad de ocultar los caracteres de la
contraseña mediante símbolos; i) no transmitir las contraseñas en texto limpio a través de la red. Información adicional Si las contraseñas se transmiten en texto limpio durante la sesión de apertura de la red, estas pueden ser capturadas por un programa husmeador �sniffer� de la red.
ISO/IEC 27002:2005 - 82 -
11.5.2 Identificación y autenticación de usuario
Control Todos los usuarios deberían tener un identificador único (ID de usuario), para su uso personal y exclusivo, y se debería elegir una técnica adecuada de autenticación para confirmar la identidad solicitada del usuario. Guía de implantación Este control debería aplicarse para todos los tipos de usuarios (incluyendo personal de soporte técnico, operarios, administradores de red, programadores del sistema y administradores de base de datos). Los identificadores de usuario (ID) deberían ser utilizados para el seguimiento de las actividades de responsabilidad individual. Las actividades habituales de usuario no deberían ser desempeñadas a través de cuentas privilegiadas. En circunstancias excepcionales, donde exista un claro beneficio para el negocio, se puede hacer uso de un identificador de usuario (ID) compartido para un grupo de usuarios de un puesto de trabajo específico. Para tales casos, la aprobación de la Dirección debería estar documentada. Pueden requerirse controles adicionales para mantener la responsabilidad. Únicamente deberían permitirse identificadores de usuario (IDs) genéricos para ser utilizados por un individuo, en el caso de que las funciones accesibles o las acciones llevadas a cabo por ese identificador no necesiten ser trazables (por ejemplo, acceso de sólo lectura), o cuando están implantados otros controles (por ejemplo, si la contraseña para un ID genérico sólo se utiliza por una persona al mismo tiempo y se registra tal caso). Cuando se requiera una fuerte autenticación y verificación de la identidad, se deberían utilizar métodos alternativos de autenticación para las contraseñas, tales como medios criptográficos, tarjetas inteligentes, dispositivos o medios biométricos. Información adicional Las contraseñas es un camino muy habitual de proporcionar identificación y autenticación, están basadas en un secreto que sólo el usuario conoce. Esto mismo puede conseguirse mediante medios criptográficos y protocolos de autenticación. La fortaleza de la identificación y autenticación del usuario debería ser proporcional a la sensibilidad de la información a la que se accede. Objetos tales como dispositivos de memoria o tarjetas inteligentes que los usuarios poseen, pueden también utilizarse para la identificación y autenticación. Las tecnologías biométricas de autenticación que utilizan características o atributos únicos de un individuo pueden ser utilizadas para autenticar la identidad de la persona. Con una combinación, que una tecnologías y mecanismos de seguridad, se conseguirá una autenticación más fuerte. 11.5.3 Sistema de gestión de contraseñas
Control Los sistemas para la gestión de contraseñas deberían ser interactivos y establecer contraseñas de calidad. Guía de implantación Un sistema de gestión de contraseñas debería: a) forzar el uso de los identificadores de usuario (IDs) individuales y de las contraseñas para mantener la
responsabilidad; b) permitir a los usuarios el seleccionar y cambiar sus propias contraseñas e incluir un procedimiento de confirmación
que tenga en cuenta los errores de entrada; c) forzar la elección de contraseñas de calidad (véase 11.3.1); d) forzar el cambio de contraseñas (véase 11.3.1); e) forzar a los usuarios el cambio de las contraseñas provisionales después de la primera entrada (véase 11.2.3);
- 83 - ISO/IEC 27002:2005
f) mantener un registro de las contraseñas de usuarios anteriores y prevenir su reutilización; g) no mostrar las contraseñas en la pantalla cuando se están introduciendo; h) almacenar los ficheros de contraseñas de manera separada de los datos de la aplicación del sistema; i) almacenar y transmitir las contraseñas de forma protegida (por ejemplo: cifradas o codificadas). Información adicional Las contraseñas son uno de los medios principales de validación de la autorización de un usuario para acceder a un servicio de ordenadores. Algunas aplicaciones requieren que las contraseñas de usuario sean asignadas por una autoridad independiente; en tales casos, los puntos b), d) y e) de las anteriores directrices no son de aplicación. En muchos casos, las contraseñas se seleccionan y mantienen por los usuarios. Véase el apartado 11.3.1 como guía para el uso de las contraseñas. 11.5.4 Uso de los recursos del sistema
Control Se debería restringir y controlar de una manera rigurosa el uso de programas y utilidades que puedan ser capaces de invalidar los controles del sistema y de la aplicación. Guía de implantación Se deberían considerar las siguientes directrices para el uso del sistema: a) el uso de procedimientos de identificación, autenticación y autorización para los recursos del sistema; b) la segregación de los recursos del sistema para las aplicaciones de software; c) la limitación, al mínimo número viable de usuarios, del uso de las utilidades del sistema (véase también 11.2.2); d) la autorización para el uso ad-hoc de los recursos de los sistemas; e) la limitación de la disponibilidad de los recursos del sistema, por ejemplo para la duración de un cambio autorizado; f) el registro de todos los usos de los recursos del sistema; g) definir y documentar los niveles de autorización para los recursos del sistema; h) retirar o deshabilitar todos los recursos y el software del sistema basados en software innecesario; i) no dejar disponibles los recursos del sistema a los usuarios que tienen acceso a las aplicaciones de los sistemas
donde se requiere segregación de tareas. Información adicional Muchas instalaciones de ordenadores tienen uno o más programas del sistema que pueden ser capaces de invalidar los controles del sistema y de la aplicación. 11.5.5 Desconexión automática de sesión
Control Las sesiones inactivas deberían cerrarse después de un periodo de inactividad definido.
ISO/IEC 27002:2005 - 84 -
Guía de implantación Un recurso de tiempo de espera debería limpiar la pantalla de la sesión y también, posiblemente después, cerrar tanto la aplicación como la sesión en red después de un periodo de inactividad definido. El retardo del tiempo de espera debería ser reflejo de los riesgos de seguridad del área, de la clasificación de la información que está siendo manejada y de la aplicación que está en uso, así como de los riesgos relativos a los usuarios del equipo. Para algunos sistemas puede proporcionarse un recurso de tiempo de espera limitado, el cual limpia la pantalla y previene el acceso no autorizado, pero no cierra la aplicación o sesión en red. Información adicional Este control es particularmente importante en posiciones de alto riesgo, que incluyen áreas públicas o externas fuera de la gestión de la seguridad de la organización. Las sesiones deberían cerrarse para prevenir el acceso por personas no autorizadas y denegar los ataques al servicio. 11.5.6 Limitación del tiempo de conexión
Control Para proporcionar seguridad adicional a las aplicaciones de alto riesgo, se deberían utilizar restricciones en los tiempos de conexión. Guía de implantación Se deberían considerar los controles de tiempo de conexión para las aplicaciones sensibles, especialmente en posiciones de alto riesgo, por ejemplo áreas públicas o externas que están fuera de la gestión de la seguridad de la organización. Ejemplos de tales restricciones incluyen: a) el uso de espacios de tiempo predeterminados, por ejemplo, para transmisiones de ficheros por lotes, o sesiones
regulares interactivas de corta duración; b) restringir los tiempos de conexión a horas normales de oficina si no hay requisitos de funcionamiento en horas
extras o ampliación de horas; c) considerar la re-autenticación a intervalos de tiempo. Información adicional El limitar el periodo durante el que se permiten las conexiones a los servicios de ordenadores, reduce las oportunidades de acceso no autorizado. La limitación de la duración de las sesiones activas previene el que los usuarios mantengan las sesiones abiertas para evitar la re-autenticación.
11.6 Control de acceso a las aplicaciones y a la información
Objetivo Prevenir el acceso no autorizado a la información que contienen las aplicaciones. Se deberían utilizar recursos de seguridad para restringir el acceso a y dentro de los sistemas de aplicación. El acceso lógico a las aplicaciones de software y a la información debería estar restringido a los usuarios autorizados. Los sistemas de aplicación deberían: a) controlar el acceso del usuario a la información y a las funciones del sistema de aplicación, de acuerdo con una
política de control de acceso definida; b) proporcionar protección contra el acceso no autorizado a través de cualquier recurso, contra el software del sistema
operativo, y el software malicioso que es capaz de invalidar o evitar los controles del sistema o de la aplicación; c) no comprometer otros sistemas con los que se comparten recursos de información.
- 85 - ISO/IEC 27002:2005
11.6.1 Restricción del acceso a la información
Control Se debería restringir el acceso a la información y a las aplicaciones a los usuarios y al personal de soporte, de acuerdo con la política de control de acceso definida. Guía de implantación Las restricciones de acceso deberían estar basadas en requisitos individuales de aplicación del negocio. La política de control de acceso debería también ser consistente con la política de acceso organizativa (véase 11.1). Se debería considerar la aplicación de las siguientes directrices para dar apoyo a los requisitos de restricción de acceso: a) proporcionar menús de control de acceso para las funciones del sistema de aplicación; b) controlar los derechos de acceso de los usuarios, por ejemplo de lectura, de escritura, de borrado y de ejecución; c) controlar los derechos de acceso de otras aplicaciones; d) asegurar que las salidas de los sistemas de aplicación que manejan información sensible contienen únicamente la
información relevante para el uso de la salida y son enviadas sólo a los terminales y posiciones autorizadas; esto debería incluir revisiones periódicas de tales salidas para asegurar que se elimina la información redundante.
11.6.2 Aislamiento de sistemas sensibles
Control Los sistemas sensibles deberían tener un entorno dedicado (aislado) de ordenadores. Guía de implantación Se deberían considerar los siguientes puntos para el aislamiento del sistema sensible: a) la sensibilidad de un sistema de aplicación debería estar explícitamente definida y documentada por el propietario de
la aplicación (véase 7.1.2); b) cuando una aplicación está ejecutándose en un entorno compartido, deberían identificarse y aceptarse por parte del
propietario de la aplicación sensible, los sistemas de aplicación con los que se comparten recursos así como los riesgos correspondientes.
Información adicional Algunos sistemas de aplicación son lo suficientemente sensibles ante una posible pérdida que requieren un mantenimiento especial. La sensibilidad puede indicar que el sistema de aplicación: a) debería ejecutarse en un ordenador dedicado; o b) deberían compartir recursos únicamente con sistemas de aplicación de confianza. El aislamiento podría conseguirse utilizando métodos físicos o lógicos (véase 11.4.5).
11.7 Ordenadores portátiles y teletrabajo
Objetivo: Garantizar la seguridad de la información cuando se utilizan ordenadores portátiles y servicios de teletrabajo. La protección requerida debería ser acorde con los riesgos específicos derivados de la forma de trabajo. Cuando se utilizan ordenadores portátiles, deberían considerarse los riesgos del trabajo en un entorno no protegido, y aplicar la protección adecuada. En el caso del teletrabajo, la organización debería aplicar una protección al lugar desde el que se realiza el teletrabajo y asegurarse de que han sido implantadas las disposiciones adecuadas para esta forma de trabajo.
ISO/IEC 27002:2005 - 86 -
11.7.1 Ordenadores portátiles y comunicaciones móviles
Control Se debería implantar una política formal y se deberían adoptar las medidas de seguridad adecuadas para la protección contra los riesgos de la utilización de ordenadores portátiles y comunicaciones móviles. Guía de implantación Cuando se utilicen ordenadores y dispositivos de comunicación portátiles, por ejemplo agendas, ordenadores de mano, portátiles, tarjetas inteligentes, y teléfonos móviles, se debería tener un cuidado especial para asegurar que no se compromete la información del negocio. La política de ordenadores móviles debería tener en cuenta los riesgos que conlleva el trabajar con el equipo móvil en entornos desprotegidos. La política de ordenadores móviles debería incluir los requisitos para la protección física, los controles de acceso, las técnicas criptográficas, las copias de seguridad y la protección antivirus. Esta política también debería incluir reglas y consejos para conectar los dispositivos móviles a las redes, así como una guía para el uso de estos dispositivos en lugares públicos. Se debería tener cuidado con el uso de dispositivos móviles en zonas públicas, salas de reunión y otras áreas desprotegidas fuera de las instalaciones de la organización. Se debería implantar algún tipo de protección para evitar el acceso no autorizado o la revelación de la información almacenada y procesada por estos recursos. Por ejemplo utilizando técnicas criptográficas (véase 12.3). Los usuarios de ordenadores móviles en zonas públicas deberían tener cuidado para evitar el riesgo de miradas por personas no autorizadas. Los procedimientos contra el software malicioso deberían implantarse y mantenerse al día (véase 10.4). Se deberían hacer regularmente copias de seguridad de la información crítica para el negocio. Los equipos deberían estar disponibles para posibilitar el copiado fácil y rápido de la información. Se debería dar a estas copias la protección adecuada contra, por ejemplo, el robo o la pérdida de la información. Se debería dar la protección adecuada al uso de dispositivos móviles conectados a las redes. El acceso remoto a la información del negocio a través de redes públicas utilizando dispositivos móviles, debería tener lugar únicamente después de una identificación y autenticación satisfactorias, y a través de la implantación de los mecanismos de control adecuados (véase 11.4). Los dispositivos móviles también deberían estar físicamente protegidos contra el robo, especialmente cuando se dejan, por ejemplo en coches y otras formas de transporte, habitaciones de hoteles, centros de conferencia y salas de reunión. Se debería establecer un procedimiento específico, que tuviera en cuenta, los requisitos legales, los requisitos de los seguros y otros requisitos de seguridad de la organización, para los casos de robo o pérdida de los dispositivos móviles. Los equipos que contienen información importante, sensible y/o crítica para el negocio, no se deberían dejar desatendidos y, cuando sea posible, se deberían tener cerrados con llave, o se deberían utilizar cierres especiales para proteger el equipo (véase 9.2.5). Se debería proporcionar formación al personal que utiliza ordenadores portátiles para aumentar su concienciación respecto a los riesgos adicionales de esta forma de trabajo y de los controles que se deberían implantar. Información adicional Las conexiones de dispositivos móviles a redes inalámbricas son similares a otros tipos de conexión a redes, pero tienen diferencias importantes que deberían tenerse en cuenta cuando se identifican los controles. Diferencias típicas son: a) algunos protocolos de seguridad inalámbrica son inmaduros y tienen debilidades; b) de la información almacenada en ordenadores móviles puede no hacerse una copia de seguridad debido a la
limitación del ancho de banda y/o porqué el equipo móvil puede no estar conectado en el momento en que se programan las copias de seguridad.
- 87 - ISO/IEC 27002:2005
11.7.2 Teletrabajo
Control Se debería redactar e implantar, una política de actividades de teletrabajo, así como los planes y procedimientos de operación correspondientes. Guía de implantación Las organizaciones deberían autorizar únicamente actividades de teletrabajo si quedan satisfechas las disposiciones de seguridad y los controles implantados, y se cumple con la política de seguridad de la organización. Se debería implantar la protección adecuada a las actividades de teletrabajo, contra por ejemplo el robo del equipo y de la información, la revelación no autorizada de la información, el acceso remoto no autorizado a los sistemas internos de la organización o contra el mal uso de los recursos. Las actividades de teletrabajo deberían estar autorizadas y controladas por la Dirección, y se debería garantizar que se han implantado las disposiciones adecuadas para esta forma de trabajo. Se deberían considerar los siguientes aspectos: a) la existencia de una seguridad física en el lugar de teletrabajo, teniendo en cuenta 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 la que se va a acceder y transmitir a través del enlace de comunicación, así como la sensibilidad del sistema interno;
d) el intento de acceso no autorizado a la información o a los recursos por parte de otras personas del mismo
emplazamiento, por ejemplo: familia y amigos; e) el uso de redes domésticas y los requisitos o restricciones en la configuración de los servicios de la red inalámbrica; f) las políticas y procedimientos para prevenir las disputas relativas a los derechos de propiedad intelectual de lo
desarrollado por el propietario del equipo de manera privada; g) el acceso a la parte privada del propietario del equipo (para comprobar la seguridad de la máquina o durante una
investigación), que puede prevenirse a través de la legislación; h) acuerdos de licencia de software que pueden hacer que las organizaciones puedan ser responsables de emitir
licencias a clientes o para uso privado de empleados en puestos de trabajo, contratistas o terceros; i) los requisitos de protección antivirus y de cortafuegos. Las directrices y disposiciones a ser consideradas deberían incluir: a) la provisión del equipo adecuado y el mobiliario de almacenamiento para las actividades de teletrabajo, donde no se
permita el uso privado por parte del propietario del equipo que no está bajo el control de la organización; b) una definición del trabajo permitido, las horas de trabajo, la clasificación de la información que puede manejarse y
los sistemas y servicios a los que el teletrabajador está autorizado a acceder; c) la provisión de los equipos de comunicación adecuados, incluyendo los métodos para asegurar el acceso remoto; d) la seguridad física; e) las reglas y directrices para el acceso de la familia y los accesos de los visitantes al equipo y a la información;
ISO/IEC 27002:2005 - 88 -
f) la provisión de soporte y mantenimiento de hardware y software; g) la provisión de seguros; h) los procedimientos para las copias de seguridad y para la continuidad del negocio; i) auditoría y seguimiento de la seguridad; j) la revocación de la autorización y de los derechos de acceso, y la devolución del equipo cuando se terminan las
actividades de teletrabajo. Información adicional El teletrabajo utiliza tecnologías de comunicación para posibilitar al personal trabajar remotamente desde un lugar fijo fuera de sus organizaciones. 12 ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE LOS SISTEMAS DE INFORMACIÓN
12.1 Requisitos de seguridad de los sistemas de información
Objetivo: Garantizar que la seguridad está integrada en los sistemas de información. Los sistemas de información abarcan los sistemas operativos, la infraestructura, las aplicaciones empresariales, los productos disponibles en el mercado, los servicios y las aplicaciones desarrolladas por el usuario. Las fases de diseño y de implantación del sistema de información que da soporte a los procesos de negocio pueden resultar cruciales para la seguridad. Los requisitos de seguridad deberían ser identificados y acordados antes de desarrollar o implantar los sistemas de información. Durante la fase de requisitos de un proyecto, todos los requisitos de seguridad deberían identificarse, justificarse, acordarse y documentarse como parte de las necesidades globales del negocio dentro de un sistema de información. 12.1.1 Análisis y especificación de los requisitos de seguridad
Control En las declaraciones de los requisitos de negocio para los nuevos sistemas de información, o para mejoras de los sistemas de información ya existentes, se deberían especificar los requisitos de los controles de seguridad. Guía de implantación Las especificaciones de los requisitos de los controles deberían considerar la incorporación al sistema de información de controles automatizados, así como la posible necesidad de controles manuales de apoyo. Deberían realizarse consideraciones similares al evaluar los paquetes de software desarrollados o adquiridos para las aplicaciones empresariales. Los requisitos de seguridad y los controles deberían reflejar el valor empresarial de los activos de información afectados (véase 7.2), así como el posible daño empresarial que podría resultar de un fallo de seguridad o de la ausencia de la misma. Los requisitos del sistema en lo que respecta a la seguridad de la información y los procesos para implantar la seguridad deberían integrarse en las primeras fases de los proyectos de sistemas de información. Los controles introducidos en la fase de diseño resultan mucho más económicos a la hora de implantarlos y mantenerlos que aquellos que se incluyen durante o después de la implantación. Si los productos se adquieren, debería seguirse un proceso formal de pruebas y compra. Los contratos con el proveedor deberían abordar los requisitos de seguridad identificados. Si las funciones de seguridad de un producto propuesto no satisfacen los requisitos especificados, debería reconsiderarse el riesgo introducido y los controles asociados antes de adquirir el producto. Cuando se suministre una función adicional que provoque un riesgo de seguridad, dicha función debería desactivarse o bien debería revisarse la estructura de control propuesta para determinar si se puede obtener un beneficio de la ampliación de funciones.
- 89 - ISO/IEC 27002:2005
Información adicional Si se considera adecuado, por motivos de coste por ejemplo, la Dirección puede querer emplear productos evaluados y certificados de forma independiente. Para más información acerca de los criterios de evaluación de los productos de seguridad de TI, puede consultarse la Norma ISO/IEC 15408 u otras normas de evaluación o certificación, según resulte apropiado. La Norma ISO/IEC TR 13335-3 ofrece orientación acerca del uso de procesos de gestión de riesgos para identificar los requisitos de los controles de seguridad.
12.2 Tratamiento correcto de las aplicaciones
Objetivo: Evitar errores, pérdidas, modificaciones no autorizadas o usos indebidos de la información en las aplicaciones. Deberían diseñarse controles adecuados en las aplicaciones, incluyendo las desarrolladas por el usuario, para garantizar un correcto tratamiento. Estos controles deberían incluir la validación de los datos introducidos, el procesamiento interno y los datos resultantes. En los sistemas que procesen o afecten a información sensible, valiosa o crítica, puede ser necesario implantar controles adicionales. Dichos controles deberían determinarse en función de los requisitos de seguridad y de la evaluación de riesgos. 12.2.1 Validación de los datos de entrada
Control La introducción de datos en las aplicaciones debería validarse para garantizar que dichos datos son correctos y adecuados. Guía de implantación Deberían aplicarse controles a la introducción de transacciones empresariales, datos fijos (por ejemplo, nombres y direcciones, límites de crédito, números de referencia de clientes) y tablas de parámetros (por ejemplo, precios de venta, tipos de cambio de divisas, tipos fiscales). Deberían considerarse las siguientes directrices: a) introducción dual u otras comprobaciones para las entradas, como comprobación de la delimitación o limitación de
los campos a un ámbito específico de datos, con el fin de detectar los siguientes errores:
1) valores fuera del ámbito; 2) caracteres inválidos en los campos de datos; 3) falta de datos o datos incompletos; 4) sobrepasar los límites superiores o inferiores de volumen de datos; 5) control de datos no autorizado o incoherente;
b) revisión periódica del contenido de los campos clave o de los archivos de datos para confirmar su validez e integridad; c) inspección de las entradas de documentos impresos en papel para buscar cambios no autorizados (todos los cambios
a los documentos de entrada deberían recibir autorización); d) procedimientos para reaccionar ante errores de validación; e) procedimientos para comprobar la verosimilitud de los datos introducidos;
ISO/IEC 27002:2005 - 90 -
f) definición de las responsabilidades de todo el personal que interviene en el proceso de introducción de datos; g) creación de un registro de las actividades relacionadas con el proceso de introducción de datos (véase 10.10.1). Información adicional Puede considerarse la realización de un examen automático y una validación de los datos introducidos, cuando resulte aplicable, para reducir el riesgo de errores y evitar ataques estándar, incluyendo el desbordamiento de la memoria intermedia (búfer) y la inyección de código. 12.2.2 Control del procesamiento interno
Control Para detectar cualquier corrupción de la información debida a errores de procesamiento o actos intencionados, se deberían incorporar comprobaciones de validación en las aplicaciones. Guía de implantación El diseño y la implementación de las aplicaciones deberían garantizar que se minimizan los riesgos de fallos en el procesamiento que provoquen una pérdida de la integridad. Algunas áreas específicas que se deberían considerar son: a) el uso de las funciones de añadir, modificar y borrar para implantar los cambios en los datos; b) los procedimientos para evitar que los programas funcionen en orden incorrecto o que funcionen después de un error
del procesamiento anterior (véase 10.1.1); c) el uso de programas adecuados para recuperarse de los fallos con el fin de garantizar un procesamiento adecuado de
los datos; d) la protección contra ataques que utilicen el desbordamiento o la saturación de la memoria intermedia (búfer). Debería prepararse una lista de comprobación adecuada, las actividades deberían documentarse y los resultados deberían guardarse de forma segura. Algunas de las comprobaciones que podrían incorporarse son las siguientes: a) controles de sesión o de lote para cuadrar el saldo de los archivos de datos después de actualizar las transacciones; b) controles del saldo para comparar los saldos iniciales con los anteriores saldos de cierre; es decir:
1) controles entre ejecuciones (run to run); 2) actualizaciones totales de archivos; 3) controles entre programas;
c) validación de los datos de entrada generados por el sistema (véase 12.2.1); d) comprobaciones de la integridad, la autenticidad o cualquier otra característica de seguridad de los datos o del
software descargado o cargado entre el ordenador central y un ordenador remoto; e) dispersión total de los registros y archivos; f) comprobaciones para garantizar que los programas de la aplicación se activan en el momento adecuado; g) comprobaciones para garantizar que los programas se ejecutan en el orden correcto y finalizan en caso de error y
que el procesamiento posterior se interrumpe hasta que se resuelve el problema; g) creación de un registro de las actividades relacionadas con el procesamiento (véase 10.10.1).
- 91 - ISO/IEC 27002:2005
Información adicional Los datos correctamente introducidos pueden verse corrompidos por errores de hardware o de procesamiento o por actos intencionados. Las comprobaciones de validación requeridas dependerán de la naturaleza de la aplicación y del efecto que tiene cualquier corrupción de los datos sobre el negocio. 12.2.3 Integridad de los mensajes
Control Se deberían identificar los requisitos para garantizar la autenticidad y para proteger la integridad de los mensajes en las aplicaciones y se deberían identificar e implantar los controles adecuados. Guía de implantación Debería llevarse a cabo una evaluación de los riesgos de seguridad para determinar si se requiere integridad en los mensajes y para identificar la forma más adecuada para la implantación. Información adicional Pueden emplearse técnicas criptográficas (véase 12.3) como una forma adecuada de implantar la autenticación de los mensajes. 12.2.4 Validación de los datos de salida
Control Los datos de salida de una aplicación se deberían validar para garantizar que el tratamiento de la información almacenada es correcto y adecuado a las circunstancias. Guía de implantación La validación de las salidas puede incluir lo siguiente: a) comprobaciones de la verosimilitud para determinar si los datos resultantes son razonables; b) cuentas de control de conciliación para garantizar el procesamiento de todos los datos; c) presentación de la información suficiente para el lector o para el sistema de tratamiento posterior a fin de determinar
la exactitud, la integridad, la precisión y la clasificación de la información; d) procedimientos para reaccionar ante los errores de validación de salida de datos; e) definición de las responsabilidades de todo el personal que interviene en el proceso de salida de datos; f) creación de un registro de actividades del proceso de validación de salida de datos. Información adicional Normalmente, los sistemas y las aplicaciones se construyen considerando que si se lleva a cabo una validación, una verificación y una comprobación adecuadas, el resultado siempre será correcto. No obstante, esta suposición no siempre resulta válida; es decir, los sistemas comprobados pueden seguir generando un resultado incorrecto en determinadas circunstancias.
12.3 Controles criptográficos
Objetivo: Proteger la confidencialidad, la autenticidad o la integridad de la información por medios criptográficos. Debería desarrollarse una política acerca del uso de controles criptográficos. Debería existir una gestión de las claves que de soporte al uso de técnicas criptográficas.
ISO/IEC 27002:2005 - 92 -
12.3.1 Política de uso de los controles criptográficos
Control Se debería formular e implantar una política para el uso de los controles criptográficos para proteger la información. Guía de implantación Al desarrollar una política criptográfica, debería tenerse en cuenta lo siguiente: a) el enfoque de la Dirección con respecto al uso de controles criptográficos en toda la organización, incluyendo los
principios generales en base a los cuales debería protegerse la información empresarial (véase 5.1.1); b) tomando como base la evaluación de los riesgos, debería identificarse el nivel de protección necesario, teniendo en
cuenta el tipo, la fortaleza y la calidad del algoritmo de cifrado requerido; c) el uso del cifrado para proteger la información sensible transportada a través de dispositivos móviles o extraíbles o a
través de líneas de comunicación; d) el enfoque de la gestión de las claves, incluyendo los métodos para ocuparse de la protección de las claves
criptográficas y la recuperación de la información cifrada en caso de pérdida, vulneración o daño de las claves; e) las funciones y responsabilidades; es decir, quién será responsable de:
1) la implantación de la política; 2) la gestión de las claves, incluyendo la generación de las mismas (véase 12.3.2).
f) las normas que deberían adoptarse para la implantación efectiva en toda la organización (qué solución se utilizará
para cada proceso de negocio); g) el impacto del uso de información cifrada en los controles que se basan en la inspección del contenido (por ejemplo
la detección de virus). Al implantar la política criptográfica de la organización, deberían tenerse en cuenta las normativas y restricciones nacionales que puedan resultar aplicables al uso de técnicas criptográficas en las distintas partes del mundo, así como a las cuestiones relativas al flujo transfronterizo de información cifrada (véase 15.1.6). Los controles criptográficos pueden utilizarse para alcanzar distintos objetivos de seguridad, por ejemplo: a) confidencialidad: uso del cifrado de la información para proteger información sensible o crítica, tanto si ésta se
almacena como si se transmite; b) integridad/autenticidad: uso de firmas digitales o códigos de autenticación de mensajes para proteger la autenticidad
y la integridad de la información sensible o crítica que se almacene o se transmita; c) no repudio: uso de técnicas criptográficas para obtener pruebas de la existencia o inexistencia de un evento o una acción. Información adicional La toma de una decisión en cuanto a si una solución criptográfica resulta adecuada debería considerarse como parte del proceso general de evaluación de riesgos y selección de controles. En ese caso, esta evaluación podría utilizarse para determinar si un control criptográfico es adecuado, qué tipo de control debería aplicarse, para qué fin y en qué procesos de negocio. La política sobre el uso de controles criptográficos resulta necesaria para maximizar los beneficios y minimizar los riesgos de utilizar técnicas criptográficas, así como para evitar un uso inadecuado o incorrecto. Si se utilizan firmas digitales, debería tenerse en cuenta cualquier legislación aplicable, especialmente la legislación que describa las condiciones en las que una firma digital resulta legalmente vinculante (véase 15.1).
- 93 - ISO/IEC 27002:2005
Debería consultarse con un especialista para identificar el nivel apropiado de protección y para definir las especificaciones adecuadas que ofrecerán la protección requerida y darán apoyo a la implantación de un sistema seguro de gestión de claves (véase 12.3.2). El Subcomité ISO/IEC JTC1 SC27 ha desarrollado varias normas relativas a los controles criptográficos. También puede encontrarse más información en la norma IEEE1363 del IEEE y en el documento de la OCDE "Directrices sobre criptografía. 12.3.2 Gestión de claves
Control Debería implantarse un sistema de gestión de claves para dar soporte al uso de técnicas criptográficas por parte de la organización. Guía de implantación Todas las claves criptográficas deberían estar protegidas contra la modificación, la pérdida y la destrucción de las mismas. Además, las claves secretas y privadas necesitan protección contra una revelación no autorizada de las mismas. Los equipos utilizados para generar, almacenar y archivar claves deberían contar con protección física. El sistema de gestión de claves debería basarse en un conjunto consensuado de normas, procedimientos y métodos seguros para: a) generar claves para distintos sistemas criptográficos y diferentes aplicaciones; b) generar y obtener certificados de clave pública; c) distribuir las claves a los usuarios previstos, incluyendo la forma en que dichas claves deberían activarse cuando se
reciban; d) almacenar claves, incluyendo la forma en que los usuarios autorizados pueden acceder a las mismas; e) cambiar o actualizar las claves, incluyendo las normas relativas a cuándo y cómo deberían cambiarse las claves; f) actuar ante las claves vulneradas; g) revocar claves, incluyendo cómo deberían retirarse o desactivarse las claves, por ejemplo cuando éstas han sido
vulneradas o cuando un usuario deja una organización (en cuyo caso, las claves también deberían archivarse); h) recuperar claves perdidas o corruptas como parte de la gestión de la continuidad del negocio, por ejemplo para
recuperar información cifrada; i) archivar claves, por ejemplo para información archivada o en copia de seguridad; j) destruir claves; k) registrar y auditar las actividades relacionadas con la gestión de las claves. Para reducir la posibilidad de vulneración, deberían definirse fechas de activación y desactivación de las claves, de manera que éstas sólo puedan utilizarse durante un espacio limitado de tiempo. Dicho espacio de tiempo debería depender de las circunstancias en que se está usando el control criptográfico y del riesgo percibido. Además de una gestión segura de las claves secretas y privadas, también debería tenerse en cuenta la autenticidad de las claves públicas. Este proceso de autenticación puede llevarse a cabo utilizando certificados de clave pública, que suelen ser expedidos por una autoridad de certificación, que debería ser una organización reconocida que cuente con controles y procedimientos adecuados para ofrecer el grado de confianza necesario.
ISO/IEC 27002:2005 - 94 -
El contenido de los acuerdos o contratos de nivel de servicio con proveedores externos de servicios criptográficos como, por ejemplo, una autoridad de certificación, debería cubrir las cuestiones relativas a la responsabilidad, la fiabilidad de los servicios y los tiempos de respuesta para la prestación de servicios (véase 6.2.3). Información adicional La gestión de claves criptográficas resulta fundamental para un uso eficaz de las técnicas criptográficas. La Norma ISO/IEC 11770 ofrece más información acerca de la gestión de las claves. Hay dos tipos de técnicas criptográficas: a) técnicas de clave secreta, en las que dos o más partes comparten la misma clave, que se utiliza tanto para cifrar
como para descifrar la información. Esta clave debería mantenerse en secreto puesto que cualquier persona que tenga acceso a ella será capaz de descifrar toda la información que se cifre con dicha clave o de introducir información no autorizada utilizando dicha clave;
b) técnicas de clave pública, en las que cada usuario tiene dos claves: una pública (que puede revelar a cualquiera) y
una privada (que debería mantenerse en secreto). Las técnicas de clave pública pueden utilizarse para el cifrado y para generar firmas digitales (véanse también las Normas ISO/IEC 9796 e ISO/IEC 14888).
Existe el peligro de que se falsifique una firma digital sustituyendo la clave pública de un usuario. Este problema puede abordarse mediante el uso de un certificado de clave pública. También pueden emplearse técnicas criptográficas para proteger claves criptográficas. Puede que sea necesario considerar el uso de procedimientos para tratar los requisitos legales de acceso a las claves criptográficas; por ejemplo, puede que, en un juicio, deba presentarse información cifrada como prueba en un formato no cifrado.
12.4 Seguridad de los archivos del sistema
Objetivo: Garantizar la seguridad de los archivos de sistema. Debería controlarse el acceso a los archivos de sistema y a los códigos fuente de los programas, y los proyectos de TI y sus actividades de apoyo deberían llevarse a cabo de forma segura. Debería tenerse cuidado para evitar la exposición de datos sensibles en entornos de prueba. 12.4.1 Control del software en explotación
Control Deberían estar implantados procedimientos para controlar la instalación de software en los sistemas en producción o en explotación. Guía de implantación Para minimizar el riesgo de corromper los sistemas operativos, deberían tenerse en cuenta las siguientes directrices con el fin de controlar los cambios: a) la actualización del software operativo, de las aplicaciones y de las bibliotecas de programas sólo debería ser llevada
a cabo por administradores formados con la adecuada autorización de gestión (véase 12.4.3); b) los sistemas operativos sólo deberían manejar códigos ejecutables aprobados, y no códigos de desarrollo o
compiladores; c) el software de las aplicaciones y del sistema operativo sólo debería implantarse tras haber superado exhaustivas
pruebas, que deberían incluir pruebas de utilidad, seguridad, efectos en otros sistemas y facilidad de uso y deberían llevarse a cabo en sistemas independientes (véase también 10.1.4). Debería asegurarse que todas las bibliotecas fuente del programa correspondiente han sido actualizadas;
d) debería emplearse un sistema de control de la configuración para supervisar todo el software implantado, así como
la documentación del sistema;
- 95 - ISO/IEC 27002:2005
e) debería existir una estrategia de restauración antes de implantar los cambios; f) debería mantenerse un registro de auditoría de todas las actualizaciones de las bibliotecas de los programas operativos; g) deberían conservarse versiones anteriores del software de las aplicaciones como medida de contingencia; h) deberían archivarse versiones antiguas del software, junto con toda la información requerida y los parámetros,
procedimientos, detalles de configuración y software de apoyo durante todo el tiempo en que la información se conserve en el archivo.
El software adquirido a proveedores que se utilice en los sistemas operativos debería mantenerse en un nivel que cuente con la asistencia técnica del proveedor. Con el tiempo, los proveedores de software ya no ofrecerán asistencia para las versiones antiguas del software. La organización debería considerar los riesgos de utilizar software sin contar con asistencia técnica. La decisión de pasar a una nueva versión debería tener en cuenta los requisitos de negocio para los cambios y la seguridad de la versión; es decir, la introducción de nuevas funciones de seguridad o el número y la gravedad de los problemas de seguridad que afecten a esta versión. Deberían aplicarse parches de software cuando éstos puedan ayudar a eliminar o a reducir los puntos débiles de seguridad (véase 12.6.1). Sólo debería concederse acceso físico o lógico a los proveedores para que presten servicios de asistencia técnica cuando sea necesario y con una autorización por parte de la Dirección. Las actividades del proveedor deberían supervisarse. El software informático puede depender de software y de módulos adquiridos externamente, que deberían ser supervisados y controlados para evitar cambios no autorizados, ya que éstos podrían generar un punto débil de seguridad. Información adicional Los sistemas operativos sólo deberían actualizarse a una versión posterior cuando sea necesario hacerlo, por ejemplo, porque la versión actual del sistema operativo ya no satisface las necesidades del negocio. Estas actualizaciones no deberían efectuarse únicamente porque existe una versión más moderna del sistema operativo. Las nuevas versiones de los sistemas operativos pueden resultar menos seguras, menos estables y menos comprensibles que los sistemas actuales. 12.4.2 Protección de los datos de prueba del sistema
Control Los datos de prueba se deberían seleccionar cuidadosamente y deberían estar protegidos y controlados. Guía de implantación Debería evitarse el uso de bases de datos operativas que contengan información personal o cualquier información adicional sensible con fines de prueba. Si se utiliza información personal o que sea sensible en algún otro aspecto con fines de prueba, antes de utilizar dicha información, todos los detalles y contenidos sensibles deberían ser omitidos o modificados hasta que no resulten reconocibles. Cuando los datos operativos se utilicen con fines de prueba, deberían aplicarse las siguientes directrices para protegerlos: a) los procedimientos de control de acceso aplicables a los sistemas de aplicación operativos también deberían
aplicarse a la hora de probar los sistemas de aplicación; b) debería obtenerse una autorización independiente cada vez que se copie información operativa a un sistema de
aplicación de prueba; c) la información operativa debería borrarse del sistema de aplicación de prueba inmediatamente después de finalizar
la misma; d) la copia o el uso de información operativa deberían quedar registrados para que pueda servir como pista de de auditoría.
ISO/IEC 27002:2005 - 96 -
Información adicional Las pruebas de sistema y de aceptación suelen requerir un volumen considerable de datos de prueba lo más similares posible a los datos operativos. 12.4.3 Control de acceso al código fuente de los programas
Control Se debería restringir el acceso al código fuente de los programas. Guía de implantación El acceso al código fuente de los programas y a los elementos relacionados con él (diseños, especificaciones, planes de verificación y de validación) debería estar estrictamente controlado para evitar cambios involuntarios o para evitar la introducción de funciones no autorizadas. El código fuente de un programa puede archivarse en una memoria central controlada del propio código, preferiblemente en bibliotecas fuente del programa. En ese caso, para controlar el acceso a dichas bibliotecas fuente del programa con el fin de reducir la posibilidad de corrupción de los programas informáticos, deberían tenerse en cuenta las siguientes directrices, (véase el capítulo 11): a) cuando sea posible, las bibliotecas fuente de los programas no deberían mantenerse en los sistemas operativos; b) el código fuente y las bibliotecas fuente de los programas deberían gestionarse de acuerdo con procedimientos
establecidos; c) el personal de asistencia técnica no debería tener acceso sin restricciones a las bibliotecas fuente de los programas; d) la actualización de las bibliotecas fuente de los programas y los elementos relacionados con ellas, así como la
emisión de fuentes de programa a los programadores, sólo debería efectuarse tras haber recibido la autorización adecuada;
e) deberían guardarse listados de programas en un entorno seguro (véase 10.7.4). Información adicional Los programadores escriben el código fuente de un programa, que se compila (y vincula) para crear ejecutables. Algunos lenguajes de programación no distinguen formalmente entre códigos fuente y ejecutables, ya que estos últimos se crean en el momento en que se activan. Las Normas ISO 10007 e ISO/IEC 12207 ofrecen más información acerca de la gestión de la configuración y del proceso del ciclo de vida del software.
12.5 Seguridad en los procesos de desarrollo y soporte
Objetivo: Mantener la seguridad del software y de la información de las aplicaciones. Los entornos de proyecto y de asistencia técnica deberían estar estrictamente controlados. Los directores responsables de los sistemas de aplicación también deberían responsabilizarse de la seguridad del entorno del proyecto o de asistencia técnica. Deberían asegurarse de que todas las modificaciones del sistema propuestas se revisan para comprobar que no ponen en peligro la seguridad del sistema o del entorno operativo. 12.5.1 Procedimientos de control de cambios
Control La implantación de cambios debería controlarse mediante el uso de procedimientos formales de control de cambios.
- 97 - ISO/IEC 27002:2005
Guía de implantación Los procedimientos de control de cambios deberían estar documentados y aplicarse para minimizar la corrupción de los sistemas de información. La introducción de nuevos sistemas o de cambios importantes en los sistemas existentes debería seguir un proceso formal de documentación, especificación, pruebas, control de calidad e implantación controlada. Este proceso debería incluir una evaluación de riesgos, un análisis de los efectos de los cambios y una especificación de los controles de seguridad necesarios. Este proceso también debería garantizar que los procedimientos de seguridad y control existentes no se pongan en peligro, que los programadores de la asistencia técnica sólo tengan acceso a aquellas partes del sistema necesarias para su trabajo y que se obtenga un consentimiento y aprobación formales para cualquier cambio. Siempre que sea factible, los procedimientos de control de cambios operativos y de aplicación deberían ser integrados (véase 10.1.2). Los procedimientos de cambio deberían incluir lo siguiente: a) mantener un registro de los niveles de autorización acordados; b) garantizar que los cambios son enviados por usuarios autorizados; c) revisar los controles y los procedimientos de integridad para garantizar que no se verán vulnerados por los cambios; d) identificar todo el software, la información y las entidades de la base de datos así como el hardware que requieran
modificaciones; e) obtener una aprobación formal para las propuestas detalladas antes de que se inicien los trabajos; f) garantizar que los usuarios autorizados aceptan los cambios previamente a su implantación; g) garantizar que el conjunto de la documentación del sistema se actualiza al completar cada cambio y que la
documentación antigua se archiva o se elimina; h) mantener un control de la versión de todas las actualizaciones del software; i) mantener las pistas de auditoría de todas las solicitudes de cambio; j) garantizar que la documentación operativa (véase 10.1.1) y los procedimientos de usuario se modifican según sea
necesario para que sigan siendo adecuados; k) garantizar que la implantación de los cambios se realiza en el momento adecuado y que no perturba los procesos de
negocio implicados. Información adicional Los cambios en el software pueden afectar al entorno operativo. Las buenas prácticas incluyen la prueba del nuevo software en un entorno independiente de los entornos de producción y desarrollo (véase 10.1.4). Con ello, se consigue tener un control sobre el nuevo software y permite una protección adicional de la información operacional utilizada con fines de prueba. Esta fase debería incluir parches, paquetes de servicio (service packs) y otras actualizaciones. No deberían utilizarse las actualizaciones automáticas en los sistemas críticos, ya que algunas actualizaciones podrían hacer que ciertas aplicaciones críticas fallen (véase 12.6).
ISO/IEC 27002:2005 - 98 -
12.5.2 Revisión técnica de las aplicaciones tras efectuar cambios en el sistema operativo
Control Cuando se modifiquen los sistemas operativos, las aplicaciones empresariales críticas deberían ser revisadas y probadas para garantizar que no existen efectos adversos en las operaciones o en la seguridad de la organización. Guía de implantación Este proceso debería cubrir lo siguiente: a) revisar los procedimientos de integridad y de control de la aplicación para garantizar que no se han visto
comprometidos por los cambios del sistema operativo; b) asegurar que el plan y el presupuesto anuales de asistencia técnica cubrirán las revisiones y las pruebas del sistema
como consecuencia de los cambios del sistema operativo; c) asegurarse de que los cambios en el sistema operativo se notifican con tiempo suficiente para permitir la realización
de pruebas y revisiones adecuadas antes de su implantación; d) asegurar que se realizan los cambios oportunos en los planes de continuidad del negocio (véase el capítulo 14). La responsabilidad de supervisar las vulnerabilidades y las nuevas versiones de parches y correcciones de los proveedores debería recaer sobre un individuo o un grupo específicos (véase el apartado 12.6). 12.5.3 Restricciones a los cambios en los paquetes de software
Control Se deberían desaconsejar las modificaciones en los paquetes de software, limitándose a los cambios necesarios, y todos los cambios deberían ser objeto de un control riguroso. Guía de implantación Cuando sea posible y factible, los paquetes de software provenientes de proveedores deberían utilizarse sin ser modificados. Si un paquete de software necesita ser modificado, deberían tenerse en cuenta los siguientes puntos: a) el riesgo de que los controles integrados y los procesos de integridad se vean comprometidos; b) si se debería obtener el consentimiento del proveedor; c) la posibilidad de obtener los cambios requeridos del proveedor como actualizaciones estándar del programa; d) los efectos en caso de que la organización se responsabilice del mantenimiento futuro del software como resultado
de los cambios. Si es necesario realizar cambios, el software original debería conservarse y los cambios deberían aplicarse sobre una copia claramente identificada. Debería implantarse un proceso de gestión de las actualizaciones de software para garantizar que se instalan los parches y las actualizaciones de la aplicación aprobados más recientemente en todo el software autorizado (véase 12.6). Todos los cambios deberían probarse y documentarse en su totalidad de manera que puedan volver a aplicarse en caso necesario en futuras actualizaciones del software. Si así se requiere, las modificaciones deberían ser comprobadas y validadas por un organismo de evaluación independiente. 12.5.4 Fugas de información
Control Deberían evitarse las situaciones que permitan que se produzcan fugas de información.
- 99 - ISO/IEC 27002:2005
Guía de implantación Debería tenerse en consideración lo siguiente, para limitar el riesgo de fugas de información, por ejemplo, por el uso y la explotación de canales ocultos: a) el escaneo de los medios y comunicaciones de salida en busca de información oculta; b) el sistema de enmascaramiento y modulación del sistema y el comportamiento de las comunicaciones para reducir la
probabilidad de que un tercero pueda deducir información a partir de dicho comportamiento; c) utilización de sistemas y software considerados de elevada integridad, por ejemplo, con productos evaluados (véase
la Norma ISO/IEC 15408); d) supervisión periódica del personal y de las actividades del sistema, siempre que esté permitido por la legislación o
las normativas vigentes; e) supervisión del uso de recursos en los sistemas informáticos. Información adicional Los canales ocultos son vías que no han sido previstas para transmitir flujos de información pero que, no obstante, existen en un sistema o en una red. Por ejemplo, la manipulación de bits en los paquetes de protocolos de comunicaciones podría utilizarse como un método oculto de señalización. Debido a su naturaleza, el evitar la existencia de todos los canales ocultos posibles resultaría muy difícil si no imposible. No obstante, la explotación de dichos canales suele ser obra de un código troyano (véase 10.4.1). Por ello, al tomar medidas de protección contra los códigos troyanos se reduce el riesgo de explotación de canales ocultos. La prevención de accesos no autorizados a la red (11.4), así como las políticas y procedimientos que desincentivan el uso indebido de los servicios de información por parte del personal (15.1.5), ayudarían a obtener protección contra los canales ocultos. 12.5.5 Externalización del desarrollo de software
Control La externalización del desarrollo de software debería ser supervisada y controlada por la organización. Guía de implantación Si el desarrollo de software está externalizado, deberían tenerse en cuenta los siguientes puntos: a) contratos de licencia, propiedad del código y derechos de propiedad intelectual (véase 15.1.2); b) certificación de la calidad y la precisión del trabajo desempeñado; c) contratos de garantía bloqueada en caso de error por parte de terceros; d) derechos de acceso para auditar la calidad y la precisión del trabajo realizado; e) requisitos contractuales para funcionalidades de calidad y seguridad del código; f) pruebas antes de la instalación para detectar códigos maliciosos y troyanos.
12.6 Gestión de la vulnerabilidad técnica
Objetivo: Reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas publicadas. La gestión de la vulnerabilidad técnica debería implantarse de forma efectiva, sistemática y repetitiva y deberían adoptarse medidas que confirmen su efectividad. Estas consideraciones deberían incluir los sistemas operativos y cualquier otra aplicación que se esté usando.
ISO/IEC 27002:2005 - 100 -
12.6.1 Control de las vulnerabilidades técnicas
Control Se debería obtener la información adecuada acerca de las vulnerabilidades técnicas de los sistemas de información que están siendo utilizados, evaluar la exposición de la organización a dichas vulnerabilidades y adoptar las medidas adecuadas para afrontar el riesgo asociado. Guía de implantación Un requisito previo para la gestión efectiva de las vulnerabilidades técnicas es la elaboración de un inventario actual y completo de los activos (véase 7.1). La información específica que se requiere para dar soporte a la gestión de vulnerabilidades técnicas incluye el proveedor de software, los números de versión, el estado actual de implantación (por ejemplo qué software está instalado en qué sistemas) y la persona o personas de la organización responsables del software. Deberían adoptarse medidas adecuadas y oportunas en respuesta a la identificación de posibles vulnerabilidades técnicas. Deberían seguirse las siguientes directrices con el fin de establecer un proceso efectivo de gestión de las vulnerabilidades técnicas: a) la organización debería definir y establecer las funciones y responsabilidades asociadas con la gestión de las
vulnerabilidades técnicas, incluyendo la supervisión de vulnerabilidades, la evaluación de riesgos de vulnerabilidad, el parcheo, el seguimiento de activos y cualquier responsabilidad de coordinación necesaria;
b) los recursos de información que se utilizarán para identificar las vulnerabilidades técnicas pertinentes y para
mantener la alerta sobre ellas deberían identificarse tanto para el software y como para otras tecnologías (en función del inventario de activos, véase 7.1.1); estos recursos de información deberían actualizarse según se modifique el inventario o cuando se encuentren otros recursos nuevos o que sean de utilidad;
c) debería definirse una escala temporal para reaccionar a las notificaciones de vulnerabilidades técnicas que puedan
resultar relevantes; d) una vez identificada la vulnerabilidad técnica, la organización debería identificar los riesgos asociados y las medidas
que deberían adoptarse, las cuales podrían incluir el parcheo de sistemas vulnerables o la aplicación de otros controles;
e) dependiendo de la urgencia con que deba tratarse la vulnerabilidad técnica, la medida adoptada debería ser lleva a
cabo de acuerdo con los controles relativos a la gestión de cambios (véase 12.5.1) o siguiendo los procedimientos de respuesta a incidentes de seguridad de la información (véase 13.2);
f) si existe un parche disponible, deberían evaluarse los riesgos asociados con la instalación del mismo (deberían
compararse los riesgos planteados por la vulnerabilidad con los riesgos de instalar el parche); g) los parches deberían ser probados y evaluados antes de su instalación para garantizar que son efectivos y que no
tienen efectos secundarios que no puedan ser aceptados. Si no hay ningún parche disponible, deberían considerarse otros controles, como:
1) la desactivación de servicios o capacidades relacionadas con la vulnerabilidad; 2) la adaptación o la inclusión de controles de acceso, como por ejemplo, cortafuegos, en los límites de la red
(véase 11.4.5); 3) el aumento de la supervisión para detectar o evitar ataques reales; 4) aumentar la concienciación de la vulnerabilidad;
- 101 - ISO/IEC 27002:2005
h) debería mantenerse un registro de auditoría de todos los procedimientos adoptados; i) el proceso de gestión de las vulnerabilidades técnicas debería supervisarse y evaluarse periódicamente para
garantizar su efectividad y su eficacia; j) los sistemas con elevado riesgo deberían ser los primeros en tratarse. Información adicional Para muchas organizaciones, el correcto funcionamiento de su proceso de gestión de vulnerabilidades técnicas es fundamental, por lo que debería supervisarse periódicamente. Un inventario exacto resulta esencial para garantizar que se identifican las vulnerabilidades técnicas que puedan ser relevantes. La gestión de vulnerabilidades técnicas puede considerarse una función secundaria de la gestión de cambios y, como tal, puede beneficiarse de los procesos y procedimientos de la misma (véanse 10.1.2 y 12.5.1). Los proveedores suelen estar sometidos a mucha presión para publicar parches lo antes posible. Por ello, un parche puede no afrontar el problema correctamente y tener efectos secundarios negativos. Asimismo, en algunos casos, puede que no sea fácil desinstalar un parche una vez que se ha aplicado. Si no es posible probar de manera adecuada los parches, por ejemplo, por motivos de coste o por falta de recursos, puede considerarse la opción de retrasar el parcheo para evaluar los riesgos asociados en función de la experiencia de otros usuarios. 13 GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN
13.1 Notificación de eventos y puntos débiles de seguridad de la información
Objetivo: Asegurarse de que los eventos de seguridad de la información y las debilidades asociadas con los sistemas de información, se comunican de manera que sea posible emprender las acciones correctivas oportunas. Deberían existir procedimientos formales de comunicación de eventos y de escalada. Todos los trabajadores, contratistas y terceros deberían conocer los procedimientos de comunicación de los diferentes tipos de eventos y puntos débiles que pueden afectar a la seguridad de los activos de la organización. Se les debería requerir que comunicaran al contacto designado cualquier evento o punto débil de seguridad de la información lo antes posible. 13.1.1 Notificación de eventos de seguridad de la información
Control Los eventos de seguridad de la información se deberían notificar a través de los canales adecuados de gestión lo antes posible. Guía de implantación Debería establecerse un procedimiento formal de comunicación de eventos de seguridad de la información, junto con un procedimiento de respuesta y escalada de incidentes, que determine la respuesta que debería darse cuando se recibe un informe relativo a un evento de seguridad de la información. Debería establecerse un punto de contacto para comunicar los eventos de seguridad de la información. Debería garantizarse que este punto de contacto es conocido en toda la organización, que siempre está disponible y que es capaz de ofrecer respuestas adecuadas y oportunas. Todos los trabajadores, contratistas y terceros deberían conocer su responsabilidad de comunicar cualquier evento de seguridad de la información lo antes posible. También deberían conocer el procedimiento de comunicación de eventos de seguridad de la información y el punto de contacto. Los procedimientos de comunicación deberían incluir: a) procesos de retroalimentación adecuados para garantizar que aquellas personas que comuniquen eventos de
seguridad de la información son informadas de los resultados después de que se haya tratado y cerrado el problema;
ISO/IEC 27002:2005 - 102 -
b) formularios de comunicación de eventos de seguridad de la información para apoyar la acción de comunicación y para ayudar a la persona que los comunique a recordar todas las acciones necesarias en caso de un evento de seguridad de la información;
c) el comportamiento adecuado que debería tomarse en caso de un evento de seguridad de la información; es decir,
1) anotar inmediatamente todos los detalles importantes (por ejemplo, tipo de incumplimiento, fallo de funcionamiento, mensajes en la pantalla, comportamiento extraño);
2) no hacer nada, pero informar inmediatamente al punto de contacto;
d) la referencia a un proceso disciplinario formal establecido para tratar a los trabajadores, contratistas o terceros que
hayan cometido el quebrantamiento de la seguridad. En entornos de alto riesgo, puede existir una alarma de coacción4), por la que una persona bajo coacción puede indicar dichos problemas. Los procedimientos de respuesta a las alarmas de coacción deberían reflejar la situación de alto riesgo que dichas alarmas indican. Información adicional Algunos ejemplos de eventos e incidentes de seguridad de la información son los siguientes: a) pérdida del servicio, de equipos o de instalaciones; b) fallos o sobrecargas del sistema; c) errores humanos; d) incumplimiento de políticas o directrices; e) incumplimientos de los acuerdos relativos a las infracciones de la seguridad física; f) cambios del sistema no controlados; g) fallos del software o del hardware; h) violaciones de acceso. Prestando la debida atención a los aspectos de seguridad, los incidentes de seguridad de la información pueden utilizarse en los cursos de concienciación del usuario (véase 8.2.2) como ejemplos de lo que podría ocurrir, de cómo reaccionar ante esos incidentes y de cómo evitarlos en el futuro. Para poder tratar los eventos e incidentes de seguridad de la información de forma adecuada, puede que sea necesario recopilar pruebas lo antes posible después de un incidente haya tenido lugar (véase 13.2.3). Los fallos u otros comportamientos anómalos del sistema pueden ser un indicador de un ataque a la seguridad o de un quebrantamiento real de la misma, por lo que siempre deberían notificarse como un evento de seguridad de la información. Para más información acerca de la comunicación de los eventos de seguridad de la información y la gestión de incidentes de seguridad de la información, consulte la Norma ISO/IEC TR 18044.
4) Una alarma de coacción es un método de indicar en secreto que una acción tiene lugar �bajo coacción�.
- 103 - ISO/IEC 27002:2005
13.1.2 Notificación de puntos débiles de seguridad
Control Todos los empleados, contratistas, y terceros que sean usuarios de los sistemas y servicios de información deberían estar obligados a anotar y notificar cualquier punto débil que observen o que sospechen exista, en dichos sistemas o servicios. Guía de implantación Todos los trabajadores, contratistas y terceros deberían comunicar estos incidentes a su director, o directamente al proveedor de servicios, lo antes posible para evitar incidentes de seguridad de la información. El mecanismo de comunicación debería ser todo lo fácil, accesible y disponible que sea posible. Deberían estar informados de que en ningún caso deberían intentar comprobar un punto débil que sospechen que exista. Información adicional Debería informarse a los trabajadores, contratistas y terceros que no deberían intentar comprobar ningún punto débil de seguridad que sospechen que exista. Si lo hacen, esto podría interpretarse como un posible uso indebido del sistema y podría asimismo provocar daños en el sistema o servicio de información, lo que podría derivar en responsabilidades legales para la persona que haya realizado la comprobación.
13.2 Gestión de incidentes de seguridad de la información y mejoras
Objetivo: Garantizar que se aplica un enfoque coherente y efectivo a la gestión de los incidentes de seguridad de la información. Deberían existir responsabilidades y procedimientos para tratar los indicentes y los puntos débiles de seguridad de la información de forma efectiva una vez que se hayan comunicado. Debería aplicarse un proceso de mejora continua a la reacción, la supervisión, la evaluación y la gestión general de los incidentes de seguridad de la información. Cuando sean necesarias pruebas, éstas deberían recopilarse para garantizar el cumplimiento de los requisitos legales. 13.2.1 Responsabilidades y procedimientos
Control Se deberían establecer las responsabilidades y procedimientos de gestión para garantizar una respuesta rápida, efectiva y ordenada a los incidentes de seguridad de la información. Guía de implantación Además de comunicar los eventos y puntos débiles de seguridad de la información (véase 13.1), debería utilizarse la supervisión de sistemas, alertas y vulnerabilidades (10.10.2) para detectar incidentes de seguridad de la información. Deberían tenerse en cuenta las siguientes directrices en los procedimientos de gestión de los incidentes de seguridad de la información: a) deberían establecerse procedimientos para tratar diferentes tipos de incidentes de seguridad de la información, incluyendo:
1) fallos del sistema de información y pérdida del servicio; 2) código malicioso (véase 10.4.1); 3) denegación del servicio; 4) errores como resultado de datos de negocio incompletos o poco precisos; 5) quebrantamiento de la confidencialidad y la integridad; 6) uso indebido de los sistemas de información.
ISO/IEC 27002:2005 - 104 -
b) además de los planes normales de contingencia (véase 14.1.3), los procedimientos también deberían cubrir lo siguiente (véase 13.2.2):
1) análisis e identificación de las causas del incidente;
2) contención;
3) planificación e implantación de acciones correctivas para evitar que vuelva a producirse, en caso de ser necesario;
4) comunicación con las personas afectadas o implicadas en la recuperación del incidente;
5) comunicación de las medidas a la autoridad adecuada. c) deberían recopilarse pistas de auditoría y evidencias similares (véase 13.2.3) y guardarse de forma segura, según sea
necesario, para lo siguiente:
1) análisis de los problemas internos;
2) uso como prueba forense en relación con un posible incumplimiento del contrato o de un requisito legal o en caso de procesos civiles o penales, por ejemplo, de acuerdo con la legislación sobre uso indebido de la informática o sobre la protección de datos;
3) negociaciones de indemnización de los proveedores de software o de servicios. d) deberían controlarse atentamente y de manera formal las acciones para recuperarse de quebrantamientos de la
seguridad y fallos de un sistema correcto. Los procedimientos deberían garantizar que:
1) sólo el personal claramente identificado y autorizado tiene acceso a sistemas y datos activos (véase 6.2 para accesos externos);
2) todas las acciones de emergencia llevadas a cabo se documentan detalladamente;
3) las acciones de emergencia se comunican a la Dirección y se revisan de manera adecuada;
4) la integridad de los sistemas y controles de negocio queda confirmada con un retraso mínimo.
Los objetivos de la gestión de incidentes de seguridad de la información deberían ser acordados con la Dirección, y debería garantizarse que los responsables de la gestión de incidentes de seguridad de la información comprenden las prioridades de la organización en cuanto al tratamiento de los incidentes de seguridad de la información. Información adicional Los incidentes de seguridad de la información pueden trascender los límites de la organización o del país. Para reaccionar ante dichos incidentes, resulta cada vez más necesario coordinar la respuesta y compartir la información acerca de estos incidentes con organizaciones externas, cuando esto sea apropiado. 13.2.2 Aprendizaje de los incidentes de seguridad de la información
Control Deberían existir mecanismos que permitan cuantificar y supervisar los tipos, volúmenes y costes de los incidentes de seguridad de la información. Guía de implantación La información obtenida a partir de la evaluación de los incidentes de seguridad de la información debería utilizarse para identificar incidentes recurrentes o con un elevado alcance. Información adicional La evaluación de los incidentes de seguridad de la información puede sugerir la necesidad de mejorar o añadir controles para limitar la frecuencia, el daño y el coste de futuras apariciones, o para tenerlos en cuenta en el proceso de revisión de la política de seguridad (véase 5.1.2).
- 105 - ISO/IEC 27002:2005
13.2.3 Recopilación de evidencias
Control Cuando se emprenda una acción contra una persona u organización, después de un incidente de seguridad de la información, que implique acciones legales (tanto civiles como penales), deberían recopilarse las evidencias, y conservarse y presentarse conforme a las normas establecidas en la jurisdicción correspondiente. Guía de implantación Deberían desarrollarse procedimientos internos para seguirse a la hora de recopilar y presentar pruebas con el fin de ejercer una acción disciplinaria dentro de una organización. Por lo general, las normas para las pruebas abarcan: a) la admisibilidad de la prueba: si la prueba puede usarse o no ante un tribunal; b) el peso de la prueba: la calidad y la integridad de la prueba. Para que la prueba sea admitida, la organización debería asegurarse de que sus sistemas de información cumplan alguna norma existente o algún código de prácticas para la elaboración de pruebas admisibles. El peso de la prueba entregada debería cumplir cualquier requisito que le sea aplicable. Para que una prueba tenga peso, un sólido seguimiento de la prueba debería demostrar la calidad y la integridad de los controles utilizados para proteger de forma correcta y coherente la prueba (por ejemplo, prueba del control del proceso) durante todo el periodo en que la prueba que debía recuperarse estuvo almacenada y fue procesada. Normalmente, un seguimiento será sólido si se establece en las siguientes condiciones: a) para documentos en papel: el original se guarda de forma segura con un registro de la persona que encontró el
documento, de dónde y cuándo lo encontró y de quién presenció dicho descubrimiento. Cualquier investigación debería garantizar que los originales no han sido alterados;
b) para la información en soportes informáticos: deberían realizarse imágenes o copias exactas (dependiendo de los
requisitos aplicables) de cualquier medio extraíble y de la información en discos duros o en la memoria para garantizar su disponibilidad. Debería mantenerse un registro de todas las acciones llevadas a cabo durante el proceso de copia, y dicho proceso debería ser presenciado por otra persona. Los soportes originales y el registro (si esto no es posible, por lo menos una imagen o copia exacta) deberían mantenerse en lugar seguro y no tocarse.
Los trabajos forenses deberían efectuarse exclusivamente en copias del material de prueba. Debería protegerse la integridad de todo el material de prueba. La copia del material de prueba debería estar supervisada por personal digno de confianza y debería registrarse la información acerca de dónde y cuándo se efectuó el proceso de copia, de quién llevó a cabo las actividades de copia y de qué herramientas y programas se utilizaron para ello. Información adicional Cuando se detecta por primera vez un evento de seguridad de la información, puede que no resulte evidente si dicho evento tendrá como consecuencia una acción legal. Por este motivo, existe el peligro de que se destruyan de forma intencional o accidental las pruebas necesarias antes de tomar conciencia de la gravedad del incidente. Es recomendable hacer uso de los servicios de un abogado o de la policía en las primeras fases de cualquier acción legal que se esté considerando, así como el asesorarse sobre las pruebas necesarias. Las pruebas pueden trascender los límites de la organización o la jurisdicción. En estos casos, debería garantizarse que la organización está autorizada a recopilar la información requerida como prueba. También deberían tenerse en cuenta los requisitos de otras jurisdicciones con el fin de maximizar las oportunidades de admisión en todas las jurisdicciones competentes.
ISO/IEC 27002:2005 - 106 -
14 GESTIÓN DE LA CONTINUIDAD DEL NEGOCIO
14.1 Aspectos de seguridad de la información en la gestión de la continuidad del negocio
Objetivo: Contrarrestar las interrupciones de las actividades empresariales y proteger los procesos críticos de negocio de los efectos derivados de fallos importantes o catastróficos de los sistemas de información, así como garantizar su oportuna reanudación. Debería implantarse un proceso de gestión de la continuidad del negocio para minimizar los efectos sobre la organización y poder recuperarse de pérdidas de activos de información (como resultado, por ejemplo, de desastres naturales, accidentes, fallos de los equipos y acciones intencionadas) hasta un nivel aceptable mediante una combinación de controles preventivos y de recuperación. Este proceso debería identificar los procesos críticos de negocio e integrar los requisitos de gestión de la seguridad de la información para la continuidad del negocio con otros requisitos de continuidad relacionados con aspectos tales como las actividades, el personal, los materiales, el transporte y las instalaciones. Las consecuencias de los desastres, fallos de seguridad, pérdidas del servicio y disponibilidad del servicio deberían estar sometidas a un análisis de efectos sobre el negocio. Deberían desarrollarse e implantarse planes de continuidad de negocio para garantizar una reanudación adecuada de las actividades fundamentales. La seguridad de la información debería ser una parte integrada en el proceso general de continuidad del negocio y de otros procesos de gestión dentro de la organización. La gestión de la continuidad del negocio debería incluir controles para identificar y reducir los riesgos, además del proceso general de evaluación de riesgos, limitar las consecuencias de incidentes dañinos y garantizar que la información necesaria para los procesos del negocio está disponible. 14.1.1 Inclusión de la seguridad de la información en el proceso de gestión de la continuidad del negocio
Control Debería desarrollarse y mantenerse un proceso para la continuidad del negocio en toda la organización, que gestione los requisitos de seguridad de la información necesarios para la continuidad del negocio. Guía de implantación El proceso debería reunir los siguientes elementos clave para la gestión de la continuidad del negocio: a) comprender los riesgos que la organización afronta en cuanto a probabilidad y efectos en el tiempo, incluyendo la
identificación y la priorización de los procesos críticos del negocio (véase 14.1.2); b) identificar todos los activos que intervienen en los procesos críticos del negocio (véase 7.1.1); c) comprender los efectos que las interrupciones causadas por los incidentes de seguridad de la información puedan
tener en el negocio (es importante encontrar soluciones que traten tanto incidentes de menor impacto, así como incidentes graves que pudieran amenazar la viabilidad de la organización) y establecer los objetivos del negocio en lo relativo a los recursos de tratamiento de la información;
d) considerar la contratación de un seguro adecuado que pueda formar parte del proceso general de continuidad del
negocio, así como de la gestión de riesgos operativos; e) identificar y considerar la implantación de más controles preventivos o paliativos; f) identificar suficientes recursos financieros, organizativos, técnicos y del entorno con el fin de afrontar los requisitos
de seguridad de la información identificados; g) garantizar la seguridad del personal y la protección de los recursos de tratamiento de la información así como del
patrimonio de la organización;
- 107 - ISO/IEC 27002:2005
h) formular y documentar planes de continuidad de negocio que traten los requisitos de seguridad de la información de acuerdo con la estrategia de continuidad del negocio acordada (véase 14.1.3);
i) probar y actualizar periódicamente los planes y los procesos que se apliquen (véase 14.1.5); j) garantizar que la gestión de la continuidad del negocio se incorpora a los procesos y a la estructura de la
organización; la responsabilidad del proceso de gestión de la continuidad del negocio debería recaer en un nivel de responsabilidad adecuado dentro de la organización (véase 6.1.1).
14.1.2 Continuidad del negocio y evaluación de riesgos
Control Deberían identificarse los eventos que puedan causar interrupciones en los procesos de negocio, así como la probabilidad de que se produzcan tales interrupciones, sus efectos y sus consecuencias para la seguridad de la información. Guía de implantación Los aspectos de seguridad de la información de la continuidad del negocio deberían basarse en la identificación de eventos (o secuencia de eventos) que provocan interrupciones en los procesos del negocio de la organización, por ejemplo, fallos de los equipos, errores humanos, robos, incendios, desastres naturales y actos terroristas. A esta identificación debería seguir una evaluación de los riesgos para determinar la probabilidad y los efectos de dichas interrupciones en cuanto a tiempo, escala de daños y período de recuperación. Las evaluaciones de los riesgos de continuidad del negocio deberían llevarse a cabo con una implicación total de los propietarios de los recursos y los procesos de negocio. Esta evaluación debería considerar todos los procesos del negocio y no debería limitarse a los recursos de tratamiento de la información, sino que debería incluir los resultados específicos relativos a la seguridad de la información. Es importante relacionar los distintos aspectos del riesgo para obtener una imagen completa de los requisitos de continuidad del negocio de la organización. La evaluación debería identificar, cuantificar y priorizar los riesgos comparándolos con criterios y objetivos relevantes para la organización, incluyendo los recursos críticos, los efectos de las perturbaciones, los tiempos tolerables de interrupción del servicio y las prioridades de recuperación. Dependiendo de los resultados de la evaluación de riesgos, debería desarrollarse una estrategia de continuidad de negocio para determinar el enfoque general para la continuidad del negocio. Cuando se haya creado esta estrategia, debería ser refrendada por la Dirección y debería crearse y refrendarse un plan para implantar esta estrategia. 14.1.3 Desarrollo e implantación de planes de continuidad que incluyan la seguridad de la información
Control Deberían desarrollarse e implantarse planes para mantener o restaurar las operaciones y garantizar la disponibilidad de la información en el nivel y en el tiempo requerido, después de una interrupción o un fallo de los procesos críticos de negocio. Guía de implantación El proceso de planificación de la continuidad del negocio debería tener en cuenta lo siguiente: a) la identificación y acuerdo de todas las responsabilidades y los procedimientos de continuidad del negocio; b) la identificación de las pérdidas tolerables de información y de servicios; c) la implantación de los procedimientos que permitan la recuperación y la restauración de las actividades del negocio,
así como la disponibilidad de la información en las escalas temporales requeridas; debería prestarse una especial atención a la evaluación de las dependencias internas y externas del negocio y de los contratos en vigor;
d) los procedimientos operativos que deberían seguirse mientras no se haya completado aún la recuperación y la
restauración;
ISO/IEC 27002:2005 - 108 -
e) la documentación de los procedimientos y procesos acordados; f) una formación adecuada para el personal sobre los procesos y procedimientos acordados, incluyendo formación para
la gestión de la situación de crisis; g) las pruebas y actualización de los planes. El proceso de planificación debería centrase en los objetivos del negocio requeridos, por ejemplo, la restauración de los servicios de comunicación con los clientes en un tiempo aceptable. Se deberían identificar los servicios y los recursos que hacen posible esto, incluyendo el personal, los recursos, así como los planes necesarios para los recursos de tratamiento de la información. Tales planes necesarios pueden incluir acuerdos con terceros en forma de acuerdos recíprocos, o servicios se suscripción comercial. Los planes de continuidad del negocio deberían estar dirigidos hacia las vulnerabilidades de tipo organizacional, y por lo tanto pueden contener información sensible que necesita estar adecuadamente protegida. Las copias de los planes de continuidad de negocio deberían estar almacenadas en un lugar separado, a una distancia suficiente para no quedar afectadas por cualquier daño o desastre que ocurra en las instalaciones principales. La Dirección debería asegurarse de que las copias de los planes de continuidad de negocio están actualizadas y protegidas con el mismo nivel de protección que el aplicado en las instalaciones principales. El resto de material necesario para ejecutar los planes de continuidad debería estar también almacenado en un lugar separado. Si se utiliza la alternativa de localizaciones provisionales, el nivel de protección debería ser equivalente al de las instalaciones principales. Información adicional Debería señalarse que los planes y actividades de la gestión de crisis [véase 14.1.3 f)] pueden ser diferentes de los de la gestión de la continuidad del negocio; por ejemplo, puede darse el caso de que una crisis se trate siguiendo procedimientos de gestión ordinarios. 14.1.4 Marco de referencia para la planificación de la continuidad del negocio
Control Debería mantenerse un único marco de referencia para los planes de continuidad del negocio, para asegurar que todos los planes sean coherentes, para cumplir los requisitos de seguridad de la información de manera consistente y para identificar las prioridades de realización de pruebas y del mantenimiento. Guía de implantación Cada plan de continuidad de negocio debería describir el enfoque de continuidad, por ejemplo, el enfoque para asegurar que la información o el sistema de información están disponibles y son seguros. Cada plan debería también especificar el escalado del plan y las condiciones para su activación, así como las personas responsables de la ejecución de cada componente del plan. Cuando se identifican nuevos requisitos, cualquier procedimiento de emergencia existente, por ejemplo planes de evacuación o disposiciones necesarias, deberían ser modificadas según sea apropiado. Los procedimientos deberían ser incluidos dentro de los programas de gestión de los cambios en la organización para asegurar que las cuestiones relativas a la continuidad del negocio se tratan siempre de la manera adecuada. Cada plan debería tener un propietario específico. Los procedimientos de emergencia, los manuales con las disposiciones necesarias y los planes de reanudación deberían ser responsabilidad de los propietarios de los correspondientes recursos o procesos del negocio implicados. Los acuerdos necesarios para los servicios técnicos alternativos, tales como recursos de tratamiento de la información y de las comunicaciones, deberían, normalmente, ser responsabilidad de los proveedores del servicio. Un marco de referencia de un plan de continuidad del negocio debería estar dirigido a los requisitos de la seguridad de la información y tener en cuenta lo siguiente: a) las condiciones de activación de los planes que describen el proceso a seguir antes de la activación de cada plan (por
ejemplo, cómo valorar la situación, quiénes tiene que estar involucrados);
- 109 - ISO/IEC 27002:2005
b) procedimientos de emergencia que describan las acciones que deberían tomarse después de un incidente que ponga en peligro las actividades del negocio;
c) procedimientos alternativos que describan las medidas que deberían adoptarse para trasladar temporalmente
actividades del negocio esenciales o servicios de asistencia técnica a ubicaciones alternativas y para hacer que los procesos vuelvan a funcionar en las escalas temporales requeridas;
d) procedimientos operativos provisionales que deberían seguirse mientras no se hayan completado aún los procesos de
recuperación y restauración; e) procedimientos de reanudación que describan las acciones que deberían tomarse para retornar a las actividades del
negocio habituales; f) un programa de mantenimiento que especifique cómo y dónde se probará el plan, así como el proceso para el
mantenimiento del mismo; g) actividades de concienciación y formación diseñadas para generar un conocimiento de los procesos de continuidad
del negocio y garantizar que los procesos continúan siendo efectivos; h) las responsabilidades de las personas, describiendo quién es responsable de la ejecución de qué elemento del plan.
Deberían designarse alternativas cuando sea necesario; i) los activos y los recursos críticos necesarios para que sea posible la actuación en caso de emergencia o de necesidad
de puesta en marcha de los procedimientos de reanudación. 14.1.5 Pruebas, mantenimiento y reevaluación de los planes de continuidad del negocio
Control Los planes de continuidad del negocio deberían probarse y actualizarse periódicamente para asegurar que están al día y que son efectivos. Guía de implantación Los planes de continuidad del negocio deberían garantizar que todos los miembros del equipo de recuperación, así como cualquier otra persona relevante, conocen los planes y su responsabilidad para la continuidad del negocio y la seguridad de la información, y que conocen sus funciones cuando se recurre a un plan. La programación de las pruebas del plan o de los planes de continuidad del negocio debería indicar cuándo y cómo debería probarse cada elemento del plan. Todos los elementos del plan o los planes deberían probarse con frecuencia. Deberían utilizarse varias técnicas para obtener garantías de que el plan o los planes funcionarán en la vida real. Dichas técnicas deberían incluir lo siguiente: a) pruebas de sobremesa de varios escenarios (debates acerca de las disposiciones de recuperación del negocio
utilizando ejemplos de interrupciones); b) simulaciones (especialmente para formar a las personas en sus funciones de gestión de crisis o tras un incidente); c) pruebas de recuperación técnica (garantizar que los sistemas de información pueden restaurarse de forma efectiva); d) pruebas de recuperación en un emplazamiento alternativo (hacer funcionar los procesos del negocio al mismo
tiempo que las operaciones de recuperación fuera del emplazamiento principal); e) pruebas a instalaciones y servicios de los proveedores (garantizar que los servicios y productos externos cumplirán
el compromiso contratado);
ISO/IEC 27002:2005 - 110 -
f) ensayos generales (probar que la organización, el personal, los equipos, las instalaciones y los procesos pueden afrontar las interrupciones).
Estas técnicas pueden ser utilizadas por cualquier organización. Estas técnicas deberían aplicarse al plan de recuperación específico. Deberían registrarse los resultados de las pruebas y deberían emprenderse acciones para mejorar los planes cuando sea necesario. Deberían asignarse responsabilidades de revisión periódica de cada plan de continuidad del negocio. La identificación de los cambios en los objetivos del negocio que aún no hayan sido reflejados en los planes de continuidad del negocio deberían ir acompañadas de una actualización adecuada del plan. Este proceso formal de control de cambios debería garantizar que los planes actualizados se distribuyen y se refuerzan con revisiones periódicas del plan al completo. Algunos ejemplos de los cambios en los que debería considerarse la actualización de los planes de continuidad del negocio son la adquisición de nuevos equipos, la implantación de nuevas versiones de los sistemas y las modificaciones en: a) el personal; b) las direcciones o números de teléfono; c) la estrategia del negocio; d) la ubicación, instalaciones y los recursos; e) la legislación; f) los contratistas, proveedores y clientes clave; g) los procesos nuevos o los eliminados; h) riesgos (operativos y financieros). 15 CUMPLIMIENTO
15.1 Cumplimiento de los requisitos legales
Objetivo: Evitar incumplimientos de las leyes o de las obligaciones legales, reglamentarias o contractuales y de los requisitos de seguridad. El diseño, el funcionamiento, el uso y la gestión de los sistemas de información pueden estar sujetos a requisitos legales, reglamentarios y contractuales de seguridad. Debería consultarse a los asesores legales de la organización o a abogados adecuadamente cualificados acerca de los requisitos legales específicos. Los requisitos legales pueden ser diferentes en cada país, y puede ser diferente para la información creada en un país y que se transmite a otro (es decir, flujo transfronterizo de datos). 15.1.1 Identificación de la legislación aplicable
Control Todos los requisitos pertinentes, tanto legales como reglamentarios o contractuales, y el enfoque de la organización para cumplir dichos requisitos, deberían estar definidos, documentados y mantenerse actualizados de forma explícita para cada sistema de información de la organización. Guía de implantación Deberían definirse y documentarse de forma similar los controles específicos y las responsabilidades personales para cumplir estos requisitos.
- 111 - ISO/IEC 27002:2005
15.1.2 Derechos de propiedad intelectual (IPR)
Control Deberían implantarse procedimientos adecuados para garantizar el cumplimiento de los requisitos legales, reglamentarios y contractuales sobre el uso de material, con respecto al cual puedan existir derechos de propiedad intelectual y sobre el uso de productos de software propietario. Guía de implantación Deberían tenerse en cuenta las siguientes directrices para proteger cualquier material que pueda ser considerado propiedad intelectual: a) publicar una política de cumplimiento de derechos de propiedad intelectual que defina el uso legal de los productos
de software y de la información; b) adquirir software únicamente a través de fuentes conocidas y de confianza para garantizar que no se infringen
derechos de autor; c) mantener el conocimiento de las políticas de protección de los derechos de propiedad intelectual, y notificar la
intención de aplicar medidas disciplinarias a cualquier miembro del personal que quebrante dichas políticas; d) mantener registros adecuados de los activos e identificar todos los activos que requieran la protección de derechos
de propiedad intelectual; e) mantener resguardos y pruebas de la propiedad de licencias, discos maestros, manuales, etc.; f) implantar controles para garantizar que no se excede en ningún caso el número máximo de usuarios permitidos que
pueda existir; g) llevar a cabo comprobaciones de que se instalan exclusivamente productos con licencia y software autorizado; h) disponer de una política para mantener unas condiciones de licencia adecuadas; i) disponer una política para transferir software a un tercero o deshacerse de software; j) utilizar herramientas de auditoría adecuadas; k) cumplir las condiciones contractuales del software y la información obtenida de redes públicas; l) no duplicar, convertir a otro formato ni extraer de grabaciones comerciales (de vídeo o audio) más de lo que permita
la ley de derechos de autor; m) no copiar parcial o totalmente libros, artículos, informes u otros documentos más allá de lo que permita la ley de
derechos de autor. Información adicional Los derechos de propiedad intelectual incluyen derechos de autor sobre el software o sobre los documentos, derechos de diseño, marcas registradas, patentes y licencias de código fuente. Los productos de software propietario suelen suministrarse con un contrato de licencia que especifica las condiciones de la licencia como, por ejemplo, una limitación del uso de los productos a unas máquinas específicas o una limitación de copias exclusivamente a la creación de copias de seguridad. La situación de IPR del software de la organización debería ser clarificada con el personal.
ISO/IEC 27002:2005 - 112 -
Los requisitos legales, reglamentarios y contractuales pueden plantear restricciones a la copia del material propietario. En particular, pueden exigir que sólo pueda utilizarse material desarrollado por la organización o que cuente con licencia o haya sido suministrado por el desarrollador a la organización. El quebrantamiento de los derechos de autor puede desembocar en acciones legales, que pueden incluir procedimientos penales. 15.1.3 Protección de los documentos5) de la organización
Control Los documentos importantes deberían estar protegidos contra la pérdida, destrucción y falsificación de acuerdo con los requisitos legales, reglamentarios, contractuales y empresariales. Guía de implantación Los registros deberían estar clasificados según el tipo de registro, por ejemplo, registros contables, registros de la base de datos, registros de transacciones, registros de auditorías y procedimientos operativos, y cada uno de ellos debería contar con detalles acerca de los períodos de conservación y del tipo de medios de almacenamiento, por ejemplo, papel, microficha o soporte magnético u óptico. Asimismo, debería almacenarse cualquier material de cifrado criptográfico relacionado y cualquier programa asociado a archivos cifrados o firmas digitales (véase 12.3) para permitir descifrar los registros durante el período de tiempo en que éstos se conserven. Debería considerarse la posibilidad de que los soportes utilizados para almacenar los registros se deterioren. Los procedimientos de almacenamiento y manipulación deberían implantarse de acuerdo con las recomendaciones del fabricante. Para un almacenamiento a largo plazo, debería considerarse el uso de papel y microfichas. Si se escogen soportes electrónicos de almacenamiento, deberían incluirse procedimientos para asegurar la accesibilidad a los datos (legibilidad del soporte y del formato) durante todo el período de conservación como garantía contra la pérdida producida por los posibles cambios tecnológicos. Deberían escogerse aquellos sistemas de almacenamiento de datos con los que se pueda acceder a los datos requeridos en un plazo y un formato aceptables, que dependerá de los requisitos que haya que cumplir. El sistema de almacenamiento y manipulación debería garantizar una clara identificación de los registros y de sus períodos de conservación, según quede definido en la legislación o las normativas nacionales o regionales, cuando éstas sean aplicables. El sistema debería permitir una destrucción apropiada de los registros transcurrido dicho período si ya no resultan necesarios para la organización. Para satisfacer estos objetivos de salvaguarda de los registros, deberían adoptarse dentro de una organización las siguientes medidas: a) deberían emitirse directrices acerca de la conservación, el almacenamiento, la manipulación y la eliminación de
registros e información; b) debería prepararse un calendario de conservación que identifique los registros y el período de tiempo por el que
deberían conservarse; c) debería mantenerse un inventario de las fuentes de información clave; d) deberían implantarse controles adecuados para proteger los registros y la información contra la pérdida, la
destrucción y la falsificación.
5) NOTA NACIONAL Según recoge la Norma UNE-ISO 15489-1, el inglés posee tres términos distintos (documents, records y archives), para de-
signar lo que en castellano, como en el resto de lenguas latinas, cuenta con una única voz (documentos). Así, document es el equivalente de documento en su significado genérico, como mera información registrada. Por el contrario, los términos records y archives designan de manera específica a aquellos documentos producidos como prueba y reflejo de las activida-des de la organización que los ha creado, reservándose el empleo de este último a los documentos de carácter histórico.
- 113 - ISO/IEC 27002:2005
Información adicional Algunos registros pueden tener que conservarse de manera segura para cumplir los requisitos legales, reglamentarios o contractuales, así como para apoyar las actividades empresariales más importantes. Algunos ejemplos serían los registros que pueden ser requeridos como prueba de que una organización funciona dentro de las normas legales o reglamentarias, para garantizar una defensa adecuada ante posible demandas civiles o penales o para confirmar la situación financiera de una organización frente a accionistas, partes externas y auditores. El período de tiempo y el contenido de los datos para la conservación de la información puede estar establecido por una ley o normativa nacional. Para más información acerca de la gestión de registros de la organización, consulte la Norma ISO 15489-1. 15.1.4 Protección de datos y privacidad de la información de carácter personal
Control Debe garantizarse la protección y la privacidad de los datos según se requiera en la legislación y la reglamentación aplicables y, en su caso, en las cláusulas contractuales pertinentes. Guía de implantación Debería desarrollarse e implantarse una política de protección de datos y de privacidad de la organización. Dicha política debería comunicarse a todas las personas que participen en el tratamiento de información de carácter personal. El cumplimiento de esta política y de toda la legislación y normativa aplicables sobre protección de datos requiere una estructura de gestión y un control adecuados. A menudo, la mejor forma de alcanzar este objetivo es designar a un responsable, como un encargado de protección de datos, que debería orientar a los directores, usuarios y proveedores de servicios acerca de sus responsabilidades individuales y de los procedimientos específicos que deberían seguirse. La responsabilidad de tratar la información personal y de garantizar el conocimiento de los principios de protección de datos debería realizarse de acuerdo con la legislación y las normativas aplicables. Deberían implementarse medidas técnicas y organizativas adecuadas para proteger la información personal. Información adicional Muchos países han aprobado leyes que exigen controles para la recopilación, el tratamiento y la transmisión de datos personales (normalmente, información acerca de personas vivas que pueden ser identificadas a partir de dicha información). Dependiendo de la legislación nacional correspondiente, dichos controles pueden imponer multas a aquellos que recopilen, procesen y divulguen información personal y pueden restringir la capacidad de transferir dichos datos a otros países. 15.1.5 Prevención del uso indebido de los recursos de tratamiento de la información
Control Se debería disuadir a los usuarios de utilizar los recursos de tratamiento de la información para fines no autorizados. Guía de implantación La Dirección debería aprobar el uso de los recursos de tratamiento de la información. Cualquier uso de estos recursos para fines no empresariales sin autorización de la Dirección (véase 6.1.4) o para cualquier propósito no autorizado, debería considerarse como un uso indebido de los recursos. Si se identifica una actividad no autorizada mediante la supervisión o por cualquier otro medio, esta actividad debería ser puesta en conocimiento del director encargado de considerar la acción disciplinaria y/o legal más adecuada. Debería consultarse con un abogado antes de la implantación de procedimientos de supervisión. Todos los usuarios deberían conocer el alcance exacto del acceso que se les permite y estar al tanto de la supervisión implantada para detectar usos no autorizados. Para ello, puede darse a los usuarios una autorización por escrito, una copia que debería ser firmada por el usuario y conservada de forma segura por la organización. Debería ser puesto en conocimiento de los trabajadores de la organización, los contratistas y terceros el hecho de que no se permitirá ningún acceso que no esté autorizado.
ISO/IEC 27002:2005 - 114 -
Al iniciar la sesión, debería aparecer un mensaje de aviso que indique que el recurso de tratamiento de la información en el que se está entrando es propiedad de la organización y que no se permite ningún acceso que no esté autorizado. El usuario debería aceptar y actuar conforme al mensaje de la pantalla para poder seguir con el proceso de inicio de sesión (véase 11.5.1). Información adicional Los recursos de tratamiento de la información de una organización tienen como objetivo principal o exclusivo fines de negocio. La detección de intrusos, la inspección del contenido y otras herramientas de supervisión pueden ayudar a prevenir y detectar un uso indebido de las instalaciones de tratamiento de la información. Muchos países cuentan con legislación destinada a proteger los usos informáticos indebidos. La utilización de un ordenador para fines no autorizados puede constituir un delito penal. La legalidad del uso de la supervisión difiere en los distintos países y puede exigir que la Dirección avise a todos los usuarios de dicha supervisión o que éstos accedan a dicha supervisión. Si el sistema al que se accede es de acceso público (por ejemplo, un servidor web público) y está sometido a supervisión de seguridad, debería aparecer un mensaje indicándolo. 15.1.6 Regulación de los controles criptográficos
Control Los controles criptográficos se deberían utilizar de acuerdo con todos los contratos, leyes y reglamentaciones pertinentes. Guía de implantación Deberían tenerse en cuenta los siguientes elementos para el cumplimiento de los contratos, leyes y normativas pertinentes: a) restricciones a la importación o exportación de hardware y software informático para realizar funciones criptográficas; b) restricciones a la importación o exportación de hardware o software informático diseñado para que se le añadan
funciones criptográficas; c) restricciones al uso del cifrado; d) métodos de acceso obligatorio o discrecional por parte de las autoridades del país a la información cifrada mediante
hardware o software para ofrecer confidencialidad al contenido. Debería consultarse a un abogado para garantizar el cumplimiento de las leyes y normativas nacionales. También debería consultarse a un abogado antes de transferir información cifrada o controles criptográficos a otro país.
15.2 Cumplimiento de las políticas y normas de seguridad y cumplimiento técnico
Objetivo: Asegurar que los sistemas cumplen las políticas y normas de seguridad de la organización. La seguridad de los sistemas de información debería revisarse periódicamente. Dichas revisiones deberían realizarse mediante una comparación con políticas de seguridad adecuadas y debería auditarse que las plataformas técnicas y los sistemas de información cumplan las normas de implantación de seguridad y los controles de seguridad documentados que resulten aplicables. 15.2.1 Cumplimiento de las políticas y normas de seguridad
Control Los directores deberían asegurarse de que todos los procedimientos de seguridad dentro de su área de responsabilidad se realizan correctamente con el fin de cumplir las políticas y normas de seguridad.
- 115 - ISO/IEC 27002:2005
Guía de implantación Los directores deberían revisar periódicamente que el tratamiento de información dentro de su área de responsabilidad cumple las políticas y normas de seguridad apropiadas, así como cualquier otro requisito de seguridad. Si, como resultado de la revisión, se encuentra algún incumplimiento, los directores deberían: a) determinar las causas del incumplimiento; b) evaluar la necesidad de medidas para garantizar que no vuelva a producirse el incumplimiento; c) determinar e implantar las acciones correctivas adecuadas; d) revisar las acciones correctivas tomadas. Debería registrarse el resultado de las revisiones y las acciones correctivas llevadas a cabo por los directores, y estos registros deberían conservarse. Cuando se lleve a cabo una revisión independiente en su área de responsabilidad, los directores deberían informar de los resultados a las personas que lleven a cabo dichas revisiones independientes (véase 6.1.8). Información adicional La supervisión operativa del uso del sistema se trata en el apartado 10.10. 15.2.2 Comprobación del cumplimiento técnico
Control Debería comprobarse periódicamente que los sistemas de información cumplen las normas de aplicación para la implantación. Guía de implantación Un ingeniero de sistemas experimentado debería llevar a cabo la comprobación del cumplimiento técnico manualmente (con ayuda de las herramientas de software adecuadas si fuera necesario) o con ayuda de herramientas automáticas que generen un informe técnico para su posterior interpretación por parte de un especialista técnico. Si se utilizan pruebas de penetración o evaluaciones de la vulnerabilidad, debería procederse con precaución, puesto que dichas actividades podrían poner en peligro la seguridad del sistema. Estas pruebas deberían planificarse y documentarse, y deberían poder repetirse. Cualquier comprobación de cumplimiento técnico sólo debería ser efectuada por personas competentes y autorizadas, o bajo la supervisión de dichas personas. Información adicional La comprobación del cumplimiento técnico implica el examen de los sistemas operativos para garantizar que los controles de hardware y software se han implantado correctamente. Este tipo de comprobación del cumplimiento requiere unos conocimientos técnicos especializados. La comprobación del cumplimiento también cubre, por ejemplo, las pruebas de penetración y las evaluaciones de vulnerabilidad, que podrían ser realizadas por expertos independientes contratados específicamente para este fin. Esto puede resultar útil para detectar vulnerabilidades en el sistema y para comprobar la efectividad de los controles a la hora de evitar accesos no autorizados debidos a estas vulnerabilidades. Las pruebas de penetración y las evaluaciones de vulnerabilidad ofrecen una foto del sistema en un estado determinado en un momento determinado. Esta foto está limitada a aquellas porciones del sistema que se hayan probado durante el intento o los intentos de penetración. Las pruebas de penetración y las evaluaciones de vulnerabilidad no sustituyen a las evaluaciones de riesgos.
ISO/IEC 27002:2005 - 116 -
15.3 Consideraciones sobre la auditoría de los sistemas de información
Objetivo: Lograr que el proceso de auditoría de los sistemas de información alcance la máxima eficacia con las mínimas interferencias. Durante las auditorías del sistema de información, deberían existir controles para salvaguardar los sistemas operativos y las herramientas de auditoría. También se requiere protección para salvaguardar la integridad y evitar un uso indebido de las herramientas de auditoría. 15.3.1 Controles de auditoría de los sistemas de información
Control Los requisitos y las actividades de auditoría que impliquen comprobaciones en los sistemas en producción deberían ser cuidadosamente planificados y acordados para minimizar el riesgo de interrupciones en los procesos del negocio. Guía de implantación Deberían cumplirse las siguientes directrices: a) los requisitos de auditoría deberían acordarse con la Dirección adecuada; b) debería acordarse y controlarse el alcance de las comprobaciones; c) las comprobaciones deberían limitarse a accesos de sólo lectura al software y a los datos; d) un acceso diferente al de sólo lectura debería permitirse únicamente en copias aisladas de los archivos del sistema,
que deberían borrarse cuando finalizara la auditoría, o a las que debería protegerse adecuadamente si es obligatorio mantener dichos archivos de acuerdo con los requisitos de documentación de la auditoría;
e) los recursos para llevar a cabo las comprobaciones deberían identificarse explícitamente y hacerse disponibles; f) deberían identificarse y acordarse los requisitos para un tratamiento especial o adicional; g) todos los accesos deberían ser supervisados y registrados para obtener una pista de referencia. Debería considerarse
el uso de pistas de referencia con la inclusión de tiempos para los datos o sistemas críticos; h) deberían documentarse todos los procedimientos, requisitos y responsabilidades; i) la persona o personas que lleven a cabo la auditoría deberían ser independientes de las actividades auditadas. 15.3.2 Protección de las herramientas de auditoría de los sistemas de información
Control El acceso a las herramientas de auditoría de los sistemas de información debería estar protegido para evitar cualquier posible peligro o uso indebido. Guía de implantación Las herramientas de auditoría de los sistemas de información, por ejemplo, software o archivos de datos, deberían ser independientes de los sistemas de desarrollo y los sistemas operativos, y no deberían mantenerse en bibliotecas de cintas o áreas de usuarios, salvo que exista un nivel adecuado de protección adicional. Información adicional Si en la auditoría participa un tercero, puede existir el riesgo de que esta tercera organización utilice indebidamente las herramientas de auditoría o de que acceda a la información. Para tratar este riesgo, pueden considerarse los controles descritos en 6.2.1 (para evaluar los riesgos) y 9.1.2 (para restringir el acceso físico) y debería adoptarse cualquier medida en consecuencia, como cambiar inmediatamente las contraseñas reveladas a los auditores.
- 117 - ISO/IEC 27002:2005
BIBLIOGRAFIA Guía ISO/IEC 2:1996 Normalización y actividades relacionadas. Vocabulario general. Guía ISO/IEC 73:2002 Gestión del riesgo. Vocabulario. Directrices para la utilización en las normas ISO/IEC 13335-1:2004 Tecnologías de la Información. Técnicas de seguridad. Gestión de la seguridad de las tecnologías de la información y las comunicaciones. Parte 1: Conceptos y modelos para la gestión de la seguridad de las tecnologías de la información y las comunicaciones ISO/IEC TR 13335-3:1998 Tecnologías de la Información. Técnicas de seguridad. Gestión de la seguridad de las tecnologías de la información y las comunicaciones. Parte 3: Técnicas para la gestión de la seguridad de las TI ISO/IEC 13888-1:1997 Tecnologías de la Información. Técnicas de seguridad. No repudio. Parte 1: Generalidades ISO/IEC 11770-1:1996 Tecnologías de la Información. Técnicas de seguridad. Gestión de claves. Parte 1: Marco conceptual ISO/IEC 9796-2:2002 Tecnologías de la Información. Técnicas de seguridad. Esquemas de firma digital que proporcionan recuperación de mensaje. Parte 2: Mecanismos basados en la factorización de enteros ISO/IEC 9796-3:2000 Tecnologías de la Información. Técnicas de seguridad. Técnicas de seguridad. Esquemas de firma digital que proporcionan recuperación de mensaje Parte 3: Mecanismos basados en logaritmo discreto ISO/IEC 14888-1:1998 Tecnologías de la Información. Técnicas de seguridad. Firmas digitales con apéndice. Parte 1: Generalidades ISO/IEC 15408-1:1999 Tecnologías de la Información. Técnicas de seguridad. Criterios de evaluación para la seguridad de TI. Parte 1: Introducción y modelo general ISO/IEC 14516:2002 Tecnologías de la Información. Técnicas de seguridad. Directrices para el uso y la gestión de los servicios de una tercera parte de confianza ISO 15489-1:1999 Información y documentación. Gestión de documentos. Parte 1: Generalidades. ISO 10007:2003 Sistemas de gestión de la calidad. Directrices para la gestión de la configuración ISO/IEC 12207:1995 Tecnologías de la Información. Procesos de ciclo de vida del software ISO 19011:2002 Directrices para la auditoría de los sistemas de gestión de la calidad y/o ambiental Directrices de la OCDE para la Seguridad de Sistemas y Redes de Información hacia una cultura de seguridad Directrices de la OCDE para una Política Criptográfica IEEE P1363-2000 Especificaciones normalizadas para el cifrado de clave pública ISO/IEC 18028-4 Tecnologías de la Información. Técnicas de seguridad. Seguridad de las redes de TI. Parte 4: Acceso en remoto seguro ISO/IEC TR 18044 Tecnologías de la Información. Técnicas de seguridad. Gestión de incidentes de seguridad de la información
ISO/IEC 27002:2005 - 118 -
ANEXO A (Informativo)
NOTA NACIONAL Es importante señalar que el presente documento, al tener el carácter de norma nacional idéntica a la Norma ISO/IEC 27002:2005, para un lector que se limite a considerar capítulos o apartados de manera aislada, como por ejemplo, el capítulo 8, podría tener la impresión que la norma incurre puntualmente en aspectos que pueden ser objeto de conflicto con la legislación aplicable en el marco español. Pero si la norma se contempla en su totalidad, se verá que sí tiene en cuenta los mencionados aspectos, indicando el de-bido cumplimiento de la legislación aplicable en cada estado. Concretamente, en el apartado 4.2 haciendo referencia al apartado 10.10, se describe como puede ser monitorizado el uso de un sistema y como recoger las evidencias: En el capítulo 4, se indica:
"Algunos de los controles descritos como por ejemplo el registro de eventos, pueden estar en conflicto con la legislación aplicable, como por ejemplo en lo relativo a la protección de la privacidad de los clientes o de los trabajadores.
Por este motivo, en el capítulo 15 se tratan con más detalle los aspectos que deben ser objeto de cumplimiento con la normativa legal aplicable de cada estado.
Génova, 6 [email protected] Tel.: 902 102 201 28004 MADRID-España www.aenor.es Fax: 913 104 032
