Guía de aplicación de la Norma UNE-ISOIEC 27001 sobre segurida.pdf

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes Luis Gómez Fernández y Ana Andrés Álvarez 2.ª edición (ampliada con el Esquema Nacional de Seguridad)

Título: Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes. 2.ª edición Autores: Luis Gómez Fernández y Ana Andrés Álvarez

© AENOR (Asociación Española de Normalización y Certificación), 2012 Todos los derechos reservados. Queda prohibida la reproducción total o parcial en cualquier soporte, sin la previa autorización escrita de AENOR. ISBN: 978-84-8143-7áÜ-ß Impreso en España - Printed in Spain Edita: AENOR Maqueta y diseño de cubierta: AENOR

Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.

Génova, 6. 28004 Madrid • Tel.: 902 102 201 • Fax: 913 103 695 [email protected] • www.aenor.es

Índice

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Objeto de esta guía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.

2.

Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

1.1.

Definición de un SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

1.2.

El ciclo de mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

1.3.

La Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Origen de la norma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2. Objeto y campo de aplicación de la norma . . . . . . . . . . . .

16 16 17

1.4.

La Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2. Objeto y campo de aplicación . . . . . . . . . . . . . . . . . . . . . .

17 17 18

1.5.

El Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . . . . . . . . 1.5.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2. Objeto y campo de aplicación . . . . . . . . . . . . . . . . . . . . . .

18 18 19

1.6.

Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Comprender la Norma UNE-ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . .

23

2.1.

Requisitos generales del sistema de gestión de la seguridad . . . . . . .

23

2.2.

Establecimiento y gestión del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Establecimiento del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Definición del alcance del SGSI . . . . . . . . . . . . . . . . . . . . . 2.2.3. Definición de la política de seguridad . . . . . . . . . . . . . . . . .

25 25 27 28

4

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

2.2.4. 2.2.5. 2.2.6. 2.2.7. 2.2.8. 2.2.9. 2.2.10. 2.2.11. 2.2.12. 2.2.13.

3.

Identificación de los activos de información . . . . . . . . . . . . Definición del enfoque del análisis de riesgos . . . . . . . . . . . Cómo escoger la metodología del análisis de riesgos . . . . . Tratamiento de los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . Selección de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Declaración de aplicabilidad . . . . . . . . . . . . . . . . . . . . . . . Implementación y puesta en marcha del SGSI . . . . . . . . . . . Control y revisión del SGSI . . . . . . . . . . . . . . . . . . . . . . . . Mantenimiento y mejora del SGSI . . . . . . . . . . . . . . . . . . .

28 29 30 31 31 32 32 33 33 34

2.3.

Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Control de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Control de registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 35 35 36

2.4.

Compromiso de la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

2.5.

Gestión de los recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

2.6.

Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

2.7.

Auditorías internas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

2.8.

Revisión por la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1. Entradas a la revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2. Salidas de la revisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39 40 40

2.9.

Mejora continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.1. Acción correctiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.2. Acción preventiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 42 43

2.10. El anexo A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Comprender la Norma UNE-ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . .

45

3.1.

Valoración y tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.2.

Política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.3.

Organización de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.4.

Gestión de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.5.

Seguridad ligada a los recursos humanos . . . . . . . . . . . . . . . . . . . .

50

3.6.

Seguridad física y del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

3.7.

Gestión de comunicaciones y operaciones . . . . . . . . . . . . . . . . . . . .

53

Índice

5

3.8.

Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

3.9.

Adquisición, desarrollo y mantenimiento de los sistemas . . . . . . . . . .

64

3.10. Gestión de las incidencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

3.11. Gestión de la continuidad del negocio . . . . . . . . . . . . . . . . . . . . . .

68

3.12. Cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

Definición e implementación de un SGSI . . . . . . . . . . . . . . . . . . . . . . . .

73

4.1.

El proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

4.2.

Documentación del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

4.3.

Política de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

4.4.

Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

4.5.

Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

4.6.

Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

4.7.

Plan de tratamiento del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

4.8.

Procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

4.9.

Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

4.10. Revisión por la dirección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

4.11. Auditoría interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

4.12. Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

5.

Proceso de certificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

6.

Relación entre los apartados de la norma y la documentación 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

4.

8.

Caso práctico: modelo de SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.1.

Documentación de la política de seguridad . . . . . . . . . . . . . . . . . . . 8.1.1. Política de seguridad de la información . . . . . . . . . . . . . . . 8.1.2. Definición del SGSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. Organización e infraestructura de seguridad . . . . . . . . . . . . 8.1.4. Clasificación de la información . . . . . . . . . . . . . . . . . . . . . 8.1.5. Análisis de riesgos de seguridad . . . . . . . . . . . . . . . . . . . . .

101 101 101 103 104 104

8.2.

Documentación del inventario de activos . . . . . . . . . . . . . . . . . . . . . 105 8.2.1. Procesos de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.2.2. 8.2.3. 8.2.4.

Inventario de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Relación proceso de negocio-activos . . . . . . . . . . . . . . . . . 106 Valoración de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.3.

Documentación del Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 107 8.3.1. Valoración del riesgo por activos . . . . . . . . . . . . . . . . . . . . 107 8.3.2. Tramitación del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.4.

Documentación de la Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . 110 8.4.1. Valoración del riesgo por activos . . . . . . . . . . . . . . . . . . . . 110

8.5.

Documentación de la Declaración de aplicabilidad . . . . . . . . . . . . . 114 8.5.1. Controles aplicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8.6.

Documentación del Plan de tratamiento del riesgo . . . . . . . . . . . . . . 8.6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.3. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.4. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.5. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.6. Objetivos e indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . .

123 123 123 123 123 124 124

8.7.

Documentación del Procedimiento de auditorías internas . . . . . . . . . 8.7.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.3. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.4. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.5. Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . 8.7.6. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7.7. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125 125 125 125 126 128 128 128

8.8.

Documentación del Procedimiento para las copias de seguridad . . . . 8.8.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.3. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.4. Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.5. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.6. Requisitos de documentación . . . . . . . . . . . . . . . . . . . . . . . 8.8.7. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.8.8. Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131 131 132 132 132 132 134 134 134

Índice

9.

7

Comprender el Esquema Nacional de Seguridad (ENS) . . . . . . . . . . . . . 137 9.1.

Generalidades del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

9.2.

Principios básicos del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

9.3.

Requisitos mínimos de seguridad del ENS . . . . . . . . . . . . . . . . . . . . 9.3.1. Organización e implementación del proceso de seguridad . . 9.3.2. Análisis y gestión de los riesgos . . . . . . . . . . . . . . . . . . . . . 9.3.3. Gestión de personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.4. Profesionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.5. Autorización y control de los accesos . . . . . . . . . . . . . . . . . 9.3.6. Protección de las instalaciones . . . . . . . . . . . . . . . . . . . . . . 9.3.7. Adquisición de nuevos productos de seguridad . . . . . . . . . . 9.3.8. Seguridad por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.9. Integridad y actualización del sistema . . . . . . . . . . . . . . . . . 9.3.10. Protección de la información almacenada y en tránsito . . . . 9.3.11. Prevención ante otros sistemas de información interconectados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.12. Registro de actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.13. Incidentes de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.14. Continuidad de la actividad . . . . . . . . . . . . . . . . . . . . . . . . 9.3.15. Mejora continua del proceso de seguridad . . . . . . . . . . . . . 9.3.16. Soporte al cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . .

140 140 140 141 141 141 141 142 142 142 143

Otros requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1. Comunicaciones electrónicas . . . . . . . . . . . . . . . . . . . . . . . 9.4.2. Auditoría de la seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.3. Estado de seguridad de los sistemas . . . . . . . . . . . . . . . . . . 9.4.4. Respuesta a incidentes de seguridad . . . . . . . . . . . . . . . . . . 9.4.5. Normas de conformidad . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.6. Actualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.7. Categorización de los sistemas . . . . . . . . . . . . . . . . . . . . . 9.4.8. Formación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

145 145 146 146 146 147 147 147 148

9.4.

143 143 144 144 144 144

10. Implementación del ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 10.1. El plan de adecuación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 10.2. Adecuación al ENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 10.2.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 10.2.2. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

8

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

10.2.3. Verificación y validación . . . . . . . . . . . . . . . . . . . . . . . . . . 154 10.2.4. Actualización y mejora continua . . . . . . . . . . . . . . . . . . . . . 155 11. Ejemplo práctico: plan de adecuación . . . . . . . . . . . . . . . . . . . . . . . . . . 157 11.1. Documentación de la política de seguridad . . . . . . . . . . . . . . . . . . . 157 11.2. Documentación de la categoría del sistema . . . . . . . . . . . . . . . . . . . 158 11.2.1. Criterios de valoración de los activos . . . . . . . . . . . . . . . . . 158 11.2.2. Categorización de sistemas . . . . . . . . . . . . . . . . . . . . . . . . 158 11.3. Documentación del análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . 11.3.1. Metodología de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2. Valoración de activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3. Mapas de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.4. Nivel de riesgo aceptable . . . . . . . . . . . . . . . . . . . . . . . . .

160 160 160 161 161

11.4. Documentación de la declaración de aplicabilidad . . . . . . . . . . . . . 164 11.5. Insuficiencias del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 11.6. Plan de mejora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 12. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Normas de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Legislación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Otros documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Links de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Norma UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de seguridad. Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Introducción

La información es el principal activo de muchas organizaciones y precisa ser protegida 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 más con riesgos e inseguridades procedentes de una amplia variedad de contingencias, las cuales pueden dañar considerablemente tanto los sistemas de información como la información procesada y almacenada. Ante estas circunstancias, las organizaciones han de establecer estrategias y controles adecuados que garanticen una gestión segura de los procesos del negocio, primando la protección de la información. Para proteger la información de una manera coherente y eficaz es necesario implementar un Sistema de Gestión de Seguridad de la Información (SGSI). Este sistema es una parte del sistema global de gestión, basado en un análisis de los riesgos del negocio, que permite asegurar la información frente a la pérdida de: • Confidencialidad: sólo accederá a la información quien se encuentre autorizado. • Integridad: la información será exacta y completa. • Disponibilidad: los usuarios autorizados tendrán acceso a la información 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 satisfactorio, que reduzca al mínimo los riesgos a los que se está expuesto y el impacto que ocasionarían si efectivamente se produjeran.

Objeto de esta guía

El objeto de esta publicación es facilitar la comprensión de los diversos conceptos involucrados en un sistema de gestión normalizado y contemplar las recomendaciones generales para la implementación de un SGSI en una pyme, utilizando la norma de facto en el mercado internacional para ello, la Norma UNE-ISO/IEC 27001. También se ofrece una visión general de cómo hacerlo en el caso de utilizar el modelo del Esquema Nacional de Seguridad (ENS), obligatorio por ley en nuestro país, para la protección de los sistemas que soportan la administración electrónica, visión también particularmente de interés para pymes que proporcionen servicios TIC a las Administraciones Públicas. Tanto la Norma UNE-ISO/IEC 27001 como el ENS, facilitan la mejora en seguridad, aunque pueden resultar de difícil aplicación para aquellos que no estén familiarizados con los conceptos que tratan. Esta guía no pretende ser preceptiva (existen infinidad de formas de implementar correctamente la norma y el ENS), sino informativa, proporcionando explicaciones básicas de los requisitos de la norma y orientando respecto a la manera en que se pueden cumplir esos requisitos. Generalmente, una primera aproximación a la norma puede infundir desconfianza en cuanto a la capacidad de la empresa para poder llevar a cabo todos los requerimientos que expresa. Muchos términos no se utilizan en la actividad cotidiana de una pyme, tales como riesgos, amenazas, vulnerabilidades. Además, exige una serie de tareas desconocidas en la operativa habitual, tales como la realización de un análisis de riesgos y la selección de controles. Para complicar más 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 técnico. Los objetivos, controles e indicaciones contenidos en la Norma

12

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

UNE-ISO/IEC 27002 pueden llegar a ser muy difíciles de valorar por un gestor que no cuente con la información o la formación adecuada, hecho que le impediría decidir cabalmente sobre cuál es su relevancia para la empresa y las consecuencias de la implementación o no de un determinado control en ella. Esta guía pretende suplir semejantes carencias, proporcionando información detallada sobre el significado práctico de los requisitos de la norma y explicando con ejemplos cómo se pueden realizar, teniendo siempre en cuenta la situación inicial, los requisitos de seguridad de la empresa y, por supuesto, los recursos disponibles, ya que sin contar con esto ningún sistema de gestión se hallará bien diseñado y, por lo tanto, estará condenado al fracaso. Para una mejor comprensión de las implicaciones de los diversos requisitos de la norma, esta guía incluye un ejemplo práctico, basado en una empresa ficticia, con la documentación básica que debe incluir un SGSI e indicaciones sobre la información que debe recoger cada documento.

1

Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI)

1.1. Definición de un SGSI Un Sistema de Gestión de Seguridad de la Información (SGSI), según la Norma UNE-ISO/IEC 27001, es una parte del sistema de gestión general, basada en un enfoque de riesgo empresarial, que se establece para crear, implementar, operar, supervisar, revisar, mantener y mejorar la seguridad de la información. Esto significa 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 información y sobre la propia información que se maneja en la organización. Nos permitirá conocer mejor nuestra organización, cómo funciona y qué podemos hacer para que la situación mejore. La norma especifica que, como cualquier otro sistema de gestión, el SGSI incluye tanto la organización como las políticas, la planificación, las responsabilidades, las prácticas, los procedimientos, los procesos y los recursos. Es decir, tanto la documentación de soporte como las tareas que se realizan. Los sistemas de gestión que definen las normas ISO siempre están documentados, ya que, por un lado, es la mejor manera de formalizar normas e instrucciones y, por otro, son más fáciles de transmitir y comunicar, cosa que no sucedería si se confía en un traspaso de información verbal informal. La norma es compatible con el resto de las normas ISO para sistemas de gestión (UNE-EN ISO 9001 y UNE-EN ISO 14001) y poseen idéntica estructura y requisitos comunes, por lo que se recomienda integrar el SGSI con el resto de los sistemas de gestión que existan en la empresa para no duplicar esfuerzos. Incluso cuando no exista un sistema de gestión formal, el amplio conocimiento actual de estos sistemas hace que las principales características de la norma sean

14

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

comprensibles para la mayoría 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 información de nuestra organización.

1.2. El ciclo de mejora continua Para establecer y gestionar un sistema de gestión de la seguridad de la información se utiliza el ciclo PDCA (conocido también como ciclo Deming), tradicional en los sistemas de gestión de la calidad (véase la figura 1.1). El ciclo PDCA es un concepto ideado originalmente por Shewhart, pero adaptado a lo largo del tiempo por algunos de los más sobresalientes personajes del mundo de la calidad. Esta metodología ha demostrado su aplicabilidad y ha permitido establecer la mejora continua en organizaciones de todas clases. El modelo PDCA o “Planificar-Hacer-Verificar-Actuar” (Plan-Do-Check-Act, de sus siglas en inglés), tiene una serie de fases y acciones que permiten establecer un modelo de indicadores y métricas comparables en el tiempo, de manera que se pueda cuantificar el avance en la mejora de la organización: • Plan. Esta fase se corresponde con establecer el SGSI. Se planifica y diseña el programa, sistematizando las políticas a aplicar en la organización, cuáles son los fines a alcanzar y en qué ayudarán a lograr los objetivos de negocio, qué medios se utilizarán para ello, los procesos de negocio y los activos que los soportan, cómo se enfocará el análisis de riesgos y los criterios que se seguirán para gestionar las contingencias de modo coherente con las políticas y objetivos de seguridad. • Do. Es la fase en la que se implementa y pone en funcionamiento el SGSI. Las políticas y los controles escogidos para cumplirlas se implementan mediante recursos técnicos, procedimientos o ambas cosas a la vez, y se asignan responsables a cada tarea para comenzar a ejecutarlas según las instrucciones. • Check. Esta fase es la de monitorización y revisión del SGSI. Hay que controlar que los procesos se ejecutan como se ha establecido, de manera eficaz y eficiente, alcanzando los objetivos definidos para ellos. Además, hay que verificar el grado de cumplimiento de las políticas y procedimientos, identificando los fallos que pudieran existir y, hasta donde sea posible, su origen, mediante revisiones y auditorías.

1. Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI)

15

• Act. Es la fase en la que se mantiene y mejora el SGSI, decidiendo y efectuando las acciones preventivas y correctivas necesarias para rectificar los fallos, detectados en las auditorías internas y revisiones del SGSI, o cualquier otra información 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 organización en un proceso 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 debería ser diseñar un SGSI que se ajuste lo más posible a la realidad de la organización, que contemple las medidas de seguridad mínimas e imprescindibles para proteger la información y cumplir con la norma, pero que consuma pocos recursos e introduzca el menor número de cambios posibles. De esta manera, el SGSI se podrá integrar de una forma no traumática en la operativa habitual de la organización, dotándola de herramientas con las que hasta entonces no contaba que puedan demostrar su eficacia a corto plazo. La aceptación de este primer SGSI es un factor de éxito fundamental. Permitirá a la organización ir mejorando su seguridad paulatinamente y con escaso esfuerzo.

Tomar acciones correctivas y preventivas

Revisar y auditar el SGSI

Act

Plan

Check

Do

Figura 1.1. Ciclo PDCA

Definir política y alcance

Implementar el SGSI

16

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

1.3. La Norma UNE-ISO/IEC 27001 1.3.1. Origen de la norma ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica Internacional) constituyen el sistema especializado para la normalización a nivel mundial. Los organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de las normas internacionales a través de comités técnicos establecidos por las organizaciones respectivas para realizar acuerdos en campos específicos de la actividad técnica. Los comités técnicos de ISO e IEC colaboran en los campos de interés mutuo. En el campo de la tecnología de la información, ISO e IEC han establecido un comité técnico conjunto, el denominado ISO/IEC JTC 1 (Joint Technical Committee 1). Los borradores de estas normas internacionales, adoptadas por la unión de este comité técnico, son enviados a los organismos de las diferentes naciones para su votación. La publicación como norma internacional requiere la aprobación 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 Instituto de Normas Británico (como BS 7799), y adoptada bajo la supervisión del subcomité de técnicos de seguridad del comité técnico ISO/IEC JTC 1, en paralelo con su aprobación por los organismos nacionales miembros de ISO e IEC. Una vez que fue publicada la Norma ISO/IEC 17799-1 (actualmente se corresponde con la Norma ISO/IEC 27002), Reino Unido (BSI) y España (AENOR) elevaron al comité internacional sus normas nacionales sobre las especificaciones de los sistemas de gestión de la seguridad de la información (SGSI), BS 7799-2 y UNE 71502 respectivamente, siendo estas normas el origen de lo que finalmente acabo publicándose como norma internacional ISO/IEC 27001 en el año 2005, que fue adoptada como norma española UNE-ISO/IEC 27001 en el año 2007, tras un periodo de convivencia con la norma anteriormente mencionada. Actualmente, tanto la norma ISO/IEC 27001 como la ISO/IEC 27002 están en proceso de revisión internacional, y se espera que se publiquen las nuevas versiones a lo largo del año 2013. Como se ha comentado anteriormente, este estándar internacional adopta también el modelo Plan-Do-Check-Act (PDCA), es decir, se basa en un ciclo de mejora continua 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 gestión, haciéndola más eficaz y efectiva.

1. Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI)

17

1.3.2. Objeto y campo de aplicación de la norma La Norma UNE-ISO/IEC 27001, como el resto de las normas aplicables a los sistemas de gestión, está pensada para que se emplee en todo tipo de organizaciones (empresas privadas y públicas, entidades sin ánimo de lucro, etc.), sin importar el tamaño o la actividad. Esta norma especifica los requisitos para la creación, implementación, funcionamiento, supervisión, revisión, mantenimiento y mejora de un SGSI documentado, teniendo en cuenta los riesgos empresariales generales de la organización. Es decir, explica cómo diseñar un SGSI y establecer los controles de seguridad, de acuerdo con las necesidades de una organización o de partes de la misma, pero no aclara mediante qué procedimientos se ponen en práctica. Por ejemplo, uno de los principales requisitos es la realización de un análisis de riesgos con unas determinadas características de objetividad y precisión, pero no aporta indicaciones de cuál es la mejor manera de llevar a cabo dicho análisis. Puede ejecutarse con una herramienta comercial, con una aplicación diseñada expresamente para la empresa, mediante reuniones, entrevistas, tablas o cualquier otro método que se estime oportuno. Todos estos recursos servirán para cumplir la norma, siempre y cuando se observen los requisitos de objetividad del método, los resultados sean repetibles y la metodología se documente.

1.4. La Norma UNE-ISO/IEC 27002 1.4.1. Origen La Norma UNE-ISO/IEC 27002 Tecnología de la información. Código de buenas prácticas para la gestión de la seguridad de la información, ha sido elaborada por el AEN/CTN 71/SC 27 Técnicas de seguridad que pertenece al comité técnico conjunto ISO/IEC JTC 1/SC 27 Tecnología de la información. En ambas normas el contenido es idéntico, diferenciándose únicamente en la numeración, que ha sido modificada en el marco de la creación de la familia de normas ISO 27000. Esta norma se está desarrollando dentro de una familia de normas internacionales sobre Sistemas de Gestión de la Seguridad de la Información (SGSI). Tal familia incluye normas internacionales sobre requisitos, gestión del riesgo, métricas y mediciones, así como una guía de implementación de los sistemas de gestión de la seguridad de la información. Dicha familia de normas tiene un esquema de numeración que utilizará los números de la serie 27000.

18

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

1.4.2. Objeto y campo de aplicación La Norma UNE-ISO/IEC 27002 establece las directrices y principios generales para el comienzo, la implementación, el mantenimiento y la mejora de la gestión de la seguridad de la información en una organización. Es un catálogo de buenas prácticas, obtenido a partir de la experiencia y colaboración de numerosos participantes, los cuales han alcanzado un consenso acerca de los objetivos comúnmente aceptados para la gestión de la seguridad de la información. Los objetivos de control y los controles de esta norma internacional tienen como fin servir de guía para el desarrollo de pautas de seguridad internas y prácticas efectivas de gestión de la seguridad. Por ello, la elección de los controles permanece sujeta a lo detectado en un análisis de riesgos previo, y el grado de implementación de cada uno de los controles se llevará a cabo de acuerdo a los requisitos de seguridad identificados y a los recursos disponibles de la organización 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 electrónico de los ciudadanos a los Servicios Públicos está siendo el motor y la guía de la administración electrónica. Esta ley ha dado paso a una nueva etapa en la gestión de la Administración Pública, impulsando la adopción de los medios tecnológicos actualmente disponibles para realizar tareas de gestión y facilitando a los ciudadanos el acceso a la Administración Pública en contextos más adecuados a la realidad social. Esta ley, en su artículo 1 reconoce el derecho de los ciudadanos a relacionarse con las Administraciones Públicas por medios electrónicos con la misma validez que por los medios tradicionales, y estipula que éstas utilicen las tecnologías de la información asegurando la disponibilidad, el acceso, la integridad, la autenticidad, la confidencialidad y la conservación de los datos, informaciones y servicios que gestionen en el ejercicio de sus competencias. También determina que la herramienta para conseguir este objetivo será el Esquema Nacional de Seguridad, que establecerá una política de seguridad en la utilización de medios electrónicos, y contará con unos principios básicos y una serie de requisitos mínimos que permitirán una protección adecuada de los sistemas y la información. El ENS está regulado por el Real Decreto 3/2010, de 8 de enero, que recoge los requisitos técnicos y organizativos que se deben cumplir para proteger la información dentro del ámbito de aplicación del mismo. Por tanto, se puede decir que trata

1. Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI)

19

la protección de la información y de los servicios en el ámbito de la administración electrónica y que, a la luz de principios y requisitos generalmente reconocidos, exige la gestión continuada de la seguridad, aplicando un sistema de gestión de seguridad de la información.

1.5.2. Objeto y campo de aplicación El objeto del ENS es garantizar la seguridad de los servicios prestados mediante medios electrónicos, de manera que los ciudadanos puedan realizar cualquier trámite con la confianza de que va a tener validez jurídica plena y que sus datos van a ser tratados de manera segura. Toda la Administración Pública española, Administración General del Estado, Administraciones de las Comunidades Autónomas, Administraciones Locales, así como las entidades de derecho público vinculadas o dependientes de las mismas, están sujetas al cumplimiento de los requisitos del ENS. Su ámbito de aplicación son los sistemas de información, los datos, las comunicaciones y los servicios electrónicos, que permitan a los ciudadanos y a las Administraciones Públicas el ejercicio de derechos y el cumplimiento de deberes a través de medios electrónicos.

