Publi PDF AEN 9551 PDF

Gua de aplicacin de la Norma UNE-ISO/IEC 27001
sobre seguridad en sistemas

de informacin para pymes
Luis Gmez Fernndez y Ana Andrs lvarez
2. edicin
(ampliada con el Esquema
Nacional de Seguridad)
AENOR AUTORIZA EL USO DE ESTE DOCUMENTO A CARLOS PRADAS HERRAIZ
Licencia para un usuario - Copia y uso en red prohibidos
Ttulo: Gua de aplicacin de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de informacin para pymes.
2. edicin
Autores: Luis Gmez Fernndez y Ana Andrs lvarez
AENOR (Asociacin Espaola de Normalizacin y Certificacin), 2012
Todos los derechos reservados. Queda prohibida la reproduccin total o parcial en cualquier soporte,
sin la previa autorizacin escrita de AENOR.
ISBN: 978-84-8143-761-4
Impreso en Espaa - Printed in Spain
Edita: AENOR
Maqueta y diseo de cubierta: AENOR
Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.
Gnova, 6. 28004 Madrid Tel.: 902 102 201 Fax: 913 103 695
comercial@aenor.es www.aenor.es
ndice
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Objeto de esta gua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduccin a los Sistemas de Gestin de Seguridad de
la Informacin (SGSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1. Definicin de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2. El ciclo de mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3. La Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1. Origen de la norma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2. Objeto y campo de aplicacin de la norma . . . . . . . . . . . . 17
1.4. La Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2. Objeto y campo de aplicacin . . . . . . . . . . . . . . . . . . . . . . 18
1.5. El Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . . . . . . . . 18
1.5.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.2. Objeto y campo de aplicacin . . . . . . . . . . . . . . . . . . . . . . 19
1.6. Trminos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Comprender la Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . 23
2.1. Requisitos generales del sistema de gestin de la seguridad . . . . . . . 23
2.2. Establecimiento y gestin del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1. Establecimiento del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2. Definicin del alcance del SGSI . . . . . . . . . . . . . . . . . . . . . 27
2.2.3. Definicin de la poltica de seguridad . . . . . . . . . . . . . . . . . 28
Gua de aplicacin de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de informacin para pymes 4
2.2.4. Identificacin de los activos de informacin . . . . . . . . . . . . 28
2.2.5. Definicin del enfoque del anlisis de riesgos . . . . . . . . . . . 29
2.2.6. Cmo escoger la metodologa del anlisis de riesgos . . . . . 30
2.2.7. Tratamiento de los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.8. Seleccin de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.9. Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.10. Declaracin de aplicabilidad . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.11. Implementacin y puesta en marcha del SGSI . . . . . . . . . . . 33
2.2.12. Control y revisin del SGSI . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.13. Mantenimiento y mejora del SGSI . . . . . . . . . . . . . . . . . . . 34
2.3. Requisitos de documentacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2. Control de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3. Control de registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4. Compromiso de la direccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5. Gestin de los recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6. Formacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.7. Auditoras internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.8. Revisin por la direccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8.1. Entradas a la revisin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.8.2. Salidas de la revisin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.9. Mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.9.1. Accin correctiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.9.2. Accin preventiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.10. El anexo A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3. Comprender la Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . 45
3.1. Valoracin y tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2. Poltica de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Organizacin de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4. Gestin de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5. Seguridad ligada a los recursos humanos . . . . . . . . . . . . . . . . . . . . 50
3.6. Seguridad fsica y del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.7. Gestin de comunicaciones y operaciones . . . . . . . . . . . . . . . . . . . . 53
ndice 5
3.8. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.9. Adquisicin, desarrollo y mantenimiento de los sistemas . . . . . . . . . . 64
3.10. Gestin de las incidencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.11. Gestin de la continuidad del negocio . . . . . . . . . . . . . . . . . . . . . . 68
3.12. Cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4. Definicin e implementacin de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . 73
4.1. El proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2. Documentacin del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3. Poltica de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4. Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5. Anlisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6. Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.7. Plan de tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.8. Procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.9. Formacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.10. Revisin por la direccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.11. Auditora interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.12. Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5. Proceso de certificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6. Relacin entre los apartados de la norma y la documentacin del sistema . . 93
7. Correspondencia entre las Normas UNE-EN ISO 9001:2008,
UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007 . . . . . . . . . . . . 97
8. Caso prctico: modelo de SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1. Documentacin de la poltica de seguridad . . . . . . . . . . . . . . . . . . . 101
8.1.1. Poltica de seguridad de la informacin . . . . . . . . . . . . . . . 101
8.1.2. Definicin del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.3. Organizacin e infraestructura de seguridad . . . . . . . . . . . . 103
8.1.4. Clasificacin de la informacin . . . . . . . . . . . . . . . . . . . . . 104
8.1.5. Anlisis de riesgos de seguridad . . . . . . . . . . . . . . . . . . . . . 104
8.2. Documentacin del inventario de activos . . . . . . . . . . . . . . . . . . . . . 105
8.2.1. Procesos de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2.2. Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2.3. Relacin proceso de negocio-activos . . . . . . . . . . . . . . . . . 106
8.2.4. Valoracin de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.3. Documentacin del Anlisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 107
8.3.1. Valoracin del riesgo por activos . . . . . . . . . . . . . . . . . . . . 107
8.3.2. Tramitacin del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.4. Documentacin de la Gestin de riesgos . . . . . . . . . . . . . . . . . . . . . 110
8.4.1. Valoracin del riesgo por activos . . . . . . . . . . . . . . . . . . . . 110
8.5. Documentacin de la Declaracin de aplicabilidad . . . . . . . . . . . . . 114
8.5.1. Controles aplicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.6. Documentacin del Plan de tratamiento del riesgo . . . . . . . . . . . . . . 123
8.6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.3. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.4. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.6.5. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.6.6. Objetivos e indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.7. Documentacin del Procedimiento de auditoras internas . . . . . . . . . 125
8.7.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.7.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.7.4. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.7.5. Requisitos de documentacin . . . . . . . . . . . . . . . . . . . . . . . 128
8.7.6. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.7.7. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.8. Documentacin del Procedimiento para las copias de seguridad . . . . 131
8.8.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.8.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.4. Trminos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.5. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.8.6. Requisitos de documentacin . . . . . . . . . . . . . . . . . . . . . . . 134
8.8.7. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.8.8. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9. Comprender el Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . 137
9.1. Generalidades del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2. Principios bsicos del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.3. Requisitos mnimos de seguridad del ENS . . . . . . . . . . . . . . . . . . . . 140
9.3.1. Organizacin e implementacin del proceso de seguridad . . 140
9.3.2. Anlisis y gestin de los riesgos . . . . . . . . . . . . . . . . . . . . . 140
9.3.3. Gestin de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.3.4. Profesionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.3.5. Autorizacin y control de los accesos . . . . . . . . . . . . . . . . . 141
9.3.6. Proteccin de las instalaciones . . . . . . . . . . . . . . . . . . . . . . 141
9.3.7. Adquisicin de nuevos productos de seguridad . . . . . . . . . . 142
9.3.8. Seguridad por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.3.9. Integridad y actualizacin del sistema . . . . . . . . . . . . . . . . . 142
9.3.10. Proteccin de la informacin almacenada y en trnsito . . . . 143
9.3.11. Prevencin ante otros sistemas de informacin
interconectados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.3.12. Registro de actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.3.13. Incidentes de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.3.14. Continuidad de la actividad . . . . . . . . . . . . . . . . . . . . . . . . 144
9.3.15. Mejora continua del proceso de seguridad . . . . . . . . . . . . . 144
9.3.16. Soporte al cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.4. Otros requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.4.1. Comunicaciones electrnicas . . . . . . . . . . . . . . . . . . . . . . . 145
9.4.2. Auditora de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.4.3. Estado de seguridad de los sistemas . . . . . . . . . . . . . . . . . . 146
9.4.4. Respuesta a incidentes de seguridad . . . . . . . . . . . . . . . . . . 146
9.4.5. Normas de conformidad . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.4.6. Actualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.4.7. Categorizacin de los sistemas . . . . . . . . . . . . . . . . . . . . . 147
9.4.8. Formacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
10. Implementacin del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.1. El plan de adecuacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.2. Adecuacin al ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.1. Planificacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.2. Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7 ndice
10.2.3. Verificacin y validacin . . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.2.4. Actualizacin y mejora continua . . . . . . . . . . . . . . . . . . . . . 155
11. Ejemplo prctico: plan de adecuacin . . . . . . . . . . . . . . . . . . . . . . . . . . 157
11.1. Documentacin de la poltica de seguridad . . . . . . . . . . . . . . . . . . . 157
11.2. Documentacin de la categora del sistema . . . . . . . . . . . . . . . . . . . 158
11.2.1. Criterios de valoracin de los activos . . . . . . . . . . . . . . . . . 158
11.2.2. Categorizacin de sistemas . . . . . . . . . . . . . . . . . . . . . . . . 158
11.3. Documentacin del anlisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 160
11.3.1. Metodologa de anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.3.2. Valoracin de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.3.3. Mapas de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.3.4. Nivel de riesgo aceptable . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.4. Documentacin de la declaracin de aplicabilidad . . . . . . . . . . . . . 164
11.5. Insuficiencias del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.6. Plan de mejora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
12. Bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Normas de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Legislacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Otros documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Links de inters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Norma UNE-ISO/IEC 27001:2007 Tecnologa de la informacin. Tcnicas de
seguridad. Sistemas de Gestin de la Seguridad de la Informacin (SGSI).
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
8 Gua de aplicacin de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de informacin para pymes
Introduccin
La informacin es el principal activo de muchas organizaciones y precisa ser prote-
gida adecuadamente frente a amenazas que puedan poner en peligro la continuidad
del negocio.
En la actualidad, las empresas de cualquier tipo o sector de actividad se enfrentan
cada vez ms con riesgos e inseguridades procedentes de una amplia variedad de
contingencias, las cuales pueden daar considerablemente tanto los sistemas de infor-
macin como la informacin procesada y almacenada.
Ante estas circunstancias, las organizaciones han de establecer estrategias y contro-
les adecuados que garanticen una gestin segura de los procesos del negocio, pri-
mando la proteccin de la informacin.
Para proteger la informacin de una manera coherente y eficaz es necesario imple-
mentar un Sistema de Gestin de Seguridad de la Informacin (SGSI). Este sis-
tema es una parte del sistema global de gestin, basado en un anlisis de los riesgos
del negocio, que permite asegurar la informacin frente a la prdida de:
Confidencialidad: slo acceder a la informacin quien se encuentre autori-
zado.
Integridad: la informacin ser exacta y completa.
Disponibilidad: los usuarios autorizados tendrn acceso a la informacin
cuando lo requieran.
La seguridad total es inalcanzable, pero mediante el proceso de mejora continua
del sistema de seguridad se puede conseguir un nivel de seguridad altamente satis-
factorio, que reduzca al mnimo los riesgos a los que se est expuesto y el impacto
que ocasionaran si efectivamente se produjeran.
El objeto de esta publicacin es facilitar la comprensin de los diversos conceptos
involucrados en un sistema de gestin normalizado y contemplar las recomenda-
ciones generales para la implementacin de un SGSI en una pyme, utilizando la
norma de facto en el mercado internacional para ello, la Norma UNE-ISO/IEC
27001. Tambin se ofrece una visin general de cmo hacerlo en el caso de utilizar el
modelo del Esquema Nacional de Seguridad (ENS), obligatorio por ley en nuestro
pas, para la proteccin de los sistemas que soportan la administracin electrnica,
visin tambin particularmente de inters para pymes que proporcionen servicios
TIC a las Administraciones Pblicas.
Tanto la Norma UNE-ISO/IEC 27001 como el ENS, facilitan la mejora en segu-
ridad, aunque pueden resultar de difcil aplicacin para aquellos que no estn
familiarizados con los conceptos que tratan.
Esta gua no pretende ser preceptiva (existen infinidad de formas de implementar
correctamente la norma y el ENS), sino informativa, proporcionando explicaciones
bsicas de los requisitos de la norma y orientando respecto a la manera en que se
pueden cumplir esos requisitos.
Generalmente, una primera aproximacin a la norma puede infundir desconfianza
en cuanto a la capacidad de la empresa para poder llevar a cabo todos los requeri-
mientos que expresa. Muchos trminos no se utilizan en la actividad cotidiana de
una pyme, tales como riesgos, amenazas, vulnerabilidades. Adems, exige una serie
de tareas desconocidas en la operativa habitual, tales como la realizacin de un an-
lisis de riesgos y la seleccin de controles. Para complicar ms las cosas, se hace
referencia a la Norma UNE-ISO/IEC 27002, que especifica una amplia gama de
controles de seguridad a implementar, en numerosos casos, con una gran carga de
contenido tcnico. Los objetivos, controles e indicaciones contenidos en la Norma
Objeto de esta gua
UNE-ISO/IEC 27002 pueden llegar a ser muy difciles de valorar por un gestor
que no cuente con la informacin o la formacin adecuada, hecho que le impedira
decidir cabalmente sobre cul es su relevancia para la empresa y las consecuencias
de la implementacin o no de un determinado control en ella.
Esta gua pretende suplir semejantes carencias, proporcionando informacin deta-
llada sobre el significado prctico de los requisitos de la norma y explicando con
ejemplos cmo se pueden realizar, teniendo siempre en cuenta la situacin inicial,
los requisitos de seguridad de la empresa y, por supuesto, los recursos disponibles,
ya que sin contar con esto ningn sistema de gestin se hallar bien diseado y, por
lo tanto, estar condenado al fracaso.
Para una mejor comprensin de las implicaciones de los diversos requisitos de la
norma, esta gua incluye un ejemplo prctico, basado en una empresa ficticia, con
la documentacin bsica que debe incluir un SGSI e indicaciones sobre la informa-
cin que debe recoger cada documento.
1.1. Definicin de un SGSI
Un Sistema de Gestin de Seguridad de la Informacin (SGSI), segn la Norma
UNE-ISO/IEC 27001, es una parte del sistema de gestin general, basada en un
enfoque de riesgo empresarial, que se establece para crear, implementar, operar,
supervisar, revisar, mantener y mejorar la seguridad de la informacin. Esto signi-
fica que se va a dejar de operar de una manera intuitiva y se va a empezar a tomar
el control sobre lo que sucede en los sistemas de informacin y sobre la propia
informacin que se maneja en la organizacin. Nos permitir conocer mejor nues-
tra organizacin, cmo funciona y qu podemos hacer para que la situacin
mejore.
La norma especifica que, como cualquier otro sistema de gestin, el SGSI incluye
tanto la organizacin como las polticas, la planificacin, las responsabilidades, las
prcticas, los procedimientos, los procesos y los recursos. Es decir, tanto la docu-
mentacin de soporte como las tareas que se realizan. Los sistemas de gestin que
definen las normas ISO siempre estn documentados, ya que, por un lado, es la
mejor manera de formalizar normas e instrucciones y, por otro, son ms fciles de
transmitir y comunicar, cosa que no sucedera si se confa en un traspaso de infor-
macin verbal informal.
La norma es compatible con el resto de las normas ISO para sistemas de gestin
(UNE-EN ISO 9001 y UNE-EN ISO 14001) y poseen idntica estructura y
requisitos comunes, por lo que se recomienda integrar el SGSI con el resto de los
sistemas de gestin que existan en la empresa para no duplicar esfuerzos.
Incluso cuando no exista un sistema de gestin formal, el amplio conocimiento
actual de estos sistemas hace que las principales caractersticas de la norma sean
1
Introduccin a los
Sistemas de Gestin
de Seguridad de la
Informacin (SGSI)
comprensibles para la mayora de la gente, y que para explicarla en detalle sea
suficiente con incidir en las diferencias fundamentales, a saber, que con un SGSI
lo que tratamos es de gestionar la seguridad de la informacin de nuestra
organizacin.
1.2. El ciclo de mejora continua
Para establecer y gestionar un sistema de gestin de la seguridad de la informacin
se utiliza el ciclo PDCA (conocido tambin como ciclo Deming), tradicional en los
sistemas de gestin de la calidad (vase la figura 1.1). El ciclo PDCA es un con-
cepto ideado originalmente por Shewhart, pero adaptado a lo largo del tiempo por
algunos de los ms sobresalientes personajes del mundo de la calidad. Esta meto-
dologa ha demostrado su aplicabilidad y ha permitido establecer la mejora conti-
nua en organizaciones de todas clases.
El modelo PDCA o Planificar-Hacer-Verificar-Actuar (Plan-Do-Check-Act, de sus
siglas en ingls), tiene una serie de fases y acciones que permiten establecer un
modelo de indicadores y mtricas comparables en el tiempo, de manera que se
pueda cuantificar el avance en la mejora de la organizacin:
Plan. Esta fase se corresponde con establecer el SGSI. Se planifica y disea el
programa, sistematizando las polticas a aplicar en la organizacin, cules son
los fines a alcanzar y en qu ayudarn a lograr los objetivos de negocio, qu
medios se utilizarn para ello, los procesos de negocio y los activos que los
soportan, cmo se enfocar el anlisis de riesgos y los criterios que se segui-
rn para gestionar las contingencias de modo coherente con las polticas y
objetivos de seguridad.
Do. Es la fase en la que se implementa y pone en funcionamiento el SGSI.
Las polticas y los controles escogidos para cumplirlas se implementan
mediante recursos tcnicos, procedimientos o ambas cosas a la vez, y se asig-
nan responsables a cada tarea para comenzar a ejecutarlas segn las instruc-
ciones.
Check. Esta fase es la de monitorizacin y revisin del SGSI. Hay que con-
trolar que los procesos se ejecutan como se ha establecido, de manera eficaz
y eficiente, alcanzando los objetivos definidos para ellos. Adems, hay que
verificar el grado de cumplimiento de las polticas y procedimientos, identi-
ficando los fallos que pudieran existir y, hasta donde sea posible, su origen,
mediante revisiones y auditoras.
15 1. Introduccin a los Sistemas de Gestin de Seguridad de la Informacin (SGSI)
Act. Es la fase en la que se mantiene y mejora el SGSI, decidiendo y efec-
tuando las acciones preventivas y correctivas necesarias para rectificar los
fallos, detectados en las auditoras internas y revisiones del SGSI, o cualquier
otra informacin relevante para permitir la mejora permanente del SGSI.
La mejora continua es un proceso en s mismo. Debe entenderse como la mejora
progresiva de los niveles de eficiencia y eficacia de una organizacin en un pro-
ceso continuo de aprendizaje, tanto de sus actividades como de los resultados
propios.
Dado que la norma se encuentra enfocada hacia la mejora continua, es un esfuerzo
innecesario tratar de implementar un SGSI perfecto en un primer proyecto de este
tipo. El objetivo debera ser disear un SGSI que se ajuste lo ms posible a la reali-
dad de la organizacin, que contemple las medidas de seguridad mnimas e impres-
cindibles para proteger la informacin y cumplir con la norma, pero que consuma
pocos recursos e introduzca el menor nmero de cambios posibles. De esta manera,
el SGSI se podr integrar de una forma no traumtica en la operativa habitual de la
organizacin, dotndola de herramientas con las que hasta entonces no contaba que
puedan demostrar su eficacia a corto plazo.
La aceptacin de este primer SGSI es un factor de xito fundamental. Permitir a
la organizacin ir mejorando su seguridad paulatinamente y con escaso esfuerzo.
Act
Tomar acciones correctivas
y preventivas
Revisar y auditar el SGSI
Definir poltica y alcance
Implementar el SGSI
Plan
Check Do
Figura 1.1. Ciclo PDCA
1.3. La Norma UNE-ISO/IEC 27001
1.3.1. Origen de la norma
ISO (Organizacin Internacional de Normalizacin) e IEC (Comisin Electrotc-
nica Internacional) constituyen el sistema especializado para la normalizacin a
nivel mundial. Los organismos nacionales que son miembros de ISO o IEC parti-
cipan en el desarrollo de las normas internacionales a travs de comits tcnicos
establecidos por las organizaciones respectivas para realizar acuerdos en campos
especficos de la actividad tcnica. Los comits tcnicos de ISO e IEC colaboran en
los campos de inters mutuo.
En el campo de la tecnologa de la informacin, ISO e IEC han establecido un
comit tcnico conjunto, el denominado ISO/IEC JTC 1 (Joint Technical Commit-
tee 1). Los borradores de estas normas internacionales, adoptadas por la unin de
este comit tcnico, son enviados a los organismos de las diferentes naciones para
su votacin. La publicacin como norma internacional requiere la aprobacin de,
por lo menos, el 75% de los organismos nacionales que emiten su voto.
La Norma Internacional ISO/IEC 27002 fue preparada inicialmente por el Insti-
tuto de Normas Britnico (como BS 7799), y adoptada bajo la supervisin del sub-
comit de tcnicos de seguridad del comit tcnico ISO/IEC JTC 1, en paralelo
con su aprobacin por los organismos nacionales miembros de ISO e IEC.
Una vez que fue publicada la Norma ISO/IEC 17799-1 (actualmente se corres-
ponde con la Norma ISO/IEC 27002), Reino Unido (BSI) y Espaa (AENOR)
elevaron al comit internacional sus normas nacionales sobre las especificaciones de
los sistemas de gestin de la seguridad de la informacin (SGSI), BS 7799-2 y
UNE 71502 respectivamente, siendo estas normas el origen de lo que finalmente
acabo publicndose como norma internacional ISO/IEC 27001 en el ao 2005,
que fue adoptada como norma espaola UNE-ISO/IEC 27001 en el ao 2007,
tras un periodo de convivencia con la norma anteriormente mencionada.
Actualmente, tanto la norma ISO/IEC 27001 como la ISO/IEC 27002 estn en
proceso de revisin internacional, y se espera que se publiquen las nuevas versiones
a lo largo del ao 2013.
Como se ha comentado anteriormente, este estndar internacional adopta tambin
el modelo Plan-Do-Check-Act (PDCA), es decir, se basa en un ciclo de mejora con-
tinua que consiste en planificar, desarrollar, comprobar y actuar en consecuencia
con lo que se haya detectado al efectuar las comprobaciones. De esta manera se
conseguir ir refinando la gestin, hacindola ms eficaz y efectiva.
1.3.2. Objeto y campo de aplicacin de la norma
La Norma UNE-ISO/IEC 27001, como el resto de las normas aplicables a los sis-
temas de gestin, est pensada para que se emplee en todo tipo de organizaciones
(empresas privadas y pblicas, entidades sin nimo de lucro, etc.), sin importar el
tamao o la actividad.
Esta norma especifica los requisitos para la creacin, implementacin, funciona-
miento, supervisin, revisin, mantenimiento y mejora de un SGSI documentado,
teniendo en cuenta los riesgos empresariales generales de la organizacin. Es decir,
explica cmo disear un SGSI y establecer los controles de seguridad, de acuerdo
con las necesidades de una organizacin o de partes de la misma, pero no aclara
mediante qu procedimientos se ponen en prctica. Por ejemplo, uno de los princi-
pales requisitos es la realizacin de un anlisis de riesgos con unas determinadas
caractersticas de objetividad y precisin, pero no aporta indicaciones de cul es la
mejor manera de llevar a cabo dicho anlisis. Puede ejecutarse con una herramienta
comercial, con una aplicacin diseada expresamente para la empresa, mediante
reuniones, entrevistas, tablas o cualquier otro mtodo que se estime oportuno.
Todos estos recursos servirn para cumplir la norma, siempre y cuando se observen
los requisitos de objetividad del mtodo, los resultados sean repetibles y la
metodologa se documente.
1.4. La Norma UNE-ISO/IEC 27002
1.4.1. Origen
La Norma UNE-ISO/IEC 27002 Tecnologa de la informacin. Cdigo de buenas
prcticas para la gestin de la seguridad de la informacin, ha sido elaborada por el
AEN/CTN 71/SC 27 Tcnicas de seguridad que pertenece al comit tcnico con-
junto ISO/IEC JTC 1/SC 27 Tecnologa de la informacin. En ambas normas el con-
tenido es idntico, diferencindose nicamente en la numeracin, que ha sido
modificada en el marco de la creacin de la familia de normas ISO 27000.
Esta norma se est desarrollando dentro de una familia de normas internacionales
sobre Sistemas de Gestin de la Seguridad de la Informacin (SGSI). Tal familia
incluye normas internacionales sobre requisitos, gestin del riesgo, mtricas y
mediciones, as como una gua de implementacin de los sistemas de gestin de la
seguridad de la informacin. Dicha familia de normas tiene un esquema de nume-
racin que utilizar los nmeros de la serie 27000.
1.4.2. Objeto y campo de aplicacin
La Norma UNE-ISO/IEC 27002 establece las directrices y principios generales
para el comienzo, la implementacin, el mantenimiento y la mejora de la gestin
de la seguridad de la informacin en una organizacin. Es un catlogo de buenas
prcticas, obtenido a partir de la experiencia y colaboracin de numerosos partici-
pantes, los cuales han alcanzado un consenso acerca de los objetivos comnmente
aceptados para la gestin de la seguridad de la informacin.
Los objetivos de control y los controles de esta norma internacional tienen como
fin servir de gua para el desarrollo de pautas de seguridad internas y prcticas efec-
tivas de gestin de la seguridad. Por ello, la eleccin de los controles permanece
sujeta a lo detectado en un anlisis de riesgos previo, y el grado de implementacin
de cada uno de los controles se llevar a cabo de acuerdo a los requisitos de seguri-
dad identificados y a los recursos disponibles de la organizacin para alcanzar as
un balance razonable entre seguridad y coste.
1.5. El Esquema Nacional de Seguridad (ENS)
1.5.1. Origen
La Ley 11/2007, de 22 de junio, de acceso electrnico de los ciudadanos a los Ser-
vicios Pblicos est siendo el motor y la gua de la administracin electrnica. Esta
ley ha dado paso a una nueva etapa en la gestin de la Administracin Pblica,
impulsando la adopcin de los medios tecnolgicos actualmente disponibles para
realizar tareas de gestin y facilitando a los ciudadanos el acceso a la Administra-
cin Pblica en contextos ms adecuados a la realidad social.
Esta ley, en su artculo 1 reconoce el derecho de los ciudadanos a relacionarse con
las Administraciones Pblicas por medios electrnicos con la misma validez que
por los medios tradicionales, y estipula que stas utilicen las tecnologas de la infor-
macin asegurando la disponibilidad, el acceso, la integridad, la autenticidad, la
confidencialidad y la conservacin de los datos, informaciones y servicios que ges-
tionen en el ejercicio de sus competencias. Tambin determina que la herramienta
para conseguir este objetivo ser el Esquema Nacional de Seguridad, que estable-
cer una poltica de seguridad en la utilizacin de medios electrnicos, y contar
con unos principios bsicos y una serie de requisitos mnimos que permitirn una
proteccin adecuada de los sistemas y la informacin.
El ENS est regulado por el Real Decreto 3/2010, de 8 de enero, que recoge los
requisitos tcnicos y organizativos que se deben cumplir para proteger la informa-
cin dentro del mbito de aplicacin del mismo. Por tanto, se puede decir que trata
la proteccin de la informacin y de los servicios en el mbito de la administracin
electrnica y que, a la luz de principios y requisitos generalmente reconocidos,
exige la gestin continuada de la seguridad, aplicando un sistema de gestin de
seguridad de la informacin.
1.5.2. Objeto y campo de aplicacin
El objeto del ENS es garantizar la seguridad de los servicios prestados mediante
medios electrnicos, de manera que los ciudadanos puedan realizar cualquier tr-
mite con la confianza de que va a tener validez jurdica plena y que sus datos van a
ser tratados de manera segura.
Toda la Administracin Pblica espaola, Administracin General del Estado,
Administraciones de las Comunidades Autnomas, Administraciones Locales, as
como las entidades de derecho pblico vinculadas o dependientes de las mismas,
estn sujetas al cumplimiento de los requisitos del ENS.
Su mbito de aplicacin son los sistemas de informacin, los datos, las comunica-
ciones y los servicios electrnicos, que permitan a los ciudadanos y a las Adminis-
traciones Pblicas el ejercicio de derechos y el cumplimiento de deberes a travs de
medios electrnicos.
1.6. Trminos y definiciones
Para cumplir con las intenciones de este documento, conviene aclarar el significado
de ciertos trminos y definiciones:
Activo
Cualquier bien que tiene valor para la organizacin.
[ISO/IEC 13335-1:2004]
Disponibilidad
La propiedad de ser accesible y utilizable por una entidad autorizada.
[ISO/IEC 13335-1:2004]
Confidencialidad
La propiedad por la que la informacin no se pone a disposicin o se revela
a individuos, entidades o procesos no autorizados.
[ISO/IEC 13335-1:2004]
Seguridad de la informacin
La preservacin de la confidencialidad, la integridad y la disponibilidad de la
informacin, pudiendo, adems, abarcar otras propiedades, como la autenti-
cidad, la responsabilidad, la fiabilidad y el no repudio.
[ISO/IEC 17799:2005]
Evento de seguridad de la informacin
La ocurrencia detectada en un estado de un sistema, servicio o red que indica
una posible violacin de la poltica de seguridad de la informacin, un fallo
de las salvaguardas o una situacin desconocida hasta el momento y que
puede ser relevante para la seguridad.
[ISO/IEC TR 18044:2004]
Incidente de seguridad de la informacin
Un nico evento o una serie de eventos de seguridad de la informacin, ines-
perados o no deseados, que tienen una probabilidad significativa de compro-
meter las operaciones empresariales y de amenazar la seguridad de la infor-
macin.
[ISO/IEC TR 18044:2004]
Sistema de Gestin de la Seguridad de la Informacin (SGSI) [Information
Security Management System, ISMS]
La parte del sistema de gestin general, basada en un enfoque de riesgo
empresarial, que se establece para crear, implementar, operar, supervisar, revi-
sar, mantener y mejorar la seguridad de la informacin.
Nota: el sistema de gestin incluye la estructura organizativa. las polticas, las actividades
de planificacin, las responsabilidades, las prcticas, los procedimientos, los procesos y
los recursos.
Integridad
La propiedad de salvaguardar la exactitud y completitud de los activos.
[ISO/IEC 13335-1:2004]
Riesgo residual
Riesgo remanente que existe despus de que se hayan tornado las medidas
de seguridad.
[ISO/IEC Guide 73:2002]
Aceptacin del riesgo
La decisin de aceptar un riesgo.
Anlisis de riesgos
Utilizacin sistemtica de la informacin disponible para identificar peligros
y estimar los riesgos.
Evaluacin de riesgos
El proceso general de anlisis y estimacin de los riesgos.
Estimacin de riesgos
El proceso de comparacin del riesgo estimado con los criterios de riesgo,
para as determinar la importancia del riesgo.
Gestin de riesgos
Actividades coordinadas para dirigir y controlar una organizacin con res-
pecto a los riesgos.
Tratamiento de riesgos
El proceso de seleccin e implementacin de las medidas encaminadas a
modificar los riesgos.
[ISO/IEC Guide 73:2002].
Nota: en esta norma internacional, el trmino control se utiliza como sinnimo de
medida de seguridad.
Declaracin de aplicabilidad
Declaracin documentada que describe los objetivos de control y los contro-
les que son relevantes para el SGSI de la organizacin y aplicables al mismo.
Nota: los objetivos de control y los controles se basan en los resultados y conclusiones de
la evaluacin de riesgos y en los procesos de tratamiento del riesgo, en los requisitos lega-
les o reglamentarios, en las obligaciones contractuales y en las necesidades empresariales
de la organizacin en materia de seguridad de la informacin.
La seguridad no es el resultado de un proceso, es un proceso en s mismo. Se con-
seguir un nivel de seguridad aceptable en la medida en que este proceso funcione
y progrese adecuadamente.
No es de extraar, por tanto, que la Norma UNE-ISO/IEC 27001 exija que se
adopte un proceso para establecer, implementar, operar, monitorizar, revisar, man-
tener y mejorar el SGSI en una organizacin. Es decir, hay que disearlo, ponerlo
en marcha, comprobar que se obtienen los resultados esperados y, en funcin de
esa evaluacin, tomar acciones para corregir las desviaciones detectadas o intentar
mejorar la situacin, en este caso, la seguridad de la informacin. Y todo ello de
una manera ordenada y metdica, mediante un proceso.
2.1. Requisitos generales del sistema de gestin
de la seguridad
Una organizacin necesita identificar y administrar cualquier tipo de actividad para
funcionar eficientemente. Cualquier actividad que emplea recursos y es adminis-
trada para transformar entradas en salidas, puede ser considerada como un pro-
ceso. A menudo, estas salidas son aprovechadas nuevamente como entradas, gene-
rando una realimentacin.
Habitualmente se piensa que los sistemas de gestin son un conjunto de activida-
des que requieren unos niveles de recursos y dinero que no estn al alcance de una
empresa pequea. Nada ms lejos de la realidad. En infinidad de ocasiones son las
pequeas empresas las que ms se pueden beneficiar de estas iniciativas, ya que
2
Comprender la
Norma UNE-ISO/IEC 27001
carecen de los conocimientos y la cultura que transmiten las normas de manera tan
sinttica y depurada. El xito de un proyecto de implementacin de un SGSI est
fuertemente ligado a la habilidad del promotor de asignar los recursos justos y
necesarios para disear un sistema adecuado a las necesidades de la organizacin.
El sistema debe cumplir con los requisitos de la norma, por supuesto, pero no
menos importante es el cumplimiento de los requisitos del negocio. Cualquier
sistema de gestin debe apoyar el cumplimiento de los objetivos de la organizacin
o no tendr razn de ser.
Los requisitos que exige este estndar internacional son genricos y aplicables a la
totalidad de las organizaciones, independientemente de su tamao o sector de acti-
vidad. En particular, no se acepta la exclusin de los requerimientos especificados
en los apartados 4, 5, 6, 7 y 8 cuando una organizacin solicite su conformidad con
esta norma. Estos apartados son las que realmente conforman el cuerpo principal
de la norma:
Sistema de gestin de la seguridad de la informacin.
Responsabilidad de la direccin.
Auditoras internas del SGSI.
Revisin del SGSI por la direccin.
Mejora del SGSI.
Lo que la norma reclama es que exista un sistema documentado (poltica, anlisis
de riesgos, procedimientos, etc.), donde la direccin colabore activamente y se
implique en el desarrollo y gestin del sistema. Se controlar el funcionamiento
del sistema para que marche correctamente y la mejora sea continua, practicndose
auditoras internas y revisiones del sistema para verificar que se estn obteniendo
los resultados esperados, igualmente se activarn acciones encaminadas a solucio-
nar los problemas detectados en las actividades de comprobacin (auditoras y revi-
siones), a prevenir problemas y a mejorar aquellos asuntos que sean susceptibles
de ello.
El sistema constar de una documentacin en varios niveles (vase la figura 2.1):
Polticas, que proporcionan las guas generales de actuacin en cada caso.
Procedimientos, que dan las instrucciones para ejecutar cada una de las tareas
previstas.
Registros, que son las evidencias de que se han llevado a cabo las actuaciones
establecidas.
25 2. Comprender la Norma UNE-ISO/IEC 27001
Figura 2.1. Niveles de documentacin
Registros
Procedimientos
Polticas
2.2. Establecimiento y gestin del SGSI
2.2.1. Establecimiento del SGSI
La norma establece una serie de requisitos, que se detallan a continuacin (vase la
figura 2.2). Para satisfacerlos, la organizacin debe buscar los medios ms apropia-
dos a sus circunstancias, necesidades y, por supuesto, los recursos disponibles. Debe
recopilarse informacin sobre varios aspectos, tales como a qu se dedica la organi-
zacin, qu necesidades de seguridad precisa teniendo en cuenta su actividad, y el
mbito en el que opera, as como las restricciones legales a las que puede estar
sujeta dicha actividad.
Los requisitos en muchos casos no se encuentran definidos. La organizacin sabe,
en trminos generales, qu nivel de seguridad desea, pero no existen mecanismos
para expresarlo y documentarlo. Hay que concretar esas necesidades que se perci-
ben para poder comenzar el diseo del SGSI. Sabiendo qu se necesita se podrn
proponer opciones y tomar decisiones. Es fundamental no comprometer recursos
difciles de conseguir. Hay que ser realista con los recursos disponibles en cada
momento y dimensionar el proyecto de acuerdo con las prioridades del negocio.
Cuando una empresa decide adaptarse a esta norma (vase la figura 2.3), bsica-
mente se emprendern las actividades que se detallan a continuacin, y que como
tienen que ser documentadas, al finalizarlas, el SGSI contar ya con los siguientes
documentos:
Poltica de seguridad, que contendr las directrices generales a las que se
ajustar la organizacin en cuanto a seguridad, as como la estrategia a seguir
a la hora de establecer objetivos y lneas de actuacin. La poltica estar ali-
neada con el resto de los objetivos del negocio y polticas de gestin que
existan en la organizacin. Esta poltica estar aprobada por la direccin.
Inventario de activos, que detallar los activos dentro del alcance del SGSI,
as como los propietarios y la valoracin de tales activos.
Anlisis de riesgos, con los riesgos identificados basndose en la poltica de
la organizacin sobre seguridad de la informacin y el grado de seguridad
requerido.
SGSI
Contratos
ISO 27001
Leyes
Negocio
Reglamentos
Recursos
Figura 2.2. Requisitos del SGSI
Las decisiones de la direccin respecto a los riesgos identificados, as como
la aprobacin de los riesgos residuales.
Documento de aplicabilidad con la relacin de los controles que son aplicables
para conseguir el nivel de riesgo residual aprobado por la direccin.
2.2.2. Definicin del alcance del SGSI
Es decir, sobre qu proceso (o procesos) va a actuar, ya que no es necesaria la apli-
cacin de la norma a toda la entidad. Hay que evaluar los recursos que se pueden
dedicar al proyecto y si realmente es preciso abarcar toda la organizacin. Normal-
mente es ms prctico limitar el alcance del SGSI a aquellos servicios, departamentos
o procesos en los que resulte ms sencillo, bien porque el esfuerzo va a ser menor
o porque la visibilidad del proyecto (interna o externa) es mayor. En cualquier caso,
Figura 2.3. Establecer el SGSI
Definir
alcance
Definir poltica
de seguridad
Identificar activos
Identificar los riesgos
Analizar los riesgos
Tratar los riesgos
Definir el enfoque
de anlisis
hay que tener en cuenta que dimensionar correctamente el proyecto es fundamental
para alcanzar el xito. Embarcarse en un proyecto costoso, complejo, que se alarga
en el tiempo, con falta de resultados, est abocado al fracaso.
2.2.3. Definicin de la poltica de seguridad
Decidir qu criterios se van a seguir, estableciendo las principales lneas de accin
que se van a seguir para que la confidencialidad, la integridad y la disponibilidad
queden garantizadas. Esta poltica tendr en cuenta los requisitos del negocio, los
contractuales y los legales y estatutarios que sean aplicables. Es primordial incorpo-
rar en esta fase inicial las necesidades de la organizacin. Aunque a veces son difci-
les de expresar y documentar, es esencial que el SGSI est alineado con el resto de
las estrategias, planes y modos de funcionar de la organizacin para que pueda inte-
grarse en el da a da sin complicaciones y rindiendo resultados desde el principio.
Cuando resulte posible, ser til recopilar los documentos de seguridad existentes
en la organizacin para incorporarlos desde el principio al sistema. La poltica de
seguridad debe dejar claras las normas bsicas de seguridad en la organizacin,
definiendo cul va a ser el comportamiento de la misma en cuanto a los usos de la
informacin y de los sistemas, los accesos, cmo se gestionarn las incidencias, etc.
Los empleados deben conocer esta poltica y adherirse a ella, incluso formalmente
si es necesario.
2.2.4. Identificacin de los activos de informacin
Se deben identificar junto con sus responsables. El SGSI va a proteger los activos
que queden dentro del alcance definido, por eso es vital listarlos todos, lo cual no
significa que haya que detallar cada componente de los sistemas de informacin y
cada documento que se maneje en la empresa, pero s es indispensable identificar
qu activos son los que soportan los procesos de la organizacin. Es decir, qu hace
falta para que la empresa funcione: los equipos, las aplicaciones, los informes, los
expedientes, las bases de datos, las comunicaciones, etc. Para ello, lo primero es
identificar los activos dentro del alcance del SGSI (hardware, software, infraestruc-
turas, aplicaciones, servicios, etc.) junto con los responsables de estos activos.
Una vez identificados deben valorarse, de manera que se puedan categorizar, ya
que es probable que este inventario de activos sea voluminoso, por lo que no es
viable realizar un anlisis de riesgos sobre todos ellos. De acuerdo con la relevancia
que la organizacin otorgue a los activos, se escoger el grupo de los ms valiosos
para efectuar el anlisis de riesgos. Esta tarea consume gran parte de los recursos del
proyecto, por lo que es conveniente simplificarla ya desde esta fase.
Los activos deben relacionarse con los procesos de negocio que soportan, de
forma que quede explcita la dependencia del negocio respecto de esos activos.
La norma es bastante clara al respecto. El SGSI debe apoyar la consecucin de
los objetivos de negocio. Se realiza una gestin para obtener unos resultados, la
seguridad de la informacin no es una excepcin. Su gestin ha de estar orien-
tada en todo momento a que la organizacin funcione ms y mejor y consiga sus
propsitos. Como la seguridad parece un tema muy tcnico se puede caer en el
error de considerar que es un problema que deben solucionar los informticos.
No cabe duda de que la seguridad de la informacin consta de un destacable
componente tcnico y que el personal tcnico debe estar involucrado activamente
en el diseo, desarrollo y mantenimiento de un SGSI, pero recordemos que esta-
mos hablando de un sistema de gestin, por lo que la parte de gestin es tanto
o ms importante que la parte tcnica. Un sistema no funciona si el personal que
lo debe utilizar no lo hace. Como prueba, slo hay que pensar que las incidencias
ms graves de seguridad no suelen tener su origen en fallos tcnicos, sino en fallos
humanos.
2.2.5. Definicin del enfoque del anlisis de riesgos
Hay que decidir cmo se enfocar el anlisis de riesgos. El anlisis de riesgos deter-
minar las amenazas y vulnerabilidades de los activos de informacin previamente
inventariados. Esta tarea es crucial para el correcto diseo del SGSI, puesto que de
su resultado depende que se escojan unos controles u otros, que son los que con-
formarn nuestro sistema.
Como es una tarea laboriosa, se buscan mtodos para que su ejecucin sea ms
simple sin dejar de ser rigurosa. Primeramente se elige el nivel de detalle con el
que se va a llevar a cabo el anlisis, enfoque de mnimos o detallado, y despus
el grado de formalidad, enfoque informal o formal. Estas categoras no son exclu-
yentes, es decir, se puede optar por un enfoque detallado y formal para un grupo
de activos muy crticos, para otro grupo importante se hace un anlisis detallado e
informal y para un tercer grupo de menor relevancia, un enfoque de mnimos.
Esto se llamara enfoque mixto. En un enfoque de mnimos se establece un nivel
bsico de seguridad para los sistemas, efectuando una simplificacin del inventario
de activos y del anlisis de riesgos que consuma los recursos mnimos. Con un
enfoque detallado se realizan revisiones detalladas del anlisis de riesgos para todos
los sistemas, se identifican todos los riesgos y la evaluacin de sus magnitudes.
Como estas tareas consumen muchos recursos, no se suele utilizar un enfoque deta-
llado para todos los activos, slo para los ms notables.
2.2.6. Cmo escoger la metodologa del anlisis
de riesgos
Puesto que la norma nicamente establece que los resultados han de ser compara-
bles y repetibles, debe escogerse aquella metodologa que mejor se adapte a los
modos de trabajo de la organizacin, as el ejercicio se integrar sin problemas en
el trabajo cotidiano. Adems, ayuda a que los resultados sean ms aceptables por la
organizacin y a que se pueda mantener en el tiempo. Si la metodologa escogida
es excesivamente complicada y requiere mucho esfuerzo para llevar a cabo el anlisis,
la carga de trabajo aadida complicar el proyecto, y los resultados pueden parecer
poco fiables por los no implicados directamente en su obtencin, puesto que ser
difcil explicarlos.
Identificar los riesgos que pueden afectar a la organizacin y a sus activos de infor-
macin. Hay que saber cules son los peligros a los que se enfrenta la empresa, los
puntos dbiles, para poder solucionar de manera efectiva los problemas, insistiendo
con ms recursos y esfuerzos en los temas que ms lo necesitan. Un SGSI tiene que
incluir medidas de seguridad apropiadas a los riesgos a los que la organizacin debe
enfrentarse, para ello se plantear un anlisis de riesgos que determine el nivel de
riesgo existente sobre los activos de informacin de la empresa. Con un mtodo
de anlisis de riesgos ya escogido se identificarn las amenazas sobre estos activos,
las vulnerabilidades que podran ser explotadas por las amenazas y los impactos que
pueden tener en los activos. El riesgo se define a menudo como la funcin del dao
que podra producir una amenaza por la probabilidad de que eso ocurra. Cuantifi-
cando estos parmetros, se obtendrn los valores de riesgo para cada activo.
Definir los criterios para aceptar los riesgos y seleccionar los controles, de manera
proporcional a los riesgos detectados y a los recursos disponibles. En la prctica, el
punto de corte para decidir si se acepta un riesgo o no va a venir dado por los
recursos que se le puedan asignar al SGSI. Puesto que tendremos valores para cada
uno de los activos, se decidir a la vista de los mismos dnde se halla el valor por
debajo del cual ya no podremos hacer ms de lo que se ha hecho. Aplicar controles
a todos los activos no suele ser viable ni organizativa ni econmicamente.
Una vez definidos los lmites, condicionantes y requisitos que debe cumplir el
SGSI, puesto que en la norma no se requiere que exista un Manual de seguridad en
la lnea de otras normas de gestin, toda esta informacin debe quedar plasmada
en parte de los documentos que compondrn el SGSI. En particular es necesario
documentar en esta fase:
La poltica de seguridad, que adems debe aprobarse por la direccin.
La metodologa a seguir para realizar el anlisis de riesgos.
2.2.7. Tratamiento de los riesgos
Obtenidos los niveles de riesgo, hay que decidir si son aceptables o no, segn el cri-
terio fijado previamente. Si no lo son, hay que evaluar cmo se van a tratar esos
riesgos:
Mitigar el riesgo. Es decir, reducirlo, mediante la implementacin de controles
que disminuyan el riesgo hasta un nivel aceptable.
Asumir el riesgo. La direccin tolera el riesgo, ya que est por debajo de un
valor de riesgo asumible o bien porque no se puede hacer frente razonable-
mente a ese riesgo, por costoso o por difcil. La direccin debe firmar que
los activos con un valor de riesgo inferior no estarn sometidos a controles
que mitiguen el riesgo.
Transferir el riesgo a un tercero. Por ejemplo, asegurando el activo que tiene
el riesgo o subcontratando el servicio. An as, evidenciar que la responsabi-
lidad sobre el activo permanece siempre en manos de la organizacin y tener
en cuenta que hay daos, como los causados a la reputacin de la organiza-
cin, que difcilmente son cubiertos por ningn seguro.
Eliminar el riesgo. Aunque no suele ser la opcin ms viable, ya que puede
resultar complicado o costoso.
Tambin se puede optar por una estrategia que combine dos o ms de estas elec-
ciones. Por ejemplo, un sistema muy crtico y con mucho riesgo puede decidirse a
aplicar controles que mitiguen el riesgo en los aspectos operativos cotidianos y sub-
contratar los cambios con lo que se transferir parte del riesgo al contratista. La
opciones ms habituales son las de mitigar y asumir. Cuando se resuelva mitigar el
riesgo, los controles deben ser seleccionados e implementados teniendo en cuenta
los requisitos identificados y el resultado del anlisis de riesgos.
2.2.8. Seleccin de controles
La norma especifica que los controles deben ser seleccionados de entre los listados
en el anexo A de la propia norma, es decir, los que la Norma UNE-ISO/IEC 27002
contiene. En caso necesario, se pueden aadir otros, pero esta lista de controles es
un slido punto de partida para elegir las medidas de seguridad apropiadas para
el SGSI, asegurando que ningn aspecto o control importante se pasan por alto.
La seleccin de controles es un punto crtico del SGSI. A la hora de escoger o
rechazar un control se debe considerar hasta qu punto ese control va a ayudar
a reducir el riesgo que hay y cul va a ser el coste de su implementacin y mante-
nimiento. Cabe la posibilidad de que un control que se estime oportuno imple-
mentar, sea demasiado costoso o difcil de implementar para la organizacin, por
resistencia al cambio o por falta de formacin, y que haya que excluirlo de la selec-
cin por esos motivos. Un SGSI no tiene necesariamente que tener cubiertos todos
y cada uno de los riesgos a los que se est expuesto, sino que tratar de mitigarlos
de acuerdo con las necesidades del negocio. Las necesidades de seguridad de un
banco y de un almacn de madera son radicalmente distintas, y eso significa que
sus SGSI tambin han de serlo. Nunca el coste de implementacin y manteni-
miento de un control debe superar a los beneficios que se esperan de l.
2.2.9. Gestin de riesgos
Una vez seleccionados los controles se repetir el anlisis de riesgos, teniendo en
cuenta ya todas las medidas de seguridad implementadas y aquellas elegidas para
hacerlo. El valor del riesgo obtenido ser el riesgo actual, en funcin del que se
determina el riesgo asumible por la organizacin, y se deciden las nuevas estrate-
gias y acciones para reducir los riesgos que estn por encima de ese valor.
Una tercera iteracin del anlisis de riesgos que contemplan las medidas previstas,
nos dar los riesgos residuales.
La direccin debe aprobar el valor de riesgo aceptable y asumir el riesgo residual.
2.2.10. Declaracin de aplicabilidad
El siguiente requisito de la norma es la preparacin de una declaracin de aplicabi-
lidad, que debe incluir:
Los objetivos de control y los controles seleccionados, con las razones de
esta seleccin.
Los objetivos de control y los controles actualmente implementados, con
una justificacin.
La exclusin de cualquier control objetivo del control y de cualquier control
en el anexo A y la justificacin para dicha exclusin.
Esta declaracin de aplicabilidad sirve para comprobar que realmente se han consi-
derado todas las opciones de controles disponibles y que no se ha omitido ninguno.
2.2.11. Implementacin y puesta en marcha del SGSI
Para poner en marcha el SGSI la direccin tiene que aprobar la documentacin desa-
rrollada en las actividades detalladas en el punto anterior y proveer los recursos
necesarios para ejecutar las actividades.
Estas actividades se registrarn en un plan de tratamiento del riesgo que regule todas
las acciones necesarias para tratarle, adems de los recursos, las responsabilidades y las
prioridades para la gestin de los riesgos de seguridad de la informacin.
Tan importante como la definicin de las tareas a realizar y los recursos que se van a
asignar, es decidir cmo se va a medir la eficacia de estas acciones y de las medidas de
seguridad aplicadas. Esto implica establecer un conjunto de objetivos y mtricas aso-
ciadas a los mismos, tanto para los procesos como para las medidas de seguridad, que
permitan evaluar de manera objetiva y precisa el avance en la mejora de la seguridad.
La seguridad de la informacin es una cuestin multidisciplinar e importante para
cada proyecto y sistema y para todos los usuarios en la organizacin. La asignacin
y delimitacin de responsabilidades debe asegurar que se acometen todas las tareas
relevantes y que se llevan a cabo de un modo eficiente. Si bien este objetivo puede
lograrse a travs de diversos esquemas, dependiendo de la estructura y tamao de
la organizacin, en cualquier caso se ha de de contar con la designacin de:
Un responsable de seguridad, que coordine las tareas y esfuerzos en materia de
seguridad. Actuar como foco de todos los aspectos de seguridad de la organi-
zacin y sus responsabilidades cubrirn todas las funciones de seguridad.
Un comit de seguridad que trate y busque soluciones a los temas de seguri-
dad, resuelva los asuntos interdisciplinarios y apruebe directrices y normas.
Ambos, el comit de seguridad y el responsable de seguridad de la organizacin,
deben tener sus tareas bien delimitadas y encontrarse a un nivel suficiente en la
estructura de la organizacin, de forma que pueda asegurarse el compromiso con
la poltica de seguridad. La organizacin debe proporcionar lneas claras de comu-
nicacin, responsabilidad y autoridad al responsable de seguridad, y sus tareas han
de ser aprobadas por el comit de seguridad.
2.2.12. Control y revisin del SGSI
La revisin del SGSI forma parte de la fase del Check (comprobar) del ciclo PDCA.
Hay que controlar y revisar el SGSI de manera peridica para garantizar la conve-
niencia, adecuacin y eficacia continuas del sistema.
Para efectuar la revisin hay que recopilar informacin de los resultados de las dis-
tintas actividades del SGSI para comprobar si se estn alcanzando los objetivos, y,
si no es as, averiguar las causas y buscar soluciones.
Las revisiones consistirn en estudiar los resultados de las auditoras de seguridad,
los incidentes, los resultados de la eficacia de las mediciones, las sugerencias y las
opiniones de todas las partes interesadas. Hay que medir la eficacia de los controles
para verificar que se han cumplido los requisitos de seguridad.
Adems, hay que revisar los anlisis del riesgo a intervalos planificados y examinar
los riesgos residuales, as como los niveles aceptables del riesgo, teniendo en cuenta
los cambios en la organizacin, la tecnologa, los objetivos y procesos del negocio,
las amenazas identificadas, la eficacia de los controles implementados, los cambios
en el entorno legal o reglamentarios, cambios en las obligaciones contractuales y
cambios en el entorno social. Las auditoras internas del SGSI tambin forman
parte de esta fase de revisin.
Las revisiones del SGSI tienen que estar planificadas y gestionadas para asegurar
que el alcance contina siendo adecuado y que se han identificado mejoras en el
proceso del SGSI.
En cualquier caso, todos los resultados de las revisiones deben ser documentados
para proporcionar evidencia de su realizacin, involucrar a la direccin en la ges-
tin del sistema y apoyar las acciones de mejora, as como para actualizar los planes
de seguridad.
2.2.13. Mantenimiento y mejora del SGSI
La seguridad es un proceso en continuo cambio. Las organizaciones no son estti-
cas y su gestin tampoco lo es. Por lo tanto, sera un grave error considerar que una
vez analizados los riesgos y definidas las medidas para reducirlos se haya terminado
el trabajo. Los cambios en la organizacin impactarn en los niveles de riesgo y a la
inversa, y tiene que haber mecanismos que acomoden estos cambios y mantengan
el nivel de seguridad en un nivel aceptable.
Un sistema de gestin debe mantenerse y mejorarse en lo posible para que resulte
efectivo. El mantenimiento incluye el detectar mejoras e implementarlas, aprender
de los defectos y errores identificados, y aplicar acciones correctivas y preventivas
donde sea apropiado.
2.3. Requisitos de documentacin
2.3.1. Generalidades
El SGSI debe contar con la documentacin necesaria que justifique las decisiones
de la direccin, las polticas y las acciones tomadas y que se pueda demostrar que
los controles seleccionados lo han sido como resultado de estas decisiones y del
anlisis de riesgos. Es decir, se debe delinear la trazabilidad que se ha de seguir
desde las polticas y objetivos hasta los controles implementados.
Por ello es necesario tener documentado:
La poltica y los objetivos del SGSI.
El alcance del SGSI.
Una descripcin de la metodologa de anlisis del riesgo.
El inventario de activos.
Los procedimientos y controles de apoyo al SGSI.
El anlisis del riesgo.
El plan de tratamiento del riesgo.
La declaracin de aplicabilidad.
Los procedimientos necesarios para la implementacin de los controles y
para asegurarse de que se cumplan los objetivos.
Los registros requeridos por la norma.
La norma no exige ningn tipo de formato para los documentos ni para los regis-
tros, cualquier soporte es vlido.
2.3.2. Control de documentos
Los documentos requeridos por el SGSI deben hallarse protegidos y controlados,
por lo que se precisan unos procedimientos de control de documentacin, de revi-
sin y de registro (informes, auditoras, cambios, autorizaciones de acceso, permisos
temporales, bajas, etc.).
Los procedimientos de documentacin deben contemplar cmo se generan, aprue-
ban, revisan y actualizan los documentos segn sea necesario.
Una buena gestin documental contar con que los cambios sean identificados y
que la identificacin de los documentos y su estado resulten claras.
Los documentos deben estar disponibles y accesibles en todos los puntos en los que
sea necesario utilizarlos. Adems, hay que comprobar que el almacenamiento sea
correcto y que cuando haya que destruir los documentos se haga de acuerdo con su
clasificacin. Cuando un documento quede obsoleto hay que retirarlo para evitar
su uso.
2.3.3. Control de registros
Los registros son aquellos documentos que proporcionan evidencia de la realiza-
cin de actividades del SGSI. Con ellos se puede verificar el cumplimiento de los
requisitos. Ejemplo de registros son el libro de visitas, los informes de auditoras y
los logs de los sistemas.
Los registros estarn protegidos y controlados teniendo en cuenta cualquier requi-
sito de tipo legal, reglamentario u obligacin contractual. Permanecern legibles,
fcilmente identificables y recuperables. Los controles necesarios para la identificacin,
almacenamiento, proteccin, recuperacin, tiempo de conservacin y disposicin
de los registros se encontrarn documentados e implementados.
Debern guardarse todos los registros del funcionamiento del proceso y las inci-
dencias de seguridad significativas relacionadas con el SGSI.
2.4. Compromiso de la direccin
Uno de los requisitos fundamentales para poner en marcha un SGSI es contar
con el compromiso de la direccin, no slo por ser uno de los epgrafes contem-
plados en la norma, sino porque el cambio de cultura y concienciacin que
genera el proceso sera imposible de sobrellevar sin el compromiso constante de
la direccin.
El desarrollo, la implementacin y el mantenimiento del SGSI exigen un esfuerzo
organizativo importante, que nicamente podra llevarse a cabo con una voluntad
clara de hacerlo por parte de la direccin, puesto que es ella quien tiene que pro-
veer de recursos al proyecto, tanto financieros como humanos, por lo que su apoyo
es imprescindible.
La direccin debe comprometerse de manera evidente con el establecimiento,
implementacin, puesta en marcha, monitorizacin, revisin, mantenimiento y
mejora del SGSI. La forma en la que se plasma este compromiso es colaborando o
ejecutando, segn los casos, las siguientes tareas:
Establecer la poltica del SGSI.
Asegurar que se establecen los objetivos y planes del SGSI.
Asignar los roles y las responsabilidades para la seguridad de la informa-
cin.
Comunicar a la organizacin la conveniencia del cumplimiento de los obje-
tivos de seguridad de la informacin y, conforme a la poltica de seguridad
de la informacin, sus responsabilidades legales y la necesidad de la mejora
continua.
Proporcionar recursos suficientes para implementar, mantener y mejorar
el SGSI.
Decidir los criterios de aceptacin de los riesgos.
Verificar que se realizan las auditoras internas del SGSI.
Dirigir la gestin de las revisiones del SGSI.
2.5. Gestin de los recursos
Como se comentaba anteriormente, es la direccin la que debe gestionar los
recursos. Ha de comenzar por proveer de recursos al desarrollo y mantenimiento
del SGSI en funcin de lo que se estime necesario para establecer, implementar,
poner en funcionamiento, efectuar el seguimiento, revisar, mantener y mejorar el
SGSI.
Hay que contar con las diversas tareas que implica el funcionamiento, la verifica-
cin y la mejora del sistema, puesto que conservar el nivel de seguridad que aporta
el SGSI slo puede lograrse comprobando regularmente que los procedimientos
de seguridad estn alineados con el negocio, que cumplen con los requisitos legales,
que los controles estn correctamente implementados y que se llevan a cabo las
acciones oportunas para corregir errores y mejorar el sistema.
Captulo aparte merece la gestin de los recursos humanos. Este punto es uno de
los factores crticos de xito. Sin una colaboracin activa del personal es muy difcil
implementar con xito un SGSI.
2.6. Formacin
La norma exige que todos los trabajadores con responsabilidades definidas en el
SGSI sean competentes para efectuar las actividades necesarias. Esto significa que
hay que definir las competencias necesarias y, en funcin de tales necesidades,
proporcionar la formacin a la plantilla o adoptar otras acciones para satisfacerlas
(por ejemplo, la contratacin de personal competente).
Como cualquier otra actividad, requiere una planificacin, as como verificar que
se cumplen los objetivos y mantener los registros de educacin, formacin y cuali-
ficacin de los empleados.
Independientemente de la formacin, el personal estar concienciado de la impor-
tancia de las actividades de seguridad de la informacin y en particular de las suyas
propias, y de que cmo la aportacin de cada uno es fundamental para alcanzar los
objetivos de seguridad establecidos, y en consecuencia los de la organizacin.
En la medida que seamos capaces de formar al personal y concienciarlo de que es
fundamental ceirse a las normas de seguridad, reduciremos drsticamente la pro-
babilidad de fallos y su potencial impacto.
2.7. Auditoras internas
Una de las herramientas ms interesantes para controlar el funcionamiento del
SGSI son las auditoras internas. Estas auditoras deben programarse y prepararse
regularmente, normalmente una vez al ao. Esta programacin se recoger en el
plan de auditoras.
A la hora de desarrollar el plan de auditoras hay que fijarse en:
El estado e importancia de los procesos y las reas que sern auditadas, de
este modo se determinar el tiempo y los recursos que habr que destinar
para efectuar la auditora.
Los criterios de la auditora.
El alcance, si va a ser global (va a abarcar toda la empresa) o parcial (slo una
parte).
La frecuencia de realizacin de las auditoras, sabiendo que cada tres aos, al
menos, toda la organizacin debe ser auditada.
Los mtodos que se van a utilizar para hacer las auditoras.
El plan ha de estar aprobado por la direccin. Una vez preparado y aprobado, debe
distribuirse a todos los departamentos y a los auditores afectados con la suficiente
antelacin, de manera que puedan preparar adecuadamente la auditora.
Las auditoras internas sirven para determinar si los objetivos, los controles y los
procedimientos son conformes con los requisitos aplicables (los de la propia
norma, los de negocio, los legales, los de seguridad, etc.), as como el grado de
implementacin que tienen, si se estn aplicando bien y si los resultados obtenidos
son los esperados.
Debe existir un procedimiento documentado que defina las responsabilidades y los
requisitos para planificar y dirigir las auditoras, para informar de los resultados y para
mantener los registros, tales como el informe de auditora emitido por los auditores.
El responsable del rea auditada debe asegurar que las acciones para eliminar las
no conformidades detectadas y sus causas se llevan a cabo en un plazo razonable.
El seguimiento de las actividades debe incluir la verificacin de las acciones tomadas
y el informe de la verificacin de los resultados.
Es importante la seleccin de los auditores, ya que no deben auditar su propio tra-
bajo, slo siendo independientes se puede garantizar la imparcialidad.
2.8. Revisin por la direccin
La direccin debe revisar el SGSI de manera peridica para garantizar la conve-
niencia, adecuacin y eficacia continuas del sistema. El proceso de revisin por la
direccin no debera ser un ejercicio ejecutado nicamente para cumplir los requi-
sitos de la norma y de los auditores, sino que debera ser una parte integral del pro-
ceso de gestin del negocio de la organizacin.
Para realizar esta revisin hay que recopilar informacin de los resultados de las dis-
tintas actividades del SGSI para comprobar si se estn alcanzando los objetivos, y
si no es as, averiguar las causas y decidir sobre las posibles soluciones.
Esta revisin es una de las pocas tareas que se le asigna especficamente a la direccin,
por lo que posee relevancia en varios aspectos: mantiene a la direccin en contacto
con la realidad del SGSI, ya que lgicamente no se encuentra involucrada en el da a
da, pero es importante que est al tanto de los trabajos realizados, de los logros obte-
nidos y de los problemas que aparezcan. Adems es una herramienta para aportar ini-
ciativas al SGSI, ya que es la direccin la encargada de la visin estratgica de la
empresa, la que determina hacia dnde debe ir y cmo. Como herramienta de ges-
tin que es, el SGSI debe incorporar esta visin y colaborar para hacerla viable.
2.8.1. Entradas a la revisin
Los resultados de la revisin deben ser documentados para proporcionar evidencia
de su realizacin, involucrar a la direccin en la gestin del sistema y apoyar las
acciones de mejora.
Las entradas a la revisin pueden ser:
Los resultados de las auditoras y las revisiones del SGSI.
Comentarios de las partes interesadas (usuarios de los sistemas de informa-
cin, contratistas, clientes, etc.).
Tcnicas, productos o procedimientos que podran ser empleados en la orga-
nizacin para mejorar el funcionamiento y la efectividad del SGSI.
El estado de las acciones preventivas y correctivas.
Las vulnerabilidades o amenazas que no se han tratado adecuadamente en
anlisis de riesgos anteriores.
Los resultados de las mtricas de efectividad.
Las acciones de seguimiento de anteriores revisiones por la direccin.
Cualquier cambio que pudiera afectar al SGSI.
Recomendaciones para la mejora.
Con esta informacin se puede tener una visin general de hasta qu punto el SGSI
est funcionando bien, mal o no todo lo bien que se esperaba. Investigando en las
causas de los fallos o dificultades encontradas se pueden corregir los errores y mejorar
el rendimiento del sistema, que en definitiva es el objetivo de la revisin, adems
de involucrar a la direccin activamente en la gestin del sistema.
2.8.2. Salidas de la revisin
Los resultados de la revisin pueden ser de varios tipos:
Identificacin de acciones para mejorar la efectividad del SGSI.
Actualizacin de la evaluacin y la gestin de riesgos.
Modificacin de los procedimientos y controles que afectan a la seguridad
de la informacin para ajustarse a incidentes o cambios en:
Requisitos de negocio, de seguridad o legales.
Procesos de negocio que tengan efecto en los requisitos de negocio exis-
tentes.
Obligaciones contractuales.
Niveles de riesgo y/o criterios para aceptar los riesgos.
Necesidades de recursos.
Realizacin de mejoras en la manera de medir la efectividad de los con-
troles.
La revisin, aunque se centre en la deteccin y resolucin de problemas en la gestin
y operativa del SGSI, debe considerar tambin los puntos fuertes, es decir, qu se
est haciendo bien y la razn, sobre todo en comparacin con revisiones anteriores,
de manera que se ponga en evidencia la mejora continua del sistema.
Como resultado del proceso de revisin por la direccin, debera existir evidencia
de decisiones relacionadas con cambios en la poltica y los objetivos de seguridad,
los planes, presupuestos o acciones de mejora.
Se requieren registros de la revisin por la direccin, pero no se especifica su
formato. Las actas de las reuniones son el tipo ms comn de registro, pero los
registros electrnicos, los diagramas estadsticos, las presentaciones, etc., podran
ser tipos de registro aceptables.
El informe de revisin por la direccin suele realizarlo el responsable de seguridad
y discutirse dentro del comit de seguridad, aunque es la direccin quien debe
aprobarlo una vez consensuado.
2.9. Mejora continua
La mejora continua es una actividad recurrente para incrementar la capacidad a la
hora de cumplir los requisitos. El proceso mediante el cual se establecen objetivos
y se identifican oportunidades de mejora es continuo.
Es un punto fundamental en cualquier sistema de gestin segn las normas ISO.
Este concepto tambin es crucial en todos los modelos de mejora de procesos o
negocio que existen. En pura lgica, cualquier organizacin desea hacer las cosas
cada vez mejor (mejores productos, ms baratos, en menos tiempo, mayores bene-
ficios), por lo que la mejora continua es un concepto empresarial de primer orden.
Los sistemas de gestin tendrn por tanto que apoyar este proceso, que se reali-
menta a s mismo y nunca termina, ya que siempre se puede mejorar en algo.
Cuando una organizacin se considera madura, es decir, cuando la mejora conti-
nua forma parte de la cultura de la empresa y se obtiene el mximo rendimiento de
los procesos, es porque todos los niveles de la organizacin estn involucrados y la
direccin ha hecho de la mejora continua una de las herramientas fundamentales
para la gestin del negocio. Aunque la mejora continua es un proceso que debe ser
impulsado desde la direccin, su implementacin se realizar en la base, donde se
ejecuta el trabajo.
Las principales herramientas para la mejora continua son las revisiones, las audito-
ras, las acciones correctivas, preventivas y de mejora, los objetivos y el anlisis de
los incidentes de seguridad. Los resultados de estas actividades son una valiossima
fuente de informacin sobre cules son los puntos dbiles de la organizacin y sus
procesos. Sabiendo esto, se pueden tomar acciones encaminadas a eliminarlos,
haciendo que los procesos sean ms eficientes y efectivos, en definitiva, que hacer
el trabajo sea cada vez ms rpido y menos costoso, tanto en recursos humanos
como en materiales.
2.9.1. Accin correctiva
La accin correctiva se define como la tarea que se emprende para corregir una no
conformidad significativa con cualquiera de los requisitos del sistema de gestin de
seguridad de la informacin.
Localizado el problema debe determinarse la relacin causa-efecto, considerando
todas las causas posibles. A veces no es fcil dilucidar cules son las causas exactas
del problema, pero hay que intentar aproximarse lo ms posible. En primer lugar
porque slo conociendo de dnde parti el problema se puede tomar una decisin
coherente y acertada para solucionarlo. Y adems porque es la manera de ir desta-
pando los puntos dbiles de nuestros procesos. En ms de una ocasin varios pro-
blemas detectados se han originado de un nico punto, y hasta que no se solucione
ese punto es muy probable que se sucedan incidencias que aparentemente pueden
tener poco que ver entre s.
Una vez localizado el origen, se analiza su importancia relativa y las alternativas que
pueden aplicarse para solucionar el problema, evaluando su coste y complejidad.
Esto se realizar normalmente dentro del comit de seguridad, que tomar la deci-
sin sobre las acciones a tomar y asignar responsables y plazos para su ejecucin.
Es esencial el cumplimiento de los plazos, y el comit debe velar por ello y analizar,
en su caso, cules son los motivos por los que no se cumplen.
Un error frecuente cuando se empiezan a utilizar las acciones correctivas es hacerlo
para todo, grandes y pequeos problemas. Es cierto que, y ms al principio, es dif-
cil distinguir entre los diversos grados de gravedad de las incidencias o no confor-
midades detectadas. Pero utilizar las acciones correctivas para todo no resulta
eficaz, deberan reservarse para asuntos que no pueden ser resueltos satisfactoria-
mente por otros medios. Cuando surgen los problemas hay que valorar si son inci-
dentes cotidianos, problemas de origen conocido, de fcil solucin y que no conllevan
un impacto considerable. Si el problema tiene causas difciles de detectar, la solu-
cin no es obvia o factible, es un hecho recurrente, el impacto que ha causado es
importante o es una desviacin sistemtica de las normas, entonces s es apropiado
utilizar una accin correctiva para solucionarlo.
Esta herramienta debe emplearse para detectar errores o fallos en los procesos y
nunca para buscar culpables. Si no se hace as, no se contar con la colaboracin
del personal en la deteccin de las causas de los problemas y la bsqueda de solu-
ciones, y realmente son los que tienen el conocimiento para ello, por lo que es fun-
damental asegurarse su colaboracin.
2.9.2. Accin preventiva
Las acciones preventivas se aplican para evitar la aparicin de futuras no conformida-
des. Son acciones encaminadas a eliminar la causa de una posible no conformidad.
En una accin preventiva se determina la posible fuente de problemas con el objeto
de eliminarla. Se pretende con ello evitar tener que solucionar problemas, puesto
que es ms eficaz y sencillo prevenirlos que solucionarlos.
Se puede decidir abrir acciones preventivas a raz de observaciones detalladas en las
auditoras internas o externas, del anlisis de la evolucin de los objetivos y de los
resultados de las actividades de revisin, ya que pueden utilizarse como fuentes de
informacin para el establecimiento de acciones preventivas:
Los resultados de la revisin por la direccin.
Los resultados de los anlisis de incidencias y objetivos.
Los registros.
El personal.
Las acciones preventivas son poco frecuentes al inicio de la implementacin de un
SGSI, ya que requieren una cierta madurez del sistema y una actitud proactiva del
personal para que afloren los problemas potenciales susceptibles de ser el objeto de
una accin preventiva. Por eso mismo son una potente herramienta de gestin que
permite adelantarse a los fallos, economizando recursos y costes. Se pasa de una
coyuntura de apagar fuegos a controlar la situacin y modificarla de acuerdo con
las necesidades de la organizacin.
Tanto en el caso de las acciones preventivas como en el de las correctivas, debe asig-
narse responsables con nombres y apellidos, y determinar fechas lmites de resolu-
cin para que la responsabilidad no se diluya. Por supuesto no es viable asignar
tareas a quien puede no tener la competencia o autoridad para llevarlas a cabo, por
lo que hay que ser cuidadosos al asignar dichas responsabilidades.
2.10. El anexo A
El anexo A contiene los 133 controles considerados como las mejores prcticas en
seguridad de la informacin y que se detallan en la Norma UNE-ISO/IEC 27002.
A lo largo de la Norma UNE-ISO/IEC 27001 se referencia este anexo como el
punto de partida para la seleccin de controles. Es decir, cuando se est desarro-
llando el SGSI, al llegar a dicha tarea, se debe utilizar esta tabla como lista de che-
queo para decidir si procede o no aplicar cada uno de los controles. El resultado de
este chequeo se documentar en el documento de aplicabilidad.
3
Comprender la Norma
UNE-ISO/IEC 27002
Esta norma contiene 11 captulos de controles de seguridad, es decir, reas de la
seguridad a considerar, con un total de 39 categoras principales de seguridad, con
sus correspondientes objetivos y los controles asociados a esos objetivos, ms un
captulo de introduccin sobre valoracin y tratamiento del riesgo.
Los 11 captulos (acompaados del nmero de categoras principales de seguridad
incluidos dentro de cada captulo) son los siguientes:
Poltica de seguridad (1).
Aspectos organizativos de la seguridad de la informacin (2).
Gestin de activos (2).
Seguridad ligada a los recursos humanos (3).
Seguridad fsica y del entorno (2).
Gestin de comunicaciones y operaciones (10).
Control de acceso (7).
Adquisicin, desarrollo y mantenimiento de los sistemas de informacin (6).
Gestin de incidentes de seguridad de la informacin y mejoras (2).
Gestin de la continuidad del negocio (1).
Cumplimiento (3).
Para cada uno de los controles la norma proporciona guas para su imple-
mentacin. Esta norma no es certificable, por lo que las recomendaciones no deben
ser consideradas normativas. Las indicaciones que da la norma son bastantes
exhaustivas, por lo que resultan muy tiles como referencia, pero no son obligatorias.
El grado de implementacin de cada uno de los controles es algo que la organizacin
debe decidir en funcin de sus necesidades y recursos disponibles. Y, por supuesto, el
modo en que se implementen es de competencia exclusiva de la organizacin.
3.1. Valoracin y tratamiento del riesgo
La norma propone 133 controles, pero no para tener que cumplirlos todos, sino
para elegir de entre ellos los que sean ms apropiados. Esto es precisamente lo que
nos ayudar a decidir la valoracin del riesgo.
Una vez identificados y valorados los activos, se elige el grupo a analizar. Pueden
ser todos, pero en el caso de que sean numerosos es recomendable escoger un
grupo, habitualmente el de los ms crticos, para no complicar en exceso el anlisis
de riesgos. Este anlisis es una tarea crucial y, en muchos casos, la ms laboriosa,
por cuanto exige valorar una gran cantidad de parmetros desde mltiples puntos
de vista, y suele implicar a multitud de personas que deben llegar a un consenso en
sus valoraciones. El objetivo es poner un valor lo ms objetivo posible a los riesgos
a los que estn expuestos los activos.
Para ello existen diversas metodologas, como CRAMM, Ebios, Magerit, ISO
13335-2, etc., y muchas herramientas en el mercado, como Callio, Cramm, Pilar,
casi siempre basadas en alguna de las metodologas ms aceptadas. Lo importante es
elegir aquel mtodo o herramienta que sea fcil de utilizar y que no exija demasiado
esfuerzo despus para mantener actualizado el anlisis de riesgos.
Es necesario que el personal de los distintos mbitos de la organizacin se implique
en la realizacin del anlisis de riesgos. Lo que la norma s exige es que este anlisis
sea objetivo y repetible. Para cumplir con el primer requisito resulta casi impre-
scindible que la mayor parte de las reas implicadas en el SGSI participen y aporten
su punto de vista en el anlisis de riesgos. Las distintas perspectivas permitirn
obtener un idea ms precisa de cules son exactamente los peligros y en qu medida
pueden afectar a la organizacin, sobre todo cuando la organizacin funciona por
departamentos y no por procesos, puesto que cada rea conoce y controla lo que
pasa en su entorno, pero no en el resto, no lo que ocurre a lo largo de todo el pro-
ceso, y saber eso es precisamente lo que se necesita para que el anlisis de riesgos
sea realista y est lo menos sesgado posible hacia un rea en particular. Cuanto ms
objetivo sea el anlisis y ms fcil de utilizar el mtodo o herramienta escogido,
mejor se cumplir el segundo requisito de que el anlisis sea repetible.
En general, en cualquier metodologa o herramienta se proporcionar una lista de
posibles amenazas, unas vulnerabilidades que habr que considerar, y unos baremos
para ponderar la probabilidad y el impacto que ocasionaran en la organizacin
que la amenaza se convirtiese en realidad. Valorando todos los parmetros que nos
ofrecen, se obtendr un valor de riesgo. Sealar que este anlisis de riesgos debe
efectuarse observando que no existe ninguna medida de seguridad implementada
para calcular lo que se llama riesgo intrnseco, es decir, el riesgo que presenta un
activo por el mero hecho de existir.
Obtenidos los valores de riesgo de todos los activos conseguiremos una imagen de
dnde radican los mayores riesgos en nuestra organizacin y, por lo tanto, en qu
puntos hay que incrementar el esfuerzo, dnde tendremos que aplicar medidas o
mejorar las existentes.
3.2. Poltica de seguridad
El nico objetivo de este captulo es que la organizacin cuente con una poltica
que refleje sus expectativas en materia de seguridad, a fin de gestionarla con
coherencia y soporte.
Este captulo consta de dos controles:
Documento de poltica de seguridad. El documento de poltica de seguridad
de la informacin debera establecer el compromiso de la direccin y el
enfoque de la organizacin para gestionar la seguridad de la informacin.
Este documento debera ser aprobado por la direccin y publicado y comu-
nicado a todos los empleados y terceras partes.
Revisin de la poltica de seguridad. La poltica de seguridad debe ser un
documento vivo, que se revise y actualice peridicamente para que siga
siendo adecuado tras los inevitables cambios que sufre toda organizacin.
Al implementar un SGSI segn la UNE-ISO/IEC 27001, es obligatorio desarrollar
una poltica de seguridad y mantenerla actualizada, por lo que la mera imple-
mentacin del sistema ya cumple con estos dos controles.
3.3. Organizacin de la seguridad
Este captulo tiene dos objetivos:
Organizacin interna, para gestionar la seguridad de la informacin dentro
de la organizacin. Los controles de este objetivo son:
Compromiso de la direccin con la seguridad de la informacin. La direc-
cin debe respaldar la seguridad de la informacin y tomar decisiones al
respecto, tales como poner objetivos y aprobar el riesgo aceptable, pro-
porcionando recursos y avalando acciones.
Coordinacin de la seguridad de la informacin. Es fundamental que las
actividades relativas a la seguridad de la informacin estn coordinadas
para que no haya redundancia o lagunas y produzcan situaciones inde-
seadas.
Asignacin de responsabilidades relativas a la seguridad de la informacin.
Hay que definir claramente quin se va a encargar de cada actividad de
seguridad de la informacin, evitando malentendidos y errores.
Proceso de autorizacin de recursos para el tratamiento de la informacin.
La gestin de la seguridad debe comenzar en el mismo proceso de com-
pra de cada nuevo recurso de tratamiento de la informacin.
Acuerdos de confidencialidad. Para proteger adecuadamente la informa-
cin sensible de la organizacin, deben establecerse y revisarse de una
manera regular cundo y quin debe firmar este tipo de acuerdo.
Contacto con las autoridades. Sera recomendable mantener los contactos
adecuados con las autoridades correspondientes, en particular en lo refe-
rente a planes de continuidad del negocio que pueden requerir de contac-
tos en los cuerpos y fuerzas de seguridad del Estado.
Contacto con grupos de inters especial. Dada la complejidad de la seguri-
dad y los numerosos cambios tecnolgicos que influyen en cmo hay que
enfocarla y tratarla, es fundamental mantenerse al da y conservar el con-
tacto con grupos de inters especial, foros y asociaciones profesionales
especialistas en seguridad.
Revisin independiente de la seguridad de la informacin. Siempre es til
contar con la opinin de terceros, sobre todo si son especialistas en el
tema, para que valoren si el enfoque de la organizacin para la gestin de
la seguridad de la informacin es adecuado y en qu se puede mejorar. La
ausencia de presiones internas y la comparacin con otras organizaciones
o modelos de gestin permite que surja un aporte de cosas nuevas que
difcilmente hubieran aflorado internamente.
Terceros. El objetivo aqu es que las medidas de seguridad abarquen tam-
bin a cualquier tercero que sea susceptible de acceder, procesar, comu-
nicar o gestionar la informacin de la organizacin. Los controles para
ello son:
Identificacin de riesgos derivados del acceso de terceros. Lgicamente, el
primer control ser saber cules son los riesgos que supone el acceso de
terceros a nuestros sistemas e informacin, para poder implementar los
controles adecuados antes de permitir dicho acceso.
Tratamiento de la seguridad en la relacin con los clientes. Si a los clientes
se les permite acceder a la informacin, hay que considerar qu requisitos
deben cumplir y los sistemas para garantizar la seguridad.
Tratamiento de la seguridad en contratos con terceros. Es crtico que se
hagan acuerdos formales con aquellos terceros que posean acceso a recur-
sos de tratamiento de informacin de la organizacin. Estos acuerdos
deben basarse en un contrato formal que contemple todos los requisitos
de seguridad necesarios y que obligue a que se cumplan las polticas y
normas de seguridad de la organizacin. El contrato debe asegurar que no
hay malentendidos entre la organizacin y los terceros. De esta manera la
organizacin puede mantener el mismo control tanto sobre sus usuarios
internos como sobre los externos.
3.4. Gestin de activos
Los activos de informacin son los elementos que tratamos de proteger con el
SGSI. Los controles de este captulo estn dirigidos a lograrlo.
Responsabilidad sobre los activos. Para conseguir y mantener una proteccin
adecuada sobre los activos de la organizacin deben existir responsabilidades
claras. Hay tres controles para este objetivo:
Inventario de activos. Para poder gestionarlos, es fundamental identificar
dichos activos, preparando con esa informacin un inventario de todos los
activos importantes, que habr de ser mantenido y actualizado. Se nece-
sita un inventario de los recursos de informacin de la organizacin para,
basndose en este conocimiento, asegurar que se brinda un nivel adecuado
de proteccin.
Propiedad de los activos. Cada uno de los activos contar con un propie-
tario, una parte designada de la organizacin, y ser responsable de su
seguridad.
Uso aceptable de los activos. Las reglas bsicas para el empleo aceptable
de la informacin y de los activos asociados con los recursos para el
tratamiento de la informacin deben ser documentadas y publicadas, para
que se apliquen en toda la organizacin.
Clasificacin de la informacin, para asegurar que la informacin recibe un
nivel adecuado de proteccin en funcin de su criticidad. Existen dos con-
troles:
Directrices de clasificacin. Debe clasificarse la informacin de acuerdo a
su sensibilidad y criticidad, su valor para la organizacin y el dao que
ocasionara su fuga o filtracin, para as poder adoptar las medidas de
seguridad adecuadas a cada nivel de proteccin.
Etiquetado y manipulado de la informacin. La informacin debe ser
marcada y tratada de acuerdo con el esquema de clasificacin adoptado
por la organizacin. El etiquetado de la informacin puede realizarse de
diferentes formas, pero debera hacerse de modo que se distinga fcil-
mente el tipo de informacin que contiene el documento.
3.5. Seguridad ligada a los recursos humanos
Este captulo establece la necesidad de educar e informar a los empleados
actuales y potenciales sobre lo que se espera de ellos en materia de seguridad y
asuntos de confidencialidad. Tambin determina cmo incide el papel que los
empleados desempean en materia de seguridad en el funcionamiento general
de la compaa.
Ante la contratacin de personal deben tomarse medidas de seguridad previas a la
contratacin, durante el perodo que dure el contrato y al concluir. Este captulo
marca tres objetivos:
Antes del empleo, para asegurar que cualquier persona que entre a formar
parte de la organizacin (empleados, contratistas, etc.) conoce y entiende sus
responsabilidades en materia de seguridad y puede llevar a cabo las tareas
que se le encomienden, colaborando activamente en reducir los riesgos de
robo, fraude o utilizacin indebida de los recursos. Los controles son tres:
Funciones y responsabilidades. Para poder exigirlas, las funciones y
responsabilidades de seguridad de los empleados contratistas y terceros se
deben definir y documentar.
Investigacin de antecedentes. Para segn qu puestos puede ser especial-
mente relevante comprobar los antecedentes de todos los candidatos a
ejercer el trabajo. Esta comprobacin deber efectuarse de acuerdo a la
legislacin vigente y de una manera proporcionada a los requisitos del
negocio y de seguridad de la organizacin.
Trminos y condiciones de contratacin. Los contratos debern reflejar,
junto con los trminos del acuerdo, las obligaciones y responsabilidades
de las dos partes en lo relativo a seguridad de la informacin.
Durante el empleo, para que en el trabajo cotidiano todo el mundo se
encuentre concienciado en materia de seguridad y ponga en prctica la
poltica de seguridad de la organizacin, reduciendo el riesgo de error
humano. Este objetivo cuenta con tres controles:
Responsabilidades de la direccin, que es la que debe establecer las direc-
trices a seguir y exigir su cumplimiento, tanto a los empleados como a
contratistas y terceros.
Concienciacin, formacin y capacitacin en seguridad de la informacin.
Hay que poner en conocimiento de los implicados las polticas y proced-
imientos de la organizacin, y proporcionar la formacin adecuada para
que las puedan ejecutar.
Proceso disciplinario. Debe existir algn mecanismo de penalizacin para
las infracciones de seguridad que sirva como mtodo de disuasin.
Cese del empleo o cambio de puesto de trabajo, para lograr que cuando
alguien deja de trabajar con la organizacin o cambia la relacin con ella,
dichos cambios discurran adecuadamente y no generan vulnerabilidades. Los
controles son:
Responsabilidad del cese o cambio. Las responsabilidades deben estar
establecidas y ser conocidas en caso de cese o cambio de puesto de algn
empleado, para efectuarlo correctamente.
Devolucin de activos. Si cesa el empleo o contrato, los activos que se han
entregado para poder realizarlo deben ser devueltos.
Retirada de los derechos de acceso. Cuando concluye el empleo, el con-
trato o el acuerdo con un empleado o contratista, deben retirarse todos los
derechos de acceso a la informacin y a los recursos de tratamiento de la
informacin o bien deben ser adaptados a los cambios producidos.
3.6. Seguridad fsica y del entorno
Este captulo responde a la necesidad de proteger fsicamente las reas en las que
se encuentran los equipos y la informacin. Los mecanismos de proteccin para el
sistema de informacin de la organizacin pasan por definir un permetro fsico de
seguridad que impida el acceso no autorizado a la informacin y eviten daos por
eventos, tales como fuego, inundacin, terremoto, explosin, malestar social y
otras formas de desastres naturales o provocados por el hombre.
Existen dos objetivos:
reas seguras. Deben establecerse unas medidas de seguridad para prevenir
los accesos fsicos no autorizados, los daos y las intromisiones en las instala-
ciones y en la informacin de la organizacin. Podemos utilizar los siguientes
controles:
Permetro de seguridad fsica. Barreras, muros, puertas de entrada con restric-
ciones (recepcin, cerraduras, control a travs de tarjeta, etc.), cualquier
medio que sirva para proteger las zonas en las que se encuentra la informa-
cin y los sistemas de informacin formarn parte de este primer control.
Controles fsicos de entrada. Las reas en las que slo el personal autori-
zado puede entrar deben poseer controles de entrada apropiados que res-
trinjan el acceso.
Seguridad de oficinas, despachos e instalaciones. Tambin estos recintos
deben contar con medidas razonables que permitan mantener la informa-
cin y los sistemas bajo control.
Proteccin contra las amenazas externas y de origen ambiental. Tanto por
la magnitud de los daos que pueden ocasionar estas amenazas, como
por la legislacin que controla este punto, se deben aplicar las medidas
apropiadas contra el dao causado por fuego, inundacin, terremoto y
otros desastres, tanto naturales como provocados por el hombre.
Trabajo en reas seguras. Por su especial sensibilidad, las reas seguras
contarn, adems de con medidas de proteccin fsica, con directrices para
trabajar en ellas.
reas de acceso pblico y de carga y descarga. Puesto que estos puntos
son vulnerables a accesos no autorizados, debern controlarse con cuidado
y, en la medida de lo posible, mantenerlos alejados y aislados de aquellas
zonas en las que residan los sistemas de informacin.
Seguridad de los equipos, para que las actividades de la organizacin no se
interrumpan debido a daos en los equipos, robo de activos o prdidas de
los mismos. Los controles definidos para este objetivo son:
Emplazamiento y proteccin de equipos. Los equipos deben situarse en
lugares seguros, protegidos de riesgos ambientales (agua, luz, viento, etc.)
que puedan daarlos. Asimismo, se ubicarn all donde su acceso resulte
complicado para personas no autorizadas.
Instalaciones de suministro. Los equipos pueden daarse si se producen
fallos en el suministro elctrico o en las comunicaciones, por lo que es
recomendable que tengan alguna proteccin para evitar problemas si suce-
den estos fallos, especialmente si se trata de equipos muy crticos.
Seguridad del cableado. Puesto que el cableado hace posible que los
equipos funcionen, se instalar de manera que se eviten daos, que impi-
dan interceptaciones o que dificulten una fuga de informacin.
Mantenimiento de los equipos. Otro punto crucial para que los equipos
funcionen correctamente es que se sometan a un mantenimiento, preven-
tivo y correctivo, que asegure su disponibilidad y su integridad.
Seguridad de los equipos fuera de las instalaciones. Cuando los equipos
estn fuera de las instalaciones de la organizacin, el nivel de seguridad
debe ser el mismo, aunque las circunstancias no lo sean, por lo que
deben disearse y aplicarse las medidas de seguridad adecuadas a estos
equipos.
Reutilizacin o retirada segura de equipos. Los equipos almacenan infor-
macin que debe ser eliminada (sobre todo si es sensible) cuando son reti-
rados o se van a reutilizar. Para evitar problemas, esta eliminacin se com-
probar antes de retirarlos o ponerlos en uso de nuevo.
Retirada de materiales propiedad de la empresa. Hay que autorizar y regis-
trar las salidas de equipos para poder controlar la informacin o software
en todo momento, de manera que se sepa quin es el responsable de los
activos y dnde se encuentran.
3.7. Gestin de comunicaciones y operaciones
Este es el captulo con ms objetivos y controles, y el ms tcnico de toda la
norma. Aqu se recogen los controles tcnicos, puesto que se trata de proteger el
funcionamiento y las operaciones de los sistemas de informacin. Hay que tener
en cuenta que el origen de esta norma se encuentra en grandes empresas y corpo-
raciones con sistemas de informacin muy sofisticados y amplios. En el contexto
de una pyme, es aqu donde se hace ms relevante realizar el esfuerzo de escalar
hacia abajo los requisitos planteados por la norma. Muchos de los controles de
este captulo no sern aplicables en el contexto de una pyme tpica, a menos que
su negocio posea implicaciones que los hagan necesarios, y desde luego la imple-
mentacin de los que s son aplicables tiene que ser lo ms sencilla que seamos
capaces de disear. Un banco tendr que tener un procedimiento de copias de
seguridad muy estricto y laborioso y muchos recursos dedicados a esa tarea, tanto
para realizarla como para almacenar las copias. En una pyme puede ser suficiente
una copia semanal, almacenada en un pequeo dispositivo USB que se pueda
transportar cmodamente fuera de las instalaciones a un lugar seguro.
Este captulo contiene diez objetivos:
Responsabilidades y procedimientos de operacin. Para encargarse eficaz-
mente de que los sistemas de informacin funcionen de manera correcta y
segura, ser necesario establecer las responsabilidades y procedimientos para
la gestin de todos los recursos de informacin, reduciendo los riesgos de
negligencia o uso indebido. Los controles son:
Documentacin de los procedimientos de operacin. Siempre hay una
forma ms o menos establecida de afrontar las tareas, este control trata de
documentar esos modos de trabajo, estableciendo las responsabilidades y
cubriendo todas las tareas fundamentales, por ejemplo, el procedimiento
para las copias de seguridad, para la configuracin de accesos, etc.
Gestin de cambios. Los sistemas de informacin y las aplicaciones deben
estar bajo control de cambios, ya que stos son una fuente importante de
errores y fallos. Esta gestin del cambio tiene que incluir la identificacin
de los cambios, su aprobacin, la planificacin de cmo y cundo van a
ser incorporados, las pruebas que se efectuarn, siempre fuera del entorno
de produccin, y cul ser el procedimiento para deshacerlos si sucede
algn evento imprevisto.
Segregacin de tareas. Hay que separar las diversas reas de responsabili-
dad para evitar usos o accesos indebidos, accidentales o intencionados, de
la informacin. Esta segregacin puede resultar difcil de emprender en
organizaciones pequeas, pero el principio debera aplicarse en la medida
en que sea posible y prctico.
Separacin de los recursos de desarrollo, prueba y operacin. Siguiendo
el mismo principio anterior, es necesario separar el entorno donde se rea-
licen desarrollos del entorno de prueba, y por supuesto los entornos de
produccin deben permanecer aislados del resto, as se eliminan riesgos
de accesos no autorizados o cambios no deseados. Deberan establecerse
las normas para trasladar software y datos de unos entornos a otros, por
ejemplo, en qu condiciones se pueden usar datos reales para realizar
pruebas.
Gestin de la provisin de servicios por terceros. Estos servicios deben tener el
mismo nivel de seguridad que los internos, por lo que se establecern acuerdos
en los que se recogern estos requisitos, comprobndose el cumplimiento de
los acuerdos y gestionando los cambios necesarios para asegurar que los servi-
cios entregados son conformes con lo estipulado. Los controles son tres:
Provisin de servicios. Se establecern acuerdos de nivel de servicio con
todos los requisitos necesarios para que se cumplan las expectativas, tanto
funcionales como de seguridad, para la provisin del servicio. Estos acuer-
dos establecern las normas para el intercambio de informacin y las
responsabilidades de los contratistas respecto a los activos de informacin
a los que tengan acceso.
Supervisin y revisin de los servicios prestados por terceros. Ha de man-
tenerse un control para garantizar que los servicios se suministran segn
los acuerdos establecidos, incluso realizando auditoras cuando sea perti-
nente. Para ello se revisarn los informes entregados y los registros gene-
rados por la actividad, y se comprobar que los incidentes y problemas de
seguridad de la informacin se gestionan y resuelven adecuadamente.
Gestin del cambio en los servicios prestados por terceros. En la lnea de
mantener el mismo nivel de seguridad en los servicios suministrados por
terceros que en los internos, tambin los cambios deben ser gestionados
en dichos servicios. Durante su provisin pueden darse cambios para
mejorar los servicios, nuevos desarrollos, modificaciones de las polticas y
procedimientos de la organizacin, cambios tecnolgicos, etc. Ha de exis-
tir un procedimiento claro para incorporar estos cambios a los servicios
de una forma eficaz.
Planificacin y aceptacin del sistema, de modo que se eviten fallos de los
sistemas por sobrecargas y fallos de disponibilidad. Existen dos controles:
Gestin de capacidades. Para ello se controlar el uso de recursos para que
se puedan hacer previsiones de futuro, planificando con tiempo suficiente
la capacidad que va a ser necesaria para evitar agotarla.
Aceptacin del sistema. Se deberan establecer, documentar, y probar pre-
viamente a su aceptacin y uso los requisitos operacionales de los sistemas
nuevos, as se evitaran fallos, incluso aunque se trate de una simple actua-
lizacin.
Proteccin contra cdigo malicioso y descargable. Evitar virus, troyanos y el
resto de los tipos de cdigo malicioso sirve para proteger la integridad del
software y de la informacin.
Controles contra el cdigo malicioso. La proteccin contra este riesgo
tiene dos vertientes, la tcnica y la humana. Deben instalarse sistemas de
deteccin, prevencin y recuperacin que protejan contra cdigo mali-
cioso. Adems se deben realizar procedimientos adecuados de concien-
ciacin para que todos los usuarios sean conscientes de los problemas que
genera el cdigo malicioso y cmo proceder cuando se reciban correos
engaosos.
Controles contra el cdigo descargado en el cliente. Si se autoriza el uso
de cdigo descargado en el cliente (JavaScript, VBScript, applets de Java
applets, controles ActiveX, etc.), la configuracin debe garantizar que
dicho cdigo autorizado funciona de acuerdo con una poltica de seguri-
dad claramente definida. Cualquier uso y recepcin de cdigo ambu-
lante no autorizado ha de bloquearse. Los ataques del cdigo mvil
pueden modificar la informacin, robar las contraseas o archivos, redi-
reccionar los accesos telefnicos por mdem o lanzar un ataque de dene-
gacin de servicio, por lo que hay que ser especialmente precavidos en
este punto.
Copias de seguridad. Realizar copias de la informacin ayuda a mantener la
integridad y disponibilidad de la misma y de los recursos de tratamiento de
la informacin, ya que en caso de incidente se podra recuperar rpidamente.
Este objetivo slo tiene un control:
Copias de seguridad de la informacin. Deberan establecerse procedi-
mientos para efectuar las copias de seguridad de acuerdo con la frecuencia
y amplitud que recomienden la sensibilidad y criticidad de la informacin
gestionada. Adems, las copias han de comprobarse regularmente para
verificar que la informacin es y permanece correcta y completa, y ensayar
los tiempos de recuperacin. Se ha convertido en un requisito bsico contar
con una copia de seguridad fuera de las instalaciones de la organizacin,
lo cual garantiza la disponibilidad de la informacin incluso en caso de
desastre.
Gestin de la seguridad de las redes. Por pequea que sea la organizacin, lo
ms corriente es que cuente con una red por la que circulan las comunica-
ciones digitales y la informacin. Este objetivo trata de asegurar esta
infraestructura para evitar incidentes.
Controles de red. Para proteger la red, en primer lugar, debe estar gestion-
ada y controlada, con responsabilidades claras y diferenciadas de las
responsabilidades operativas, si es posible. Las medidas de seguridad para
proteger la confidencialidad, la integridad de los datos que pasan a travs
de ellas y los dispositivos que protegen las aplicaciones y los sistemas
conectados son crticas aqu, as como mantener logs con informacin que
pueda ayudar a detectar fallos, errores o ataques.
Seguridad de los servicios de red. Dado el gran nmero de utilidades que
soportan las redes, se deben identificar los requisitos funcionales y de
seguridad y los niveles de servicio que deben incluirse en todo acuerdo
de servicios de red, tanto si estos servicios son internos como si se subcon-
tratan. Esto incluir las necesidades de autenticacin de usuarios, de ci-
frado de datos, de control de conexiones, requisitos de acceso para usuarios
remotos, etc.
Manipulacin de los soportes. La informacin puede estar en varios for-
matos y soportes, por lo que protegerlos es bsico para evitar que se revele
o destruya informacin o se interrumpan las actividades de la organi-
zacin.
Gestin de soportes extrables. La proliferacin de este tipo de soportes
(discos pticos, lpices USB, discos duros externos) hace necesario
establecer normas para su utilizacin.
Retirada de soportes. Cuando ya no se vayan a utilizar, hay que retirarlos
de acuerdo con las normas que se establezcan, las cuales eviten que la
informacin que contengan pueda llegar a personas no autorizadas.
Procedimientos de manipulacin de la informacin. Se deberan estable-
cer procedimientos para tratar y almacenar la informacin. El objetivo
es impedir que dicha informacin sea revelada sin autorizacin o que se
la d un mal uso, por ejemplo, se recomienda que se etiqueten los soportes
segn la clasificacin de la informacin que porten, considerando los
siguientes aspectos: las restricciones de acceso, el mantenimiento de un
registro de los destinatarios autorizados, el almacenamiento de los
soportes de acuerdo con las especificaciones del fabricante, etc.
Seguridad de la documentacin del sistema. Es importante mantener
segura esta informacin, ya que contiene datos valiosos para la organi-
zacin, por ejemplo, las descripciones de las aplicaciones de los procesos,
las estructuras de datos y los procesos de autorizacin.
Intercambio de informacin. Un SGSI debe proteger la informacin a lo
largo de todo su ciclo de vida, en muchos momentos de este ciclo la infor-
macin saldr de la organizacin por unos motivos u otros, por lo que deben
establecerse los mecanismos adecuados para que permanezca segura cuando
se intercambie con terceros. Los controles para conseguirlo son:
Polticas y procedimientos de intercambio de informacin. Se deberan
establecer procedimientos y normas para proteger la informacin y los
soportes fsicos que contienen informacin en trnsito.
Acuerdos de intercambio. El intercambio de informacin debe realizarse
en el marco de un acuerdo que recoja las responsabilidades de cada parte,
las exigencias en el caso de incidentes de seguridad de la informacin,
cmo va a ser etiquetada la informacin sensible o crtica, las normas tc-
nicas para el registro y lectura de la informacin y del software, etc.
Soportes fsicos en trnsito. Para que la informacin est segura cuando se
encuentre en trnsito deben protegerse los soportes, utilizando mensajeros
y transportistas de confianza, embalando bien los soportes, etc.
Mensajera electrnica. Se establecern normas de seguridad para el uso
del correo electrnico, las cuales recogern las medidas de seguridad mni-
mas para garantizar un empleo responsable y seguro del servicio, en par-
ticular cuando se utilice para el envo de informacin confidencial.
Sistemas de informacin empresariales. Se deberan desarrollar y aplicar
polticas y procedimientos para proteger la informacin que se va a com-
partir con otros sistemas de informacin pertenecientes a otras organiza-
ciones, definiendo qu informacin puede ser compartida, por quin, las
responsabilidades de cada parte, etc.
Servicios de comercio electrnico. El xito de estos servicios se basa en la
confianza de los usuarios en la seguridad de los mismos. Para garantizar esta
seguridad de los servicios de comercio electrnico, se pueden utilizar los
siguientes controles:
Comercio electrnico. Es vital que toda la informacin incluida en el com-
ercio electrnico se proteja contra actividades fraudulentas, disputas con-
tractuales y revelacin o modificacin no autorizada de dicha informacin.
Transacciones en lnea. Estas transacciones son muy vulnerables a errores
o fallos de transmisin o de direccionamiento, alteraciones no autorizadas
de los mensajes, as como revelacin, duplicacin o reproduccin no
autorizadas del mensaje, por lo que han de ser correctamente protegidas.
Informacin puesta a disposicin pblica. La integridad de la informacin
destinada a hacerse pblica debe protegerse para impedir modificaciones
no autorizadas que daen la reputacin de la organizacin.
Supervisin. La nica manera de detectar a tiempo las actividades de proce-
samiento de la informacin no autorizadas es llevando a cabo una supervisin
que las ponga en evidencia. El nivel de monitorizacin est basado en el
nivel de riesgo del negocio, cuanto ms riesgo mayor debera ser el nivel
de vigilancia. Los controles son:
Registro de auditoras. Se deben mantener registros de las operaciones de
privilegio, las conexiones y desconexiones (log in/ log out), los intentos
de acceso no autorizado, violaciones de la poltica de acceso, las alertas por
fallos, etc. Estos registros deben ser almacenados durante un perodo
acordado para servir como prueba en investigaciones futuras y en la super-
visin del control de acceso.
Supervisin del uso del sistema, para verificar que los recursos del sistema
se utilizan debidamente.
Proteccin de la informacin de los registros. Debido a la sensibilidad de
los dispositivos de registro y la informacin generada por ellos, deben ser
protegidos contra manipulaciones indebidas y accesos no autorizados.
Registros de administracin y operacin. Los registros del administrador
del sistema y del operador del sistema deberan ser revisados regular-
mente, de manera que se compruebe que se cumplen las actividades del
sistema y de la administracin de la red.
Registro de fallos. Registrar los fallos, tanto de los usuarios como de las
aplicaciones, es el primer paso hacia una correcta gestin de los mismos
hasta su resolucin. Deberan existir reglas precisas para el tratamiento de
los informes de fallos, incluyendo la revisin de los registros y el cumpli-
miento de las medidas correctivas tomadas.
Sincronizacin del reloj. En caso de incidencias, teniendo todos los
equipos sincronizados, se podr comprobar qu equipos estaban conecta-
dos en el sistema de informacin, y al observar los registros de dichos
equipos, se podr llegar a una conclusin sobre lo sucedido.
3.8. Control de acceso
Este captulo trata de las medidas a tomar cuando se desee monitorizar y controlar
el acceso a la red y los recursos de informacin, y de la proteccin existente contra
los abusos internos y los intrusos externos, dada la importancia que tienen para
la organizacin sus activos. Por lo tanto, el objetivo de este grupo de controles es
regular el acceso a la informacin, de acuerdo con los requisitos de negocio y los de
seguridad, que se puede obtener aplicando alguno de los siete objetivos de control
definidos:
Requisitos de negocio para el control de acceso, de manera que slo accedan
a la informacin quienes estn autorizados para ello. Tiene un control:
Poltica de control de acceso. En primer lugar hay que definir y documen-
tar cules van a ser las lneas de actuacin en la organizacin en este
aspecto. Hay que valorar qu clases de informaciones son tratadas y si se
puede permitir acceso a todo el mundo a toda o a la gran mayora de la
informacin y restringir slo una parte, o bien darle a cada uno acceso
slo a aquella informacin que necesita.
Gestin de acceso de usuario, de manera que slo los usuarios autorizados
pueden acceder a la informacin y los sistemas, mientras que aquellos que
no lo estn no puedan hacerlo. Se utilizarn los siguientes controles:
Registro de usuarios. El primer paso es establecer un registro de usuarios,
donde se anoten las altas y bajas de los mismos, junto con los permisos de
acceso que se les conceden o revoquen, todo ello de acuerdo con un pro-
cedimiento formal que evite errores en la asignacin de permisos, en la
medida de lo posible.
Gestin de privilegios. Los privilegios otorgados a los usuarios deben
estar debidamente autorizados, segn su necesidad de uso, manteniendo
un registro para controlar su utilizacin.
Gestin de contraseas de usuario. Es uno de los controles ms difundidos
y ms eficaces para el control de accesos, siempre que est bien implemen-
tado y gestionado. Para conservar la eficacia de las contraseas es funda-
mental que permanezcan confidenciales, por lo que se debe concienciar
al personal sobre este punto. Las contraseas deben tener mayor comple-
jidad (ms caracteres, mezclar nmeros, letras y smbolos) segn la critici-
dad de las aplicaciones o la informacin a la que se acceda, y deben ser
cambiadas frecuentemente, como mnimo una vez al ao.
Revisin de los derechos de acceso de usuario. Debido a los cambios que
sufren las organizaciones, los accesos que se concedieron en su momento
pueden perder validez, por lo que hay que revisarlos regularmente para
actualizarlos.
Responsabilidades de usuario. Ya se ha comentado la importancia de que el
personal colabore activamente en mantener la seguridad. Todas las medidas
tcnicas implementadas no podrn evitar que se cometan errores, como
apuntar contraseas en un papel o dejar informes confidenciales en la impre-
sora. Para evitar este tipo de fallos de seguridad, hay que formar, concienciar
y, si es necesario, comprometer al personal. Por ello, en este objetivo se tratan
los controles orientados a prevenir el acceso de usuarios no autorizados, y
evitar robos de informacin o equipos causados por las malas prcticas de
los usuarios.
Uso de contrasea. Los usuarios deben seguir buenas prcticas de segu-
ridad en la seleccin y el uso de las contraseas: mantener su confidenciali-
dad, no compartirlas, no emplear la misma contrasea para propsitos pro-
fesionales que para no profesionales, no guardarla en papel o en un fichero
de software fcil de acceder, etc.
Equipo de usuario desatendido. Los usuarios, a lo largo de la jornada,
suelen ausentarse de su puesto de trabajo por diferentes motivos, dejando
desatendido el equipo y la informacin que estn utilizando. Para evitar
incidentes no deseados, las pantallas y los equipos debern bloquearse
pasado un perodo de inactividad, por ejemplo, con un protector de pan-
talla con contrasea.
Poltica de puesto de trabajo despejado y pantalla limpia. Tanto las mesas
de trabajo como los equipos informticos del puesto son dos elementos
del sistema de informacin susceptibles de fugas de informacin, por lo
que deben establecerse normas y mecanismos para que el personal man-
tenga tanto la mesa como la pantalla sin informacin visible, papeles o
medios de almacenamiento extrables, que puedan comprometer la confi-
dencialidad de los datos.
Control de acceso a la red. Los sistemas de informacin actuales cuentan con
redes que son vulnerables a accesos no autorizados, por lo que deben ser
protegidas. Los controles para ello son:
Poltica de uso de los servicios en red. Hay que establecer cmo se va a
utilizar la red y sus servicios, y definir cmo se van a asignar los accesos.
Esta poltica deber ser coherente con la poltica de accesos de la organi-
zacin.
Autenticacin de usuario para conexiones externas. Si los usuarios van a
conectarse en remoto a la red, hay mayores riesgos que en una conexin
interna, por lo que la autenticacin debe ser ms rigurosa, sobre todo si se
utilizan redes inalmbricas. Los mtodos de autenticacin se escogern
tanto ms seguros segn la valoracin del riesgo que se haya hecho de la
informacin y las aplicaciones a acceder y los medios de acceso que se van
a utilizar para ello. Si se emplean redes privadas virtuales (VPN) puede ser
suficiente el sistema de usuario y contrasea, si se va a trabajar con redes
pblicas puede ser necesario utilizar, por ejemplo, tcnicas criptogrficas o
dispositivos biomtricos.
Identificacin de los equipos en las redes. De esta manera se pueden aut-
enticar las conexiones provenientes de localizaciones y equipos especfi-
cos. Los identificadores de los equipos indicarn claramente a qu red se
permite al equipo la conexin, si existe ms de una red y, en particular, si
estas redes tienen distinto grado de sensibilidad. Se puede aplicar la iden-
tificacin del equipo adicionalmente a la identificacin de usuario,
reforzndola.
Diagnstico remoto y proteccin de los puertos de configuracin. Cuando
sea necesario mantener un puerto abierto para estas tareas, se debe contro-
lar tanto el acceso fsico como el lgico permitido para este puerto.
Segregacin de las redes. Cuando sea oportuno y prctico, se separarn en
redes distintas los servicios de informacin, los de usuarios y los sistemas,
evitando as filtraciones o modificaciones de la informacin.
Control de la conexin a la red. Cuando se comparta la red, sobre todo si
se hace con otras organizaciones, los accesos deben estar perfectamente
definidos y restringidos. No todos los usuarios poseen las mismas nece-
sidades de acceso, as que, para evitar problemas, lo ms recomendable
es que cada uno tenga los derechos de acceso a la red que estrictamente
necesite para realizar su trabajo.
Control de encaminamiento (routing) de red. Los controles de encami-
namiento (routing) de redes se implementan para evitar que la informacin
llegue a un destino distinto del requerido, de manera que las conexiones de
los ordenadores y los flujos de informacin estn de acuerdo con la poltica
de control de acceso de la organizacin.
Control de acceso al sistema operativo, para prevenir accesos indebidos a los
sistemas operativos que provoquen daos en las aplicaciones e inestabili-
dades de los sistemas. Los controles a utilizar para alcanzar este objetivo son:
Procedimientos seguros de inicio de sesin. Las sesiones deben ser inicia-
das con un procedimiento que no facilite a un usuario no autorizado
la entrada ni revele informacin del sistema y que limite los intentos de
entrada para bloquearlos.
Identificacin y autenticacin de usuario. Cada usuario deber tener un
identificador nico (ID de usuario) para su uso personal y exclusivo, as
se lograr que su autenticacin sea fiable, de manera que se puedan seguir
sus actividades y, si es necesario, exigir responsabilidades.
Sistema de gestin de contraseas. Gestionar las contraseas necesita de la
colaboracin del personal y servirn a su propsito en funcin de la calidad
y robustez de las mismas. Donde sea posible, se permitir a los usuarios
escoger sus propias contraseas, aunque se establezcan criterios para dise-
arlas.
Uso de los recursos del sistema. Hay programas y utilidades del sistema
que pueden ser capaces de invalidar los controles del mismo y de la apli-
cacin, por lo que su uso debera estar restringido a los usuarios que real-
mente lo necesiten y encontrarse estrictamente controlado.
Desconexin automtica de sesin. Las sesiones abiertas son oportu-
nidades para realizar accesos no autorizados, por lo que debe establecerse
un tiempo tras el cual, si no ha habido actividad, la sesin caducar.
Limitacin del tiempo de conexin. Limitar la franja horaria en la que se
pueden realizar las conexiones es un mecanismo que refuerza el control de
accesos, ya que reduce el marco de oportunidades de acceso no autorizado.
Control de acceso a las aplicaciones y a la informacin. Las aplicaciones y
la informacin que contienen son elementos muy sensibles de los sistemas
de informacin, que deben ser protegidos contra accesos no autorizados
para evitar fallos de confidencialidad o de integridad. Existen dos controles para
este objetivo:
Restriccin del acceso a la informacin. Debe seguirse la poltica de acce-
sos de la organizacin, de manera que el acceso se conceda a los usuarios
autorizados para ello. Adems, deben protegerse contra accesos permitidos
por software malicioso o software del sistema operativo que permita obviar
los controles establecidos.
Aislamiento de sistemas sensibles. Cuando las aplicaciones y su informa-
cin son particularmente crticos, deberan estar alojados en entornos pro-
tegidos con equipos dedicados, aislados del resto de los sistemas.
Ordenadores porttiles y teletrabajo. Este tipo de equipos y modo de trabajo
se va extendiendo cada vez ms, con la mejora del hardware, el software y las
comunicaciones, pero son muy vulnerables, por lo que hay que ser especial-
mente escrupuloso para garantizar su seguridad.
Ordenadores porttiles y comunicaciones mviles. Cuando se emplean
este tipo de dispositivos, los riesgos son distintos que cuando se usan los
equipos de sobremesa, por lo que deben establecerse normas de uti-
lizacin especficas encaminadas a protegerlos adecuadamente, tales como
la proteccin fsica, los controles de acceso, las tcnicas criptogrficas, las
copias de respaldo y la proteccin antivirus.
Teletrabajo. Para que el trabajo realizado en remoto se haga con el mismo
nivel de seguridad que si se realizara dentro de las instalaciones de la orga-
nizacin, deben existir unas normas que consideren aspectos como la
seguridad fsica en el lugar de teletrabajo y las comunicaciones. Es impres-
cindible contar con una definicin del trabajo permitido, las horas de tra-
bajo, la clasificacin de la informacin que puede mantenerse en el equipo,
y los sistemas y servicios a los que el teletrabajador est autorizado a
acceder, que garanticen unos mnimos de seguridad.
3.9. Adquisicin, desarrollo y mantenimiento de
los sistemas
En toda labor de la tecnologa de la informacin se debe implementar y mantener
la seguridad mediante el uso de controles de seguridad que abarquen todas las etapas
del ciclo de vida de los activos de informacin. El objetivo especfico de este grupo
de controles es garantizar que la seguridad sea una parte integral de los sistemas de
informacin, desde su concepcin hasta su retirada.
Requisitos de seguridad de los sistemas de informacin. Si queremos garan-
tizar una seguridad integrada en los sistemas de informacin es fundamental
que los requisitos de seguridad sean explcitos y estn documentados. El con-
trol es claro:
Anlisis y especificacin de los requisitos de seguridad. Tanto si se van
a comprar paquetes de software o equipos, como si se est pensando en
subcontratar un nuevo desarrollo, el primer paso es definir los requisitos
que debe cumplir el elemento que se va a adquirir. Si queremos que ese
elemento sea seguro y su incorporacin a los sistemas de informacin no
cree problemas, los requisitos de seguridad debern ser incorporados a las
especificaciones junto con el resto de los requisitos funcionales y tcnicos.
Tratamiento correcto de las aplicaciones. Las aplicaciones deben procesar
correctamente la informacin introducida en ellas para evitar errores, prdidas,
modificaciones no autorizadas o usos indebidos de dicha informacin. Para
alcanzar este objetivo los controles a aplicar son:
Validacin de los datos de entrada. El primer paso ser comprobar que los
datos de entrada en las aplicaciones son vlidos, es decir, la aplicacin
deber ser capaz de detectar si los datos introducidos son correctos, en la
medida de lo posible: que se encuentran dentro de un rango, que el for-
mato es aceptable, que son coherentes, etc.
Control del procesamiento interno. La validacin de los datos debe conti-
nuar durante su procesamiento. La aplicacin ha de contar con mecanismos
que detecten informacin corrupta, si los resultados no encajan con lo espe-
rado o si la informacin no ha seguido el ciclo esperado de trata-miento.
Integridad de los mensajes. Los mensajes del sistema son herramientas
importantes para detectar y corregir errores, por lo que es fundamental
proteger su autenticidad e integridad.
Validacin de los datos de salida. Terminado el tratamiento de la informa-
cin, se deben validar los datos obtenidos comprobando que son cohe-
rentes con lo esperado, verosmiles y razonables, ya que a pesar de que se
han podido tomar todas las precauciones posibles en anteriores etapas del
procesamiento de la informacin, se pueden producir errores en la salida
que invaliden los datos.
Controles criptogrficos. Cuando la sensibilidad de los datos o su criticidad
hacen recomendable utilizar tcnicas criptogrficas para protegerlos, los con-
troles a aplicar son:
Poltica de uso de los controles criptogrficos. Estas medidas tan espe-
ciales son costosas, por lo que debe haber una poltica para aplicarlas de
manera coherente con las necesidades de la organizacin.
Gestin de claves. El uso de tcnicas criptogrficas implica una gestin
de las claves que les dan soporte, lo cual incluir tener normas para la gene-
racin de claves, su uso y su distribucin a los usuarios autorizados, pro-
tegindolas en todo momento.
Seguridad de los archivos de sistema. Estos archivos, incluyendo el cdigo
fuente, son activos de informacin de los que dependen en gran medida la
seguridad de los datos almacenados en los sistemas. Por ello, debe contro-
larse el acceso y manipulacin de estos archivos. Los controles son:
Control del software en explotacin. Para controlarlo adecuadamente
deben existir procedimientos para efectuar la instalacin y actualizacin
de software en los sistemas operativos, incluyendo el modo de restaurar el
programa inicial si falla la instalacin. Estas tareas debern ser ejecutadas
por administradores con la adecuada formacin y autorizacin para ello, y
slo tras haber realizado pruebas que garanticen la ausencia de problemas
tras la instalacin.
Proteccin de los datos de prueba del sistema. En muchos casos se utilizan
datos reales para realizar las pruebas, por lo que hay que ser muy cuidadosos
al seleccionarlos, mantenerlos protegidos mientras duran las pruebas y eli-
minarlos de ese entorno en cuanto concluyan.
Control de acceso al cdigo fuente de los programas. Un acceso indebido
pondra en peligro la integridad de los programas, por lo que debe tomarse
medidas, tales como mantener el cdigo fuente fuera de los entornos de
produccin y tener distintos niveles de permisos de acceso, ya que no todo
el mundo necesita acceder a toda la biblioteca, por ejemplo, el personal de
asistencia tcnica podr acceder slo a aquellos programas que precisen.
Seguridad en los procesos de desarrollo y soporte. Cuando se desarrolla soft-
ware o se proporcionan servicios de asistencia tcnica, es necesario que el
entorno en el que se desarrollan las actividades sea seguro y est controlado,
lo cual se conseguir con los siguientes controles:
Procedimientos de control de cambios. Realizar cambios en un desarrollo
es una tarea que requiere de un estricto control para evitar costosos fallos.
Por ello, deben realizarse mediante un procedimiento formal que mini-
mice el riesgo de incidentes.
Revisin tcnica de las aplicaciones tras efectuar cambios en el sistema
operativo. Los sistemas operativos son susceptibles de cambios por diver-
sos motivos, pero, al depender de l las aplicaciones, es aconsejable realizar
un chequeo para verificar que esos cambios no han afectado de alguna
manera (funcional, operativa o en seguridad) a las aplicaciones, sobre
todo a aquellas que la organizacin considere crticas.
Restricciones a los cambios en los paquetes de software. Es casi inevitable
tener que realizar cambios a los paquetes de software en algn momento
de su vida til, pero para evitar problemas con su integridad o el de la
informacin que manejan, slo se deben efectuar los cambios estricta-
mente necesarios, por personal autorizado y que controle perfectamente
todo el proceso.
Fugas de informacin. Al desarrollar software se deben prever situaciones
que permitan fugas de informacin, para ello se supervisar al personal,
las actividades del sistema, el uso de los recursos, se escanearn las comu-
nicaciones para detectar informacin oculta, etc.
Externalizacin del desarrollo de software. Cuando se subcontrata el desa-
rrollo de software, deben establecerse los mecanismos apropiados para super-
visar dicho desarrollo, de manera que los requisitos establecidos sean incor-
porados desde el principio y se vayan cumpliendo a lo largo del proyecto.
As se evita llegar al final de proyecto y descubrir que falta alguno de ellos.
Gestin de las vulnerabilidades tcnicas. Los sistemas de informacin estn
sujetos a cambios y actualizaciones para corregir fallos. Los proveedores
informan sobre los mismos y emiten parches y actualizaciones para mitigarlos
o eliminarlos.
Control de las vulnerabilidades tcnicas. Hay que esforzarse para mante-
nerse al da en lo relativo a las vulnerabilidades tcnicas de los sistemas de
informacin que estn siendo utilizados. Con esa informacin se puede
evaluar en qu grado pueden las vulnerabilidades afectar a los sistemas y
al negocio, y adoptar las medidas oportunas. Es decir, no necesariamente
deben implementarse los parches y actualizaciones que recomiende el fa-
bricante, pero al menos hay que considerarlo y tomar una decisin
documentada.
3.10. Gestin de las incidencias
Puesto que es inevitable que las incidencias ocurran, hay que tener mecanismos que
permitan detectarlas y emprender acciones inmediatas para reducir en lo posible
los daos originados. Los objetivos y controles de este captulo tratan precisamente
de cmo hacerlo:
Notificacin de eventos y puntos dbiles de la seguridad de la informacin.
En muchas ocasiones no se solucionan los problemas porque no existen
canales de comunicacin apropiados para comunicarlos. El objetivo consiste
en asegurarse de que los eventos y las vulnerabilidades de la seguridad de la
informacin se comunican, y as puedan buscarse soluciones.
Notificacin de los eventos de seguridad de la informacin. Todos aquellos
en contacto con los sistemas de informacin, trabajadores, contratistas y
terceros, deberan tener instrucciones claras sobre cmo proceder en caso
de que detecten algn evento de seguridad, a quin deben comunicrselo
y de qu forma.
Notificacin de los puntos dbiles de la seguridad. Como en el control
anterior, cualquier usuario de los sistemas y la informacin, tanto los
internos como los externos, deben estar obligados a notificar cualquier
punto dbil que observen o que sospechen que exista.
Gestin de incidentes de seguridad de la informacin y mejoras. Para solu-
cionar eficazmente los incidentes que ocurran deben tomarse medidas estu-
diadas y coherentes. Los controles a aplicar son:
Responsabilidades y procedimientos. Deben existir responsabilidades y
procedimientos, de manera que se pueda dar una respuesta rpida a los
incidentes. Quizs sea necesario establecer distintos niveles de soporte de
incidentes en funcin del tipo y complejidad de los mismos.
Aprendizaje de los incidentes de seguridad de la informacin. Si se regis-
tran los tipos, volmenes y costes de los incidentes de seguridad de la
informacin, pueden detectarse incidentes recurrentes o con un elevado
alcance. Esto permitira adoptar decisiones informadas para la mejora de
los controles o para aadir nuevos, que eviten gastos innecesarios.
Recopilacin de evidencias. Es necesario llevar a cabo este control con rigu-
rosidad en caso de establecer acciones legales tras un incidente. Hay que
recopilar evidencias y conservarlas en la manera prevista por la ley para
que puedan ser admitidas en un tribunal.
3.11. Gestin de la continuidad del negocio
En caso de desastre, la organizacin debe estar preparada para continuar con sus
actividades en el menor plazo de tiempo posible para evitar su desaparicin. Los
peligros de ataque terrorista o desastres casuales, que se materializan de cuando en
cuando y llenan pginas en los peridicos, han hecho que ahora se perciban ms
necesarios este tipo de actividades.
Un plan de continuidad se puede definir como el conjunto de instrucciones y pro-
cedimientos que van a seguirse en una organizacin en caso de que ocurra algo
que interrumpa las actividades normales durante un plazo de tiempo significativo.
Es decir, un corte de luz de unos minutos no ser un incidente grave para la mayora
de las organizaciones. Un corte de luz de horas puede comprometer algunas ope-
raciones de la organizacin y debern existir procedimientos para paliar esta si-
tuacin. Un corte de luz de das es muy probable que requiera un plan de con-
tinuidad en toda regla para impedir que la organizacin colapse.
Un plan de continuidad contendr procedimientos para actuar en cada etapa de la
crisis, hasta que se consigan recuperar las actividades hasta un nivel aceptable. Para
que puedan aplicarse eficazmente, todo el personal de la organizacin debe for-
marse adecuadamente en estos procedimientos:
Aspectos de seguridad de la informacin en la gestin de la continuidad del
negocio. Aun en el caso de que exista algn plan de continuidad en la orga-
nizacin, no es habitual que se contemplen los aspectos relacionados con los
sistemas de informacin y la informacin misma. Pero una organizacin no
puede subsistir sin su informacin, por lo que garantizar su seguridad debe
ser un elemento clave de cualquier plan de continuidad.
Inclusin de la seguridad de la informacin en el proceso de gestin de la
continuidad del negocio. Debera desarrollarse y mantenerse un proceso
controlado para la continuidad del negocio en toda la organizacin que
trate los requisitos de seguridad de la informacin necesarios, como
cules son los activos que soportan los procesos crticos de negocio y cules
seran las consecuencias de incidencias en dichos activos.
Continuidad del negocio y evaluacin de riesgos. Una de las tareas funda-
mentales para desarrollar un plan de continuidad del negocio es el anlisis
del impacto en l, es decir, un anlisis de riesgos donde se identifican las
incidencias que pueden suponer una interrupcin de las actividades, la
probabilidad de que ocurran, sus efectos y sus consecuencias en el tiempo.
Desarrollo e implementacin de planes de continuidad que incluyan la
seguridad de la informacin. Los planes de continuidad de negocio deben
permitir la recuperacin y restauracin de las operaciones de negocio y la
disponibilidad de la informacin en los plazos identificados. Para trazar
un plan de continuidad se debe:
Identificar los objetivos y los responsables de las distintas fases.
Identificar las prdidas aceptables de informacin o servicios.
Definir las escalas temporales en las que deben estar restablecidos los
servicios y la informacin.
Marco de referencia para la planificacin de la continuidad del negocio.
Un marco de referencia de un plan de continuidad del negocio identifica
los requisitos de seguridad de la informacin, adems tendr en cuenta los
aspectos generales, tales como en qu condiciones se activarn los planes,
cules son los procedimientos de emergencia, medidas para proteger la
imagen y reputacin de la organizacin, y formacin del personal para
que pueda ejecutar sus tareas y responsabilidades adecuadamente en caso
de crisis.
Pruebas, mantenimiento y revaluacin de los planes de continuidad del
negocio. El plan ha de revisarse para verificar que sigue siendo aplicable
y que cubre todos los activos. El plan debe probarse para comprobar que es
viable y que todo el mundo conoce las acciones que debe emprender si
se activa el plan.
3.12. Cumplimiento
Este captulo trata de garantizar que los sistemas cumplen con las polticas y normas
de seguridad de la organizacin, as como con los requisitos legales pertinentes.
Cuenta con tres objetivos de control:
Cumplimiento de los requisitos legales. El objetivo de este procedimiento es
cumplir con la legislacin aplicable a la organizacin, evitando infracciones
que pueden resultar muy dainas tanto en trminos econmicos como de
reputacin para la organizacin. En nuestro pas, las principales leyes que
afectan a la mayora de las organizaciones son:
Ley Orgnica 15/1999, de 13 de diciembre, de Proteccin de datos de
carcter personal y Real Decreto 994/1999, de 11 de junio, por el que
se aprueba el Reglamento de Medidas de seguridad de los ficheros auto-
matizados que contengan datos de carcter personal.
Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el
Texto Refundido de la Ley de Propiedad Intelectual.
Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones, para la
regulacin de las telecomunicaciones, sobre la explotacin de las redes y
la prestacin de los servicios de comunicaciones electrnicas y los recursos
asociados.
Ley 34/2002, de 11 de julio, de servicios de la sociedad de la informacin
y de comercio electrnico (LSSI).
Los controles a aplicar son:
Identificacin de la legislacin aplicable. El responsable de seguridad,
junto con los servicios jurdicos de la organizacin, debe mantener actuali-
zada una lista de legislacin vigente aplicable y ocuparse de que cumplan
con ella los que tengan responsabilidades relativas a la aplicacin de la ley.
Derechos de Propiedad Intelectual (DPI). La organizacin debe contar
con procedimientos que garanticen un uso correcto de material con dere-
chos de propiedad intelectual, incluyendo el software propietario.
Proteccin de los documentos de la organizacin. En toda organizacin
existen documentos importantes por diversos motivos, que deben prote-
gerse adecuadamente frente a prdidas, destruccin y falsificacin.
Proteccin de datos y privacidad de la informacin de carcter personal.
El procedimiento deben seguirlo todos los empleados con acceso a datos
personales, bien a travs del sistema informtico habilitado para acceder a
los mismos o bien a travs de cualquier otro medio.
Prevencin del uso indebido de los recursos de tratamiento de la informa-
cin. La organizacin debe tener medidas que impidan que los usuarios
recurran a los sistemas de informacin para usos indebidos.
Regulacin de los controles criptogrficos. Estos controles estn sujetos a
leyes y regulaciones, posiblemente tambin a acuerdos con otras organiza-
ciones, por lo que deben existir normas para su correcta utilizacin.
Cumplimiento de las polticas y normas de seguridad, y cumplimiento tc-
nico. El SGSI contiene numerosas polticas y normas a seguir, por lo que hay
que efectuar un seguimiento para comprobar en qu medida se cumplen.
Cumplimiento de las polticas y normas de seguridad. Los responsables
de cada rea son los encargados de velar por el correcto cumplimiento de las
mismas. Para comprobar que es as, se llevarn a cabo auditoras internas
o externas que detecten las posibles no conformidades.
Comprobacin del cumplimiento tcnico. Deben realizarse chequeos pe-
ridicos de los sistemas para verificar que se estn aplicando los controles
y medidas definidos en el sistema, para detectar posibles errores u omi-
siones que comprometan la seguridad de la informacin.
Consideraciones sobre la auditora de los sistemas de informacin. Objetivo:
lograr que el proceso de auditora de los sistemas de informacin alcance la
mxima eficacia con las mnimas interferencias.
Controles de la auditora de los sistemas de informacin. Las auditoras
informticas son herramientas muy tiles para detectar vulnerabilidades y
puntos de mejora, pero por su propia naturaleza hay que ser cuidadosos al
planificarlas y disearlas, de manera que no interfieran o interrumpan las
actividades habituales de la organizacin.
Proteccin de las herramientas de auditora de los sistemas de informa-
cin. Un uso indebido de estas herramientas, intencionado o no, puede
ser muy perjudicial, por lo que deben estar protegidas y el acceso a ellas
debera encontrarse restringido.
4.1. El proyecto
Bsicamente, un proyecto de definicin de un SGSI se puede estructurar en 7 grandes
bloques, que comprenden una serie de fases y actividades de acuerdo al esquema
presentado en la figura 4.1.
Las actividades principales para crear un SGSI son:
Definicin del alcance, los objetivos y la poltica de seguridad. Debe cubrir
todos los aspectos de la seguridad: seguridad fsica, seguridad lgica, seguri-
dad del personal, y adecuarse a las necesidades y recursos de la organizacin.
Desarrollar el inventario de activos. Hay que tener presente cules son los
activos ms valiosos, que a la vez pueden ser los ms vulnerables.
Realizar el anlisis de riesgos. Cada uno de los pasos ha de ser documentado
en el anlisis de riesgos, con las valoraciones de todos los parmetros impli-
cados: amenazas que afectan a cada activo, nivel de vulnerabilidad, probabi-
lidad de ocurrencia y los efectos que podra suponer que se materializara la
amenaza, es decir, que una amenaza explorara la vulnerabilidad de un activo.
Este anlisis proporcionar un mapa de los puntos dbiles del negocio, que
sern los que hay que tratar en primer lugar.
Seleccionar las medidas de seguridad a implementar. La gestin de los riesgos
implica seleccionar e implementar las medidas tcnicas y organizativas nece-
sarias para impedir, reducir o controlar los riesgos identificados, de forma que
los perjuicios que puedan causar se eliminen o se reduzcan al mximo. Hay
que considerar, antes de seleccionarlos, que dichos controles tienen unos
costes de implementacin y gestin.
4
Definicin e
implementacin
de un SGSI
Lanzamiento y anlisis de situacin 1
2
3
4
5
6
7
Definicin del alcance
Elaboracin de poltica
y propuesta de objetivos
Elaboracin de documentacin del SGSI
(manual, procedimientos, instrucciones)
Implementacin del SGSI
Auditora de certificacin
Inventario
de activos
Anlisis
de riesgos
Seleccin
de controles
Auditora interna Revisin del sistema
Fases del proyecto
Figura 4.1. Fases del proyecto de implementacin de un SGSI
Evaluar los riesgos residuales. Despus de identificar los controles adecuados
para reducir riesgos al valor estimado como aceptable, debe evaluarse en
cunto se reduce el riesgo al aplicarlos. Por muchos controles que se apliquen
no se puede eliminar el riesgo totalmente, siempre habr un riesgo residual.
La direccin tiene que conocer que este riesgo existe y aceptarlo.
75 4. Definicin e implementacin de un SGSI
Documentar los procedimientos necesarios para implementar las medidas
seleccionadas. Los procedimientos son la manera de plasmar la imple-
mentacin de los controles de seguridad y las tareas de administracin
del SGSI. Un procedimiento debe reflejar fielmente los pasos a seguir para
la realizacin de las tareas, pero debe ser conciso y claro para que no se
cometan errores.
Implementacin de los controles y los procedimientos. Puesto que lo habitual
es que haya muchos controles a implementar, lo ms prctico es planificarla
en el tiempo. De todos modos, es preferible abordar proyectos pequeos que
tengan un plazo de ejecucin corto y permitan obtener beneficios enseguida,
que intentar abordar proyectos muy ambiciosos que se alargan en el tiempo
y que no parecen ofrecer un adecuado retorno de la inversin.
Formar y concienciar al personal. Es fundamental para que el SGSI est bien
implementacin que haya un plan de formacin con acciones formativas a
distintos niveles. El responsable del SGSI deber poseer una formacin
exhaustiva en todos los temas relacionados, incluso como auditor interno; el
personal en general tendr que conocer y asumir, si no lo han hecho ya, sus
responsabilidades en materia de seguridad, y los afectados por los nuevos
procedimientos tendrn que asimilar sus nuevas tareas o los cambios que se
han producido en las que ejecutaban.
Realizar la auditora interna y la revisin del SGSI por la direccin. De esta
manera se comprobar que el SGSI se ajusta a la norma y a los requisitos de
la organizacin.
4.2. Documentacin del SGSI
Segn la norma, en un SGSI no se exige un manual de seguridad al uso de otras
normas de gestin, que s especifican que ha de existir un manual de gestin. Sin
embargo, la norma es muy clara en cuanto a la informacin que debe estar docu-
mentada. Por ello, el SGSI consistir en un conjunto de documentos que, como
mnimo, sern los siguientes:
Poltica de seguridad.
Inventario de activos.
Anlisis de riesgos.
Gestin de riesgos.
Documento de aplicabilidad.
Procedimientos para implementar los controles.
Procedimientos para la gestin del SGSI.
Pueden existir tambin otros documentos como planes de seguridad, instrucciones
tcnicas, etc.
Uno de los requisitos de la norma es que se establezca la trazabilidad en todo el sis-
tema, desde la poltica hasta los procedimientos, justificando la eleccin de los con-
troles, que deben ser proporcionales a los riesgos y a las necesidades de la empresa.
Estas necesidades comprenden tanto las de seguridad (cmo de seguro quiere que
sea el sistema), como las del negocio (qu se necesita para funcionar eficazmente,
qu estn haciendo sus competidores) y las legales o reglamentarias (qu leyes y
regulaciones aplicables a su negocio debe tener en cuenta).
4.3. Poltica de seguridad
La poltica de seguridad recoger las lneas generales de actuacin de la organizacin
en una declaracin que estar firmada por la direccin, en la que se compromete a
velar por la confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad
de los activos de informacin.
Adems, como parte de este documento o en otro distinto, se debe documentar:
El alcance del sistema, es decir, qu partes de la organizacin van a estar pro-
tegidas por el SGSI. Puede ser la organizacin entera o una parte relevante
de la misma: departamento, servicio o proceso. La recomendacin a la hora
de decidir el alcance es escoger uno que sea realmente abordable por la
empresa. Si es demasiado amplio y no se cuenta con los recursos necesarios
para llevar a cabo un SGSI de esa dimensin, el proyecto se alargar y llegar
un momento en que se parar, puesto que no hay personal o presupuesto
para continuar con l, con la consiguiente frustracin de los implicados y la
prdida de tiempo y dinero de la organizacin.
La estructura de la empresa, un organigrama de las distintas reas y respons-
ables de la organizacin, y sus relaciones internas.
Las diferentes responsabilidades de cada parte de la organizacin: el respon-
sable de seguridad, la direccin, el responsable de sistemas, el personal, etc.
La topologa de la red, de manera que se muestren los principales sistemas
de informacin y comunicacin que se emplean.
La clasificacin de la informacin, utilizando la nomenclatura de la organi-
zacin y explicando los criterios de clasificacin.
El enfoque y la metodologa del anlisis de riesgos. As cualquiera puede veri-
ficar los resultados del anlisis, ajustndose al razonamiento que se ha seguido
para llevarlo a cabo.
Las normas generales de uso de los activos. Estas normas deben existir para
evitar incidentes no deseados y utilizaciones indebidas de los activos. Sern
hechas pblicas, e incluso pueden ser objeto de una entrega formal a los
empleados o terceras partes implicadas, de modo que se hagan responsables de
las infracciones. Es fundamental establecer unas pautas mnimas en temas
como el empleo de las contraseas y el de las comunicaciones, fuente de
numerosas incidencias. Estas normas de uso son un elemento importante en la
concienciacin del personal, ya que establecen unas pautas de compor-
tamiento, que aunque sean de sentido comn y no marquen lmites demasiado
estrictos, s indican que la empresa se preocupa al respecto y que los emplea-
dos deberan hacer lo mismo.
Los objetivos de seguridad que se pretenden alcanzar. Puede ser difcil
establecer unos objetivos claros y tiles sin tener datos de partida, pero al
menos se deber intentar expresar qu nivel de seguridad se desea alcanzar.
Se puede comenzar por estimar qu metas se quieren lograr en trminos
de confidencialidad, disponibilidad e integridad. Por ejemplo, para veri-
ficar las mejoras en confidencialidad puede utilizarse como mtrica el
nmero de incidencias relativas a la confidencialidad, y decidir que el obje-
tivo para este ao va a ser tener tres o menos incidencias de este tipo. Con
los resultados que se vayan obteniendo, se ir revisando dicho objetivo
para ajustarlo a la realidad. Si sistemticamente obtenemos un valor mucho
ms elevado, puede que el objetivo no sea realista y haya que revisarlo a la
baja.
Un ejemplo de cmo realizar este documento puede consultarse en el apartado 8.1
de este libro.
4.4. Inventario de activos
El inventario de activos es la recopilacin de todos aquellos elementos indispensa-
bles para que la administracin electrnica pueda prestarse con todas las garantas,
de manera que los ciudadanos tengan confianza en ella.
El inventario de activos debe recoger la siguiente informacin:
El nombre del activo, por ejemplo: equipo de usuario, router 014, proyecto,
expediente, etc.
La descripcin del activo.
Categora a la que pertenece, por ejemplo: equipo, aplicacin, servicio, etc.
Ubicacin: el lugar fsico en el que se encuentra dentro de la organizacin.
Propietario: entendiendo por tal al responsable del activo.
Identificados los activos de informacin: se les debe valorar de acuerdo a su
importancia para la empresa. Esta apreciacin ser lo ms objetiva posible, ya
que con ella se determinar sobre qu activos se realizar el anlisis de riesgos.
Por supuesto, se puede hacer una estimacin de todos los activos, pero si son
muchos, los recursos limitados, o ambas cosas, lo razonable es elegir un grupo
de activos reducido para que el anlisis de riesgos no sea inabarcable. Por ejem-
plo, se puede escoger analizar los activos que estn por encima de un valor.
Para valorar los activos se considerarn los parmetros de confidencialidad, disponi-
bilidad e integridad de los activos, determinndose la importancia que tienen para la
organizacin en una escala de valores predefinida.
Como ejemplo, vamos a utilizar un activo llamado Facturas, del tipo Datos,
ubicado en el Servidor S y cuyo propietario es el responsable de administracin.
Cada uno de los parmetros se valorar del 1 al 4 segn su relevancia para la orga-
nizacin, y el valor total del activo ser la suma aritmtica de todos los valores par-
ciales (vase la tabla 4.1).
La confidencialidad de las facturas es importante, pero no crtica, puesto que ha de
estar disponible para mucha gente (clientes, Hacienda, asesores fiscales, personal
de administracin, etc.) y su filtracin no supondra un trastorno excesivo. Una
base de datos de clientes tendra un valor ms alto en este aspecto, por contener
datos de carcter personal.
La integridad de las facturas es muy importante, puesto que las errneas son
origen de reclamaciones y trabajo extra, e incluso de sanciones por parte de la
Activo Confidencialidad Integridad Disponibilidad Valoracin total
Facturas 2 4 2 8
Tabla 4.1. Inventario de activos
Administracin, lo cual no es en absoluto deseable. La integridad de un expediente
de compra se valorara menos.
Que las facturas estn disponibles es importante, pero no fundamental para que el
negocio contine funcionando. No se producir un trastorno serio en la organi-
zacin a menos que el momento en el que suceda la indisponibilidad sea crtico
(por ejemplo, cuando llega la hora de preparar los impuestos o cerrar el ao). Sin
embargo, la disponibilidad del Servidor S en el que se alojan las facturas se valo-
rara ms alta, puesto que la indisponibilidad de dicho equipo s supondra un
trastorno considerable para la marcha de la organizacin.
La suma de los valores nos da 8. Haciendo lo mismo para todos los activos po-
dremos estimar cules son los activos ms crticos, ms valiosos para la organi-
zacin y establecer comparaciones.
Obviamente, los razonamientos anteriores son hipotticos y se ofrecen a modo de
ejemplo. En cada organizacin los activos se ven y valoran de acuerdo con las cir-
cunstancias y la utilizacin que brinda cada uno de ellos.
Otro aspecto a documentar en este punto es la relacin entre los procesos de negocio y
los activos de informacin. Segn la norma se debe documentar cmo la informacin
que se gestiona en la empresa soporta los procesos de negocio, es decir, colabora en el
funcionamiento del negocio y, por lo tanto, en que ste siga generando ingresos.
Para ello hay que definir cules son los principales procesos de negocio (adminis-
tracin, produccin, gestin de proyectos, compras, etc.) y especificar qu activos
forman parte de su operativa normal. Por ejemplo, podemos considerar que el pro-
ceso Compras se apoya en el personal del departamento, las aplicaciones con las
que se produce la documentacin, la propia documentacin (peticiones de oferta,
ofertas, rdenes de compra, etc.), los equipos de usuarios, los servidores donde se
aloja la informacin y las comunicaciones.
Un ejemplo de cmo realizar este documento puede consultarse en el apartado 8.2 de
este libro.
4.5. Anlisis de riesgos
Para efectuar el anlisis de riesgos confeccionaremos (o utilizaremos la propuesta
por la metodologa o herramienta que se haya escogido) una lista de las amenazas
a las que se enfrenta la empresa. Por ejemplo:
Fuego.
Inundacin.
Probabilidad de ocurrencia
de la amenaza
Gua
1 Muy baja Una media de una vez cada 5 aos
Una media de una vez cada 2 aos
Una media de una vez al ao
Una media de 3 veces al ao
2 Baja
3 Media
4 Alta
Corte de suministro elctrico.
Fallo del suministro de comunicaciones.
Error de usuario.
Para cada activo hay que valorar cul es la vulnerabilidad de ese activo con respecto
a cada una de las amenazas. Esta valoracin se har de acuerdo a una escala definida
por la empresa, por ejemplo de 1 a 4:
1 Nada vulnerable.
2 Poco vulnerable.
3 Bastante vulnerable.
4 Muy vulnerable.
Es decir, si tenemos un activo facturas expuesto a la amenaza fuego, ser muy
vulnerable (4) si las facturas estn en soporte papel, pero podemos considerar que
es bastante vulnerable (3) si estn en soporte electrnico.
El siguiente paso ser decidir cul es la probabilidad de que ocurra la amenaza
(vase la tabla 4.2).
Por ltimo, para decidir el nivel de riesgo de los activos habr que evaluar el
impacto que tendra en el negocio que la amenaza se materializara, siguiendo con
el ejemplo anterior, que un incendio acabara con las facturas.
Hay que definir de nuevo una escala para asignar un valor numrico a ese impacto,
como:
1 Ningn impacto.
Tabla 4.2. Anlisis de riesgos
Amenazas Facturas
Fuego
Fallo de electricidad
Error de usuario
3 1 3 9
1 3 3 9
4 4 2 32
2 Poco impacto.
3 Bastante impacto.
4 Mucho impacto.
En nuestro ejemplo vamos a considerar que el impacto sera 3.
Estas valoraciones se deben realizar sin aplicar ninguna medida de seguridad a los
activos, es decir, hay que estimar que nuestras facturas en papel estn simplemente
en una carpeta o que las facturas en soporte electrnico no tienen copias de seguri-
dad ni se encuentran protegidas por contrasea.
Con los valores obtenidos para cada activo hay que calcular el riesgo para cada
amenaza (que ser, por ejemplo, el producto de los tres parmetros), y despus cal-
cular el nivel de riesgo de ese activo, que puede ser una simple suma de todos los
valores obtenidos o puede optarse por tomar slo el valor ms alto. El objetivo es
cuantificar algo tan intangible como el nivel de riesgo y poder comparar todos los
activos con un criterio homogneo. Por ello, el mtodo de clculo no es tan crucial
como los criterios que se apliquen para efectuar esos clculos, que deben ser claros,
coherentes y bien definidos.
Las escalas y los clculos sern concretos, entendibles y se aplicarn a todos los
activos de la misma manera.
En este ejemplo (vase la tabla 4.3), el nivel de riesgo puede considerarse que
es 32, puesto que es el mayor de los obtenidos, o bien se pueden sumar los valores
y sera 50. En cualquier caso, lo esencial es utilizar el mismo sistema para todos y
cada uno de los activos, puesto que de lo que se trata es de comparar sus niveles de
riesgo, ver qu activos tienen ms riesgo que otros. De esta manera, obtendremos
un mapa de riesgos coherente, como en la tabla 4.4, del que se puede deducir
que la aplicacin de gestin est expuesta a ms riesgo y entonces debern aplicarse
ms medidas de seguridad para protegerla.
Tabla 4.3. Ejemplo del nivel de riesgo
Activo Riesgo
Facturas 32
24
48
9
Equipos de usuario
Aplicacin de gestin
Base de datos de proveedores
Tabla 4.4. Mapa de riesgos
Tanto los mtodos de clculo como las valoraciones y los resultados quedarn docu-
mentados para cumplir con la norma.
Una vez obtenidos todos los valores de riesgo hay que decidir qu se va hacer con
cada uno de ellos, si se va a asumir, a transferir, a eliminar o a mitigar. Esta
declaracin de la gestin de los riesgos estar firmada por la direccin. Normal-
mente las decisiones son asumir los riesgos o mitigarlos. En cualquier caso hay que
tener en cuenta que siempre habr un pequeo grupo de controles que van a apli-
carse sobre todos los activos o sobre muchos, como es el caso de la poltica de
seguridad, el inventario de activos, la proteccin de los datos personales o las
copias de seguridad.
Decidir en qu punto un nivel de riesgo puede ser asumido por la empresa, o por
decirlo con la expresin utilizada en la norma, cundo un riesgo es asumible, depende
por entero de la empresa y de hasta qu punto puede y quiere tomar medidas en
cuanto a la seguridad de su informacin. Por eso hay que idear de nuevo un criterio
para distinguir entre los riesgos asumibles y los que no lo son.
Siguiendo con nuestro ejemplo, los posibles valores de riesgo iran del 1 al 64, por
lo que podramos estipular que la mediana, el 32, es el valor por debajo del cual se
considerar asumible el riesgo. Otra opcin podra ser la media de los valores, o
directamente convenir un valor por debajo del cual el riesgo es asumible, por ejem-
plo 10. La norma no especifica nada sobre cmo escoger este valor, y es la empresa
la que debe valorar cuntos riesgos est dispuesta a correr y hasta dnde puede
invertir en mitigarlos.
La documentacin del anlisis de riesgos recoger:
Todas las valoraciones realizadas.
Los valores de riesgo intrnseco.
Cul es el riesgo asumible.
Las decisiones tomadas respecto a cada uno de los activos.
Un ejemplo de cmo realizar este documento puede consultarse en el apartado 8.3
de este libro.
4.6. Gestin de riesgos
Una vez que sabemos a qu nos estamos enfrentando, es necesario escoger de entre
los controles incluidos en la Norma UNE-ISO/IEC 27002 los que nos van a servir
para reducir los niveles de riesgo identificados en la fase anterior.
En un sentido amplio, los controles se pueden dividir en dos grupos, los de carcter
organizativo y los tcnicos. Es importante lograr un balance en la seleccin que ase-
gure que no slo se aplican las medidas tcnicas apropiadas, sino que la gestin de la
seguridad es lo suficientemente slida como para que funcionen correctamente.
Hay que revisar uno por uno los controles y considerar:
Si est ya implementado.
Si ayudara a reducir el riesgo de alguno de los activos.
Si el coste de implementarlo es aceptable.
Si el coste de la operacin y el mantenimiento del control sern aceptables.
Existen una serie de controles que deben ser implementados obligatoriamente
si optamos por la certificacin, por ejemplo, tener una poltica de seguridad o un
inventario de activos, pero salvo esos, el resto, aunque nos parezcan muy apro-
piados al problema que tenemos entre manos, hay que valorar cuidadosamente los
criterios expuestos anteriormente, porque aplicar un control que luego es muy cos-
toso de implementar no va a ser una medida de seguridad eficiente, y uno que
suponga mucho esfuerzo implementacin por motivos culturales o de organi-
zacin, ser difcil que llegue a ser eficaz.
No hay un nmero establecido o recomendado de controles a implementar. Se
deben implementar todos aquellos que beneficien a la seguridad de la informacin,
pero no pretender abarcar demasiados, puesto que lastraran el desarrollo del SGSI
y no le permitiran una implementacin adecuada.
Por ejemplo, el activo facturas que manejbamos. Ser necesario contar con con-
troles de acceso a esta informacin (no todo el mundo tiene por qu acceder a ella),
copias de seguridad (que garanticen la disponibilidad de la informacin) o proce-
dimientos para intercambio de informacin (cmo las vamos a hacer llegar de
manera segura a los clientes o a los asesores garantizando su integridad). En gene-
ral, estos controles son fciles de implementar e incluso en muchos casos, aunque
sea de manera informal, ya existen buenas prcticas relacionadas. El coste no
resulta elevado y reducen los principales riesgos detectados (fallos de usuario,
fuego). Aislar los equipos en los que se tratan las facturas en un rea segura, con
costosas medidas de seguridad fsica y equipos especiales que garanticen la
disponibilidad es, normalmente, demasiado gravoso econmicamente para los
beneficios que se obtienen. La reduccin del riesgo sera mayor que en el primer
caso, pero no compensara.
Puesto que estamos hablando de sistemas de gestin orientados a la mejora continua,
es mucho ms prctico en una primera iteracin quedarse con un conjunto mnimo
de controles que cumplan con los requisitos de la Norma UNE-ISO/IEC 27001,
y que mitiguen hasta un nivel aceptable, aunque no sea muy bajo, el riesgo. Una
vez que el SGSI funciona de un modo correcto, se pueden ir aadiendo controles
o mejorando la implementacin de los existentes para reducir progresivamente el
riesgo, es decir, para ir mejorando el sistema.
Decididos los controles a implementar e identificados aquellos que ya se utilizaban
en la empresa, hay que repetir el anlisis de riesgos, cindose al mismo mtodo y
a los mismos criterios que la primera vez. La diferencia estriba en que lo que ahora
se debe valorar es el riesgo, puesto que ya tenemos medidas de seguridad que
habrn reducido la vulnerabilidad del activo y el posible impacto que un incidente
de seguridad supondra.
Retomando nuestro ejemplo, supongamos en esta ocasin que el activo facturas
existe en papel, guardado en un armario en una oficina con medidas antiincendios
(detectores, extintores, alarmas), y adems se almacenan en un servidor, que con-
tar con un Sistema de Alimentacin Ininterrumpida (SAI), situado en un armario
especfico cerrado con llave, con control de temperatura, etc. Adems se realiza una
copia semanal de seguridad, que a partir de ahora se enviar a otra ubicacin.
Con estas medidas de seguridad implementadas o a punto de hacerlo, la vulnera-
bilidad al fuego se ha reducido quizs a 1, y como existen copias de seguridad
incluso fuera de la oficina, el impacto tambin se reducir, por ejemplo a 2. La
vulnerabilidad al fallo de electricidad, es baja, el SAI puede ayudar a aminorar el
impacto, ya que si se produce un fallo el usuario puede terminar y guardar su tra-
bajo antes de que la avera lo elimine o corrompa. Puesto que la implementacin
de un SGSI conlleva la definicin y publicacin de una poltica de seguridad con
normas para los usuarios, la vulnerabilidad al error de usuario deber ser menor
(vase la tabla 4.5).
Amenazas
Facturas
Riesgo
inicial
Vulnera-
bilidad
Impacto
Riego
residual
Fuego
Fallo de electricidad
Error de usuario
9 1 2 2
3 1 2 2
8 2 2 4
El grado de riesgo del activo facturas es ahora de 4, lo cual le sita en un nivel
inferior por debajo del cual el riesgo es asumible, es decir, no es necesario aadir
ms controles a este activo.
En esta fase se generarn dos documentos: el documento de aplicabilidad y el
informe de gestin de riesgos.
Las decisiones sobre aplicar o no un control debern quedar documentadas en el
documento de aplicabilidad. Este documento debe contener para cada control la
siguiente informacin:
Si est aplicado.
Si se va a aplicar.
Si no se va a aplicar.
Razonamiento explicando la decisin.
El informe de gestin de riesgos recoger:
Los controles aplicados a cada activo.
Las valoraciones y los valores de riesgo resultantes tras la aplicacin de los
controles.
La aceptacin de la direccin de los riesgos residuales.
Un ejemplo de cmo realizar dichos documentos puede consultarse en los apar-
tados 8.4 y 8.5 de este libro.
Tabla 4.5. Gestin de riesgos
4.7. Plan de tratamiento del riesgo
Es conveniente, una vez decidido lo que se va a hacer, que se prepare un plan para
ejecutar las tareas a emprender para que el SGSI quede completamente implemen-
tado.
Las principales tareas sern la implementacin de todos los controles, la formacin,
la auditora interna y la revisin por la direccin.
El plan puede ser adems el documento idneo para plasmar los objetivos de seguri-
dad junto con un grupo de mtricas relevantes, medibles con escasos recursos y que
ofrezcan una informacin fiable de cmo funciona el SGSI.
La norma establece que se debe medir el rendimiento de todos aquellos controles
que se consideren relevantes. Adems, hay que procurar que medir no resulte cos-
toso, por lo que se escoger un grupo reducido de mtricas que nos orienten sobre
si el SGSI funciona o no, por ejemplo, partiendo de los tres aspectos de seguridad,
y ver de qu manera podemos medir si conseguimos mantenerlos:
Confidencialidad: reducir el porcentaje de incidentes relacionados, aumentar
la concienciacin del personal, etc.
Disponibilidad: porcentaje de disponibilidad de los equipos y sistemas.
Integridad: reducir el porcentaje de informacin errnea, disminuir el por-
centaje de fallos del sistema o las aplicaciones, etc.
Una vez en marcha el programa de mtricas, se ver cules son los puntos que
aportan informacin relevante sobre la marcha del SGSI, cules deberan ser
descartados y cules incorporados para mejorar nuestro conocimiento del fun-
cionamiento del SGSI. El mismo funcionamiento de los controles puede sugerir
nuevos objetivos y mtricas que aadir.
Un ejemplo de este documento puede consultarse en el apartado 8.6 de este libro.
4.8. Procedimientos
Es uno de los puntos ms problemticos. El objetivo de un procedimiento es
describir la manera en la que se va a realizar una tarea. El nivel de detalle de un pro-
cedimiento no debera ser muy alto. Se trata de contar cmo se hace una tarea de
forma que alguien que no est familiarizado con ella pudiera ejecutarla en caso
necesario. Para ello se debera describir a grandes rasgos lo que se debe hacer y citar
aquellos documentos que puedan ser de ayuda para llevar a cabo la tarea. Se debe
evitar ofrecer detalles que pueden cambiar con frecuencia, y obligaran a revisar el
procedimiento muy a menudo. Este tipo de datos deberan documentarse en
instrucciones tcnicas y no en procedimientos.
El lenguaje debera ser lo ms claro posible, evitando modismos y jergas ininteligi-
bles o que conduzcan a malas interpretaciones. El estilo debera ser conciso, sin
rebozos, lo cual facilita la comprensin del texto. El procedimiento, lo ms breve
posible para que sea sencillo de leer, comprender y, lo ms importante, de utilizar.
No hay ninguna regla respecto al nmero de procedimientos que deben crearse.
Adems, un control puede implementarse de diversas maneras. Habr, por ejem-
plo, controles que se implementarn con un documento como el inventario de
activos, y otros que lo harn con una medida tcnica (instalacin de un cortafue-
gos). Cuando la implementacin se efecte mediante un procedimiento, puede
aplicarse un procedimiento para cada control que se ha decidido implementar, pero
no es necesario. Tambin resulta til recoger en un mismo procedimiento varios
controles relacionados, por ejemplo, los relativos al control de accesos. Esta agru-
pacin facilita enormemente la implementacin de los controles y la gestin de la
documentacin, y en consecuencia hace ms sencilla la implementacin del sistema.
Por otro lado, dependiendo de la complejidad de la organizacin o de las activi-
dades a tratar, tambin puede suceder que un control requiera ms de un procedi-
miento para implementarse.
Sealar de nuevo que lo propuesto por la Norma UNE-ISO/IEC 27002 es mera-
mente informativo, puede utilizarse como referencia y punto de partida, pero los
procedimientos deben recoger el modo de ejecutar un control o varios, depen-
diendo del funcionamiento, estructura y cultura de la organizacin. En la medida
que el procedimiento refleje la realidad de la organizacin, o al menos la tenga en
cuenta al introducir los cambios, tendr ms xito la implementacin de los nuevos
modos de trabajo.
Es en este punto donde se hace ms notoria la necesidad de ajustar el sistema a la
organizacin. Los procedimientos son los documentos de trabajo que ms difusin
van a tener y que ms van a afectar al personal tras la poltica de seguridad. Por eso
es crucial que se perciban como herramientas de trabajo tiles y no como directri-
ces alejadas de los modos habituales de trabajo. Para ello deben reunir todos los
requisitos mencionados, que sintetizaremos en dos palabras: claridad y realismo.
Un ejemplo de cmo realizar este documento puede consultarse en los aparta-
dos 8.7 y 8.8 de este libro.
4.9. Formacin
El personal afectado por el SGSI, y en la medida de lo posible, todo el personal de
la empresa, debe recibir formacin adecuada en seguridad de la informacin.
El personal es el elemento clave que permitir al SGSI funcionar o fracasar. Todo el
mundo ha de conocer su existencia, el motivo de la nueva situacin y los objetivos
que se persiguen al implementar los nuevos modos de trabajo o al formalizar los ya
existentes.
Cada grupo tendr unas necesidades especficas y no todo el mundo necesitar for-
macin en todos los aspectos del SGSI. Por eso, el plan de formacin deber
recoger distintas actuaciones en funcin de estas necesidades.
Los medios de comunicacin interna que ya existan en la organizacin (intranet,
paneles informativos, boletines, etc.) son muy tiles para difundir, por ejemplo, la
poltica de seguridad que debe llegar a toda la organizacin.
La formacin puede ser interna, por ejemplo, charlas del responsable de seguridad
para explicar qu es un SGSI, las causas de su implementacin y los principales
cambios que haya habido es una manera muy eficaz de informar a todos.
La asistencia o participacin de la direccin en las acciones formativas es una exce-
lente oportunidad de demostrar su compromiso con el SGSI y su apoyo a la iniciativa.
4.10. Revisin por la direccin
El informe de revisin por la direccin habitualmente es elaborado por el respon-
sable de seguridad, que siguiendo los parmetros establecidos por la norma, realiza
un resumen de lo que se ha hecho y de cmo se ha desarrollado la implementacin
o en su caso la operativa del SGSI, con las incidencias, los problemas, las soluciones
y los beneficios recabados.
Este informe debe ser estudiado y aprobado por la direccin, lo cual se hace en
muchos casos dentro del comit de seguridad.
4.11. Auditora interna
La auditora es una potente herramienta que permite detectar errores y puntos
dbiles en el SGSI. Consiste en evaluar hasta qu punto el SGSI se ajusta a la
norma y el grado de cumplimiento de la organizacin de sus propias normas.
Para ello:
Se comprueba que la documentacin del SGSI est de acuerdo con lo
establecido en la norma.
Se revisa cada punto de la norma y se va verificando que, efectivamente, exis-
ten pruebas de su cumplimiento (habitualmente estas pruebas son los reg-
istros generados al ejecutar los procedimientos).
Se revisan los procedimientos, confirmando que se ejecutan tal y como est
establecido en ellos, realizando pruebas de cumplimiento, es decir, verificar
tcnicamente que los procedimientos se cumplen: que los usuarios estn efec-
tivamente dados de alta, que se efectan las copias de seguridad y cmo, etc.
Las auditoras internas deberan recoger y utilizar los resultados de otras auditoras
que se lleven a cabo, como la auditora de la LOPD, pruebas de intrusin, audi-
toras informticas, etc.
Los auditores internos han de conocer la empresa a fondo, ser independientes,
objetivos y tener algn conocimiento del SGSI.
4.12. Registros
Puestos en marcha los procedimientos, se generarn una serie de registros, que son
la prueba de que se han ejecutado.
Algunos de los principales registros son:
Actas del comit de seguridad.
Informe de la revisin por la direccin.
Informes de auditoras.
Registros de formacin.
Perfiles profesionales.
Acciones correctivas y preventivas.
Registros de copias de seguridad.
Registros de mantenimientos.
Registros de usuarios.
Los registros pueden estar en cualquier formato y soporte, pero debern per-
manecer controlados para que no se deterioren o pierdan. El nmero de registros
depender de qu procedimientos se encuentren en uso, su complejidad y las cos-
tumbres de la empresa.
La recomendacin es automatizar lo ms posible la produccin de registros para
evitar tener que generarlos manualmente, con el consiguiente consumo de recursos.
5
Proceso de certificacin
Actualmente, la Norma UNE-ISO/IEC 27001 es la norma espaola vigente para
la certificacin de sistemas de gestin de la seguridad de la informacin.
La Norma UNE-ISO/IEC 27002 no es certificable, es slo una gua de buenas prc-
ticas.
Hay que tener claro que con estas normas no estamos certificando la seguridad de
la informacin de nuestra organizacin, sino el sistema mediante el cual gestion-
amos esta seguridad.
Certificar un sistema de gestin es obtener un documento que reconoce y respalda
la correcta adecuacin del sistema de gestin de seguridad de la informacin con-
forme a una norma de referencia, en este caso la Norma UNE-ISO/IEC 27001.
El certificado de cumplimiento de una norma nicamente puede ser emitido por
una entidad debidamente acreditada ante el organismo que define los criterios bajo
los que pueden llevarse a cabo estas actividades.
En Espaa las entidades de certificacin tienen que estar acreditadas por ENAC.
ENAC es una entidad privada, independiente y sin nimo de lucro, cuya funcin
es coordinar y dirigir en el mbito nacional un sistema de acreditacin conforme a
criterios y normas internacionales. ENAC acredita organismos que realizan acti-
vidades de evaluacin de la conformidad, sea cual sea el sector en que desarrolle su
actividad, su tamao, su carcter pblico o privado, o su pertenencia a asociaciones
o empresas, universidades u organizaciones de investigacin. ENAC acredita a labo-
ratorios, entidades de inspeccin, entidades de certificacin, verificadores medioam-
bientales, etc.
La realizacin de auditoras de sistemas de gestin en general se rige por la Norma
UNE-EN ISO/IEC 17021 Evaluacin de la conformidad. Requisitos para los organismos
que realizan la auditora y la certificacin de sistemas de gestin, y en particular, son
los SGSI los que deben ser auditados por entidades que cumplan los requisitos de
la Norma ISO/IEC 27006 Tecnologa de la informacin. Tcnicas de seguridad. Req-
uisitos para organismos proveedores de auditora y certificacin de Sistemas de Gestin de
Seguridad de la Informacin.
Entre los beneficios de emprender la certificacin sealaremos los siguientes:
Contribuye a impulsar las actividades de proteccin de la informacin en las
organizaciones.
Mejora la imagen y afianza la reputacin de una organizacin.
Genera confianza frente a terceros, ya que es una prueba de la rigurosidad de
la gestin de la empresa.
Es un factor que permite diferenciarse de la competencia, lo que proporciona
una cierta ventaja competitiva.
Si no existe todava otro sistema de gestin en la organizacin, logra crear
una cultura de enfoque a procesos y de mejora continua que beneficiar a
toda la estructura.
La organizacin que desee solicitar el certificado debe contactar con una entidad
de certificacin acreditada.
Esta entidad recoge la informacin bsica de la empresa, como su tipo de negocio,
nmero de empleados y actividades a certificar, con el fin de asignar un equipo
auditor adecuado y determinar el nmero de das necesarios para llevar a cabo la
auditora.
Fase 1. Revisin documental. El equipo auditor revisa la documentacin
del SGSI para verificar que cumple con los principales requisitos de la norma
y emiten un informe con los hallazgos. Si el equipo auditor descubriese
incumplimientos graves de la norma, informaran a la organizacin de la
imposibilidad de conseguir la certificacin en esas condiciones. Si detectasen
pequeas no conformidades, habra que corregirlas antes de la siguiente fase,
que suele realizarse un mes ms tarde.
Fase 2. Auditora de certificacin. El equipo auditor recoger evidencias
objetivas de que la organizacin cumple tanto con los requisitos de la normas
como con sus polticas, objetivos y procedimientos, as como con los requi-
sitos documentados. Si los auditores no detectan no conformidades graves, se
concede el certificado a la empresa.
Apartados de la norma Documento de soporte
0 Introduccin
1 Objeto y campo de aplicacin
2 Normas para consulta
3 Trminos y definiciones
4 Sistema de gestin de la seguridad de
la informacin
4.1 Requisitos generales
4.2 Creacin y gestin del SGSI
4.2.1 Creacin del SGSI
Poltica de seguridad
Inventario de activos
Anlisis de riesgos
Gestin de riesgos
Documento de aplicabilidad
(contina)
Relacin entre los
apartados de la norma y
la documentacin del sistema
6
Para certificar un SGSI debe cumplir con los apartados 4 al 8 de la norma. La justifi-
cacin de este cumplimiento quedar recogida en los documentos correspondientes y
los registros de ciertas actividades, que, a modo de ejemplo, pueden ser los siguientes:
4.2.2 Implementacin y operacin
del SGSI
4.2.3 Supervisin y revisin del SGSI
4.2.4 Mantenimiento y mejora del SGSI
4.3 Requisitos de la documentacin
4.3.1 Generalidades
4.3.2 Control de documentos
4.3.3 Control de registros
Plan de tratamiento del riesgo
Gestin de incidencias
Auditoras internas
Revisin por la direccin
Monitorizacin de objetivos
Acciones de mejora
Acciones preventivas y correctivas
Objetivos de seguridad
Procedimientos
Anlisis de riesgos
Gestin de riesgos
Registros
5 Responsabilidad de la direccin
5.1 Compromiso de la direccin Poltica y planes firmados
Criterios y aceptacin
de riesgos firmada
Revisin aprobada por la direccin
5.2 Gestin de los recursos
5.2.1 Provisin de los recursos Planes de seguridad
5.2.2 Concienciacin, formacin y
capacitacin
Planes de formacin
Registros de formacin
Procedimiento para el
control de la documentacin
Procedimiento para
el control de los registros
(contina)
95 6. Relacin entre los apartados de la norma y la documentacin del sistema
6 Auditoras internas del SGSI
7 Revisin del SGSI por la direccin
Plan de auditoras
Informes de auditoras
Informe de revisin por la direccin
7.1 Generalidades
7.2 Datos iniciales de la revisin
7.3 Resultados de la revisin
8 Mejora del SGSI
Acciones de mejora
Acciones correctivas
Acciones preventivas
8.1 Mejora continua
8.2 Accin correctiva
8.3 Accin preventiva
UNE-EN ISO 9001:2008
0 Introduccin
UNE-EN ISO 14001:2004
Introduccin
1 Objeto y campo de
aplicacin
UNE-ISO/IEC 27001:2007
0 Introduccin
0.1 Generalidades
0.2 Enfoque basado en
procesos
0.3 Relacin con la
Norma ISO 9004
0.4 Compatibilidad
con otros sistemas
de gestin
0.2 Enfoque por procesos
1 Objeto y campo de
aplicacin
1.1 Generalidades
1.2 Aplicacin
1 Objeto y campo de
aplicacin
4 Requisitos del sistema
de gestin ambiental
4 Sistema de gestin de
la calidad
4 Sistema de gestin de
la seguridad de la
informacin
2 Normas para consulta 2 Normas para consulta 2 Normas para consulta
3 Trminos y definiciones 3 Trminos y definiciones 3 Trminos y definiciones
1.1 Generalidades
1.2 Aplicacin
0.3 Compatibilidad
con otros sistemas
de gestin
0.1 Generalidades
(contina)
7
Correspondencia entre las
Normas UNE-EN ISO 9001:2008,
UNE-EN ISO 14001:2004
y UNE-ISO/IEC 27001:2007
UNE-EN ISO 14001:2004
UNE-ISO/IEC 27001:2007
5.4 Planificacin 4.3 Planificacin
8.2.3 Seguimiento
y medicin de
los procesos
8.2.4 Seguimiento
y medicin
del producto
4.2 Requisitos de la
documentacin
4.5.1 Seguimiento y
medicin
4.2.3 Supervisin y
revisin del SGSI
4.2.4 Mantenimiento y
mejora del SGSI
4.4 Implementacin y
operacin
4.2.2 Implementacin y
operacin del SGSI
4.4.5 Control de los
documentos
documentos
4.3 Requisitos de la
documentacin
4.2.1 Generalidades
4.2.2 Manual de
la calidad
documentos
registros
4.3.3 Control de registros 4.2.4 Control de los
registros
5 Responsabilidad
de la direccin
5 Responsabilidad
de la direccin
5.2 Enfoque al cliente
5.3 Poltica de la calidad 4.2 Poltica ambiental
5.1 Compromiso
de la direccin
5.1 Compromiso
de la direccin
4.3.1 Generalidades
4.2 Creacin y gestin
del SGSI
(contina)
99 7. Correspondencia entre las Normas UNE-EN ISO 9001:2008, UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007
4.6 Revisin por
la direccin
6.2 Recursos humanos
6.3 Infraestructura
6.4 Ambiente de trabajo
5.6.1 Generalidades
5.6.2 Informacin
de entrada para
la revisin
8.2.2 Auditora interna 4.5.5 Auditora interna 6 Auditoras internas
del SGSI
5.6 Revisin por
la direccin
7 Revisin del SGSI por
la direccin
7.1 Generalidades
7.2 Datos iniciales
de la revisin
8.5 Mejora
8.5.1 Mejora continua
8 Mejora del SGSI
8.1 Mejora continua
8.5.3 Accin preventiva 8.3 Accin preventiva
8.5.2 Accin correctiva 4.5.3 No conformidad,
accin correctiva
y accin preventiva
5.6.3 Resultados de
la revisin
7.3 Resultados de
la revisin
5.5 Responsabilidad,
autoridad y
comunicacin
6.2.2 Competencia,
formacin y toma
de conciencia
4.4.2 Competencia,
formacin y toma
de conciencia
5.2.2 Concienciacin,
formacin y
capacitacin
6 Gestin de los recursos
UNE-EN ISO 14001:2004 UNE-ISO/IEC 27001:2007
5.2 Gestin de
los recursos
6.1 Provisin de recursos 5.2.1 Provisin de
los recursos
8.1. Documentacin de la poltica de seguridad
8.1.1. Poltica de seguridad de la informacin
En este apartado se debera hacer relacin de los puntos que describan la poltica
de seguridad de la informacin de la empresa. Esta poltica debe estar aprobada por
la direccin de la empresa y debera ser revisada anualmente.
8.1.2. Definicin del SGSI
Este apartado recoge el mbito de aplicacin y los lmites del SGSI teniendo en
cuenta las actividades que realiza la organizacin, los servicios y productos que
oferta, el equipamiento con el que cuenta y las restricciones legales o reglamen-
tarias que sean aplicables a su actividad.
8.1.2.1. Conceptos generales
Definicin de los conceptos ms bsicos de la seguridad:
Disponibilidad.
Confidencialidad.
Integridad.
Seguridad de la Informacin.
Sistemas de Gestin de Seguridad de la Informacin.
Tambin se pueden incluir las definiciones de conceptos utilizadas internamente en
la empresa.
Caso prctico:
modelo de SGSI
8
8.1.2.2. Campo de aplicacin de la poltica de seguridad
Descripcin de a quin y a qu afecta la poltica de seguridad, ya que puede ser al
conjunto de la organizacin, a una parte o servicio, a todos los empleados, a los
contratistas, etc.
Se puede incluir un organigrama de la organizacin.
8.1.2.3. Alcance del sistema
Descripcin de los servicios de venta y alquiler de vehculos terrestres tanto a
empresas como a particulares.
8.1.2.4. Infraestructura informtica
Inclusin de un diagrama de red de la organizacin que muestre de manera
esquemtica la infraestructura informtica con la que se cuenta.
8.1.2.5. Objetivos de la poltica de seguridad
Breve descripcin de qu se pretende conseguir con esta poltica:
Definir el SGSI.
Mejorar la confianza de los clientes y usuarios en las actividades.
Reducir el riesgo de posibles prdidas de informacin, reaccionar adecuada-
mente ante cualquier tipo de incidencia, etc.
8.1.2.6. Requisitos legales
Detalle de las leyes aplicables en relacin con la seguridad de la informacin corres-
pondiente.
8.1.2.7. Revisiones y auditoras
Establecimiento de la metodologa y periodicidad de la revisin de la poltica de
seguridad y de las auditoras de la misma.
8.1.2.8. Compromiso de la direccin
Descripcin clara y directa de cmo la direccin est detrs de la definicin y la
implementacin del SGSI.
8.1.3. Organizacin e infraestructura de seguridad
Este apartado recoge quin y cmo se va a hacer cargo de la seguridad en la
organizacin.
8.1.3.1. Responsabilidades
En esta seccin se describiran las responsabilidades de los distintos roles en materia
de seguridad de la informacin que existen en una organizacin.
8.1.3.1.1. Direccin
Breve definicin de las responsabilidades de la direccin:
Proporcionar recursos al SGSI.
Aprobar los riesgos residuales.
Realizar la revisin por la direccin.
Etc.
8.1.3.1.2. Responsable de seguridad
Breve definicin de sus responsabilidades:
Gestionar y mantener el sistema de seguridad de la informacin.
Proporcionar ayuda y soporte a los usuarios.
Proteger la informacin y los sistemas adecuadamente protegidos.
Etc.
8.1.3.1.3. Propietario de los activos
Definir si el activo est afectado por la Ley de Proteccin de Datos y apli-
carle en su caso los procedimientos correspondientes.
Definir quin, cmo y cundo se puede tener acceso a la informacin.
Clasificar la informacin y la funcin a desempear.
Asegurarse de que el activo cuenta con el mantenimiento adecuado.
Etc.
103 8. Caso prctico: modelo de SGSI
8.1.3.1.4. Responsable de sistemas
Administrar y gestionar las cuentas de los usuarios.
Asegurarse de que slo las personas autorizadas a tener acceso cuentan con l.
Asegurarse de que los sistemas tienen los niveles de disponibilidad requeridos
por la organizacin o incluir los aspectos de seguridad que se apliquen en los
requisitos para nuevos desarrollos.
8.1.3.1.5. Personal
Breve definicin de las responsabilidades del personal:
Cmo conocer y aplicar las directrices de la poltica de seguridad.
Notificar las incidencias de seguridad.
Etc.
8.1.3.2. Responsabilidades asociadas a los activos
Para gestionar correctamente los activos el responsable de seguridad debe crear y
mantener un inventario actualizado de los activos importantes, registrando quin es
el propietario del activo, su ubicacin fsica y el valor que tiene para la organizacin.
8.1.4. Clasificacin de la informacin
La informacin de la organizacin debe clasificarse segn su nivel de confidenciali-
dad o sensibilidad para tomar las medidas de seguridad adecuadas a este nivel de
criticidad: informacin confidencial, restringida, interna, pblica, etc.
8.1.5. Anlisis de riesgos de seguridad
Definicin de la necesidad de realizar el anlisis de riesgos y los beneficios que
comporta.
8.1.5.1. Anlisis de riesgos
Descripcin de las tareas a realizar para el anlisis de riesgos.
8.1.5.2. Gestin de riesgos
Descripcin de las tareas a realizar para la gestin de riesgos.
8.2. Documentacin del inventario de activos
En este apartado se describe la manera de documentar el listado y la valoracin de
los activos de informacin con los que cuenta la organizacin de acuerdo con los
requisitos de la norma.
8.2.1. Procesos de negocio
Un ejemplo podra ser:
8.2.2. Inventario de activos
Proceso de negocio Descripcin
Administracin
Gestin de pagos y cobros,
pago de impuestos, etc.
Alquiler y venta Servicios de alquiler y venta de vehculos
Comercial Captacin de clientes
Recursos Humanos Nminas, altas y bajas de personal
Nombre Descripcin Categora Ubicacin Propietario
Aplicaciones
comerciales
Office, NominaPlus,
FacturaPlus, etc.
Aplicaciones Servidor
Responsable
de informtica
Servidor
Servidor que contiene
los datos de la empresa
Hardware Sala del servidor
Responsable
de informtica
Puestos
de usuario
PC de los usuarios Hardware Oficinas
Responsable
de informtica
Clientes Datos de clientes Datos Servidor/Archivo Director General
Contabilidad Datos de contabilidad Datos Servidor Director financiero
Laboral Datos de personal Datos Servidor Director RRHH
Personal
Personal propio
de Cibercar
Personal Oficinas Director General
8.2.3. Relacin proceso de negocio-activos
Proceso
Activos
Administracin
Alquiler
y venta
Comercial
Recursos
humanos
Aplicaciones
comerciales
X X X X
Servidor X X X X
Puestos de usuario X X X X
Clientes X X X
Contabilidad X
Laboral X
Personal X X X X
8.2.4. Valoracin de activos
Se valorarn los activos segn una escala de puntuacin de 0 (no aplicable/sin valor)
a 4 (mucho valor). La valoracin total ser la suma aritmtica de los cuatro valores.
Activo Confidencialidad Integridad Disponibilidad Total
Aplicaciones
comerciales
1 2 4 7
Servidor 2 3 4 9
Puestos de usario 1 2 3 6
Clientes 4 4 4 12
Contabilidad 2 4 3 9
Laboral 4 4 3 11
Personal 1 2 3 6
8.3. Documentacin del Anlisis de riesgos
El nivel de riesgo vendr dado por el valor ms alto para cada activo de:
Nivel de amenaza Nivel de vulnerabilidad Nivel de impacto
Tanto el nivel de vulnerabilidad como el nivel (o probabilidad) de amenaza se valo-
ran de 0 a 3 (no aplicado, bajo, medio y alto).
8.3.1. Valoracin del riesgo por activos
Aplicaciones comerciales
Servidor
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 7 1 0 0
Robo 7 1 1 7
Error de
mantenimiento
7 1 3 21
Fallo de software 7 3 2 42
Fallo de
comunicaciones
7 2 1 14
Errores de usuario 7 2 2 28
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 9 1 3 27
Robo 9 2 3 54
Error de
mantenimiento
9 2 3 54
Fallo de
comunicaciones
9 1 1 9
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 9 1 3 27
Robo 9 2 3 54
Error de
mantenimiento
9 2 3 54
Fallo de
comunicaciones
9 1 0 0
Clientes
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 12 1 1 12
Robo 12 2 2 48
Error de
mantenimiento
12 1 2 12
Fallo de
comunicaciones
12 1 1 12
Contabilidad
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 9 1 1 9
Robo 9 2 2 36
Error de
mantenimiento
9 1 1 9
(contina)
Puestos de usuario
Laboral
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 11 1 1 11
Robo 11 2 2 44
Error de
mantenimiento
11 1 1 11
Fallo de
comunicaciones
11 1 2 22
Personal
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fuego 6 1 3 18
Robo 6 0 0 0
Error de
mantenimiento
6 0 0 0
Fallo de
comunicaciones
6 0 0 0
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Nivel
de riesgo
Fallo de
comunicaciones
9 1 2 18
8. Caso prctico: modelo de SGSI 109
8.3.2. Tratamiento del riesgo
El valor de riesgo aceptable en este caso se establecera en 50, por lo que se trataran
los que igualen o superen esta cifra y se asumiran los que estuvieran por debajo. De
todas formas, se aplicaran los controles mnimos establecidos por la norma.
8.4. Documentacin de la Gestin de riesgos
Con la aplicacin de controles se reduciran tanto el nivel de amenaza como el de
vulnerabilidad o posiblemente los dos. Consecuencia de todo ello sera la disminu-
cin del nivel de riesgo.
8.4.1. Valoracin del riesgo por activos
Aplicaciones comerciales
Activo Riesgo Tratamiento
Aplicaciones comerciales 42 Se asume el riesgo
Servidor 54 Se asume el riesgo
Puestos de usario 54 Se asume el riesgo
Clientes 108 Se asume el riesgo
Contabilidad 81 Se asume el riesgo
Laboral 99 Se asume el riesgo
Personal 44 Se asume el riesgo
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 7 1 0 0 0
Robo 7 1 1 7 7
Error de
mantenimiento
7 1 3 21 14
(contina)
Servidor
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fallo de software 7 2 2 42 28
Fallo de
comunicaciones
7 2 1 14 14
Errores de usuario 7 1 2 28 14
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 9 1 2 27 18
Robo 9 2 2 54 36
Error de
mantenimiento
9 2 2 54 36
Fallo de
comunicaciones
9 1 1 9 9
Puestos de usuario
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 9 1 2 27 18
Robo 9 2 2 54 36
Error de
mantenimiento
9 2 2 54 36
Fallo de
comunicaciones
9 1 0 0 0
Clientes
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 12 1 1 12 12
Robo 12 1 2 48 24
Error de
mantenimiento
12 1 1 12 12
Fallo de
comunicaciones
12 1 1 12 12
Contabilidad
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 9 1 1 9 9
Robo 9 1 1 36 9
Error de
mantenimiento
9 1 1 9 9
Fallo de
comunicaciones
9 1 2 18 18
Laboral
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 11 1 1 11 11
Robo 11 1 1 44 11
Error de
mantenimiento
11 1 1 11 11
Fallo de
comunicaciones
11 1 2 22 22
Personal
Amenaza
Impacto
(valor del activo)
Nivel de
amenaza
Vulnerabilidad
Riesgo
inicial
Riesgo
residual
Fuego 6 1 2 12 12
Robo 6 0 0 0 0
Error de
mantenimiento
6 0 0 0 0
Fallo de
comunicaciones
6 0 0 0 0
8.5. Documentacin de la Declaracin de
aplicabilidad
Segn lo exigido por la norma, se deben documentar los controles seleccionados,
su aplicacin, as como aquellos que no han sido seleccionados y los motivos por
los que han sido rechazados. Toda esta informacin es la que se recoge en la
declaracin de aplicabilidad.
8.5.1. Controles aplicados
A.6 Organizacin de la seguridad de la informacin
A.6.1
Organizacin
interna
6.1.1 Compromiso de la
Direccin con la seguridad
de la informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
6.1.2 Coordinacin de la
seguridad de la informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
6.1.3 Asignacin de
responsabilidades en seguri-
dad de la informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
6.1.4 Proceso de autorizacin
para las instalaciones
de procesamiento de la
Informacin
Aplicado
La autorizacin para la
compra e instalacin de
nuevos equipos o software
se gestiona mediante el
procedimiento de compras
6.1.5 Acuerdos de
confidencialidad
Aplicado
Se firman con empleados
y contratistas
6.1.6 Contacto con las
autoridades
No
aplicar
No se considera que este
control ayude a reducir
el riesgo de los activos
identificados
Seccin Objetivo Control Estado Justificacin
A.5 Poltica de seguridad
A.5.1
Poltica de
seguridad de la
informacin
5.1.1 Documento de poltica
de seguridad de la
informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
5.1.2 Revisin de la poltica
de seguridad de la
informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
(contina)
A.6.2 Terceras partes
6.2.1 Identificacin de
riesgos relacionados
con terceras partes
No
aplicar
Se considera que el coste
de implementacin de este
control supera al beneficio
que se obtendra
6.2.2 Gestin de la seguridad al
tratar con clientes
No
aplicar
identificados
6.2.3 Gestin de la seguridad
en contratos con terceras
partes
No
aplicar
que se obtendra
A.7 Gestin de activos
A.7.1
Responsabilidades
de los activos
7.1.1 Inventario de activos Aplicar
Exigido por
UNE/ISO-IEC 27001
7.1.2 Propiedad de los activos Aplicar
Exigido por
UNE/ISO-IEC 27001
A.7.2
Clasificacin de
la informacin
7.2.1 Guas de clasificacin Aplicar
Exigido por
UNE/ISO-IEC 27001
7.2.2 Etiquetado y tratamiento de
la informacin
Aplicar
Exigido por
UNE/ISO-IEC 27001
7.1.3 Utilizacin aceptable de
los activos
Aplicar
Se marcarn unas pautas
de utilizacin de los activos
(contina)
A.8 Seguridad de la gestin de los recursos humanos
A.8.1
Antes de la
contratacin
8.1.1 Roles y responsabilidades
No
aplicar
En el anlisis de riesgos
no se han detectado
amenazas en este sentido
8.1.2 Anlisis y seleccin Aplicado
Se controla la seleccin de
personal
8.1.3 Trminos y condiciones
de empleo
Aplicado
Se documentan en los
contratos
A.6.1
Organizacin
interna
6.1.7 Contacto con grupos de
inters especial
Aplicado
Se mantienen contactos con
foros especializados, listas
de correo, revistas, etc.
6.1.8 Revisin independiente
de la seguridad de la
informacin
No
aplicar
que se obtendra
9.1.3 Asegurar las oficinas, salas
e instalaciones
Aplicado
Se han asegurado las
oficinas de acuerdo a la
legislacin vigente y
proporcionalmente al
tamao y actividad de
la organizacin
9.1.4 Proteccin contra amenazas
externas y ambientales
Aplicado
Se han asegurado las
oficinas de acuerdo a la
legislacin vigente y
proporcionalmente al
tamao y actividad de
la organizacin
A.9.1 reas seguras
9.1.1 Permetro de seguridad fsica Aplicado
Existen controles fsicos de
entrada proporcionales
al tamao y actividad
de la organizacin
9.1.2 Controles fsicos de entrada Aplicado
Existen controles fsicos de
entrada proporcionales
al tamao y actividad
de la organizacin
A.8.3
Finalizacin o
cambio de empleo
8.3.1 Responsabilidades
ante la finalizacin
No
aplicar
no se han detectado
Cuando el empleado cesa
devuelve todos los activos
que posea
8.3.2 Devolucin de activos Aplicado
no se han detectado
Para evitar los accesos a
la informacin de personal
que ya no pertenece a la
organizacin
8.2.3 Proceso disciplinario
8.3.3 Retirada de los derechos
de acceso
No
aplicar
Aplicado
A.8.2 Durante el empleo
8.2.1 Responsabilidades de los
gestores
No
aplicar
no se han detectado
Segn el anlisis de riesgos,
una amenaza habitual es
la falta de formacin en
materia de seguridad
8.2.2 Concienciacin, formacin
y entrenamiento sobre la
seguridad de la informacin
Aplicar
(contina)
A.9 Seguridad fsica y del entorno
A.10.1
Procedimientos
operativos y
responsabilidades
10.1.4 Separacin de las
instalaciones de desarrollo,
prueba y operacin
No
aplicar
control ayude a reducir los
riesgos detectados
A.10 Gestin de las comunicaciones y las operaciones
10.1.1 Procedimientos operativos
documentados
Aplicar
Exigido por
UNE/ISO-IEC 27001
10.1.2 Gestin de cambios Aplicar
Los cambios se realizarn
de manera controlada
10.1.3 Separacin de tareas Aplicado
En circunstancias
aconsejables, los equipos
se encuentran aislados
del resto
A.9.2
Seguridad de
los equipos
9.2.1 Emplazamiento y proteccin
de los equipos
Aplicado
Los equipos estn en reas
controladas por personal
autorizado o en salas
cerradas con llave
9.2.2 Servicios de soporte Aplicado
Los servidores cuentan
con SAI
9.2.3 Seguridad del cableado Aplicado
La instalacin del
cableado es segura
9.2.4 Mantenimiento de los
equipos
Aplicado
Existe un mantenimiento
interno de los equipos
9.2.5 Seguridad de los equipos
fuera de las instalaciones
Aplicado
Cuentan con ID y
contrasea para acceder
a ellos
9.2.6 Descarte o re-utilizacin
seguros de los equipos
Aplicado
Los equipos descartados
se formatean e instalan de
nuevo cuando se ponen
de nuevo en servicio
9.2.7 Extraccin de elementos de
la propiedad
Aplicado
Existe un procedimiento
de autorizacin aunque
no est documentado
A.9.1 reas seguras
9.1.5 Trabajo en reas seguras
No
aplicar
No existen reas
consideradas seguras
9.1.6 reas de acceso pblico, de
carga y de distribucin
Aplicado
Se establece una zona
en recepcin para carga
y descarga
(contina)
10.6.2 Servicios de seguridad
de redes
No
aplicar
de implementacin de
este control superara al
beneficio que se obtendra
A.10.7
Gestin
de soportes
10.7.1 Gestin de soportes
removibles
Aplicar
Necesario para evitar
riesgos de prdida de
informacin. Exigido
por la LOPD para datos
de carcter personal
A.10.5
Copias de
seguridad
A.10.6
Gestin de
la seguridad
de la red
10.5.1 Respaldo de la
informacin
Aplicado
Necesario para evitar
riesgos de prdida de
informacin
10.6.1 Controles de red Aplicado
Cada departamento
dispondra de una firma
digital para usarla en
caso de transmisin de
informacin sensible
A.10.4
Proteccin frente a
cdigo malicioso
y cdigo mvil
10.4.1 Controles contra cdigo
malicioso
Aplicado
Se dispone de sistemas
antivirus y anti spyware
10.4.2 Controles contra
cdigo mvil
No
aplicar
identificados
A.10.3
Planificacin
y aceptacin
del sistema
10.3.1 Gestin de la capacidad Aplicado
Se hara un estudio
peridico de las
necesidades presentes y
futuras de capacidad
del sistema informtico
10.3.2 Aceptacin del sistema Aplicado
Hasta ahora se hace de
una manera informal
A.10.2
Gestin de
los servicios
suministrados
por terceros
10.2.1 Suministro del servicio
No
aplicar
de implementacin de
(contina)
10.2.2 Revisin y monitorizacin
de servicios de terceras
partes
No
aplicar
de implementacin de
10.2.3 Gestin de cambios a los
servicios de terceras partes
No
aplicar
de implementacin de
A.10.10 Seguimiento
10.10.1 Registro de auditora Aplicado
Se controlaran los accesos
a algunas aplicaciones
10.10.2 Uso del sistema de
monitorizacin
Aplicar
Dado el resultado del
anlisis de riesgos,
se creera conveniente
aplicar este tipo de control
A.10.8
Intercambio
de informacin
10.8.1 Polticas y procedimientos
de intercambio de la
informacin
No
aplicar
de implementacin de
10.7.3 Procedimientos de
tratamiento de la
informacin
Aplicar
Dado el resultado del an-
lisis de riesgos, convendra
10.7.4 Seguridad de la
documentacin
del sistema
No
aplicar
No se considera que la
aplicacin de este control
ayudara a reducir los
riesgos detectados
A.10.7
Gestin
de soportes
10.8.2 Acuerdos de intercambio
No
aplicar
No se realizaran
intercambios
10.8.3 Soportes fsicos en trnsito
No
aplicar
No se extraeran soportes
con informacin relevante
fuera de las oficinas
10.8.4 Mensajera electrnica Aplicar
anlisis de riesgos, se
creera conveniente
10.8.5 Sistemas de informacin
de negocio
No
aplicar
control ayudara a reducir
identificados
A.10.9
Servicios de
comercio
electrnico
10.9.1 Comercio electrnico
No
aplicar
No se realizara comercio
electrnico
10.9.2 Transacciones en lnea
No
aplicar
No se realizaran
transacciones en lnea
10.9.3 Informacin pblica
disponible
Aplicar
anlisis de riesgos,
10.7.2 Descarte de medios
(de almacenamiento de
la informacin)
Aplicado
Existiran trituradoras
de papel
(contina)
A.11 Control de accesos
Requisitos del
negocio para
el de accesos
11.1.1 Poltica de de accesos Aplicado
Los usuarios contaran
con la informacin
pertinente respecto
a los permisos de
accesos que poseen
A.11.2
Gestin
de accesos de
los usuarios
11.2.1 Registro de usuarios Aplicar
El movimiento de
alta y baja de usuarios
en los sistemas hara
indispensable este
control
11.2.2 Gestin de privilegios Aplicar
Se asignaran permisos
a nivel del sistema
operativo
11.2.3 Gestin de contraseas
de usuarios
Aplicar
anlisis de riesgos,
11.2.4 Revisin de derechos de
usuario
Aplicado
Se hara bajo peticin del
responsable directo
del usuario
A.10.10 Seguimiento
10.10.3 Proteccin de la
informacin de log
Aplicar
Dado el resultado
del anlisis de riesgos,
aplicar este tipo de
control
10.10.4 Logs del operador y
del administrador
No
aplicar
El tamao de la
organizacin hara que
este control no fuera
necesario
10.10.5 Registro de fallos Aplicar
Dado el resultado
aplicar este tipo de
control
10.10.6 Sincronizacin horaria
No
aplicar
identificados
A.11.1
(contina)
11.3.1 Uso de contraseas Aplicar
Sera necesario para
proteger el acceso a
la informacin
A.11.3
Responsabilidades
del usuario
11.3.3 Poltica de mesas y
pantallas limpias
Aplicar
Se evitaran as
filtraciones de informacin
indeseadas
A.11.4
Control de
acceso a la red
11.4.1 Poltica de uso de
servicios de red
Aplicar
Dado el resultado
aplicar este tipo
de control
11.4.2 Autenticacin de usuarios
para conexiones externas
Aplicar
Dado el resultado
aplicar este tipo
de control
11.3.2 Equipamiento desatendido
por el usuario
Aplicar
Se considerara necesario
para evitar accesos
no autorizados
(contina)
11.4.3 Identificacin de equipos
en las redes
No
aplicar
identificados
11.4.4 Proteccin del puerto
remoto de configuracin
y diagnstico
Aplicado Se controlara este acceso
11.4.5 Segmentacin de rede
No
aplicar
identificados
11.4.6 Control de conexin
de red
No
aplicar
identificados
11.4.7 Control de
reencaminamiento
de redes
No
aplicar
identificados
11.6.2 Aislamiento de sistemas
sensibles
No
aplicar
identificados
A.11.7
Informtica mvil
y teletrabajo
11.7.1 Comunicaciones e
informtica mvil
No
aplicar
identificados
11.7.2 Teletrabajo
No
aplicar
de implementacin de
A.11.6
Control de acceso
a las aplicaciones
y la informacin
11.6.1 Restricciones de acceso
a la informacin
Aplicado
Slo se dara acceso
a la informacin que
necesitara el usuario
para realizar su trabajo
A.11.5
Control de acceso
a los sistemas
en operacin
11.5.1 Procedimientos seguros de
entrada a los sistemas
de informacin
Aplicado
Se controlara que el
acceso a los sistemas de
informacin no muestre
informacin y se limitara el
nmero de intentos fallidos
11.5.2 Identificacin y
autenticacin de usuarios
Aplicado
Cada usuario contara con
una ID y una contrasea
11.5.5 Finalizacin del tiempo
de sesin
No
aplicar
los riesgos detectados
11.5.6 Limitacin en el tiempo
de conexin
No
aplicar
los riesgos detectados
11.5.3 Sistemas de gestin
de contraseas
Aplicar
Cada usuario tendra su
contrasea. Este control
sera necesario para evitar
accesos que pudieran
suplantar la identidad
de algn usuario
11.5.4 Uso de utilidades
del sistema
Aplicar
Se restringira el uso de
estas utilidades.
8.6. Documentacin del Plan de tratamiento
del riesgo
Una vez establecidos los controles a implementar y el riesgo que se pretende
reducir con ellos, hay que definir las tareas que se van a llevar a cabo, los plazos y
los recursos asignados. Todo ello debe documentarse en este plan.
8.6.1. Objetivo
Descripcin de los objetivos del plan de tratamiento del riesgo.
8.6.2. Alcance
Definicin del periodo al que va afectar el plan de tratamiento del riesgo.
8.6.3. Responsabilidades
El responsable de seguridad se encargar de la ejecucin y supervisin de las distintas
actividades.
La direccin debera revisar y aprobar el plan y los objetivos marcados en el plan.
8.6.4. Tareas
Actividades
Implementacin del SGSI
Aprobacin de la poltica de seguridad
Aprobacin del inventario de activos
Aprobacin del anlisis de riesgos y los riesgos
residuales
Aprobacin del documento de aplicabilidad
Aprobacin del plan de tratamiento del riesgo
Aprobacin de procedimientos
Publicacin de documentos
Impartir formacin
Implementar procedimientos
Auditora interna
Revisin del SGSI
Auditora de certificacin
ID
1
2
3
4
M
e
s

1
M
e
s

2
M
e
s

3
M
e
s

4
M
e
s

5
M
e
s

6
M
e
s

7
M
e
s

8
M
e
s

9
M
e
s

1
0
M
e
s

1
1
M
e
s

1
2
8.6.5. Seguimiento
Verificacin del cumplimiento del plan en el plazo acordado por el responsable de
seguridad. En el caso de que produzcan desviaciones, se deberan tomar las medi-
das oportunas para corregirlas y, en caso necesario, se debera actualizar el plan para
reflejar los cambios.
8.6.6. Objetivos e indicadores
Indicador Mtrica Frmula Responsable
Frecuencia
de recogida
Fuente
Mejorar la
efectividad del
control de accesos
en un 5%
Porcentaje
de accesos
no autorizados
(Nmero de accesos
no autorizados /
Nmero total de
accesos) 100
Responsable
de sistemas
Trimestral
Registro
de accesos
Mejorar la
efectividad de
la formacin
en un 5%
Valoracin de
la formacin en
s del personal
Suma total de
valoraciones totales
de cada asistente /
Nmero de
asistencias
Responsable
de seguridad
Trimestral
Registros
de formacin
Porcentaje de
las incidencias
de seguridad
debidas a fallos
del usuario
(Nmero de
incidencias
de seguridad
debidas a fallos del
usuario / Nmero de
incidencias) 100
Responsable
de sistemas
Trimestral
Registros
de incidencias
Mejorar la
efectividad de los
mantenimientos
en un 5%
Porcentaje de
los equipos
correctamente
mantenidos
(Nmero de equipos
que pasaron su
mantenimiento en
fecha / Nmero de
equipos totales de la
empresa) 100
Responsable
de sistemas
Trimestral
Registro de
mantenimientos
Porcentaje
de incidencias
debidas a
fallos de
mantenimiento
(Nmero de
incidencias
de seguridad
debidas a fallos
del mantenimiento /
Nmero de
incidencias) 100
Responsable
de sistemas
Trimestral
Registro
de incidencias
(contina)
8.7. Documentacin del Procedimiento de
auditoras internas
8.7.1. Objetivo
El presente procedimiento debera dar cumplimiento a la Norma UNE-ISO/IEC
27001 en lo relativo a las actividades, criterios y responsabilidades para la realizacin
de auditoras internas del sistema de gestin de seguridad de la informacin.
8.7.2. Alcance
Este procedimiento se debera aplicar a todos los servicios incluidos dentro del
alcance del sistema de gestin de seguridad de la informacin.
El responsable de seguridad debe definir e implementar un sistema de auditoras
internas que incluya la preparacin, realizacin, registro y seguimiento de las mismas.
Para programar su frecuencia de realizacin ha de tenerse en cuenta que se debe
Indicador Mtrica Frmula Responsable
Frecuencia
de recogida
Fuente
Reducir un 5%
los ataques con
xito a los s
Porcentaje
de ataques
con xito
(Nmero de ataques
detectados /
Nmero de ataques
con impacto
en los s) 100
Responsable
de sistemas
Trimestral
Registro
de incidencias
Registros
del sistema
Porcentaje de
incidencias por
ataques a los s
(Nmero de
incidencias
de seguridad
debidas a ataques /
Nmero de
incidencias) 100
Responsable
de sistemas
Trimestral
Test de
intrusin
Monitorizacin
de los sistemas
Mejorar la
disponibilidad
el 5%
Porcentaje de
disponibilidad
(Nmero de horas
sin disponibilidad /
Nmero de horas
disponibilidad
necesaria) 100
Responsable
de sistemas
Trimestral
Registros
del sistema
auditar por completo el conjunto del SGSI cada tres aos. Lo ms recomendable
es hacer una anualmente.
El personal que realice la auditora no tendr en ningn caso responsabilidad
directa sobre el rea a auditar.
8.7.4. Desarrollo
La manera de llevar a cabo las tareas objeto de este procedimiento son detalladas a
continuacin.
8.7.4.1. Cualificacin del personal
El personal encargado de la ejecucin de las auditoras debera tener las siguientes
caractersticas:
Preparacin profesional necesaria en las metodologas que hay que emplear.
Conocimientos generales adecuados, tanto del ambiente empresarial como
del SGSI.
Carisma personal para transmitir credibilidad.
Estar convenientemente respaldado por la autoridad empresarial.
Debe ser elegido de manera que se garantice la independencia en relacin
con las actividades involucradas.
8.7.4.2. Planificacin de la auditora
Las auditoras pueden hacerse sobre la totalidad del SGSI implicando a toda la
organizacin, considerndose en estos casos como global. O bien, podra hacerse
sobre una parte en concreto, implicando a un determinado departamento, contrato,
sector, etc., considerndose entonces como parcial.
El responsable de seguridad debera realizar anualmente un plan de auditoras que
incluya las fechas y el auditor de cada auditora. Este plan ser aprobado por la
direccin y el responsable de seguridad lo distribuir a todos los departamentos y
auditores afectados.
Con independencia de lo anterior, se deberan realizar auditoras internas cuando:
La amplitud o profundidad de las modificaciones al SGSI as lo aconsejen.
Parcialmente, cuando se implementen procedimientos nuevos o se detecten
no conformidades en las reas afectadas.
8.7.4.3. Preparacin de la auditora
Las auditoras se llevan a cabo mediante una lista de comprobacin que, en cada
caso, debe ser elaborada por el auditor bajo la supervisin del responsable de
seguridad y que ser enviada al departamento afectado.
El auditor debe establecer el alcance de la auditora, las actividades a auditar, los
documentos aplicables y la lista de comprobacin. Basndose en esta informacin,
confeccionar la lista de comprobacin que debera ser revisada por el responsable
de seguridad y enviada, con suficiente antelacin, al departamento que va a ser
auditado. Adems, en el caso de modificarse la inicialmente programada, en dicha
lista se incluira la nueva fecha prevista de realizacin de la auditora y que estara
acordada entre los auditores y el rea a auditar.
8.7.4.4. Realizacin de la auditora
El primer paso en la auditora debera ser una reunin donde se confirme el alcance
de la misma, su secuencia y donde se discuta aquellos puntos que cualquiera de las
partes crea conveniente.
A continuacin, se procedera a llevar a cabo la auditora en s mediante el uso de
la lista de comprobacin, anteriormente realizada, como gua de trabajo. Se exami-
nara simultneamente la evidencia objetiva para comprobar que se cumplen los
requisitos y los controles aplicables.
En caso de que la auditora se realizara como consecuencia de la existencia de no
conformidades, se profundizara a fin de identificar las causas y efectos y poder
definir la accin correctiva/preventiva requerida.
Terminada la auditora, el equipo auditor redactara un informe de resultados, iden-
tificando de manera clara y concreta las no conformidades detectadas. Cuando haya
no conformidades importantes, se debera programar la fecha de la siguiente audi-
tora para verificar su eliminacin.
El responsable del departamento afectado por la no conformidad detectada o en su
caso el comit de seguridad, elaborar la accin correctiva/preventiva a llevar a
cabo, que ser aprobada por el responsable de seguridad. El responsable del rea
afectada por la accin correctiva/preventiva deber tomar las medidas necesarias
para aplicar totalmente las acciones correctivas y preventivas dentro del plazo sea-
lado en el informe.
Los informes de auditora sern archivados por el responsable de seguridad y se
enviarn copias a direccin y al responsable del rea auditada.
El cierre de la accin correctiva/preventiva se realizar una vez que, tanto el respon-
sable del rea afectada como los auditores internos, hayan comprobado su efectivi-
dad. En el apartado correspondiente del impreso de la accin correctora, se dejar
constancia de dichas comprobaciones con lo que se considerar la accin
correctiva/preventiva cerrada.
8.7.5. Requisitos de documentacin
Los documentos asociados a este procedimiento son:
Plan de auditoras.
Lista de comprobacin.
Informes de auditora.
8.7.6. Referencias
Los documentos de referencia para la realizacin de este procedimiento son:
Norma UNE-ISO/IEC 27001.
Norma UNE-ISO/IEC 17799.
Procedimientos de seguridad.
Objetivos de seguridad.
Resultados de otras auditoras: anteriores auditoras internas y externas del
SGSI, auditoras de la LOPD, tests de intrusin, etc.
Revisin del sistema de gestin.
8.7.7. Anexos
Lista de comprobacin de auditora (vase la figura 8.1).
Informe de auditora (vase la figura 8.2).
Plan de auditoras internas (vase la figura 8.3).
Departamento
Observaciones
Auditora de calidad N.
o
Fecha
Cuestiones a aplicar:
Verificacin del cumplimiento de las no conformidades detectadas en anteriores auditoras.
Revisin de documentacin existente en el puesto.
Cumplimiento del procedimiento (el que aplique al departamento).
Verificacin de registros.
Cambios en la estructura y funcionamiento del departamento.
Auditor Jefe Dpto. afectado
Fecha Fecha
Figura 8.1. Lista de comprobacin de auditora
Elaborado por
Revisa y aprueba
Requisito
de la norma
Comentarios
Hallazgos
No
conformidad
Observacin
Nmero auditora
rea/Proceso clave auditado
Fecha auditora
Figura 8.2. Informe de auditora
Auditor
Grupo auditor
Hallazgos detectados:
Nombre
Fecha
Firma
Nombre
Fecha
Firma
N.
o
Departamento/Seccin Fecha prevista Auditores
8.8. Documentacin del Procedimiento para las
copias de seguridad
8.8.1. Objetivo
El presente procedimiento general debera dar cumplimiento al control 10.5.1 de
la Norma UNE-ISO/IEC 17799 para asegurar la informacin de respaldo. Debera
definir la sistemtica establecida para crear copias de seguridad de manera ptima y
que no sean obviadas por algn usuario del sistema.
Figura 8.3. Plan de auditora interna
Responsable Actividades
Administrador
del sistema
Se deberan definir:
Todos los mecanismos necesarios para la correcta realizacin
de las copias de respaldo y recuperacin.
La realizacin de dichas copias segn la normativa que ellos
mismos hayan definido.
8.8.2. Alcance
Debera estar dirigida a todos los equipos de proceso de informacin que realizan
copias de seguridad de la informacin principal.
8.8.4. Trminos y definiciones
Equipos de proceso: cualquier equipo electrnico utilizado para procesar de
forma automtica la informacin.
8.8.5. Procedimiento
Para asegurar que las copias de respaldo y recuperacin son realizadas correcta-
mente segn la normativa vigente y las definiciones establecidas por el adminis-
trador, se deberan establecer las siguientes medidas:
8.8.5.1. Realizacin de las copias de seguridad en servidores
La informacin que debera requerir copia de seguridad es:
Documentacin.
Informacin del sistema.
Pginas web.
Bases de datos.
Correos electrnicos.
Las copias de seguridad se deberan realizar peridicamente volcando la informa-
cin desde el servidor a un DVD que se debera almacenar de manera adecuada, en
un sitio protegido y controlado por el responsable correspondiente.
En el caso de que la informacin a guardar tuviera datos extremadamente confi-
denciales, sta debera ser almacenada en una segunda ubicacin diferente a la del
fichero principal haciendo para ello distintas copias y guardndolas en distintos
sitios bajo tutela del responsable correspondiente.
Si se produjeran fallos en la realizacin de la copia de respaldo, se deber proceder a
realizarla de nuevo, bien de manera manual o bien automtica con un nuevo soporte.
8.8.5.2. Rotacin de los soportes de copias de seguridad y
recuperacin en servidores
No se conveniente reutilizar los soportes de informacin. Cada semana se debera
utilizar un DVD diferente convenientemente identificado (contenido guardado en
l y fecha de realizacin).
Igualmente, se debera desechar y sustituir el soporte cuando se hayan encontrado
errores en la grabacin del mismo. Todas estas altas y bajas de soportes debern
quedar registradas de acuerdo a la sistemtica definida en el Procedimiento de
gestin de soportes.
8.8.5.3. Recuperacin de datos de servidores
La recuperacin de datos de los servidores, as como del resto de equipamiento
informtico, deber ser llevada a cabo nicamente por los administradores del sis-
tema utilizando la copia de respaldo disponible ms reciente o aqulla que sea ms
adecuada a cada situacin.
En el caso de que existan aplicaciones que lo permitan, puede utilizarse la opcin
de la propia aplicacin para restaurar los datos. De otra manera, su recuperacin
consistir en la reposicin de los ficheros guardados en la copia de respaldo, copin-
dolos sobre la ubicacin de los ficheros originales. En caso de ser necesario, se
grabarn los datos no incluidos en la copia de seguridad manualmente.
En caso de utilizar personal tcnico externo no habitual para estas tareas, ste
deber estar acompaado en todo momento del responsable de seguridad o del
personal correspondiente.
La recuperacin de datos deber registrarse como incidencia y quedar registrada de
acuerdo a la sistemtica definida en el Procedimiento de gestin de incidencias.
8.8.5.4. Realizacin de copias de seguridad en los PC
La realizacin de las copias de respaldo de aquellos datos ubicados en los PC de
usuario consistir en una copia extrada a un soporte externo cada vez que las modi-
ficaciones de la informacin sean relevantes.
De la misma manera que se ha detallado en el apartado 5.2, todas las altas y bajas
de soportes deberan quedar registradas de acuerdo a la sistemtica definida en el
Procedimiento de gestin de soportes.
8.8.5.5. Recuperacin de datos de los PC
La recuperacin de datos consistir en la reposicin de los ficheros guardados en la
copia de respaldo, copindolos sobre la ubicacin de los ficheros originales.
8.8.6. Requisitos de documentacin
Inventario de equipos de proceso.
Registro de simulaciones de recuperacin de informacin.
Inventario de soportes.
Registro de incidencias.
8.8.7. Referencias
UNE-ISO/IEC 17799.
Manuales de funcionamiento y uso de los equipos electrnicos.
Ley Orgnica de Proteccin de Datos.
8.8.8. Anexos
Registro de copias de seguridad (vase la figura 8.4).
Soporte
Tipo de soporte y nmero
Contenido
Servidor o equipo
Informacin almacenada
Autorizacin
Persona responsable
de la copia
Persona que autoriza
Observaciones
Firmas
Almacenamiento
Medio
Responsable
Lugar
Figura 8.4. Registro de copias de seguridad
Registro de copias de seguridad
Fecha de copia: ___ /___ /______ Hora: ___ : ___
9
Comprender el
Esquema Nacional
de Seguridad (ENS)
9.1. Generalidades del ENS
El ENS establece la poltica de seguridad en el mbito de la administracin electr-
nica. Para ello, se han definido unos principios bsicos y unos requisitos mnimos
que se consideran imprescindibles para proteger adecuadamente unos servicios tan
crticos y sensibles como los que nos ocupan.
El alcance del ENS son los sistemas de informacin, los datos, las comunicaciones,
y los servicios electrnicos de cualquier Administracin Pblica (estatal, auton-
mica o local), as como de las entidades dependientes de ellas que se utilicen para la
prestacin de servicios electrnicos.
El Real Decreto 3/2010 pretende con su aplicacin asegurar el acceso, la integri-
dad, la disponibilidad, la autenticidad, la confidencialidad, la trazabilidad y la con-
servacin de los datos, las informaciones y los servicios utilizados en medios elec-
trnicos que se gestionan en las Administraciones Pblicas.
Lgicamente, el ENS no se ha desarrollado sin consultar la normativa y legislacin
que existen en el sector TIC a nivel internacional, por lo que muchos de los con-
ceptos que se manejan tienen similitudes y paralelismos con los que se han visto
anteriormente en esta publicacin. Sin embargo, ha de tenerse en cuenta que las
normas son documentos voluntarios que las organizaciones adoptan con distintos
fines (mejorar su gestin, distinguirse en el mercado, etc.). En cambio, el ENS es
una obligacin legal en el mbito de la administracin electrnica y no es opcional
para los organismos pblicos que prestan estos servicios.
Como ejemplo de los paralelismos entre la Norma UNE-ISO/IEC 27001 y el ENS
se muestra la correspondencia que existe entre algunos de los requisitos de ambas
en la tabla 9.1.
ENS UNE-ISO/IEC 27001 Requisito
11
12
13.1
13.2
13.3
27.1
14 - 15
34.1
26
Compromiso de la direccin
Gestin de riesgos
Formacin
Auditoras
Mejora continua
4.2.1.b)
5.1.c) d)
4.2.1.c) d) e)
4.2.1.f) g)
4.2.1.g)
5.2.2
4.2.3.e) - 6
8.1
Tabla 9.1. Correspondencias entre el ENS y la Norma UNE-ISO/IEC 27001
9.2. Principios bsicos del ENS
El ENS seala unos principios bsicos y unos requisitos mnimos que conducen a
la exigencia de la gestin continuada de la seguridad, para la que cabe aplicar un
sistema de gestin. Para satisfacerlos se puede aplicar un modelo de tipo PCDA
como el expuesto en la Norma UNE-ISO/IEC 27001. Los principios bsicos esta-
blecidos en el ENS son los siguientes:
Seguridad integral. Sin exigir expresamente que se desarrolle un sistema de
gestin, el ENS al reclamar que la seguridad sea un esfuerzo integral, impide
que se pretenda gestionar la misma mediante un plan formado por varias
medidas puntuales sin una visin global de los problemas de seguridad y su
importancia dentro de la organizacin. Con esto se evitan agujeros de segu-
ridad y utilizar recursos en aspectos que tal vez no lo necesiten.
Gestin de riesgos. Es un aspecto que recoge cualquier mtodo o modelo de
gestin de seguridad de la informacin, ya que slo sabiendo los riesgos a
los que se est expuesto se pueden tomar decisiones informadas. Como los
9. Comprender el Esquema Nacional de Seguridad (ENS) 139
sistemas de informacin y su entorno estn en constante cambio, es necesa-
rio mantener la evaluacin de los riesgos actualizada.
Prevencin, reaccin y recuperacin. Establecer medidas de seguridad de dis-
tinto tipo es fundamental para conseguir el objetivo de seguridad integral.
Evidentemente, el primer paso para evitar problemas de seguridad es contar
con medidas preventivas (como por ejemplo, la instalacin de un antivirus
como medida de prevencin contra infecciones o el uso de sistemas de
autenticacin para evitar accesos no autorizados). Sin embargo, a pesar del
cuidado que se ponga, los incidentes pueden suceder, por lo que es necesario
contar con medidas que permitan reaccionar adecuadamente y minimizar los
daos (por ejemplo, el uso de un sistema de monitorizacin de la red aler-
tar a los administradores si se produce un acceso no autorizado, y permitir
tomar acciones para limitar el dao o incluso evitarlo). Asimismo, deben
existir medios para recuperarse de los daos ocasionados por un incidente.
Si, por ejemplo, la intrusin ha ocasionado la eliminacin de un documento,
se debera contar con una copia de seguridad que permita recuperar los
datos.
Lneas de defensa. El conjunto de medidas de seguridad elegidas tienen que
estar implementadas de modo que los sistemas de informacin cuenten con
distintos niveles de proteccin, de manera que un incidente vaya encon-
trando dificultades que le impidan hacer todo el dao del que seran capaces
(por ejemplo, para impedir accesos no autorizados a un servidor, se tendr
un recinto en el que se ubique y donde el acceso al mismo est controlado
con un registro de entradas y salidas, un mecanismo de autenticacin del
acceso, tiempos limitados de conexin, un protocolo de actuacin para
cerrar aquellos puertos que sean necesarios o cerrar segmentos de red, etc.).
Este enfoque est alineado con el objetivo de contar con una gestin de la
seguridad integral, y con tener distintos tipos de medidas de seguridad.
Reevaluacin peridica. Para mantener constante un nivel de seguridad
aceptable es necesario revisar continuamente que el nivel de riesgo no ha
variado y que las medidas de seguridad aplicadas funcionan segn lo espe-
rado. Hay que realizar una revisin peridica de estos aspectos para ir
haciendo los ajustes necesarios y contar en todo momento con las medidas
de seguridad adecuadas y proporcionales a los sistemas de informacin y a
su entorno.
Funcin diferenciada. La gestin de la seguridad de la informacin es una
tarea en la que estn involucradas muchas personas que, dependiendo de su
perfil y funciones, tienen distintas prioridades. Para no comprometer la segu-
ridad, el ENS ha definido como principio bsico que los responsables de la
informacin, del servicio y de la seguridad sean personas distintas. De esta
manera, cada responsable debe definir los requisitos que aplican a su infor-
macin y a su servicio, y el responsable de seguridad se encargar de aplicar
las acciones oportunas para satisfacer de la mejor manera posible todos esos
requisitos con los medios y las polticas disponibles.
9.3. Requisitos mnimos de seguridad del ENS
El ENS requiere que las organizaciones cuenten con una poltica formalmente
aprobada y se establezcan las directrices a seguir para gestionar la seguridad en la
organizacin. Dicha poltica tiene que reunir una serie de requisitos mnimos que
se detallan a continuacin.
9.3.1. Organizacin e implementacin del proceso
de seguridad
La gestin de la seguridad requiere que haya ciertas responsabilidades asignadas
que son fundamentales para que se desarrollen los trabajos correctamente, tales
como el responsable de seguridad, el responsable de la informacin y el de los
servicios o el comit de seguridad. Pero la responsabilidad de la seguridad de la
informacin es universal, cada persona debera ser responsable de la informacin
y de los servicios a los que tiene acceso.
La poltica debe contemplar todas estas responsabilidades y las lneas de actuacin
que se deben observar. Adems, debe ser publicada y difundida de manera que
todo el mundo la conozca y se pueda aplicar.
9.3.2. Anlisis y gestin de los riesgos
La poltica recoger el modo en el que se va a realizar el anlisis y la gestin de los
riesgos que afectan a los sistemas de informacin de la organizacin. Para el anli-
sis se puede usar cualquier metodologa internacionalmente aceptada.
En la prctica, la amplia difusin de la metodologa MAGERIT y de PILAR, su
herramienta asociada, hacen que sean las ms comnmente utilizadas en la Admi-
nistracin Pblica espaola. Para la gestin de los riesgos se aplicarn medidas de
seguridad que sean proporcionales a los riesgos que se pretenden mitigar, debiendo
compensar en coste y esfuerzo su implementacin.
9.3.3. Gestin de personal
El personal es una parte fundamental de los sistemas de informacin. Cada uno de
ellos tiene responsabilidades en materia de seguridad, acorde con el puesto desem-
peado. La comunicacin de estas responsabilidades, y una adecuada formacin y
concienciacin en materia de seguridad permitirn una correcta gestin de la
misma.
Adems, tendrn que existir normas de seguridad y mecanismos para verificar que
se cumplen los preceptos marcados. Los usuarios estarn identificados en los siste-
mas de manera nica para poder supervisar sus acciones y, si se diera el caso, poder
exigirles responsabilidades.
9.3.4. Profesionalidad
Las tareas que implica la gestin de la seguridad sern realizadas por personal cua-
lificado para ello, que debern contemplar en ellas todo el ciclo de vida de los siste-
mas, desde su compra e instalacin inicial hasta su retirada, pasando por su mante-
nimiento. Para ello, es importante que se reciba la formacin necesaria que permita
realizar su labor de manera segura.
Cuando se contraten servicios de seguridad externos, se deber acreditar que dichos
servicios tienen el nivel de seguridad requerido por los sistemas de la entidad.
9.3.5. Autorizacin y control de los accesos
Uno de los primeros asuntos a tratar cuando se trata de seguridad es la definicin
de la poltica que se va a seguir para autorizar accesos, es decir, qu se va permitir a
cada usuario y cules van a ser los criterios para la designacin de los permisos. La
recomendacin es autorizar el acceso a los servicios y a la informacin en funcin
de la necesidad de cada puesto. Adems, se deber tener un mecanismo que per-
mita revisar y anular los privilegios de acceso para evitar incidentes.
9.3.6. Proteccin de las instalaciones
La seguridad fsica es el primer paso para garantizar la proteccin de los servicios y
la informacin que se gestionan. Para ello, los sistemas que albergan informacin
deben estar fsicamente en otras instalaciones, protegidos contra accesos no autori-
zados y con medidas contra incendios, inundaciones, etc.
9.3.7. Adquisicin de nuevos productos de seguridad
Cuando se valoren nuevos productos de seguridad para su adquisicin, se debera
tener en mayor consideracin aquellos que tengan certificada (ISO/IEC 15408, etc.)
la funcionalidad de seguridad.
9.3.8. Seguridad por defecto
Para limitar los riesgos y evitar problemas de seguridad, se requiere que los siste-
mas sean diseados y configurados de manera que su uso sea seguro. Esto implica
actuaciones en distintos aspectos:
Que slo tengan la funcionalidad necesaria para el uso que se pretende dar al
sistema.
Que las funciones de operacin, administracin y registro de actividad sean
las mnimas necesarias.
Que estas funciones slo puedan ser realizadas por el personal autorizado
y, para reforzar el control, se pueda restringir el periodo y los lugares de
acceso.
Que se configure el sistema para que no estn disponibles ni accesibles fun-
ciones que no sean estrictamente necesarias.
Que el uso del sistema sea sencillo y seguro, de manera que un evento de
seguridad tenga que ser producido deliberadamente por el usuario.
9.3.9. Integridad y actualizacin del sistema
Para garantizar en todo momento la integridad del sistema, no se podr instalar
ningn elemento fsico ni lgico sin tener una autorizacin formal previa para ello.
La actualizacin del sistema se llevar a cabo manteniendo un control permanente
sobre las indicaciones de los fabricantes, las vulnerabilidades y las actualizaciones
que les afecten. El identificar nuevas vulnerabilidades, evaluar su aplicacin o no a
los sistemas y ejecutar los cambios que se aprueben har que se mantenga el nivel
de seguridad del sistema.
9.3.10. Proteccin de la informacin almacenada y
en trnsito
Es muy habitual que las medidas de proteccin de las que goza la informacin al
inicio de su ciclo de vida, al generarse y gestionarse, se diluyan o desaparezcan
cuando se transmite o almacena. Es fundamental protegerla durante todo su ciclo
de vida, por ello se deben disear medidas de seguridad que tengan en cuenta que
muchas veces la informacin se encuentra en entornos inseguros: equipos portti-
les, asistentes personales (PDA), dispositivos perifricos, soportes de informacin
y comunicaciones sobre redes abiertas o con cifrado dbil.
Los procedimientos para la recuperacin y conservacin a largo plazo de los docu-
mentos electrnicos producidos por las Administraciones Pblicas en el mbito de
sus competencias se encuentran sujetos a este requisito.
En este aspecto es donde se ampla de alguna manera el alcance del ENS. Hemos
visto que sus requisitos aplican nicamente a los servicios de administracin elec-
trnica, pero an existe mucha informacin en soporte no electrnico, que se ha
originado o es el origen de informacin electrnica, y por lo tanto, deber estar
protegida como si lo fuera, con la salvedad de que las medidas que se apliquen sean
coherentes con el soporte donde se encuentra.
9.3.11. Prevencin ante otros sistemas de informacin
interconectados
De igual manera que se protege el permetro fsico de un sistema, debe protegerse
el lgico. Como es intrnseco a la administracin electrnica el tener los sistemas
internos de la entidad conectados con internet y con otras entidades, este perme-
tro lgico conlleva unos riesgos que deben ser analizados y evaluados, de manera
que se puedan mitigar de manera coherente y proporcional.
9.3.12. Registro de actividad
Para gestionar la seguridad es imprescindible tener identificados a los usuarios y
sus respectivos privilegios en los sistemas de informacin, ya que es una de las
herramientas principales para impedir accesos no autorizados. Debe complemen-
tarse con el registro de las actividades de los usuarios, de manera que se puedan
identificar accesos fraudulentos o no autorizados y tomar las medidas de correc-
cin que sean necesarias, as como proceder a la sancin del infractor si fuera
necesario. Lgicamente, debe tenerse cuidado a la hora de recopilar estos datos
para no entrar en conflicto con lo estipulado en la Ley Orgnica de Proteccin de
Datos de carcter personal y sus desarrollos, o invadir la privacidad de los usuarios.
9.3.13. Incidentes de seguridad
La gestin de los incidentes de seguridad es uno de los pilares de cualquier sistema
de gestin de la seguridad. Es inevitable que sucedan incidentes a pesar de las
medidas establecidas, por lo que se necesita contar con un mecanismo que permita,
tanto reaccionar rpidamente para minimizar los daos como luego analizar y
extraer conclusiones, que permitan incorporar mejoras al sistema de gestin, a los
de informacin, o a todos, para evitar otros incidentes similares.
Como es de rigor en un entorno tan conectado como el que nos ocupa, el ENS
requiere que se cuente con un sistema de deteccin y reaccin frente al cdigo
daino.
9.3.14. Continuidad de la actividad
El riesgo de que algn incidente grave inutilice o no permita acceder a los
medios habituales de trabajo, por su grave impacto en los servicios que se pres-
tan, requiere de un plan de continuidad que de alguna manera permita seguir
operando. Como mnimo, se dispondr de copias de seguridad y una serie de
protocolos de actuacin.
9.3.15. Mejora continua del proceso de seguridad
La seguridad es un proceso. Para mantener un cierto nivel de seguridad, hay que
estar continuamente revisando, actualizando y mejorando el sistema, o de lo con-
trario, los cambios en el contexto (el personal, la tecnologa, nuevas vulnerabili-
dades, etc.) harn que el nivel descienda.
9.3.16. Soporte al cumplimiento
Para cumplir con todos estos requisitos mnimos hay que aplicar las medidas de
seguridad que se detallan en el anexo II del Real Decreto 3/2010 considerando que:
Deben aplicarse a los activos que constituyen el sistema.
Deben escogerse segn la categora del sistema.
Pueden aplicarse otras medidas que se estimen oportunas segn los servicios
y la informacin gestionados y los riesgos identificados mediante el anlisis
de riesgos.
Que no puede haber conflicto con los requisitos de la LOPD.
Si se considera que algn sistema de informacin no est relacionado con el mbito
de aplicacin del ENS, la entidad podr excluirlo del sistema de gestin de la
seguridad.
Para facilitar el cumplimiento del ENS, existen infraestructuras y servicios comu-
nes reconocidos en las Administraciones Pblicas. Asimismo, como herramientas
de consulta, el Centro Criptolgico Nacional (CCN) ha elaborado y difundido
guas de seguridad.
9.4. Otros requisitos
9.4.1. Comunicaciones electrnicas
Evidentemente, las comunicaciones son un aspecto crtico a tener en cuenta en el
momento de disear la seguridad de un sistema de informacin por su sensibili-
dad. El ENS demanda que se controlen las comunicaciones, de manera que las
transmisiones se lleven a cabo sin incidencias, que su contenido llegue ntegro y
que se pueda identificar al remitente y al destinatario de las mismas de manera
inequvoca.
No hay que olvidar que las comunicaciones tienen un valor y eficacia jurdicos
que no se deben perder en ningn momento. Este es el caso de las notificaciones
y publicaciones electrnicas, ya que el ENS exige que se asegure la autenticidad
del organismo que las publica, la integridad de la informacin publicada, que
conste la fecha y hora de la puesta a disposicin del interesado de la resolucin o
el acto objeto de publicacin o notificacin, as como del acceso a su contenido,
adems de que se asegure la autenticidad del destinatario de la publicacin o
notificacin.
Una de las herramientas que se utilizar para garantizar la seguridad de las comu-
nicaciones ser la firma electrnica, que protege la autenticidad de quien emite una
comunicacin electrnica. Su utilizacin debe estar regulada mediante una poltica
y aplicada segn lo estipulado en el anexo II del ENS y el Esquema Nacional de
Interoperabilidad.
9.4.2. Auditora de la seguridad
Para garantizar la adecuacin en todo momento del sistema a los requisitos del
ENS, se estipular la realizacin de una auditora cada dos aos, como mnimo, o
antes si hay cambios importantes en el sistema de informacin, que puedan afectar
a las medidas de seguridad requeridas. Esta auditora deber servir tambin como
herramienta de mejora de la eficacia de las medidas de seguridad establecidas.
Debern emitirse informes que identifiquen las deficiencias y desviaciones del sis-
tema de seguridad respecto a lo establecido en el ENS, que sern presentados al
responsable del sistema para que valore los resultados y adopte las medidas de
correccin adecuadas.
9.4.3. Estado de seguridad de los sistemas
Regularmente, el Comit Sectorial de Administracin Electrnica elaborar un
informe en el que se recogern las principales variables de la seguridad en los siste-
mas de informacin a los que se refiere el ENS, de forma que permita elaborar un
perfil general del estado de la seguridad en las Administraciones Pblicas.
9.4.4. Respuesta a incidentes de seguridad
Para ayudar a dar respuesta a los incidentes de seguridad, el Centro Criptolgico
Nacional (CCN) pone a disposicin de las entidades el Centro Criptolgico Nacio-
nal-Computer Emergency Reaction Team (CCN-CERT). Se denomina CERT a un
grupo de trabajo responsable de desarrollar medidas de prevencin y de reaccin
ante incidentes de seguridad en los sistemas de informacin.
Este CCN-CERT prestar a las Administraciones Pblicas los siguientes servicios:
Soporte y coordinacin para la resolucin de incidentes de seguridad y tratar
vulnerabilidades.
Investigacin y divulgacin de las mejores prcticas sobre seguridad de la
informacin. En este contexto se han desarrollado las series de documentos
Centro Criptolgico Nacional-Seguridad de las Tecnologas de Informacin
y Comunicaciones (CCN-STIC), elaboradas por el Centro Criptolgico
Nacional y que se pueden consultar en su sitio web.
Formacin en el campo de la seguridad de las tecnologas de la informacin.
Informacin sobre vulnerabilidades, alertas y avisos de nuevas amenazas.
Un programa para informar, formar, emitir recomendaciones y proporcionar
herramientas para que cada entidad pueda desarrollar sus propias capacida-
des de respuesta a incidentes de seguridad, actuando el CCN como
coordinador nacional.
9.4.5. Normas de conformidad
El ENS demanda en este aspecto:
Que se garantice la seguridad de las redes y los registros electrnicos por ser
la primera toma contacto del ciudadano con la administracin electrnica.
Que la seguridad est presente en todo el ciclo de vida de los servicios y los
sistemas. Para ello, las especificaciones de seguridad deben formar parte de la
planificacin de un nuevo servicio o sistema.
Que exista un mecanismo de control que monitorice y verifique el correcto
seguimiento de las directrices de seguridad, de manera que se pueda garanti-
zar que funciona correctamente. Deben establecerse puntos y elementos de
control para realizar esta tarea.
Las entidades sujetas al ENS deben hacer pblicas, en las correspondientes
sedes electrnicas, las declaraciones de conformidad con el ENS y cualquier
otro distintivo de seguridad que posean como, por ejemplo, la certificacin
segn la Norma UNE-ISO/IEC 27001.
9.4.6. Actualizacin
Es un aspecto que ya se ha tratado anteriormente y en el que se insiste en este cap-
tulo. El sistema de seguridad debe estar permanentemente actualizado, mejorn-
dolo con el tiempo para responder a los cambios en los servicios de administracin
electrnica, la evolucin tecnolgica, y los nuevos estndares internacionales sobre
seguridad y auditora en los sistemas y tecnologas de la informacin.
9.4.7. Categorizacin de los sistemas
El ENS describe en su anexo I el modo de proceder para asignar una categora al
sistema o sistemas que se identifiquen en una entidad. Hay tres categoras, baja,
media y alta, a las que se adscribirn los sistemas en funcin de la gravedad del
impacto que tendra un incidente que afectara a la seguridad de la informacin o
de los servicios. Esta categora determinar las medidas que haya que aplicar al sis-
tema, y por lo tanto, el esfuerzo que habra que dedicar a la seguridad del mismo.
El responsable de cada informacin o servicio es quien debe realizar las valoracin
del impacto de un incidente en la disponibilidad, autenticidad, integridad, confi-
dencialidad o trazabilidad de ese activo, y mantenerlas actualizadas.
El responsable del sistema es quien debe asignar la categora al mismo.
9.4.8. Formacin
Ningn sistema de gestin puede funcionar si no se cuenta con el personal adecua-
damente formado y concienciado. En este caso, es particularmente esencial, ya que
las personas son un activo importante de los sistemas y una fuente de riesgos
importante. El ENS requiere que el personal reciba la formacin necesaria que
garantice su cumplimiento.
10
Implementacin del ENS
10.1. El plan de adecuacin
La implementacin del ENS puede dividirse en dos partes:
La elaboracin del plan de adecuacin.
La ejecucin de las acciones definidas en dicho plan.
El plan de adecuacin lo desarrollar el responsable de seguridad cuando lo haya o
la persona a la que se asigne esta funcin de forma temporal y debe contener la
siguiente informacin:
La poltica de seguridad. Cada entidad debe contar con una poltica de segu-
ridad que recoja sus objetivos, el marco legal, los roles y funciones de seguri-
dad, as como los comits de seguridad y las directrices para la gestin de la
documentacin, entre otros puntos. Si no posible elaborarla y aprobarla en
esos momentos, debe planificarse como una tarea a realizar en el plan de
mejora.
Informacin que se maneja, con su valoracin. Se identifica primero la infor-
macin que se utiliza para la prestacin de los servicios electrnicos y des-
pus se evala en un rango de tres categoras (baja, media y alta) cmo sera
el impacto de un incidente sobre esa informacin en cada uno de las cinco
dimensiones de seguridad: confidencialidad, integridad, disponibilidad,
autenticidad y trazabilidad. Los criterios generales de valoracin del impacto
en cada nivel son:
Bajos. Cuando las consecuencias de un incidente supongan un perjuicio
limitado sobre los activos o las funciones de la entidad.
Medios. Cuando las consecuencias de un incidente supongan un perjuicio
grave sobre los activos o las funciones de la entidad, de manera que no
puedan funcionar normalmente, se dae seriamente algn activo, se haya
incumplido alguna ley o se haya perjudicado a alguna persona.
Alto. Cuando las consecuencias de un incidente supongan un perjuicio
muy grave sobre los activos o las funciones de la entidad, de manera que
no pueda funcionar, se haya daado gravemente algn activo o incluso
haya sido destruido, se haya incumplido gravemente alguna ley o se haya
perjudicado irremediablemente a alguna persona.
Si esta valoracin la realiza el responsable de seguridad, se considerar provi-
sional y deber planificarse la valoracin por parte de los propietarios de la
informacin en el plan de mejora.
Servicios que se prestan, con su valoracin. Como en el caso de la informacin,
hay que identificar los servicios, valorando las cinco dimensiones del mismo
modo, en funcin de la gravedad del impacto de un incidente en la entidad.
Adems de los servicios actualmente prestados, hay que incluir los que van a
ser puestos en marcha, ya que el ENS exige que cualquier servicio que se
comience a prestar debe estar ya cumpliendo con los requisitos, as que deben
analizarse junto con el resto.
Datos de carcter personal. Ser bastante habitual por la naturaleza de los
servicios electrnicos, que se manejen datos de carcter personal. Se identifi-
carn o se har referencia al Documento de Seguridad de la LOPD.
Categora del sistema. Las valoraciones de la informacin y los servicios
son los datos de partida para decidir la categora del sistema o los sistemas
identificados. En cada dimensin sta vendr dada por el mayor de los
niveles que haya alcanzado en ella. Finalmente, ser el mayor de los niveles
alcanzado en cualquiera de las cinco dimensiones. Es decir, un sistema en
el que las cinco dimensiones estn valoradas de nivel bajo, ser de catego-
ra bsica. Si alguna de ellas es de nivel medio y ninguna es alto, ser de
categora media. Si alguna de ellas es de nivel alto, la categora del sistema
ser alta.
Para economizar recursos es preferible desglosar el sistema en tanto subsiste-
mas como sea razonable hacerlo, de manera que las medidas para el nivel
alto, que son ms exigentes que para el resto, se apliquen al menor nmero
de servicios e informacin posible. Como ejemplo, se puede tomar una sede
electrnica. Si la consideramos como un nico sistema, teniendo en cuenta
los requisitos planteados por la Ley 11/2007, la disponibilidad del registro
electrnico tendr que ser de 24 horas al da, los 365 das del ao, por lo
10. Implementacin del ENS 151
tanto, se podr valorar su dimensin de disponibilidad como de nivel alto, y
consecuentemente, la categora del sistema ser alta.
Sin embargo, si desglosamos la sede electrnica en varios subsistemas, por
ejemplo:
Pgina web.
Registro electrnico.
Notificaciones.
Servicio de validacin de documentos.
Tabln de anuncios.
Como solamente el registro electrnico tiene ese requisito de disponibilidad,
este subsistema ser de nivel alto, pero el resto pueden ser de niveles ms
bajos, con el consiguiente ahorro de esfuerzo y recursos.
Declaracin de aplicabilidad de las medidas del anexo II del ENS. Es un requi-
sito formal del ENS, consiste en un listado de las medidas de seguridad a apli-
car al sistema de acuerdo con la categora del mismo. En el anexo II del ENS
se recogen las 75 medidas de seguridad, con las dimensiones a las que aplican
y en qu medida lo hacen segn la categora del sistema. Por ejemplo, la
medida op.pl.1, Anlisis de riesgos, aplica al sistema, y si es de nivel bajo
habra que hacer un anlisis informal, si fuera de nivel medio uno semiformal
y si fuera de nivel alto uno formal. Otro ejemplo, la medida mp.if.9, Instala-
ciones alternativas, afecta a la disponibilidad y no aplicara a los sistemas de
niveles bajo y medio, pero s a los de nivel alto. Si hubiera medidas que habra
que aplicar debido al nivel del sistema, pero no se consideran aplicables, habra
que justificar por qu es as. Asimismo, si se usaran otras medidas diferentes de
las propuestas por el ENS, tambin habra que justificarlas e identificar a cu-
les sustituyen. Esta declaracin estar firmada por el responsable de seguridad.
Anlisis de riesgos. Realizarle tiene como objetivo completar las medidas de
seguridad a las que obliga el ENS con otras que se considere necesarias para
mitigar los riesgos identificados, adems de establecer un mapa de riesgos
potenciales y actuales que ponga de manifiesto el progreso en la eliminacin
de problemas. Los riesgos residuales, los que quedan tras la aplicacin de las
medidas de seguridad seleccionadas, deben ser formalmente aceptados por
los responsables de la informacin y servicios afectados, o en su defecto, lo
har el responsable de seguridad.
El ENS exige que la metodologa que se use para la realizacin del anlisis
de riesgos sea reconocida internacionalmente. La metodologa MAGERIT,
del Ministerio de Administraciones Pblicas, as como su herramienta aso-
ciada PILAR, cumplen este requisito dado que est recogida en el inventario
de la European Network and information Security Agency (ENISA). El alto
grado de implementacin de MAGERIT y PILAR en la Administracin
Pblica espaola, junto con el coste nulo que suponen, hacen que sean la
eleccin habitual a la hora de decidir la herramienta a utilizar.
Insuficiencias del sistema. Se realizar un anlisis de los requisitos que no se
estn cumpliendo, como punto de partida para la definicin del plan de
mejora. Estas insuficiencias pueden venir de desviaciones respecto a los dis-
tintos artculos del Real Decreto 3/2010, incumplimientos de las medidas de
seguridad, tal y como se definen en el anexo II, o incumplimientos de los
requisitos exigidos por el Real Decreto 1720/2007 para los datos de carcter
personal tratados por el sistema.
Plan de mejora seguridad, incluyendo plazos estimados de ejecucin. Se
determinarn las acciones a tomar para eliminar o subsanar las insuficiencias
detectadas y se planificar su ejecucin, indicando los plazos previstos de eje-
cucin, los hitos del proyecto y la estimacin de costes.
Una vez elaborado y aprobado el plan de adecuacin, la entidad puede publicar su
declaracin de conformidad en la sede electrnica, as como otros certificados de
accesibilidad, interoperabilidad, menciones de calidad de cualquiera de las Admi-
nistraciones Pblicas (estatal, autonmica y local), de organizaciones internaciona-
les o de organismos privados. Esta declaracin ha de ir firmada por el titular del
organismo emisor de la declaracin de conformidad, que ha de identificarse con su
nombre completo y cargo que desempea.
10.2. Adecuacin al ENS
La adecuacin al ENS pasa por la realizacin de una serie de tareas que coinciden a
grandes rasgos con las que se vieron previamente para la implementacin de un SGSI
segn la Norma UNE-ISO/IEC 27001: definir el alcance de la aplicacin del ENS,
la poltica de seguridad, asignar responsabilidades, realizar un anlisis de riesgos, etc.
Hay que sealar que, dado que cumplir con el ENS es una obligacin legal, no es
posible obviar ninguna de las acciones y documentos que exige.
10.2.1. Planificacin
La planificacin es la realizacin del plan de adecuacin.
Toda la informacin necesaria para poder comparar el estado de la seguridad en la
entidad con el estado que pide el ENS, se recopilar durante la realizacin del plan
de adecuacin, que a su vez contendr el plan de mejora con las acciones a tomar.
Este plan incluir:
El desarrollo y la aprobacin de una poltica de seguridad.
La asignacin y aprobacin de los responsables de seguridad, de la informa-
cin y de los servicios.
La definicin la normativa de seguridad. Sern documentos que detallen
cmo y quin realizar las distintas tareas y cmo se identificarn y resol-
vern los comportamientos anmalos, tales como procedimientos para la
gestin de incidencias, la monitorizacin del sistema o el plan de conti-
nuidad.
La definicin y la descripcin de los procesos de autorizacin, formalizando
las autorizaciones que cubran todos los elementos de los sistemas de infor-
macin: instalaciones, equipos, aplicaciones, medios de comunicacin, acce-
sos, soportes, etc.
La implementacin de medidas de seguridad.
La formacin al personal de la entidad sobre la poltica, normativa y proce-
dimientos de seguridad.
La evaluacin de la eficacia de las medidas adoptadas.
La definicin e implementacin de los procedimientos para la actualizacin
de la gestin de la seguridad.
La realizacin de una auditora de seguridad.
10.2.2. Implementacin
Partiendo del plan de mejora y de la declaracin de aplicabilidad, se desarrollar la
normativa de seguridad, es decir, aquellos procedimientos necesarios para imple-
mentar todos los requisitos que hacen falta para cumplir con los requisitos del ENS.
Estos procedimientos detallarn las distintas tareas, los responsables de su ejecu-
cin y supervisin, as como los mecanismos para identificar y resolver los compor-
tamientos anmalos.
Puede ser necesario desarrollar tambin instrucciones de trabajo y documentos
modelo que permitan registrar las operaciones descritas en los procedimientos, as
como controlar la resolucin de las incidencias.
Otras tareas que se realizarn en esta fase son:
La elaboracin y puesta en marcha de un plan de pruebas y monitorizacin
del sistema, para controlar la seguridad del mismo.
La definicin y ejecucin de un plan de auditoras, en las que se revisarn la
poltica de seguridad y su cumplimiento, as como el conjunto de riesgos,
normativas, procedimientos y controles establecidos.
La definicin y ejecucin de un plan de formacin y sensibilizacin. Se debe-
ra impartir formacin a todo el personal de la entidad, de modo que cada
uno conozca cules son sus responsabilidades y tareas para proteger la infor-
macin y los servicios que gestione. Es una parte fundamental de la imple-
mentacin, tanto por ser imprescindible para cumplir con el ENS como para
garantizar el xito de las medidas implementadas.
10.2.3. Verificacin y validacin
El nivel de seguridad debe ser controlado para verificar si las medidas de seguridad
estn funcionando correctamente y los resultados son los esperados. Con el tiempo
y los cambios en la organizacin, puede ser que las adoptadas en un principio no
sean las adecuadas por ser excesivas o insuficientes, no ser eficaces para reducir el
riesgo, etc.
Adems del control rutinario, se deben realizar revisiones, como por ejemplo:
Autoevaluaciones. Llevadas a cabo por el responsable de seguridad, perti-
nentemente documentadas, y en las que se chequeen:
La validez y vigencia de la poltica, y la normativa de seguridad.
La vigencia de la categorizacin de los sistemas y el anlisis de riesgos.
La validez y vigencia de los controles aplicados.
La eficacia de los controles.
Auditoras. Llevadas a cabo por un auditor cualificado e independiente, que
compruebe que las medidas implementadas y la documentacin de soporte
cumple con los requisitos del ENS.
Cuando los sistemas son de nivel bajo, una autoevaluacin peridica es suficiente,
pero si son de nivel medio o alto estn sujetos, como mnimo, a una auditora cada
dos aos.
10.2.4. Actualizacin y mejora continua
Para cumplir con los requisitos de actualizacin y mejora continua que plantea el
ENS, se utilizar la informacin derivada de la gestin de incidencias y los resulta-
dos de las actividades de verificacin y validacin.
A partir de aqu, se debe derivar a un plan de accin para subsanar los errores
detectados, que justificarn el cumplimiento en este aspecto que requiere el ENS.
11
Ejemplo prctico:
plan de adecuacin
11.1. Documentacin de la poltica de seguridad
Aprobacin y entrada en vigor. Fecha de la aprobacin y entrada en vigor de la
poltica.
Introduccin. Breve descripcin de los objetivos de la organizacin en cuanto a la
seguridad de la informacin y los medios que se estn utilizarn para garantizarla.
Prevencin. Declaracin de las medidas de seguridad existentes para prevenir
daos a la informacin o los servicios.
Deteccin. Declaracin de las medidas de seguridad existentes para detectar inci-
dentes que puedan producir daos a la informacin o los servicios.
Respuesta. Declaracin de las medidas de seguridad existentes para dar respuesta a
los incidentes que puedan producir daos a la informacin o los servicios.
Recuperacin. Declaracin de las medidas de seguridad existentes para recuperar
la disponibilidad de los servicios y garantizar la continuidad de las actividades de la
entidad.
Alcance. Declaracin del alcance de la aplicacin del ENS, habitualmente en tr-
minos de los servicios que se prestan en la entidad.
Misin. Declaracin de la misin de la entidad en los aspectos de seguridad.
Marco normativo. Declaracin de la legislacin aplicable a la entidad en el mbito
de la seguridad de la informacin.
Organizacin de la seguridad. Descripcin de los principales roles y responsabili-
dades exigidos por el ENS: responsable de servicio, responsable de la informacin
y responsable de seguridad.
Descripcin de la composicin de los comits de seguridad y de sus funciones.
Procedimientos de designacin. Descripcin del mecanismo a utilizar para desig-
nar los responsables descritos anteriormente.
Poltica de seguridad de la informacin. Descripcin de la gestin de la poltica,
vigencia, revisin y actualizacin, y difusin.
Datos de carcter personal. En esta seccin se deben identificar los datos de
carcter personal que quedan dentro del mbito del ENS o hacer referencia al
documento de seguridad.
Gestin de riesgos. Declaracin de haber realizado un anlisis de riesgos y de la
periodicidad de su revisin y actualizacin.
Desarrollo de la poltica de seguridad de la informacin. Descripcin de los
mecanismos por los que se desarrollar la poltica, como por ejemplo, la normativa
de seguridad y cmo se va a difundir en la organizacin.
Obligaciones del personal. Descripcin de las principales obligaciones del personal,
como por ejemplo, conocer y aplicar la poltica, y formarse segn requerimientos.
Terceras partes. Descripcin de los mecanismos para gestionar la seguridad
cuando se presten servicios o se gestione informacin de terceros, y a la inversa,
cuando terceros presten servicios o gestionen informacin de la entidad.
11.2. Documentacin de la categora del sistema
11.2.1. Criterios de valoracin de los activos
En esta seccin se describirn los criterios mediante los que se van a valorar los acti-
vos.
Para el ejemplo se han seguido los criterios definidos en la gua CCN-STIC-803
Esquema Nacional de Seguridad, valoracin de los sistemas.
11.2.2. Categorizacin de sistemas
Para categorizar los sistemas segn el ENS, se recomienda seguir los pasos descri-
tos en la gua CCN-STIC-803 Valoracin de los sistemas.
Se identificarn los servicios que se prestan y la informacin que los soporta,
decidiendo para cada uno de ellos, la relevancia para la entidad del impacto de
un incidente en cada una de las dimensiones de seguridad: disponibilidad (D),
integridad (I) y confidencialidad (C), autenticidad (A) y trazabilidad (T).
En la tabla 11.1 se muestra un ejemplo donde se han incluido los responsables pro-
puestos. Los que se asignen definitivamente quedarn documentados en la poltica
de seguridad.
159 11. Ejemplo prctico: plan de adecuacin
Tabla 11.1. Categorizacin de sistemas
Sistema /
Subsistema
Tipo de
Activo
Responsable Activos D I C A T Categora
Sede electrnica
Portal web B B B B B B
Informacin
Secretara
general
Informacin
de la sede
B B B B B
Servicios
Responsable
TIC
Portal de sede B B B B B
Consultas y notificaciones B M M M M M
Informacin
Responsable
del servicio
Expedientes
administrativos
M M M M M
Servicios
Responsable
TIC
Consultas M M B M M
Notificaciones M A M M M
Registro electrnico M M A A A A
Informacin
Secretara
general
Datos del
registro
A M M M M
Servicios
Responsable
TIC
Registro
general
A M B M M
Tabln oficial B B B B B B
Informacin
Secretara
general
Informacin
del tabln
B B B B B
Servicios
Responsable
TIC
Plataforma
del tabln
B B B B B
11.3. Documentacin del anlisis de riesgos
11.3.1. Metodologa de anlisis
En esta seccin se indicar la metodologa que se va a seguir para realizar el anlisis
de riesgos. En este ejemplo, se ha utilizado la herramienta PILAR basada en la
metodologa MAGERIT.
11.3.2. Valoracin de activos
En este punto se identificarn los activos utilizados para soportar los servicios y la
informacin, y se valorar su importancia para la entidad en cada una de las cinco
dimensiones de seguridad. Puede verse un ejemplo en la tabla 11.2.
Activo D I C A T
Servicios
Portal de la sede B B B B B
Consultas M M B M M
Notificaciones M A M M M
Registro General A M B M M
Plataforma del tabln oficial B B B B B
Informacin
Informacin de la sede B B B B B
Expedientes administrativos M M M M M
Datos del registro A M M M M
Informacin del tabln B B B B B
[HW] Hardware
Servidor de datos A A M M M
Servidor de aplicaciones A A M M M
Puestos de usuario M M M M M
Tabla 11.2. Valoracin de activos
(contina)
11.3.3. Mapas de riesgos
Con la valoracin anterior se realizar un anlisis de riesgos, evaluando en primer
lugar el riesgo potencial, que es el que presenta un activo antes de aplicarle ninguna
medida de seguridad y despus el riesgo actual, que es el que presentan los activos
considerando las medidas de seguridad (salvaguardas) implementadas en la organi-
zacin.
En la tabla 11.3 se muestra un ejemplo de listado de las medidas implementadas y
su grado de madurez.
En la tabla 11.4 se muestran los riesgos potenciales y los actuales de los activos
identificados.
11.3.4. Nivel de riesgo aceptable
A la vista de los riesgos identificados hay que marcar el nivel que se considera acep-
table. En este ejemplo, se considerar que el riesgo aceptable es 4. Se aplicarn
medidas a los riesgos que superen este valor y se asumirn el resto.
Activo D I C A T
Red de comunicaciones A A M M M
[SW] Software
Aplicacin de gestin A A M M M
Gestin de BD Oracle A A M M M
Ofimtica M M M M M
[I] Instalaciones
Sede central M M M M M
CPD alternativo M M M M M
[PE] Personal
Personal propio M M M M M
Personal subcontratado M M M M M
Tabla 11.2. Valoracin de activos (continuacin)
Tabla 11.3. Medidas de seguridad implementadas
Medidas
Nivel de
madurez
Marco organizativo 40%
Poltica de seguridad 50%
Normativa de seguridad 50%
Procedimientos de seguridad 50%
Proceso de autorizacin 10%
Marco operacional 43%
Planificacin 40%
Control de acceso 56%
Explotacin 58%
Servicios externos 63%
Continuidad del servicio 10%
Monitorizacin del sistema 30%
Medidas de proteccin 44%
Proteccin de las instalaciones e infraestructuras 70%
Gestin del personal 43%
Proteccin de los equipos 37%
Proteccin de las comunicaciones 37%
Proteccin de los soportes de informacin 18%
Proteccin de las aplicaciones informticas (SW) 50%
Proteccin de la informacin 48%
Proteccin de los servicios 50%
Tabla 11.4. Mapa de riesgos
Activo
Potencial Actual
[D] [I] [C] [A] [T] [D] [I] [C] [A] [T]
[SE] Servicios
Portal de la sede 1,9 1,5 1,9 1,5 1 0,94 0,94 1,4 0,9 0,8
Consultas 3,6 3,3 1,9 3,3 2,8 2,5 2,5 1,4 2,5 2
Notificaciones 3,6 5,1 3,6 3,3 2,8 2,5 4,2 3,1 2,5 2
Registro general 6 3,3 1,9 3,3 2,8 4,8 2,5 1,4 2,5 2
Plataforma del tabln oficial 1,9 1,5 1,9 1,5 1 0,9 0,9 1,4 0,9 0,8
[IN] Informacin
Informacin de la sede electrnica 1 1,5 1,9 1,5 1 0,8 1,1 1,5 1,4 0,9
Expedientes administrativos 2,8 3,3 3,6 3,3 2,8 2,2 2,8 3,3 3,2 2,5
Datos del registro electrnico 2,8 3,3 3,6 3,3 2,8 2,2 2,8 3,3 3,2 2,5
Informacin del tabln de anuncios 1 1,5 1,9 1,5 1 0,8 1,1 1,5 1,4 0,9
[HW] Hardware
Servidor de datos 5,1 3,8 3,3 - - 4,2 2,9 2,5 - -
Servidor de aplicaciones 5,1 3,8 3,3 - - 4,2 2,9 2,5 - -
Puestos de usuario 3,3 2,1 3,3 - - 2,4 1,1 2,5 - -
Red de comunicaciones 5,1 3,8 3,3 - - 4,1 3,1 2,3 - -
[SW] Software
Aplicacin de gestin 5,1 5,7 4,5 3,9 3,4 4,3 4,7 3,7 3,4 2,9
Gestin de DB Oracle 5,1 5,7 4,5 3,9 3,4 4,3 4,7 3,7 3,4 2,9
Ofimtica 3,3 3,9 3,9 3,3 2,8 2,6 2,9 3,1 2,8 2,3
[L] Instalaciones
Sede central 2,5 2,8 2,8 - - 1,7 1,8 1,8 - -
CPD alternativo 3 2,8 2,8 - - 2,2 1,8 1,8 - -
[P] Personal
Personal propio 2,5 2 2,9 - - 1,9 1,7 2,6 - -
Personal subcontratado 2,5 2 2,9 - - 1,8 1,6 2,6 - -
11.4. Documentacin de la declaracin de
aplicabilidad
Esta declaracin consiste en detallar las medidas de seguridad de entre las mencio-
nadas en el anexo II del ENS, con el estado en el que se encuentran, teniendo en
cuenta las que aplican debido a la categora de los sistemas y subsistemas, y aque-
llas que se decidan para mitigar los riesgos detectados.
Cada medida de seguridad tendr uno de los dos estados siguientes:
No aplica. Control no seleccionado debido a que no es obligatorio segn la
categora del sistema, ni se considera necesario para mitigar los riesgos.
Aplica. Control seleccionado por requerimiento del ENS para la categora
del sistema o para mitigar algn riesgo detectado.
En la tabla 11.5 se muestra un ejemplo. A pesar de que por el nivel de los sistemas
no aplicara, para reducir los riesgos no asumibles, se han seleccionado los siguien-
tes controles que se han sealado como aplica en los sistemas de nivel medio:
op.mon.2 Sistema de mtricas.
mp.if.9 Instalaciones alternativas.
mp.per.9 Personal alternativo.
mp.com.9 Medios alternativos.
Tabla 11.5. Declaracin de aplicabilidad
Dimensiones
afectadas
Tipo de
medida
Medida
de seguridad
Estado
nivel medio
Estado
nivel alto
org Marco organizativo
categora org.1 Poltica de seguridad Aplica Aplica
categora org.2 Normativa de seguridad Aplica Aplica
categora org.3 Procedimientos de seguridad Aplica Aplica
categora org.4 Proceso de autorizacin Aplica Aplica
op Marco operacional
op.pl Planificacin
categora op.pl.1 Anlisis de riesgos Aplica Aplica
(contina)
Dimensiones
afectadas
Tipo de
medida
Medida
de seguridad
Estado
nivel medio
Estado
nivel alto
categora op.pl.2 Arquitectura de seguridad Aplica Aplica
categora op.pl.3 Adquisicin de nuevos componentes Aplica Aplica
D op.pl.4 Dimensionamiento/Gestin de capacidades Aplica Aplica
categora op.pl.5 Componentes certificados n.a. Aplica
op.acc Control de acceso
A T op.acc.1 Identificacin Aplica Aplica
I C A T op.acc.2 Requisitos de acceso Aplica Aplica
I C A T op.acc.3 Segregacin de funciones y tareas Aplica Aplica
I C A T op.acc.4 Acceso de gestin de derecho des Aplica Aplica
I C A T op.acc.5 Mecanismo de autenticacin Aplica Aplica
I C A T op.acc.6 Acceso local (local login) Aplica Aplica
I C A T op.acc.7 Acceso remoto (remote login) Aplica Aplica
op.exp Explotacin
categora op.exp.1 Inventario de activos Aplica Aplica
categora op.exp.2 Configuracin de seguridad Aplica Aplica
categora op.exp.3 Gestin de la configuracin Aplica Aplica
categora op.exp.4 Mantenimiento Aplica Aplica
categora op.exp.5 Gestin de cambios Aplica Aplica
categora op.exp.6 Proteccin frente a cdigo daino Aplica Aplica
categora op.exp.7 Gestin de incidencias Aplica Aplica
T op.exp.8 Registro de la actividad de los usuarios n.a. Aplica
categora op.exp.9 Registro de la gestin de incidencias Aplica Aplica
T op.exp.10 Proteccin de los registros de actividad n.a. Aplica
categora op.exp.11 Proteccin de claves criptogrficas Aplica Aplica
op.ext Servicios externos
categora op.ext.1 Contratacin y acuerdos de nivel de servicio Aplica Aplica
categora op.ext.2 Gestin diaria Aplica Aplica
D op.ext.9 Medios alternativos n.a. Aplica
Tabla 11.5. Declaracin de aplicabilidad (continuacin)
(contina)
Dimensiones
afectadas
Tipo de
medida
Medida
de seguridad
Estado
nivel medio
Estado
nivel alto
op.cont Continuidad del servicio
D op.cont.1 Anlisis de impacto Aplica Aplica
D op.cont.2 Plan de continuidad n.a. Aplica
D op.cont.3 Pruebas peridicas n.a. Aplica
op.mon Monitorizacin del sistema
categora op.mon.1 Deteccin de intrusin n.a. Aplica
categora op.mon.2 Sistema de mtricas Aplica Aplica
mp Medidas de proteccin
mp.if Proteccin de las instalaciones e infraestructuras
categora mp.if.1 reas separadas y con control de acceso Aplica Aplica
categora mp.if.2 Identificacin de las personas Aplica Aplica
categora mp.if.3 Acondicionamiento de los locales Aplica Aplica
D mp.if.4 Energa elctrica Aplica Aplica
D mp.if.5 Proteccin frente a incendios Aplica Aplica
D mp.if.6 Proteccin frente a inundaciones Aplica Aplica
categora mp.if.7 Registro de entrada y salida de equipamiento Aplica Aplica
D mp.if.9 Instalaciones alternativas Aplica Aplica
mp.per Gestin del personal
categora mp.per.1 Caracterizacin del puesto de trabajo Aplica Aplica
categora mp.per.2 Deberes y obligaciones Aplica Aplica
categora mp.per.3 Concienciacin Aplica Aplica
categora mp.per.4 Formacin Aplica Aplica
D mp.per.9 Personal alternativo Aplica Aplica
mp.eq Proteccin de los equipos
categora mp.eq.1 Puesto de trabajo despejado Aplica Aplica
A mp.eq.2 Bloqueo de puesto de trabajo Aplica Aplica
categora mp.eq.3 Proteccin de equipos porttiles Aplica Aplica
D mp.eq.9 Medios alternativos Aplica Aplica
(contina)
Dimensiones
afectadas
Tipo de
medida
Medida
de seguridad
Estado
nivel medio
Estado
nivel alto
mp.com Proteccin de las comunicaciones
categora mp.com.1 Permetro seguro Aplica Aplica
C mp.com.2 Proteccin de la confidencialidad Aplica Aplica
I A mp.com.3 Proteccin de la autenticidad y de la integridad Aplica Aplica
categora mp.com.4 Segregacin de redes n.a. Aplica
D mp.com.9 Medios alternativos n.a. Aplica
mp.si Proteccin de los soportes de informacin
C mp.si.1 Etiquetado Aplica Aplica
I C mp.si.2 Criptografa Aplica Aplica
categora mp.si.3 Custodia Aplica Aplica
categora mp.si.4 Transporte Aplica Aplica
C mp.si.5 Borrado y destruccin Aplica Aplica
mp.sw Proteccin de las aplicaciones informticas
categora mp.sw.1 Desarrollo Aplica Aplica
categora mp.sw.2 Aceptacin y puesta en servicio Aplica Aplica
mp.info Proteccin de la informacin
categora mp.info.1 Datos de carcter personal Aplica Aplica
C mp.info.2 Calificacin de la informacin Aplica Aplica
C mp.info.3 Cifrado n.a. Aplica
I A mp.info.4 Firma electrnica Aplica Aplica
T mp.info.5 Sellos de tiempo n.a. Aplica
C mp.info.6 Limpieza de documentos Aplica Aplica
D mp.info.9 Copias de seguridad (back up) Aplica Aplica
mp.s Proteccin de los servicios
categora mp.s.1 Proteccin del correo electrnico Aplica Aplica
categora mp.s.2 Proteccin de servicios y aplicaciones web Aplica Aplica
D mp.s.8 Proteccin frente a la denegacin de servicio Aplica Aplica
D mp.s.9 Medios alternativos n.a. Aplica
11.5. Insuficiencias del sistema
En esta seccin se documentarn las insuficiencias identificadas respecto a los
requisitos del ENS.
Por ejemplo, el bajo nivel de madurez de algunas de las medidas aplicadas viene
dado por una falta de documentacin, por lo que se podra decir que las principa-
les insuficiencias detectadas son:
Documentacin. No hay una gestin documental formal de los aspectos de
seguridad de la informacin a excepcin de lo provisto para cumplir con la
LOPD.
Formacin. El personal ha recibido formacin en cuanto a LOPD pero no
se ha impartido sobre otros aspectos de seguridad.
11.6. Plan de mejora
El plan de mejora debe contener las acciones a tomar hasta el plazo marcado por el
Real Decreto 3/2010.
En la tabla 11.6 se muestra un ejemplo.
Tabla 11.6. Plan de mejora
(contina)
ID Acciones
1.
er
semestre
2012
2.
semestre
2012
1.
er
semestre
2013
2.
semestre
2013
1.
er
semestre
2014
1 Lanzamiento del ENS
1.1 Planificar formacin
1.2 Planificar auditoras
2 Documentacin del ENS
2.1 Elaboracin de la normativa
de seguridad
2.2 Elaboracin de procedimientos
de seguridad
2.3 Formalizar la gestin de los
servicios externos
Tabla 11.6. Plan de mejora (continuacin)
ID Acciones
1.
er
semestre
2012
2.
semestre
2012
1.
er
semestre
2013
2.
semestre
2013
1.
er
semestre
2014
2.4 Documentar la gestin de la
continuidad
2.5 Establecer mtricas de
desempeo
3 Implementacin del ENS
3.1 Llevar a cabo acciones de
concienciacin y formativas
3.2 Implementar procedimientos de
seguridad
4 Monitorizacin y supervisin
4.1 Realizar auditoras
4.2 Revisar objetivos
4.3 Revisar el anlisis de riesgos
5 Proyecto 5: actualizacin y
mantenimiento
4.4 Planificar mejoras
Normas de referencia
Norma UNE- ISO/IEC 27000 Tecnologa de la informacin. Tcnicas de seguridad.
Sistemas de Gestin de la Seguridad de la Informacin (SGSI). Visin de conjunto y
vocabulario.
La aplicacin de cualquier norma necesita de un vocabulario claramente defi-
nido, que evite distintas interpretaciones de conceptos tcnicos y de gestin.
Norma UNE-ISO/IEC 27001 Tecnologa de la informacin. Tcnicas de seguridad.
Sistemas de Gestin de la Seguridad de la Informacin (SGSI). Requisitos.
En ella se recogen los requisitos para establecer, implementar, documentar y
evaluar un SGSI. Es la norma sobre la que se desarrolla el sistema y la que per-
mite obtener la certificacin del mismo por parte de un organismo certificador
independiente. La certificacin del sistema de gestin contribuye a fomentar las
actividades de proteccin de la informacin en las organizaciones, mejorando
su imagen y generando confianza frente a terceros. En su anexo A, enumera los
objetivos de control y controles que desarrolla la UNE-ISO/IEC 27002 para
que sean seleccionados por las organizaciones en el desarrollo de sus SGSI, esta-
bleciendo as formalmente el nexo de unin entre las dos normas.
Norma UNE-ISO/IEC 27002 Tecnologa de la informacin. Tcnicas de seguridad.
Cdigo de buenas prcticas para la gestin de la seguridad de la informacin.
Esta norma ofrece recomendaciones para realizar la gestin de la seguridad de
la informacin que pueden utilizarse por los responsables de iniciar, implemen-
tar o mantener la seguridad en una organizacin. Persigue proporcionar una
Bibliografa
base comn para desarrollar normas de seguridad y constituir una prctica efi-
caz de la gestin. Esta norma no es certificable.
Norma ISO/IEC 27003 Information technology Information security management
system implementation guidance.
Es una gua de implementacin de un SGSI basado en la Norma ISO/IEC
27001 e informacin acerca del uso del modelo PDCA y de los requerimientos
de sus diferentes fases.
Measurement.
Especifica las mtricas y las tcnicas de medida aplicables para determinar la efi-
cacia de un SGSI y de los controles relacionados. Estas mtricas se usan funda-
mentalmente para la medicin de los componentes de la fase Do (implementar
y utilizar) del ciclo PDCA.
Norma ISO/IEC 27005 Information technology Information security risk mana-
gement.
Consiste en una gua de tcnicas para la gestin del riesgo de la seguridad de la
informacin y servir, por tanto, de apoyo a la Norma UNE-ISO/IEC 27001 y
a la implementacin de un SGSI. Recoge partes de ISO/IEC TR 13335.
Norma ISO/IEC 27006 Information technology Requirements for bodies pro-
viding audit and certification of information security management systems.
Especifica los requisitos para la acreditacin de entidades de auditora y certifi-
cacin de sistemas de gestin de seguridad de la informacin.
Norma ISO/IEC 27007 Information technology Guidelines for information secu-
rity management systems auditing.
En fase de desarrollo. Consistir en una gua para realizar una auditora a un
SGSI.
guidelines for telecommunications organizations based on ISO/IEC 27002.
Es una gua de gestin de seguridad de la informacin especfica para telecomu-
nicaciones, elaborada a partir de una Recomendacin de la UIT (Unin Inter-
nacional de Telecomunicaciones).
Norma ISO/IEC FCD 27032 Information technology Guidelines for cybersecurity
En fase de desarrollo. Consistir en una gua relativa a la ciberseguridad.
Serie ISO/IEC 27033 Information technology Network security
Dividida en 7 partes: gestin de seguridad de redes, arquitectura de seguridad
de redes, escenarios de redes de referencia, aseguramiento de las comunicacio-
nes entre redes mediante gateways, acceso remoto, aseguramiento de comunica-
ciones en redes mediante VPNs y diseo e implementacin de seguridad en
redes. Provendr de la revisin, ampliacin y renumeracin de ISO 18028.
Serie ISO/IEC 27034 Information technology Network security.
Se ha publicado la primera parte, y el resto est en desarrollo. Ser en una gua
de seguridad en aplicaciones.
Informe UNE 71501-1 IN Tecnologa de la Informacin (TI). Gua para la gestin
de la seguridad de TI. Parte 1: Conceptos y modelos para la seguridad de TI.
Este informe proporciona una visin general de los conceptos fundamentales y
de los modelos utilizados para describir la gestin de seguridad de TI.
Informe UNE 71501-2 IN Tecnologa de la informacin (TI). Gua para la gestin
de la seguridad de TI. Parte 2: Gestin y planificacin de la seguridad de TI.
Se describen varios aspectos de gestin y planificacin de la seguridad de TI.
Informe UNE 71501-3 IN Tecnologa de la informacin (TI). Gua para la gestin
de la seguridad de TI. Parte 3: Tcnicas para la gestin de la seguridad de TI.
Esta norma describe varias tcnicas de seguridad indicadas para distintas fases
de un proyecto, desde la planificacin hasta la explotacin, pasando por la
implementacin.
Informe UNE 66172:2003 Directrices para la justificacin y desarrollo de normas de
sistemas de gestin.
ISO/IEC 15408 Information technology Security techniques Evaluation criteria
for IT security.
UNE-ISO GUIA 73:2010 IN Gestin del riesgo. Vocabulario.
173 Bibliografa
Legislacin
Ley 11/2007, de 22 de junio, de acceso electrnico de los ciudadanos a los Servi-
cios Pblicos. Su objeto es establecer la poltica de seguridad en la utilizacin de
medios electrnicos, y est constituido por principios bsicos y requisitos mni-
mos que permitan una proteccin adecuada de la informacin.
Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Seguridad en el mbito de la Administracin Electrnica.
Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Interoperabilidad en el mbito de la Administracin Electrnica.
Ley Orgnica 15/1999, de 13 de diciembre, de Proteccin de Datos de Carcter
Personal.
Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento
de desarrollo de la Ley Orgnica 15/1999, de 13 de diciembre, de proteccin de
datos de carcter personal.
Otros documentos
CCN-STIC-201 Estructura de seguridad. Enero 2009.
CCN-STIC-402 Organizacin y gestin TIC. Diciembre 2006.
CCN-STIC-801 Responsabilidades en el Esquema Nacional de Seguridad. Febrero
2010.
CCN-STIC-802 Auditora del Esquema Nacional de Seguridad. Junio 2010.
CCN-STIC-803 Valoracin de sistemas en el Esquema Nacional de Seguridad.
Enero 2011.
CCN-STIC-804 Medidas de implantacin del Esquema Nacional de Seguridad
(borrador). Octubre 2011.
CCN-STIC-805 Poltica de seguridad del Esquema Nacional de Seguridad. Sep-
tiembre 2011.
CCN-STIC-806 Plan de adecuacin del Esquema Nacional de Seguridad. Enero
2011.
CCN-STIC-807 Criptologa de empleo en el Esquema Nacional de Seguridad.
Septiembre 2011.
Bibliografa 175
CCN-STIC-808 Verificacin del cumplimiento de las medidas en el Esquema
Nacional de Seguridad. Septiembre 2011.
CCN-STIC-809 Declaracin de conformidad del Esquema Nacional de Seguridad
(borrador). Julio 2010.
CCN-STIC-810 Creacin de un CERT-CSIRT (borrador). Septiembre 2011.
CCN-STIC-811 Interconexin en el Esquema Nacional de Seguridad (borrador).
Septiembre 2011.
CCN-STIC-812 Seguridad en entornos y aplicaciones web (borrador). Octubre
2011.
CCN-STIC-814 Seguridad en correo electrnico (borrador). Agosto 2011.
CCN-STIC-815 Mtricas e indicadores en el Esquema Nacional de Seguridad
(borrador). Diciembre 2011.
Norma Tcnica de Interoperabilidad de Documento Electrnico. Resolucin de 19
de julio de 2011 de la Secretara de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de Digitalizacin de Documentos. Resolu-
cin de 19 de julio de 2011 de la Secretara de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de Expediente Electrnico. Resolucin de 19
de julio de 2011, de la Secretara de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de Poltica de Firma Electrnica y de certifi-
cados de la Administracin. Resolucin de 19 de julio de 201, de la Secretara
de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de requisitos de conexin a la red de comuni-
caciones de las Administraciones Pblicas espaolas. Resolucin de 19 de julio
de 2011 de la Secretara de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de Procedimientos de copiado autntico y
conversin entre documentos electrnicos. Resolucin de 19 de julio de 2011
de la Secretara de Estado para la Funcin Pblica.
Norma Tcnica de Interoperabilidad de Modelo de Datos para el Intercambio de
asientos entre las entidades registrales. Resolucin de 19 de julio de 2011, de la
Secretara de Estado para la Funcin Pblica.
CNSS Inst. 4009 National Information Assurance (IA) Glossary. April 2010.
FIPS 200. Minimum Security Requirements for Federal Information and Information
Systems. March 2006.
ISO Guide 73 Risk management Vocabulary. 2009.
SP 800-12. An Introduction to Computer Security: The NIST Handbook. Special
Publication 800-12. October 1995.
Links de inters
Asociacin Espaola de Normalizacin (AENOR).
www.aenor.es
European Network and Information Security Agency (ENISA).
www.enisa.europa.eu
Instituto Nacional de Tecnologas de la Comunicacin (INTECO).
www.inteco.es
ISMS Forum Spain. Asociacin Espaola para el Fomento de la Seguridad de
la Informacin.
www.ismsforum.es
MAGERIT versin 2. Metodologa de Anlisis y Gestin de Riesgos de los
Sistemas de Informacin.
www.csi.map.es/csi/pg5m20.htm
Esquema Nacional de Seguridad
https://www.ccn-cert.cni.es
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P4002281
273766578416&langPae=es
Esquema Nacional de Interoperabilidad
http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P4001281
273739471793&langPae=es
National Institute of Standards and Technology (NIST).
An Introduction to Computer Security: The NIST Handbook
http://csrc.nist.gov/publications
RED.ES. Documentos emitidos por RED.ES.
www.red.es
START UP. Empresa consultora especializada en diseo e implementacin de
sistemas de gestin de seguridad de la informacin.
www.seguridadinformacion.com
Norma UNE-ISO/IEC 27001:2007
Tecnologa de la informacin.
Tcnicas de seguridad.
Sistemas de Gestin de la Seguridad
de la Informacin (SGSI). Requisitos
UNE-ISO/IEC 27001

norma
espaola
Noviembre 2007

TITULO

Tecnologa de la informacin

Tcnicas de seguridad

Sistemas de Gestin de la Seguridad de la Informacin (SGSI)

Requisitos

(ISO/IEC 27001:2005)

Information technology. Security techniques. Information security management systems. Requirements.
(ISO/IEC 27001.2005).

Technologies ae linformation. Techniques ae securite. Systmes ae gestion ae securite ae linformation.
Exigences. (ISO/IEC 27001.2005).

CORRESPONDENCIA

Esta norma es idntica a la Norma Internacional ISO/IEC 27001:2005.

OBSERVACIONES

Esta norma anulara y sustituira a la Norma UNE 71502:2004 el 2008-12-31.

ANTECEDENTES

Esta norma ha sido elaborada por el comit tcnico AEN/CTN 71 Tecnologia ae la
Informacion cuya Secretaria desempea AETIC.

Editada e impresa por AENOR
Deposito legal: M 52351:2007

LAS OBSERVACIONES A ESTE DOCUMENTO HAN DE DIRIGIRSE A:

35 Paginas

AENOR 2007
Reproduccion prohibida
C Gnova, 6
28004 MADRID-Espaa
TelIono 91 432 60 00
Fax 91 310 40 32
Grupo 22
S
- 3 - ISO/IEC 27001:2005
INDICE
Pgina
PRLOGO........................................................................................................................................ 4

0 INTRODUCCIN............................................................................................................ 5
0.1 Generalidades ................................................................................................................... 5
0.2 Enfoque por proceso ........................................................................................................ 5
0.3 Compatibilidad con otros sistemas de gestin ............................................................... 6

1 OB1ETO Y CAMPO DE APLICACIN ...................................................................... 7
1.1 Generalidades ................................................................................................................... 7
1.2 Aplicacin ......................................................................................................................... 7

2 NORMAS PARA CONSULTA....................................................................................... 7

3 TRMINOS Y DEFINICIONES.................................................................................... 7

4 SISTEMA DE GESTIN DE LA SEGURIDAD DE LA INFORMACIN .............. 9
4.1 Requisitos generales ......................................................................................................... 9
4.2 Creacin y gestin del SGSI ............................................................................................ 9
4.2.1 Creacin del SGSI ............................................................................................................ 9
4.2.2 Implementacin y operacin del SGSI ........................................................................... 11
4.2.3 Supervisin y revisin del SGSI...................................................................................... 12
4.2.4 Mantenimiento y mejora del SGSI ................................................................................. 12
4.3 Requisitos de la documentacin...................................................................................... 13
4.3.1 Generalidades ................................................................................................................... 13
4.3.2 Control de documentos .................................................................................................... 13
4.3.3 Control de registros.......................................................................................................... 14

5 RESPONSABILIDAD DE LA DIRECCIN................................................................ 14
5.1 Compromiso de la direccin............................................................................................ 14
5.2 Gestin de los recursos..................................................................................................... 15
5.2.1 Provisin de los recursos ................................................................................................. 15
5.2.2 Concienciacin, formacin y capacitacin..................................................................... 15

6 AUDITORIAS INTERNAS DEL SGSI ......................................................................... 15

7 REVISIN DEL SGSI POR LA DIRECCIN............................................................. 16
7.1 Generalidades ................................................................................................................... 16
7.2 Datos iniciales de la revisin............................................................................................ 16
7.3 Resultados de la revisin ................................................................................................. 16

8 ME1ORA DEL SGSI ....................................................................................................... 17
8.1 Mejora continua ............................................................................................................... 17
8.2 Accin correctiva.............................................................................................................. 17
8.3 Accin preventiva............................................................................................................. 17

ANEXO A (Normativo) OB1ETIVOS DE CONTROL Y CONTROLES ............................... 18

ANEXO B (Informativo) LOS PRINCIPIOS DE LA OCDE Y ESTA
NORMA INTERNACIONAL............................................................. 32

ANEXO C (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS ISO 9001:2000,
ISO 14001:2004 Y ESTA NORMA INTERNACIONAL.................. 33

BIBLIOGRAFIA............................................................................................................................... 35
ISO/IEC 27001:2005 - 4 -

PRLOGO

ISO (Organizacion Internacional de Normalizacion) e IEC (Comision Electrotcnica Internacional)
constituyen el sistema especializado para la normalizacion a nivel mundial. Los organismos nacionales
que son miembros de ISO o IEC participan en el desarrollo de las normas internacionales a travs de
comits tcnicos establecidos por las organizaciones respectivas para realizar acuerdos en campos especi-
Iicos de la actividad tcnica. Los comits tcnicos de ISO e IEC colaboran en los campos de inters
mutuo. Otras organizaciones internacionales, gubernamentales y no gubernamentales, en colaboracion
con ISO e IEC, tambin toman parte en el trabajo. En el campo de la tecnologia de la inIormacion, ISO e
IEC han establecido un comit tcnico 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 comits tcnicos es elaborar normas internacionales. Los proyectos de normas
internacionales adoptados por los comits tcnicos se envian a los organismos nacionales miembros para
su voto. La publicacion como norma internacional requiere la aprobacion de al menos el 75 de los
organismos nacionales miembros con derecho a voto.

Se llama la atencion 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 de la identiIicacion
de dichos derechos de patente.

La Norma ISO/IEC 27001 ha sido elaborada por el subcomit SC 27 Tecnicas ae seguriaaa que Iorma
parte del comit tcnico conjunto ISO/IEC JTC 1 Tecnologias ae la informacion.

- 5 - ISO/IEC 27001:2005
0 INTRODUCCIN

0.1 Generalidades
Esta norma internacional proporciona un modelo para la creacion, implementacion, operacion, supervision, revision,
mantenimiento y mejora de un Sistema de Gestion de la Seguridad de la InIormacion (SGSI). La adopcion de un SGSI
deberia ser Iruto de una decision estratgica de una organizacion. El diseo y la implementacion del SGSI dependen de
las necesidades y objetivos de cada organizacion, asi como de sus requisitos de seguridad, sus procesos, su tamao y
estructura. Es previsible que estos Iactores y los sistemas que los soportan cambien con el tiempo. Lo habitual es que la
implementacion de un SGSI se ajuste a las necesidades de la organizacion; por ejemplo, una situacion sencilla requiere
un SGSI simple.

Esta norma internacional sirve para que cualquier parte interesada, ya sea interna o externa a la organizacion, pueda
eIectuar una evaluacion de la conIormidad.
0.2 Enfoque por proceso
Esta norma internacional adopta un enIoque por proceso para la creacion, implementacion, operacion, supervision,
revision, mantenimiento y mejora del SGSI de una organizacion.

Una organizacion tiene que deIinir y gestionar numerosas actividades para Iuncionar con eIicacia. Cualquier actividad
que utiliza recursos y se gestiona de modo que permite la transIormacion de unos elementos de 'entrada en unos
elementos de 'salida puede considerarse un proceso. A menudo, la salida de un proceso se convierte directamente en la
entrada del proceso siguiente.

La aplicacion de un conjunto de procesos en una organizacion, junto con la identiIicacion de stos y sus interacciones y
su gestion, puede caliIicarse de 'enIoque por proceso.

El enIoque por proceso para la gestion de la seguridad de la inIormacion que se describe en esta norma internacional
anima a los usuarios a enIatizar la importancia de:

a) comprender los requisitos de seguridad de la inIormacion de una organizacion y la necesidad de establecer una
politica de seguridad de la inIormacion y sus objetivos;

b) implementar y operar los controles para administrar los riesgos de seguridad de la inIormacion de una organizacion
en el marco de sus riesgos empresariales generales;

c) supervisar y revisar el rendimiento y la eIicacia del SGSI; y

d) asegurar la mejora continua sobre la base de la medicion objetiva.

Esta norma internacional sigue el modelo 'PlaniIicar-hacer-veriIicar-actuar (Plan-Do-Check-Act conocido como mo-
delo PDCA), que se aplica para estructurar todos los procesos del SGSI. La Iigura 1 muestra como un SGSI, partiendo
de los requisitos y expectativas de seguridad de la inIormacion de las partes interesadas y a travs de las acciones y pro-
cesos necesarios, produce los elementos de salida de seguridad de la inIormacion que responden a dichos requisitos y
expectativas. La Iigura 1 ilustra asimismo los vinculos con los procesos que se describen en los capitulos 4, 5, 6, 7 y 8.

La adopcion del modelo PDCA tambin reIlejara los principios deIinidos en las Directrices de la OCDE (2002)
1)
que
rigen la seguridad de los sistemas y las redes de inIormacion. Esta norma internacional proporciona un modelo robusto
para implementar los principios de dichas directrices que rigen la evaluacion de riesgos, el diseo y la implementacion
de la seguridad, asi como la gestion y la reevaluacion de la seguridad.

1) Directrices de la OCDE para la Seguridad de los Sistemas y Redes de InIormacion Hacia una cultura de la seguridad. Paris: OCDE, julio
de 2002. www.oecd.org.
ISO/IEC 27001:2005 - 6 -
EJEMPLO 1 (requisito de seguridad)
Un requisito podria ser que ninguna violacion de la seguridad de la inIormacion debe provocar perjuicios economicos
graves y/o comprometer a la organizacion.

EJEMPLO 2 (expectativa de seguridad)
En el caso de que se produjera un incidente grave, como por ejemplo un ataque inIormatico al sitio web de comercio
electronico de una organizacion, deberia haber personas con suIiciente Iormacion en los procedimientos adecuados para
minimizar las consecuencias.

Figura 1 Modelo PDCA aplicado a los procesos del SGSI

Planificar (creacin del SGSI) DeIinir la politica, objetivos, procesos y procedimientos del SGSI relevantes para
gestionar el riesgo y mejorar la seguridad de la inIormacion, con el Iin de obtener
resultados acordes con las politicas y objetivos generales de la organizacion.
Hacer (implementacin y
operacin del SGSI)
Implementar y operar la politica, controles, procesos y procedimientos del SGSI.
Verificar (supervisin y revisin
del SGSI)
Evaluar y, en su caso, medir el rendimiento del proceso contra la politica, los
objetivos y la experiencia practica del SGSI, e inIormar de los resultados a la
Direccion para su revision.
Actuar (mantenimiento y mejora
del SGSI)
Adoptar medidas correctivas y preventivas, en Iuncion de los resultados de la
auditoria interna del SGSI y de la revision por parte de la direccion, o de otras
inIormaciones relevantes, para lograr la mejora continua del SGSI.

0.3 Compatibilidad con otros sistemas de gestin
Esta norma internacional sigue las pautas marcadas en las Normas ISO 9001:2000 e ISO 14001:2004 para asegurar una
implementacion integrada y consistente con las mencionadas normas de gestion. De este modo, un sistema de gestion
bien concebido puede cumplir los requisitos de todas esas normas. La tabla C.1 muestra la relacion entre los capitulos
de esta norma internacional y las Normas ISO 9001:2000 e ISO 14001:2004.

Esta norma internacional esta diseada para posibilitar a una organizacion el adaptar su SGSI a los requisitos de los
sistemas de gestion mencionados.
- 7 - ISO/IEC 27001:2005
IMPORTANTE: Esta publicacin no pretende incluir todas las provisiones necesarias en un contrato. Los
usuarios de la norma son responsables de su correcta aplicacin. La conformidad con esta norma internacional
no otorga inmunidad frente al cumplimiento de las obligaciones legales.
1 OB1ETO Y CAMPO DE APLICACIN

1.1 Generalidades
Esta norma internacional abarca todo tipo de organizaciones (por ejemplo, empresas, organismos y entes publicos, enti-
dades sin animo de lucro) y especiIica los requisitos para la creacion, implementacion, operacion, supervision, revision,
mantenimiento y mejora de un SGSI documentado, en el marco de los riesgos empresariales generales de la
organizacion. EspeciIica los requisitos para el establecimiento de controles de seguridad, adaptados a las necesidades de
una organizacion o de partes de la misma.

El SGSI esta diseado con el Iin de asegurar la seleccion de controles de seguridad, adecuados y proporcionados, que
protejan los activos de inIormacion y den garantias a las partes interesadas.
NOTA 1 Las reIerencia al trmino 'empresarial o de 'negocio en esta norma internacional deberian interpretarse en un sentido amplio, abarcando
aquellas actividades que son esenciales para alcanzar los Iines que persigue la organizacion.
NOTA 2 La Norma ISO/IEC 17799 proporciona una guia de implantacion que puede utilizarse al disear los controles.
1.2 Aplicacin
Los requisitos establecidos en esta norma internacional son genricos y aplicables a todas las organizaciones, cualquiera
que sea su tipo, tamao y naturaleza. Cuando una organizacion declara que cumple esta norma internacional, no se
admitira la exclusion de ninguno de los requisitos deIinidos en los capitulos 4, 5, 6, 7 y 8.

Toda exclusion de controles que se considere necesaria para cumplir los criterios de aceptacion del riesgo necesita ser justiIi-
cada mediante evidencia de que los riesgos asociados han sido aceptados por las personas responsables. Cuando se excluya
algun control, no se aceptara ninguna declaracion de conIormidad con esta norma internacional a menos que tales exclusiones
no aIecten a la capacidad y/o responsabilidad de la organizacion para garantizar la seguridad de la inIormacion de acuerdo con
los requisitos de seguridad derivados de la evaluacion de riesgos y de los requisitos legales o reglamentarios aplicables.

NOTA En la mayoria de los casos, si una organizacion tiene implantado un sistema de gestion del proceso de negocio (por ejemplo, ISO 9001 o
ISO 14001), es preIerible cumplir los requisitos de esta norma internacional dentro del sistema de gestion ya existente.
2 NORMAS PARA CONSULTA
Las normas que a continuacion se indican son indispensables para la aplicacion de esta norma. Para las reIerencias con
Iecha, solo se aplica la edicion citada. Para las reIerencias sin Iecha se aplica la ultima edicion de la norma (incluyendo
cualquier modiIicacion de sta).
ISO/IEC 17799:2005 Tecnologia ae la informacion. Tecnicas ae seguriaaa. Coaigo ae buenas practicas para la gestion
ae la seguriaaa ae la informacion.
3 TRMINOS Y DEFINICIONES
Para los Iines del presente documento, se aplican las siguientes deIiniciones.

3.1 activo:
Cualquier bien que tiene valor para la organizacion.
|ISO/IEC 13335-1:2004|

3.2 disponibilidad:
La propiedad de ser accesible y utilizable por una entidad autorizada.
|ISO/IEC 13335-1:2004|
ISO/IEC 27001:2005 - 8 -
3.3 confidencialidad:
La propiedad por la que la inIormacion no se pone a disposicion o se revela a individuos, entidades o procesos no
autorizados.

|ISO/IEC 13335-1:2004|
3.4 seguridad de la informacin:
La preservacion de la conIidencialidad, la integridad y la disponibilidad de la inIormacion, pudiendo, ademas, abarcar
otras propiedades, como la autenticidad, la responsabilidad, la Iiabilidad y el no repudio.

|ISO/IEC 17799:2005|
3.5 evento de seguridad de la informacin:
La ocurrencia detectada en un estado de un sistema, servicio o red que indica una posible violacion de la politica de
seguridad de la inIormacion, un Iallo de las salvaguardas o una situacion desconocida hasta el momento y que puede ser
relevante para la seguridad.

|ISO/IEC TR 18044:2004|
3.6 incidente de seguridad de la informacin:
un unico evento o una serie de eventos de seguridad de la inIormacion, inesperados o no deseados, que tienen una pro-
babilidad signiIicativa de comprometer las operaciones empresariales y de amenazar la seguridad de la inIormacion.

|ISO/IEC TR 18044:2004|
3.7 Sistema de Gestin de la Seguridad de la Informacin (SGSI) [Information Security Management System
(ISMS)j:
La parte del sistema de gestion general, basada en un enIoque de riesgo empresarial, que se establece para crear, imple-
mentar, operar, supervisar, revisar, mantener y mejorar la seguridad de la inIormacion.

NOTA El sistema de gestion incluye la estructura organizativa, las politicas, las actividades de planiIicacion, las responsabilidades, las practicas, los
procedimientos, los procesos y los recursos.
3.8 integridad:
La propiedad de salvaguardar la exactitud y completitud de los activos.

|ISO/IEC 13335-1:2004|
3.9 riesgo residual:
Riesgo remanente que existe despus de que se hayan tomado las medidas de seguridad.

|ISO/IEC Guide 73:2002|
3.10 aceptacin del riesgo:
La decision de aceptar un riesgo.

3.11 anlisis de riesgos:
Utilizacion sistematica de la inIormacion disponible para identiIicar peligros y estimar los riesgos.

- 9 - ISO/IEC 27001:2005
3.12 evaluacin de riesgos:
El proceso general de analisis y estimacion de los riesgos.
3.13 estimacin de riesgos:
El proceso de comparacion del riesgo estimado con los criterios de riesgo, para asi determinar la importancia del riesgo.
3.14 gestin de riesgos
Actividades coordinadas para dirigir y controlar una organizacion con respecto a los riesgos.
3.15 tratamiento de riesgos
El proceso de seleccion e implementacion de las medidas encaminadas a modiIicar los riesgos.
|ISO/IEC Guide 73:2002|.

NOTA En esta norma internacional, el trmino 'control se utiliza como sinonimo de 'medida de seguridad.
3.16 declaracin de aplicabilidad:
Declaracion documentada que describe los objetivos de control y los controles que son relevantes para el SGSI de la
organizacion y aplicables al mismo.

NOTA Los objetivos de control y los controles se basan en los resultados y conclusiones de la evaluacion de riesgos y en los procesos de tratamiento
del riesgo, en los requisitos legales o reglamentarios, en las obligaciones contractuales y en las necesidades empresariales de la organizacion
en materia de seguridad de la inIormacion.

4 SISTEMA DE GESTIN DE LA SEGURIDAD DE LA INFORMACIN

La organizacion debe crear, implementar, operar, supervisar, revisar, mantener y mejorar un SGSI documentado dentro
del contexto de las actividades empresariales generales de la organizacion y de los riesgos que sta aIronta. A eIectos de
esta norma internacional, el proceso utilizado se basa en el modelo PDCA descrito en la Iigura 1.
4.2 Creacin y gestin del SGSI

La organizacion debe hacer lo siguiente:

a) DeIinir el alcance y los limites del SGSI en trminos de las caracteristicas de la actividad empresarial, de la
organizacion, su ubicacion, sus activos y tecnologia, incluyendo los detalles y la justiIicacion de cualquier exclusion
del alcance (vase 1.2).

b) DeIinir una politica del SGSI acorde con las caracteristicas de la actividad empresarial, la organizacion, su ubica-
cion, sus activos y tecnologia, que:
1) incluya un marco para la Iijacion de objetivos y establezca una orientacion general sobre las directrices y prin-
cipios de actuacion en relacion con la seguridad de la inIormacion;
2) tenga en cuenta los requisitos de la actividad empresarial, los requisitos legales o reglamentarios y las obligacio-
nes de seguridad contractuales;
3) est alineada con el contexto de la estrategia de gestion de riesgos de la organizacion contexto en el que tendra
lugar la creacion y el mantenimiento del SGSI;
ISO/IEC 27001:2005 - 10 -
4) establezca criterios de estimacion del riesgo |vase 4.2.1c)| y
5) sea aprobada por la Direccion.

NOTA A eIectos de esta norma internacional, la politica de seguridad de la inIormacion se considera un subconjunto de la politica del SGSI.
Estas politicas pueden estar descritas en un unico documento.

c) DeIinir el enIoque de la evaluacion de riesgos de la organizacion.
1) EspeciIicar una metodologia de evaluacion de riesgos adecuada para el SGSI, las necesidades de negocio identi-
Iicadas en materia de seguridad de la inIormacion de la empresa y los requisitos legales y reglamentarios.
2) Desarrollar criterios de aceptacion de riesgo y Iijar los niveles de riesgo aceptables |vase 5.1I)|.

La metodologia seleccionada para la evaluacion de riesgos debe asegurar que las evaluaciones de riesgos generen
resultados comparables y reproducibles.

NOTA Hay diIerentes metodologias para la evaluacion de riesgos. En la Norma ISO/IEC TR 13335-3, Tecnologia de la inIormacion. Direc-
trices para la gestion de la seguridad de TI. Tcnicas de gestion de la seguridad de TI , se comentan algunos ejemplos de metodologias
para la evaluacion de riesgos.

d) IdentiIicar los riesgos.
1) IdentiIicar los activos que estan dentro del ambito de aplicacion del SGSI y a los propietarios
2)
de estos activos.
2) IdentiIicar las amenazas a que estan expuestos esos activos.
3) IdentiIicar las vulnerabilidades bajo las que podrian actuar dichas amenazas.
4) IdentiIicar los impactos que sobre los activos puede tener una prdida de conIidencialidad, integridad y disponi-
bilidad en los mismos.

e) Analizar y valorar los riesgos.
1) Evaluar los eIectos en la actividad empresarial de la organizacion que pudieran derivarse de eventuales Iallos de
seguridad, teniendo en cuenta las consecuencias de una prdida de conIidencialidad, integridad o disponibilidad
de los activos.
2) Evaluar la probabilidad, de una Iorma realista, de que se produzcan Iallos de seguridad a la luz de las amenazas y
vulnerabilidades existentes, los impactos asociados a los activos y los controles implementados.
3) Estimar los niveles de riesgo.
4) Determinar si los riesgos son aceptables o si requieren un tratamiento conIorme a los criterios de aceptacion de
riesgos establecidos en 4.2.1c)2).

I) IdentiIicar y evaluar las opciones para el tratamiento de riesgos.

Las posibles acciones a realizar, entre otras, son las siguientes:
1) aplicar controles adecuados;
2) asumir los riesgos de manera consciente y objetiva, conIorme a las politicas de la organizacion y a los criterios
de aceptacion de riesgos |vase 4.2.1c)2)|;
3) evitar los riesgos; y
4) transIerir los riesgos asociados a la actividad empresarial a otras partes, como por ejemplo compaias de seguros
o proveedores.

2) El trmino 'propietario se reIiere a un individuo o una entidad al que se le ha asignado la responsabilidad administrativa para el control de la
produccion, el desarrollo, el mantenimiento, el uso y la seguridad de los activos. El trmino 'propietario no signiIica que la persona tenga
realmente algun derecho de propiedad sobre el activo.
- 11 - ISO/IEC 27001:2005
g) Seleccionar los objetivos de control y los controles para el tratamiento de los riesgos.

Los objetivos de control y los controles deben seleccionarse e implementarse para cumplir los requisitos identi-
Iicados en la evaluacion de riesgos y en el proceso de tratamiento de riesgos. Esta seleccion debe tener en cuenta los
criterios de aceptacion de riesgos |vase 4.2.1c)2)|, ademas de los requisitos legales, reglamentarios y contractuales.

Los objetivos de control y los controles del anexo A deben seleccionarse como parte de este proceso en la medida en
que sirvan para satisIacer los requisitos identiIicados.

Los objetivos de control y los controles enumerados en el anexo A no son exhaustivos, por lo que pueden seleccio-
narse otros objetivos de control y otros controles adicionales.

NOTA El anexo A contiene una lista completa de objetivos de control y controles que se han considerado comunmente relevantes en las organi-
zaciones. El anexo A proporciona a los usuarios de esta norma internacional un punto de partida para seleccionar los controles, garan-
tizando que no se pasan por alto importantes opciones de control.

h) Obtener la aprobacion, por parte de la Direccion, de los riesgos residuales propuestos.

i) Obtener la autorizacion de la Direccion para implementar y operar el SGSI.

j) Elaborar una declaracion de aplicabilidad.

Una declaracion de aplicabilidad debe incluir lo siguiente:
1) los objetivos de control y los controles seleccionados en 4.2.1g) y las justiIicaciones de su seleccion;
2) los objetivos de control y los controles actualmente implementados |vase 4.2.1e)2)|; y
3) la exclusion de cualquier objetivo de control y control del anexo A y la justiIicacion de esta exclusion.

NOTA La declaracion de aplicabilidad proporciona un resumen de las decisiones relativas al tratamiento de los riesgos. La justiIicacion de las
exclusiones Iacilita una comprobacion cruzada de que no se ha omitido inadvertidamente ningun control.

4.2.2 Implementacin y operacin del SGSI
La organizacion debe hacer lo que se indica a continuacion.
a) Formular un plan de tratamiento de riesgos que identiIique las acciones de la Direccion, los recursos, las responsa-
bilidades y las prioridades adecuados para gestionar los riesgos de la seguridad de la inIormacion (vase 5).
b) Implementar el plan de tratamiento de riesgos para lograr los objetivos de control identiIicados, que tenga en cuenta
la Iinanciacion y la asignacion de Iunciones y responsabilidades.
c) Implementar los controles seleccionados en 4.2.1g) para cumplir los objetivos de control.
d) DeIinir el modo de medir la eIicacia de los controles o de los grupos de controles seleccionados y especiIicar como
tienen que usarse estas mediciones para evaluar la eIicacia de los controles de cara a producir unos resultados
comparables y reproducibles |vase 4.2.3c)|.
NOTA La medicion de la eIicacia de los controles permite a los directivos y al personal determinar hasta qu punto los controles cumplen los
objetivos de control planiIicados.
e) Implementar programas de Iormacion y de concienciacion (vase 5.2.2).
I) Gestionar la operacion del SGSI.
g) Gestionar los recursos del SGSI (vase 5.2).
h) Implementar procedimientos y otros controles que permitan una deteccion temprana de eventos de seguridad y una
respuesta ante cualquier incidente de seguridad |vase 4.2.3a)|.
ISO/IEC 27001:2005 - 12 -
4.2.3 Supervisin y revisin del SGSI
La organizacion debe hacer lo que se indica a continuacion.

a) Ejecutar procedimientos de supervision y revision, asi como otros mecanismos de control para:
1) detectar lo antes posible los errores en los resultados del procesado;
2) identiIicar lo antes posible las debilidades del sistema de seguridad asi como el aprovechamiento de stas tanto
con o sin xito, y los incidentes;
3) permitir a la Direccion determinar si las actividades de seguridad delegadas en otras personas o llevadas a cabo
por medios inIormaticos o a travs de tecnologias de la inIormacion, dan los resultados esperados;
4) ayudar a detectar eventos de seguridad y por tanto a prevenir incidentes de seguridad mediante el uso de
indicadores; y
5) determinar si las acciones tomadas para resolver una violacion de la seguridad han sido eIicaces.

b) Realizar revisiones periodicas de la eIicacia del SGSI teniendo en cuenta los resultados de las auditorias de
seguridad, los incidentes, los resultados de las mediciones de la eIicacia, las sugerencias asi como los comentarios
de todas las partes interesadas Estas revisiones incluyen el cumplimiento de la politica, y de los objetivos del SGSI,
y la revision de los controles de seguridad

c) Medir la eIicacia de los controles para veriIicar si se han cumplido los requisitos de seguridad.

d) Revisar las evaluaciones de riesgos en intervalos planiIicados y revisar los riesgos residuales y los niveles de riesgo
aceptables que han sido identiIicados, teniendo en cuenta los cambios en:
1) la organizacion;
2) la tecnologia;
3) los objetivos y requisitos empresariales;
4) las amenazas identiIicadas;
5) la eIicacia de los controles implementados; y
6) los Iactores externos, como por ejemplo los cambios del entorno legal o reglamentario, de las obligaciones
contractuales y del clima social.

e) Realizar las auditorias internas del SGSI en intervalos planiIicados (vase 6).

NOTA Las auditorias internas, a veces denominadas auditorias por primera parte, las lleva a cabo la propia organizacion, o bien se realizan por
encargo de sta, con Iines internos.

I) Realizar, por parte de la Direccion una revision del SGSI, con caracter regular para asegurar que el ambito de
aplicacion sigue siendo adecuado y que se identiIican mejoras del proceso del SGSI (vase 7.1).

g) Actualizar los planes de seguridad teniendo en cuenta las conclusiones de las actividades de supervision y revision.

h) Registrar las acciones e incidencias que pudieran aIectar a la eIicacia o al Iuncionamiento del SGSI (vase 4.3.3).

4.2.4 Mantenimiento y mejora del SGSI
Regularmente, la organizacion debe hacer lo que se indica a continuacion:

a) Implementar en el SGSI las mejoras identiIicadas.

b) Aplicar las medidas correctivas y preventivas adecuadas de acuerdo con los apartados 8.2 y 8.3, sobre la base de la
experiencia en materia de seguridad de la propia organizacion y de otras organizaciones.
- 13 - ISO/IEC 27001:2005
c) Comunicar las acciones y mejoras a todas las partes interesadas con un nivel de detalle acorde con las circunstancias.

d) Asegurar que las mejoras alcancen los objetivos previstos.
4.3 Requisitos de la documentacin

4.3.1 Generalidades
La documentacion debe incluir las decisiones de la Direccion junto con los registros (records) de las mismas, debiendo
quedar constancia de que las acciones dan respuesta a las decisiones y a las politicas adoptadas, y garantizando que
dichos documentos y los correspondientes registros estan disponibles.

NOTA NACIONAL 1 Segun recoge la Norma UNE-ISO 15489-1, el ingls posee tres trminos distintos (documents, records y archives), para
designar lo que en castellano, como en el resto de lenguas latinas, cuenta con una unica voz (documentos). Asi, document es
el equivalente de documento en su signiIicado genrico, como mera inIormacion registrada. Por el contrario, los trminos
records y archives designan de manera especiIica a aquellos documentos producidos como prueba y reIlejo de las actividades
de la organizacion que los ha creado, reservandose el empleo de este ultimo a los documentos de caracter historico.

NOTA NACIONAL 2 Un registro disponible es aqul que puede ser localizado, recuperado, presentado e interpretado.

Es importante poder demostrar la relacion de los controles seleccionados con los resultados de los procesos de
evaluacion y de tratamiento de riesgos y por tanto, con la politica y objetivos del SGSI.

La documentacion del SGSI debe incluir:
a) declaraciones documentadas de la politica |vase 4.2.1b)| y de los objetivos del SGSI;
b) el alcance del SGSI |vase 4.2.1a)|;
c) los procedimientos y mecanismos de control que soportan al SGSI;
d) una descripcion de la metodologia de evaluacion de riesgos |vase 4.2.1c)|;
e) el inIorme de evaluacion de riesgos |vase 4.2.1c) a 4.2.1 g)|;
I) el plan de tratamiento de riesgos |vase 4.2.2b)|;
g) los procedimientos documentados que necesita la organizacion para asegurar una correcta planiIicacion, operacion y
control de sus procesos de seguridad de la inIormacion, y para describir como medir la eIicacia de los controles
|vase 4.2.3 c)|;
h) los registros requeridos por esta norma internacional (vase 4.3.3); y
i) la declaracion de aplicabilidad.

NOTA 1 Cuando en esta norma internacional aparece el trmino 'procedimiento documentado, signiIica que el procedimiento se crea, se
documenta, se implementa y se mantiene.

NOTA 2 La extension de la documentacion del SGSI puede diIerir de una organizacion a otra debido a:
el tamao y tipo de actividades de la organizacion; y
el alcance y la complejidad de los requisitos de seguridad y del sistema que se esta gestionando.

NOTA 3 Los documentos y registros pueden estar en cualquier Iormato o tipo de medio.

4.3.2 Control de documentos
Los documentos exigidos por el SGSI (vase 4.3.1) deben estar protegidos y controlados. Se debe establecer un
procedimiento documentado para deIinir las acciones de gestion necesarias para:

a) aprobar en Iorma los documentos previamente a su distribucion;
ISO/IEC 27001:2005 - 14 -
b) revisar, actualizar y volver a aprobar los documentos, segun vaya siendo necesario;

c) asegurar que estan identiIicados los cambios, asi como el estado del documento que contiene la ultima revision;

d) asegurar que las versiones correspondientes de los documentos estan disponibles;

e) asegurar que los documentos permanecen legibles y Iacilmente identiIicables;

I) asegurar que los documentos estan disponibles para todo aquel que los necesita, y se transIieren, almacenan y se
destruyen de acuerdo con los procedimientos aplicables a su clasiIicacion;

g) asegurar que los documentos procedentes del exterior estan identiIicados;

h) asegurar que la distribucion de los documentos esta controlada;

i) prevenir el uso no intencionado de documentos obsoletos; y

j) aplicar una identiIicacion adecuada a los documentos obsoletos que son retenidos con algun proposito.

4.3.3 Control de registros
Se deben crear y mantener registros para proporcionar evidencias de la conIormidad con los requisitos y del Iunciona-
miento eIicaz del SGSI. Dichos registros deben esta protegidos y controlados. El SGSI debe tener en cuenta cualquier
requisito legal o regulatorio aplicable, asi como las obligaciones contractuales. Los registros deben permanecer legibles,
Iacilmente identiIicables y recuperables. Los controles necesarios para la identiIicacion, almacenamiento, proteccion,
recuperacion, retencion y disposicion de los registros deben estar documentados e implementados.

Deben conservarse los registros del desarrollo del proceso, segun se indica en 4.2, y de todos los sucesos derivados de
incidentes de seguridad signiIicativos relativos al SGSI.

EJEMPLO
Ejemplos de registros son: el libro de visitas, los inIormes de auditoria y los Iormularios de autorizacion de acceso cum-
plimentados.

5 RESPONSABILIDAD DE LA DIRECCIN

5.1 Compromiso de la Direccin
La Direccion debe suministrar evidencias de su compromiso para crear, implementar, operar, supervisar, revisar,
mantener y mejorar el SGSI, a travs de las siguientes acciones:
a) Iormulando la politica del SGSI;
b) velando por el establecimiento de los objetivos y planes del SGSI;
c) estableciendo los roles y responsabilidades en materia de seguridad de la inIormacion;
d) comunicando a la organizacion la importancia de cumplir los objetivos y la politica de seguridad de la inIormacion,
sus responsabilidades legales y la necesidad de la mejora continua;
e) proporcionando recursos suIicientes para crear, implementar, operar, supervisar, revisar, mantener y mejorar el
SGSI (vase 5.2.1);
I) decidiendo los criterios de aceptacion de riesgos y los niveles aceptables de riesgo;
g) velando por que se realicen las auditorias internas del SGSI (vase 6); y
h) dirigiendo las revisiones del SGSI (vase 7).
- 15 - ISO/IEC 27001:2005
5.2 Gestin de los recursos

5.2.1 Provisin de los recursos
La organizacion debe determinar y proporcionar los recursos necesarios para:
a) establecer, implementar, operar, supervisar, revisar, mantener y mejorar el SGSI;
b) asegurar que los procedimientos de seguridad de la inIormacion responden a los requisitos empresariales;
c) identiIicar y cumplir los requisitos legales y reglamentarios, asi como las obligaciones de seguridad contractuales;
d) mantener la seguridad adecuada mediante la aplicacion correcta de todos los controles implantados;
e) llevar a cabo revisiones, cuando sean necesarias, y reaccionar en base a los resultados de estas revisiones; y
I) cuando se requiera, mejorar la eIicacia del SGSI.

5.2.2 Concienciacin, formacin y capacitacin
La organizacion debe asegurarse de que todo el personal al que se le hayan asignado responsabilidades deIinidas en el
SGSI sea competente para llevar a cabo las tareas requeridas, a travs de:
a) determinar las competencias necesarias para el personal que lleva a cabo trabajos que aIecten al SGSI;
b) impartir Iormacion o realizar otras acciones (por ejemplo, la contratacion de personal competente) para satisIacer
estas necesidades;
c) evaluar la eIicacia de las acciones realizadas; y
d) mantener registros de educacion, Iormacion, aptitudes, experiencia y cualiIicaciones (vase 4.3.3).

La organizacion, debe asegurarse tambin de que todo el personal aIectado sea consciente de la trascendencia y de la
importancia de las actividades de seguridad de la inIormacion y de su contribucion a los objetivos del SGSI.

6 AUDITORIAS INTERNAS DEL SGSI
La organizacion debe realizar auditorias internas del SGSI a intervalos planiIicados, para determinar si los objetivos de
control, los controles, los procesos y los procedimientos de este SGSI:
a) cumplen los requisitos de esta norma internacional, asi como la legislacion y normativa aplicables;
b) cumplen los requisitos de seguridad de la inIormacion identiIicados;
c) se implantan y se mantienen de Iorma eIectiva; y
d) dan el resultado esperado.

Se debe planiIicar un programa de auditorias, teniendo en cuenta el estado e importancia de los procesos y las areas a
auditar, asi como los resultados de las auditorias previas. Se deben deIinir los criterios, el alcance, la Irecuencia y los
mtodos de auditoria. La seleccion de auditores y la direccion de las auditorias debe garantizar la objetividad e impar-
cialidad del proceso de auditoria. Los auditores no deben auditar su propio trabajo.

Las responsabilidades y los requisitos para la planiIicacion, realizacion de las auditorias, la inIormacion de los resul-
tados y el mantenimiento de los registros (vase 4.3.3), deben estar deIinidos en un procedimiento documentado.

El responsable del area auditada debe velar por que se realicen acciones para eliminar, sin demoras indebidas, las
disconIormidades detectadas y sus causas. Las actividades de seguimiento, deben incluir la veriIicacion de las acciones
realizadas y los inIormes de los resultados de la veriIicacion (vase 8).

NOTA La Norma ISO 19011:2002, Directrices para la auaitoria ae los sistemas ae gestion ae la caliaaa y/o ambiental, proporciona orientaciones
utiles para realizar las auditorias internas del SGSI.
ISO/IEC 27001:2005 - 16 -
7 REVISIN DEL SGSI POR LA DIRECCIN

7.1 Generalidades
La Direccion debe revisar el SGSI de la organizacion a intervalos planiIicados (al menos una vez al ao) para asegurar
que se mantiene su conveniencia, adecuacion y eIicacia. Esta revision debe contemplar las oportunidades de mejora y la
necesidad de cambios en el SGSI, incluyendo la politica y los objetivos de seguridad de la inIormacion. Los resultados
de las revisiones deben estar claramente documentados y se deben mantener los registros (vase 4.3.3).
7.2 Datos iniciales de la revisin
Los datos utilizados por la Direccion para la revision deben incluir:
a) los resultados de las auditorias y revisiones del SGSI;
b) los comentarios de las partes interesadas;
c) las tcnicas, productos o procedimientos que podrian utilizarse dentro de la organizacion para mejorar el
comportamiento y la eIicacia del SGSI;
d) el estado de las acciones preventivas o correctivas;
e) las vulnerabilidades o amenazas no abordadas adecuadamente en la evaluacion de riesgos previa;
I) los resultados de las mediciones de la eIicacia;
g) las acciones de seguimiento de las revisiones anteriores;
h) cualquier cambio que pudiera aIectar al SGSI; y
i) las recomendaciones de mejora.
7.3 Resultados de la revisin
Los resultados de la revision realizada por la Direccion deben incluir cualquier decision y accion relativas a :

a) la mejora de la eIicacia del SGSI;

b) la actualizacion de la evaluacion de riesgos y del plan de tratamiento de riesgos;

c) la modiIicacion de los procedimientos y controles que aIectan a la seguridad de la inIormacion, cuando sea
necesario para responder a los eventos internos o externos que pueden aIectar al SGSI, incluyendo los cambios en:
1) los requisitos del negocio;
2) los requisitos de seguridad;
3) los procesos de negocio que aIectan a los requisitos de negocio existentes;
4) los requisitos legales o reglamentarios;
5) las obligaciones contractuales; y
6) los niveles de riesgo y/o los criterios de aceptacion de los riesgos.

d) las necesidades de recursos;

e) la mejora en el modo de medir la eIicacia de los controles.
- 17 - ISO/IEC 27001:2005
8 ME1ORA DEL SGSI

8.1 Mejora continua
La organizacion debe mejorar de manera continua la eIicacia del SGSI, mediante el uso de la politica y de los objetivos
de seguridad de la inIormacion, de los resultados de las auditorias, del analisis de la monitorizacion de eventos, de las
acciones correctivas y preventivas y de las revisiones de la Direccion (vase 7).
La organizacion debe realizar acciones para eliminar la causa de las no conIormidades con los requisitos del SGSI, a Iin
de evitar que vuelvan a producirse. El procedimiento documentado para las acciones correctivas debe deIinir los requi-
sitos para:

a) identiIicar las no conIormidades;

b) determinar las causas de las no conIormidades;

c) evaluar la necesidad de adoptar acciones para asegurarse de que las no conIormidades no vuelvan a producirse;

d) determinar e implantar las acciones correctivas necesarias;

e) registrar los resultados de las acciones realizadas (vase 4.3.3); y

I) revisar las acciones correctivas realizadas.
8.3 Accin preventiva
La organizacion debe determinar las acciones necesarias para eliminar la causa de las posibles no conIormidades con
los requisitos del SGSI, para evitar que stas vuelvan a producirse. Las acciones preventivas adoptadas deben ser
apropiadas en relacion a los eIectos de los problemas potenciales. El procedimiento documentado para las acciones
preventivas debe deIinir los requisitos para:

a) identiIicar las posibles no conIormidades y sus causas;

b) evaluar la necesidad de adoptar acciones para prevenir la ocurrencia de no conIormidades;

c) determinar e implementar las acciones preventivas necesarias;

d) registrar los resultados de las acciones adoptadas (vase 4.3.3); y

e) revisar las acciones preventivas adoptadas.

La organizacion debe identiIicar los cambios en los riesgos, asi como los requisitos de las acciones preventivas, cen-
trando la atencion en los riesgos que hayan suIrido cambios signiIicativos.

La prioridad de las acciones preventivas debe determinarse basandose en los resultados de la evaluacion de riesgos.

NOTA Actuar para prevenir las no conIormidades suele ser mas rentable que realizar acciones correctivas.

ISO/IEC 27001:2005 - 18 -
ANEXO A (Normativo)

OB1ETIVOS DE CONTROL Y CONTROLES

Los objetivos de control y los controles indicados en la tabla A.1 tienen correspondencia directa con los establecidos en
la Norma ISO/IEC 17799:2005, capitulos 5 a 15. Las listas de la tabla A.1 no son exhaustivas y una organizacion puede
considerar que son necesarios objetivos de control y controles adicionales. Los objetivos de control y los controles que
Iiguran en estas tablas deben ser seleccionados como parte del proceso del SGSI especiIicado en el apartado 4.2.1.

Los capitulos 5 a 15 de la Norma ISO/IEC 17799:2005 oIrecen asesoramiento para la implantacion junto con una guia
de buenas practicas de apoyo a los controles especiIicados en los puntos A.5 hasta A.15.

Tabla A.1 Objetivos de control y controles

A.5 Poltica de seguridad
A.5.1 Poltica de seguridad de la informacin
Obfetivo: Proporcionar indicaciones para la gestion y soporte de la seguridad de la inIormacion de acuerdo con los
requisitos empresariales y con la legislacion y las normativas aplicables.
A.5.1.1
Documento de politica de seguridad de la
inIormacion
Control La Direccion debe aprobar un documento de po-
litica de seguridad de la inIormacion, publicarlo y distri-
buirlo a todos los empleados y terceros aIectados.
A.5.1.2
Revision de la politica de seguridad e la
inIormacion
Control La politica de seguridad de la inIormacion debe
revisarse a intervalos planiIicados o siempre que se pro-
duzcan cambios signiIicativos, a Iin de asegurar que se
mantenga su idoneidad, adecuacion y eIicacia.
A.6 Aspectos organizativos de la seguridad de la informacin
A..1 Organizacin interna
Obfetivo. Gestionar la seguridad de la inIormacion dentro de la organizacion.
A.6.1.1
Comit de gestion de seguridad de la
inIormacion.
Control La Direccion debe prestar un apoyo activo a la
seguridad dentro de la organizacion a travs de directrices
claras, un compromiso demostrado, asignaciones explicitas
y el reconocimiento de las responsabilidades de seguridad
de la inIormacion.
A.6.1.2
Coordinacion de la seguridad de la
inIormacion
Control Las actividades relativas a la seguridad de la in-
Iormacion deben ser coordinadas entre los representantes
de las diIerentes partes de la organizacion con sus corres-
pondientes roles y Iunciones de trabajo.
A.6.1.3 Asignacion de responsabilidades relativas a
la seguridad de la inIormacion
Control Deben deIinirse claramente todas las responsabi-
lidades relativas a la seguridad de la inIormacion.
A.6.1.4
Proceso de autorizacion de recursos para el
procesado de la inIormacion
Control Para cada nuevo recurso de procesado de la in-
Iormacion, debe deIinirse e implantarse un proceso de
autorizacion por parte de la Direccion.
A.6.1.5 Acuerdos de conIidencialidad
Control Debe determinarse y revisarse periodicamente la
necesidad de establecer acuerdos de conIidencialidad o no
revelacion, que reIlejen las necesidades de la organizacion
para la proteccion de la inIormacion.
- 19 - ISO/IEC 27001:2005
A.6.1.6
Contacto con las autoridades
Control Deben mantenerse los contactos adecuados con
las autoridades competentes.
A.6.1.7 Contacto con grupos de especial inters
Control Deben mantenerse los contactos apropiados con
grupos de inters especial, u otros Ioros, y asociaciones
proIesionales especializados en seguridad.
A.6.1.8
Revision independiente de la seguridad de
la inIormacion
Control El enIoque de la organizacion para la gestion de la
seguridad de la inIormacion y su implantacion (es decir,
los objetivos de control, los controles, las politicas, los
procesos y los procedimientos para la seguridad de la
inIormacion), debe someterse a una revision independiente
a intervalos planiIicados o siempre que se produzcan
cambios signiIicativos en la implantacion de la seguridad.
A..2 1erceros
Obfetivo. Mantener la seguridad de la inIormacion de la organizacion y de los dispositivos de procesado de la
inIormacion que son objeto de acceso, tratamiento, comunicacion o gestion por terceros.
A.6.2.1
IdentiIicacion de los riesgos derivados del
acceso de terceros
Control Deben identiIicarse los riesgos para la inIorma-
cion y para los dispositivos de procesado de la inIormacion
de la organizacion derivados de los procesos de negocio
que requieran de terceros, e implantar los controles
apropiados antes de otorgar el acceso.
A.6.2.2
Tratamiento de la seguridad en la relacion
con los clientes
Control Antes de otorgar acceso a los clientes a los activos
o a la inIormacion de la organizacion, deben tratarse todos
los requisitos de seguridad identiIicados.
A.6.2.3
Tratamiento de la seguridad en contratos
con terceros
Control Los acuerdos con terceros que conlleven acceso,
tratamiento, comunicacion o gestion, bien de la
inIormacion de la organizacion, o de los recursos de
tratamiento de la inIormacion, o bien la incorporacion de
productos o servicios a los recursos de tratamiento de la
inIormacion, deben cubrir todos los requisitos de seguridad
pertinentes.
A.7 Gestin de activos
A.7.1 Responsabilidad sobre los activos
Obfetivo. Conseguir y mantener una proteccion adecuada de los activos de la organizacion.
A.7.1.1 Inventario de activos
Control Todos los activos deben estar claramente identiIi-
cados y debe elaborarse y mantenerse un inventario de
todos los activos importantes.
A.7.1.2 Propiedad de los activos
Control Toda la inIormacion y activos asociados con los
recursos para el tratamiento de la inIormacion deben tener
un propietario
3)
que Iorme parte de la organizacion y haya
sido designado como propietario
A.7.1.3 Uso aceptable de los activos
Control Se deben identiIicar, documentar e implantar las
reglas para el uso aceptable de la inIormacion y los activos
asociados con los recursos para el procesado de la
inIormacion.

3) Explicacion: El trmino 'propietario se reIiere a la persona o entidad a la que se le ha asignado la responsabilidad administrativa del control de
la produccion, desarrollo, mantenimiento, uso y seguridad de los activos. El trmino 'propietario no signiIica que la persona tenga realmente
algun derecho de propiedad sobre el activo.
ISO/IEC 27001:2005 - 20 -
A.7.2 Clasificacin de la informacin
Obfetivo. Asegurar que la inIormacion recibe un nivel adecuado de proteccion.
A.7.2.1 Directrices de clasiIicacion
Control La inIormacion debe ser clasiIicada segun su
valor, los requisitos legales, la sensibilidad y la criticidad
para la organizacion.
A.7.2.2 Etiquetado y manipulado de la inIormacion
Control Se debe desarrollar e implantar un conjunto
adecuado de procedimientos para etiquetar y manejar la
inIormacion, de acuerdo con el esquema de clasiIicacion
adoptado por la organizacion.
A.8 Seguridad ligada a los recursos humanos
A.8.1 Antes del empleo
4)

Obfetivo. Asegurar que los empleados, los contratistas y los terceros entienden sus responsabilidades, y son adecuados
para llevar a cabo las Iunciones que les corresponden, asi como para reducir el riesgo de robo, Iraude o de uso
indebido de los recursos.
A.8.1.1 Funciones y responsabilidades
Control Las Iunciones y responsabilidades de seguridad de
los empleados, contratistas y terceros se deben deIinir y
documentar de acuerdo con la politica de seguridad de la
inIormacion de la organizacion.
A.8.1.2 Investigacion de antecedentes
Control La comprobacion de los antecedentes de todos los
candidatos al puesto de trabajo, de los contratistas o de los
terceros, se debe llevar a cabo de acuerdo con las legisla-
ciones, normativas y codigos ticos que sean de aplicacion
y de una manera proporcionada a los requisitos del
negocio, la clasiIicacion de la inIormacion a la que se
accede y los riesgos considerados.
A.8.1.3 Trminos y condiciones de contratacion
Control Como parte de sus obligaciones contractuales, los
empleados, los contratistas y los terceros deben aceptar y
Iirmar los trminos y condiciones de su contrato de trabajo,
que debe establecer sus responsabilidades y las de la or-
ganizacion en lo relativo a seguridad de la inIormacion.
A.8.2 Durante el empleo
Obfetivo. Asegurar que todos los empleados, contratistas y terceros son conscientes de las amenazas y problemas que
aIectan a la seguridad de la inIormacion y de sus responsabilidades y obligaciones, y de que estan preparados para
cumplir la politica de seguridad de la organizacion, en el desarrollo habitual de su trabajo, y para reducir el riesgo de
error humano.
A.8.2.1 Responsabilidades de la Direccion
Control La Direccion debe exigir a los empleados, con-
tratistas y terceros, que apliquen la seguridad de acuerdo
con las politicas y procedimientos establecidos en la
organizacion.
A.8.2.2
Concienciacion, Iormacion y capacitacion
en seguridad de la inIormacion
Control Todos los empleados de la organizacion y, cuando
corresponda, los contratistas y terceros, deben recibir una
adecuada concienciacion y Iormacion, con actualizaciones
periodicas, sobre las politicas y procedimientos de la orga-
nizacion, segun corresponda con su puesto de trabajo.

4) Explicacion: La palabra 'empleo utilizada en este documento hace reIerencia a distintas situaciones: contratacion de personal (temporal o de lar-
ga duracion), nombramiento de cargos, cambio de cargos, asignacion de contratistas, y terminacion de cualquiera de estos acuerdos o compro-
misos.
- 21 - ISO/IEC 27001:2005
A.8.2.3 Proceso disciplinario
Control Debe existir un proceso disciplinario Iormal para
los empleados que hayan provocado alguna violacion de la
seguridad.
A.8.3 Cese del empleo o cambio de puesto de trabajo
Obfetivo. Asegurar que los empleados, contratistas y terceros abandonan la organizacion o cambian de puesto de
trabajo de una manera ordenada.
A.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 deben estar
claramente deIinidas y asignadas.
A.8.3.2 Devolucion de activos
Control Todos los empleados, contratistas y terceros de-
ben devolver todos activos de la organizacion que estn en
su poder al Iinalizar su empleo, contrato o acuerdo.
A.8.3.3 Retirada de los derechos de acceso
Control Los derechos de acceso a la inIormacion y a los
recursos de tratamiento de la inIormacion de todos los
empleados, contratistas y terceros deben ser retirados a la
Iinalizacion del empleo, del contrato o del acuerdo, o bien
deben ser adaptados a los cambios producidos
A.9 Seguridad fsica y ambiental
A.9.1 reas seguras
Obfetivo. Prevenir los accesos Iisicos no autorizados, los daos y las intromisiones en las instalaciones y en la
inIormacion de la organizacion.
A.9.1.1 Perimetro de seguridad Iisica
Control Se deben utilizar perimetros de seguridad
(barreras, muros, puertas de entrada con control a travs de
tarjeta, o puestos de control) para proteger las areas que
contienen la inIormacion y los recursos de tratamiento de
la inIormacion.
A.9.1.2 Controles Iisicos de entrada
Control Las areas seguras deben estar protegidas por
controles de entrada adecuados, para asegurar que
unicamente se permite el acceso al personal autorizado.
A.9.1.3
Seguridad de oIicinas, despachos e
instalaciones
Control Se deben disear y aplicar las medidas de se-
guridad Iisica para las oIicinas, despachos e instalaciones.
A.9.1.4
Proteccion contra las amenazas externas y
de origen ambiental
Control Se debe disear y aplicar una proteccion Iisica
contra el dao causado por Iuego, inundacion, terremoto,
explosion, revueltas sociales y otras Iormas de desastres
naturales o provocados por el hombre.
A.9.1.5 Trabajo en areas seguras
Control Se deben disear e implantar una proteccion Iisica
y una serie de directrices para trabajar en las areas seguras.
A.9.1.6
Areas de acceso publico y de carga y
descarga
Control Deben controlarse los puntos de acceso tales
como las areas de carga y descarga y otros puntos, a travs
de los que personal no autorizado puede acceder a las
instalaciones, y si es posible, dichos puntos se deben aislar
de los recursos de tratamiento de la inIormacion para evitar
los accesos no autorizados.
A.9.2 Seguridad de los equipos
Obfetivo. Evitar prdidas, daos, robos o circunstancias que pongan en peligro los activos, o que puedan provocar la
interrupcion de las actividades de la organizacion.
ISO/IEC 27001:2005 - 22 -
A.9.2.1 Emplazamiento y proteccion de equipos
Control Los equipos deben situarse o protegerse de Iorma
que se reduzcan los riesgos derivados de las amenazas y
peligros de origen ambiental asi como las ocasiones de que
se produzcan accesos no autorizados.
A.9.2.2 Instalaciones de suministro
Control Los equipos deben estar protegidos contra Iallos
de alimentacion y otras anomalias causadas por Iallos en
las instalaciones de suministro.
A.9.2.3 Seguridad del cableado
Control El cableado elctrico y de telecomunicaciones que
transmite datos o que da soporte a los servicios de inIorma-
cion debe estar protegido Irente a interceptaciones o daos.
A.9.2.4 Mantenimiento de los equipos
Control Los equipos deben recibir un mantenimiento
correcto que asegure su disponibilidad y su integridad.
A.9.2.5
Seguridad de los equipos Iuera de las
instalaciones
Control Teniendo en cuenta los diIerentes riesgos que
conlleva trabajar Iuera de las instalaciones de la organiza-
cion, deben aplicarse medidas de seguridad a los equipos
situados Iuera dichas instalaciones.
A.9.2.6 Reutilizacion o retirada segura de equipos
Control Todos los soportes de almacenamiento deben ser
comprobados para conIirmar que todo dato sensible y todas
las licencias de soItware se han eliminado o bien se han
recargado de manera segura, antes de su retirada.
A.9.2.7
Retirada de materiales propiedad de la
empresa
Control Los equipos, la inIormacion o el soItware no
deben sacarse de las instalaciones, sin una autorizacion
previa.
A.10 Gestin de comunicaciones y operaciones
A.1.1 Responsabilidades y procedimientos de operacin
Obfetivo. Asegurar el Iuncionamiento correcto y seguro de los recursos de procesamiento de la inIormacion.
A.10.1.1
Documentacion de los procedimientos de
operacion
Control Deben documentarse y mantenerse los procedi-
mientos de operacion y ponerse a disposicion de todos los
usuarios que los necesiten.
A.10.1.2 Gestion de cambios
Control Deben controlarse los cambios en los recursos y
los sistemas de tratamiento de la inIormacion.
A.10.1.3 Segregacion de tareas
Control Las tareas y areas de responsabilidad deben
segregarse para reducir la posibilidad de que se produzcan
modiIicaciones no autorizadas o no intencionadas o usos
indebidos de los activos de la organizacion.
A.10.1.4
Separacion de los recursos de desarrollo,
prueba y operacion
Control Deben separarse los recursos de desarrollo, de
pruebas y de operacion, para reducir los riesgos de acceso
no autorizado o los cambios en el sistema operativo.
A.1.2 Cestin de la provisin de servicios por terceros
Obfetivo. Implantar y mantener el nivel apropiado de seguridad de la inIormacion en la provision del servicio, en con-
sonancia con los acuerdos de provision de servicios por terceros.
A.10.2.1 Provision de servicios
Control Se debe comprobar que los controles de seguri-
dad, las deIiniciones de los servicios y los niveles de provi-
sion, incluidos en el acuerdo de provision de servicios por
terceros, han sido implantados, puestos en operacion y son
mantenidos por parte de un tercero.
- 23 - ISO/IEC 27001:2005
A.10.2.2
Supervision y revision de los servicios
prestados por terceros
Control Los servicios, inIormes y registros proporciona-
dos por un tercero deben ser objeto de supervision y
revision periodicas, y tambin deben llevarse a cabo
auditorias periodicas.
A.10.2.3
Gestion de cambios en los servicios
prestados por terceros
Control Se deben gestionar los cambios en la provision de
los servicios, incluyendo el mantenimiento y la mejora de
las politicas, los procedimientos y los controles de seguri-
dad de la inIormacion existentes, teniendo en cuenta la
criticidad de los procesos y sistemas del negocio aIectados
asi como la reevaluacion de los riesgos.
A.1.3 Planificacin y aceptacin del sistema
Obfetivo. Minimizar el riesgo de Iallos de los sistemas.
A.10.3.1 Gestion de capacidades
Control La utilizacion de los recursos se debe supervisar y
ajustar asi como realizar proyecciones de los requisitos
Iuturos de capacidad, para garantizar el comportamiento
requerido del sistema.
A.10.3.2 Aceptacion del sistema
Control Se deben establecer los criterios para la acepta-
cion de nuevos sistemas de inIormacion, de las actualiza-
ciones y de nuevas versiones de los mismos, y se deben
llevar a cabo pruebas adecuadas de los sistemas durante el
desarrollo y previamente a la aceptacion.
A.1.4 Proteccin contra cdigo malicioso y descargable
Obfetivo. Proteger la integridad del soItware y de la inIormacion.
A.10.4.1 Controles contra el codigo malicioso
Control Se deben implantar los controles de deteccion,
prevencion y recuperacion que sirvan como proteccion
contra codigo malicioso y se deben implantar procedi-
mientos adecuados de concienciacion del usuario.
A.10.4.2
Controles contra el codigo descargado en el
cliente
Control Cuando se autorice el uso de codigo descargado
en el cliente, (JavaScript, VBScript, applets de Java
applets, controles ActiveX, etc..), la conIiguracion debe
garantizar que dicho codigo autorizado Iunciona de
acuerdo con una politica de seguridad claramente deIinida,
y se debe evitar que se ejecute el codigo no autorizado.
A.1.5 Copias de seguridad
Obfetivo. Mantener la integridad y disponibilidad de la inIormacion y de los recursos de tratamiento de la inIormacion.
A.10.5.1 Copias de seguridad de la inIormacion
Control Se deben realizar copias de seguridad de la inIor-
macion y del soItware, y se deben probar periodicamente
con conIorme a la politica de copias de seguridad acordada.
A.1. Cestin de la seguridad de las redes
Obfetivo. Asegurar la proteccion de la inIormacion en las redes y la proteccion de la inIraestructura de soporte.
A.10.6.1 Controles de red
Control Las redes deben estar adecuadamente gestionadas
y controladas, para que estn protegidas Irente a posibles
amenazas y para mantener la seguridad de los sistemas y
de las aplicaciones que utilizan estas redes, incluyendo la
inIormacion en transito.
ISO/IEC 27001:2005 - 24 -
A.10.6.2 Seguridad de los servicios de red
Control Se deben identiIicar las caracteristicas de seguri-
dad, los niveles de servicio, y los requisitos de gestion de
todos los servicios de red y se deben incluir en todo acuer-
do de servicios de red, tanto si estos servicios se prestan
dentro de la organizacion como si se subcontratan.
A.1.7 Manipulacin de los soportes
Obfetivo. Evitar la revelacion, modiIicacion, retirada o destruccion no autorizada de los activos, y la interrupcion de
las actividades de la organizacion.
A.10.7.1 Gestion de soportes extraibles
Control Se deben establecer procedimientos para la
gestion de los soportes extraibles.
A.10.7.2 Retirada de soportes
Control Los soportes deben ser retirados de Iorma segura
cuando ya no vayan a ser necesarios, mediante los proce-
dimientos Iormales establecidos.
A.10.7.3
Procedimientos de manipulacion de la
inIormacion
Control Deben establecerse procedimientos para la mani-
pulacion y el almacenamiento de la inIormacion, de modo
que se proteja dicha inIormacion contra la revelacion no
autorizada o el uso indebido.
A.10.7.4 Seguridad de la documentacion del sistema
Control La documentacion del sistema debe estar
protegida contra accesos no autorizados.
A.1.8 Intercambio de informacin
Obfetivo. Mantener la seguridad de la inIormacion y del soItware intercambiados dentro de una organizacion y con un
tercero
A.10.8.1
Politicas y procedimientos de intercambio
de inIormacion
Control Deben establecerse politicas, procedimientos y
controles Iormales que protejan el intercambio de inIor-
macion mediante el uso de todo tipo de recursos de
comunicacion.
A.10.8.2 Acuerdos de intercambio
Control Deben establecerse acuerdos para el intercambio
de inIormacion y del soItware entre la organizacion y los
terceros.
A.10.8.3 Soportes Iisicos en transito
Control Durante el transporte Iuera de los limites Iisicos
de la organizacion, los soportes que contengan inIormacion
deben estar protegidos contra accesos no autorizados, usos
indebidos o deterioro.
A.10.8.4 Mensajeria electronica
Control La inIormacion que sea objeto de mensajeria
electronica debe estar adecuadamente protegida.
A.10.8.5 Sistemas de inIormacion empresariales
Control Deben Iormularse e implantarse politicas y pro-
cedimientos para proteger la inIormacion asociada a la
interconexion de los sistemas de inIormacion empresariales
A.1.9 Servicios de comercio electrnico
Obfetivo. Garantizar la seguridad de los servicios de comercio electronico, y el uso seguro de los mismos
A.10.9.1 Comercio electronico
Control La inIormacion incluida en el comercio electro-
nico que se transmita a travs de redes publicas debe pro-
tegerse contra las actividades Iraudulentas, las disputas
contractuales, y la revelacion o modiIicacion no autorizada
de dicha inIormacion.
- 25 - ISO/IEC 27001:2005
A.10.9.2 Transacciones en linea
Control La inIormacion contenida en las transacciones en
linea debe estar protegida para evitar transmisiones incom-
pletas, errores de direccionamiento, alteraciones no autori-
zadas de los mensajes, la revelacion, la duplicacion o la
reproduccion no autorizadas del mensaje.
A.10.9.3 InIormacion puesta a disposicion publica
Control La integridad de la inIormacion puesta a disposi-
cion publica se debe proteger para evitar modiIicaciones no
autorizadas.
A.1.1 Supervisin
Obfetivo. Detectar las actividades de procesamiento de la inIormacion no autorizadas.
A.10.10.1 Registro de auditorias
Control Se deben realizar registros de auditoria de las
actividades de los usuarios, las excepciones y eventos de
seguridad de la inIormacion, y se deben mantener estos
registros durante un periodo acordado para servir como
prueba en investigaciones Iuturas y en la supervision del
control de acceso.
A.10.10.2 Supervision del uso del sistema
Control Se deben establecer procedimientos para supervi-
sar el uso de los recursos de procesamiento de la
inIormacion y se deben revisar periodicamente los
resultados de las actividades de supervision.
A.10.10.3
Proteccion de la inIormacion de los
registros
Control Los dispositivos de registro y la inIormacion de
los registros deben estar protegidos contra manipulaciones
indebidas y accesos no autorizados.
A.10.10.4 Registros de administracion y operacion
Control Se deben registrar las actividades del
administrador del sistema y de la operacion del sistema.
A.10.10.5 Registro de Iallos
Control Los Iallos deben ser registrados y analizados y se
deben tomar las correspondientes acciones
A.10.10.6 Sincronizacion del reloj
Control Los relojes de todos los sistemas de
procesamiento de la inIormacion dentro de una
organizacion o de un dominio de seguridad, deben estar
sincronizados con una precision de tiempo acordada.
A.11 Control de acceso
A.11.1 Requisitos de negocio para el control de acceso
Obfetivo. Controlar el acceso a la inIormacion
A.11.1.1 Politica de control de acceso
Control Se debe establecer, documentar y revisar una
politica de control de acceso basada en los requisitos
empresariales y de seguridad para el acceso.
A.11.2 Cestin de acceso de usuario
Obfetivo. Asegurar el acceso de un usuario autorizado y prevenir el acceso no autorizado a los sistemas de inIormacion
A.11.2.1 Registro de usuario
Control Debe establecerse un procedimiento Iormal de
registro y de anulacion de usuarios para conceder y revocar
el acceso a todos los sistemas y servicios de inIormacion.
A.11.2.2 Gestion de privilegios
Control La asignacion y el uso de privilegios deben estar
restringidos y controlados.
A.11.2.3 Gestion de contraseas de usuario
Control La asignacion de contraseas debe ser controlada
a travs de un proceso de gestion Iormal
ISO/IEC 27001:2005 - 26 -
A.11.2.4
Revision de los derechos de acceso de
usuario
Control La Direccion debe revisar los derechos de acceso
de usuario a intervalos regulares y utilizando un proceso
Iormal.
A.11.3 Responsabilidades de usuario
Obfetivo. Prevenir el acceso de usuarios no autorizados, asi como evitar el que se comprometa o se produzca el robo
de la inIormacion o de los recursos de procesamiento de la inIormacion
A.11.3.1 Uso de contrasea
Control Se debe requerir a los usuarios el seguir las
buenas practicas de seguridad en la seleccion y el uso de
las contraseas.
A.11.3.2 Equipo de usuario desatendido
Control Los usuarios deben asegurarse de que el equipo
desatendido tiene la proteccion adecuada.
A.11.3.3
Politica de puesto de trabajo despejado y
pantalla limpia
Control Debe adoptarse una politica de puesto de trabajo
despejado de papeles y de soportes de almacenamiento
extraibles junto con una politica de pantalla limpia para los
recursos de procesamiento de la inIormacion.
A.11.4 Control de acceso a la red
Obfetivo. Prevenir el acceso no autorizado a los servicios en red.
A.11.4.1 Politica de uso de los servicios en red
Control Se debe proporcionar a los usuarios unicamente el
acceso a los servicios para que los que hayan sido
especiIicamente autorizados.
A.11.4.2
Autenticacion de usuario para conexiones
externas
Control Se deben utilizar los mtodos apropiados de
autenticacion para controlar el acceso de los usuarios
remotos.
A.11.4.3 IdentiIicacion de los equipos en las redes
Control La identiIicacion automatica de los equipos se
debe considerar como un medio de autenticacion de las
conexiones provenientes de localizaciones y equipos
especiIicos.
A.11.4.4
Diagnostico remoto y proteccion de los
puertos de conIiguracion
Control Se debe controlar el acceso Iisico y logico a los
puertos de diagnostico y de conIiguracion.
A.11.4.5 Segregacion de las redes
Control Los grupos de servicios de inIormacion, usuarios
y sistemas de inIormacion deben estar segregados en redes.
A.11.4.6 Control de la conexion a la red
Control En redes compartidas, especialmente en aquellas
que traspasen las Ironteras de la organizacion, debe res-
tringirse la capacidad de los usuarios para conectarse a la
red, esto debe hacerse de acuerdo a la politica de control de
acceso y a los requisitos de las aplicaciones del negocio
(vase 11.1).
A.11.4.7 Control de encaminamiento (routing) de red
Control Se deben implantar controles de encaminamiento
(routing) de redes para asegurar que las conexiones de los
ordenadores y los Ilujos de inIormacion no violan la politi-
ca de control de acceso de las aplicaciones empresariales.
A.11.5 Control de acceso al sistema operativo
Obfetivo. Prevenir el acceso no autorizado a los sistemas operativos.
A.11.5.1 Procedimientos seguros de inicio de sesion
Control El acceso a los sistemas operativos se debe con-
trolar por medio de un procedimiento seguro de inicio de
sesion.
- 27 - ISO/IEC 27001:2005
A.11.5.2 IdentiIicacion y autenticacion de usuario
Control Todos los usuarios deben tener un identiIicador
unico (ID de usuario) para su uso personal y exclusivo, y
se debe elegir una tcnica adecuada de autenticacion para
conIirmar la identidad solicitada del usuario.
A.11.5.3 Sistema de gestion de contraseas
Control Los sistemas para la gestion de contraseas deben
ser interactivos y establecer contraseas seguras y robustas.
A.11.5.4 Uso de los recursos del sistema
Control Se debe restringir y controlar rigurosamente el uso
de programas y utilidades que puedan ser capaces de inva-
lidar los controles del sistema y de la aplicacion.
A.11.5.5 Desconexion automatica de sesion.
Control Las sesiones inactivas deben cerrarse despus de
un periodo de inactividad deIinido.
A.11.5.6 Limitacion del tiempo de conexion
Control Para proporcionar seguridad adicional a las aplica-
ciones de alto riesgo, se deben utilizar restricciones en los
tiempos de conexion.
A.11. Control de acceso a las aplicaciones y a la informacin
Obfetivo. Prevenir el acceso no autorizado a la inIormacion que contienen las aplicaciones
A.11.6.1 Restriccion del acceso a la inIormacion
Control Se debe restringir el acceso a la inIormacion y a
las aplicaciones a los usuarios y al personal de soporte, de
acuerdo con la politica de control de acceso deIinida.
A.11.6.2 Aislamiento de sistemas sensibles
Control Los sistemas sensibles deben tener un entorno de
ordenadores dedicados (aislados).
A.11.7 Ordenadores porttiles y teletrabajo
Obfetivo. Garantizar la seguridad de la inIormacion cuando se utilizan ordenadores portatiles y servicios de teletrabajo.
A.11.7.1
Ordenadores portatiles y comunicaciones
moviles
Control Se debe implantar una politica Iormal y se deben
adoptar las medidas de seguridad adecuadas de proteccion
contra los riesgos de la utilizacion de ordenadores portati-
les y comunicaciones moviles.
A.11.7.2 Teletrabajo
Control Se debe redactar e implantar, una politica de acti-
vidades de teletrabajo, asi como los planes y procedimien-
tos de operacion correspondientes.
A.12 Adquisicin, desarrollo y mantenimiento de los sistemas de informacin
A.12.1 Requisitos de seguridad de los sistemas de informacin
Obfetivo. Garantizar que la seguridad esta integrada en los sistemas de inIormacion.
A.12.1.1
Analisis y especiIicacion de los requisitos
de seguridad
Control En las declaraciones de los requisitos de negocio
para los nuevos sistemas de inIormacion, o para mejoras de
los sistemas de inIormacion ya existentes, se deben especi-
Iicar los requisitos de los controles de seguridad.
A.12.2 1ratamiento correcto de las aplicaciones
Obfetivo. Evitar errores, prdidas, modiIicaciones no autorizadas o usos indebidos de la inIormacion en las aplicaciones
A.12.2.1 Validacion de los datos de entrada
Control La introduccion de datos en las aplicaciones debe
validarse para garantizar que dichos datos son correctos y
adecuados.
ISO/IEC 27001:2005 - 28 -
A.12.2.2 Control del procesamiento interno
Control Para detectar cualquier corrupcion de la inIor-
macion debida a errores de procesamiento o actos intencio-
nados, se deben incorporar comprobaciones de validacion
en las aplicaciones.
A.12.2.3 Integridad de los mensajes
Control Se deben identiIicar los requisitos para garantizar
la autenticidad y para proteger la integridad de los mensa-
jes en las aplicaciones y se deben identiIicar e implantar
los controles adecuados.
A.12.2.4 Validacion de los datos de salida
Control Los datos de salida de una aplicacion se deben
validar para garantizar que el tratamiento de la inIormacion
almacenada es correcto y adecuado a las circunstancias.
A.12.3 Controles criptogrficos
Obfetivo. Proteger la conIidencialidad, la autenticidad o la integridad de la inIormacion por medios criptograIicos.
A.12.3.1
Politica de uso de los controles
criptograIicos
Control Se debe Iormular e implantar una politica para el
uso de los controles criptograIicos para proteger la
inIormacion.
A.12.3.2 Gestion de claves
Control Debe implantarse un sistema de gestion de claves
para dar soporte al uso de tcnicas criptograIicas por parte
de la organizacion.
A.12.4 Seguridad de los archivos de sistema
Obfetivo. Garantizar la seguridad de los archivos de sistema.
A.12.4.1 Control del soItware en explotacion
Control Deben estar implantados procedimientos para
controlar la instalacion de soItware en los sistemas
operativos.
A.12.4.2
Proteccion de los datos de prueba del
sistema
Control Los datos de prueba se deben seleccionar con
cuidado y deben estar protegidos y controlados.
A.12.4.3
Control de acceso al codigo Iuente de los
programas
Control Se debe restringir el acceso al codigo Iuente de los
programas.
A.12.5 Seguridad en los procesos de desarrollo y soporte
Obfetivo. Mantener la seguridad del soItware y de la inIormacion de las aplicaciones
A.12.5.1 Procedimientos de control de cambios
Control La implantacion de cambios debe controlarse
mediante el uso de procedimientos Iormales de control de
cambios.
A.12.5.2
Revision tcnica de las aplicaciones tras
eIectuar cambios en el sistema operativo
Control Cuando se modiIiquen los sistemas operativos, las
aplicaciones empresariales criticas deben ser revisadas y
probadas para garantizar que no existen eIectos adversos
en las operaciones o en la seguridad de la organizacion.
A.12.5.3
Restricciones a los cambios en los paquetes
de soItware
Control Se deben desaconsejar las modiIicaciones en los
paquetes de soItware, limitandose a los cambios
necesarios, y todos los cambios deben ser objeto de un
control riguroso.
A.12.5.4 Fugas de inIormacion
Control Deben evitarse las situaciones que permitan que
se produzcan Iugas de inIormacion.
A.12.5.5 Externalizacion del desarrollo de soItware
Control La externalizacion del desarrollo de soItware debe
ser supervisada y controlada por la organizacion.
- 29 - ISO/IEC 27001:2005
A.12. Cestin de la vulnerabilidad tcnica
Obfetivo. Reducir los riesgos resultantes de la explotacion de las vulnerabilidades tcnicas publicadas.
A.12.6.1 Control de las vulnerabilidades tcnicas
Control Se debe obtener inIormacion oportuna acerca de
las vulnerabilidades tcnicas de los sistemas de inIorma-
cion que estan siendo utilizados, evaluar la exposicion de
la organizacion a dichas vulnerabilidades y adoptar las
medidas adecuadas para aIrontar el riesgo asociado.
A.13 Gestin de incidentes de seguridad de la informacin
A.13.1 Aotificacin de eventos y puntos dbiles de la seguridad de la informacin
Obfetivo. Asegurarse de que los eventos y las vulnerabilidades de la seguridad de la inIormacion, asociados con los
sistemas de inIormacion, se comunican de manera que sea posible emprender las acciones correctivas oportunas.
A.13.1.1
NotiIicacion de los eventos de seguridad de
la inIormacion
Control Los eventos de seguridad de la inIormacion se
deben notiIicar a travs de los canales adecuados de
gestion lo antes posible.
A.13.1.2
NotiIicacion de los puntos dbiles de la
seguridad
Control Todos los empleados, contratistas, y terceros que
sean usuarios de los sistemas y servicios de inIormacion
deben estar obligados a anotar y notiIicar cualquier punto
dbil que observen o que sospechen exista, en dichos
sistemas o servicios.
A.13.2 Cestin de incidentes de seguridad de la informacin y mejoras
Obfetivo. Garantizar que se aplica un enIoque coherente y eIectivo a la gestion de los incidentes de seguridad de la
inIormacion.
A.13.2.1 Responsabilidades y procedimientos
Control Se deben establecer las responsabilidades y
procedimientos de gestion para garantizar una respuesta
rapida, eIectiva y ordenada a los incidentes de seguridad de
la inIormacion.
A.13.2.2
Aprendizaje de los incidentes de seguridad
de la inIormacion
Control Deben existir mecanismos que permitan cuanti-
Iicar y supervisar los tipos, volumenes y costes de los
incidentes de seguridad de la inIormacion.
A.13.2.3 Recopilacion de evidencias
Control Cuando se emprenda una accion contra una per-
sona u organizacion, despus de un incidente de seguridad
de la inIormacion, que implique acciones legales (tanto
civiles como penales), deben recopilarse las evidencias,
conservarse y presentarse conIorme a las normas
establecidas en la jurisdiccion correspondiente.
A.14 Gestin de la continuidad del negocio
A.14.1 Aspectos de seguridad de la informacin en la gestin de la continuidad del negocio
Obfetivo. Contrarrestar las interrupciones de las actividades empresariales y proteger los procesos criticos de negocio
de los eIectos derivados de Iallos importantes o catastroIicos de los sistemas de inIormacion, asi como garantizar su
oportuna reanudacion
A.14.1.1
Inclusion de la seguridad de la inIormacion
en el proceso de gestion de la continuidad
del negocio
Control Debe desarrollarse y mantenerse un proceso para
la continuidad del negocio en toda la organizacion, que
gestione los requisitos de seguridad de la inIormacion
necesarios para la continuidad del negocio.
ISO/IEC 27001:2005 - 30 -
A.14.1.2
Continuidad del negocio y evaluacion de
riesgos
Control Deben identiIicarse los eventos que puedan causar
interrupciones en los procesos de negocio, asi como la pro-
babilidad de que se produzcan tales interrupciones, sus eIec-
tos y sus consecuencias para la seguridad de la inIormacion.
A.14.1.3
Desarrollo e implantacion de planes de
continuidad que incluyan la seguridad de la
inIormacion
Control Deben desarrollarse e implantarse planes para
mantener o restaurar las operaciones y garantizar la
disponibilidad de la inIormacion en el nivel y en el tiempo
requeridos, despus de una interrupcion o un Iallo de los
procesos de negocio criticos.
A.14.1.4
Marco de reIerencia para la planiIicacion de
la continuidad del negocio
Control Debe mantenerse un unico marco de reIerencia
para los planes de continuidad del negocio, para asegurar
que todos los planes sean coherentes, para cumplir los
requisitos de seguridad de la inIormacion de manera
consistente y para identiIicar las prioridades de realizacion
de pruebas y de mantenimiento.
A.14.1.5
Pruebas, mantenimiento y reevaluacion de
los planes de continuidad del negocio
Control Los planes de continuidad del negocio deben
probarse y actualizarse periodicamente para asegurar que
estan al dia y que son eIectivos.
A.15 Cumplimiento
A.15.1 Cumplimiento de los requisitos legales
Obfetivo. Evitar incumplimientos de las leyes o de las obligaciones legales, reglamentarias o contractuales y de los
requisitos de seguridad.
A.15.1.1 IdentiIicacion de la legislacion aplicable
Control Todos los requisitos pertinentes, tanto legales como
reglamentarios o contractuales, y el enIoque de la organiza-
cion para cumplir dichos requisitos, deben estar deIinidos,
documentados y mantenerse actualizados de Iorma explicito
para cada sistema de inIormacion de la organizacion.
A.15.1.2
Derechos de propiedad intelectual (DPI)
|Intellectual Property Rights (IPR)|
Control Deben implantarse procedimientos adecuados para
garantizar el cumplimiento de los requisitos legales, regla-
mentarios y contractuales sobre el uso de material, con res-
pecto al cual puedan existir derechos de propiedad intelec-
tual y sobre el uso de productos de soItware/propietario.
A.15.1.3
Proteccion de los documentos
3)
de la
organizacion
Control Los documentos importantes deben estar protegi-
dos contra la prdida, destruccion y IalsiIicacion de acuer-
do con los requisitos legales, regulatorios, contractuales y
empresariales.
A.15.1.4
Proteccion de datos y privacidad de la
inIormacion personal
Control Debe garantizarse la proteccion y la privacidad de
los datos segun se requiera en la legislacion y las regulacio-
nes y, en su caso, en las clausulas contractuales pertinentes.
A.15.1.5
Prevencion del uso indebido de los recursos
de tratamiento de la inIormacion
Control Se debe impedir que los usuarios utilicen los
recursos de tratamiento de la inIormacion para Iines no
autorizados.

3) NOTA NACIONAL Segun recoge la Norma UNE-ISO 15489-1, el ingls posee tres trminos distintos (documents, records y archives), para
designar lo que en castellano, como en el resto de lenguas latinas, cuenta con una unica voz (documentos). Asi, document es
el equivalente de documento en su signiIicado genrico, como mera inIormacion registrada. Por el contrario, los trminos
records y archives designan de manera especiIica a aquellos documentos producidos como prueba y reIlejo de las
actividades de la organizacion que los ha creado, reservandose el empleo de este ultimo a los documentos de caracter
historico.
- 31 - ISO/IEC 27001:2005
A.15.1.6 Regulacion de los controles criptograIicos
Control Los controles criptograIicos se deben utilizar de
acuerdo con todos los contratos, leyes y regulaciones
pertinentes.
A.15.2 Cumplimiento de las polticas y normas de seguridad y cumplimiento tcnico
Obfetivo. Asegurar que los sistemas cumplen las politicas y normas de seguridad de la organizacion.
A.15.2.1
Cumplimiento de las politicas y normas de
seguridad
Control Los directores deben asegurarse de que todos los
procedimientos de seguridad dentro de su area de responsa-
bilidad se realizan correctamente con el Iin de cumplir las
politicas y normas de seguridad.
A.15.2.2 Comprobacion del cumplimiento tcnico
Control Debe comprobarse periodicamente que los siste-
mas de inIormacion cumplen las normas de aplicacion de
la seguridad.
A.15.3 Consideraciones sobre la auditoria de los sistemas de informacin
Obfetivo. Lograr que el proceso de auditoria de los sistemas de inIormacion alcance la maxima eIicacia con las mini-
mas interIerencias.
A.15.3.1
Controles de auditoria de los sistemas de
inIormacion
Control Los requisitos y las actividades de auditoria que
impliquen comprobaciones en los sistemas operativos de-
ben ser cuidadosamente planiIicados y acordados para
minimizar el riesgo de interrupciones en los procesos de
empresariales.
A.15.3.2
Proteccion de las herramientas de auditoria
de los sistemas de inIormacion
Control El acceso a las herramientas de auditoria de los
sistemas de inIormacion debe estar protegido para evitar
cualquier posible peligro o uso indebido.

ISO/IEC 27001:2005 - 32 -
ANEXO B (InIormativo)

LOS PRINCIPIOS DE LA OCDE Y ESTA NORMA INTERNACIONAL

Los principios recogidos en las Directrices de la OCDE para la seguridad de los sistemas y redes de inIormacion se
aplican a todas las politicas y a todos los niveles de operacion que rigen la seguridad de los sistemas y redes de
inIormacion. Esta norma internacional constituye el marco del sistema de gestion de la seguridad de la inIormacion para
implementar algunos de los principios de la OCDE utilizando el modelo PDCA y los procesos descritos en los capitu-
los 4, 5, 6 y 8, segun se indica en la tabla B.1.

Tabla B.1 Los principios de la OCDE y el modelo PDCA

Principio de la OCDE Proceso del SGSI y fase del PDCA correspondientes
Concienciacin
Los participantes deben concienciarse de la necesidad de ga-
rantizar la seguridad de los sistemas y redes de inIormacion y
saber qu pueden hacer ellos para mejorar la seguridad
Esta actividad es parte de la Iase Hacer (Do)
(vanse 4.2.2 y 5.2.2).
Responsabilidad
Todos los participantes son responsables de la seguridad de
los sistemas y redes de inIormacion.
Esta actividad es parte de la Iase Hacer (Do)
(vanse 4.2.2 y 5.1).
Respuesta
Los participantes deben actuar de Iorma oportuna y
coordinada para prevenir, detectar y responder a los
incidentes de seguridad.
Esto es en parte una actividad de supervision de la Iase
Verificar (Check) (vase 4.2.3 y 6 a 7.3) y una acti-
vidad de respuesta de la Iase Actuar (Act) (vase 4.2.4
y 8.1 a 8.3). Tambin puede tener que ver con algunos
aspectos de las Iases Planificar (Plan) y Verificar
(Check).
Los participantes deben llevar a cabo evaluaciones de
riesgos.
Esta actividad es parte de la Iase Planificar (Plan)
(vase 4.2.1) y la reevaluacion del riesgo es parte de la
Iase Verificar (Check) (vase 4.2.3 y 6 a 7.3).
Diseo e implantacin de la seguridad
Los participantes deben incorporar la seguridad como un
elemento esencial de los sistemas y redes de inIormacion
Una vez que Iinalizada la evaluacion de riesgos, se se-
leccionan los controles para el tratamiento de los riesgos
como parte de la Iase Planificar (Plan) (vase 4.2.1). La
Iase Hacer (Do) (vase 4.2.2 y 5.2) comprende la
implantacion y el uso operativo de estos controles.
Gestin de la seguridad
Los participantes deben adoptar criterios detallados de
mantenimiento, revision y auditoria.
La gestion del riesgo es un proceso que incluye la
prevencion, deteccion y respuesta a los incidentes, y la
gestion continuada de la seguridad. Todos estos aspectos
estan comprendidos en las Iases Planificar (Plan),
Hacer (Do), Verificar (Check) y Actuar (Act).
Reevaluacin
Los participantes deben revisar y reevaluar la seguridad de
los sistemas y redes de inIormacion, y eIectuar las
modiIicaciones apropiadas de las politicas, practicas,
medidas y procedimientos de seguridad
La reevaluacion de la seguridad de la inIormacion es
parte de la Iase Verificar (Check) (vase 4.2.3 y 6 a
7.3), en la cual deben llevarse a cabo revisiones perio-
dicas para comprobar la eIicacia del sistema de gestion
de seguridad de la inIormacion, y la mejora de la segu-
ridad es parte de la Iase Actuar (Act) (vase 4.2.4 y 8.1
a 8.3).
- 33 - ISO/IEC 27001:2005
ANEXO C (InIormativo)

CORRESPONDENCIA ENTRE LAS NORMAS ISO 9001:2000, ISO 14001:2004
Y ESTA NORMA INTERNACIONAL

La tabla C.1 muestra la correspondencia entre las normas ISO 9001:2000 e ISO 14001:2004 y esta norma internacional.

Tabla C.1 Correspondencia entre las normas ISO 9001:2000 e ISO 14001:2004 y esta norma internacional

Esta norma internacional ISO 9001:2000 ISO 14001:2004
0 Introduccin 0 Introduccin Introduccin
0.1 Generalidades 0.1 Generalidades
0.2 EnIoque del proceso 0.2 EnIoque del proceso
0.3 Relacion con la Norma ISO 9004
0.3 Compatibilidad con otros
sistemas de gestion
0.4 Compatibilidad con otros sistemas
de gestion

1 Objeto y campo de aplicacin 1 Objeto y campo de aplicacin 1 Objeto y campo de aplicacin
1.1 Generalidades 1.1 Generalidades
1.2 Aplicacion 1.2 Aplicacion
2 Normas para consulta 2 Normas para consulta 2 Normas para consulta
3 Trminos y definiciones 3 Trminos y definiciones 3 Trminos y definiciones
4 Seguridad de la informacin 4 Sistema de gestin de la calidad 4 Sistema de gestin de los requi-
sitos del SGA
4.1 Requisitos generales 4.1 Requisitos generales 4.1 Requisitos generales
4.2 Creacion y gestion del SGSI
4.2.1 Creacion del SGSI
4.2.2 Implantacion y operacion del
SGSI
4.4 Implantacion y operacion
4.2.3 Supervision y revision del
SGSI
8.2.3 Supervision y medicion de los
procesos
4.5.1 Supervision y medicion
8.2.4 Supervision y medicion del
producto

4.2.4 Mantenimiento y mejora del
SGSI

4.3 Requisitos de la documentacion 4.2 Requisitos de documentacion
4.3.1 Generalidades 4.2.1 Generalidades
4.2.2 Manual de calidad
4.3.2 Control de documentos 4.2.3 Control de documentos 4.4.5 Control de documentacion
4.3.3 Control de registros 4.2.4 Control de registros 4.5.4 Control de registros
ISO/IEC 27001:2005 - 34 -
Esta norma internacional ISO 9001:2000 ISO 14001:2004
5 Responsabilidad de la Direccin 5 Responsabilidad de la Direccin
5.1 Compromiso de la Direccion 5.1 Compromiso de la Direccion
5.2 Orientacion al cliente
5.3 Politica de calidad 4.2 Politica ambiental
5.4 PlaniIicacion 4.3 PlaniIicacion
5.5 Responsabilidad, autoridad y
comunicacion

5.2 Gestion de los recursos 6 Gestin de los recursos
5.2.1 Provision de los recursos 6.1 Provision de los recursos
6.2 Recursos humanos
5.2.2 Concienciacion, Iormacion y
competencia
6.2.2 Competencia, concienciacion y
Iormacion
4.4.2 Competencia, Iormacion, y
concienciacion
6.3 InIraestructura
6.4 Entorno de trabajo
6 Auditoras internas del SGSI 8.2.2 Auditoria interna 4.5.5 Auditoria interna
7 Revisin del SGSI por la
Direccin
5.6 Revisin por la Direccin 4.6 Revisin por la Direccin
7.1 Generalidades 5.6.1 Generalidades
7.2 Datos iniciales de la revision 5.6.2 Datos iniciales de la revision
7.3 Resultados de la revision 5.6.3 Resultados de la revision
8 Mejora del SGSI 8.5 Mejora
8.1 Mejora continua 8.5.1 Mejora continua
8.2 Accion correctiva 8.5.3 Acciones correctivas 4.5.3 DisconIormidad, accion
correctiva y accion preventiva
8.3 Accion preventiva 8.5.3 Acciones preventivas
Anexo A Objetivos de control y
controles
Anexo A Gua de uso de esta
norma internacional
Anexo B Los principios de la
OCDE y esta norma internacional

Anexo C Correspondencia entre
las Normas ISO 9001:2000 e
ISO 14001:2004 y esta norma
internacional
Anexo A Correspondencia entre las
Normas ISO 9001:2000 e
ISO 14001:1996
Anexo B Correspondencia entre
las Normas ISO 14001:2004 e
ISO 9001:2000

- 35 - ISO/IEC 27001:2005
BIBLIOGRAFIA

Publicaciones de normas

|1| ISO 9001:2000 Sistemas ae gestion ae la caliaaa. Requisitos.

|2| ISO/IEC 13335-1:2004 Tecnologias ae la informacion. Tecnicas ae seguriaaa. Gestion ae la seguriaaa ae las
tecnologias ae la informacion y las comunicaciones. Parte 1. Conceptos y moaelos para la gestion ae la seguri-
aaa ae las tecnologias ae la informacion y las comunicaciones.

|3| ISO/IEC TR 13335-3:1998 Tecnologias ae la informacion. Directrices para la gestion ae la seguriaaa ae las TI.
Parte 3. Tecnicas para la gestion ae la seguriaaa ae las TI.

|4| ISO/IEC TR 13335-4:2000 Tecnologias ae la informacion. Directrices para la gestion ae la seguriaaa ae las TI.
Parte 4. Seleccion ae salvaguaraias.

|5| ISO 14001:2004 Sistemas ae gestion ambiental. Requisitos y orientaciones ae uso.

|6| ISO/IEC TR 18044:2004 Tecnologias ae la informacion. Tecnicas ae seguriaaa. Gestion ae inciaentes ae
seguriaaa ae la informacion.

|7| ISO 19011:2002 Directrices para auaitorias ae caliaaa o ae sistemas ae gestion ambiental.

|8| ISO/IEC Guia 62:1996 Requisitos generales para entiaaaes encargaaas ae la evaluacion y certificacion o
registro ae sistemas ae caliaaa.

|9| ISO/IEC Guia 73:2002 Gestion ae riesgos. Jocabulario. Directrices ae uso en normas.

Otras publicaciones

|1| OCDE, Directrices para la seguriaaa ae los sistemas y reaes ae informacion. Hacia una cultura ae la
seguriaaa. Paris. OCDE, fulio ae 2002. www.oeca.org

|2| NIST SP 800-30, Guia ae gestion ae riesgos para sistemas ae tecnologias ae la informacion.

|3| Deming W.E., Out of the Crisis, Cambriage, Mass. MIT, Center for Aavancea Engineering Stuay, 1986.

Luis Gmez Fernndez es licenciado en Econmicas por la Facultad de Econmicas
de la Universidad de Oviedo. Ha desempeado diversos cargos directivos, tanto en
la Administracin Pblica como la empresa privada, hasta la creacin de su propia
empresa que, actualmente, es un referente en seguridad de la informacin y servicios
de TI.
Ana Andrs lvarez es ingeniera de software por la University of Salford, Certified
Information Systems Auditor (CISA) y Certified Information Security Management
(CISM). Tiene una dilatada carrera profesional desempeada en el rea de sistemas
de gestin y mejora de procesos, y especialmente, en proyectos de seguridad de la
informacin, servicios de TI y auditoras de sistemas de gestin.
Sobre los autores

Publi PDF AEN 9551 PDF

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Publi PDF AEN 9551 PDF

Transféré par

Droits d'auteur :

Gua de aplicacin de la Norma UNE-ISO/IEC 27001

sobre seguridad en sistemas

Vous aimerez peut-être aussi