1.6. Términos y definiciones Para cumplir con las intenciones de este documento, conviene aclarar el significado de ciertos términos y definiciones: • Activo Cualquier bien que tiene valor para la organización. [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 información no se pone a disposición o se revela a individuos, entidades o procesos no autorizados. [ISO/IEC 13335-1:2004]

20

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

• Seguridad de la información La preservación de la confidencialidad, la integridad y la disponibilidad de la información, pudiendo, además, abarcar otras propiedades, como la autenticidad, la responsabilidad, la fiabilidad y el no repudio. [ISO/IEC 17799:2005] • Evento de seguridad de la información La ocurrencia detectada en un estado de un sistema, servicio o red que indica una posible violación de la política de seguridad de la información, un fallo de las salvaguardas o una situación desconocida hasta el momento y que puede ser relevante para la seguridad. [ISO/IEC TR 18044:2004] • Incidente de seguridad de la información Un único evento o una serie de eventos de seguridad de la información, inesperados o no deseados, que tienen una probabilidad significativa de comprometer las operaciones empresariales y de amenazar la seguridad de la información. [ISO/IEC TR 18044:2004] • Sistema de Gestión de la Seguridad de la Información (SGSI) [Information Security Management System, ISMS] La parte del sistema de gestión general, basada en un enfoque de riesgo empresarial, que se establece para crear, implementar, operar, supervisar, revisar, mantener y mejorar la seguridad de la información. Nota: el sistema de gestión incluye la estructura organizativa. las políticas, las actividades de planificación, las responsabilidades, las prácticas, 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 después de que se hayan tornado las medidas de seguridad. [ISO/IEC Guide 73:2002]

1. Introducción a los Sistemas de Gestión de Seguridad de la Información (SGSI)

21

• Aceptación del riesgo La decisión de aceptar un riesgo. [ISO/IEC Guide 73:2002] • Análisis de riesgos Utilización sistemática de la información disponible para identificar peligros y estimar los riesgos. [ISO/IEC Guide 73:2002] • Evaluación de riesgos El proceso general de análisis y estimación de los riesgos. [ISO/IEC Guide 73:2002] • Estimación de riesgos El proceso de comparación del riesgo estimado con los criterios de riesgo, para así determinar la importancia del riesgo. [ISO/IEC Guide 73:2002] • Gestión de riesgos Actividades coordinadas para dirigir y controlar una organización con respecto a los riesgos. [ISO/IEC Guide 73:2002] • Tratamiento de riesgos El proceso de selección e implementación de las medidas encaminadas a modificar los riesgos. [ISO/IEC Guide 73:2002]. Nota: en esta norma internacional, el término “control” se utiliza como sinónimo de “medida de seguridad.”

• Declaración de aplicabilidad Declaración documentada que describe los objetivos de control y los controles que son relevantes para el SGSI de la organización y aplicables al mismo. Nota: los objetivos de control y los controles se basan en los resultados y conclusiones de la evaluación 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 organización en materia de seguridad de la información.

2

Comprender la Norma UNE-ISO/IEC 27001

La seguridad no es el resultado de un proceso, es un proceso en sí mismo. Se conseguirá un nivel de seguridad aceptable en la medida en que este proceso funcione y progrese adecuadamente. No es de extrañar, por tanto, que la Norma UNE-ISO/IEC 27001 exija que se adopte un proceso para establecer, implementar, operar, monitorizar, revisar, mantener y mejorar el SGSI en una organización. Es decir, hay que diseñarlo, ponerlo en marcha, comprobar que se obtienen los resultados esperados y, en función de esa evaluación, tomar acciones para corregir las desviaciones detectadas o intentar mejorar la situación, en este caso, la seguridad de la información. Y todo ello de una manera ordenada y metódica, mediante un proceso.

2.1. Requisitos generales del sistema de gestión de la seguridad Una organización necesita identificar y administrar cualquier tipo de actividad para funcionar eficientemente. Cualquier actividad que emplea recursos y es administrada para transformar entradas en salidas, puede ser considerada como un “proceso”. A menudo, estas salidas son aprovechadas nuevamente como entradas, generando una realimentación. Habitualmente se piensa que los sistemas de gestión son un conjunto de actividades que requieren unos niveles de recursos y dinero que no están al alcance de una empresa pequeña. Nada más lejos de la realidad. En infinidad de ocasiones son las pequeñas empresas las que más se pueden beneficiar de estas iniciativas, ya que

24

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

carecen de los conocimientos y la cultura que transmiten las normas de manera tan sintética y depurada. El éxito de un proyecto de implementación de un SGSI está fuertemente ligado a la habilidad del promotor de asignar los recursos justos y necesarios para diseñar un sistema adecuado a las necesidades de la organización. 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 gestión debe apoyar el cumplimiento de los objetivos de la organización o no tendrá razón de ser. Los requisitos que exige este estándar internacional son genéricos y aplicables a la totalidad de las organizaciones, independientemente de su tamaño o sector de actividad. En particular, no se acepta la exclusión de los requerimientos especificados en los apartados 4, 5, 6, 7 y 8 cuando una organización solicite su conformidad con esta norma. Estos apartados son las que realmente conforman el cuerpo principal de la norma: • Sistema de gestión de la seguridad de la información. • Responsabilidad de la dirección. • Auditorías internas del SGSI. • Revisión del SGSI por la dirección. • Mejora del SGSI. Lo que la norma reclama es que exista un sistema documentado (política, análisis de riesgos, procedimientos, etc.), donde la dirección colabore activamente y se implique en el desarrollo y gestión del sistema. Se controlará el funcionamiento del sistema para que marche correctamente y la mejora sea continua, practicándose auditorías internas y revisiones del sistema para verificar que se están obteniendo los resultados esperados, igualmente se activarán acciones encaminadas a solucionar los problemas detectados en las actividades de comprobación (auditorías y revisiones), a prevenir problemas y a mejorar aquellos asuntos que sean susceptibles de ello. El sistema constará de una documentación en varios niveles (véase la figura 2.1): • Políticas, que proporcionan las guías generales de actuación 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.

2. Comprender la Norma UNE-ISO/IEC 27001

25

Políticas

Procedimientos

Registros

Figura 2.1. Niveles de documentación

2.2. Establecimiento y gestión del SGSI 2.2.1. Establecimiento del SGSI La norma establece una serie de requisitos, que se detallan a continuación (véase la figura 2.2). Para satisfacerlos, la organización debe buscar los medios más apropiados a sus circunstancias, necesidades y, por supuesto, los recursos disponibles. Debe recopilarse información sobre varios aspectos, tales como a qué se dedica la organización, 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 organización sabe, en términos generales, qué nivel de seguridad desea, pero no existen mecanismos para expresarlo y documentarlo. Hay que concretar esas necesidades que se perciben para poder comenzar el diseño del SGSI. Sabiendo qué se necesita se podrán

26

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

ISO 27001

Reglamentos

Leyes

SGSI

Recursos

Negocio

Contratos

Figura 2.2. Requisitos del SGSI

proponer opciones y tomar decisiones. Es fundamental no comprometer recursos difíciles 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 (véase la figura 2.3), básicamente se emprenderán las actividades que se detallan a continuación, y que como tienen que ser documentadas, al finalizarlas, el SGSI contará ya con los siguientes documentos: • Política de seguridad, que contendrá las directrices generales a las que se ajustará la organización en cuanto a seguridad, así como la estrategia a seguir a la hora de establecer objetivos y líneas de actuación. La política estará alineada con el resto de los objetivos del negocio y políticas de gestión que existan en la organización. Esta política estará aprobada por la dirección. • Inventario de activos, que detallará los activos dentro del alcance del SGSI, así como los propietarios y la valoración de tales activos. • Análisis de riesgos, con los riesgos identificados basándose en la política de la organización sobre seguridad de la información y el grado de seguridad requerido.

2. Comprender la Norma UNE-ISO/IEC 27001

27

• Las decisiones de la dirección respecto a los riesgos identificados, así como la aprobación de los riesgos residuales. • Documento de aplicabilidad con la relación de los controles que son aplicables para conseguir el nivel de riesgo residual aprobado por la dirección.

Definir alcance Definir política de seguridad Identificar activos Definir el enfoque de análisis Identificar los riesgos Analizar los riesgos Tratar los riesgos

Figura 2.3. Establecer el SGSI

2.2.2. Definición del alcance del SGSI Es decir, sobre qué proceso (o procesos) va a actuar, ya que no es necesaria la aplicación 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 organización. Normalmente es más práctico limitar el alcance del SGSI a aquellos servicios, departamentos o procesos en los que resulte más sencillo, bien porque el esfuerzo va a ser menor o porque la visibilidad del proyecto (interna o externa) es mayor. En cualquier caso,

28

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

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. Definición de la política de seguridad Decidir qué criterios se van a seguir, estableciendo las principales líneas de acción que se van a seguir para que la confidencialidad, la integridad y la disponibilidad queden garantizadas. Esta política tendrá en cuenta los requisitos del negocio, los contractuales y los legales y estatutarios que sean aplicables. Es primordial incorporar en esta fase inicial las necesidades de la organización. Aunque a veces son difíciles de expresar y documentar, es esencial que el SGSI esté alineado con el resto de las estrategias, planes y modos de funcionar de la organización para que pueda integrarse en el día a día sin complicaciones y rindiendo resultados desde el principio. Cuando resulte posible, será útil recopilar los documentos de seguridad existentes en la organización para incorporarlos desde el principio al sistema. La política de seguridad debe dejar claras las normas básicas de seguridad en la organización, definiendo cuál va a ser el comportamiento de la misma en cuanto a los usos de la información y de los sistemas, los accesos, cómo se gestionarán las incidencias, etc. Los empleados deben conocer esta política y adherirse a ella, incluso formalmente si es necesario.

2.2.4. Identificación de los activos de información 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 información y cada documento que se maneje en la empresa, pero sí es indispensable identificar qué activos son los que soportan los procesos de la organización. 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, infraestructuras, 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 análisis de riesgos sobre todos ellos. De acuerdo con la relevancia que la organización otorgue a los activos, se escogerá el grupo de los más valiosos para efectuar el análisis de riesgos. Esta tarea consume gran parte de los recursos del proyecto, por lo que es conveniente simplificarla ya desde esta fase.

2. Comprender la Norma UNE-ISO/IEC 27001

29

Los activos deben relacionarse con los procesos de negocio que soportan, de forma que quede explícita la dependencia del negocio respecto de esos activos. La norma es bastante clara al respecto. El SGSI debe apoyar la consecución de los objetivos de negocio. Se realiza una gestión para obtener unos resultados, la seguridad de la información no es una excepción. Su gestión ha de estar orientada en todo momento a que la organización funcione más y mejor y consiga sus propósitos. Como la seguridad parece un tema muy técnico se puede caer en el error de considerar que es un problema que deben solucionar los informáticos. No cabe duda de que la seguridad de la información consta de un destacable componente técnico y que el personal técnico debe estar involucrado activamente en el diseño, desarrollo y mantenimiento de un SGSI, pero recordemos que estamos hablando de un sistema de gestión, por lo que la parte de gestión es tanto o más importante que la parte técnica. Un sistema no funciona si el personal que lo debe utilizar no lo hace. Como prueba, sólo hay que pensar que las incidencias más graves de seguridad no suelen tener su origen en fallos técnicos, sino en fallos humanos.

2.2.5. Definición del enfoque del análisis de riesgos Hay que decidir cómo se enfocará el análisis de riesgos. El análisis de riesgos determinará las amenazas y vulnerabilidades de los activos de información previamente inventariados. Esta tarea es crucial para el correcto diseño del SGSI, puesto que de su resultado depende que se escojan unos controles u otros, que son los que conformarán nuestro sistema. Como es una tarea laboriosa, se buscan métodos para que su ejecución sea más simple sin dejar de ser rigurosa. Primeramente se elige el nivel de detalle con el que se va a llevar a cabo el análisis, enfoque de mínimos o detallado, y después el grado de formalidad, enfoque informal o formal. Estas categorías no son excluyentes, es decir, se puede optar por un enfoque detallado y formal para un grupo de activos muy críticos, para otro grupo importante se hace un análisis detallado e informal y para un tercer grupo de menor relevancia, un enfoque de mínimos. Esto se llamaría enfoque mixto. En un enfoque de mínimos se establece un nivel básico de seguridad para los sistemas, efectuando una simplificación del inventario de activos y del análisis de riesgos que consuma los recursos mínimos. Con un enfoque detallado se realizan revisiones detalladas del análisis de riesgos para todos los sistemas, se identifican todos los riesgos y la evaluación de sus magnitudes. Como estas tareas consumen muchos recursos, no se suele utilizar un enfoque detallado para todos los activos, sólo para los más notables.

30

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

2.2.6. Cómo escoger la metodología del análisis de riesgos Puesto que la norma únicamente establece que los resultados han de ser comparables y repetibles, debe escogerse aquella metodología que mejor se adapte a los modos de trabajo de la organización, así el ejercicio se integrará sin problemas en el trabajo cotidiano. Además, ayuda a que los resultados sean más aceptables por la organización y a que se pueda mantener en el tiempo. Si la metodología escogida es excesivamente complicada y requiere mucho esfuerzo para llevar a cabo el análisis, la carga de trabajo añadida complicará el proyecto, y los resultados pueden parecer poco fiables por los no implicados directamente en su obtención, puesto que será difícil explicarlos. Identificar los riesgos que pueden afectar a la organización y a sus activos de información. Hay que saber cuáles son los peligros a los que se enfrenta la empresa, los puntos débiles, para poder solucionar de manera efectiva los problemas, insistiendo con más recursos y esfuerzos en los temas que más lo necesitan. Un SGSI tiene que incluir medidas de seguridad apropiadas a los riesgos a los que la organización debe enfrentarse, para ello se planteará un análisis de riesgos que determine el nivel de riesgo existente sobre los activos de información de la empresa. Con un método de análisis de riesgos ya escogido se identificarán las amenazas sobre estos activos, las vulnerabilidades que podrían ser explotadas por las amenazas y los impactos que pueden tener en los activos. El riesgo se define a menudo como la función del daño que podría producir una amenaza por la probabilidad de que eso ocurra. Cuantificando estos parámetros, se obtendrán 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 práctica, 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 dónde se halla el valor por debajo del cual ya no podremos hacer más de lo que se ha hecho. Aplicar controles a todos los activos no suele ser viable ni organizativa ni económicamente. Una vez definidos los límites, condicionantes y requisitos que debe cumplir el SGSI, puesto que en la norma no se requiere que exista un Manual de seguridad en la línea de otras normas de gestión, toda esta información debe quedar plasmada en parte de los documentos que compondrán el SGSI. En particular es necesario documentar en esta fase: • La política de seguridad, que además debe aprobarse por la dirección. • La metodología a seguir para realizar el análisis de riesgos.

2. Comprender la Norma UNE-ISO/IEC 27001

31

2.2.7. Tratamiento de los riesgos Obtenidos los niveles de riesgo, hay que decidir si son aceptables o no, según el criterio fijado previamente. Si no lo son, hay que evaluar cómo se van a tratar esos riesgos: • Mitigar el riesgo. Es decir, reducirlo, mediante la implementación de controles que disminuyan el riesgo hasta un nivel aceptable. • Asumir el riesgo. La dirección tolera el riesgo, ya que está por debajo de un valor de riesgo asumible o bien porque no se puede hacer frente razonablemente a ese riesgo, por costoso o por difícil. La dirección debe firmar que los activos con un valor de riesgo inferior no estarán 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. Aún así, evidenciar que la responsabilidad sobre el activo permanece siempre en manos de la organización y tener en cuenta que hay daños, como los causados a la reputación de la organización, que difícilmente son cubiertos por ningún seguro. • Eliminar el riesgo. Aunque no suele ser la opción más viable, ya que puede resultar complicado o costoso. También se puede optar por una estrategia que combine dos o más de estas elecciones. Por ejemplo, un sistema muy crítico y con mucho riesgo puede decidirse a aplicar controles que mitiguen el riesgo en los aspectos operativos cotidianos y subcontratar los cambios con lo que se transferirá parte del riesgo al contratista. La opciones más 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 análisis de riesgos.

2.2.8. Selección 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 añadir otros, pero esta lista de controles es un sólido punto de partida para elegir las medidas de seguridad apropiadas para el SGSI, asegurando que ningún aspecto o control importante se pasan por alto. La selección de controles es un punto crítico del SGSI. A la hora de escoger o rechazar un control se debe considerar hasta qué punto ese control va a ayudar

32

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

a reducir el riesgo que hay y cuál va a ser el coste de su implementación y mantenimiento. Cabe la posibilidad de que un control que se estime oportuno implementar, sea demasiado costoso o difícil de implementar para la organización, por resistencia al cambio o por falta de formación, y que haya que excluirlo de la selección 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 almacén de madera son radicalmente distintas, y eso significa que sus SGSI también han de serlo. Nunca el coste de implementación y mantenimiento de un control debe superar a los beneficios que se esperan de él.

2.2.9. Gestión de riesgos Una vez seleccionados los controles se repetirá el análisis 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 función del que se determina el riesgo asumible por la organización, y se deciden las nuevas estrategias y acciones para reducir los riesgos que estén por encima de ese valor. Una tercera iteración del análisis de riesgos que contemplan las medidas previstas, nos dará los riesgos residuales. La dirección debe aprobar el valor de riesgo aceptable y asumir el riesgo residual.

2.2.10. Declaración de aplicabilidad El siguiente requisito de la norma es la preparación de una declaración de aplicabilidad, que debe incluir: • Los objetivos de control y los controles seleccionados, con las razones de esta selección. • Los objetivos de control y los controles actualmente implementados, con una justificación. • La exclusión de cualquier control objetivo del control y de cualquier control en el anexo A y la justificación para dicha exclusión. Esta declaración de aplicabilidad sirve para comprobar que realmente se han considerado todas las opciones de controles disponibles y que no se ha omitido ninguno.

2. Comprender la Norma UNE-ISO/IEC 27001

33

2.2.11. Implementación y puesta en marcha del SGSI Para poner en marcha el SGSI la dirección tiene que aprobar la documentación desarrollada en las actividades detalladas en el punto anterior y proveer los recursos necesarios para ejecutar las actividades. Estas actividades se registrarán en un plan de tratamiento del riesgo que regule todas las acciones necesarias para tratarle, además de los recursos, las responsabilidades y las prioridades para la gestión de los riesgos de seguridad de la información. Tan importante como la definición de las tareas a realizar y los recursos que se van a asignar, es decidir cómo se va a medir la eficacia de estas acciones y de las medidas de seguridad aplicadas. Esto implica establecer un conjunto de objetivos y métricas asociadas 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 información es una cuestión multidisciplinar e importante para cada proyecto y sistema y para todos los usuarios en la organización. La asignación y delimitación 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 través de diversos esquemas, dependiendo de la estructura y tamaño de la organización, en cualquier caso se ha de de contar con la designación 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 organización y sus responsabilidades cubrirán todas las funciones de seguridad. • Un comité de seguridad que trate y busque soluciones a los temas de seguridad, resuelva los asuntos interdisciplinarios y apruebe directrices y normas. Ambos, el comité de seguridad y el responsable de seguridad de la organización, deben tener sus tareas bien delimitadas y encontrarse a un nivel suficiente en la estructura de la organización, de forma que pueda asegurarse el compromiso con la política de seguridad. La organización debe proporcionar líneas claras de comunicación, responsabilidad y autoridad al responsable de seguridad, y sus tareas han de ser aprobadas por el comité de seguridad.

2.2.12. Control y revisión del SGSI La revisión del SGSI forma parte de la fase del Check (comprobar) del ciclo PDCA. Hay que controlar y revisar el SGSI de manera periódica para garantizar la conveniencia, adecuación y eficacia continuas del sistema.

34

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Para efectuar la revisión hay que recopilar información de los resultados de las distintas actividades del SGSI para comprobar si se están alcanzando los objetivos, y, si no es así, averiguar las causas y buscar soluciones. Las revisiones consistirán en estudiar los resultados de las auditorías 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. Además, hay que revisar los análisis del riesgo a intervalos planificados y examinar los riesgos residuales, así como los niveles aceptables del riesgo, teniendo en cuenta los cambios en la organización, la tecnología, 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 auditorías internas del SGSI también forman parte de esta fase de revisión. Las revisiones del SGSI tienen que estar planificadas y gestionadas para asegurar que el alcance continúa 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 realización, involucrar a la dirección en la gestión 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 estáticas y su gestión tampoco lo es. Por lo tanto, sería 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 organización impactarán 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 gestión 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. Comprender la Norma UNE-ISO/IEC 27001

35

2.3. Requisitos de documentación 2.3.1. Generalidades El SGSI debe contar con la documentación necesaria que justifique las decisiones de la dirección, las políticas y las acciones tomadas y que se pueda demostrar que los controles seleccionados lo han sido como resultado de estas decisiones y del análisis de riesgos. Es decir, se debe delinear la trazabilidad que se ha de seguir desde las políticas y objetivos hasta los controles implementados. Por ello es necesario tener documentado: • La política y los objetivos del SGSI. • El alcance del SGSI. • Una descripción de la metodología de análisis del riesgo. • El inventario de activos. • Los procedimientos y controles de apoyo al SGSI. • El análisis del riesgo. • El plan de tratamiento del riesgo. • La declaración de aplicabilidad. • Los procedimientos necesarios para la implementación de los controles y para asegurarse de que se cumplan los objetivos. • Los registros requeridos por la norma. La norma no exige ningún tipo de formato para los documentos ni para los registros, cualquier soporte es válido.

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 documentación, de revisión y de registro (informes, auditorías, cambios, autorizaciones de acceso, permisos temporales, bajas, etc.). Los procedimientos de documentación deben contemplar cómo se generan, aprueban, revisan y actualizan los documentos según sea necesario.

36

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Una buena gestión documental contará con que los cambios sean identificados y que la identificación 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. Además, hay que comprobar que el almacenamiento sea correcto y que cuando haya que destruir los documentos se haga de acuerdo con su clasificación. 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 realización 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 auditorías y los logs de los sistemas. Los registros estarán protegidos y controlados teniendo en cuenta cualquier requisito de tipo legal, reglamentario u obligación contractual. Permanecerán legibles, fácilmente identificables y recuperables. Los controles necesarios para la identificación, almacenamiento, protección, recuperación, tiempo de conservación y disposición de los registros se encontrarán documentados e implementados. Deberán guardarse todos los registros del funcionamiento del proceso y las incidencias de seguridad significativas relacionadas con el SGSI.

2.4. Compromiso de la dirección Uno de los requisitos fundamentales para poner en marcha un SGSI es contar con el compromiso de la dirección, no sólo por ser uno de los epígrafes contemplados en la norma, sino porque el cambio de cultura y concienciación que genera el proceso sería imposible de sobrellevar sin el compromiso constante de la dirección. El desarrollo, la implementación y el mantenimiento del SGSI exigen un esfuerzo organizativo importante, que únicamente podría llevarse a cabo con una voluntad clara de hacerlo por parte de la dirección, puesto que es ella quien tiene que proveer de recursos al proyecto, tanto financieros como humanos, por lo que su apoyo es imprescindible. La dirección debe comprometerse de manera evidente con el establecimiento, implementación, puesta en marcha, monitorización, revisión, mantenimiento y

2. Comprender la Norma UNE-ISO/IEC 27001

37

mejora del SGSI. La forma en la que se plasma este compromiso es colaborando o ejecutando, según los casos, las siguientes tareas: • Establecer la política del SGSI. • Asegurar que se establecen los objetivos y planes del SGSI. • Asignar los roles y las responsabilidades para la seguridad de la información. • Comunicar a la organización la conveniencia del cumplimiento de los objetivos de seguridad de la información y, conforme a la política de seguridad de la información, sus responsabilidades legales y la necesidad de la mejora continua. • Proporcionar recursos suficientes para implementar, mantener y mejorar el SGSI. • Decidir los criterios de aceptación de los riesgos. • Verificar que se realizan las auditorías internas del SGSI. • Dirigir la gestión de las revisiones del SGSI.

2.5. Gestión de los recursos Como se comentaba anteriormente, es la dirección la que debe gestionar los recursos. Ha de comenzar por proveer de recursos al desarrollo y mantenimiento del SGSI en función 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 verificación y la mejora del sistema, puesto que conservar el nivel de seguridad que aporta el SGSI sólo puede lograrse comprobando regularmente que los procedimientos de seguridad están alineados con el negocio, que cumplen con los requisitos legales, que los controles están correctamente implementados y que se llevan a cabo las acciones oportunas para corregir errores y mejorar el sistema. Capítulo aparte merece la gestión de los recursos humanos. Este punto es uno de los factores críticos de éxito. Sin una colaboración activa del personal es muy difícil implementar con éxito un SGSI.

38

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

2.6. Formación 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 función de tales necesidades, proporcionar la formación a la plantilla o adoptar otras acciones para satisfacerlas (por ejemplo, la contratación de personal competente). Como cualquier otra actividad, requiere una planificación, así como verificar que se cumplen los objetivos y mantener los registros de educación, formación y cualificación de los empleados. Independientemente de la formación, el personal estará concienciado de la importancia de las actividades de seguridad de la información y en particular de las suyas propias, y de que cómo la aportación de cada uno es fundamental para alcanzar los objetivos de seguridad establecidos, y en consecuencia los de la organización. En la medida que seamos capaces de formar al personal y concienciarlo de que es fundamental ceñirse a las normas de seguridad, reduciremos drásticamente la probabilidad de fallos y su potencial impacto.

2.7. Auditorías internas Una de las herramientas más interesantes para controlar el funcionamiento del SGSI son las auditorías internas. Estas auditorías deben programarse y prepararse regularmente, normalmente una vez al año. Esta programación se recogerá en el plan de auditorías. A la hora de desarrollar el plan de auditorías hay que fijarse en: • El estado e importancia de los procesos y las áreas que serán auditadas, de este modo se determinará el tiempo y los recursos que habrá que destinar para efectuar la auditoría. • Los criterios de la auditoría. • El alcance, si va a ser global (va a abarcar toda la empresa) o parcial (sólo una parte). • La frecuencia de realización de las auditorías, sabiendo que cada tres años, al menos, toda la organización debe ser auditada. • Los métodos que se van a utilizar para hacer las auditorías.

2. Comprender la Norma UNE-ISO/IEC 27001

39

El plan ha de estar aprobado por la dirección. Una vez preparado y aprobado, debe distribuirse a todos los departamentos y a los auditores afectados con la suficiente antelación, de manera que puedan preparar adecuadamente la auditoría. Las auditorías 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 implementación que tienen, si se están 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 auditorías, para informar de los resultados y para mantener los registros, tales como el informe de auditoría 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 verificación de las acciones tomadas y el informe de la verificación de los resultados. Es importante la selección de los auditores, ya que no deben auditar su propio trabajo, sólo siendo independientes se puede garantizar la imparcialidad.

2.8. Revisión por la dirección La dirección debe revisar el SGSI de manera periódica para garantizar la conveniencia, adecuación y eficacia continuas del sistema. El proceso de revisión por la dirección no debería ser un ejercicio ejecutado únicamente para cumplir los requisitos de la norma y de los auditores, sino que debería ser una parte integral del proceso de gestión del negocio de la organización. Para realizar esta revisión hay que recopilar información de los resultados de las distintas actividades del SGSI para comprobar si se están alcanzando los objetivos, y si no es así, averiguar las causas y decidir sobre las posibles soluciones. Esta revisión es una de las pocas tareas que se le asigna específicamente a la dirección, por lo que posee relevancia en varios aspectos: mantiene a la dirección en contacto con la realidad del SGSI, ya que lógicamente no se encuentra involucrada en el día a día, pero es importante que esté al tanto de los trabajos realizados, de los logros obtenidos y de los problemas que aparezcan. Además es una herramienta para aportar iniciativas al SGSI, ya que es la dirección la encargada de la visión estratégica de la empresa, la que determina hacia dónde debe ir y cómo. Como herramienta de gestión que es, el SGSI debe incorporar esta visión y colaborar para hacerla viable.

40

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

2.8.1. Entradas a la revisión Los resultados de la revisión deben ser documentados para proporcionar evidencia de su realización, involucrar a la dirección en la gestión del sistema y apoyar las acciones de mejora. Las entradas a la revisión pueden ser: • Los resultados de las auditorías y las revisiones del SGSI. • Comentarios de las partes interesadas (usuarios de los sistemas de información, contratistas, clientes, etc.). • Técnicas, productos o procedimientos que podrían ser empleados en la organización 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 análisis de riesgos anteriores. • Los resultados de las métricas de efectividad. • Las acciones de seguimiento de anteriores revisiones por la dirección. • Cualquier cambio que pudiera afectar al SGSI. • Recomendaciones para la mejora. Con esta información se puede tener una visión 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 revisión, además de involucrar a la dirección activamente en la gestión del sistema.

2.8.2. Salidas de la revisión Los resultados de la revisión pueden ser de varios tipos: • Identificación de acciones para mejorar la efectividad del SGSI. • Actualización de la evaluación y la gestión de riesgos. • Modificación de los procedimientos y controles que afectan a la seguridad de la información para ajustarse a incidentes o cambios en: – Requisitos de negocio, de seguridad o legales.

2. Comprender la Norma UNE-ISO/IEC 27001

41

– Procesos de negocio que tengan efecto en los requisitos de negocio existentes. – Obligaciones contractuales. – Niveles de riesgo y/o criterios para aceptar los riesgos. – Necesidades de recursos. • Realización de mejoras en la manera de medir la efectividad de los controles. La revisión, aunque se centre en la detección y resolución de problemas en la gestión y operativa del SGSI, debe considerar también los puntos fuertes, es decir, qué se está haciendo bien y la razón, sobre todo en comparación con revisiones anteriores, de manera que se ponga en evidencia la mejora continua del sistema. Como resultado del proceso de revisión por la dirección, debería existir evidencia de decisiones relacionadas con cambios en la política y los objetivos de seguridad, los planes, presupuestos o acciones de mejora. Se requieren registros de la revisión por la dirección, pero no se especifica su formato. Las actas de las reuniones son el tipo más común de registro, pero los registros electrónicos, los diagramas estadísticos, las presentaciones, etc., podrían ser tipos de registro aceptables. El informe de revisión por la dirección suele realizarlo el responsable de seguridad y discutirse dentro del comité de seguridad, aunque es la dirección 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 gestión según las normas ISO. Este concepto también es crucial en todos los modelos de mejora de procesos o negocio que existen. En pura lógica, cualquier organización desea hacer las cosas cada vez mejor (mejores productos, más baratos, en menos tiempo, mayores beneficios), por lo que la mejora continua es un concepto empresarial de primer orden. Los sistemas de gestión tendrán por tanto que apoyar este proceso, que se realimenta a sí mismo y nunca termina, ya que siempre se puede mejorar en algo.

42

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Cuando una organización se considera madura, es decir, cuando la mejora continua forma parte de la cultura de la empresa y se obtiene el máximo rendimiento de los procesos, es porque todos los niveles de la organización están involucrados y la dirección ha hecho de la mejora continua una de las herramientas fundamentales para la gestión del negocio. Aunque la mejora continua es un proceso que debe ser impulsado desde la dirección, su implementación se realizará en la base, donde se ejecuta el trabajo. Las principales herramientas para la mejora continua son las revisiones, las auditorías, las acciones correctivas, preventivas y de mejora, los objetivos y el análisis de los incidentes de seguridad. Los resultados de estas actividades son una valiosísima fuente de información sobre cuáles son los puntos débiles de la organización y sus procesos. Sabiendo esto, se pueden tomar acciones encaminadas a eliminarlos, haciendo que los procesos sean más eficientes y efectivos, en definitiva, que hacer el trabajo sea cada vez más rápido y menos costoso, tanto en recursos humanos como en materiales.

2.9.1. Acción correctiva La acción correctiva se define como la tarea que se emprende para corregir una no conformidad significativa con cualquiera de los requisitos del sistema de gestión de seguridad de la información. Localizado el problema debe determinarse la relación causa-efecto, considerando todas las causas posibles. A veces no es fácil dilucidar cuáles son las causas exactas del problema, pero hay que intentar aproximarse lo más posible. En primer lugar porque sólo conociendo de dónde partió el problema se puede tomar una decisión coherente y acertada para solucionarlo. Y además porque es la manera de ir destapando los puntos débiles de nuestros procesos. En más de una ocasión varios problemas 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 decisión sobre las acciones a tomar y asignará responsables y plazos para su ejecución. Es esencial el cumplimiento de los plazos, y el comité debe velar por ello y analizar, en su caso, cuáles 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 pequeños problemas. Es cierto que, y más al principio, es difí-

2. Comprender la Norma UNE-ISO/IEC 27001

43

cil distinguir entre los diversos grados de gravedad de las incidencias o no conformidades detectadas. Pero utilizar las acciones correctivas para todo no resulta eficaz, deberían reservarse para asuntos que no pueden ser resueltos satisfactoriamente por otros medios. Cuando surgen los problemas hay que valorar si son incidentes cotidianos, problemas de origen conocido, de fácil solución y que no conllevan un impacto considerable. Si el problema tiene causas difíciles de detectar, la solución no es obvia o factible, es un hecho recurrente, el impacto que ha causado es importante o es una desviación sistemática de las normas, entonces sí es apropiado utilizar una acción 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 colaboración del personal en la detección de las causas de los problemas y la búsqueda de soluciones, y realmente son los que tienen el conocimiento para ello, por lo que es fundamental asegurarse su colaboración.

2.9.2. Acción preventiva Las acciones preventivas se aplican para evitar la aparición de futuras no conformidades. Son acciones encaminadas a eliminar la causa de una posible no conformidad. En una acción 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 más eficaz y sencillo prevenirlos que solucionarlos. Se puede decidir abrir acciones preventivas a raíz de observaciones detalladas en las auditorías internas o externas, del análisis de la evolución de los objetivos y de los resultados de las actividades de revisión, ya que pueden utilizarse como fuentes de información para el establecimiento de acciones preventivas: • Los resultados de la revisión por la dirección. • Los resultados de los análisis de incidencias y objetivos. • Los registros. • El personal. Las acciones preventivas son poco frecuentes al inicio de la implementación 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 acción preventiva. Por eso mismo son una potente herramienta de gestión que permite adelantarse a los fallos, economizando recursos y costes. Se pasa de una coyuntura de “apagar fuegos” a controlar la situación y modificarla de acuerdo con las necesidades de la organización.

44

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Tanto en el caso de las acciones preventivas como en el de las correctivas, debe asignarse responsables con nombres y apellidos, y determinar fechas límites de resolución 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 prácticas en seguridad de la información 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 selección de controles. Es decir, cuando se está desarrollando el SGSI, al llegar a dicha tarea, se debe utilizar esta tabla como lista de chequeo 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 capítulos de controles de seguridad, es decir, áreas de la seguridad a considerar, con un total de 39 categorías principales de seguridad, con sus correspondientes objetivos y los controles asociados a esos objetivos, más un capítulo de introducción sobre valoración y tratamiento del riesgo. Los 11 capítulos (acompañados del número de categorías principales de seguridad incluidos dentro de cada capítulo) son los siguientes: • Política de seguridad (1). • Aspectos organizativos de la seguridad de la información (2). • Gestión de activos (2). • Seguridad ligada a los recursos humanos (3). • Seguridad física y del entorno (2). • Gestión de comunicaciones y operaciones (10). • Control de acceso (7). • Adquisición, desarrollo y mantenimiento de los sistemas de información (6). • Gestión de incidentes de seguridad de la información y mejoras (2). • Gestión de la continuidad del negocio (1). • Cumplimiento (3). Para cada uno de los controles la norma proporciona guías para su implementación. Esta norma no es certificable, por lo que las recomendaciones no deben ser consideradas normativas. Las indicaciones que da la norma son bastantes

46

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

exhaustivas, por lo que resultan muy útiles como referencia, pero no son obligatorias. El grado de implementación de cada uno de los controles es algo que la organización debe decidir en función de sus necesidades y recursos disponibles. Y, por supuesto, el modo en que se implementen es de competencia exclusiva de la organización.

3.1. Valoración 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 más apropiados. Esto es precisamente lo que nos ayudará a decidir la valoración 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 más críticos, para no complicar en exceso el análisis de riesgos. Este análisis es una tarea crucial y, en muchos casos, la más laboriosa, por cuanto exige valorar una gran cantidad de parámetros desde múltiples 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 más objetivo posible a los riesgos a los que están expuestos los activos. Para ello existen diversas metodologías, 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 metodologías más aceptadas. Lo importante es elegir aquel método o herramienta que sea fácil de utilizar y que no exija demasiado esfuerzo después para mantener actualizado el análisis de riesgos. Es necesario que el personal de los distintos ámbitos de la organización se implique en la realización del análisis de riesgos. Lo que la norma sí exige es que este análisis sea objetivo y repetible. Para cumplir con el primer requisito resulta casi imprescindible que la mayor parte de las áreas implicadas en el SGSI participen y aporten su punto de vista en el análisis de riesgos. Las distintas perspectivas permitirán obtener un idea más precisa de cuáles son exactamente los peligros y en qué medida pueden afectar a la organización, sobre todo cuando la organización 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 proceso, y saber eso es precisamente lo que se necesita para que el análisis de riesgos sea realista y esté lo menos sesgado posible hacia un área en particular. Cuanto más objetivo sea el análisis y más fácil de utilizar el método o herramienta escogido, mejor se cumplirá el segundo requisito de que el análisis sea repetible. En general, en cualquier metodología o herramienta se proporcionará una lista de posibles amenazas, unas vulnerabilidades que habrá que considerar, y unos baremos

3. Comprender la Norma UNE-ISO/IEC 27002

47

para ponderar la probabilidad y el impacto que ocasionarían en la organización que la amenaza se convirtiese en realidad. Valorando todos los parámetros que nos ofrecen, se obtendrá un valor de riesgo. Señalar que este análisis de riesgos debe efectuarse observando que no existe ninguna medida de seguridad implementada para calcular lo que se llama riesgo intrínseco, 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 dónde radican los mayores riesgos en nuestra organización y, por lo tanto, en qué puntos hay que incrementar el esfuerzo, dónde tendremos que aplicar medidas o mejorar las existentes.

3.2. Política de seguridad El único objetivo de este capítulo es que la organización cuente con una política que refleje sus expectativas en materia de seguridad, a fin de gestionarla con coherencia y soporte. Este capítulo consta de dos controles: • Documento de política de seguridad. El documento de política de seguridad de la información debería establecer el compromiso de la dirección y el enfoque de la organización para gestionar la seguridad de la información. Este documento debería ser aprobado por la dirección y publicado y comunicado a todos los empleados y terceras partes. • Revisión de la política de seguridad. La política de seguridad debe ser un documento vivo, que se revise y actualice periódicamente para que siga siendo adecuado tras los inevitables cambios que sufre toda organización. Al implementar un SGSI según la UNE-ISO/IEC 27001, es obligatorio desarrollar una política de seguridad y mantenerla actualizada, por lo que la mera implementación del sistema ya cumple con estos dos controles.

3.3. Organización de la seguridad Este capítulo tiene dos objetivos: • Organización interna, para gestionar la seguridad de la información dentro de la organización. Los controles de este objetivo son:

48

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– Compromiso de la dirección con la seguridad de la información. La dirección debe respaldar la seguridad de la información y tomar decisiones al respecto, tales como poner objetivos y aprobar el riesgo aceptable, proporcionando recursos y avalando acciones. – Coordinación de la seguridad de la información. Es fundamental que las actividades relativas a la seguridad de la información estén coordinadas para que no haya redundancia o lagunas y produzcan situaciones indeseadas. – Asignación de responsabilidades relativas a la seguridad de la información. Hay que definir claramente quién se va a encargar de cada actividad de seguridad de la información, evitando malentendidos y errores. – Proceso de autorización de recursos para el tratamiento de la información. La gestión de la seguridad debe comenzar en el mismo proceso de compra de cada nuevo recurso de tratamiento de la información. – Acuerdos de confidencialidad. Para proteger adecuadamente la información sensible de la organización, deben establecerse y revisarse de una manera regular cuándo y quién debe firmar este tipo de acuerdo. – Contacto con las autoridades. Sería recomendable mantener los contactos adecuados con las autoridades correspondientes, en particular en lo referente a planes de continuidad del negocio que pueden requerir de contactos en los cuerpos y fuerzas de seguridad del Estado. – Contacto con grupos de interés especial. Dada la complejidad de la seguridad y los numerosos cambios tecnológicos que influyen en cómo hay que enfocarla y tratarla, es fundamental mantenerse al día y conservar el contacto con grupos de interés especial, foros y asociaciones profesionales especialistas en seguridad. – Revisión independiente de la seguridad de la información. Siempre es útil contar con la opinión de terceros, sobre todo si son especialistas en el tema, para que valoren si el enfoque de la organización para la gestión de la seguridad de la información es adecuado y en qué se puede mejorar. La ausencia de presiones internas y la comparación con otras organizaciones o modelos de gestión permite que surja un aporte de cosas nuevas que difícilmente hubieran aflorado internamente. • Terceros. El objetivo aquí es que las medidas de seguridad abarquen también a cualquier tercero que sea susceptible de acceder, procesar, comunicar o gestionar la información de la organización. Los controles para ello son:

3. Comprender la Norma UNE-ISO/IEC 27002

49

– Identificación de riesgos derivados del acceso de terceros. Lógicamente, el primer control será saber cuáles son los riesgos que supone el acceso de terceros a nuestros sistemas e información, para poder implementar los controles adecuados antes de permitir dicho acceso. – Tratamiento de la seguridad en la relación con los clientes. Si a los clientes se les permite acceder a la información, hay que considerar qué requisitos deben cumplir y los sistemas para garantizar la seguridad. – Tratamiento de la seguridad en contratos con terceros. Es crítico que se hagan acuerdos formales con aquellos terceros que posean acceso a recursos de tratamiento de información de la organización. Estos acuerdos deben basarse en un contrato formal que contemple todos los requisitos de seguridad necesarios y que obligue a que se cumplan las políticas y normas de seguridad de la organización. El contrato debe asegurar que no hay malentendidos entre la organización y los terceros. De esta manera la organización puede mantener el mismo control tanto sobre sus usuarios internos como sobre los externos.

3.4. Gestión de activos Los activos de información son los elementos que tratamos de proteger con el SGSI. Los controles de este capítulo están dirigidos a lograrlo. • Responsabilidad sobre los activos. Para conseguir y mantener una protección adecuada sobre los activos de la organización deben existir responsabilidades claras. Hay tres controles para este objetivo: – Inventario de activos. Para poder gestionarlos, es fundamental identificar dichos activos, preparando con esa información un inventario de todos los activos importantes, que habrá de ser mantenido y actualizado. Se necesita un inventario de los recursos de información de la organización para, basándose en este conocimiento, asegurar que se brinda un nivel adecuado de protección. – Propiedad de los activos. Cada uno de los activos contará con un propietario, una parte designada de la organización, y será responsable de su seguridad. – Uso aceptable de los activos. Las reglas básicas para el empleo aceptable de la información y de los activos asociados con los recursos para el tratamiento de la información deben ser documentadas y publicadas, para que se apliquen en toda la organización.

50

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

• Clasificación de la información, para asegurar que la información recibe un nivel adecuado de protección en función de su criticidad. Existen dos controles: – Directrices de clasificación. Debe clasificarse la información de acuerdo a su sensibilidad y criticidad, su valor para la organización y el daño que ocasionaría su fuga o filtración, para así poder adoptar las medidas de seguridad adecuadas a cada nivel de protección. – Etiquetado y manipulado de la información. La información debe ser marcada y tratada de acuerdo con el esquema de clasificación adoptado por la organización. El etiquetado de la información puede realizarse de diferentes formas, pero debería hacerse de modo que se distinga fácilmente el tipo de información que contiene el documento.

3.5. Seguridad ligada a los recursos humanos Este capítulo 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. También determina cómo incide el papel que los empleados desempeñan en materia de seguridad en el funcionamiento general de la compañía. Ante la contratación de personal deben tomarse medidas de seguridad previas a la contratación, durante el período que dure el contrato y al concluir. Este capítulo marca tres objetivos: • Antes del empleo, para asegurar que cualquier persona que entre a formar parte de la organización (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 utilización 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. – Investigación de antecedentes. Para según qué puestos puede ser especialmente relevante comprobar los antecedentes de todos los candidatos a ejercer el trabajo. Esta comprobación deberá efectuarse de acuerdo a la legislación vigente y de una manera proporcionada a los requisitos del negocio y de seguridad de la organización.

3. Comprender la Norma UNE-ISO/IEC 27002

51

– Términos y condiciones de contratación. Los contratos deberán reflejar, junto con los términos del acuerdo, las obligaciones y responsabilidades de las dos partes en lo relativo a seguridad de la información. • Durante el empleo, para que en el trabajo cotidiano todo el mundo se encuentre concienciado en materia de seguridad y ponga en práctica la política de seguridad de la organización, reduciendo el riesgo de error humano. Este objetivo cuenta con tres controles: – Responsabilidades de la dirección, que es la que debe establecer las directrices a seguir y exigir su cumplimiento, tanto a los empleados como a contratistas y terceros. – Concienciación, formación y capacitación en seguridad de la información. Hay que poner en conocimiento de los implicados las políticas y procedimientos de la organización, y proporcionar la formación adecuada para que las puedan ejecutar. – Proceso disciplinario. Debe existir algún mecanismo de penalización para las infracciones de seguridad que sirva como método de disuasión. • Cese del empleo o cambio de puesto de trabajo, para lograr que cuando alguien deja de trabajar con la organización o cambia la relación 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 algún empleado, para efectuarlo correctamente. – Devolución 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 contrato o el acuerdo con un empleado o contratista, deben retirarse todos los derechos de acceso a la información y a los recursos de tratamiento de la información o bien deben ser adaptados a los cambios producidos.

3.6. Seguridad física y del entorno Este capítulo responde a la necesidad de proteger físicamente las áreas en las que se encuentran los equipos y la información. Los mecanismos de protección para el

52

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

sistema de información de la organización pasan por definir un perímetro físico de seguridad que impida el acceso no autorizado a la información y eviten daños por eventos, tales como fuego, inundación, terremoto, explosión, 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 físicos no autorizados, los daños y las intromisiones en las instalaciones y en la información de la organización. Podemos utilizar los siguientes controles: – Perímetro de seguridad física. Barreras, muros, puertas de entrada con restricciones (recepción, cerraduras, control a través de tarjeta, etc.), cualquier medio que sirva para proteger las zonas en las que se encuentra la información y los sistemas de información formarán parte de este primer control. – Controles físicos de entrada. Las áreas en las que sólo el personal autorizado puede entrar deben poseer controles de entrada apropiados que restrinjan el acceso. – Seguridad de oficinas, despachos e instalaciones. También estos recintos deben contar con medidas razonables que permitan mantener la información y los sistemas bajo control. – Protección contra las amenazas externas y de origen ambiental. Tanto por la magnitud de los daños que pueden ocasionar estas amenazas, como por la legislación que controla este punto, se deben aplicar las medidas apropiadas contra el daño causado por fuego, inundación, terremoto y otros desastres, tanto naturales como provocados por el hombre. – Trabajo en áreas seguras. Por su especial sensibilidad, las áreas seguras contarán, además de con medidas de protección física, con directrices para trabajar en ellas. – Áreas de acceso público y de carga y descarga. Puesto que estos puntos son vulnerables a accesos no autorizados, deberán controlarse con cuidado y, en la medida de lo posible, mantenerlos alejados y aislados de aquellas zonas en las que residan los sistemas de información. • Seguridad de los equipos, para que las actividades de la organización no se interrumpan debido a daños en los equipos, robo de activos o pérdidas de los mismos. Los controles definidos para este objetivo son: – Emplazamiento y protección de equipos. Los equipos deben situarse en lugares seguros, protegidos de riesgos ambientales (agua, luz, viento, etc.)

3. Comprender la Norma UNE-ISO/IEC 27002

53

que puedan dañarlos. Asimismo, se ubicarán allí donde su acceso resulte complicado para personas no autorizadas. – Instalaciones de suministro. Los equipos pueden dañarse si se producen fallos en el suministro eléctrico o en las comunicaciones, por lo que es recomendable que tengan alguna protección para evitar problemas si suceden estos fallos, especialmente si se trata de equipos muy críticos. – Seguridad del cableado. Puesto que el cableado hace posible que los equipos funcionen, se instalará de manera que se eviten daños, que impidan interceptaciones o que dificulten una fuga de información. – Mantenimiento de los equipos. Otro punto crucial para que los equipos funcionen correctamente es que se sometan a un mantenimiento, preventivo y correctivo, que asegure su disponibilidad y su integridad. – Seguridad de los equipos fuera de las instalaciones. Cuando los equipos están fuera de las instalaciones de la organización, el nivel de seguridad debe ser el mismo, aunque las circunstancias no lo sean, por lo que deben diseñarse y aplicarse las medidas de seguridad adecuadas a estos equipos. – Reutilización o retirada segura de equipos. Los equipos almacenan información que debe ser eliminada (sobre todo si es sensible) cuando son retirados o se van a reutilizar. Para evitar problemas, esta eliminación se comprobará antes de retirarlos o ponerlos en uso de nuevo. – Retirada de materiales propiedad de la empresa. Hay que autorizar y registrar las salidas de equipos para poder controlar la información o software en todo momento, de manera que se sepa quién es el responsable de los activos y dónde se encuentran.

3.7. Gestión de comunicaciones y operaciones Este es el capítulo con más objetivos y controles, y el más técnico de toda la norma. Aquí se recogen los controles técnicos, puesto que se trata de proteger el funcionamiento y las operaciones de los sistemas de información. Hay que tener en cuenta que el origen de esta norma se encuentra en grandes empresas y corporaciones con sistemas de información muy sofisticados y amplios. En el contexto de una pyme, es aquí donde se hace más relevante realizar el esfuerzo de escalar hacia abajo los requisitos planteados por la norma. Muchos de los controles de este capítulo no serán aplicables en el contexto de una pyme típica, a menos que

54

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

su negocio posea implicaciones que los hagan necesarios, y desde luego la implementación de los que sí son aplicables tiene que ser lo más sencilla que seamos capaces de diseñar. 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 pequeño dispositivo USB que se pueda transportar cómodamente fuera de las instalaciones a un lugar seguro. Este capítulo contiene diez objetivos: • Responsabilidades y procedimientos de operación. Para encargarse eficazmente de que los sistemas de información funcionen de manera correcta y segura, será necesario establecer las responsabilidades y procedimientos para la gestión de todos los recursos de información, reduciendo los riesgos de negligencia o uso indebido. Los controles son: – Documentación de los procedimientos de operación. Siempre hay una forma más 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 configuración de accesos, etc. – Gestión de cambios. Los sistemas de información y las aplicaciones deben estar bajo control de cambios, ya que éstos son una fuente importante de errores y fallos. Esta gestión del cambio tiene que incluir la identificación de los cambios, su aprobación, la planificación de cómo y cuándo van a ser incorporados, las pruebas que se efectuarán, siempre fuera del entorno de producción, y cuál será el procedimiento para deshacerlos si sucede algún evento imprevisto. – Segregación de tareas. Hay que separar las diversas áreas de responsabilidad para evitar usos o accesos indebidos, accidentales o intencionados, de la información. Esta segregación puede resultar difícil de emprender en organizaciones pequeñas, pero el principio debería aplicarse en la medida en que sea posible y práctico. – Separación de los recursos de desarrollo, prueba y operación. Siguiendo el mismo principio anterior, es necesario separar el entorno donde se realicen desarrollos del entorno de prueba, y por supuesto los entornos de producción deben permanecer aislados del resto, así se eliminan riesgos de accesos no autorizados o cambios no deseados. Deberían 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.

3. Comprender la Norma UNE-ISO/IEC 27002

55

• Gestión de la provisión de servicios por terceros. Estos servicios deben tener el mismo nivel de seguridad que los internos, por lo que se establecerán acuerdos en los que se recogerán estos requisitos, comprobándose el cumplimiento de los acuerdos y gestionando los cambios necesarios para asegurar que los servicios entregados son conformes con lo estipulado. Los controles son tres: – Provisión de servicios. Se establecerán acuerdos de nivel de servicio con todos los requisitos necesarios para que se cumplan las expectativas, tanto funcionales como de seguridad, para la provisión del servicio. Estos acuerdos establecerán las normas para el intercambio de información y las responsabilidades de los contratistas respecto a los activos de información a los que tengan acceso. – Supervisión y revisión de los servicios prestados por terceros. Ha de mantenerse un control para garantizar que los servicios se suministran según los acuerdos establecidos, incluso realizando auditorías cuando sea pertinente. Para ello se revisarán los informes entregados y los registros generados por la actividad, y se comprobará que los incidentes y problemas de seguridad de la información se gestionan y resuelven adecuadamente. – Gestión del cambio en los servicios prestados por terceros. En la línea de mantener el mismo nivel de seguridad en los servicios suministrados por terceros que en los internos, también los cambios deben ser gestionados en dichos servicios. Durante su provisión pueden darse cambios para mejorar los servicios, nuevos desarrollos, modificaciones de las políticas y procedimientos de la organización, cambios tecnológicos, etc. Ha de existir un procedimiento claro para incorporar estos cambios a los servicios de una forma eficaz. • Planificación y aceptación del sistema, de modo que se eviten fallos de los sistemas por sobrecargas y fallos de disponibilidad. Existen dos controles: – Gestión 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. – Aceptación del sistema. Se deberían establecer, documentar, y probar previamente a su aceptación y uso los requisitos operacionales de los sistemas nuevos, así se evitarían fallos, incluso aunque se trate de una simple actualización. • Protección contra código malicioso y descargable. Evitar virus, troyanos y el resto de los tipos de código malicioso sirve para proteger la integridad del software y de la información.

56

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– Controles contra el código malicioso. La protección contra este riesgo tiene dos vertientes, la técnica y la humana. Deben instalarse sistemas de detección, prevención y recuperación que protejan contra código malicioso. Además se deben realizar procedimientos adecuados de concienciación para que todos los usuarios sean conscientes de los problemas que genera el código malicioso y cómo proceder cuando se reciban correos engañosos. – Controles contra el código descargado en el cliente. Si se autoriza el uso de código descargado en el cliente (JavaScript, VBScript, applets de Java applets, controles ActiveX, etc.), la configuración debe garantizar que dicho código autorizado funciona de acuerdo con una política de seguridad claramente definida. Cualquier uso y recepción de código ambulante no autorizado ha de bloquearse. Los ataques del código móvil pueden modificar la información, robar las contraseñas o archivos, redireccionar los accesos telefónicos por módem o lanzar un ataque de denegación de servicio, por lo que hay que ser especialmente precavidos en este punto. • Copias de seguridad. Realizar copias de la información ayuda a mantener la integridad y disponibilidad de la misma y de los recursos de tratamiento de la información, ya que en caso de incidente se podría recuperar rápidamente. Este objetivo sólo tiene un control: – Copias de seguridad de la información. Deberían establecerse procedimientos para efectuar las copias de seguridad de acuerdo con la frecuencia y amplitud que recomienden la sensibilidad y criticidad de la información gestionada. Además, las copias han de comprobarse regularmente para verificar que la información es y permanece correcta y completa, y ensayar los tiempos de recuperación. Se ha convertido en un requisito básico contar con una copia de seguridad fuera de las instalaciones de la organización, lo cual garantiza la disponibilidad de la información incluso en caso de desastre. • Gestión de la seguridad de las redes. Por pequeña que sea la organización, lo más corriente es que cuente con una red por la que circulan las comunicaciones digitales y la información. Este objetivo trata de asegurar esta infraestructura para evitar incidentes. – Controles de red. Para proteger la red, en primer lugar, debe estar gestionada 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 través

3. Comprender la Norma UNE-ISO/IEC 27002

57

de ellas y los dispositivos que protegen las aplicaciones y los sistemas conectados son críticas aquí, así como mantener logs con información que pueda ayudar a detectar fallos, errores o ataques. – Seguridad de los servicios de red. Dado el gran número 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 subcontratan. Esto incluirá las necesidades de autenticación de usuarios, de cifrado de datos, de control de conexiones, requisitos de acceso para usuarios remotos, etc. • Manipulación de los soportes. La información puede estar en varios formatos y soportes, por lo que protegerlos es básico para evitar que se revele o destruya información o se interrumpan las actividades de la organización. – Gestión de soportes extraíbles. La proliferación de este tipo de soportes (discos ópticos, lápices USB, discos duros externos…) hace necesario establecer normas para su utilización. – 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 información que contengan pueda llegar a personas no autorizadas. – Procedimientos de manipulación de la información. Se deberían establecer procedimientos para tratar y almacenar la información. El objetivo es impedir que dicha información sea revelada sin autorización o que se la dé un mal uso, por ejemplo, se recomienda que se etiqueten los soportes según la clasificación de la información 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 documentación del sistema. Es importante mantener segura esta información, ya que contiene datos valiosos para la organización, por ejemplo, las descripciones de las aplicaciones de los procesos, las estructuras de datos y los procesos de autorización. • Intercambio de información. Un SGSI debe proteger la información a lo largo de todo su ciclo de vida, en muchos momentos de este ciclo la información saldrá de la organización 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:

58

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– Políticas y procedimientos de intercambio de información. Se deberían establecer procedimientos y normas para proteger la información y los soportes físicos que contienen información en tránsito. – Acuerdos de intercambio. El intercambio de información 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 información, cómo va a ser etiquetada la información sensible o crítica, las normas técnicas para el registro y lectura de la información y del software, etc. – Soportes físicos en tránsito. Para que la información esté segura cuando se encuentre en tránsito deben protegerse los soportes, utilizando mensajeros y transportistas de confianza, embalando bien los soportes, etc. – Mensajería electrónica. Se establecerán normas de seguridad para el uso del correo electrónico, las cuales recogerán las medidas de seguridad mínimas para garantizar un empleo responsable y seguro del servicio, en particular cuando se utilice para el envío de información confidencial. – Sistemas de información empresariales. Se deberían desarrollar y aplicar políticas y procedimientos para proteger la información que se va a compartir con otros sistemas de información pertenecientes a otras organizaciones, definiendo qué información puede ser compartida, por quién, las responsabilidades de cada parte, etc. • Servicios de comercio electrónico. 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 electrónico, se pueden utilizar los siguientes controles: – Comercio electrónico. Es vital que toda la información incluida en el comercio electrónico se proteja contra actividades fraudulentas, disputas contractuales y revelación o modificación no autorizada de dicha información. – Transacciones en línea. Estas transacciones son muy vulnerables a errores o fallos de transmisión o de direccionamiento, alteraciones no autorizadas de los mensajes, así como revelación, duplicación o reproducción no autorizadas del mensaje, por lo que han de ser correctamente protegidas. – Información puesta a disposición pública. La integridad de la información destinada a hacerse pública debe protegerse para impedir modificaciones no autorizadas que dañen la reputación de la organización. • Supervisión. La única manera de detectar a tiempo las actividades de procesamiento de la información no autorizadas es llevando a cabo una supervisión

3. Comprender la Norma UNE-ISO/IEC 27002

59

que las ponga en evidencia. El nivel de monitorización está basado en el nivel de riesgo del negocio, cuanto más riesgo mayor debería ser el nivel de vigilancia. Los controles son: – Registro de auditorías. 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 política de acceso, las alertas por fallos, etc. Estos registros deben ser almacenados durante un período acordado para servir como prueba en investigaciones futuras y en la supervisión del control de acceso. – Supervisión del uso del sistema, para verificar que los recursos del sistema se utilizan debidamente. – Protección de la información de los registros. Debido a la sensibilidad de los dispositivos de registro y la información generada por ellos, deben ser protegidos contra manipulaciones indebidas y accesos no autorizados. – Registros de administración y operación. Los registros del administrador del sistema y del operador del sistema deberían ser revisados regularmente, de manera que se compruebe que se cumplen las actividades del sistema y de la administración de la red. – Registro de fallos. Registrar los fallos, tanto de los usuarios como de las aplicaciones, es el primer paso hacia una correcta gestión de los mismos hasta su resolución. Deberían existir reglas precisas para el tratamiento de los informes de fallos, incluyendo la revisión de los registros y el cumplimiento de las medidas correctivas tomadas. – Sincronización del reloj. En caso de incidencias, teniendo todos los equipos sincronizados, se podrá comprobar qué equipos estaban conectados en el sistema de información, y al observar los registros de dichos equipos, se podrá llegar a una conclusión sobre lo sucedido.

3.8. Control de acceso Este capítulo trata de las medidas a tomar cuando se desee monitorizar y controlar el acceso a la red y los recursos de información, y de la protección existente contra los abusos internos y los intrusos externos, dada la importancia que tienen para la organización sus activos. Por lo tanto, el objetivo de este grupo de controles es regular el acceso a la información, de acuerdo con los requisitos de negocio y los de seguridad, que se puede obtener aplicando alguno de los siete objetivos de control definidos:

60

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

• Requisitos de negocio para el control de acceso, de manera que sólo accedan a la información quienes estén autorizados para ello. Tiene un control: – Política de control de acceso. En primer lugar hay que definir y documentar cuáles van a ser las líneas de actuación en la organización 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 mayoría de la información y restringir sólo una parte, o bien darle a cada uno acceso sólo a aquella información que necesita. • Gestión de acceso de usuario, de manera que sólo los usuarios autorizados pueden acceder a la información y los sistemas, mientras que aquellos que no lo estén no puedan hacerlo. Se utilizarán 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 procedimiento formal que evite errores en la asignación de permisos, en la medida de lo posible. – Gestión de privilegios. Los privilegios otorgados a los usuarios deben estar debidamente autorizados, según su necesidad de uso, manteniendo un registro para controlar su utilización. – Gestión de contraseñas de usuario. Es uno de los controles más difundidos y más eficaces para el control de accesos, siempre que esté bien implementado y gestionado. Para conservar la eficacia de las contraseñas es fundamental que permanezcan confidenciales, por lo que se debe concienciar al personal sobre este punto. Las contraseñas deben tener mayor complejidad (más caracteres, mezclar números, letras y símbolos) según la criticidad de las aplicaciones o la información a la que se acceda, y deben ser cambiadas frecuentemente, como mínimo una vez al año. – Revisión 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 técnicas implementadas no podrán evitar que se cometan errores, como apuntar contraseñas en un papel o dejar informes confidenciales en la impresora. 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

3. Comprender la Norma UNE-ISO/IEC 27002

61

los controles orientados a prevenir el acceso de usuarios no autorizados, y evitar robos de información o equipos causados por las malas prácticas de los usuarios. – Uso de contraseña. Los usuarios deben seguir buenas prácticas de seguridad en la selección y el uso de las contraseñas: mantener su confidencialidad, no compartirlas, no emplear la misma contraseña para propósitos profesionales que para no profesionales, no guardarla en papel o en un fichero de software fácil 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 información que están utilizando. Para evitar incidentes no deseados, las pantallas y los equipos deberán bloquearse pasado un período de inactividad, por ejemplo, con un protector de pantalla con contraseña. – Política de puesto de trabajo despejado y pantalla limpia. Tanto las mesas de trabajo como los equipos informáticos del puesto son dos elementos del sistema de información susceptibles de fugas de información, por lo que deben establecerse normas y mecanismos para que el personal mantenga tanto la mesa como la pantalla sin información visible, papeles o medios de almacenamiento extraíbles, que puedan comprometer la confidencialidad de los datos. • Control de acceso a la red. Los sistemas de información actuales cuentan con redes que son vulnerables a accesos no autorizados, por lo que deben ser protegidas. Los controles para ello son: – Política de uso de los servicios en red. Hay que establecer cómo se va a utilizar la red y sus servicios, y definir cómo se van a asignar los accesos. Esta política deberá ser coherente con la política de accesos de la organización. – Autenticación de usuario para conexiones externas. Si los usuarios van a conectarse en remoto a la red, hay mayores riesgos que en una conexión interna, por lo que la autenticación debe ser más rigurosa, sobre todo si se utilizan redes inalámbricas. Los métodos de autenticación se escogerán tanto más seguros según la valoración del riesgo que se haya hecho de la información 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 contraseña, si se va a trabajar con redes públicas puede ser necesario utilizar, por ejemplo, técnicas criptográficas o dispositivos biométricos.

62

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– Identificación de los equipos en las redes. De esta manera se pueden autenticar las conexiones provenientes de localizaciones y equipos específicos. Los identificadores de los equipos indicarán claramente a qué red se permite al equipo la conexión, si existe más de una red y, en particular, si estas redes tienen distinto grado de sensibilidad. Se puede aplicar la identificación del equipo adicionalmente a la identificación de usuario, reforzándola. – Diagnóstico remoto y protección de los puertos de configuración. Cuando sea necesario mantener un puerto abierto para estas tareas, se debe controlar tanto el acceso físico como el lógico permitido para este puerto. – Segregación de las redes. Cuando sea oportuno y práctico, se separarán en redes distintas los servicios de información, los de usuarios y los sistemas, evitando así filtraciones o modificaciones de la información. – Control de la conexión 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 necesidades de acceso, así que, para evitar problemas, lo más 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 encaminamiento (routing) de redes se implementan para evitar que la información llegue a un destino distinto del requerido, de manera que las conexiones de los ordenadores y los flujos de información estén de acuerdo con la política de control de acceso de la organización. • Control de acceso al sistema operativo, para prevenir accesos indebidos a los sistemas operativos que provoquen daños en las aplicaciones e inestabilidades de los sistemas. Los controles a utilizar para alcanzar este objetivo son: – Procedimientos seguros de inicio de sesión. Las sesiones deben ser iniciadas con un procedimiento que no facilite a un usuario no autorizado la entrada ni revele información del sistema y que limite los intentos de entrada para bloquearlos. – Identificación y autenticación de usuario. Cada usuario deberá tener un identificador único (ID de usuario) para su uso personal y exclusivo, así se logrará que su autenticación sea fiable, de manera que se puedan seguir sus actividades y, si es necesario, exigir responsabilidades. – Sistema de gestión de contraseñas. Gestionar las contraseñas necesita de la colaboración del personal y servirán a su propósito en función de la calidad

3. Comprender la Norma UNE-ISO/IEC 27002

63

y robustez de las mismas. Donde sea posible, se permitirá a los usuarios escoger sus propias contraseñas, 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 aplicación, por lo que su uso debería estar restringido a los usuarios que realmente lo necesiten y encontrarse estrictamente controlado. – Desconexión automática de sesión. Las sesiones abiertas son oportunidades para realizar accesos no autorizados, por lo que debe establecerse un tiempo tras el cual, si no ha habido actividad, la sesión caducará. – Limitación del tiempo de conexión. 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 información. Las aplicaciones y la información que contienen son elementos muy sensibles de los sistemas de información, que deben ser protegidos contra accesos no autorizados para evitar fallos de confidencialidad o de integridad. Existen dos controles para este objetivo: – Restricción del acceso a la información. Debe seguirse la política de accesos de la organización, de manera que el acceso se conceda a los usuarios autorizados para ello. Además, 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 información son particularmente críticos, deberían estar alojados en entornos protegidos con equipos dedicados, aislados del resto de los sistemas. • Ordenadores portátiles y teletrabajo. Este tipo de equipos y modo de trabajo se va extendiendo cada vez más, con la mejora del hardware, el software y las comunicaciones, pero son muy vulnerables, por lo que hay que ser especialmente escrupuloso para garantizar su seguridad. – Ordenadores portátiles y comunicaciones móviles. 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 utilización específicas encaminadas a protegerlos adecuadamente, tales como la protección física, los controles de acceso, las técnicas criptográficas, las copias de respaldo y la protección antivirus.

64

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– 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 organización, deben existir unas normas que consideren aspectos como la seguridad física en el lugar de teletrabajo y las comunicaciones. Es imprescindible contar con una definición del trabajo permitido, las horas de trabajo, la clasificación de la información que puede mantenerse en el equipo, y los sistemas y servicios a los que el teletrabajador está autorizado a acceder, que garanticen unos mínimos de seguridad.

3.9. Adquisición, desarrollo y mantenimiento de los sistemas En toda labor de la tecnología de la información 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 información. El objetivo específico de este grupo de controles es garantizar que la seguridad sea una parte integral de los sistemas de información, desde su concepción hasta su retirada. • Requisitos de seguridad de los sistemas de información. Si queremos garantizar una seguridad integrada en los sistemas de información es fundamental que los requisitos de seguridad sean explícitos y estén documentados. El control es claro: – Análisis y especificación 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 incorporación a los sistemas de información no cree problemas, los requisitos de seguridad deberán ser incorporados a las especificaciones junto con el resto de los requisitos funcionales y técnicos. • Tratamiento correcto de las aplicaciones. Las aplicaciones deben procesar correctamente la información introducida en ellas para evitar errores, pérdidas, modificaciones no autorizadas o usos indebidos de dicha información. Para alcanzar este objetivo los controles a aplicar son: – Validación de los datos de entrada. El primer paso será comprobar que los datos de entrada en las aplicaciones son válidos, es decir, la aplicación 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 formato es aceptable, que son coherentes, etc.

3. Comprender la Norma UNE-ISO/IEC 27002

65

– Control del procesamiento interno. La validación de los datos debe continuar durante su procesamiento. La aplicación ha de contar con mecanismos que detecten información corrupta, si los resultados no encajan con lo esperado o si la información 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. – Validación de los datos de salida. Terminado el tratamiento de la información, se deben validar los datos obtenidos comprobando que son coherentes con lo esperado, verosímiles y razonables, ya que a pesar de que se han podido tomar todas las precauciones posibles en anteriores etapas del procesamiento de la información, se pueden producir errores en la salida que invaliden los datos. • Controles criptográficos. Cuando la sensibilidad de los datos o su criticidad hacen recomendable utilizar técnicas criptográficas para protegerlos, los controles a aplicar son: – Política de uso de los controles criptográficos. Estas medidas tan especiales son costosas, por lo que debe haber una política para aplicarlas de manera coherente con las necesidades de la organización. – Gestión de claves. El uso de técnicas criptográficas implica una gestión de las claves que les dan soporte, lo cual incluirá tener normas para la generación de claves, su uso y su distribución a los usuarios autorizados, protegiéndolas en todo momento. • Seguridad de los archivos de sistema. Estos archivos, incluyendo el código fuente, son activos de información de los que dependen en gran medida la seguridad de los datos almacenados en los sistemas. Por ello, debe controlarse el acceso y manipulación de estos archivos. Los controles son: – Control del software en explotación. Para controlarlo adecuadamente deben existir procedimientos para efectuar la instalación y actualización de software en los sistemas operativos, incluyendo el modo de restaurar el programa inicial si falla la instalación. Estas tareas deberán ser ejecutadas por administradores con la adecuada formación y autorización para ello, y sólo tras haber realizado pruebas que garanticen la ausencia de problemas tras la instalación. – Protección 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

66

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

al seleccionarlos, mantenerlos protegidos mientras duran las pruebas y eliminarlos de ese entorno en cuanto concluyan. – Control de acceso al código fuente de los programas. Un acceso indebido pondría en peligro la integridad de los programas, por lo que debe tomarse medidas, tales como mantener el código fuente fuera de los entornos de producción 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 técnica podrá acceder sólo a aquellos programas que precisen. • Seguridad en los procesos de desarrollo y soporte. Cuando se desarrolla software o se proporcionan servicios de asistencia técnica, 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 minimice el riesgo de incidentes. – Revisión técnica de las aplicaciones tras efectuar cambios en el sistema operativo. Los sistemas operativos son susceptibles de cambios por diversos 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 organización considere críticas. – Restricciones a los cambios en los paquetes de software. Es casi inevitable tener que realizar cambios a los paquetes de software en algún momento de su vida útil, pero para evitar problemas con su integridad o el de la información que manejan, sólo se deben efectuar los cambios estrictamente necesarios, por personal autorizado y que controle perfectamente todo el proceso. – Fugas de información. Al desarrollar software se deben prever situaciones que permitan fugas de información, para ello se supervisará al personal, las actividades del sistema, el uso de los recursos, se escanearán las comunicaciones para detectar información oculta, etc. – Externalización del desarrollo de software. Cuando se subcontrata el desarrollo de software, deben establecerse los mecanismos apropiados para supervisar dicho desarrollo, de manera que los requisitos establecidos sean incorporados 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.

3. Comprender la Norma UNE-ISO/IEC 27002

67

• Gestión de las vulnerabilidades técnicas. Los sistemas de información están 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 técnicas. Hay que esforzarse para mantenerse al día en lo relativo a las vulnerabilidades técnicas de los sistemas de información que están siendo utilizados. Con esa información 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 fabricante, pero al menos hay que considerarlo y tomar una decisión documentada.

3.10. Gestión 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 daños originados. Los objetivos y controles de este capítulo tratan precisamente de cómo hacerlo: • Notificación de eventos y puntos débiles de la seguridad de la información. En muchas ocasiones no se solucionan los problemas porque no existen canales de comunicación apropiados para comunicarlos. El objetivo consiste en asegurarse de que los eventos y las vulnerabilidades de la seguridad de la información se comunican, y así puedan buscarse soluciones. – Notificación de los eventos de seguridad de la información. Todos aquellos en contacto con los sistemas de información, trabajadores, contratistas y terceros, deberían tener instrucciones claras sobre cómo proceder en caso de que detecten algún evento de seguridad, a quién deben comunicárselo y de qué forma. – Notificación de los puntos débiles de la seguridad. Como en el control anterior, cualquier usuario de los sistemas y la información, tanto los internos como los externos, deben estar obligados a notificar cualquier punto débil que observen o que sospechen que exista. • Gestión de incidentes de seguridad de la información y mejoras. Para solucionar eficazmente los incidentes que ocurran deben tomarse medidas estudiadas y coherentes. Los controles a aplicar son:

68

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– Responsabilidades y procedimientos. Deben existir responsabilidades y procedimientos, de manera que se pueda dar una respuesta rápida a los incidentes. Quizás sea necesario establecer distintos niveles de soporte de incidentes en función del tipo y complejidad de los mismos. – Aprendizaje de los incidentes de seguridad de la información. Si se registran los tipos, volúmenes y costes de los incidentes de seguridad de la información, pueden detectarse incidentes recurrentes o con un elevado alcance. Esto permitiría adoptar decisiones informadas para la mejora de los controles o para añadir nuevos, que eviten gastos innecesarios. – Recopilación de evidencias. Es necesario llevar a cabo este control con rigurosidad 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. Gestión de la continuidad del negocio En caso de desastre, la organización debe estar preparada para continuar con sus actividades en el menor plazo de tiempo posible para evitar su desaparición. Los peligros de ataque terrorista o desastres casuales, que se materializan de cuando en cuando y llenan páginas en los periódicos, han hecho que ahora se perciban más necesarios este tipo de actividades. Un plan de continuidad se puede definir como el conjunto de instrucciones y procedimientos que van a seguirse en una organización 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 mayoría de las organizaciones. Un corte de luz de horas puede comprometer algunas operaciones de la organización y deberán existir procedimientos para paliar esta situación. Un corte de luz de días es muy probable que requiera un plan de continuidad en toda regla para impedir que la organización 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 organización debe formarse adecuadamente en estos procedimientos: • Aspectos de seguridad de la información en la gestión de la continuidad del negocio. Aun en el caso de que exista algún plan de continuidad en la organización, no es habitual que se contemplen los aspectos relacionados con los sistemas de información y la información misma. Pero una organización no

3. Comprender la Norma UNE-ISO/IEC 27002

69

puede subsistir sin su información, por lo que garantizar su seguridad debe ser un elemento clave de cualquier plan de continuidad. – Inclusión de la seguridad de la información en el proceso de gestión de la continuidad del negocio. Debería desarrollarse y mantenerse un proceso controlado para la continuidad del negocio en toda la organización que trate los requisitos de seguridad de la información necesarios, como cuáles son los activos que soportan los procesos críticos de negocio y cuáles serían las consecuencias de incidencias en dichos activos. – Continuidad del negocio y evaluación de riesgos. Una de las tareas fundamentales para desarrollar un plan de continuidad del negocio es el análisis del impacto en él, es decir, un análisis de riesgos donde se identifican las incidencias que pueden suponer una interrupción de las actividades, la probabilidad de que ocurran, sus efectos y sus consecuencias en el tiempo. – Desarrollo e implementación de planes de continuidad que incluyan la seguridad de la información. Los planes de continuidad de negocio deben permitir la recuperación y restauración de las operaciones de negocio y la disponibilidad de la información en los plazos identificados. Para trazar un plan de continuidad se debe: √ Identificar los objetivos y los responsables de las distintas fases. √ Identificar las pérdidas aceptables de información o servicios. √ Definir las escalas temporales en las que deben estar restablecidos los servicios y la información. – Marco de referencia para la planificación de la continuidad del negocio. Un marco de referencia de un plan de continuidad del negocio identifica los requisitos de seguridad de la información, además tendrá en cuenta los aspectos generales, tales como en qué condiciones se activarán los planes, cuáles son los procedimientos de emergencia, medidas para proteger la imagen y reputación de la organización, y formación del personal para que pueda ejecutar sus tareas y responsabilidades adecuadamente en caso de crisis. – Pruebas, mantenimiento y revaluación 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.

70

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

3.12. Cumplimiento Este capítulo trata de garantizar que los sistemas cumplen con las políticas y normas de seguridad de la organización, 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 legislación aplicable a la organización, evitando infracciones que pueden resultar muy dañinas tanto en términos económicos como de reputación para la organización. En nuestro país, las principales leyes que afectan a la mayoría de las organizaciones son: – Ley Orgánica 15/1999, de 13 de diciembre, de Protección de datos de carácter personal y Real Decreto 994/1999, de 11 de junio, por el que se aprueba el Reglamento de Medidas de seguridad de los ficheros automatizados que contengan datos de carácter 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 regulación de las telecomunicaciones, sobre la explotación de las redes y la prestación de los servicios de comunicaciones electrónicas y los recursos asociados. – Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSI). Los controles a aplicar son: – Identificación de la legislación aplicable. El responsable de seguridad, junto con los servicios jurídicos de la organización, debe mantener actualizada una lista de legislación vigente aplicable y ocuparse de que cumplan con ella los que tengan responsabilidades relativas a la aplicación de la ley. – Derechos de Propiedad Intelectual (DPI). La organización debe contar con procedimientos que garanticen un uso correcto de material con derechos de propiedad intelectual, incluyendo el software propietario. – Protección de los documentos de la organización. En toda organización existen documentos importantes por diversos motivos, que deben protegerse adecuadamente frente a pérdidas, destrucción y falsificación. – Protección de datos y privacidad de la información de carácter personal. El procedimiento deben seguirlo todos los empleados con acceso a datos

3. Comprender la Norma UNE-ISO/IEC 27002

71

personales, bien a través del sistema informático habilitado para acceder a los mismos o bien a través de cualquier otro medio. – Prevención del uso indebido de los recursos de tratamiento de la información. La organización debe tener medidas que impidan que los usuarios recurran a los sistemas de información para usos indebidos. – Regulación de los controles criptográficos. Estos controles están sujetos a leyes y regulaciones, posiblemente también a acuerdos con otras organizaciones, por lo que deben existir normas para su correcta utilización. • Cumplimiento de las políticas y normas de seguridad, y cumplimiento técnico. El SGSI contiene numerosas políticas y normas a seguir, por lo que hay que efectuar un seguimiento para comprobar en qué medida se cumplen. – Cumplimiento de las políticas 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 llevarán a cabo auditorías internas o externas que detecten las posibles no conformidades. – Comprobación del cumplimiento técnico. Deben realizarse chequeos periódicos de los sistemas para verificar que se están aplicando los controles y medidas definidos en el sistema, para detectar posibles errores u omisiones que comprometan la seguridad de la información. • Consideraciones sobre la auditoría de los sistemas de información. Objetivo: lograr que el proceso de auditoría de los sistemas de información alcance la máxima eficacia con las mínimas interferencias. – Controles de la auditoría de los sistemas de información. Las auditorías informáticas son herramientas muy útiles para detectar vulnerabilidades y puntos de mejora, pero por su propia naturaleza hay que ser cuidadosos al planificarlas y diseñarlas, de manera que no interfieran o interrumpan las actividades habituales de la organización. – Protección de las herramientas de auditoría de los sistemas de información. Un uso indebido de estas herramientas, intencionado o no, puede ser muy perjudicial, por lo que deben estar protegidas y el acceso a ellas debería encontrarse restringido.

4

Definición e implementación de un SGSI

4.1. El proyecto Básicamente, un proyecto de definición 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: • Definición del alcance, los objetivos y la política de seguridad. Debe cubrir todos los aspectos de la seguridad: seguridad física, seguridad lógica, seguridad del personal, y adecuarse a las necesidades y recursos de la organización. • Desarrollar el inventario de activos. Hay que tener presente cuáles son los activos más valiosos, que a la vez pueden ser los más vulnerables. • Realizar el análisis de riesgos. Cada uno de los pasos ha de ser documentado en el análisis de riesgos, con las valoraciones de todos los parámetros implicados: amenazas que afectan a cada activo, nivel de vulnerabilidad, probabilidad de ocurrencia y los efectos que podría suponer que se materializara la amenaza, es decir, que una amenaza explorara la vulnerabilidad de un activo. Este análisis proporcionará un mapa de los puntos débiles del negocio, que serán los que hay que tratar en primer lugar. • Seleccionar las medidas de seguridad a implementar. La gestión de los riesgos implica seleccionar e implementar las medidas técnicas y organizativas necesarias para impedir, reducir o controlar los riesgos identificados, de forma que los perjuicios que puedan causar se eliminen o se reduzcan al máximo. Hay que considerar, antes de seleccionarlos, que dichos controles tienen unos costes de implementación y gestión.

74

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Fases del proyecto Lanzamiento y análisis de situación

Definición del alcance

Inventario de activos

Elaboración de política y propuesta de objetivos

Análisis de riesgos

Selección de controles

1

2

3

Elaboración de documentación del SGSI (manual, procedimientos, instrucciones)

4

Implementación del SGSI

5

Auditoría interna

Revisión del sistema

Auditoría de certificación

6

7

Figura 4.1. Fases del proyecto de implementación de un SGSI

• Evaluar los riesgos residuales. Después de identificar los controles adecuados para reducir riesgos al valor estimado como aceptable, debe evaluarse en cuánto 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 dirección tiene que conocer que este riesgo existe y aceptarlo.

4. Definición e implementación de un SGSI

75

• Documentar los procedimientos necesarios para implementar las medidas seleccionadas. Los procedimientos son la manera de plasmar la implementación de los controles de seguridad y las tareas de administración del SGSI. Un procedimiento debe reflejar fielmente los pasos a seguir para la realización de las tareas, pero debe ser conciso y claro para que no se cometan errores. • Implementación de los controles y los procedimientos. Puesto que lo habitual es que haya muchos controles a implementar, lo más práctico es planificarla en el tiempo. De todos modos, es preferible abordar proyectos pequeños que tengan un plazo de ejecución 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 inversión. • Formar y concienciar al personal. Es fundamental para que el SGSI esté bien implementación que haya un plan de formación con acciones formativas a distintos niveles. El responsable del SGSI deberá poseer una formación 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 tendrán que asimilar sus nuevas tareas o los cambios que se han producido en las que ejecutaban. • Realizar la auditoría interna y la revisión del SGSI por la dirección. De esta manera se comprobará que el SGSI se ajusta a la norma y a los requisitos de la organización.

4.2. Documentación del SGSI Según la norma, en un SGSI no se exige un manual de seguridad al uso de otras normas de gestión, que sí especifican que ha de existir un manual de gestión. Sin embargo, la norma es muy clara en cuanto a la información que debe estar documentada. Por ello, el SGSI consistirá en un conjunto de documentos que, como mínimo, serán los siguientes: • Política de seguridad. • Inventario de activos. • Análisis de riesgos. • Gestión de riesgos. • Documento de aplicabilidad.

76

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

• Procedimientos para implementar los controles. • Procedimientos para la gestión del SGSI. Pueden existir también otros documentos como planes de seguridad, instrucciones técnicas, etc. Uno de los requisitos de la norma es que se establezca la trazabilidad en todo el sistema, desde la política hasta los procedimientos, justificando la elección de los controles, que deben ser proporcionales a los riesgos y a las necesidades de la empresa. Estas necesidades comprenden tanto las de seguridad (cómo de seguro quiere que sea el sistema), como las del negocio (qué se necesita para funcionar eficazmente, qué están haciendo sus competidores) y las legales o reglamentarias (qué leyes y regulaciones aplicables a su negocio debe tener en cuenta).

4.3. Política de seguridad La política de seguridad recogerá las líneas generales de actuación de la organización en una declaración que estará firmada por la dirección, en la que se compromete a velar por la confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad de los activos de información. Además, como parte de este documento o en otro distinto, se debe documentar: • El alcance del sistema, es decir, qué partes de la organización van a estar protegidas por el SGSI. Puede ser la organización entera o una parte relevante de la misma: departamento, servicio o proceso. La recomendación 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 dimensión, 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 frustración de los implicados y la pérdida de tiempo y dinero de la organización. • La estructura de la empresa, un organigrama de las distintas áreas y responsables de la organización, y sus relaciones internas. • Las diferentes responsabilidades de cada parte de la organización: el responsable de seguridad, la dirección, el responsable de sistemas, el personal, etc. • La topología de la red, de manera que se muestren los principales sistemas de información y comunicación que se emplean.

4. Definición e implementación de un SGSI

77

• La clasificación de la información, utilizando la nomenclatura de la organización y explicando los criterios de clasificación. • El enfoque y la metodología del análisis de riesgos. Así cualquiera puede verificar los resultados del análisis, ajustándose 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. Serán hechas públicas, 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 mínimas en temas como el empleo de las contraseñas y el de las comunicaciones, fuente de numerosas incidencias. Estas normas de uso son un elemento importante en la concienciación del personal, ya que establecen unas pautas de comportamiento, que aunque sean de sentido común y no marquen límites demasiado estrictos, sí indican que la empresa se preocupa al respecto y que los empleados deberían hacer lo mismo. • Los objetivos de seguridad que se pretenden alcanzar. Puede ser difícil 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 términos de confidencialidad, disponibilidad e integridad. Por ejemplo, para verificar las mejoras en confidencialidad puede utilizarse como métrica el número de incidencias relativas a la confidencialidad, y decidir que el objetivo para este año 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 sistemáticamente obtenemos un valor mucho más elevado, puede que el objetivo no sea realista y haya que revisarlo a la baja. Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.1 de este libro.

4.4. Inventario de activos El inventario de activos es la recopilación de todos aquellos elementos indispensables para que la administración electrónica pueda prestarse con todas las garantías, de manera que los ciudadanos tengan confianza en ella.

78

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

El inventario de activos debe recoger la siguiente información: • El nombre del activo, por ejemplo: equipo de usuario, router 014, proyecto, expediente, etc. • La descripción del activo. • Categoría a la que pertenece, por ejemplo: equipo, aplicación, servicio, etc. • Ubicación: el lugar físico en el que se encuentra dentro de la organización. • Propietario: entendiendo por tal al responsable del activo. • Identificados los activos de información: se les debe valorar de acuerdo a su importancia para la empresa. Esta apreciación será lo más objetiva posible, ya que con ella se determinará sobre qué activos se realizará el análisis de riesgos. Por supuesto, se puede hacer una estimación 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 análisis de riesgos no sea inabarcable. Por ejemplo, se puede escoger analizar los activos que están por encima de un valor. Para valorar los activos se considerarán los parámetros de confidencialidad, disponibilidad e integridad de los activos, determinándose la importancia que tienen para la organización 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 administración. Cada uno de los parámetros se valorará del 1 al 4 según su relevancia para la organización, y el valor total del activo será la suma aritmética de todos los valores parciales (véase la tabla 4.1). Tabla 4.1. Inventario de activos Activo

Confidencialidad

Integridad

Disponibilidad

Valoración total

Facturas

2

4

2

8

La confidencialidad de las facturas es importante, pero no crítica, puesto que ha de estar disponible para mucha gente (clientes, Hacienda, asesores fiscales, personal de administración, etc.) y su filtración no supondría un trastorno excesivo. Una base de datos de clientes tendría un valor más alto en este aspecto, por contener datos de carácter personal. La integridad de las facturas es muy importante, puesto que las erróneas son origen de reclamaciones y trabajo extra, e incluso de sanciones por parte de la

4. Definición e implementación de un SGSI

79

Administración, lo cual no es en absoluto deseable. La integridad de un expediente de compra se valoraría menos. Que las facturas estén disponibles es importante, pero no fundamental para que el negocio continúe funcionando. No se producirá un trastorno serio en la organización a menos que el momento en el que suceda la indisponibilidad sea crítico (por ejemplo, cuando llega la hora de preparar los impuestos o cerrar el año). Sin embargo, la disponibilidad del Servidor S en el que se alojan las facturas se valoraría más alta, puesto que la indisponibilidad de dicho equipo sí supondría un trastorno considerable para la marcha de la organización. La suma de los valores nos da 8. Haciendo lo mismo para todos los activos podremos estimar cuáles son los activos más críticos, más valiosos para la organización y establecer comparaciones. Obviamente, los razonamientos anteriores son hipotéticos y se ofrecen a modo de ejemplo. En cada organización los activos se ven y valoran de acuerdo con las circunstancias y la utilización que brinda cada uno de ellos. Otro aspecto a documentar en este punto es la relación entre los procesos de negocio y los activos de información. Según la norma se debe documentar cómo la información 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 cuáles son los principales procesos de negocio (administración, producción, gestión de proyectos, compras, etc.) y especificar qué activos forman parte de su operativa normal. Por ejemplo, podemos considerar que el proceso “Compras” se apoya en el personal del departamento, las aplicaciones con las que se produce la documentación, la propia documentación (peticiones de oferta, ofertas, órdenes de compra, etc.), los equipos de usuarios, los servidores donde se aloja la información y las comunicaciones. Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.2 de este libro.

4.5. Análisis de riesgos Para efectuar el análisis de riesgos confeccionaremos (o utilizaremos la propuesta por la metodología o herramienta que se haya escogido) una lista de las amenazas a las que se enfrenta la empresa. Por ejemplo: • Fuego. • Inundación.

80

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

• Corte de suministro eléctrico. • Fallo del suministro de comunicaciones. • Error de usuario. Para cada activo hay que valorar cuál es la vulnerabilidad de ese activo con respecto a cada una de las amenazas. Esta valoración 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 están en soporte papel, pero podemos considerar que es bastante vulnerable (3) si están en soporte electrónico. El siguiente paso será decidir cuál es la probabilidad de que ocurra la amenaza (véase la tabla 4.2). Tabla 4.2. Análisis de riesgos Probabilidad de ocurrencia de la amenaza

Guía

1 Muy baja

Una media de una vez cada 5 años

2 Baja

Una media de una vez cada 2 años

3 Media

Una media de una vez al año

4 Alta

Una media de 3 veces al año

Por último, para decidir el nivel de riesgo de los activos habrá que evaluar el impacto que tendría 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 numérico a ese impacto, como: 1 Ningún impacto.

4. Definición e implementación de un SGSI

81

2 Poco impacto. 3 Bastante impacto. 4 Mucho impacto. En nuestro ejemplo vamos a considerar que el impacto sería 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 están simplemente en una carpeta o que las facturas en soporte electrónico no tienen copias de seguridad ni se encuentran protegidas por contraseña. Con los valores obtenidos para cada activo hay que calcular el riesgo para cada amenaza (que será, por ejemplo, el producto de los tres parámetros), y después calcular el nivel de riesgo de ese activo, que puede ser una simple suma de todos los valores obtenidos o puede optarse por tomar sólo el valor más alto. El objetivo es cuantificar algo tan intangible como el nivel de riesgo y poder comparar todos los activos con un criterio homogéneo. Por ello, el método de cálculo no es tan crucial como los criterios que se apliquen para efectuar esos cálculos, que deben ser claros, coherentes y bien definidos. Las escalas y los cálculos serán concretos, entendibles y se aplicarán a todos los activos de la misma manera. En este ejemplo (véase 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 sería 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 más 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 aplicación de gestión está expuesta a más riesgo y entonces deberán aplicarse más medidas de seguridad para protegerla.

Tabla 4.3. Ejemplo del nivel de riesgo Amenazas

Facturas

Fuego

3

1

3

9

Fallo de electricidad

1

3

3

9

Error de usuario

4

4

2

32

82

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Tabla 4.4. “Mapa de riesgos” Activo

Riesgo

Facturas

32

Equipos de usuario

24

Aplicación de gestión

48

Base de datos de proveedores

9

Tanto los métodos de cálculo como las valoraciones y los resultados quedarán documentados 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 declaración de la gestión de los riesgos estará firmada por la dirección. Normalmente las decisiones son asumir los riesgos o mitigarlos. En cualquier caso hay que tener en cuenta que siempre habrá un pequeño grupo de controles que van a aplicarse sobre todos los activos o sobre muchos, como es el caso de la política de seguridad, el inventario de activos, la protección 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 expresión utilizada en la norma, cuándo 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 información. 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 irían del 1 al 64, por lo que podríamos estipular que la mediana, el 32, es el valor por debajo del cual se considerará asumible el riesgo. Otra opción podría ser la media de los valores, o directamente convenir un valor por debajo del cual el riesgo es asumible, por ejemplo 10. La norma no especifica nada sobre cómo escoger este valor, y es la empresa la que debe valorar cuántos riesgos está dispuesta a correr y hasta dónde puede invertir en mitigarlos. La documentación del análisis de riesgos recogerá: • Todas las valoraciones realizadas. • Los valores de riesgo intrínseco.

4. Definición e implementación de un SGSI

83

• Cuál es el riesgo asumible. • Las decisiones tomadas respecto a cada uno de los activos. Un ejemplo de cómo realizar este documento puede consultarse en el apartado 8.3 de este libro.

4.6. Gestión 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 carácter organizativo y los técnicos. Es importante lograr un balance en la selección que asegure que no sólo se aplican las medidas técnicas apropiadas, sino que la gestión de la seguridad es lo suficientemente sólida como para que funcionen correctamente. Hay que revisar uno por uno los controles y considerar: • Si está ya implementado. • Si ayudaría a reducir el riesgo de alguno de los activos. • Si el coste de implementarlo es aceptable. • Si el coste de la operación y el mantenimiento del control serán aceptables. Existen una serie de controles que deben ser implementados obligatoriamente si optamos por la certificación, por ejemplo, tener una política de seguridad o un inventario de activos, pero salvo esos, el resto, aunque nos parezcan muy apropiados al problema que tenemos entre manos, hay que valorar cuidadosamente los criterios expuestos anteriormente, porque aplicar un control que luego es muy costoso de implementar no va a ser una medida de seguridad eficiente, y uno que suponga mucho esfuerzo implementación por motivos culturales o de organización, será difícil que llegue a ser eficaz. No hay un número establecido o recomendado de controles a implementar. Se deben implementar todos aquellos que beneficien a la seguridad de la información, pero no pretender abarcar demasiados, puesto que lastrarían el desarrollo del SGSI y no le permitirían una implementación adecuada. Por ejemplo, el activo “facturas” que manejábamos. Será necesario contar con controles de acceso a esta información (no todo el mundo tiene por qué acceder a ella),

84

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

copias de seguridad (que garanticen la disponibilidad de la información) o procedimientos para intercambio de información (cómo las vamos a hacer llegar de manera segura a los clientes o a los asesores garantizando su integridad). En general, estos controles son fáciles de implementar e incluso en muchos casos, aunque sea de manera informal, ya existen buenas prácticas 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 física y equipos especiales que garanticen la disponibilidad es, normalmente, demasiado gravoso económicamente para los beneficios que se obtienen. La reducción del riesgo sería mayor que en el primer caso, pero no compensaría. Puesto que estamos hablando de sistemas de gestión orientados a la mejora continua, es mucho más práctico en una primera iteración quedarse con un conjunto mínimo 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 añadiendo controles o mejorando la implementación 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 análisis de riesgos, ciñéndose al mismo método 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 habrán reducido la vulnerabilidad del activo y el posible impacto que un incidente de seguridad supondría. Retomando nuestro ejemplo, supongamos en esta ocasión que el activo “facturas” existe en papel, guardado en un armario en una oficina con medidas antiincendios (detectores, extintores, alarmas), y además se almacenan en un servidor, que contará con un Sistema de Alimentación Ininterrumpida (SAI), situado en un armario específico cerrado con llave, con control de temperatura, etc. Además se realiza una copia semanal de seguridad, que a partir de ahora se enviará a otra ubicación. Con estas medidas de seguridad implementadas o a punto de hacerlo, la vulnerabilidad al fuego se ha reducido quizás a 1, y como existen copias de seguridad incluso fuera de la oficina, el impacto también 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 trabajo antes de que la avería lo elimine o corrompa. Puesto que la implementación de un SGSI conlleva la definición y publicación de una política de seguridad con normas para los usuarios, la vulnerabilidad al error de usuario deberá ser menor (véase la tabla 4.5).

4. Definición e implementación de un SGSI

85

Tabla 4.5. Gestión de riesgos Facturas Amenazas

Riesgo inicial

Vulnerabilidad

Impacto

Riego residual

Fuego

9

1

2

2

Fallo de electricidad

3

1

2

2

Error de usuario

8

2

2

4

El grado de riesgo del activo “facturas” es ahora de 4, lo cual le sitúa en un nivel inferior por debajo del cual el riesgo es asumible, es decir, no es necesario añadir más controles a este activo. En esta fase se generarán dos documentos: el documento de aplicabilidad y el informe de gestión de riesgos. Las decisiones sobre aplicar o no un control deberán quedar documentadas en el documento de aplicabilidad. Este documento debe contener para cada control la siguiente información: • Si está aplicado. • Si se va a aplicar. • Si no se va a aplicar. • Razonamiento explicando la decisión. El informe de gestión de riesgos recogerá: • Los controles aplicados a cada activo. • Las valoraciones y los valores de riesgo resultantes tras la aplicación de los controles. • La aceptación de la dirección de los riesgos residuales. Un ejemplo de cómo realizar dichos documentos puede consultarse en los apartados 8.4 y 8.5 de este libro.

86

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

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 implementado. Las principales tareas serán la implementación de todos los controles, la formación, la auditoría interna y la revisión por la dirección. El plan puede ser además el documento idóneo para plasmar los objetivos de seguridad junto con un grupo de métricas relevantes, medibles con escasos recursos y que ofrezcan una información fiable de cómo funciona el SGSI. La norma establece que se debe medir el rendimiento de todos aquellos controles que se consideren relevantes. Además, hay que procurar que medir no resulte costoso, por lo que se escogerá un grupo reducido de métricas 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 concienciación del personal, etc. • Disponibilidad: porcentaje de disponibilidad de los equipos y sistemas. • Integridad: reducir el porcentaje de información errónea, disminuir el porcentaje de fallos del sistema o las aplicaciones, etc. Una vez en marcha el programa de métricas, se verá cuáles son los puntos que aportan información relevante sobre la marcha del SGSI, cuáles deberían ser descartados y cuáles incorporados para mejorar nuestro conocimiento del funcionamiento del SGSI. El mismo funcionamiento de los controles puede sugerir nuevos objetivos y métricas que añadir. Un ejemplo de este documento puede consultarse en el apartado 8.6 de este libro.

4.8. Procedimientos Es uno de los puntos más problemáticos. El objetivo de un procedimiento es describir la manera en la que se va a realizar una tarea. El nivel de detalle de un procedimiento no debería ser muy alto. Se trata de contar cómo se hace una tarea de forma que alguien que no esté familiarizado con ella pudiera ejecutarla en caso necesario. Para ello se debería describir a grandes rasgos lo que se debe hacer y citar

4. Definición e implementación de un SGSI

87

aquellos documentos que puedan ser de ayuda para llevar a cabo la tarea. Se debe evitar ofrecer detalles que pueden cambiar con frecuencia, y obligarían a revisar el procedimiento muy a menudo. Este tipo de datos deberían documentarse en instrucciones técnicas y no en procedimientos. El lenguaje debería ser lo más claro posible, evitando modismos y jergas ininteligibles o que conduzcan a malas interpretaciones. El estilo debería ser conciso, sin rebozos, lo cual facilita la comprensión del texto. El procedimiento, lo más breve posible para que sea sencillo de leer, comprender y, lo más importante, de utilizar. No hay ninguna regla respecto al número de procedimientos que deben crearse. Además, un control puede implementarse de diversas maneras. Habrá, por ejemplo, controles que se implementarán con un documento como el inventario de activos, y otros que lo harán con una medida técnica (instalación de un cortafuegos). Cuando la implementación se efectúe mediante un procedimiento, puede aplicarse un procedimiento para cada control que se ha decidido implementar, pero no es necesario. También resulta útil recoger en un mismo procedimiento varios controles relacionados, por ejemplo, los relativos al control de accesos. Esta agrupación facilita enormemente la implementación de los controles y la gestión de la documentación, y en consecuencia hace más sencilla la implementación del sistema. Por otro lado, dependiendo de la complejidad de la organización o de las actividades a tratar, también puede suceder que un control requiera más de un procedimiento para implementarse. Señalar de nuevo que lo propuesto por la Norma UNE-ISO/IEC 27002 es meramente informativo, puede utilizarse como referencia y punto de partida, pero los procedimientos deben recoger el modo de ejecutar un control o varios, dependiendo del funcionamiento, estructura y cultura de la organización. En la medida que el procedimiento refleje la realidad de la organización, o al menos la tenga en cuenta al introducir los cambios, tendrá más éxito la implementación de los nuevos modos de trabajo. Es en este punto donde se hace más notoria la necesidad de ajustar el sistema a la organización. Los procedimientos son los documentos de trabajo que más difusión van a tener y que más van a afectar al personal tras la política de seguridad. Por eso es crucial que se perciban como herramientas de trabajo útiles y no como directrices 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 cómo realizar este documento puede consultarse en los apartados 8.7 y 8.8 de este libro.

88

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

4.9. Formación El personal afectado por el SGSI, y en la medida de lo posible, todo el personal de la empresa, debe recibir formación adecuada en seguridad de la información. 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 situación y los objetivos que se persiguen al implementar los nuevos modos de trabajo o al formalizar los ya existentes. Cada grupo tendrá unas necesidades específicas y no todo el mundo necesitará formación en todos los aspectos del SGSI. Por eso, el plan de formación deberá recoger distintas actuaciones en función de estas necesidades. Los medios de comunicación interna que ya existan en la organización (intranet, paneles informativos, boletines, etc.) son muy útiles para difundir, por ejemplo, la política de seguridad que debe llegar a toda la organización. La formación puede ser interna, por ejemplo, charlas del responsable de seguridad para explicar qué es un SGSI, las causas de su implementación y los principales cambios que haya habido es una manera muy eficaz de informar a todos. La asistencia o participación de la dirección en las acciones formativas es una excelente oportunidad de demostrar su compromiso con el SGSI y su apoyo a la iniciativa.

4.10. Revisión por la dirección El informe de revisión por la dirección habitualmente es elaborado por el responsable de seguridad, que siguiendo los parámetros establecidos por la norma, realiza un resumen de lo que se ha hecho y de cómo se ha desarrollado la implementación 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 dirección, lo cual se hace en muchos casos dentro del comité de seguridad.

4.11. Auditoría interna La auditoría es una potente herramienta que permite detectar errores y puntos débiles en el SGSI. Consiste en evaluar hasta qué punto el SGSI se ajusta a la

4. Definición e implementación de un SGSI

89

norma y el grado de cumplimiento de la organización de sus propias normas. Para ello: • Se comprueba que la documentación del SGSI está de acuerdo con lo establecido en la norma. • Se revisa cada punto de la norma y se va verificando que, efectivamente, existen pruebas de su cumplimiento (habitualmente estas pruebas son los registros 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 técnicamente que los procedimientos se cumplen: que los usuarios están efectivamente dados de alta, que se efectúan las copias de seguridad y cómo, etc. Las auditorías internas deberían recoger y utilizar los resultados de otras auditorías que se lleven a cabo, como la auditoría de la LOPD, pruebas de intrusión, auditorías informáticas, etc. Los auditores internos han de conocer la empresa a fondo, ser independientes, objetivos y tener algún conocimiento del SGSI.

4.12. Registros Puestos en marcha los procedimientos, se generarán 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 revisión por la dirección. • Informes de auditorías. • Registros de formación. • Perfiles profesionales. • Acciones correctivas y preventivas. • Registros de copias de seguridad. • Registros de mantenimientos. • Registros de usuarios.

90

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Los registros pueden estar en cualquier formato y soporte, pero deberán permanecer controlados para que no se deterioren o pierdan. El número de registros dependerá de qué procedimientos se encuentren en uso, su complejidad y las costumbres de la empresa. La recomendación es automatizar lo más posible la producción de registros para evitar tener que generarlos manualmente, con el consiguiente consumo de recursos.

5

Proceso de certificación

Actualmente, la Norma UNE-ISO/IEC 27001 es la norma española vigente para la certificación de sistemas de gestión de la seguridad de la información. La Norma UNE-ISO/IEC 27002 no es certificable, es sólo una guía de buenas prácticas. Hay que tener claro que con estas normas no estamos certificando la seguridad de la información de nuestra organización, sino el sistema mediante el cual gestionamos esta seguridad. Certificar un sistema de gestión es obtener un “documento” que reconoce y respalda la correcta adecuación del sistema de gestión de seguridad de la información conforme 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 España las entidades de certificación tienen que estar acreditadas por ENAC. ENAC es una entidad privada, independiente y sin ánimo de lucro, cuya función es coordinar y dirigir en el ámbito nacional un sistema de acreditación conforme a criterios y normas internacionales. ENAC acredita organismos que realizan actividades de evaluación de la conformidad, sea cual sea el sector en que desarrolle su actividad, su tamaño, su carácter público o privado, o su pertenencia a asociaciones o empresas, universidades u organizaciones de investigación. ENAC acredita a laboratorios, entidades de inspección, entidades de certificación, verificadores medioambientales, etc. La realización de auditorías de sistemas de gestión en general se rige por la Norma UNE-EN ISO/IEC 17021 Evaluación de la conformidad. Requisitos para los organismos

92

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

que realizan la auditoría y la certificación de sistemas de gestión, y en particular, son los SGSI los que deben ser auditados por entidades que cumplan los requisitos de la Norma ISO/IEC 27006 Tecnología de la información. Técnicas de seguridad. Requisitos para organismos proveedores de auditoría y certificación de Sistemas de Gestión de Seguridad de la Información. Entre los beneficios de emprender la certificación señalaremos los siguientes: • Contribuye a impulsar las actividades de protección de la información en las organizaciones. • Mejora la imagen y afianza la reputación de una organización. • Genera confianza frente a terceros, ya que es una prueba de la rigurosidad de la gestión de la empresa. • Es un factor que permite diferenciarse de la competencia, lo que proporciona una cierta ventaja competitiva. • Si no existe todavía otro sistema de gestión en la organización, logra crear una cultura de enfoque a procesos y de mejora continua que beneficiará a toda la estructura. La organización que desee solicitar el certificado debe contactar con una entidad de certificación acreditada. Esta entidad recoge la información básica de la empresa, como su tipo de negocio, número de empleados y actividades a certificar, con el fin de asignar un equipo auditor adecuado y determinar el número de días necesarios para llevar a cabo la auditoría. • Fase 1. Revisión documental. El equipo auditor revisa la documentación 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, informarían a la organización de la imposibilidad de conseguir la certificación en esas condiciones. Si detectasen pequeñas no conformidades, habría que corregirlas antes de la siguiente fase, que suele realizarse un mes más tarde. • Fase 2. Auditoría de certificación. El equipo auditor recogerá evidencias objetivas de que la organización cumple tanto con los requisitos de la normas como con sus políticas, objetivos y procedimientos, así como con los requisitos documentados. Si los auditores no detectan no conformidades graves, se concede el certificado a la empresa.

6

Relación entre los apartados de la norma y la documentación del sistema

Para certificar un SGSI debe cumplir con los apartados 4 al 8 de la norma. La justificación de este cumplimiento quedará recogida en los documentos correspondientes y los registros de ciertas actividades, que, a modo de ejemplo, pueden ser los siguientes: Apartados de la norma

Documento de soporte

0 Introducción 1 Objeto y campo de aplicación 2 Normas para consulta 3 Términos y definiciones 4 Sistema de gestión de la seguridad de la información 4.1 Requisitos generales

Política de seguridad

4.2 Creación y gestión del SGSI 4.2.1 Creación del SGSI

Política de seguridad Inventario de activos Análisis de riesgos Gestión de riesgos Documento de aplicabilidad (continúa)

94

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Apartados de la norma

4.2.2 Implementación y operación del SGSI 4.2.3 Supervisión y revisión del SGSI

4.2.4 Mantenimiento y mejora del SGSI

Documento de soporte

Plan de tratamiento del riesgo

Gestión de incidencias Auditorías internas Revisión por la dirección Monitorización de objetivos Acciones de mejora Acciones preventivas y correctivas

4.3 Requisitos de la documentación 4.3.1 Generalidades

4.3.2 Control de documentos 4.3.3 Control de registros

Política de seguridad Objetivos de seguridad Procedimientos Análisis de riesgos Gestión de riesgos Registros Documento de aplicabilidad Procedimiento para el control de la documentación Procedimiento para el control de los registros

5 Responsabilidad de la dirección 5.1 Compromiso de la dirección

Política y planes firmados Criterios y aceptación de riesgos firmada Revisión aprobada por la dirección

5.2 Gestión de los recursos 5.2.1 Provisión de los recursos 5.2.2 Concienciación, formación y capacitación

Planes de seguridad Planes de formación Registros de formación (continúa)

6. Relación entre los apartados de la norma y la documentación del sistema

Apartados de la norma

6 Auditorías internas del SGSI

7 Revisión del SGSI por la dirección

Documento de soporte

Plan de auditorías Informes de auditorías Informe de revisión por la dirección

7.1 Generalidades 7.2 Datos iniciales de la revisión 7.3 Resultados de la revisión 8 Mejora del SGSI 8.1 Mejora continua

Acciones de mejora

8.2 Acción correctiva

Acciones correctivas

8.3 Acción preventiva

Acciones preventivas

95

7

Correspondencia entre las Normas UNE-EN ISO 9001:2008, UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007

UNE-EN ISO 9001:2008

0 Introducción

UNE-EN ISO 14001:2004

Introducción

UNE-ISO/IEC 27001:2007

0 Introducción

0.1 Generalidades

0.1 Generalidades

0.2 Enfoque basado en procesos

0.2 Enfoque por procesos

0.3 Relación con la Norma ISO 9004 0.4 Compatibilidad con otros sistemas de gestión 1 Objeto y campo de aplicación

0.3 Compatibilidad con otros sistemas de gestión 1 Objeto y campo de aplicación

1 Objeto y campo de aplicación

1.1 Generalidades

1.1 Generalidades

1.2 Aplicación

1.2 Aplicación

2 Normas para consulta

2 Normas para consulta

2 Normas para consulta

3 Términos y definiciones

3 Términos y definiciones

3 Términos y definiciones

4 Sistema de gestión de la calidad

4 Requisitos del sistema de gestión ambiental

4 Sistema de gestión de la seguridad de la información (continúa)

98

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

UNE-EN ISO 9001:2008

4.1 Requisitos generales

UNE-EN ISO 14001:2004

4.1 Requisitos generales

UNE-ISO/IEC 27001:2007

4.1 Requisitos generales 4.2 Creación y gestión del SGSI 4.2.1 Creación del SGSI

8.2.3 Seguimiento y medición de los procesos

4.4 Implementación y operación

4.2.2 Implementación y operación del SGSI

4.5.1 Seguimiento y medición

4.2.3 Supervisión y revisión del SGSI 4.2.4 Mantenimiento y mejora del SGSI

8.2.4 Seguimiento y medición del producto 4.2 Requisitos de la documentación

4.3 Requisitos de la documentación

4.2.1 Generalidades

4.3.1 Generalidades

4.2.2 Manual de la calidad 4.2.3 Control de los documentos

4.4.5 Control de los documentos

4.3.2 Control de los documentos

4.2.4 Control de los registros

4.5.4 Control de los registros

4.3.3 Control de registros

5 Responsabilidad de la dirección

5 Responsabilidad de la dirección

5.1 Compromiso de la dirección

5.1 Compromiso de la dirección

5.2 Enfoque al cliente 5.3 Política de la calidad

4.2 Política ambiental

5.4 Planificación

4.3 Planificación (continúa)

7. Correspondencia entre las Normas UNE-EN ISO 9001:2008, UNE-EN ISO 14001:2004 y UNE-ISO/IEC 27001:2007

UNE-EN ISO 9001:2008

UNE-EN ISO 14001:2004

UNE-ISO/IEC 27001:2007

5.5 Responsabilidad, autoridad y comunicación 6 Gestión de los recursos

5.2 Gestión de los recursos

6.1 Provisión de recursos

5.2.1 Provisión de los recursos

6.2 Recursos humanos 6.2.2 Competencia, formación y toma de conciencia

4.4.2 Competencia, formación y toma de conciencia

5.2.2 Concienciación, formación y capacitación

8.2.2 Auditoría interna

4.5.5 Auditoría interna

6 Auditorías internas del SGSI

5.6 Revisión por la dirección

4.6 Revisión por la dirección

7 Revisión del SGSI por la dirección

6.3 Infraestructura 6.4 Ambiente de trabajo

5.6.1 Generalidades

7.1 Generalidades

5.6.2 Información de entrada para la revisión

7.2 Datos iniciales de la revisión

5.6.3 Resultados de la revisión

7.3 Resultados de la revisión

8.5 Mejora

8 Mejora del SGSI

8.5.1 Mejora continua

8.1 Mejora continua

8.5.2 Acción correctiva

8.5.3 Acción preventiva

4.5.3 No conformidad, acción correctiva y acción preventiva

99

8.2 Acción correctiva

8.3 Acción preventiva

8

Caso práctico: modelo de SGSI

8.1. Documentación de la política de seguridad 8.1.1. Política de seguridad de la información En este apartado se debería hacer relación de los puntos que describan la política de seguridad de la información de la empresa. Esta política debe estar aprobada por la dirección de la empresa y debería ser revisada anualmente.

8.1.2. Definición del SGSI Este apartado recoge el ámbito de aplicación y los límites del SGSI teniendo en cuenta las actividades que realiza la organización, los servicios y productos que oferta, el equipamiento con el que cuenta y las restricciones legales o reglamentarias que sean aplicables a su actividad.

8.1.2.1. Conceptos generales Definición de los conceptos más básicos de la seguridad: • Disponibilidad. • Confidencialidad. • Integridad. • Seguridad de la Información. • Sistemas de Gestión de Seguridad de la Información. También se pueden incluir las definiciones de conceptos utilizadas internamente en la empresa.

102

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.1.2.2. Campo de aplicación de la política de seguridad Descripción de a quién y a qué afecta la política de seguridad, ya que puede ser al conjunto de la organización, a una parte o servicio, a todos los empleados, a los contratistas, etc. Se puede incluir un organigrama de la organización.

8.1.2.3. Alcance del sistema Descripción de los servicios de venta y alquiler de vehículos terrestres tanto a empresas como a particulares.

8.1.2.4. Infraestructura informática Inclusión de un diagrama de red de la organización que muestre de manera esquemática la infraestructura informática con la que se cuenta.

8.1.2.5. Objetivos de la política de seguridad Breve descripción de qué se pretende conseguir con esta política: • Definir el SGSI. • Mejorar la confianza de los clientes y usuarios en las actividades. • Reducir el riesgo de posibles pérdidas de información, reaccionar adecuadamente ante cualquier tipo de incidencia, etc.

8.1.2.6. Requisitos legales Detalle de las leyes aplicables en relación con la seguridad de la información correspondiente.

8.1.2.7. Revisiones y auditorías Establecimiento de la metodología y periodicidad de la revisión de la política de seguridad y de las auditorías de la misma.

8.1.2.8. Compromiso de la dirección Descripción clara y directa de cómo la dirección está detrás de la definición y la implementación del SGSI.

8. Caso práctico: modelo de SGSI

103

8.1.3. Organización e infraestructura de seguridad Este apartado recoge quién y cómo se va a hacer cargo de la seguridad en la organización.

8.1.3.1. Responsabilidades En esta sección se describirían las responsabilidades de los distintos roles en materia de seguridad de la información que existen en una organización.

8.1.3.1.1. Dirección Breve definición de las responsabilidades de la dirección: • Proporcionar recursos al SGSI. • Aprobar los riesgos residuales. • Realizar la revisión por la dirección. • Etc.

8.1.3.1.2. Responsable de seguridad Breve definición de sus responsabilidades: • Gestionar y mantener el sistema de seguridad de la información. • Proporcionar ayuda y soporte a los usuarios. • Proteger la información y los sistemas adecuadamente protegidos. • Etc.

8.1.3.1.3. Propietario de los activos Breve definición de sus responsabilidades: • Definir si el activo está afectado por la Ley de Protección de Datos y aplicarle en su caso los procedimientos correspondientes. • Definir quién, cómo y cuándo se puede tener acceso a la información. • Clasificar la información y la función a desempeñar. • Asegurarse de que el activo cuenta con el mantenimiento adecuado. • Etc.

104

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.1.3.1.4. Responsable de sistemas Breve definición de sus responsabilidades: • Administrar y gestionar las cuentas de los usuarios. • Asegurarse de que sólo las personas autorizadas a tener acceso cuentan con él. • Asegurarse de que los sistemas tienen los niveles de disponibilidad requeridos por la organización o incluir los aspectos de seguridad que se apliquen en los requisitos para nuevos desarrollos.

8.1.3.1.5. Personal Breve definición de las responsabilidades del personal: • Cómo conocer y aplicar las directrices de la política 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 quién es el propietario del activo, su ubicación física y el valor que tiene para la organización.

8.1.4. Clasificación de la información La información de la organización debe clasificarse según su nivel de confidencialidad o sensibilidad para tomar las medidas de seguridad adecuadas a este nivel de criticidad: información confidencial, restringida, interna, pública, etc.

8.1.5. Análisis de riesgos de seguridad Definición de la necesidad de realizar el análisis de riesgos y los beneficios que comporta.

8.1.5.1. Análisis de riesgos Descripción de las tareas a realizar para el análisis de riesgos.

8. Caso práctico: modelo de SGSI

105

8.1.5.2. Gestión de riesgos Descripción de las tareas a realizar para la gestión de riesgos.

8.2. Documentación del inventario de activos En este apartado se describe la manera de documentar el listado y la valoración de los activos de información con los que cuenta la organización de acuerdo con los requisitos de la norma.

8.2.1. Procesos de negocio Un ejemplo podría ser: Proceso de negocio

Descripción

Administración

Gestión de pagos y cobros, pago de impuestos, etc.

Alquiler y venta

Servicios de alquiler y venta de vehículos

Comercial

Captación de clientes

Recursos Humanos

Nóminas, altas y bajas de personal

8.2.2. Inventario de activos Un ejemplo podría ser: Nombre

Descripción

Categoría

Ubicación

Propietario

Aplicaciones comerciales

Office, NominaPlus, FacturaPlus, etc.

Aplicaciones

Servidor

Responsable de informática

Servidor que contiene los datos de la empresa

Hardware

Sala del servidor

Responsable de informática

PC de los usuarios

Hardware

Oficinas

Responsable de informática

Datos de clientes

Datos

Servidor/Archivo

Director General

Datos de contabilidad

Datos

Servidor

Director financiero

Laboral

Datos de personal

Datos

Servidor

Director RRHH

Personal

Personal propio de Cibercar

Personal

Oficinas

Director General

Servidor Puestos de usuario Clientes Contabilidad

106

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.2.3. Relación proceso de negocio-activos Un ejemplo podría ser: Proceso

Administración

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

Activos

Laboral Personal

X X

X

X

X

8.2.4. Valoración de activos Se valorarán los activos según una escala de puntuación de 0 (no aplicable/sin valor) a 4 (mucho valor). La valoración total será la suma aritmética 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. Caso práctico: modelo de SGSI

107

8.3. Documentación del Análisis de riesgos El nivel de riesgo vendrá dado por el valor más 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 valoran de 0 a 3 (no aplicado, bajo, medio y alto).

8.3.1. Valoración del riesgo por activos Aplicaciones comerciales Un ejemplo podría ser: 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

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 software

9

1

1

9

Fallo de comunicaciones

9

1

1

9

Errores de usuario

9

2

3

54

Amenaza

Servidor Un ejemplo podría ser: Amenaza

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

108

Puestos de usuario Un ejemplo podría ser: 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 software

9

1

1

9

Fallo de comunicaciones

9

1

0

0

Errores de usuario

9

2

3

54

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 software

12

1

1

12

Fallo de comunicaciones

12

1

1

12

Errores de usuario

12

3

3

108

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

Amenaza

Clientes Un ejemplo podría ser: Amenaza

Contabilidad Un ejemplo podría ser: Amenaza

(continúa)

8. Caso práctico: modelo de SGSI

Impacto (valor del activo)

Nivel de amenaza

Vulnerabilidad

Nivel de riesgo

Fallo de software

9

1

2

18

Fallo de comunicaciones

9

1

2

18

Errores de usuario

9

3

3

81

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 software

11

1

2

22

Fallo de comunicaciones

11

1

2

22

Errores de usuario

11

3

3

99

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 software

6

0

0

0

Fallo de comunicaciones

6

0

0

0

Errores de usuario

6

3

2

36

Amenaza

Laboral Un ejemplo podría ser: Amenaza

Personal Un ejemplo podría ser: Amenaza

109

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

110

8.3.2. Tratamiento del riesgo Un ejemplo podría ser: 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

El valor de riesgo aceptable en este caso se establecería en 50, por lo que se tratarían los que igualen o superen esta cifra y se asumirían los que estuvieran por debajo. De todas formas, se aplicarían los controles mínimos establecidos por la norma.

8.4. Documentación de la Gestión de riesgos Con la aplicación de controles se reducirían tanto el nivel de amenaza como el de vulnerabilidad o posiblemente los dos. Consecuencia de todo ello sería la disminución del nivel de riesgo.

8.4.1. Valoración del riesgo por activos Aplicaciones comerciales Un ejemplo podría ser: 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

Amenaza

(continúa)

8. Caso práctico: modelo de SGSI

111

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

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 software

9

1

1

9

9

Fallo de comunicaciones

9

1

1

9

9

Errores de usuario

9

2

2

54

36

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 software

9

1

1

9

9

Fallo de comunicaciones

9

1

0

0

0

Errores de usuario

9

2

2

54

36

Amenaza

Servidor Un ejemplo podría ser: Amenaza

Puestos de usuario Un ejemplo podría ser: Amenaza

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

112

Clientes Un ejemplo podría ser: 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 software

12

1

1

12

12

Fallo de comunicaciones

12

1

1

12

12

Errores de usuario

12

2

3

108

60

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 software

9

1

2

18

18

Fallo de comunicaciones

9

1

2

18

18

Errores de usuario

9

2

3

81

54

Amenaza

Contabilidad Un ejemplo podría ser: Amenaza

8. Caso práctico: modelo de SGSI

113

Laboral Un ejemplo podría ser: 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 software

11

1

2

22

22

Fallo de comunicaciones

11

1

2

22

22

Errores de usuario

11

2

3

99

55

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 software

6

0

0

0

0

Fallo de comunicaciones

6

0

0

0

0

Errores de usuario

6

1

2

24

12

Amenaza

Personal Un ejemplo podría ser: Amenaza

114

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.5. Documentación de la Declaración de aplicabilidad Según lo exigido por la norma, se deben documentar los controles seleccionados, su aplicación, así como aquellos que no han sido seleccionados y los motivos por los que han sido rechazados. Toda esta información es la que se recoge en la declaración de aplicabilidad.

8.5.1. Controles aplicados Sección

Objetivo

A.5

A.5.1

Estado

Justificación

Política de seguridad

Política de seguridad de la información

A.6

A.6.1

Control

5.1.1 Documento de política de seguridad de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

5.1.2 Revisión de la política de seguridad de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

Organización de la seguridad de la información

Organización interna

6.1.1 Compromiso de la Dirección con la seguridad de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

6.1.2 Coordinación de la seguridad de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

6.1.3 Asignación de responsabilidades en seguridad de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

6.1.4 Proceso de autorización para las instalaciones de procesamiento de la Información

Aplicado

La autorización para la compra e instalación 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 (continúa)

8. Caso práctico: modelo de SGSI

Sección

Objetivo

Control

Estado

Justificación

Aplicado

Se mantienen contactos con foros especializados, listas de correo, revistas, etc.

6.1.8 Revisión independiente de la seguridad de la información

No aplicar

Se considera que el coste de implementación de este control supera al beneficio que se obtendría

6.2.1 Identificación de riesgos relacionados con terceras partes

No aplicar

Se considera que el coste de implementación de este control supera al beneficio que se obtendría

6.2.2 Gestión de la seguridad al tratar con clientes

No aplicar

No se considera que este control ayude a reducir el riesgo de los activos identificados

6.2.3 Gestión de la seguridad en contratos con terceras partes

No aplicar

Se considera que el coste de implementación de este control supera al beneficio que se obtendría

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

7.1.3 Utilización aceptable de los activos

Aplicar

Se marcarán unas pautas de utilización de los activos

7.2.1 Guías de clasificación

Aplicar

Exigido por UNE/ISO-IEC 27001

7.2.2 Etiquetado y tratamiento de la información

Aplicar

Exigido por UNE/ISO-IEC 27001

6.1.7 Contacto con grupos de interés especial A.6.1

A.6.2

Organización interna

Terceras partes

A.7

A.7.1

A.7.2

Gestión de activos

Responsabilidades de los activos

Clasificación de la información

A.8

Seguridad de la gestión de los recursos humanos No aplicar

En el análisis de riesgos no se han detectado amenazas en este sentido

8.1.2 Análisis y selección

Aplicado

Se controla la selección de personal

8.1.3 Términos y condiciones de empleo

Aplicado

Se documentan en los contratos

8.1.1 Roles y responsabilidades A.8.1

115

Antes de la contratación

(continúa)

116

Sección

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Objetivo

Control

A.8.3

Durante el empleo

Finalización o cambio de empleo

En el análisis de riesgos no se han detectado amenazas en este sentido

8.2.2 Concienciación, formación y entrenamiento sobre la seguridad de la información

Aplicar

Según el análisis de riesgos, una amenaza habitual es la falta de formación en materia de seguridad

8.2.3 Proceso disciplinario

No aplicar

En el análisis de riesgos no se han detectado amenazas en este sentido

8.3.1 Responsabilidades ante la finalización

No aplicar

En el análisis de riesgos no se han detectado amenazas en este sentido

Aplicado

Cuando el empleado cesa devuelve todos los activos que poseía

Aplicado

Para evitar los accesos a la información de personal que ya no pertenece a la organización

8.3.2 Devolución de activos

8.3.3 Retirada de los derechos de acceso A.9

Seguridad física y del entorno

9.1.1 Perímetro de seguridad física

9.1.2 Controles físicos de entrada

A.9.1

Justificación

No aplicar

8.2.1 Responsabilidades de los gestores

A.8.2

Estado

Áreas seguras

9.1.3 Asegurar las oficinas, salas e instalaciones

9.1.4 Protección contra amenazas externas y ambientales

Aplicado

Existen controles físicos de entrada proporcionales al tamaño y actividad de la organización

Aplicado

Existen controles físicos de entrada proporcionales al tamaño y actividad de la organización

Aplicado

Se han asegurado las oficinas de acuerdo a la legislación vigente y proporcionalmente al tamaño y actividad de la organización

Aplicado

Se han asegurado las oficinas de acuerdo a la legislación vigente y proporcionalmente al tamaño y actividad de la organización (continúa)

8. Caso práctico: modelo de SGSI

Sección

Objetivo

Control

9.1.5 Trabajo en áreas seguras A.9.1

A.9.2

Áreas seguras

Seguridad de los equipos

A.10

A.10.1

Estado

No aplicar

117

Justificación

No existen áreas consideradas seguras

Aplicado

Se establece una zona en recepción para carga y descarga

9.2.1 Emplazamiento y protección de los equipos

Aplicado

Los equipos están 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 instalación 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 contraseña para acceder a ellos

9.2.6 Descarte o re-utilización seguros de los equipos

Aplicado

Los equipos descartados se formatean e instalan de nuevo cuando se ponen de nuevo en servicio

9.2.7 Extracción de elementos de la propiedad

Aplicado

Existe un procedimiento de autorización aunque no está documentado

9.1.6 Áreas de acceso público, de carga y de distribución

Gestión de las comunicaciones y las operaciones

Procedimientos operativos y responsabilidades

10.1.1 Procedimientos operativos documentados

Aplicar

Exigido por UNE/ISO-IEC 27001

10.1.2 Gestión de cambios

Aplicar

Los cambios se realizarán de manera controlada

Aplicado

En circunstancias aconsejables, los equipos se encuentran aislados del resto

No aplicar

No se considera que este control ayude a reducir los riesgos detectados

10.1.3 Separación de tareas

10.1.4 Separación de las instalaciones de desarrollo, prueba y operación

(continúa)

118

Sección

A.10.2

A.10.3

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Objetivo

Gestión de los servicios suministrados por terceros

Planificación y aceptación del sistema

A.10.4

Protección frente a código malicioso y código móvil

A.10.5

Copias de seguridad

Control

Estado

Justificación

10.2.1 Suministro del servicio

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

10.2.2 Revisión y monitorización de servicios de terceras partes

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

10.2.3 Gestión de cambios a los servicios de terceras partes

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

10.3.1 Gestión de la capacidad

Aplicado

Se haría un estudio periódico de las necesidades presentes y futuras de capacidad del sistema informático

10.3.2 Aceptación del sistema

Aplicado

Hasta ahora se hace de una manera informal

10.4.1 Controles contra código malicioso

Aplicado

Se dispone de sistemas antivirus y anti spyware

No aplicar

10.5.1 Respaldo de la información

Aplicado

Necesario para evitar riesgos de pérdida de información

Aplicado

Cada departamento dispondría de una firma digital para usarla en caso de transmisión de información sensible

10.6.1 Controles de red A.10.6

Gestión de la seguridad de la red 10.6.2 Servicios de seguridad de redes

A.10.7

Gestión de soportes

No se considera que este control ayude a reducir el riesgo de los activos identificados

10.4.2 Controles contra código móvil

10.7.1 Gestión de soportes removibles

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

Aplicar

Necesario para evitar riesgos de pérdida de información. Exigido por la LOPD para datos de carácter personal (continúa)

8. Caso práctico: modelo de SGSI

Sección

Objetivo

Control

10.7.2 Descarte de medios (de almacenamiento de la información)

A.10.7

A.10.8

A.10.9

Gestión de soportes

Intercambio de información

Servicios de comercio electrónico

Aplicado

Justificación

Existirían trituradoras de papel

10.7.3 Procedimientos de tratamiento de la información

Aplicar

Dado el resultado del análisis de riesgos, convendría aplicar este tipo de control

10.7.4 Seguridad de la documentación del sistema

No aplicar

No se considera que la aplicación de este control ayudaría a reducir los riesgos detectados

10.8.1 Políticas y procedimientos de intercambio de la información

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

10.8.2 Acuerdos de intercambio

No aplicar

No se realizarían intercambios

10.8.3 Soportes físicos en tránsito

No aplicar

No se extraerían soportes con información relevante fuera de las oficinas

10.8.4 Mensajería electrónica

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

10.8.5 Sistemas de información de negocio

No aplicar

No se considera que este control ayudaría a reducir el riesgo de los activos identificados

10.9.1 Comercio electrónico

No aplicar

No se realizaría comercio electrónico

10.9.2 Transacciones en línea

No aplicar

No se realizarían transacciones en línea

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

Aplicado

Se controlarían los accesos a algunas aplicaciones

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

10.9.3 Información pública disponible

10.10.1 Registro de auditoría A.10.10 Seguimiento

Estado

119

10.10.2 Uso del sistema de monitorización

(continúa)

120

Sección

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Objetivo

Control

Estado

Justificación

10.10.3 Protección de la información de log

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

10.10.4 Logs del operador y del administrador

No aplicar

El tamaño de la organización haría que este control no fuera necesario

10.10.5 Registro de fallos

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

10.10.6 Sincronización horaria

No aplicar

No se considera que este control ayudaría a reducir el riesgo de los activos identificados

A.10.10 Seguimiento

A.11

A.11.1

A.11.2

Control de accesos Requisitos del negocio para el de accesos

Gestión de accesos de los usuarios

Aplicado

Los usuarios contarían con la información pertinente respecto a los permisos de accesos que poseen

11.2.1 Registro de usuarios

Aplicar

El movimiento de alta y baja de usuarios en los sistemas haría indispensable este control

11.2.2 Gestión de privilegios

Aplicar

Se asignarían permisos a nivel del sistema operativo

11.2.3 Gestión de contraseñas de usuarios

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

11.2.4 Revisión de derechos de usuario

Aplicado

Se haría bajo petición del responsable directo del usuario

11.1.1 Política de de accesos

(continúa)

8. Caso práctico: modelo de SGSI

Sección

A.11.3

Objetivo

Responsabilidades del usuario

Control

Control de acceso a la red

Justificación

11.3.1 Uso de contraseñas

Aplicar

Sería necesario para proteger el acceso a la información

11.3.2 Equipamiento desatendido por el usuario

Aplicar

Se consideraría necesario para evitar accesos no autorizados

11.3.3 Política de mesas y pantallas “limpias”

Aplicar

Se evitarían así filtraciones de información indeseadas

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

11.4.2 Autenticación de usuarios para conexiones externas

Aplicar

Dado el resultado del análisis de riesgos, se creería conveniente aplicar este tipo de control

11.4.3 Identificación de equipos en las redes

No aplicar

No se considera que este control ayude a reducir el riesgo de los activos identificados

11.4.4 Protección del puerto remoto de configuración y diagnóstico

Aplicado

Se controlaría este acceso

11.4.5 Segmentación de rede

No aplicar

No se considera que este control ayude a reducir el riesgo de los activos identificados

11.4.6 Control de conexión de red

No aplicar

No se considera que este control ayude a reducir el riesgo de los activos identificados

11.4.7 Control de reencaminamiento de redes

No aplicar

No se considera que este control ayude a reducir el riesgo de los activos identificados

11.4.1 Política de uso de servicios de red

A.11.4

Estado

121

(continúa)

122

Sección

A.11.5

A.11.6

A.11.7

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Objetivo

Control de acceso a los sistemas en operación

Control

Estado

Justificación

11.5.1 Procedimientos seguros de entrada a los sistemas de información

Aplicado

Se controlaría que el acceso a los sistemas de información no muestre información y se limitaría el número de intentos fallidos

11.5.2 Identificación y autenticación de usuarios

Aplicado

Cada usuario contaría con una ID y una contraseña

11.5.3 Sistemas de gestión de contraseñas

Aplicar

Cada usuario tendría su contraseña. Este control sería necesario para evitar accesos que pudieran suplantar la identidad de algún usuario

11.5.4 Uso de utilidades del sistema

Aplicar

Se restringiría el uso de estas utilidades.

11.5.5 Finalización del tiempo de sesión

No aplicar

No se considera que este control ayudaría a reducir los riesgos detectados

11.5.6 Limitación en el tiempo de conexión

No aplicar

No se considera que este control ayudaría a reducir los riesgos detectados Sólo se daría acceso a la información que necesitara el usuario para realizar su trabajo

11.6.1 Restricciones de acceso a la información

Aplicado

11.6.2 Aislamiento de sistemas sensibles

No aplicar

No se considera que este control ayudaría a reducir el riesgo de los activos identificados

11.7.1 Comunicaciones e informática móvil

No aplicar

No se considera que este control ayudaría a reducir el riesgo de los activos identificados

11.7.2 Teletrabajo

No aplicar

Se considera que el coste de implementación de este control superaría al beneficio que se obtendría

Control de acceso a las aplicaciones y la información

Informática móvil y teletrabajo

8. Caso práctico: modelo de SGSI

123

8.6. Documentación 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 Descripción de los objetivos del plan de tratamiento del riesgo.

8.6.2. Alcance Definición del periodo al que va afectar el plan de tratamiento del riesgo.

8.6.3. Responsabilidades El responsable de seguridad se encargará de la ejecución y supervisión de las distintas actividades. La dirección debería revisar y aprobar el plan y los objetivos marcados en el plan.

8.6.4. Tareas

1

Implementación del SGSI Aprobación de la política de seguridad Aprobación del inventario de activos Aprobación del análisis de riesgos y los riesgos residuales Aprobación del documento de aplicabilidad Aprobación del plan de tratamiento del riesgo Aprobación de procedimientos Publicación de documentos Impartir formación Implementar procedimientos

2

Auditoría interna

3

Revisión del SGSI

4

Auditoría de certificación

Mes 12

Mes 11

Mes 10

Mes 9

Mes 8

Mes 7

Mes 6

Mes 5

Mes 4

Mes 3

Actividades

Mes 2

ID

Mes 1

Un ejemplo podría ser:

124

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.6.5. Seguimiento Verificación del cumplimiento del plan en el plazo acordado por el responsable de seguridad. En el caso de que produzcan desviaciones, se deberían tomar las medidas oportunas para corregirlas y, en caso necesario, se debería actualizar el plan para reflejar los cambios.

8.6.6. Objetivos e indicadores Un ejemplo podría ser: Indicador

Métrica

Fórmula

Responsable

Frecuencia de recogida

Fuente

Mejorar la efectividad del control de accesos en un 5%

Porcentaje de accesos no autorizados

(Número de accesos no autorizados / Número total de accesos) × 100

Responsable de sistemas

Trimestral

Registro de accesos

Mejorar la efectividad de la formación en un 5%

Valoración de la formación en sí del personal

Suma total de valoraciones totales de cada asistente / Número de asistencias

Responsable de seguridad

Trimestral

Registros de formación

Porcentaje de las incidencias de seguridad debidas a fallos del usuario

(Número de incidencias de seguridad debidas a fallos del usuario / Número de incidencias) × 100

Responsable de sistemas

Trimestral

Registros de incidencias

Porcentaje de los equipos correctamente mantenidos

(Número de equipos que pasaron su mantenimiento en fecha / Número de equipos totales de la empresa) × 100

Responsable de sistemas

Trimestral

Registro de mantenimientos

Porcentaje de incidencias debidas a fallos de mantenimiento

(Número de incidencias de seguridad debidas a fallos del mantenimiento / Número de incidencias) × 100

Responsable de sistemas

Trimestral

Registro de incidencias

Mejorar la efectividad de los mantenimientos en un 5%

(continúa)

8. Caso práctico: modelo de SGSI

Frecuencia de recogida

Indicador

Métrica

Fórmula

Responsable

Reducir un 5% los ataques con éxito a los sí

Porcentaje de ataques con éxito

(Número de ataques detectados / Número de ataques con impacto en los sí) × 100

Responsable de sistemas

Porcentaje de incidencias por ataques a los sí

(Número de incidencias de seguridad debidas a ataques / Número de incidencias) × 100

Responsable de sistemas

Trimestral

Porcentaje de disponibilidad

(Número de horas sin disponibilidad / Número de horas disponibilidad necesaria) × 100

Responsable de sistemas

Trimestral

Mejorar la disponibilidad el 5%

Trimestral

125

Fuente

Registro de incidencias Registros del sistema

Test de intrusión Monitorización de los sistemas

Registros del sistema

8.7. Documentación del Procedimiento de auditorías internas 8.7.1. Objetivo El presente procedimiento debería dar cumplimiento a la Norma UNE-ISO/IEC 27001 en lo relativo a las actividades, criterios y responsabilidades para la realización de auditorías internas del sistema de gestión de seguridad de la información.

8.7.2. Alcance Este procedimiento se debería aplicar a todos los servicios incluidos dentro del alcance del sistema de gestión de seguridad de la información.

8.7.3. Responsabilidades El responsable de seguridad debe definir e implementar un sistema de auditorías internas que incluya la preparación, realización, registro y seguimiento de las mismas. Para programar su frecuencia de realización ha de tenerse en cuenta que se debe

126

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

auditar por completo el conjunto del SGSI cada tres años. Lo más recomendable es hacer una anualmente. El personal que realice la auditoría no tendrá en ningún 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 continuación.

8.7.4.1. Cualificación del personal El personal encargado de la ejecución de las auditorías debería tener las siguientes características: • Preparación profesional necesaria en las metodologías 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 relación con las actividades involucradas.

8.7.4.2. Planificación de la auditoría Las auditorías pueden hacerse sobre la totalidad del SGSI implicando a toda la organización, considerándose en estos casos como global. O bien, podría hacerse sobre una parte en concreto, implicando a un determinado departamento, contrato, sector, etc., considerándose entonces como parcial. El responsable de seguridad debería realizar anualmente un plan de auditorías que incluya las fechas y el auditor de cada auditoría. Este plan será aprobado por la dirección y el responsable de seguridad lo distribuirá a todos los departamentos y auditores afectados. Con independencia de lo anterior, se deberían realizar auditorías 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. Caso práctico: modelo de SGSI

127

8.7.4.3. Preparación de la auditoría Las auditorías se llevan a cabo mediante una lista de comprobación que, en cada caso, debe ser elaborada por el auditor bajo la supervisión del responsable de seguridad y que será enviada al departamento afectado. El auditor debe establecer el alcance de la auditoría, las actividades a auditar, los documentos aplicables y la lista de comprobación. Basándose en esta información, confeccionar la lista de comprobación que debería ser revisada por el responsable de seguridad y enviada, con suficiente antelación, al departamento que va a ser auditado. Además, en el caso de modificarse la inicialmente programada, en dicha lista se incluiría la nueva fecha prevista de realización de la auditoría y que estaría acordada entre los auditores y el área a auditar.

8.7.4.4. Realización de la auditoría El primer paso en la auditoría debería ser una reunión donde se confirme el alcance de la misma, su secuencia y donde se discuta aquellos puntos que cualquiera de las partes crea conveniente. A continuación, se procedería a llevar a cabo la auditoría en sí mediante el uso de la lista de comprobación, anteriormente realizada, como guía de trabajo. Se examinaría simultáneamente la evidencia objetiva para comprobar que se cumplen los requisitos y los controles aplicables. En caso de que la auditoría se realizara como consecuencia de la existencia de no conformidades, se profundizaría a fin de identificar las causas y efectos y poder definir la acción correctiva/preventiva requerida. Terminada la auditoría, el equipo auditor redactaría un informe de resultados, identificando de manera clara y concreta las no conformidades detectadas. Cuando haya no conformidades importantes, se debería programar la fecha de la siguiente auditoría para verificar su eliminación. El responsable del departamento afectado por la no conformidad detectada o en su caso el comité de seguridad, elaborará la acción correctiva/preventiva a llevar a cabo, que será aprobada por el responsable de seguridad. El responsable del área afectada por la acción correctiva/preventiva deberá tomar las medidas necesarias para aplicar totalmente las acciones correctivas y preventivas dentro del plazo señalado en el informe. Los informes de auditoría serán archivados por el responsable de seguridad y se enviarán copias a dirección y al responsable del área auditada.

128

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

El cierre de la acción correctiva/preventiva se realizará una vez que, tanto el responsable del área afectada como los auditores internos, hayan comprobado su efectividad. En el apartado correspondiente del impreso de la acción correctora, se dejará constancia de dichas comprobaciones con lo que se considerará la acción correctiva/preventiva cerrada.

8.7.5. Requisitos de documentación Los documentos asociados a este procedimiento son: • Plan de auditorías. • Lista de comprobación. • Informes de auditoría. • Acciones correctivas y preventivas.

8.7.6. Referencias Los documentos de referencia para la realización de este procedimiento son: • Norma UNE-ISO/IEC 27001. • Norma UNE-ISO/IEC 17799. • Política de seguridad. • Procedimientos de seguridad. • Objetivos de seguridad. • Acciones correctivas y preventivas. • Resultados de otras auditorías: anteriores auditorías internas y externas del SGSI, auditorías de la LOPD, tests de intrusión, etc. • Revisión del sistema de gestión.

8.7.7. Anexos • Lista de comprobación de auditoría (véase la figura 8.1). • Informe de auditoría (véase la figura 8.2). • Plan de auditorías internas (véase la figura 8.3).

8. Caso práctico: modelo de SGSI

Auditoría de calidad N.o

Departamento

Fecha

Cuestiones a aplicar: • Verificación del cumplimiento de las no conformidades detectadas en anteriores auditorías. • Revisión de documentación existente en el puesto. • Cumplimiento del procedimiento (el que aplique al departamento). • Verificación de registros. • Cambios en la estructura y funcionamiento del departamento.

Observaciones

Auditor Jefe

Dpto. afectado

Fecha

Fecha

Figura 8.1. Lista de comprobación de auditoría

129

130

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Fecha auditoría

Número auditoría

Área/Proceso clave auditado

Auditor

Grupo auditor

Hallazgos detectados: Requisito de la norma

No conformidad

Hallazgos

Comentarios

Nombre Elaborado por

Nombre Revisa y aprueba

Fecha

Fecha

Figura 8.2. Informe de auditoría

Firma

Firma

Observación

8. Caso práctico: modelo de SGSI

N.o

Departamento/Sección

Fecha prevista

131

Auditores

Figura 8.3. Plan de auditoría interna

8.8. Documentación del Procedimiento para las copias de seguridad 8.8.1. Objetivo El presente procedimiento general debería dar cumplimiento al control 10.5.1 de la Norma UNE-ISO/IEC 17799 para asegurar la información de respaldo. Debería definir la sistemática establecida para crear copias de seguridad de manera óptima y que no sean obviadas por algún usuario del sistema.

132

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.8.2. Alcance Debería estar dirigida a todos los equipos de proceso de información que realizan copias de seguridad de la información principal.

8.8.3. Responsabilidades Responsable

Administrador del sistema

Actividades

Se deberían definir: • Todos los mecanismos necesarios para la correcta realización de las copias de respaldo y recuperación. • La realización de dichas copias según la normativa que ellos mismos hayan definido.

8.8.4. Términos y definiciones Equipos de proceso: cualquier equipo electrónico utilizado para procesar de forma automática la información.

8.8.5. Procedimiento Para asegurar que las copias de respaldo y recuperación son realizadas correctamente según la normativa vigente y las definiciones establecidas por el administrador, se deberían establecer las siguientes medidas:

8.8.5.1. Realización de las copias de seguridad en servidores La información que debería requerir copia de seguridad es: • Documentación. • Información del sistema. • Páginas web. • Bases de datos. • Correos electrónicos.

8. Caso práctico: modelo de SGSI

133

Las copias de seguridad se deberían realizar periódicamente volcando la información desde el servidor a un DVD que se debería almacenar de manera adecuada, en un sitio protegido y controlado por el responsable correspondiente. En el caso de que la información a guardar tuviera datos extremadamente confidenciales, ésta debería ser almacenada en una segunda ubicación diferente a la del fichero principal haciendo para ello distintas copias y guardándolas en distintos sitios bajo tutela del responsable correspondiente. Si se produjeran fallos en la realización de la copia de respaldo, se deberá proceder a realizarla de nuevo, bien de manera manual o bien automática con un nuevo soporte.

8.8.5.2. Rotación de los soportes de copias de seguridad y recuperación en servidores No se conveniente reutilizar los soportes de información. Cada semana se debería utilizar un DVD diferente convenientemente identificado (contenido guardado en él y fecha de realización). Igualmente, se debería desechar y sustituir el soporte cuando se hayan encontrado errores en la grabación del mismo. Todas estas altas y bajas de soportes deberán quedar registradas de acuerdo a la sistemática definida en el “Procedimiento de gestión de soportes”.

8.8.5.3. Recuperación de datos de servidores La recuperación de datos de los servidores, así como del resto de equipamiento informático, deberá ser llevada a cabo únicamente por los administradores del sistema utilizando la copia de respaldo disponible más reciente o aquélla que sea más adecuada a cada situación. En el caso de que existan aplicaciones que lo permitan, puede utilizarse la opción de la propia aplicación para restaurar los datos. De otra manera, su recuperación consistirá en la reposición de los ficheros guardados en la copia de respaldo, copiándolos sobre la ubicación de los ficheros originales. En caso de ser necesario, se grabarán los datos no incluidos en la copia de seguridad manualmente. En caso de utilizar personal técnico externo no habitual para estas tareas, éste deberá estar acompañado en todo momento del responsable de seguridad o del personal correspondiente. La recuperación de datos deberá registrarse como incidencia y quedar registrada de acuerdo a la sistemática definida en el “Procedimiento de gestión de incidencias”.

134

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

8.8.5.4. Realización de copias de seguridad en los PC La realización de las copias de respaldo de aquellos datos ubicados en los PC de usuario consistirá en una copia extraída a un soporte externo cada vez que las modificaciones de la información sean relevantes. De la misma manera que se ha detallado en el apartado 5.2, todas las altas y bajas de soportes deberían quedar registradas de acuerdo a la sistemática definida en el “Procedimiento de gestión de soportes”.

8.8.5.5. Recuperación de datos de los PC La recuperación de datos consistirá en la reposición de los ficheros guardados en la copia de respaldo, copiándolos sobre la ubicación de los ficheros originales.

8.8.6. Requisitos de documentación • Inventario de equipos de proceso. • Registro de simulaciones de recuperación de información. • Inventario de soportes. • Registro de incidencias.

8.8.7. Referencias • Política de seguridad. • UNE-ISO/IEC 17799. • Manuales de funcionamiento y uso de los equipos electrónicos. • Ley Orgánica de Protección de Datos.

8.8.8. Anexos Registro de copias de seguridad (véase la figura 8.4).

8. Caso práctico: modelo de SGSI

Registro de copias de seguridad Fecha de copia:

___ / ___ / ______

Hora:

___ : ___

Soporte

Tipo de soporte y número Contenido Servidor o equipo Información almacenada

Almacenamiento

Medio Responsable Lugar

Autorización

Persona responsable de la copia Persona que autoriza Observaciones Firmas

Figura 8.4. Registro de copias de seguridad

135

9

Comprender el Esquema Nacional de Seguridad (ENS)

9.1. Generalidades del ENS El ENS establece la política de seguridad en el ámbito de la administración electrónica. Para ello, se han definido unos principios básicos y unos requisitos mínimos que se consideran imprescindibles para proteger adecuadamente unos servicios tan críticos y sensibles como los que nos ocupan. El alcance del ENS son los sistemas de información, los datos, las comunicaciones, y los servicios electrónicos de cualquier Administración Pública (estatal, autonómica o local), así como de las entidades dependientes de ellas que se utilicen para la prestación de servicios electrónicos. El Real Decreto 3/2010 pretende con su aplicación asegurar el acceso, la integridad, la disponibilidad, la autenticidad, la confidencialidad, la trazabilidad y la conservación de los datos, las informaciones y los servicios utilizados en medios electrónicos que se gestionan en las Administraciones Públicas. Lógicamente, el ENS no se ha desarrollado sin consultar la normativa y legislación que existen en el sector TIC a nivel internacional, por lo que muchos de los conceptos que se manejan tienen similitudes y paralelismos con los que se han visto anteriormente en esta publicación. Sin embargo, ha de tenerse en cuenta que las normas son documentos voluntarios que las organizaciones adoptan con distintos fines (mejorar su gestión, distinguirse en el mercado, etc.). En cambio, el ENS es una obligación legal en el ámbito de la administración electrónica y no es opcional para los organismos públicos 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.

138

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Tabla 9.1. Correspondencias entre el ENS y la Norma UNE-ISO/IEC 27001 ENS

Requisito

UNE-ISO/IEC 27001

11

Política de seguridad

4.2.1.b)

12

Compromiso de la dirección

5.1.c) d)

Evaluación de riesgos

4.2.1.c) d) e)

13.3

Gestión de riesgos

4.2.1.f) g)

27.1

Documento de aplicabilidad

4.2.1.g)

14 - 15

Formación

5.2.2

34.1

Auditorías

4.2.3.e) - 6

26

Mejora continua

8.1

13.1 13.2

9.2. Principios básicos del ENS El ENS señala unos principios básicos y unos requisitos mínimos que conducen a la exigencia de la gestión continuada de la seguridad, para la que cabe aplicar un sistema de gestión. Para satisfacerlos se puede aplicar un modelo de tipo PCDA como el expuesto en la Norma UNE-ISO/IEC 27001. Los principios básicos establecidos en el ENS son los siguientes: • Seguridad integral. Sin exigir expresamente que se desarrolle un sistema de gestión, 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 visión global de los problemas de seguridad y su importancia dentro de la organización. Con esto se evitan agujeros de seguridad y utilizar recursos en aspectos que tal vez no lo necesiten. • Gestión de riesgos. Es un aspecto que recoge cualquier método o modelo de gestión de seguridad de la información, ya que sólo 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 información y su entorno están en constante cambio, es necesario mantener la evaluación de los riesgos actualizada. • Prevención, reacción y recuperación. Establecer medidas de seguridad de distinto 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 instalación de un antivirus como medida de prevención contra infecciones o el uso de sistemas de autenticación 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 daños (por ejemplo, el uso de un sistema de monitorización de la red alertará a los administradores si se produce un acceso no autorizado, y permitirá tomar acciones para limitar el daño o incluso evitarlo). Asimismo, deben existir medios para recuperarse de los daños ocasionados por un incidente. Si, por ejemplo, la intrusión ha ocasionado la eliminación de un documento, se debería contar con una copia de seguridad que permita recuperar los datos. • Líneas de defensa. El conjunto de medidas de seguridad elegidas tienen que estar implementadas de modo que los sistemas de información cuenten con distintos niveles de protección, de manera que un incidente vaya encontrando dificultades que le impidan hacer todo el daño del que serían 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 autenticación del acceso, tiempos limitados de conexión, un protocolo de actuación para cerrar aquellos puertos que sean necesarios o cerrar segmentos de red, etc.). Este enfoque está alineado con el objetivo de contar con una gestión de la seguridad integral, y con tener distintos tipos de medidas de seguridad. • Reevaluación periódica. 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 según lo esperado. Hay que realizar una revisión periódica 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 información y a su entorno. • Función diferenciada. La gestión de la seguridad de la información es una tarea en la que están involucradas muchas personas que, dependiendo de su perfil y funciones, tienen distintas prioridades. Para no comprometer la seguridad, el ENS ha definido como principio básico que los responsables de la

140

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

información, del servicio y de la seguridad sean personas distintas. De esta manera, cada responsable debe definir los requisitos que aplican a su información 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 políticas disponibles.

9.3. Requisitos mínimos de seguridad del ENS El ENS requiere que las organizaciones cuenten con una política formalmente aprobada y se establezcan las directrices a seguir para gestionar la seguridad en la organización. Dicha política tiene que reunir una serie de requisitos mínimos que se detallan a continuación.

9.3.1. Organización e implementación del proceso de seguridad La gestión 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 información y el de los servicios o el comité de seguridad. Pero la responsabilidad de la seguridad de la información es universal, cada persona debería ser responsable de la información y de los servicios a los que tiene acceso. La política debe contemplar todas estas responsabilidades y las líneas de actuación que se deben observar. Además, debe ser publicada y difundida de manera que todo el mundo la conozca y se pueda aplicar.

9.3.2. Análisis y gestión de los riesgos La política recogerá el modo en el que se va a realizar el análisis y la gestión de los riesgos que afectan a los sistemas de información de la organización. Para el análisis se puede usar cualquier metodología internacionalmente aceptada. En la práctica, la amplia difusión de la metodología MAGERIT y de PILAR, su herramienta asociada, hacen que sean las más comúnmente utilizadas en la Administración Pública española. Para la gestión de los riesgos se aplicarán medidas de seguridad que sean proporcionales a los riesgos que se pretenden mitigar, debiendo compensar en coste y esfuerzo su implementación.

9. Comprender el Esquema Nacional de Seguridad (ENS)

141

9.3.3. Gestión de personal El personal es una parte fundamental de los sistemas de información. Cada uno de ellos tiene responsabilidades en materia de seguridad, acorde con el puesto desempeñado. La comunicación de estas responsabilidades, y una adecuada formación y concienciación en materia de seguridad permitirán una correcta gestión de la misma. Además, tendrán que existir normas de seguridad y mecanismos para verificar que se cumplen los preceptos marcados. Los usuarios estarán identificados en los sistemas 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 gestión de la seguridad serán realizadas por personal cualificado para ello, que deberán contemplar en ellas todo el ciclo de vida de los sistemas, desde su compra e instalación inicial hasta su retirada, pasando por su mantenimiento. Para ello, es importante que se reciba la formación 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. Autorización y control de los accesos Uno de los primeros asuntos a tratar cuando se trata de seguridad es la definición de la política que se va a seguir para autorizar accesos, es decir, qué se va permitir a cada usuario y cuáles van a ser los criterios para la designación de los permisos. La recomendación es autorizar el acceso a los servicios y a la información en función de la necesidad de cada puesto. Además, se deberá tener un mecanismo que permita revisar y anular los privilegios de acceso para evitar incidentes.

9.3.6. Protección de las instalaciones La seguridad física es el primer paso para garantizar la protección de los servicios y la información que se gestionan. Para ello, los sistemas que albergan información deben estar físicamente en otras instalaciones, protegidos contra accesos no autorizados y con medidas contra incendios, inundaciones, etc.

142

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

9.3.7. Adquisición de nuevos productos de seguridad Cuando se valoren nuevos productos de seguridad para su adquisición, se debería tener en mayor consideración 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 sistemas sean diseñados y configurados de manera que su uso sea seguro. Esto implica actuaciones en distintos aspectos: • Que sólo tengan la funcionalidad necesaria para el uso que se pretende dar al sistema. • Que las funciones de operación, administración y registro de actividad sean las mínimas necesarias. • Que estas funciones sólo 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 estén disponibles ni accesibles funciones 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 actualización del sistema Para garantizar en todo momento la integridad del sistema, no se podrá instalar ningún elemento físico ni lógico sin tener una autorización formal previa para ello. La actualización 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 aplicación o no a los sistemas y ejecutar los cambios que se aprueben hará que se mantenga el nivel de seguridad del sistema.

9. Comprender el Esquema Nacional de Seguridad (ENS)

143

9.3.10. Protección de la información almacenada y en tránsito Es muy habitual que las medidas de protección de las que goza la información 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 diseñar medidas de seguridad que tengan en cuenta que muchas veces la información se encuentra en entornos inseguros: equipos portátiles, asistentes personales (PDA), dispositivos periféricos, soportes de información y comunicaciones sobre redes abiertas o con cifrado débil. Los procedimientos para la recuperación y conservación a largo plazo de los documentos electrónicos producidos por las Administraciones Públicas en el ámbito de sus competencias se encuentran sujetos a este requisito. En este aspecto es donde se amplía de alguna manera el alcance del ENS. Hemos visto que sus requisitos aplican únicamente a los servicios de administración electrónica, pero aún existe mucha información en soporte no electrónico, que se ha originado o es el origen de información electrónica, 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. Prevención ante otros sistemas de información interconectados De igual manera que se protege el perímetro físico de un sistema, debe protegerse el lógico. Como es intrínseco a la administración electrónica el tener los sistemas internos de la entidad conectados con internet y con otras entidades, este perímetro lógico 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 información, ya que es una de las herramientas principales para impedir accesos no autorizados. Debe complementarse 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 corrección que sean necesarias, así como proceder a la sanción del infractor si fuera

144

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

necesario. Lógicamente, debe tenerse cuidado a la hora de recopilar estos datos para no entrar en conflicto con lo estipulado en la Ley Orgánica de Protección de Datos de carácter personal y sus desarrollos, o invadir la privacidad de los usuarios.

9.3.13. Incidentes de seguridad La gestión de los incidentes de seguridad es uno de los pilares de cualquier sistema de gestión 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 rápidamente para minimizar los daños como luego analizar y extraer conclusiones, que permitan incorporar mejoras al sistema de gestión, a los de información, 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 detección y reacción frente al código dañino.

9.3.14. Continuidad de la actividad El riesgo de que algún incidente grave inutilice o no permita acceder a los medios habituales de trabajo, por su grave impacto en los servicios que se prestan, requiere de un plan de continuidad que de alguna manera permita seguir operando. Como mínimo, se dispondrá de copias de seguridad y una serie de protocolos de actuación.

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 contrario, los cambios en el contexto (el personal, la tecnología, nuevas vulnerabilidades, etc.) harán que el nivel descienda.

9.3.16. Soporte al cumplimiento Para cumplir con todos estos requisitos mínimos 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.

9. Comprender el Esquema Nacional de Seguridad (ENS)

145

• Deben escogerse según la categoría del sistema. • Pueden aplicarse otras medidas que se estimen oportunas según los servicios y la información gestionados y los riesgos identificados mediante el análisis de riesgos. • Que no puede haber conflicto con los requisitos de la LOPD. Si se considera que algún sistema de información no está relacionado con el ámbito de aplicación del ENS, la entidad podrá excluirlo del sistema de gestión de la seguridad. Para facilitar el cumplimiento del ENS, existen infraestructuras y servicios comunes reconocidos en las Administraciones Públicas. Asimismo, como herramientas de consulta, el Centro Criptológico Nacional (CCN) ha elaborado y difundido guías de seguridad.

9.4. Otros requisitos 9.4.1. Comunicaciones electrónicas Evidentemente, las comunicaciones son un aspecto crítico a tener en cuenta en el momento de diseñar la seguridad de un sistema de información por su sensibilidad. 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 inequívoca. No hay que olvidar que las comunicaciones tienen un valor y eficacia jurídicos que no se deben perder en ningún momento. Este es el caso de las notificaciones y publicaciones electrónicas, ya que el ENS exige que se asegure la autenticidad del organismo que las publica, la integridad de la información publicada, que conste la fecha y hora de la puesta a disposición del interesado de la resolución o el acto objeto de publicación o notificación, así como del acceso a su contenido, además de que se asegure la autenticidad del destinatario de la publicación o notificación. Una de las herramientas que se utilizará para garantizar la seguridad de las comunicaciones será la firma electrónica, que protege la autenticidad de quien emite una comunicación electrónica. Su utilización debe estar regulada mediante una política y aplicada según lo estipulado en el anexo II del ENS y el Esquema Nacional de Interoperabilidad.

146

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

9.4.2. Auditoría de la seguridad Para garantizar la adecuación en todo momento del sistema a los requisitos del ENS, se estipulará la realización de una auditoría cada dos años, como mínimo, o antes si hay cambios importantes en el sistema de información, que puedan afectar a las medidas de seguridad requeridas. Esta auditoría deberá servir también como herramienta de mejora de la eficacia de las medidas de seguridad establecidas. Deberán emitirse informes que identifiquen las deficiencias y desviaciones del sistema de seguridad respecto a lo establecido en el ENS, que serán presentados al responsable del sistema para que valore los resultados y adopte las medidas de corrección adecuadas.

9.4.3. Estado de seguridad de los sistemas Regularmente, el Comité Sectorial de Administración Electrónica elaborará un informe en el que se recogerán las principales variables de la seguridad en los sistemas de información a los que se refiere el ENS, de forma que permita elaborar un perfil general del estado de la seguridad en las Administraciones Públicas.

9.4.4. Respuesta a incidentes de seguridad Para ayudar a dar respuesta a los incidentes de seguridad, el Centro Criptológico Nacional (CCN) pone a disposición de las entidades el Centro Criptológico Nacional-Computer Emergency Reaction Team (CCN-CERT). Se denomina CERT a un grupo de trabajo responsable de desarrollar medidas de prevención y de reacción ante incidentes de seguridad en los sistemas de información. Este CCN-CERT prestará a las Administraciones Públicas los siguientes servicios: • Soporte y coordinación para la resolución de incidentes de seguridad y tratar vulnerabilidades. • Investigación y divulgación de las mejores prácticas sobre seguridad de la información. En este contexto se han desarrollado las series de documentos Centro Criptológico Nacional-Seguridad de las Tecnologías de Información y Comunicaciones (CCN-STIC), elaboradas por el Centro Criptológico Nacional y que se pueden consultar en su sitio web. • Formación en el campo de la seguridad de las tecnologías de la información. • Información sobre vulnerabilidades, alertas y avisos de nuevas amenazas.

9. Comprender el Esquema Nacional de Seguridad (ENS)

147

• Un programa para informar, formar, emitir recomendaciones y proporcionar herramientas para que cada entidad pueda desarrollar sus propias capacidades 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 electrónicos por ser la primera toma contacto del ciudadano con la administración electrónica. • 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 planificación 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 garantizar que funciona correctamente. Deben establecerse puntos y elementos de control para realizar esta tarea. • Las entidades sujetas al ENS deben hacer públicas, en las correspondientes sedes electrónicas, las declaraciones de conformidad con el ENS y cualquier otro distintivo de seguridad que posean como, por ejemplo, la certificación según la Norma UNE-ISO/IEC 27001.

9.4.6. Actualización 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, mejorándolo con el tiempo para responder a los cambios en los servicios de administración electrónica, la evolución tecnológica, y los nuevos estándares internacionales sobre seguridad y auditoría en los sistemas y tecnologías de la información.

9.4.7. Categorización de los sistemas El ENS describe en su anexo I el modo de proceder para asignar una categoría al sistema o sistemas que se identifiquen en una entidad. Hay tres categorías, baja, media y alta, a las que se adscribirán los sistemas en función de la gravedad del impacto que tendría un incidente que afectara a la seguridad de la información o

148

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

de los servicios. Esta categoría determinará las medidas que haya que aplicar al sistema, y por lo tanto, el esfuerzo que habría que dedicar a la seguridad del mismo. El responsable de cada información o servicio es quien debe realizar las valoración del impacto de un incidente en la disponibilidad, autenticidad, integridad, confidencialidad o trazabilidad de ese activo, y mantenerlas actualizadas. El responsable del sistema es quien debe asignar la categoría al mismo.

9.4.8. Formación Ningún sistema de gestión puede funcionar si no se cuenta con el personal adecuadamente 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 formación necesaria que garantice su cumplimiento.

10

Implementación del ENS

10.1. El plan de adecuación La implementación del ENS puede dividirse en dos partes: • La elaboración del plan de adecuación. • La ejecución de las acciones definidas en dicho plan. El plan de adecuación lo desarrollará el responsable de seguridad cuando lo haya o la persona a la que se asigne esta función de forma temporal y debe contener la siguiente información: • La política de seguridad. Cada entidad debe contar con una política de seguridad que recoja sus objetivos, el marco legal, los roles y funciones de seguridad, así como los comités de seguridad y las directrices para la gestión de la documentación, entre otros puntos. Si no posible elaborarla y aprobarla en esos momentos, debe planificarse como una tarea a realizar en el plan de mejora. • Información que se maneja, con su valoración. Se identifica primero la información que se utiliza para la prestación de los servicios electrónicos y después se evalúa en un rango de tres categorías (baja, media y alta) cómo sería el impacto de un incidente sobre esa información en cada uno de las cinco dimensiones de seguridad: confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad. Los criterios generales de valoración 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.

150

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

– 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 dañe seriamente algún 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 dañado gravemente algún activo o incluso haya sido destruido, se haya incumplido gravemente alguna ley o se haya perjudicado irremediablemente a alguna persona. Si esta valoración la realiza el responsable de seguridad, se considerará provisional y deberá planificarse la valoración por parte de los propietarios de la información en el plan de mejora. • Servicios que se prestan, con su valoración. Como en el caso de la información, hay que identificar los servicios, valorando las cinco dimensiones del mismo modo, en función de la gravedad del impacto de un incidente en la entidad. Además 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 carácter personal. Será bastante habitual por la naturaleza de los servicios electrónicos, que se manejen datos de carácter personal. Se identificarán o se hará referencia al Documento de Seguridad de la LOPD. • Categoría del sistema. Las valoraciones de la información y los servicios son los datos de partida para decidir la categoría del sistema o los sistemas identificados. En cada dimensión é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 están valoradas de nivel bajo, será de categoría básica. Si alguna de ellas es de nivel medio y ninguna es alto, será de categoría media. Si alguna de ellas es de nivel alto, la categoría del sistema será alta. Para economizar recursos es preferible desglosar el sistema en tanto subsistemas como sea razonable hacerlo, de manera que las medidas para el nivel alto, que son más exigentes que para el resto, se apliquen al menor número de servicios e información posible. Como ejemplo, se puede tomar una sede electrónica. Si la consideramos como un único sistema, teniendo en cuenta los requisitos planteados por la Ley 11/2007, la disponibilidad del registro electrónico tendrá que ser de 24 horas al día, los 365 días del año, por lo

10. Implementación del ENS

151

tanto, se podrá valorar su dimensión de disponibilidad como de nivel alto, y consecuentemente, la categoría del sistema será alta. Sin embargo, si desglosamos la sede electrónica en varios subsistemas, por ejemplo: – Página web. – Registro electrónico. – Notificaciones. – Servicio de validación de documentos. – Tablón de anuncios. Como solamente el registro electrónico tiene ese requisito de disponibilidad, este subsistema será de nivel alto, pero el resto pueden ser de niveles más bajos, con el consiguiente ahorro de esfuerzo y recursos. • Declaración de aplicabilidad de las medidas del anexo II del ENS. Es un requisito formal del ENS, consiste en un listado de las medidas de seguridad a aplicar al sistema de acuerdo con la categoría 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 según la categoría del sistema. Por ejemplo, la medida “op.pl.1, Análisis de riesgos”, aplica al sistema, y si es de nivel bajo habría que hacer un análisis informal, si fuera de nivel medio uno semiformal y si fuera de nivel alto uno formal. Otro ejemplo, la medida “mp.if.9, Instalaciones alternativas”, afecta a la disponibilidad y no aplicaría a los sistemas de niveles bajo y medio, pero sí a los de nivel alto. Si hubiera medidas que habría que aplicar debido al nivel del sistema, pero no se consideran aplicables, habría que justificar por qué es así. Asimismo, si se usaran otras medidas diferentes de las propuestas por el ENS, también habría que justificarlas e identificar a cuáles sustituyen. Esta declaración estará firmada por el responsable de seguridad. • Análisis 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, además de establecer un mapa de riesgos potenciales y actuales que ponga de manifiesto el progreso en la eliminación de problemas. Los riesgos residuales, los que quedan tras la aplicación de las medidas de seguridad seleccionadas, deben ser formalmente aceptados por los responsables de la información y servicios afectados, o en su defecto, lo hará el responsable de seguridad. El ENS exige que la metodología que se use para la realización del análisis de riesgos sea reconocida internacionalmente. La metodología MAGERIT, del Ministerio de Administraciones Públicas, así como su herramienta aso-

152

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

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 implementación de MAGERIT y PILAR en la Administración Pública española, junto con el coste nulo que suponen, hacen que sean la elección habitual a la hora de decidir la herramienta a utilizar. • Insuficiencias del sistema. Se realizará un análisis de los requisitos que no se están cumpliendo, como punto de partida para la definición del plan de mejora. Estas insuficiencias pueden venir de desviaciones respecto a los distintos artículos 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 carácter personal tratados por el sistema. • Plan de mejora seguridad, incluyendo plazos estimados de ejecución. Se determinarán las acciones a tomar para eliminar o subsanar las insuficiencias detectadas y se planificará su ejecución, indicando los plazos previstos de ejecución, los hitos del proyecto y la estimación de costes. Una vez elaborado y aprobado el plan de adecuación, la entidad puede publicar su declaración de conformidad en la sede electrónica, así como otros certificados de accesibilidad, interoperabilidad, menciones de calidad de cualquiera de las Administraciones Públicas (estatal, autonómica y local), de organizaciones internacionales o de organismos privados. Esta declaración ha de ir firmada por el titular del organismo emisor de la declaración de conformidad, que ha de identificarse con su nombre completo y cargo que desempeña.

10.2. Adecuación al ENS La adecuación al ENS pasa por la realización de una serie de tareas que coinciden a grandes rasgos con las que se vieron previamente para la implementación de un SGSI según la Norma UNE-ISO/IEC 27001: definir el alcance de la aplicación del ENS, la política de seguridad, asignar responsabilidades, realizar un análisis de riesgos, etc. Hay que señalar que, dado que cumplir con el ENS es una obligación legal, no es posible obviar ninguna de las acciones y documentos que exige.

10.2.1. Planificación La planificación es la realización del plan de adecuación.

10. Implementación del ENS

153

Toda la información necesaria para poder comparar el estado de la seguridad en la entidad con el estado que pide el ENS, se recopilará durante la realización del plan de adecuación, que a su vez contendrá el plan de mejora con las acciones a tomar. Este plan incluirá: • El desarrollo y la aprobación de una política de seguridad. • La asignación y aprobación de los responsables de seguridad, de la información y de los servicios. • La definición la normativa de seguridad. Serán documentos que detallen cómo y quién realizará las distintas tareas y cómo se identificarán y resolverán los comportamientos anómalos, tales como procedimientos para la gestión de incidencias, la monitorización del sistema o el plan de continuidad. • La definición y la descripción de los procesos de autorización, formalizando las autorizaciones que cubran todos los elementos de los sistemas de información: instalaciones, equipos, aplicaciones, medios de comunicación, accesos, soportes, etc. • La implementación de medidas de seguridad. • La formación al personal de la entidad sobre la política, normativa y procedimientos de seguridad. • La evaluación de la eficacia de las medidas adoptadas. • La definición e implementación de los procedimientos para la actualización de la gestión de la seguridad. • La realización de una auditoría de seguridad.

10.2.2. Implementación Partiendo del plan de mejora y de la declaración de aplicabilidad, se desarrollará la normativa de seguridad, es decir, aquellos procedimientos necesarios para implementar todos los requisitos que hacen falta para cumplir con los requisitos del ENS. Estos procedimientos detallarán las distintas tareas, los responsables de su ejecución y supervisión, así como los mecanismos para identificar y resolver los comportamientos anómalos. Puede ser necesario desarrollar también instrucciones de trabajo y documentos modelo que permitan registrar las operaciones descritas en los procedimientos, así como controlar la resolución de las incidencias.

154

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Otras tareas que se realizarán en esta fase son: • La elaboración y puesta en marcha de un plan de pruebas y monitorización del sistema, para controlar la seguridad del mismo. • La definición y ejecución de un plan de auditorías, en las que se revisarán la política de seguridad y su cumplimiento, así como el conjunto de riesgos, normativas, procedimientos y controles establecidos. • La definición y ejecución de un plan de formación y sensibilización. Se debería impartir formación a todo el personal de la entidad, de modo que cada uno conozca cuáles son sus responsabilidades y tareas para proteger la información y los servicios que gestione. Es una parte fundamental de la implementación, tanto por ser imprescindible para cumplir con el ENS como para garantizar el éxito de las medidas implementadas.

10.2.3. Verificación y validación El nivel de seguridad debe ser controlado para verificar si las medidas de seguridad están funcionando correctamente y los resultados son los esperados. Con el tiempo y los cambios en la organización, 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. Además del control rutinario, se deben realizar revisiones, como por ejemplo: • Autoevaluaciones. Llevadas a cabo por el responsable de seguridad, pertinentemente documentadas, y en las que se chequeen: – La validez y vigencia de la política, y la normativa de seguridad. – La vigencia de la categorización de los sistemas y el análisis de riesgos. – La validez y vigencia de los controles aplicados. – La eficacia de los controles. • Auditorías. Llevadas a cabo por un auditor cualificado e independiente, que compruebe que las medidas implementadas y la documentación de soporte cumple con los requisitos del ENS. Cuando los sistemas son de nivel bajo, una autoevaluación periódica es suficiente, pero si son de nivel medio o alto están sujetos, como mínimo, a una auditoría cada dos años.

10. Implementación del ENS

155

10.2.4. Actualización y mejora continua Para cumplir con los requisitos de actualización y mejora continua que plantea el ENS, se utilizará la información derivada de la gestión de incidencias y los resultados de las actividades de verificación y validación. A partir de aquí, se debe derivar a un plan de acción para subsanar los errores detectados, que justificarán el cumplimiento en este aspecto que requiere el ENS.

11

Ejemplo práctico: plan de adecuación

11.1. Documentación de la política de seguridad Aprobación y entrada en vigor. Fecha de la aprobación y entrada en vigor de la política. Introducción. Breve descripción de los objetivos de la organización en cuanto a la seguridad de la información y los medios que se están utilizarán para garantizarla. Prevención. Declaración de las medidas de seguridad existentes para prevenir daños a la información o los servicios. Detección. Declaración de las medidas de seguridad existentes para detectar incidentes que puedan producir daños a la información o los servicios. Respuesta. Declaración de las medidas de seguridad existentes para dar respuesta a los incidentes que puedan producir daños a la información o los servicios. Recuperación. Declaración de las medidas de seguridad existentes para recuperar la disponibilidad de los servicios y garantizar la continuidad de las actividades de la entidad. Alcance. Declaración del alcance de la aplicación del ENS, habitualmente en términos de los servicios que se prestan en la entidad. Misión. Declaración de la misión de la entidad en los aspectos de seguridad. Marco normativo. Declaración de la legislación aplicable a la entidad en el ámbito de la seguridad de la información. Organización de la seguridad. Descripción de los principales roles y responsabilidades exigidos por el ENS: responsable de servicio, responsable de la información y responsable de seguridad.

158

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Descripción de la composición de los comités de seguridad y de sus funciones. Procedimientos de designación. Descripción del mecanismo a utilizar para designar los responsables descritos anteriormente. Política de seguridad de la información. Descripción de la gestión de la política, vigencia, revisión y actualización, y difusión. Datos de carácter personal. En esta sección se deben identificar los datos de carácter personal que quedan dentro del ámbito del ENS o hacer referencia al documento de seguridad. Gestión de riesgos. Declaración de haber realizado un análisis de riesgos y de la periodicidad de su revisión y actualización. Desarrollo de la política de seguridad de la información. Descripción de los mecanismos por los que se desarrollará la política, como por ejemplo, la normativa de seguridad y cómo se va a difundir en la organización. Obligaciones del personal. Descripción de las principales obligaciones del personal, como por ejemplo, conocer y aplicar la política, y formarse según requerimientos. Terceras partes. Descripción de los mecanismos para gestionar la seguridad cuando se presten servicios o se gestione información de terceros, y a la inversa, cuando terceros presten servicios o gestionen información de la entidad.

11.2. Documentación de la categoría del sistema 11.2.1. Criterios de valoración de los activos En esta sección se describirán los criterios mediante los que se van a valorar los activos. Para el ejemplo se han seguido los criterios definidos en la guía CCN-STIC-803 Esquema Nacional de Seguridad, valoración de los sistemas.

11.2.2. Categorización de sistemas Para categorizar los sistemas según el ENS, se recomienda seguir los pasos descritos en la guía CCN-STIC-803 Valoración de los sistemas. Se identificarán los servicios que se prestan y la información que los soporta, decidiendo para cada uno de ellos, la relevancia para la entidad del impacto de

11. Ejemplo práctico: plan de adecuación

159

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 propuestos. Los que se asignen definitivamente quedarán documentados en la política de seguridad. Tabla 11.1. Categorización de sistemas Sistema / Subsistema

Tipo de Activo

Responsable

Activos

D

I

C

A

T

Categoría

B

B

B

B

B

B

Sede electrónica Portal web Información

Secretaría general

Información de la sede

B

B

B

B

B

Servicios

Responsable TIC

Portal de sede

B

B

B

B

B

B

M

M

M

M

Consultas y notificaciones Información

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

M

M

A

A

A

Registro electrónico Información

Secretaría general

Datos del registro

A

M

M

M

M

Servicios

Responsable TIC

Registro general

A

M

B

M

M

B

B

B

B

B

Tablón oficial Información

Secretaría general

Información del tablón

B

B

B

B

B

Servicios

Responsable TIC

Plataforma del tablón

B

B

B

B

B

M

A

B

160

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

11.3. Documentación del análisis de riesgos 11.3.1. Metodología de análisis En esta sección se indicará la metodología que se va a seguir para realizar el análisis de riesgos. En este ejemplo, se ha utilizado la herramienta PILAR basada en la metodología MAGERIT.

11.3.2. Valoración de activos En este punto se identificarán los activos utilizados para soportar los servicios y la información, 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. Tabla 11.2. Valoración de activos Activo

D

I

C

A

T

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 tablón oficial

B

B

B

B

B

Información de la sede

B

B

B

B

B

Expedientes administrativos

M

M

M

M

M

Datos del registro

A

M

M

M

M

Información del tablón

B

B

B

B

B

Servidor de datos

A

A

M

M

M

Servidor de aplicaciones

A

A

M

M

M

Puestos de usuario

M

M

M

M

M

Servicios

Información

[HW] Hardware

(continúa)

11. Ejemplo práctico: plan de adecuación

Tabla 11.2. Valoración de activos Activo

(continuación)

D

I

C

A

T

A

A

M

M

M

Aplicación de gestión

A

A

M

M

M

Gestión de BD Oracle

A

A

M

M

M

Ofimática

M

M

M

M

M

Sede central

M

M

M

M

M

CPD alternativo

M

M

M

M

M

Personal propio

M

M

M

M

M

Personal subcontratado

M

M

M

M

M

Red de comunicaciones

161

[SW] Software

[I] Instalaciones

[PE] Personal

11.3.3. Mapas de riesgos Con la valoración anterior se realizará un análisis de riesgos, evaluando en primer lugar el riesgo potencial, que es el que presenta un activo antes de aplicarle ninguna medida de seguridad y después el riesgo actual, que es el que presentan los activos considerando las medidas de seguridad (salvaguardas) implementadas en la organización. 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 aceptable. En este ejemplo, se considerará que el riesgo aceptable es 4. Se aplicarán medidas a los riesgos que superen este valor y se asumirán el resto.

162

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Tabla 11.3. Medidas de seguridad implementadas Medidas

Nivel de madurez

Marco organizativo

40%

Política de seguridad

50%

Normativa de seguridad

50%

Procedimientos de seguridad

50%

Proceso de autorización

10%

Marco operacional

43%

Planificación

40%

Control de acceso

56%

Explotación

58%

Servicios externos

63%

Continuidad del servicio

10%

Monitorización del sistema

30%

Medidas de protección

44%

Protección de las instalaciones e infraestructuras

70%

Gestión del personal

43%

Protección de los equipos

37%

Protección de las comunicaciones

37%

Protección de los soportes de información

18%

Protección de las aplicaciones informáticas (SW)

50%

Protección de la información

48%

Protección de los servicios

50%

11. Ejemplo práctico: plan de adecuación

163

Tabla 11.4. Mapa de riesgos Potencial

Actual

Activo [D]

[I]

[C]

[A]

[T]

Portal de la sede

1,9

1,5

1,9

1,5

1

Consultas

3,6

3,3

1,9

3,3

Notificaciones

3,6

5,1

3,6

6

3,3

1,9

[D]

[I]

[C]

[A]

[T]

0,94 0,94 1,4

0,9

0,8

2,8

2,5

2,5

1,4

2,5

2

3,3

2,8

2,5

4,2

3,1

2,5

2

1,9

3,3

2,8

4,8

2,5

1,4

2,5

2

1,5

1,9

1,5

1

0,9

0,9

1,4

0,9

0,8

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 electrónico

2,8

3,3

3,6

3,3

2,8

2,2

2,8

3,3

3,2

2,5

1

1,5

1,9

1,5

1

0,8

1,1

1,5

1,4

0,9

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

-

-

Aplicación de gestión

5,1

5,7

4,5

3,9

3,4

4,3

4,7

3,7

3,4

2,9

Gestión de DB Oracle

5,1

5,7

4,5

3,9

3,4

4,3

4,7

3,7

3,4

2,9

Ofimática

3,3

3,9

3,9

3,3

2,8

2,6

2,9

3,1

2,8

2,3

2,5

2,8

2,8

-

-

1,7

1,8

1,8

-

-

3

2,8

2,8

-

-

2,2

1,8

1,8

-

-

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

-

-

[SE] Servicios

Registro general Plataforma del tablón oficial [IN] Información Información de la sede electrónica

Información del tablón de anuncios [HW] Hardware

[SW] Software

[L] Instalaciones Sede central CPD alternativo [P] Personal

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

164

11.4. Documentación de la declaración de aplicabilidad Esta declaración consiste en detallar las medidas de seguridad de entre las mencionadas en el anexo II del ENS, con el estado en el que se encuentran, teniendo en cuenta las que aplican debido a la categoría de los sistemas y subsistemas, y aquellas 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 según la categoría del sistema, ni se considera necesario para mitigar los riesgos. • Aplica. Control seleccionado por requerimiento del ENS para la categoría del sistema o para mitigar algún riesgo detectado. En la tabla 11.5 se muestra un ejemplo. A pesar de que por el nivel de los sistemas no aplicaría, para reducir los riesgos no asumibles, se han seleccionado los siguientes controles que se han señalado como “aplica” en los sistemas de nivel medio: • “op.mon.2 Sistema de métricas”. • “mp.if.9 Instalaciones alternativas”. • “mp.per.9 Personal alternativo”. • “mp.com.9 Medios alternativos”. Tabla 11.5. Declaración de aplicabilidad Dimensiones afectadas

Tipo de medida

Medida de seguridad

Estado nivel medio

Estado nivel alto

org

Marco organizativo

categoría

org.1

Política de seguridad

Aplica

Aplica

categoría

org.2

Normativa de seguridad

Aplica

Aplica

categoría

org.3

Procedimientos de seguridad

Aplica

Aplica

categoría

org.4

Proceso de autorización

Aplica

Aplica

op

Marco operacional

op.pl

Planificación

op.pl.1

Análisis de riesgos

Aplica

Aplica

categoría

(continúa)

11. Ejemplo práctico: plan de adecuación

Tabla 11.5. Declaración de aplicabilidad Dimensiones afectadas

Tipo de medida

Medida de seguridad

165

(continuación) Estado nivel medio

Estado nivel alto

categoría

op.pl.2

Arquitectura de seguridad

Aplica

Aplica

categoría

op.pl.3

Adquisición de nuevos componentes

Aplica

Aplica

D

op.pl.4

Dimensionamiento/Gestión de capacidades

Aplica

Aplica

categoría

op.pl.5

Componentes certificados

n.a.

Aplica

op.acc

Control de acceso

AT

op.acc.1

Identificación

Aplica

Aplica

ICAT

op.acc.2

Requisitos de acceso

Aplica

Aplica

ICAT

op.acc.3

Segregación de funciones y tareas

Aplica

Aplica

ICAT

op.acc.4

Acceso de gestión de derecho des

Aplica

Aplica

ICAT

op.acc.5

Mecanismo de autenticación

Aplica

Aplica

ICAT

op.acc.6

Acceso local (local login)

Aplica

Aplica

ICAT

op.acc.7

Acceso remoto (remote login)

Aplica

Aplica

op.exp

Explotación

categoría

op.exp.1

Inventario de activos

Aplica

Aplica

categoría

op.exp.2

Configuración de seguridad

Aplica

Aplica

categoría

op.exp.3

Gestión de la configuración

Aplica

Aplica

categoría

op.exp.4

Mantenimiento

Aplica

Aplica

categoría

op.exp.5

Gestión de cambios

Aplica

Aplica

categoría

op.exp.6

Protección frente a código dañino

Aplica

Aplica

categoría

op.exp.7

Gestión de incidencias

Aplica

Aplica

T

op.exp.8

Registro de la actividad de los usuarios

n.a.

Aplica

categoría

op.exp.9

Registro de la gestión de incidencias

Aplica

Aplica

T

op.exp.10

Protección de los registros de actividad

n.a.

Aplica

categoría

op.exp.11

Protección de claves criptográficas

Aplica

Aplica

op.ext

Servicios externos

categoría

op.ext.1

Contratación y acuerdos de nivel de servicio

Aplica

Aplica

categoría

op.ext.2

Gestión diaria

Aplica

Aplica

D

op.ext.9

Medios alternativos

n.a.

Aplica (continúa)

166

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Tabla 11.5. Declaración de aplicabilidad Dimensiones afectadas

Tipo de medida

(continuación)

Medida de seguridad

Estado nivel medio

Estado nivel alto

op.cont

Continuidad del servicio

D

op.cont.1

Análisis de impacto

Aplica

Aplica

D

op.cont.2

Plan de continuidad

n.a.

Aplica

D

op.cont.3

Pruebas periódicas

n.a.

Aplica

op.mon

Monitorización del sistema

categoría

op.mon.1

Detección de intrusión

n.a.

Aplica

categoría

op.mon.2

Sistema de métricas

Aplica

Aplica

mp

Medidas de protección

mp.if

Protección de las instalaciones e infraestructuras

categoría

mp.if.1

Áreas separadas y con control de acceso

Aplica

Aplica

categoría

mp.if.2

Identificación de las personas

Aplica

Aplica

categoría

mp.if.3

Acondicionamiento de los locales

Aplica

Aplica

D

mp.if.4

Energía eléctrica

Aplica

Aplica

D

mp.if.5

Protección frente a incendios

Aplica

Aplica

D

mp.if.6

Protección frente a inundaciones

Aplica

Aplica

categoría

mp.if.7

Registro de entrada y salida de equipamiento

Aplica

Aplica

D

mp.if.9

Instalaciones alternativas

Aplica

Aplica

mp.per

Gestión del personal

categoría

mp.per.1

Caracterización del puesto de trabajo

Aplica

Aplica

categoría

mp.per.2

Deberes y obligaciones

Aplica

Aplica

categoría

mp.per.3

Concienciación

Aplica

Aplica

categoría

mp.per.4

Formación

Aplica

Aplica

D

mp.per.9

Personal alternativo

Aplica

Aplica

mp.eq

Protección de los equipos

categoría

mp.eq.1

Puesto de trabajo despejado

Aplica

Aplica

A

mp.eq.2

Bloqueo de puesto de trabajo

Aplica

Aplica

categoría

mp.eq.3

Protección de equipos portátiles

Aplica

Aplica

D

mp.eq.9

Medios alternativos

Aplica

Aplica (continúa)

11. Ejemplo práctico: plan de adecuación

Tabla 11.5. Declaración de aplicabilidad Dimensiones afectadas

Tipo de medida

167

(continuación)

Medida de seguridad

Estado nivel medio

Estado nivel alto

mp.com

Protección de las comunicaciones

categoría

mp.com.1

Perímetro seguro

Aplica

Aplica

C

mp.com.2

Protección de la confidencialidad

Aplica

Aplica

IA

mp.com.3

Protección de la autenticidad y de la integridad

Aplica

Aplica

categoría

mp.com.4

Segregación de redes

n.a.

Aplica

D

mp.com.9

Medios alternativos

n.a.

Aplica

mp.si

Protección de los soportes de información

C

mp.si.1

Etiquetado

Aplica

Aplica

IC

mp.si.2

Criptografía

Aplica

Aplica

categoría

mp.si.3

Custodia

Aplica

Aplica

categoría

mp.si.4

Transporte

Aplica

Aplica

C

mp.si.5

Borrado y destrucción

Aplica

Aplica

mp.sw

Protección de las aplicaciones informáticas

categoría

mp.sw.1

Desarrollo

Aplica

Aplica

categoría

mp.sw.2

Aceptación y puesta en servicio

Aplica

Aplica

mp.info

Protección de la información

categoría

mp.info.1

Datos de carácter personal

Aplica

Aplica

C

mp.info.2

Calificación de la información

Aplica

Aplica

C

mp.info.3

Cifrado

n.a.

Aplica

IA

mp.info.4

Firma electrónica

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

Protección de los servicios

categoría

mp.s.1

Protección del correo electrónico

Aplica

Aplica

categoría

mp.s.2

Protección de servicios y aplicaciones web

Aplica

Aplica

D

mp.s.8

Protección frente a la denegación de servicio

Aplica

Aplica

D

mp.s.9

Medios alternativos

n.a.

Aplica

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

168

11.5. Insuficiencias del sistema En esta sección se documentarán 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 documentación, por lo que se podría decir que las principales insuficiencias detectadas son: • Documentación. No hay una gestión documental formal de los aspectos de seguridad de la información a excepción de lo provisto para cumplir con la LOPD. • Formación. El personal ha recibido formación 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

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 formación 1.2 Planificar auditorías 2 Documentación del ENS 2.1 Elaboración de la normativa de seguridad 2.2 Elaboración de procedimientos de seguridad 2.3 Formalizar la gestión de los servicios externos (continúa)

11. Ejemplo práctico: plan de adecuación

Tabla 11.6. Plan de mejora

ID

Acciones

2.4 Documentar la gestión de la continuidad 2.5 Establecer métricas de desempeño 3 Implementación del ENS 3.1 Llevar a cabo acciones de concienciación y formativas 3.2 Implementar procedimientos de seguridad 4 Monitorización y supervisión 4.1 Realizar auditorías 4.2 Revisar objetivos 4.3 Revisar el análisis de riesgos 5 Proyecto 5: actualización y mantenimiento 4.4 Planificar mejoras

1.er semestre 2012

169

(continuación)

2.º semestre 2012

1.er semestre 2013

2.º semestre 2013

1.er semestre 2014

Bibliografía

Normas de referencia Norma UNE- ISO/IEC 27000 Tecnología de la información. Técnicas de seguridad. Sistemas de Gestión de la Seguridad de la Información (SGSI). Visión de conjunto y vocabulario. La aplicación de cualquier norma necesita de un vocabulario claramente definido, que evite distintas interpretaciones de conceptos técnicos y de gestión. Norma UNE-ISO/IEC 27001 Tecnología de la información. Técnicas de seguridad. Sistemas de Gestión de la Seguridad de la Información (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 permite obtener la certificación del mismo por parte de un organismo certificador independiente. La certificación del sistema de gestión contribuye a fomentar las actividades de protección de la información 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, estableciendo así formalmente el nexo de unión entre las dos normas. Norma UNE-ISO/IEC 27002 Tecnología de la información. Técnicas de seguridad. Código de buenas prácticas para la gestión de la seguridad de la información. Esta norma ofrece recomendaciones para realizar la gestión de la seguridad de la información que pueden utilizarse por los responsables de iniciar, implementar o mantener la seguridad en una organización. Persigue proporcionar una

172

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

base común para desarrollar normas de seguridad y constituir una práctica eficaz de la gestión. Esta norma no es certificable. Norma ISO/IEC 27003 Information technology – Information security management system implementation guidance. Es una guía de implementación de un SGSI basado en la Norma ISO/IEC 27001 e información acerca del uso del modelo PDCA y de los requerimientos de sus diferentes fases. Norma ISO/IEC 27004 Information technology – Information security management – Measurement. Especifica las métricas y las técnicas de medida aplicables para determinar la eficacia de un SGSI y de los controles relacionados. Estas métricas se usan fundamentalmente para la medición de los componentes de la fase Do (implementar y utilizar) del ciclo PDCA. Norma ISO/IEC 27005 Information technology – Information security risk management. Consiste en una guía de técnicas para la gestión del riesgo de la seguridad de la información y servirá, por tanto, de apoyo a la Norma UNE-ISO/IEC 27001 y a la implementación de un SGSI. Recoge partes de ISO/IEC TR 13335. Norma ISO/IEC 27006 Information technology – Requirements for bodies providing audit and certification of information security management systems. Especifica los requisitos para la acreditación de entidades de auditoría y certificación de sistemas de gestión de seguridad de la información. Norma ISO/IEC 27007 Information technology – Guidelines for information security management systems auditing. En fase de desarrollo. Consistirá en una guía para realizar una auditoría a un SGSI. Norma ISO/IEC 27011 Information technology – Information security management guidelines for telecommunications organizations based on ISO/IEC 27002. Es una guía de gestión de seguridad de la información específica para telecomunicaciones, elaborada a partir de una Recomendación de la UIT (Unión Internacional de Telecomunicaciones).

Bibliografía

173

Norma ISO/IEC FCD 27032 Information technology – Guidelines for cybersecurity En fase de desarrollo. Consistirá en una guía relativa a la ciberseguridad. Serie ISO/IEC 27033 Information technology – Network security Dividida en 7 partes: gestión de seguridad de redes, arquitectura de seguridad de redes, escenarios de redes de referencia, aseguramiento de las comunicaciones entre redes mediante gateways, acceso remoto, aseguramiento de comunicaciones en redes mediante VPNs y diseño e implementación de seguridad en redes. Provendrá de la revisión, ampliación y renumeración 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 guía de seguridad en aplicaciones. Informe UNE 71501-1 IN Tecnología de la Información (TI). Guía para la gestión de la seguridad de TI. Parte 1: Conceptos y modelos para la seguridad de TI. Este informe proporciona una visión general de los conceptos fundamentales y de los modelos utilizados para describir la gestión de seguridad de TI. Informe UNE 71501-2 IN Tecnología de la información (TI). Guía para la gestión de la seguridad de TI. Parte 2: Gestión y planificación de la seguridad de TI. Se describen varios aspectos de gestión y planificación de la seguridad de TI. Informe UNE 71501-3 IN Tecnología de la información (TI). Guía para la gestión de la seguridad de TI. Parte 3: Técnicas para la gestión de la seguridad de TI. Esta norma describe varias técnicas de seguridad indicadas para distintas fases de un proyecto, desde la planificación hasta la explotación, pasando por la implementación. Informe UNE 66172:2003 Directrices para la justificación y desarrollo de normas de sistemas de gestión. ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for IT security. UNE-ISO GUIA 73:2010 IN Gestión del riesgo. Vocabulario.

174

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

Legislación Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos. Su objeto es establecer la política de seguridad en la utilización de medios electrónicos, y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información. Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

Otros documentos CCN-STIC-201 Estructura de seguridad. Enero 2009. CCN-STIC-402 Organización y gestión TIC. Diciembre 2006. CCN-STIC-801 Responsabilidades en el Esquema Nacional de Seguridad. Febrero 2010. CCN-STIC-802 Auditoría del Esquema Nacional de Seguridad. Junio 2010. CCN-STIC-803 Valoración de sistemas en el Esquema Nacional de Seguridad. Enero 2011. CCN-STIC-804 Medidas de implantación del Esquema Nacional de Seguridad (borrador). Octubre 2011. CCN-STIC-805 Política de seguridad del Esquema Nacional de Seguridad. Septiembre 2011. CCN-STIC-806 Plan de adecuación del Esquema Nacional de Seguridad. Enero 2011. CCN-STIC-807 Criptología de empleo en el Esquema Nacional de Seguridad. Septiembre 2011.

Bibliografía

175

CCN-STIC-808 Verificación del cumplimiento de las medidas en el Esquema Nacional de Seguridad. Septiembre 2011. CCN-STIC-809 Declaración de conformidad del Esquema Nacional de Seguridad (borrador). Julio 2010. CCN-STIC-810 Creación de un CERT-CSIRT (borrador). Septiembre 2011. CCN-STIC-811 Interconexión 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 electrónico (borrador). Agosto 2011. CCN-STIC-815 Métricas e indicadores en el Esquema Nacional de Seguridad (borrador). Diciembre 2011. Norma Técnica de Interoperabilidad de Documento Electrónico. Resolución de 19 de julio de 2011 de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de Digitalización de Documentos. Resolución de 19 de julio de 2011 de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de Expediente Electrónico. Resolución de 19 de julio de 2011, de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de Política de Firma Electrónica y de certificados de la Administración. Resolución de 19 de julio de 201, de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de requisitos de conexión a la red de comunicaciones de las Administraciones Públicas españolas. Resolución de 19 de julio de 2011 de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de Procedimientos de copiado auténtico y conversión entre documentos electrónicos. Resolución de 19 de julio de 2011 de la Secretaría de Estado para la Función Pública. Norma Técnica de Interoperabilidad de Modelo de Datos para el Intercambio de asientos entre las entidades registrales. Resolución de 19 de julio de 2011, de la Secretaría de Estado para la Función Pública. CNSS Inst. 4009 National Information Assurance (IA) Glossary. April 2010. FIPS 200. Minimum Security Requirements for Federal Information and Information Systems. March 2006.

176

Guía de aplicación de la Norma UNE-ISO/IEC 27001 sobre seguridad en sistemas de información para pymes

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 interés Asociación Española de Normalización (AENOR). www.aenor.es European Network and Information Security Agency (ENISA). www.enisa.europa.eu Instituto Nacional de Tecnologías de la Comunicación (INTECO). www.inteco.es ISMS Forum Spain. Asociación Española para el Fomento de la Seguridad de la Información. www.ismsforum.es MAGERIT – versión 2. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. 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 diseño e implementación de sistemas de gestión de seguridad de la información. www.seguridadinformacion.com

Norma UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de seguridad. Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos





QRUPD HVSDxROD

81(,62,(& 

1RYLHPEUH   









7Ë78/2

 





7HFQRORJtDGHODLQIRUPDFLyQ  7pFQLFDVGHVHJXULGDG  6LVWHPDVGH*HVWLyQGHOD6HJXULGDGGHOD,QIRUPDFLyQ6*6,  5HTXLVLWRV  ,62,(&   

,QIRUPDWLRQ WHFKQRORJ\ 6HFXULW\ WHFKQLTXHV ,QIRUPDWLRQ VHFXULW\ PDQDJHPHQW V\VWHPV 5HTXLUHPHQWV ,62,(&   7HFKQRORJLHV GH O LQIRUPDWLRQ 7HFKQLTXHV GH VpFXULWp 6\VWqPHV GH JHVWLRQ GH VpFXULWp GH O LQIRUPDWLRQ ([LJHQFHV,62,(& 









  



&255(6321'(1&,$







 









  











  (VWDQRUPDHVLGpQWLFDDOD1RUPD,QWHUQDFLRQDO,62,(& 





  (VWDQRUPDDQXODUi\VXVWLWXLUiDOD1RUPD81(HO

2%6(59$&,21(6 



 











  





$17(&('(17(6 



 

  (VWD QRUPD KD VLGR HODERUDGD SRU HO FRPLWp WpFQLFR $(1&71  7HFQRORJtD GH OD ,QIRUPDFLyQFX\D6HFUHWDUtDGHVHPSHxD$(7,&













(GLWDGDHLPSUHVDSRU$(125 'HSyVLWROHJDO0



/$62%6(59$&,21(6$(67('2&80(172+$1'(',5,*,56($



©$(125 5HSURGXFFLyQSURKLELGD



&*pQRYD 0$'5,'(VSDxD







7HOpIRQR )D[





3iJLQDV  

*UXSR

6





,62,(&

Ë1',&( 3iJLQD 35Ï/2*2     ,1752'8&&,Ï1   *HQHUDOLGDGHV    (QIRTXHSRUSURFHVR    &RPSDWLELOLGDGFRQRWURVVLVWHPDVGHJHVWLyQ     2%-(72YpDVHF @\ 

  VHDDSUREDGDSRUOD'LUHFFLyQ 127$ $HIHFWRVGHHVWDQRUPDLQWHUQDFLRQDOODSROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQVHFRQVLGHUDXQVXEFRQMXQWRGHODSROtWLFDGHO6*6, (VWDVSROtWLFDVSXHGHQHVWDUGHVFULWDVHQXQ~QLFRGRFXPHQWR

 F  'HILQLUHOHQIRTXHGHODHYDOXDFLyQGHULHVJRVGHODRUJDQL]DFLyQ

  (VSHFLILFDUXQDPHWRGRORJtDGHHYDOXDFLyQGHULHVJRVDGHFXDGDSDUDHO6*6,ODVQHFHVLGDGHVGHQHJRFLRLGHQWL ILFDGDVHQPDWHULDGHVHJXULGDGGHODLQIRUPDFLyQGHODHPSUHVD\ORVUHTXLVLWRVOHJDOHV\UHJODPHQWDULRV   'HVDUUROODUFULWHULRVGHDFHSWDFLyQGHULHVJR\ILMDUORVQLYHOHVGHULHVJRDFHSWDEOHV>YpDVHI @  /DPHWRGRORJtDVHOHFFLRQDGDSDUDODHYDOXDFLyQGHULHVJRVGHEHDVHJXUDUTXHODVHYDOXDFLRQHVGHULHVJRVJHQHUHQ UHVXOWDGRVFRPSDUDEOHV\UHSURGXFLEOHV 

127$ +D\GLIHUHQWHVPHWRGRORJtDVSDUDODHYDOXDFLyQGHULHVJRV(QOD1RUPD ,62,(&757HFQRORJtDGHODLQIRUPDFLyQ'LUHF WULFHVSDUDODJHVWLyQGHODVHJXULGDGGH7,7pFQLFDVGHJHVWLyQGHODVHJXULGDGGH7,VHFRPHQWDQDOJXQRVHMHPSORVGHPHWRGRORJtDV SDUDODHYDOXDFLyQGHULHVJRV

 G  ,GHQWLILFDUORVULHVJRV

  ,GHQWLILFDUORVDFWLYRVTXHHVWiQGHQWURGHOiPELWRGHDSOLFDFLyQGHO6*6,\DORVSURSLHWDULRV GHHVWRVDFWLYRV   ,GHQWLILFDUODVDPHQD]DVDTXHHVWiQH[SXHVWRVHVRVDFWLYRV   ,GHQWLILFDUODVYXOQHUDELOLGDGHVEDMRODVTXHSRGUtDQDFWXDUGLFKDVDPHQD]DV   ,GHQWLILFDUORVLPSDFWRVTXHVREUHORVDFWLYRVSXHGHWHQHUXQDSpUGLGDGHFRQILGHQFLDOLGDGLQWHJULGDG\GLVSRQL ELOLGDGHQORVPLVPRV

 H  $QDOL]DU\YDORUDUORVULHVJRV

  (YDOXDUORVHIHFWRVHQODDFWLYLGDGHPSUHVDULDOGHODRUJDQL]DFLyQTXHSXGLHUDQGHULYDUVHGHHYHQWXDOHVIDOORVGH VHJXULGDGWHQLHQGRHQFXHQWDODVFRQVHFXHQFLDVGHXQDSpUGLGDGHFRQILGHQFLDOLGDGLQWHJULGDGRGLVSRQLELOLGDG GHORVDFWLYRV   (YDOXDUODSUREDELOLGDGGHXQDIRUPDUHDOLVWDGHTXHVHSURGX]FDQIDOORVGHVHJXULGDGDODOX]GHODVDPHQD]DV\ YXOQHUDELOLGDGHVH[LVWHQWHVORVLPSDFWRVDVRFLDGRVDORVDFWLYRV\ORVFRQWUROHVLPSOHPHQWDGRV   (VWLPDUORVQLYHOHVGHULHVJR   'HWHUPLQDUVLORVULHVJRVVRQDFHSWDEOHVRVLUHTXLHUHQXQWUDWDPLHQWRFRQIRUPHDORVFULWHULRVGHDFHSWDFLyQGH ULHVJRVHVWDEOHFLGRVHQF  

 I  ,GHQWLILFDU\HYDOXDUODVRSFLRQHVSDUDHOWUDWDPLHQWRGHULHVJRV  /DVSRVLEOHVDFFLRQHVDUHDOL]DUHQWUHRWUDVVRQODVVLJXLHQWHV   DSOLFDUFRQWUROHVDGHFXDGRV

  DVXPLUORVULHVJRVGHPDQHUDFRQVFLHQWH\REMHWLYDFRQIRUPHDODVSROtWLFDVGHODRUJDQL]DFLyQ\DORVFULWHULRV GHDFHSWDFLyQGHULHVJRV>YpDVHF  @   HYLWDUORVULHVJRV\   WUDQVIHULUORVULHVJRVDVRFLDGRVDODDFWLYLGDGHPSUHVDULDODRWUDVSDUWHVFRPRSRUHMHPSORFRPSDxtDVGHVHJXURV RSURYHHGRUHV  

  (OWpUPLQR³SURSLHWDULR´VHUHILHUHDXQLQGLYLGXRRXQDHQWLGDGDOTXHVHOHKDDVLJQDGRODUHVSRQVDELOLGDGDGPLQLVWUDWLYDSDUDHOFRQWUROGHOD SURGXFFLyQ HO GHVDUUROOR HO PDQWHQLPLHQWR HO XVR \ OD VHJXULGDG GH ORV DFWLYRV (O WpUPLQR ³SURSLHWDULR´ QR VLJQLILFD TXH OD SHUVRQD WHQJD UHDOPHQWHDOJ~QGHUHFKRGHSURSLHGDGVREUHHODFWLYR





,62,(&

J  6HOHFFLRQDUORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVSDUDHOWUDWDPLHQWRGHORVULHVJRV  /RV REMHWLYRV GH FRQWURO \ ORV FRQWUROHV GHEHQ VHOHFFLRQDUVH H LPSOHPHQWDUVH SDUD FXPSOLU ORV UHTXLVLWRV LGHQWL ILFDGRVHQODHYDOXDFLyQGHULHVJRV\HQHOSURFHVRGHWUDWDPLHQWRGHULHVJRV(VWDVHOHFFLyQGHEHWHQHUHQFXHQWDORV FULWHULRVGHDFHSWDFLyQGHULHVJRV>YpDVHF  @DGHPiVGHORVUHTXLVLWRVOHJDOHVUHJODPHQWDULRV\FRQWUDFWXDOHV  /RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVGHODQH[R$GHEHQVHOHFFLRQDUVHFRPRSDUWHGHHVWHSURFHVRHQODPHGLGDHQ TXHVLUYDQSDUDVDWLVIDFHUORVUHTXLVLWRVLGHQWLILFDGRV  /RVREMHWLYRVGHFRQWURO\ORVFRQWUROHVHQXPHUDGRVHQHODQH[R$QRVRQH[KDXVWLYRVSRUORTXHSXHGHQVHOHFFLR QDUVHRWURVREMHWLYRVGHFRQWURO\RWURVFRQWUROHVDGLFLRQDOHV  127$ (ODQH[R$FRQWLHQHXQDOLVWDFRPSOHWDGHREMHWLYRVGHFRQWURO\FRQWUROHVTXHVHKDQFRQVLGHUDGRFRP~QPHQWHUHOHYDQWHVHQODVRUJDQL ]DFLRQHV(ODQH[R$SURSRUFLRQDDORVXVXDULRVGHHVWDQRUPDLQWHUQDFLRQDOXQSXQWRGHSDUWLGDSDUDVHOHFFLRQDUORVFRQWUROHVJDUDQ WL]DQGRTXHQRVHSDVDQSRUDOWRLPSRUWDQWHVRSFLRQHVGHFRQWURO

 K  2EWHQHUODDSUREDFLyQSRUSDUWHGHOD'LUHFFLyQGHORVULHVJRVUHVLGXDOHVSURSXHVWRV  L  2EWHQHUODDXWRUL]DFLyQGHOD'LUHFFLyQSDUDLPSOHPHQWDU\RSHUDUHO6*6,  M  (ODERUDUXQDGHFODUDFLyQGHDSOLFDELOLGDG  8QDGHFODUDFLyQGHDSOLFDELOLGDGGHEHLQFOXLUORVLJXLHQWH

  ORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVVHOHFFLRQDGRVHQJ \ODVMXVWLILFDFLRQHVGHVXVHOHFFLyQ   ORVREMHWLYRVGHFRQWURO\ORVFRQWUROHVDFWXDOPHQWHLPSOHPHQWDGRV>YpDVHH  @\ 

  ODH[FOXVLyQGHFXDOTXLHUREMHWLYRGHFRQWURO\FRQWUROGHODQH[R$\ODMXVWLILFDFLyQGHHVWDH[FOXVLyQ 127$ /DGHFODUDFLyQGHDSOLFDELOLGDGSURSRUFLRQDXQUHVXPHQGHODVGHFLVLRQHVUHODWLYDVDOWUDWDPLHQWRGHORVULHVJRV/DMXVWLILFDFLyQGHODV H[FOXVLRQHVIDFLOLWDXQDFRPSUREDFLyQFUX]DGDGHTXHQRVHKDRPLWLGRLQDGYHUWLGDPHQWHQLQJ~QFRQWURO

  ,PSOHPHQWDFLyQ\RSHUDFLyQGHO6*6,

/DRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ D  )RUPXODUXQSODQGHWUDWDPLHQWRGHULHVJRVTXHLGHQWLILTXHODVDFFLRQHVGHOD'LUHFFLyQORVUHFXUVRVODVUHVSRQVD ELOLGDGHV\ODVSULRULGDGHVDGHFXDGRVSDUDJHVWLRQDUORVULHVJRVGHODVHJXULGDGGHODLQIRUPDFLyQYpDVH  E  ,PSOHPHQWDUHOSODQGHWUDWDPLHQWRGHULHVJRVSDUDORJUDUORVREMHWLYRVGHFRQWUROLGHQWLILFDGRVTXHWHQJDHQFXHQWD ODILQDQFLDFLyQ\ODDVLJQDFLyQGHIXQFLRQHV\UHVSRQVDELOLGDGHV F  ,PSOHPHQWDUORVFRQWUROHVVHOHFFLRQDGRVHQJ SDUDFXPSOLUORVREMHWLYRVGHFRQWURO G  'HILQLUHOPRGRGHPHGLUODHILFDFLDGHORVFRQWUROHVRGHORVJUXSRVGHFRQWUROHVVHOHFFLRQDGRV\HVSHFLILFDUFyPR WLHQHQ TXH XVDUVH HVWDV PHGLFLRQHV SDUD HYDOXDU OD HILFDFLD GH ORV FRQWUROHV GH FDUD D SURGXFLU XQRV UHVXOWDGRV FRPSDUDEOHV\UHSURGXFLEOHV>YpDVHF @ 127$ /DPHGLFLyQGHODHILFDFLDGHORVFRQWUROHVSHUPLWHDORVGLUHFWLYRV\DOSHUVRQDOGHWHUPLQDUKDVWDTXpSXQWRORVFRQWUROHVFXPSOHQORV REMHWLYRVGHFRQWUROSODQLILFDGRV

H  ,PSOHPHQWDUSURJUDPDVGHIRUPDFLyQ\GHFRQFLHQFLDFLyQYpDVH  I  *HVWLRQDUODRSHUDFLyQGHO6*6, J  *HVWLRQDUORVUHFXUVRVGHO6*6,YpDVH  K  ,PSOHPHQWDUSURFHGLPLHQWRV\RWURVFRQWUROHVTXHSHUPLWDQXQDGHWHFFLyQWHPSUDQDGHHYHQWRVGHVHJXULGDG\XQD UHVSXHVWDDQWHFXDOTXLHULQFLGHQWHGHVHJXULGDG>YpDVHD @

,62,(&



 6XSHUYLVLyQ\UHYLVLyQGHO6*6, /DRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ  D  (MHFXWDUSURFHGLPLHQWRVGHVXSHUYLVLyQ\UHYLVLyQDVtFRPRRWURVPHFDQLVPRVGHFRQWUROSDUD   GHWHFWDUORDQWHVSRVLEOHORVHUURUHVHQORVUHVXOWDGRVGHOSURFHVDGR   LGHQWLILFDUORDQWHVSRVLEOHODVGHELOLGDGHVGHOVLVWHPDGHVHJXULGDGDVtFRPRHODSURYHFKDPLHQWRGHpVWDVWDQWR FRQRVLQp[LWR\ORVLQFLGHQWHV   SHUPLWLUDOD'LUHFFLyQGHWHUPLQDUVLODVDFWLYLGDGHVGHVHJXULGDGGHOHJDGDVHQRWUDVSHUVRQDVROOHYDGDVDFDER SRUPHGLRVLQIRUPiWLFRVRDWUDYpVGHWHFQRORJtDVGHODLQIRUPDFLyQGDQORVUHVXOWDGRVHVSHUDGRV   D\XGDU D GHWHFWDU HYHQWRV GH VHJXULGDG \ SRU WDQWR D SUHYHQLU LQFLGHQWHV GH VHJXULGDG PHGLDQWH HO XVR GH LQGLFDGRUHV\   GHWHUPLQDUVLODVDFFLRQHVWRPDGDVSDUDUHVROYHUXQDYLRODFLyQGHODVHJXULGDGKDQVLGRHILFDFHV  E  5HDOL]DU UHYLVLRQHV SHULyGLFDV GH OD HILFDFLD GHO 6*6, WHQLHQGR HQ FXHQWD ORV UHVXOWDGRV GH ODV DXGLWRUtDV GH VHJXULGDGORVLQFLGHQWHVORVUHVXOWDGRVGHODVPHGLFLRQHVGHODHILFDFLDODVVXJHUHQFLDVDVtFRPRORVFRPHQWDULRV GHWRGDVODVSDUWHVLQWHUHVDGDV(VWDVUHYLVLRQHVLQFOX\HQHOFXPSOLPLHQWRGHODSROtWLFD\GHORVREMHWLYRVGHO6*6, \ODUHYLVLyQGHORVFRQWUROHVGHVHJXULGDG  F  0HGLUODHILFDFLDGHORVFRQWUROHVSDUDYHULILFDUVLVHKDQFXPSOLGRORVUHTXLVLWRVGHVHJXULGDG  G  5HYLVDUODVHYDOXDFLRQHVGHULHVJRVHQLQWHUYDORVSODQLILFDGRV\UHYLVDUORVULHVJRVUHVLGXDOHV\ORVQLYHOHVGHULHVJR DFHSWDEOHVTXHKDQVLGRLGHQWLILFDGRVWHQLHQGRHQFXHQWDORVFDPELRVHQ   ODRUJDQL]DFLyQ   ODWHFQRORJtD   ORVREMHWLYRV\UHTXLVLWRVHPSUHVDULDOHV   ODVDPHQD]DVLGHQWLILFDGDV   ODHILFDFLDGHORVFRQWUROHVLPSOHPHQWDGRV\   ORV IDFWRUHV H[WHUQRV FRPR SRU HMHPSOR ORV FDPELRV GHO HQWRUQR OHJDO R UHJODPHQWDULR GH ODV REOLJDFLRQHV FRQWUDFWXDOHV\GHOFOLPDVRFLDO

 H  5HDOL]DUODVDXGLWRUtDVLQWHUQDVGHO6*6,HQLQWHUYDORVSODQLILFDGRVYpDVH  

127$ /DVDXGLWRUtDVLQWHUQDVDYHFHVGHQRPLQDGDVDXGLWRUtDVSRUSULPHUDSDUWHODVOOHYDDFDERODSURSLDRUJDQL]DFLyQRELHQVHUHDOL]DQSRU HQFDUJRGHpVWDFRQILQHVLQWHUQRV

 I  5HDOL]DU SRU SDUWH GH OD 'LUHFFLyQ XQD UHYLVLyQ GHO 6*6, FRQ FDUiFWHU UHJXODU SDUD DVHJXUDU TXH HO iPELWR GH DSOLFDFLyQVLJXHVLHQGRDGHFXDGR\TXHVHLGHQWLILFDQPHMRUDVGHOSURFHVRGHO6*6,YpDVH   J  $FWXDOL]DUORVSODQHVGHVHJXULGDGWHQLHQGRHQFXHQWDODVFRQFOXVLRQHVGHODVDFWLYLGDGHVGHVXSHUYLVLyQ\UHYLVLyQ  K  5HJLVWUDUODVDFFLRQHVHLQFLGHQFLDVTXHSXGLHUDQDIHFWDUDODHILFDFLDRDOIXQFLRQDPLHQWRGHO6*6,YpDVH    0DQWHQLPLHQWR\PHMRUDGHO6*6, 5HJXODUPHQWHODRUJDQL]DFLyQGHEHKDFHUORTXHVHLQGLFDDFRQWLQXDFLyQ  D  ,PSOHPHQWDUHQHO6*6,ODVPHMRUDVLGHQWLILFDGDV  E  $SOLFDUODVPHGLGDVFRUUHFWLYDV\SUHYHQWLYDVDGHFXDGDVGHDFXHUGRFRQORVDSDUWDGRV\VREUHODEDVHGHOD H[SHULHQFLDHQPDWHULDGHVHJXULGDGGHODSURSLDRUJDQL]DFLyQ\GHRWUDVRUJDQL]DFLRQHV





,62,(&

F  &RPXQLFDUODVDFFLRQHV\PHMRUDVDWRGDVODVSDUWHVLQWHUHVDGDVFRQXQQLYHOGHGHWDOOHDFRUGHFRQODVFLUFXQVWDQFLDV  G  $VHJXUDUTXHODVPHMRUDVDOFDQFHQORVREMHWLYRVSUHYLVWRV  5HTXLVLWRVGHODGRFXPHQWDFLyQ   *HQHUDOLGDGHV /DGRFXPHQWDFLyQGHEHLQFOXLUODVGHFLVLRQHVGHOD'LUHFFLyQMXQWRFRQORVUHJLVWURVUHFRUGV GHODVPLVPDVGHELHQGR TXHGDU FRQVWDQFLD GH TXH ODV DFFLRQHV GDQ UHVSXHVWD D ODV GHFLVLRQHV \ D ODV SROtWLFDV DGRSWDGDV \ JDUDQWL]DQGR TXH GLFKRVGRFXPHQWRV\ORVFRUUHVSRQGLHQWHVUHJLVWURVHVWiQGLVSRQLEOHV  127$1$&,21$/ 6HJ~Q UHFRJH OD 1RUPD 81(,62  HO LQJOpV SRVHH WUHV WpUPLQRV GLVWLQWRV GRFXPHQWV UHFRUGV \ DUFKLYHV  SDUD GHVLJQDUORTXHHQFDVWHOODQRFRPRHQHOUHVWRGHOHQJXDVODWLQDVFXHQWDFRQXQD~QLFDYR]GRFXPHQWRV $VtGRFXPHQWHV HO HTXLYDOHQWH GH GRFXPHQWR HQ VX VLJQLILFDGR JHQpULFR FRPR PHUD LQIRUPDFLyQ UHJLVWUDGD 3RU HO FRQWUDULR ORV WpUPLQRV UHFRUGV\DUFKLYHVGHVLJQDQGHPDQHUDHVSHFtILFDDDTXHOORVGRFXPHQWRVSURGXFLGRVFRPRSUXHED\UHIOHMRGHODVDFWLYLGDGHV GHODRUJDQL]DFLyQTXHORVKDFUHDGRUHVHUYiQGRVHHOHPSOHRGHHVWH~OWLPRDORVGRFXPHQWRVGHFDUiFWHUKLVWyULFR  127$1$&,21$/ 8QUHJLVWURGLVSRQLEOHHVDTXpOTXHSXHGHVHUORFDOL]DGRUHFXSHUDGRSUHVHQWDGRHLQWHUSUHWDGR

 (V LPSRUWDQWH SRGHU GHPRVWUDU OD UHODFLyQ GH ORV FRQWUROHV VHOHFFLRQDGRV FRQ ORV UHVXOWDGRV GH ORV SURFHVRV GH HYDOXDFLyQ\GHWUDWDPLHQWRGHULHVJRV\SRUWDQWRFRQODSROtWLFD\REMHWLYRVGHO6*6,  /DGRFXPHQWDFLyQGHO6*6,GHEHLQFOXLU D  GHFODUDFLRQHVGRFXPHQWDGDVGHODSROtWLFD>YpDVHE @\GHORVREMHWLYRVGHO6*6, E  HODOFDQFHGHO6*6,>YpDVHD @ F  ORVSURFHGLPLHQWRV\PHFDQLVPRVGHFRQWUROTXHVRSRUWDQDO6*6, G  XQDGHVFULSFLyQGHODPHWRGRORJtDGHHYDOXDFLyQGHULHVJRV>YpDVHF @ H  HOLQIRUPHGHHYDOXDFLyQGHULHVJRV>YpDVHF DJ @ I  HOSODQGHWUDWDPLHQWRGHULHVJRV>YpDVHE @ J  ORVSURFHGLPLHQWRVGRFXPHQWDGRVTXHQHFHVLWDODRUJDQL]DFLyQSDUDDVHJXUDUXQDFRUUHFWDSODQLILFDFLyQRSHUDFLyQ\ FRQWURO GH VXV SURFHVRV GH VHJXULGDG GH OD LQIRUPDFLyQ \ SDUD GHVFULELU FyPR PHGLU OD HILFDFLD GH ORV FRQWUROHV >YpDVHF @ K  ORVUHJLVWURVUHTXHULGRVSRUHVWDQRUPDLQWHUQDFLRQDOYpDVH \ L  ODGHFODUDFLyQGHDSOLFDELOLGDG 

127$ &XDQGR HQ HVWD QRUPD LQWHUQDFLRQDO DSDUHFH HO WpUPLQR ³SURFHGLPLHQWR GRFXPHQWDGR´ VLJQLILFD TXH HO SURFHGLPLHQWR VH FUHD VH GRFXPHQWDVHLPSOHPHQWD\VHPDQWLHQH  127$ /DH[WHQVLyQGHODGRFXPHQWDFLyQGHO6*6,SXHGHGLIHULUGHXQDRUJDQL]DFLyQDRWUDGHELGRD − HOWDPDxR\WLSRGHDFWLYLGDGHVGHODRUJDQL]DFLyQ\ − HODOFDQFH\ODFRPSOHMLGDGGHORVUHTXLVLWRVGHVHJXULGDG\GHOVLVWHPDTXHVHHVWiJHVWLRQDQGR  127$ /RVGRFXPHQWRV\UHJLVWURVSXHGHQHVWDUHQFXDOTXLHUIRUPDWRRWLSRGHPHGLR

  &RQWUROGHGRFXPHQWRV

/RV GRFXPHQWRV H[LJLGRV SRU HO 6*6, YpDVH   GHEHQ HVWDU SURWHJLGRV \ FRQWURODGRV 6H GHEH HVWDEOHFHU XQ SURFHGLPLHQWRGRFXPHQWDGRSDUDGHILQLUODVDFFLRQHVGHJHVWLyQQHFHVDULDVSDUD  D  DSUREDUHQIRUPDORVGRFXPHQWRVSUHYLDPHQWHDVXGLVWULEXFLyQ

,62,(&

E   F   G   H   I 



UHYLVDUDFWXDOL]DU\YROYHUDDSUREDUORVGRFXPHQWRVVHJ~QYD\DVLHQGRQHFHVDULR DVHJXUDUTXHHVWiQLGHQWLILFDGRVORVFDPELRVDVtFRPRHOHVWDGRGHOGRFXPHQWRTXHFRQWLHQHOD~OWLPDUHYLVLyQ DVHJXUDUTXHODVYHUVLRQHVFRUUHVSRQGLHQWHVGHORVGRFXPHQWRVHVWiQGLVSRQLEOHV DVHJXUDUTXHORVGRFXPHQWRVSHUPDQHFHQOHJLEOHV\IiFLOPHQWHLGHQWLILFDEOHV DVHJXUDU TXH ORV GRFXPHQWRV HVWiQ GLVSRQLEOHV SDUD WRGR DTXHO TXH ORV QHFHVLWD \ VH WUDQVILHUHQ DOPDFHQDQ \ VH GHVWUX\HQGHDFXHUGRFRQORVSURFHGLPLHQWRVDSOLFDEOHVDVXFODVLILFDFLyQ

 J  DVHJXUDUTXHORVGRFXPHQWRVSURFHGHQWHVGHOH[WHULRUHVWiQLGHQWLILFDGRV  K  DVHJXUDUTXHODGLVWULEXFLyQGHORVGRFXPHQWRVHVWiFRQWURODGD  L  SUHYHQLUHOXVRQRLQWHQFLRQDGRGHGRFXPHQWRVREVROHWRV\  M  DSOLFDUXQDLGHQWLILFDFLyQDGHFXDGDDORVGRFXPHQWRVREVROHWRVTXHVRQUHWHQLGRVFRQDOJ~QSURSyVLWR   &RQWUROGHUHJLVWURV

6HGHEHQFUHDU\PDQWHQHUUHJLVWURVSDUDSURSRUFLRQDUHYLGHQFLDVGHODFRQIRUPLGDGFRQORVUHTXLVLWRV\GHOIXQFLRQD PLHQWRHILFD]GHO6*6,'LFKRVUHJLVWURVGHEHQHVWDSURWHJLGRV\FRQWURODGRV(O6*6,GHEHWHQHUHQFXHQWDFXDOTXLHU UHTXLVLWROHJDORUHJXODWRULRDSOLFDEOHDVtFRPRODVREOLJDFLRQHVFRQWUDFWXDOHV/RVUHJLVWURVGHEHQSHUPDQHFHUOHJLEOHV IiFLOPHQWH LGHQWLILFDEOHV \ UHFXSHUDEOHV /RV FRQWUROHV QHFHVDULRV SDUD OD LGHQWLILFDFLyQ DOPDFHQDPLHQWR SURWHFFLyQ UHFXSHUDFLyQUHWHQFLyQ\GLVSRVLFLyQGHORVUHJLVWURVGHEHQHVWDUGRFXPHQWDGRVHLPSOHPHQWDGRV  'HEHQFRQVHUYDUVHORVUHJLVWURVGHOGHVDUUROORGHOSURFHVRVHJ~QVHLQGLFDHQ\GHWRGRVORVVXFHVRVGHULYDGRVGH LQFLGHQWHVGHVHJXULGDGVLJQLILFDWLYRVUHODWLYRVDO6*6,  (-(03/2 (MHPSORVGHUHJLVWURVVRQHOOLEURGHYLVLWDVORVLQIRUPHVGHDXGLWRUtD\ORVIRUPXODULRVGHDXWRUL]DFLyQGHDFFHVRFXP SOLPHQWDGRV    5(63216$%,/,'$''(/$',5(&&,Ï1   &RPSURPLVRGHOD'LUHFFLyQ /D 'LUHFFLyQ GHEH VXPLQLVWUDU HYLGHQFLDV GH VX FRPSURPLVR SDUD FUHDU LPSOHPHQWDU RSHUDU VXSHUYLVDU UHYLVDU PDQWHQHU\PHMRUDUHO6*6,DWUDYpVGHODVVLJXLHQWHVDFFLRQHV D  IRUPXODQGRODSROtWLFDGHO6*6, E  YHODQGRSRUHOHVWDEOHFLPLHQWRGHORVREMHWLYRV\SODQHVGHO6*6, F  HVWDEOHFLHQGRORVUROHV\UHVSRQVDELOLGDGHVHQPDWHULDGHVHJXULGDGGHODLQIRUPDFLyQ G  FRPXQLFDQGRDODRUJDQL]DFLyQODLPSRUWDQFLDGHFXPSOLUORVREMHWLYRV\ODSROtWLFDGHVHJXULGDGGHODLQIRUPDFLyQ VXVUHVSRQVDELOLGDGHVOHJDOHV\ODQHFHVLGDGGHODPHMRUDFRQWLQXD H  SURSRUFLRQDQGR UHFXUVRV VXILFLHQWHV SDUD FUHDU LPSOHPHQWDU RSHUDU VXSHUYLVDU UHYLVDU PDQWHQHU \ PHMRUDU HO 6*6,YpDVH  I  GHFLGLHQGRORVFULWHULRVGHDFHSWDFLyQGHULHVJRV\ORVQLYHOHVDFHSWDEOHVGHULHVJR J  YHODQGRSRUTXHVHUHDOLFHQODVDXGLWRUtDVLQWHUQDVGHO6*6,YpDVH \ K  GLULJLHQGRODVUHYLVLRQHVGHO6*6,YpDVH 





,62,(&

 *HVWLyQGHORVUHFXUVRV   3URYLVLyQGHORVUHFXUVRV /DRUJDQL]DFLyQGHEHGHWHUPLQDU\SURSRUFLRQDUORVUHFXUVRVQHFHVDULRVSDUD D  HVWDEOHFHULPSOHPHQWDURSHUDUVXSHUYLVDUUHYLVDUPDQWHQHU\PHMRUDUHO6*6, E  DVHJXUDUTXHORVSURFHGLPLHQWRVGHVHJXULGDGGHODLQIRUPDFLyQUHVSRQGHQDORVUHTXLVLWRVHPSUHVDULDOHV F  LGHQWLILFDU\FXPSOLUORVUHTXLVLWRVOHJDOHV\UHJODPHQWDULRVDVtFRPRODVREOLJDFLRQHVGHVHJXULGDGFRQWUDFWXDOHV G  PDQWHQHUODVHJXULGDGDGHFXDGDPHGLDQWHODDSOLFDFLyQFRUUHFWDGHWRGRVORVFRQWUROHVLPSODQWDGRV H  OOHYDUDFDERUHYLVLRQHVFXDQGRVHDQQHFHVDULDV\UHDFFLRQDUHQEDVHDORVUHVXOWDGRVGHHVWDVUHYLVLRQHV\ I  FXDQGRVHUHTXLHUDPHMRUDUODHILFDFLDGHO6*6,   &RQFLHQFLDFLyQIRUPDFLyQ\FDSDFLWDFLyQ /DRUJDQL]DFLyQGHEHDVHJXUDUVHGHTXHWRGRHOSHUVRQDODOTXHVHOHKD\DQDVLJQDGRUHVSRQVDELOLGDGHVGHILQLGDVHQHO 6*6,VHDFRPSHWHQWHSDUDOOHYDUDFDERODVWDUHDVUHTXHULGDVDWUDYpVGH D  GHWHUPLQDUODVFRPSHWHQFLDVQHFHVDULDVSDUDHOSHUVRQDOTXHOOHYDDFDERWUDEDMRVTXHDIHFWHQDO6*6, E  LPSDUWLU IRUPDFLyQ R UHDOL]DURWUDV DFFLRQHV SRU HMHPSOR OD FRQWUDWDFLyQ GH SHUVRQDO FRPSHWHQWH  SDUD VDWLVIDFHU HVWDVQHFHVLGDGHV F  HYDOXDUODHILFDFLDGHODVDFFLRQHVUHDOL]DGDV\ G  PDQWHQHUUHJLVWURVGHHGXFDFLyQIRUPDFLyQDSWLWXGHVH[SHULHQFLD\FXDOLILFDFLRQHVYpDVH   /DRUJDQL]DFLyQGHEHDVHJXUDUVHWDPELpQGHTXHWRGRHOSHUVRQDODIHFWDGRVHDFRQVFLHQWHGHODWUDVFHQGHQFLD\GHOD LPSRUWDQFLDGHODVDFWLYLGDGHVGHVHJXULGDGGHODLQIRUPDFLyQ\GHVXFRQWULEXFLyQDORVREMHWLYRVGHO6*6,    $8',725Ë$6,17(51$6'(/6*6, /DRUJDQL]DFLyQGHEHUHDOL]DUDXGLWRUtDVLQWHUQDVGHO6*6,DLQWHUYDORVSODQLILFDGRVSDUDGHWHUPLQDUVLORVREMHWLYRVGH FRQWUROORVFRQWUROHVORVSURFHVRV\ORVSURFHGLPLHQWRVGHHVWH6*6, D  FXPSOHQORVUHTXLVLWRVGHHVWDQRUPDLQWHUQDFLRQDODVtFRPRODOHJLVODFLyQ\QRUPDWLYDDSOLFDEOHV E  FXPSOHQORVUHTXLVLWRVGHVHJXULGDGGHODLQIRUPDFLyQLGHQWLILFDGRV F  VHLPSODQWDQ\VHPDQWLHQHQGHIRUPDHIHFWLYD\ G  GDQHOUHVXOWDGRHVSHUDGR  6HGHEHSODQLILFDUXQSURJUDPDGHDXGLWRUtDVWHQLHQGRHQFXHQWDHOHVWDGRHLPSRUWDQFLDGHORVSURFHVRV\ODViUHDVD DXGLWDUDVtFRPRORVUHVXOWDGRVGHODVDXGLWRUtDVSUHYLDV6HGHEHQGHILQLUORVFULWHULRVHODOFDQFHODIUHFXHQFLD\ORV PpWRGRVGHDXGLWRUtD/DVHOHFFLyQGHDXGLWRUHV\ODGLUHFFLyQGHODVDXGLWRUtDVGHEHJDUDQWL]DUODREMHWLYLGDGHLPSDU FLDOLGDGGHOSURFHVRGHDXGLWRUtD/RVDXGLWRUHVQRGHEHQDXGLWDUVXSURSLRWUDEDMR  /DVUHVSRQVDELOLGDGHV \ORVUHTXLVLWRVSDUDODSODQLILFDFLyQUHDOL]DFLyQGHODVDXGLWRUtDVODLQIRUPDFLyQGHORVUHVXO WDGRV\HOPDQWHQLPLHQWRGHORVUHJLVWURVYpDVH GHEHQHVWDUGHILQLGRVHQXQSURFHGLPLHQWRGRFXPHQWDGR  (O UHVSRQVDEOH GHO iUHD DXGLWDGD GHEH YHODU SRU TXH VH UHDOLFHQ DFFLRQHV SDUD HOLPLQDU VLQ GHPRUDV LQGHELGDV ODV GLVFRQIRUPLGDGHVGHWHFWDGDV\VXVFDXVDV/DVDFWLYLGDGHVGHVHJXLPLHQWRGHEHQLQFOXLUODYHULILFDFLyQGHODVDFFLRQHV UHDOL]DGDV\ORVLQIRUPHVGHORVUHVXOWDGRVGHODYHULILFDFLyQYpDVH   127$ /D1RUPD,62'LUHFWULFHVSDUDODDXGLWRUtDGHORVVLVWHPDVGHJHVWLyQGHODFDOLGDG\RDPELHQWDOSURSRUFLRQDRULHQWDFLRQHV ~WLOHVSDUDUHDOL]DUODVDXGLWRUtDVLQWHUQDVGHO6*6,

,62,(&



 5(9,6,Ï1'(/6*6,325/$',5(&&,Ï1   *HQHUDOLGDGHV /D'LUHFFLyQGHEHUHYLVDUHO6*6,GHODRUJDQL]DFLyQDLQWHUYDORVSODQLILFDGRVDOPHQRVXQDYH]DODxR SDUDDVHJXUDU TXHVHPDQWLHQHVXFRQYHQLHQFLDDGHFXDFLyQ\HILFDFLD(VWDUHYLVLyQGHEHFRQWHPSODUODVRSRUWXQLGDGHVGHPHMRUD\OD QHFHVLGDGGHFDPELRVHQHO6*6,LQFOX\HQGRODSROtWLFD\ORVREMHWLYRVGHVHJXULGDGGHODLQIRUPDFLyQ/RVUHVXOWDGRV GHODVUHYLVLRQHVGHEHQHVWDUFODUDPHQWHGRFXPHQWDGRV\VHGHEHQPDQWHQHUORVUHJLVWURVYpDVH   'DWRVLQLFLDOHVGHODUHYLVLyQ /RVGDWRVXWLOL]DGRVSRUOD'LUHFFLyQSDUDODUHYLVLyQGHEHQLQFOXLU D  ORVUHVXOWDGRVGHODVDXGLWRUtDV\UHYLVLRQHVGHO6*6, E  ORVFRPHQWDULRVGHODVSDUWHVLQWHUHVDGDV F  ODV WpFQLFDV SURGXFWRV R SURFHGLPLHQWRV TXH SRGUtDQ XWLOL]DUVH GHQWUR GH OD RUJDQL]DFLyQ SDUD PHMRUDU HO FRPSRUWDPLHQWR\ODHILFDFLDGHO6*6, G  HOHVWDGRGHODVDFFLRQHVSUHYHQWLYDVRFRUUHFWLYDV H  ODVYXOQHUDELOLGDGHVRDPHQD]DVQRDERUGDGDVDGHFXDGDPHQWHHQODHYDOXDFLyQGHULHVJRVSUHYLD I  ORVUHVXOWDGRVGHODVPHGLFLRQHVGHODHILFDFLD J  ODVDFFLRQHVGHVHJXLPLHQWRGHODVUHYLVLRQHVDQWHULRUHV K  FXDOTXLHUFDPELRTXHSXGLHUDDIHFWDUDO6*6,\ L  ODVUHFRPHQGDFLRQHVGHPHMRUD  5HVXOWDGRVGHODUHYLVLyQ /RVUHVXOWDGRVGHODUHYLVLyQUHDOL]DGDSRUOD'LUHFFLyQGHEHQLQFOXLUFXDOTXLHUGHFLVLyQ\DFFLyQUHODWLYDVD  D  ODPHMRUDGHODHILFDFLDGHO6*6,  E  ODDFWXDOL]DFLyQGHODHYDOXDFLyQGHULHVJRV\GHOSODQGHWUDWDPLHQWRGHULHVJRV  F  OD PRGLILFDFLyQ GH ORV SURFHGLPLHQWRV \ FRQWUROHV TXH DIHFWDQ D OD VHJXULGDG GH OD LQIRUPDFLyQ FXDQGR VHD QHFHVDULRSDUDUHVSRQGHUDORVHYHQWRVLQWHUQRVRH[WHUQRVTXHSXHGHQDIHFWDUDO6*6,LQFOX\HQGRORVFDPELRVHQ   ORVUHTXLVLWRVGHOQHJRFLR   ORVUHTXLVLWRVGHVHJXULGDG   ORVSURFHVRVGHQHJRFLRTXHDIHFWDQDORVUHTXLVLWRVGHQHJRFLRH[LVWHQWHV   ORVUHTXLVLWRVOHJDOHVRUHJODPHQWDULRV   ODVREOLJDFLRQHVFRQWUDFWXDOHV\   ORVQLYHOHVGHULHVJR\RORVFULWHULRVGHDFHSWDFLyQGHORVULHVJRV  G  ODVQHFHVLGDGHVGHUHFXUVRV  H  ODPHMRUDHQHOPRGRGHPHGLUODHILFDFLDGHORVFRQWUROHV





,62,(&

 0(-25$'(/6*6,   0HMRUDFRQWLQXD /DRUJDQL]DFLyQGHEHPHMRUDUGHPDQHUDFRQWLQXDODHILFDFLDGHO6*6,PHGLDQWHHOXVRGHODSROtWLFD\GHORVREMHWLYRV GHVHJXULGDGGHODLQIRUPDFLyQGHORVUHVXOWDGRVGHODVDXGLWRUtDVGHODQiOLVLVGHODPRQLWRUL]DFLyQGHHYHQWRVGHODV DFFLRQHVFRUUHFWLYDV\SUHYHQWLYDV\GHODVUHYLVLRQHVGHOD'LUHFFLyQYpDVH   $FFLyQFRUUHFWLYD /DRUJDQL]DFLyQGHEHUHDOL]DUDFFLRQHVSDUDHOLPLQDUODFDXVDGHODVQRFRQIRUPLGDGHVFRQORVUHTXLVLWRVGHO6*6,DILQ GHHYLWDUTXHYXHOYDQDSURGXFLUVH(OSURFHGLPLHQWRGRFXPHQWDGRSDUDODVDFFLRQHVFRUUHFWLYDVGHEHGHILQLUORVUHTXL VLWRVSDUD  D  LGHQWLILFDUODVQRFRQIRUPLGDGHV  E  GHWHUPLQDUODVFDXVDVGHODVQRFRQIRUPLGDGHV  F  HYDOXDUODQHFHVLGDGGHDGRSWDUDFFLRQHVSDUDDVHJXUDUVHGHTXHODVQRFRQIRUPLGDGHVQRYXHOYDQDSURGXFLUVH  G  GHWHUPLQDUHLPSODQWDUODVDFFLRQHVFRUUHFWLYDVQHFHVDULDV  H  UHJLVWUDUORVUHVXOWDGRVGHODVDFFLRQHVUHDOL]DGDVYpDVH \  I  UHYLVDUODVDFFLRQHVFRUUHFWLYDVUHDOL]DGDV  $FFLyQSUHYHQWLYD /DRUJDQL]DFLyQGHEHGHWHUPLQDUODVDFFLRQHVQHFHVDULDVSDUDHOLPLQDUODFDXVDGHODVSRVLEOHVQRFRQIRUPLGDGHVFRQ ORV UHTXLVLWRV GHO 6*6, SDUD HYLWDU TXH pVWDV YXHOYDQ D SURGXFLUVH /DV DFFLRQHV SUHYHQWLYDV DGRSWDGDV GHEHQ VHU DSURSLDGDV HQ UHODFLyQ D ORV HIHFWRV GH ORV SUREOHPDV SRWHQFLDOHV (O SURFHGLPLHQWR GRFXPHQWDGR SDUD ODV DFFLRQHV SUHYHQWLYDVGHEHGHILQLUORVUHTXLVLWRVSDUD  D  LGHQWLILFDUODVSRVLEOHVQRFRQIRUPLGDGHV\VXVFDXVDV  E  HYDOXDUODQHFHVLGDGGHDGRSWDUDFFLRQHVSDUDSUHYHQLUODRFXUUHQFLDGHQRFRQIRUPLGDGHV  F  GHWHUPLQDUHLPSOHPHQWDUODVDFFLRQHVSUHYHQWLYDVQHFHVDULDV  G  UHJLVWUDUORVUHVXOWDGRVGHODVDFFLRQHVDGRSWDGDVYpDVH \  H  UHYLVDUODVDFFLRQHVSUHYHQWLYDVDGRSWDGDV  /DRUJDQL]DFLyQGHEHLGHQWLILFDUORVFDPELRVHQORVULHVJRVDVtFRPRORVUHTXLVLWRVGHODVDFFLRQHVSUHYHQWLYDVFHQ WUDQGRODDWHQFLyQHQORVULHVJRVTXHKD\DQVXIULGRFDPELRVVLJQLILFDWLYRV  /DSULRULGDGGHODVDFFLRQHVSUHYHQWLYDVGHEHGHWHUPLQDUVHEDViQGRVHHQORVUHVXOWDGRVGHODHYDOXDFLyQGHULHVJRV  127$ $FWXDUSDUDSUHYHQLUODVQRFRQIRUPLGDGHVVXHOHVHUPiVUHQWDEOHTXHUHDOL]DUDFFLRQHVFRUUHFWLYDV



,62,(&



$1(;2$1RUPDWLYR   2%-(7,926'(&21752/@ ,62,(&757HFQRORJtDVGHODLQIRUPDFLyQ'LUHFWULFHVSDUDODJHVWLyQGHODVHJXULGDGGHODV7, 3DUWH6HOHFFLyQGHVDOYDJXDUGLDV  >@ ,626LVWHPDVGHJHVWLyQDPELHQWDO5HTXLVLWRV\RULHQWDFLRQHVGHXVR  >@ ,62,(& 75  7HFQRORJtDV GH OD LQIRUPDFLyQ 7pFQLFDV GH VHJXULGDG *HVWLyQ GH LQFLGHQWHV GH VHJXULGDGGHODLQIRUPDFLyQ  >@ ,62'LUHFWULFHVSDUDDXGLWRUtDVGHFDOLGDGRGHVLVWHPDVGHJHVWLyQDPELHQWDO  >@ ,62,(& *XtD  5HTXLVLWRV JHQHUDOHV SDUD HQWLGDGHV HQFDUJDGDV GH OD HYDOXDFLyQ \ FHUWLILFDFLyQ R UHJLVWURGHVLVWHPDVGHFDOLGDG  >@ ,62,(&*XtD*HVWLyQGHULHVJRV9RFDEXODULR'LUHFWULFHVGHXVRHQQRUPDV   2WUDVSXEOLFDFLRQHV  >@ 2&'( 'LUHFWULFHV SDUD OD VHJXULGDG GH ORV VLVWHPDV \ UHGHV GH LQIRUPDFLyQ +DFLD XQD FXOWXUD GH OD VHJXULGDG3DUtV2&'(MXOLRGHZZZRHFGRUJ  >@ 1,6763*XtDGHJHVWLyQGHULHVJRVSDUDVLVWHPDVGHWHFQRORJtDVGHODLQIRUPDFLyQ  >@ 'HPLQJ:(2XWRIWKH&ULVLV&DPEULGJH0DVV0,7&HQWHUIRU$GYDQFHG(QJLQHHULQJ6WXG\  

Sobre los autores

Luis Gómez Fernández es licenciado en Económicas por la Facultad de Económicas de la Universidad de Oviedo. Ha desempeñado diversos cargos directivos, tanto en la Administración Pública como la empresa privada, hasta la creación de su propia empresa que, actualmente, es un referente en seguridad de la información y servicios de TI. Ana Andrés Á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 desempeñada en el área de sistemas de gestión y mejora de procesos, y especialmente, en proyectos de seguridad de la información, servicios de TI y auditorías de sistemas de gestión.