Modelo de seguridad para plataformas colaborativas de e...

Modelo de seguridad para plataformas colaborativas de e-ciencia sobre Cloud

Computing

Pedro Julio Vargas Barrios

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

Maestría en Ciencias de la Información y las Comunicaciones

Bogotá, Colombia

Enero de 2018

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud

Computing

Pedro Julio Vargas Barrios

Tesis presentada como requisito para optar al título de:

Magister en Ciencias de la Información y las Comunicaciones

Director:

Dr. JOSÉ NELSON PÉREZ CASTILLO

Línea de Investigación: Ingeniería de Sistemas, telemática y afines

Grupo de Investigación: GICOGE

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

Maestría en Ciencias de la Información y las Comunicaciones

Bogotá, Colombia

Enero de 2018

3

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing

Agradecimientos

Doy gracias a la Universidad Distrital Francisco José de Caldas que me brindó la

oportunidad de formarme en la modalidad de maestría y me permitió desarrollar en el Centro

de Investigación de Alto Desempeño (CECAD) la investigación y desarrollo de mi trabajo

de grado.

Agradezco a mi familia por su confianza y apoyo, a todos los docentes de la maestría por

su labor como formadores al realizar aportes y observaciones constructivas que

consolidaron este proyecto.

4


Contenido

Lista de figuras ...................................................................................................... 9

Lista de tablas ..................................................................................................... 11

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

1 Formulación de la Investigación ................................................................. 14

1.1 Problema de Investigación ................................................................................. 14

1.2 Pregunta de Investigación ................................................................................. 15

1.3 Justificación ....................................................................................................... 16

2 Objetivos ....................................................................................................... 17

2.1 Objetivo general ................................................................................................ 17

2.2 Objetivos específicos ......................................................................................... 17

3 Cloud Computing y Seguridad de la Información ...................................... 18

3.1 Modelos de servicio ........................................................................................... 20

Software as a Service (SaaS) ..................................................................... 20

Platform as a Service (PaaS) ...................................................................... 21

IaaS (Infraestructura as a Service) ............................................................. 22

3.2 Modelos de Despliegue ..................................................................................... 24

Nube Pública .............................................................................................. 24

Nube Privada .............................................................................................. 24

Nube Comunitaria ....................................................................................... 24

Nube hibrida ............................................................................................... 24

3.3 Seguridad de la información .............................................................................. 25

3.4 Principios de la seguridad de la información. ..................................................... 25

5


Confidencialidad ......................................................................................... 25

Integridad ................................................................................................... 26

Disponibilidad ............................................................................................. 26

Identificación............................................................................................... 27

Autenticación .............................................................................................. 27

Autorización ................................................................................................ 27

Accountability o trazabilidad ....................................................................... 28

No Repudio ................................................................................................ 28

3.5 Problemas de seguridad en Cloud Computing ................................................... 28

Vulnerabilidades en Cloud Computing ........................................................ 28

Amenazas en Cloud Computing ................................................................. 29

Tipos de ataque en la nube ........................................................................ 29

3.6 Enfoques de Modelos de Seguridad en Cloud Computing ................................. 30

Nubes Públicas ........................................................................................... 30

3.7 Investigación & e-ciencia ................................................................................... 32

3.8 Sistema de Gestión de Seguridad de la Información (SGSI) .............................. 33

Ciclo PDCA ................................................................................................ 33

4 Análisis de estándares de seguridad en Cloud Computing ...................... 34

4.1 Organizaciones relevantes en estandarización de Cloud Computing ................. 34

ISO ............................................................................................................. 36

NIST ........................................................................................................... 37

CSA ............................................................................................................ 37

4.2 Familia ISO 27000 ............................................................................................. 38

Vocabulario Estándar ................................................................................. 39

Estándares que especifican requisitos ........................................................ 39

Normas que describen directrices generales .............................................. 39

6


Normas que describen directrices en sectores específicos ......................... 40

4.3 National Institute of Standards and Technology (NIST) ..................................... 42

Federal Information Processing Standards (FIPS): ..................................... 42

NIST Special Publications (SPs): ................................................................ 43

Information Technology Laboratory (ITL) Bulletins: ..................................... 43

NIST Special Publication ............................................................................ 43

NIST Special Publication - Cloud ................................................................ 44

4.4 Cloud Security Alliance (CSA) ........................................................................... 46

Dominio 1: Cloud Computing Architectural Framework ............................... 47

Dominio 2: Governance and Enterprise Risk Management ......................... 47

Dominio 3: Legal Issues: Contracts and Electronic Discovery ..................... 48

Dominio 4 Compliance and Audit Management .......................................... 48

Dominio 5: Information Management and Data Security ............................. 49

Dominio 6: Interoperability And Portability .................................................. 49

Dominio 7: Traditional Security, Business Continuity, and Disaster Recovery

50

Dominio 8: Data Center Operations ............................................................ 50

Dominio 9: Incident Response .................................................................... 50

Dominio 10: Application Security ................................................................ 51

Dominio 11: Encryption and Key Management ........................................... 51

Dominio 12: Identity, Entitlement, and Access Management ....................... 51

Dominio 13: Virtualization ........................................................................... 51

Dominio 14: Security as a Service .............................................................. 52

5 Propuesta de Modelo de seguridad ............................................................ 53

5.1 ¿A quiénes va dirigido? ..................................................................................... 53

5.2 Disposición del entorno y preparación ............................................................... 54

5.3 Establecer situación inicial ................................................................................. 56

7


Reconocimiento de la estructura organizacional ......................................... 57

Verificación de políticas y controles de seguridad existentes ...................... 57

Realización de encuestas ........................................................................... 58

5.4 Definir el alcance ............................................................................................... 59

5.5 Análisis de riesgos y vulnerabilidades ................................................................ 60

Identificación y valoración de activos .......................................................... 60

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

5.6 Modelo propuesto para determinación de controles de seguridad y gestión de

riesgos ......................................................................................................................... 64

Determinación de controles de seguridad basados en normas internacionales

para una nube privada. ............................................................................................. 65

5.7 Implantación del SGSI ....................................................................................... 81

5.8 Monitorización y revisión.................................................................................... 81

5.9 Mantenimiento y mejora..................................................................................... 81

6 Caso de estudio: Modelo de Seguridad para la nube privada del CECAD de la Universidad Distrital Francisco José de Caldas ........................................... 82

6.1 Centro de Computación de Alto de Desempeño (CECAD) ................................ 82

6.2 Disposición del entorno y preparación ............................................................... 83

Contexto del modelo cloud en el CECAD ................................................... 83

Sensibilización de los altos cargos ............................................................. 83

Personal y roles para la implementación .................................................... 84

6.3 Situación actual del CECAD .............................................................................. 85

Estructura Organizacional ........................................................................... 85

Controles de seguridad existentes en la organización ................................ 87

6.4 Alcance del SGSI para el CECAD ..................................................................... 88

6.5 Análisis de riesgos y vulnerabilidades del CECAD ............................................. 88

Identificación y valoración de activos del CECAD ....................................... 88

8


Análisis de riesgos del CECAD ................................................................... 91

6.6 Determinación de controles de seguridad y gestión de riesgos – aplicación del

modelo propuesto ........................................................................................................ 94

Categorización de la información del CECAD ............................................. 94

Determinación de línea base de control para la nube privada ..................... 95

7 Conclusiones .............................................................................................. 109

8 Trabajos futuros ......................................................................................... 110

9 Anexos ......................................................................................................... 111

9.1 Anexo A - lista de Controles ISO 27001/27017/27018 ..................................... 111

9.2 Anexo B - Lista de controles CSA .................................................................... 114

9.3 Anexo C - Mapeo ISO/IEC 27001 a NIST SP800-53 ....................................... 117

9.4 Anexo D - Guía de controles y líneas base del NIST ....................................... 122

9.5 Anexo E - Lista de preguntas para evaluación de controles ............................. 128

9.6 Anexo F - Lista de controles consolidados ....................................................... 134

9.7 Anexo G – Evaluación ISO- NIST .................................................................... 135

Anexo G.1 – Evaluación ISO/IEC 27001 – NIST AC ................................. 135

Anexo G.2 - Evaluación ISO/IEC 27001 – NIST AT, AU ........................... 136

Anexo G.3 - Evaluación ISO/IEC 27001 – NIST CA-CM ........................... 137

Anexo G.4 - Evaluación ISO/IEC 27001 – NIST CP-IA ............................. 138

Anexo E.G Evaluación ISO/IEC 27001 – NIST IR-MA .............................. 139

Anexo G.6 Evaluación ISO/IEC 27001 – NIST MP-PL-PS-RA .................. 140

Anexo G.7 Evaluación ISO/IEC 27001 – NIST PE .................................... 141

Anexo G.8 Evaluación ISO/IEC 27001 – NIST SA .................................... 142

Anexo G.9 Evaluación ISO/IEC 27001 – NIST SC-SI ............................... 143

9.8 Anexo H – Evaluación CSA – NIST ................................................................. 144

10 Bibliografía .................................................................................................. 146

9


Lista de figuras

Figura 1 Características de Cloud Computing basadas en el Modelo Visual NIST [3, p. 10].

........................................................................................................................................ 19

Figura 2 . Responsabilidades en el modelo de servicio SaaS. Autoría propia. ................. 21

Figura 3. Responsabilidades en el modelo de servicio PaaS. Autoría propia. .................. 22

Figura 4. Responsabilidades en el modelo de servicio IaaS. Autoría propia. ................... 23

Figura 5. Distribución de normas de seguridad. Autoría propia. ....................................... 36

Figura 6. Relación entre el SGSI y la familia de estándares ISO [4, p. 21]. ...................... 38

Figura 7 . Documentación publicada por el NITS – Clasificación de series técnicas. Autoría

propia. ............................................................................................................................. 42

Figura 8 . Perfiles de seguridad informática en las organizaciones. Autoría propia. ......... 55

Figura 9. Etapas para determinar la situación inicial de seguridad en la organización. Autoría

propia .............................................................................................................................. 57

Figura 10. Jurisdicciones, entidades jurídicas o marcos involucrados en la aplicabilidad de

requisitos legales [3, p. 37] .............................................................................................. 66

Figura 11. Composición de los controles de seguridad seleccionados. Autoría propia..... 70

Figura 12 . Línea base de seguridad para la categoría de seguridad "baja". Autoría propia.

........................................................................................................................................ 73

Figura 13 . Línea base de seguridad para la categoría de seguridad "media". Autoría propia.

........................................................................................................................................ 74

Figura 14 . Línea base de seguridad para la categoría de seguridad "alta". Autoría propia.

........................................................................................................................................ 74

Figura 15 . Comparación de líneas base de seguridad. Autoría propia. ........................... 75

Figura 16 . Etapas para la selección de controles de seguridad de la nube privada. Autoría

propia. ............................................................................................................................. 76

10


Figura 17 . Organigrama general de la Universidad Distrital Francisco José de Caldas.

Fuente página web Universidad Distrital. ......................................................................... 85

Figura 18 . Organigrama del CECAD de la Universidad Distrital Francisco José de Caldas.

Autoría propia. ................................................................................................................. 86

Figura 19. Servidor en rack PowerEdge R610 [37] .......................................................... 89

Figura 20. Servidor PowerEdge R710 [38] ....................................................................... 89

Figura 21. PowerEdge R900 ............................................................................................ 89

Figura 22. HP DL160 G6 [39] ........................................................................................... 89

Figura 23. BladeCenter S 8886 [40] ................................................................................. 89

Figura 24. Blade HSS 22 [41]. ......................................................................................... 89

Figura 25 . Determinación de línea base de control para la nube privada del CECAD.

Autoría propia. ................................................................................................................. 95

Figura 26 . Clasificación de preguntas para evaluación de controles de seguridad. Autoría

propia. ............................................................................................................................. 96

Figura 27. Línea base de seguridad para el CECAD - Categoría ALTA. Autoría propia. .. 99

Figura 28 .Línea base de seguridad para el CECAD - Categoría MEDIA. Autoría propia. 99

Figura 29 .Línea base de seguridad para el CECAD - Categoría BAJA. Autoría propia. 100

Figura 30 . Estado general de seguridad del CECAD. Autoría propia. ........................... 102

Figura 31 . Línea base de seguridad física del CECAD - Estado ideal. Autoría propia. .. 103

Figura 32 . Estado real de la seguridad física del CECAD. Autoría propia. .................... 103

Figura 33 . Línea base de seguridad de datos del CECAD - Estado ideal. Autoría propia.

...................................................................................................................................... 104

Figura 34 . Estado real de la seguridad de datos del CECAD. Autoría propia. ............... 104

Figura 35 . Línea base de seguridad de red del CECAD - Estado ideal. Autoría propia. 105

Figura 36 . Estado real de la seguridad de datos del CECAD. Autoría propia. ............... 105

11


Lista de tablas Tabla 1. Organizaciones relevantes de estandarización en Cloud Computing [18]. ......... 35

Tabla 2. N° de certificados ISO/IEC 27001 por región – Fuente ISO ............................... 37

Tabla 3. Perfiles básicos para implementación de modelo de seguridad. Autoría propia. 56

Tabla 4. Valoración cualitativa de activos. Autoría propia ................................................ 60

Tabla 5. Valoración cuantitativa de activos. Autoría propia .............................................. 61

Tabla 6. Valoración total de activos ................................................................................. 61

Tabla 7. Criterios de Valoración de vulnerabilidades. Autoría propia. .............................. 62

Tabla 8. Valoración de riesgos ......................................................................................... 63

Tabla 9. Estados y valores del riesgo .............................................................................. 63

Tabla 10. Matriz de riesgo por activo – Autoría propia ..................................................... 64

Tabla 11. Organizaciones relevantes en desarrollo de normas y certificaciones Cloud [31].

........................................................................................................................................ 67

Tabla 12. Identificadores y nombres de controles de seguridad del NIST [33, p. 9] ......... 72

Tabla 13. Estructura de la tabla de categorización y evaluación de controles para la nube

privada. Autoría propia. .................................................................................................... 77

Tabla 14 . Ejemplo de preguntas para la valoración de controles de seguridad. Autoría

propia. ............................................................................................................................. 79

Tabla 15. Criterios para la valoración de los controles de seguridad. Autoría propia. ...... 80

Tabla 16. Activos del CECAD que hacen parte de la nube. Autoría propia. ..................... 89

Tabla 17. Imágenes de equipos que hacen parte de la nube privada ............................. 89

Tabla 18. Tabla de Valoración Cualitativa del CECAD. Autoría Propia. ........................... 90

Tabla 19. Tabla de Valoración Cuantitativa del CECAD. Autoría Propia. ......................... 90

Tabla 20. Valoración de activos del CECAD. Autoría propia. ........................................... 90

Tabla 21. Rangos de valores para la determinación de tipos de riesgo. .......................... 91

Tabla 22 . Matriz de riesgos del CECAD. Autoría propia. ................................................. 93

Tabla 23 . Categorías de seguridad según el NIST - FIPS 199. ....................................... 94

Tabla 24 . Estructura de la tabla para la elaboración de controles de seguridad. Autoría

propia. ............................................................................................................................. 97

Tabla 25 . Número de preguntas por tipo de pregunta para el CECAD. ........................... 97

Tabla 26 . Cantidad de preguntas por norma y por mapeo al NIST. ................................. 98

Tabla 27 . Evaluación de controles ................................................................................ 101

Tabla 28 . Principales Recomendaciones/Controles de seguridad para el CECAD ........ 107

12


Introducción

Las preocupaciones de seguridad en Cloud Computing están asociadas con la protección

de los datos personales de sus usuarios, la denegación de servicios, la pérdida de datos,

la seguridad de las APIs, entre otros aspectos que afectan este modelo; ahora bien, aunque

es cierto que una nube pública está mucho más expuesta a amenazas y ataques

informáticos, la organización que opta por implantar una nube privada tiene estas mismas

preocupaciones pero con la dificultad de establecer cómo abordarlas, por un lado debe

mantener en gran medida la seguridad tradicional en los recursos que la soportan, y por

otro debe escoger los controles de seguridad me mejor protegerán los servicios que

ofrecerá. Lo anterior implica que deba garantizar la implantación de un modelo de seguridad

que se enfoque en sus particularidades con el fin de generar confianza en sus

usuarios/clientes. Este proyecto se centra precisamente en la seguridad de nubes privadas,

con una distinción adicional que consiste en que la nube privada esté orientada a

investigación, donde la protección de los datos que son resultado de proyectos de

investigación toma mayor relevancia.

Existe una extensa cantidad de estándares técnicos que aplican para diferentes disciplinas

o áreas, estos son elaborados por diferentes organizaciones que pueden coincidir algunas

veces en la temática del estándar pero no así en su contenido, en el área de la seguridad

informática por ejemplo se presenta esta situación, ya que aunque algunas organizaciones

son más reconocidas que otras, como es el caso de la familia ISO/IEC 27000, es posible

que los estándares publicados no cubran por completo las características de una tecnología

específica, o que de alguna forma incluya reglas que sean innecesarias o limiten tales

características. Es así como en el Cloud Computing los controles de la ISO/IEC 27001

pueden ser complementados por estándares o buenas prácticas que son expedidas por

otras organizaciones que están dedicadas a todo lo relacionado con la Cloud; ahora bien,

si se piensa concretamente en una nube privada, el análisis de unos criterios específicos

mínimos de seguridad dentro esta amplia cantidad de estándares se hace mucho más

complejo. Este proyecto busca hacer un aporte en este sentido, proponiendo una

13


metodología que facilite a las organizaciones que han implementado una nube privada, la

protección de los servicios que ofrece y la infraestructura que la soporta.

Este trabajo se propone a través de unos criterios de seguridad seleccionados de diferentes

organizaciones, establecer una metodología para que las organizaciones obtengan una

línea base de seguridad que se ajuste a su nube privada. Se presentará así mismo un caso

de estudio realizado en el Centro de Computación de Alto Desempeño (CECAD) de la

Universidad Distrital Francisco José de Caldas.

En los dos primero capítulos se encuentra la caracterización básica y el enfoque del

proyecto, presentando en el primer capítulo la formulación de la investigación, donde se

define el problema de investigación, la pregunta de investigación y la justificación; en el

segundo capítulo se exponen los objetivos del proyecto.

El tercer y cuarto capítulo contienen los temas asociados al marco teórico, que debido a la

robustez de su contenido debieron dividirse de esa forma para facilitar la comprensión que

se dificultaría vinculándolos en un solo. Básicamente en el tercer capítulo se presentan

conceptos básicos de Cloud Computing y seguridad de la información y en el capítulo cuatro

se pretende dimensionar la cantidad de normas relacionadas con la seguridad de la

información y la dificultad para relacionarlas o centrarse en algunas específicas.

En el capítulo quinto se expone el modelo propuesto, que está basado en el tradicional ciclo

PDCA, así mismo se realiza un aporte planteando una metodología para definir los

controles de seguridad para una nube privada basado en normas y buenas prácticas de

organizaciones reconocidas. En el capítulo sexto se presenta el caso de estudio realizado

en el CECAD y su diferencia con el estado “ideal” de seguridad planteado.

14


1 Formulación de la Investigación

1.1 Problema de Investigación

El concepto de Cloud Computing continúa en auge y su uso se sigue extendiendo como

una alternativa para diferentes empresas y usuarios que buscan obtener poder y capacidad

de cómputo de forma ágil y a bajo precio; por ejemplo, empresas que optan por ofrecer

infraestructura como servicio (IAAS), han invertido en soluciones de software que les

permite utilizar sus recursos de cómputo para construir nubes privadas con el fin de obtener

una mejor administración de recursos. Así mismo, este proceso de migración a la nube se

refleja en universidades que han comenzado un proceso de implementación de nubes

privadas en sus centros de datos. Uno de los casos es el de la Universidad de los Andes,

que en el año 2012 instaló un escenario completo de Cloud Computing a partir del cual

surgieron y se continúan desarrollando proyectos del área de investigación; de la misma

forma, la Universidad Distrital implementó desde el año 2015 una nube privada en su Centro

de Computación de Alto Desempeño (CECAD), la cual ha beneficiado tanto a docentes y

estudiantes de postgrado y doctorado en el desarrollo de sus proyectos de investigación.

Este tipo de iniciativas son una tendencia, e inclusive no se puede descartar a futuro la

creación de una federación de “nubes” orientadas a investigación entre universidades a

partir de estos proyectos. “La Federación comprende los servicios de diferentes

proveedores de agregados en un solo grupo de apoyo, y tiene tres características básicas

de interoperabilidad - la migración de recursos, redundancia de recursos y la combinación

de los recursos complementarios” (Kurze, y otros, 2015). En la implementación de tales

tipos de arquitectura se deben considerar varios aspectos de seguridad que pueden no ser

suficientes para generar confianza en el usuario que utiliza el servicio, sobre todo si el

usuario es un investigador, quien puede considerar que expone una potencial publicación

reconocida o el trabajo de toda su vida. Lo anterior implica que se deban considerar los

principales estándares de seguridad en la nube y las buenas prácticas que mitiguen riesgos

como el acceso no autorizado a información de investigación, su alteración o la

15


disponibilidad de la misma; así mismo el uso de estándares puede ayudar a prevenir

amenazas tanto internas como externas. La aplicación o el uso de la nube para proyectos

científicos no ha tenido mucha difusión, es relativamente reciente su utilización en esta

área, todo gira por lo general en torno a temas más comerciales que resultan

económicamente atractivos para los proveedores de servicio. El investigador que utilice la

nube, en todo caso debe asimilar y cambiar de mentalidad, porque la información de su

investigación se puede procesar y almacenar en diferentes sitios y quedarán siempre dudas

asociadas a su seguridad y privacidad, ya que por ejemplo desconoce el estado de la

infraestructura que soporta los servicios de la nube, este es uno de sus rasgos

característicos de este modelo.

En el ámbito comercial los usuarios cuentan por lo general con un alto grado de confianza

del manejo de la información en la nube, pero en el académico, cuando se trata de nubes

privadas, esta confianza estará asociada a riesgos relacionados con la calidad de los

equipos que soportan los servicios, las garantías técnicas de los mismos, la arquitectura de

la nube, el personal capacitado, el uso adecuado del almacenamiento, etc. En general no

se ve con claridad un modelo de seguridad orientado a nubes privadas dedicadas a

investigación; es por ello que el presente proyecto de tesis busca abordar este tema.

1.2 Pregunta de Investigación

¿Cómo adaptar los modelos de seguridad tradicionales y estándares para optimizar la

seguridad de la información que resulta de investigaciones científicas en plataformas

colaborativas de e-ciencia implementados en nubes privadas?

16


1.3 Justificación

Un modelo de referencia de seguridad se orienta a crear consistentes y efectivos

mecanismos que permitan definir e implementar controles adecuados contra los riesgos

identificados. Es indiscutible que la implementación de una nube lleva consigo un conjunto

de elementos de seguridad propios, pero estos se deben respaldar con un modelo

adecuado que se ajuste a las características de la organización que lo está implementando,

en particular si se quiere elaborar un modelo para un entorno en donde la Cloud se enfoca

en investigación, como es el caso de la nube privada del Centro de Computación de Alto

Desempeño (CECAD) de la Universidad Distrital. Por tanto, se hace necesario definir los

parámetros y el modelo de seguridad con los estándares apropiados que proporcionen

mayores garantías de seguridad a las investigaciones desarrolladas en él, esto a partir de

la selección correcta de los controles que se deban instaurar. El no tomar medidas

adicionales para fortalecer la seguridad en este tipo de escenarios, elevaría la exposición

de los servicios ofrecidos a los investigadores a posibles ataques, fuga de datos u otras

vulnerabilidades. Adicionalmente se necesita contar con un referente que sirva de guía a

otras organizaciones o instituciones decididas a adaptar sus centros de datos como nubes

privadas. El uso inadecuado de los recursos también supone un riesgo para la información

de los proyectos de investigación que se desarrollen, por ello se deben establecer pautas

o recomendaciones que orienten a un buen uso de los mismos. Los aspectos que cobran

más relevancia en este escenario son el almacenamiento y la integridad de la información.

17


2 Objetivos

2.1 Objetivo general

Presentar un modelo conceptual de seguridad que permita optimizar la disponibilidad,

integridad y confidencialidad de la información generada en proyectos de investigación

desarrollados en plataformas colaborativas de e-ciencia sobre una Cloud privada.

2.2 Objetivos específicos

• Identificar recursos del entorno de implementación de la Cloud privada.

• Establecer vulnerabilidades y riesgos potenciales.

• Analizar modelos y estándares de seguridad y su aplicabilidad en el entorno de

Cloud Privada.

• Proponer y ajustar un modelo de seguridad que permita definir e implementar

controles a las vulnerabilidades de la nube privada.

18


3 Cloud Computing y Seguridad de la Información

El National Institute of Standards and Technology (NIST) define la Computación en la Nube

o Cloud Computing como “un modelo para habilitar acceso conveniente por demanda a un

conjunto compartido de recursos computacionales configurables (por ejemplo, redes,

servidores, almacenamiento, aplicaciones y servicios), que pueden ser rápidamente

aprovisionados y liberados con un esfuerzo mínimo de administración o de interacción con

el proveedor de servicios” [1, p. 2]. Esta una definición robusta es bastante aceptada, ya

que describe de forma concisa las principales características del modelo Cloud y es

ampliamente referenciada en diferentes documentos y por varios expertos. Sin embargo el

concepto de Cloud ya era contemplado (aunque sin utilizar este término) por John

McCarthy, quien en 1961 pronosticó que la computación se organizaría en el futuro como

un servicio; posteriormente, J.C.R. Licklider introdujo la idea de “red galáctica de

computación” concebida como una red interconectada globalmente. Sin embargo estas

ideas no se concretarían sino hasta finales de los 90 y comienzos del 2000, con empresas

como Salesforce y Amazon que hicieron realidad estos conceptos ofreciendo sus

novedosos servicios.

El NITS, en [2, p. 8] identifica un conjunto de características esenciales del Cloud Computing

conformadas en primer lugar por el autoservicio por demanda, que implica que un usuario

puede asignarse los recursos de computación según sus necesidades; amplio acceso a la

red, que hace referencia a que las capacidades que proporciona la Cloud se pueden

acceder desde cualquier lugar por medio de mecanismos estándar de plataformas clientes;

agrupación de recursos, que consiste, entre otras cosas, en el uso por parte de varios

usuarios de los recursos de cómputo del proveedor (p.ej., almacenamiento, procesamiento,

memoria); rapidez y elasticidad, que se refiere a la posibilidad de aumentar o disminuir las

capacidades provisionadas con rapidez; servicio supervisado, que involucra el control y

optimización de los recursos de forma automática, así como su monitoreo por parte tanto

del proveedor como de los usuarios.

La Cloud Security Alliance (CSA) en el documento Security Guidance For Critical Areas Of

Focus In Cloud Computing V3.0, hace una representación gráfica de los modelos y

características definidos por el NITS. Este modelo visual se puede observar en la Figura 1.

19


Figura 1 Características de Cloud Computing basadas en el Modelo Visual NIST [3, p. 10].

En los siguientes subtemas se explica en qué consisten los modelos de servicio y los

modelos de despliegue presentados en la Figura 1. Así mismo se comienza a exponer la

forma en que se puede asimilar la seguridad de estos modelos en el ámbito investigativo y

académico. Si bien, los riesgos son similares, se quiere resaltar el manejo de la información

en nubes privadas, como es el caso de resultados de investigaciones científicas que pueden

desarrollarse en este ambiente.

Dentro de los Roles o perfiles de los usuarios que hacen parte de un modelo cloud se

encuentran:

Cliente: El cliente o usuario de la nube es quien solicita los servicios que le resultan

conveniente de un proveedor Cloud, es el actor principal en Cloud Computing.

Proveedor: Es el responsable por mantener el servicio. Este adquiere y administra la

infraestructura necesaria para proveer el servicio en la nube que se pondrá a disposición

de los clientes. Las principales actividades del proveedor son: la implementación del

servicio, su administración y la seguridad.

20


Distribuidor: provee conectividad y transporte, el proveedor le requiere conexiones

dedicadas y encriptadas para asegurar un nivel de consistencia acorde a las obligaciones

contractuales con sus consumidores

Auditor: verifica la conformidad con estándares, evalúa servicios en términos de controles

de seguridad, privacidad y performance

Intermediario: administra el uso, performance y distribución de los servicios, negocia

relaciones entre proveedores y clientes. En ocasiones el cliente tiene relación con el

intermediario sin conocer al proveedor.

3.1 Modelos de servicio

Los modelos de servicio de Cloud Computing están asociados con el tipo de servicio que

se ofrece, conocer sus definiciones permite establecer y comprender las responsabilidades

de seguridad por parte del proveedor y el usuario/cliente. Para ello, a continuación se

presentarán los conceptos expuestos por el NITS en el documento NIST Cloud Computing

Reference Standars Roadmap o SP 500-291, así mismo se describirán los compromisos

de seguridad que conciernen tanto al proveedor como al usuario dependiendo del modelo

de servicio. La caracterización de estos modelos se orientará especialmente a su uso en la

investigación.

Software as a Service (SaaS)

En este modelo “la capacidad otorgada al cliente es para usar aplicaciones del proveedor

de una infraestructura cloud. Las aplicaciones son accesibles desde diferentes dispositivos

de cliente a través de una interfaz de cliente ligero, como un navegador web o una interfaz

de programa.” [2, p. 9]. Por lo general se accede a este tipo de servicios desde el navegador

sin utilizar software, ya que el software es administrado por el proveedor y lo expone a

través de la red. En este caso, debido a que el proveedor es quien asume las mayores

responsabilidades sobre el servicio ofrecido, es quien debe garantizar en todos los niveles

la seguridad del mismo. El cliente o usuario final no debe preocuparse por las capas que

soportan el servicio, como se observa en la Figura 2, el proveedor será quien se

responsabilice por su protección.

21


Figura 2 . Responsabilidades en el modelo de servicio SaaS. Autoría propia.

En un proyecto de e-ciencia el modelo anterior se contempla en el siguiente escenario:

teniendo un conjunto de datos que están almacenados en la nube como resultado de un

determinado experimento, estos se pueden analizar a partir de una herramienta ofrecida

por el proveedor, a través por ejemplo de una página web en la que el investigador

selecciona los cálculos o estadísticas de su interés. El investigador no deberá preocuparse

ni por el software, framework, sistema operativo o hardware, él deberá concentrarse en los

resultados objeto de su investigación, y el proveedor deberá ser quien garantice que tanto

la información como la aplicación tienen la seguridad debida.

Platform as a Service (PaaS)

Este modelo comprende “la capacidad otorgada al cliente para desplegar en la

infraestructura de la nube aplicaciones propias o adquiridas utilizando lenguajes de

programación, bibliotecas, servicios y herramientas soportadas por el proveedor.” [2, p. 9].

No es una preocupación del usuario la infraestructura, él se enfoca en el desarrollo de sus

aplicaciones o servicios y los ejecuta en la nube. Como ejemplo de PaaS encontramos

Google app engine, Heroku y Rollbase, que los desarrolladores pueden elegir de acuerdo

a sus necesidades y lenguajes de programación preferidos.

22


Es de resaltar, que a diferencia del SaaS, en el PaaS el cliente comienza a tener un papel

más destacado en lo concerniente a seguridad, ya que a nivel de aplicación asume este

tipo de responsabilidad porque depende de su conocimiento y habilidad que los desarrollos

resultantes sean confiables. El proveedor por su parte debe seguir garantizando la

seguridad en los demás niveles, desde la infraestructura hasta el framework ofrecido como

se puede visualizar en la Figura 3.

Figura 3. Responsabilidades en el modelo de servicio PaaS. Autoría propia.

IaaS (Infraestructura as a Service)

El modelo de infraestructura como servicio consiste en “la capacidad otorgada al cliente

para proveer procesamiento, almacenamiento, redes, y otros recursos de cómputo

fundamentales, donde es capaz de desplegar software arbitrario, que puede incluir

sistemas operativos y aplicaciones” [2, p. 9]. En este modelo el usuario o cliente tiene

mayores responsabilidades en temas de seguridad, sin desconocer que el proveedor tiene

un papel sumamente importante.

Entre los elementos de seguridad que competen al proveedor se encuentra en primer lugar

la seguridad física del centro de datos, donde está la infraestructura física que soporta la

23


nube, ya que aunque resulta evidente que la seguridad física no está asociada

exclusivamente al modelo cloud, sino también a los modelos tradicionales, vale la pena

aclarar su importancia. Así mismo entran en este aspecto temas como la garantía de los

equipos, la autenticación multifactor para los usuarios que tienen acceso al centro de datos,

etc. También es importante para el proveedor proteger otras características de los servicios

Cloud, como lo son la seguridad de las instancias, los métodos de autenticación de los

usuarios que ingresan a ellas, la seguridad de las APIs, el almacenamiento por bloques y

por objetos que se asigna a los usuarios, entre otros factores que se detallarán más

adelante.

Por su parte, en este modelo el cliente o usuario de la nube puede administrar máquinas

virtuales, el sistema operativo de las mismas, el tipo de almacenamiento que necesita,

redes virtuales, etc., todo a partir de una arquitectura que se planteé ajustada a las

necesidades y recursos financieros con que se cuente. El modelo IaaS se puede encontrar

con los siguientes proveedores: Amazon Web Service (AWS), vCloud, Microsoft Azure.

Teniendo en cuenta lo anterior, las responsabilidades en seguridad del proveedor y el

cliente se pueden observar en la Figura 4.

Figura 4. Responsabilidades en el modelo de servicio IaaS. Autoría propia.

24


3.2 Modelos de Despliegue

Nube Pública

En este modelo de despliegue “la infraestructura de la nube se aprovisiona para libre uso

por el público en general. Puede ser propiedad, administrada y operada por una

organización comercial, académica o gubernamental, o por una combinación de ellas” [2,

p. 10].

Nube Privada

La nube privada se caracteriza por “la infraestructura de nube se aprovisiona para uso

exclusivo de una sola organización que comprende múltiples clientes (por ejemplo,

unidades de negocio) … puede existir dentro o fuera de las instalaciones” [2, p. 10].

Nube Comunitaria

En la nube comunitaria “la infraestructura se aprovisiona para uso exclusivo de una

comunidad de clientes de organizaciones que tienen preocupaciones compartidas (por

ejemplo, misión, requisitos de seguridad, políticas y consideraciones de cumplimiento” [2,

p. 10].

Nube hibrida

Es un modelo de despliegue en el cual “la infraestructura en la nube es una composición

de dos o más distintas infraestructuras cloud (privada, comunitaria o pública) que siguen

siendo entidades únicas, pero quedan vinculadas por la tecnología estandarizada o de

propiedad que permite la portabilidad de datos y aplicaciones” [2, p. 10].

25


3.3 Seguridad de la información

Existen distintas definiciones de seguridad de la información, sin embargo se hace alusión

a la presentada por la ISO 27000, en ella se indica que la seguridad de la información se

refiere a “la protección de la confidencialidad, integridad y disponibilidad de activos de

información ya sea en almacenamiento, procesamiento o transmisión. Esta se obtiene

mediante la aplicación de políticas, educación, formación y conocimiento, y tecnología. ” [4,

p. 15], la Confidencialidad, Integridad y Disponibilidad de la información es conocida

también como CIA por sus siglas en inglés, y un escenario ideal es aquel donde se puede

garantizar que se cumple con los anteriores criterios en su totalidad, pero no es posible

llegar a tal grado de certeza, lo que se busca con la seguridad de la información es reducir

al máximo los riesgos utilizando las medidas adecuadas, y esto es un proceso continuo de

mejoras en las políticas y controles. La información es un activo primordial de cualquier

organización y puede resultar catastrófico que una vulnerabilidad sea explotada, por

ejemplo, el acceso a información confidencial de proveedores o clientes podría llevar a

graves consecuencias legales. Ahora bien, llevando este tipo de inconvenientes al entorno

académico e investigativo, se encuentra la seguridad de la información como un elemento

que ayuda a evitar el riesgo de perder información resultados de experimentos

computacionales, trabajos realizados con años de investigación, posibilidades de patentes,

proyectos de tesis, etc.

La Confidencialidad, Integridad y Disponibilidad de la información son principios o

características básicas de la seguridad de la información, pero existen otros conceptos

importantes que vale la pena comprender y que se presentan a continuación.

3.4 Principios de la seguridad de la información.

Confidencialidad

Según el NIST en la publicación FIPS 199, la confidencialidad consiste en “la preservación

de las restricciones autorizadas sobre el acceso y divulgación de información, incluidos los

medios para proteger la privacidad personal y la información propietaria” [5, p. 2] así mismo

se indica que un ejemplo de pérdida de confidencialidad es la divulgación no autorizada de

26


información. Otra definición presente en [6, p. 13] indica que la confidencialidad abarca dos

conceptos adicionales, el primero es la confidencialidad de los datos que consiste en

asegurar que la información privada no está disponible ni es revelada a personas no

autorizadas, y en segundo lugar la privacidad la cual consiste en que los individuos

controlan qué información relacionada con ellos puede ser recopilada o almacenada y a

quien puede ser revelada..

Integridad

La integridad es la “protección contra la modificación inadecuada o destrucción de la

información, e incluye asegurar la autenticidad y no repudio de la información” [5, p. 2]. La

información para el usuario debe ser exacta, consistente con las modificaciones que él ha

realizado, no deben presentarse modificaciones no autorizadas ni destrucción de la misma.

En [6, p. 13] se indica como aporte que la integridad abarca el término integridad de datos

que el cual consiste en que la información y los programas cambian sólo de un modo

específico y autorizado; y el término integridad del sistema, que asegura que un sistema

realiza su función de manera intacta, libre de manipulación no autorizada deliberada o

inadvertida en el sistema.

La integridad tiene que ver mucho con la calidad de la información, con una representación

idónea de la misma que no refleje inconsistencias; por ejemplo, un problema contable en

una organización debido a la modificación no autorizada de los datos o la eliminación de

estos puede tener graves implicaciones, como ejemplo adicional, si en una investigación

que se esté realizando y se genere una gran cantidad de datos durante un largo periodo de

tiempo, resultaría muy perjudicial que al final se encontrara que la base de datos donde se

almacena la información esta corrupta. Por ello la importancia de esta característica al

momento de pensar en la seguridad de la información.

Disponibilidad

La disponibilidad consiste en “garantizar el acceso oportuno y confiable a la información y

su uso” [5, p. 2], lo anterior por parte de los usuarios, procesos o aplicaciones autorizadas,

“la información debe ser accedida sin interferencias u obstrucciones y debe ser recibida en

el formato requerido” [7, p. 12].

27


Ahora se expondrán otros procesos o características que están orientados a la protección

de los anteriores criterios. Entre ellos se encuentra la identificación, la autenticación y la

autorización y el no repudio.

Identificación

“Es el proceso por el cual un sujeto afirma una identidad” [8], es el primer paso en la

secuencia de identificación-autenticación-autorización, la identificación por sí sola no es

suficiente, como se explica en [9, p. 10] si un sujeto llamado Persona X, dice llamarse así,

también podría identificarse diciendo que se llama Persona Y, por lo que la identidad sola

es débil, no es una prueba , para probarlo se necesita el proceso de autenticación.

Autenticación

La autenticación es “el proceso de verificar o probar que una identidad reclamada es válida.

Esta requiere que un sujeto proporcione información adicional que debe corresponder

exactamente a la identidad profesada” [8]. Es decir que en esta etapa el individuo debe

probar que es quien dice ser. Hay tres métodos de autenticación para los usuarios basados

en qué conoce, qué tiene y quien es.

• Factor - Qué conoce: Está relacionado con algo que el usuario conoce, por ejemplo

contraseñas, números de PIN, códigos, etc.

• Factor - Qué tiene: En este, el usuario debe autenticarse con algún dispositivo que

tenga, por ejemplo un token, una tarjeta, una USB, etc.

• Factor – Algo que es: En este tipo de autenticación, el usuario mediante una

característica física, a través de dispositivos biométricos debe confirmar su

identidad.

Autorización

“La autorización describe las acciones que puede realizar en un sistema una vez que haya

identificado y autenticado. Las acciones pueden incluir lectura, escritura o ejecución de

archivos o programas” [9, p. 10]. Esta autorización está asociada con los denominados

privilegios o permisos para el uso del sistema que a su vez son definidos por un

administrador del sistema.

28


Accountability o trazabilidad

El proceso de Accountability que se puede traducir como trazabilidad o registro para el tema

que se está tratando, “se realiza a través de auditoría, registro y monitoreo, asegura que

los sujetos puedan ser responsabilizados por sus acciones” [8], con ello se puede rastrear

la actividad del usuario relacionada por ejemplo con el uso de recursos de red, intentos de

acceso no permitidos, en fin, el objetivo es poder identificar intentos de violación a las

políticas de seguridad y resulta útil cuando se presentan incidentes de seguridad en

general.

No Repudio

El No Repudio significa que “un usuario no puede negar (repudiar) haber realizado una

transacción. Combina la autenticación y la integridad: la no-repudiación autentica la

identidad de un usuario que realiza una transacción y garantiza la integridad de dicha

transacción” [9, p. 10]. El No Repudio es un elemento útil para emplear por ejemplo en el

comercio electrónico.

3.5 Problemas de seguridad en Cloud Computing

Vulnerabilidades en Cloud Computing

La vulnerabilidad representa un grado de exposición, un elemento de un sistema informático

que puede ser aprovechado por un atacante para violar la seguridad. La nube en este

sentido comparte muchas características con los sistemas tradicionales. Estas pueden

estar relacionadas con un mal diseño de la seguridad perimetral por parte del proveedor,

debilidad en el diseño de protocolos utilizados en las redes, políticas de seguridad deficiente

e inexistente, errores de programación, configuración inadecuada de los sistemas

informáticos o plataformas cloud e inclusive por el uso inadecuado de los usuarios finales

de la nube.

Las nubes públicas reconocidas (AWS, Azure,…) están constantemente trabajando para

reducir las “debilidades” que se identifican debido a las amenazas que surgen diariamente.

Sin embargo cuando se trata de nubes privadas en plataformas como por ejemplo

Openstack, OpenNebula, etc., depende en gran medida de los administradores estar

29


verificando las actualizaciones de las versiones de sus plataformas, los parches o

recomendaciones de seguridad que se identifiquen, de tal forma que por lo menos en lo

que corresponde a la plataforma que ofrece los servicios se puedan reducir las

vulnerabilidades.

Amenazas en Cloud Computing

Los entornos en la nube enfrentan muchas de las mismas amenazas que las redes

corporativas tradicionales, pero además contemplando la gran cantidad de datos

almacenados en servidores en la nube, los proveedores se convierten en un objetivo

atractivo.

Dentro de las amenazas comunes a la confidencialidad de la información se encuentra el

malvare, ingeniería social, redes inseguras y una mala administración del sistema. La

información expuesta va de desde datos financieros, información de salud, propiedad

intelectual, y en el campo de la ciencia se puede pensar en resultados de investigación.

Otro ejemplo tiene que ver con problemas de autenticación, si la organización proveedora

está expuesta a ataques de fuerza bruta u otro tipo de ataques, deben revisarse métodos

como administración de claves o certificados que brinden mayor confianza, y de ser viable

utilizar una autenticación multifactor.

Los ataques a las APIs de la nube también se destacan como amenaza. Prácticamente

todos los servicios y aplicaciones en la nube ahora ofrecen APIs. Los equipos de TI utilizan

interfaces y API para gestionar e interactuar con servicios en la nube, incluidos aquellos

que ofrecen aprovisionamiento, gestión, orquestación y supervisión en la nube.

Tipos de ataque en la nube

Dentro de los ataques más comunes que pueden ocurrir en la nube se encuentran los

siguientes [10, p. 51]:

Ataques XML Signature Wrapping: En este tipo de ataque los hackers explotan la envoltura

de firmas XML (XML signature wrapping) de la estructura SOAP inyectando elementos

maliciosos en la estructura del mensaje. “Una de las opciones para restringir este tipo de

ataques es el uso del protocolo REST en lugar de SOAP” [11].

30


Ataques Cross site scripting: este tipo de ataques está dentro de la categoría de ataques

sobre aplicaciones web, y a su vez se divide en otras subcategorías, sin embargo, la forma

en que se utiliza en la nube consiste inyectar en un trozo de código en la aplicación web

para evitar los mecanismos de control de acceso.

Ataque Denial-of-Service: los ataques de denegación de servicio (DoS) están orientados a

interrumpir un sitio web, red o servicio dejándolo inutilizable o no disponible impidiendo a

usuarios legítimos el acceso. Existen diferentes tipos y cada uno tiene efectos específicos

sobre la nube, se puede mencionar por ejemplo el “Bandwidth Attack que consiste en una

sobrecarga de tráfico, o el ataque ICMP (Ping) Flood que consume los recursos de la

víctima mediante muchas peticiones de ICMP” [12].

Robo de datos por fuerza bruta: este tipo de ataques se llevan a cabo para revelar

credenciales de inicio de sesión y acceder a datos a través de sitios web, son difíciles de

detectar, sobre todo cuando son ataques sofisticados y se realizan de forma distribuida.

Algunas medidas que permiten mitigarlos son el uso de programas CAPTCHA, el uso de

contraseñas seguras, o proporcionar acceso a los servicios mediante VPNs.

3.6 Enfoques de Modelos de Seguridad en Cloud Computing

Nubes Públicas

3.6.1.1 Amazon web service Según AWS [13] los beneficios de seguridad con que cuenta son los siguientes:

Protección de los datos: La infraestructura de AWS implanta potentes medidas de seguridad

para proteger la privacidad de los clientes. Todos los datos se almacenan en centros de

datos de AWS de alta seguridad.

Cumple requisitos de conformidad y residencia de datos: El cliente conserva el control y la

propiedad total sobre la región en que los datos se encuentran físicamente, lo que facilita

el cumplimiento de los requisitos regionales de conformidad y residencia de datos.

31


Reducción de costos: Se mantienen los máximos estándares de seguridad sin tener que

administrar sus propias instalaciones.

Escalable rápidamente: La seguridad se escala con su uso de la nube de AWS. Sea cual

sea el tamaño de su negocio, la infraestructura de AWS está diseñada para proteger los

datos.

Mejora de continuidad con replicación entre regiones: Además de replicar aplicaciones y

datos en varios centros de datos de la misma región de las zonas de disponibilidad, se

puede optar también por aumentar la redundancia y la tolerancia a fallos mediante la

replicación de los datos entre regiones geográficas.

Expansión geográfica: La infraestructura de AWS se extiende a diferentes regiones

geográficas durante el año.

3.6.1.2 Microsoft Azure Esta nube según Microsoft [14], [15] cumple con los siguientes criterios de seguridad:

Privacidad: Se afirma que no se usan los datos de clientes ni se deriva información de los

mismos con fines de publicidad o minería de datos, así mismo se indica que el usuario tiene

los datos, control sobre la ubicación donde se almacenan y sobre cómo se tiene acceso a

ellos y cómo se eliminan de forma segura.

Cumplimiento: Azure cumple un conjunto amplio de estándares de cumplimiento

internacionales y específicos de la industria, como ISO 27001, HIPAA, FedRAMP, SOC 1 y

SOC 2, así como estándares específicos de cada país como el IRAP en Australia, el G-

Cloud en el Reino Unido y el MTCS en Singapur. Auditorías de terceros rigurosas, como la

del Instituto Británico de Estándares, comprueban que Azure se adhiera a los controles de

seguridad estrictos que estos estándares exigen

Gestión de identidad y accesos: Microsoft utiliza una gestión de identidades y controles de

acceso estrictos para limitar el acceso a datos y sistemas, empleando el principio de acceso

menos privilegiado.

Infraestructura segura: Una estrategia de "asumir incumplimiento" permite a Microsoft

fortalecer sus productos empresariales y servicios en la nube y mantenerse al frente de las

32


amenazas emergentes asumiendo que los atacantes ya han aprovechado las

vulnerabilidades o han ganado acceso privilegiado.

3.7 Investigación & e-ciencia

La e-ciencia como se define en [16, p. 4] se entiende como “la actividad científica y de

investigación a la que se aplican nuevos recursos tecnológicos de apoyo con nuevas

posibilidades de comunicación para que los científicos realicen su actividad puedan

comunicar su producción de forma interactiva”.

De la misma manera se indica que la e-ciencia se desarrolla comúnmente sobre los

llamados Los Entornos Virtuales de Investigación (EVI) o VREs por sus siglas en inglés.

Estos VREs “están constituidos por la infraestructura y los servicios digitales que permiten

que la investigación tenga lugar… Actualmente un VRE se ve mejor como un marco en el

que las herramientas, servicios y recursos se pueden conectar. ” [16, p. 5]. En el mismo

documento referenciado se indica que resulta difícil concebir un VRE en una sola institución,

ya que está comúnmente una investigación de este tipo debe abarcar varias organizaciones

o instituciones, se trata de usar los recursos de forma colaborativa con el fin de obtener

resultados de investigación más robustos

Existen diferentes motivos por los cuales un “intruso” o hacker puede estar interesado en

realizar un ataque, pero con respecto a investigación se deduce que las principales razones

se concentrarían en:

• Afectar la imagen del investigador o la institución de la que hace parte

• Sabotaje a investigaciones institucionales

• Apropiarse de investigaciones ajenas

33


3.8 Sistema de Gestión de Seguridad de la Información (SGSI)

Un Sistema de Gestión de Seguridad de la Información (SGSI) o ISMS por sus siglas en

inglés “consiste en políticas, procedimientos, directrices y recursos y actividades asociadas,

administradas en conjunto por una organización, con el fin de proteger sus activos de

información” [4, p. 14], a partir de estos criterios, junto con el análisis y la gestión de riesgos,

la organización debe establecer unos controles que ayuden a alcanzar los objetivos

previstos en al establecer el alcance del SGSI, todo lo anterior dentro de un plan de mejora

continua.

Ciclo PDCA

El ciclo PDCA (Plan, do, check, act), en su equivalencia en español es Planificar, hacer,

verificar y actuar (PHVA), es una estrategia de mejora continua de calidad.

Tradicionalmente utilizado en la ISO/IEC 27001 para implementar un SGSI, es un método

que tiene muchas más aplicaciones, sobre todo en procesos de generación de productos y

servicios. Aunque en la versión más reciente de la ISO/IEC 27001:2013 no se adopta como

el método para la generación del SGSI, su utilización no se considera indebida, únicamente

se ha dado la posibilidad de elegir otros métodos que la organización considere adecuados.

Este proyecto por su parte, se basará en el tradicional PDCA, debido a que es un ciclo de

mejora continua conocido que proporcionará lo necesario para centrar los esfuerzos en el

foco de la investigación que son los controles de seguridad.

34


4 Análisis de estándares de seguridad en Cloud Computing

4.1 Organizaciones relevantes en estandarización de Cloud Computing

“Un estándar es un documento que proporciona requisitos, especificaciones, directrices o

características que se pueden utilizar de manera consistente para asegurar que los

materiales, productos, procesos y servicios son adecuados para su propósito.” [17].

Adicionalmente, se puede decir que un estándar permite por tanto verificar el cumplimiento

de determinados criterios o requisitos mínimos aceptables que se asumen válidos para

quienes lo implementan. Existe gran cantidad de estándares orientados a diferentes

disciplinas o áreas, los hay abiertos, cerrados, aplicables a determinadas regiones o países,

vinculantes, no vinculantes, y dependiendo de si interviene en su elaboración una

organización de estandarización oficial o no, se dividen en estándares de jure y de facto.

Son numerosas las comunidades y organizaciones de estándares técnicos reconocidas,

entre ellas se encuentran 3GPP, ATIS, CISPR, IEC, IEEE, IETF, OpenTravel Alliance,

OSGi, W3C, ISO, ect, sin embargo, y teniendo en cuenta el tema de la presente

investigación, vale la pena destacar algunas que elaboran documentación para el entorno

del Cloud Computing, entre ellas se encuentran las mencionadas en la Tabla 1, y que hacen

parte del listado presentado por la iniciativa Cloud Standardization Coordination (CSC) en

su primera fase, este listado está compuesto por 20 organizaciones. Este listado se redujo

a 15 organizaciones durante la segunda fase de la iniciativa, como se presentará en otro

capítulo.

35


Siglas Nombre

ATIS Alliance for Telecommunications Industry Solutions CEN European Committee for Standarization

CENELEC Comité Européen de Normalisation Electrotechnique CSMIC Cloud Services Measurement Initiative Consortium

CSA Cloud Security Alliance

CSCC Cloud Standards Customer Council DMTF Distributed Management Task Force ENISA European Union Agency for Network and Information Security ETSI European Telecommunications Standards Institute

GICTF Global Inter-Cloud Technology Forum IEC International Electrical Commission

IEEE Institute for the Electrical and Electronics Engineers IETF Internet Engineering Task Force

ISO International Organization for Standardization

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

NIST National Institute for Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards ODCA Open Data Center Alliance

OGF Open Grid Forum

QuEST Quality Excellence for Suppliers of Telecommunication

SNIA Storage Networking Industry Association TIA Telecommunication Industry Association

TMF TeleManagement Forum

TOG The Open Group

Tabla 1. Organizaciones relevantes de estandarización en Cloud Computing [18].

De las anteriores organizaciones, se presentará en la siguiente sección una descripción de

aquellas que se destacan en la publicación de estándares de seguridad para Cloud

Computing. Con lo anterior se busca lograr el propósito de facilitar la selección de controles

de seguridad para las nubes privadas, centrándose en los controles que tienen mayor

impacto para este tipo de entornos. Gráficamente se presenta la idea de la siguiente forma:

36


Figura 5. Distribución de normas de seguridad. Autoría propia.

ISO

A pesar de que casi la totalidad de las normas pertenecientes a la serie ISO 27000 no son

de libre difusión y deben ser compradas para acceder a su contenido, es indiscutible su

importancia en el ámbito de gestión de la seguridad de la información, desde la ISO/IEC

27001:2013 con un enfoque al “modelo tradicional” hasta la ISO/IEC 27017:2014 y la

ISO/IEC 27018:2014 con mayor orientación al manejo de datos en Cloud Computing.

En la encuesta realizada por la ISO a nivel mundial a los organismos de certificación

acreditados, se encontró que número de certificados aprobados a

organizaciones/entidades pasó de 27.536 en el año 2015 a 33.290 en el 2016, lo que

representó un crecimiento del 21%. Se debe tener en cuenta que este certificado tiene una

validez de 3 años. La siguiente tabla presenta información por región.

Estándares de seguridad

informática

Estándares para seguridad en la

nube

Estándares para seguridad en

nubes privadas

37


Region Certificates Africa 224 Central / South America 564 North America 1469 Europe 12532 East Asia and Pacific 14704 Central and South Asia 2987 Middle East 810 Total 33290

Tabla 2. N° de certificados ISO/IEC 27001 por región – Fuente ISO

Vale la pena mencionar que en Sudamérica el país más destacado fue Colombia con 163

certificados.

NIST

Esta agencia del departamento de Comercio de los estados unidos tiene una gran cantidad

de publicaciones, pero en temas de seguridad se destaca la serie SP 800, que son

documentos relacionados con la gestión de la seguridad de la información. A diferencia de

la serie ISO 27000, los documentos del NIST son de libre descarga. Mayores detalles del

NIST se expondrán en otro capítulo, pero se destaca su reconocimiento como autoridad en

los temas asociados a Cloud Computing, sus conceptos son comúnmente referenciados en

investigaciones, publicaciones, normas, etc. Otra de las razones para su selección en el

presente proyecto tiene que ver en la asociación que existe entre los controles de la ISO

27001 y los controles publicados en el SP 800-53 del NIST, de tal forma que se pueden

categorizar los controles para diferentes análisis.

CSA

Esta organización se centra en promover buenas prácticas de seguridad para Cloud

Computing, muchos de sus conceptos son tomados de publicaciones del NIST. Sus

recomendaciones para el área de seguridad se encuentran listadas en su documento

principal denominado “Security Guidance For Critical Areas Of Focus In Cloud Computing”

que consta de 14 dominios. Su principal ventaja es que se encuentra totalmente orientado

a Cloud Computing, de tal forma que complementa con rigurosidad los aportes de las ISO

27001 y el NIST.

38


4.2 Familia ISO 27000

La serie o familia ISO 27000, es un conjunto de estándares reservado por la ISO

(International Organization for Standardization) y la IEC (International Electrotechnical

Commission) que proporciona un marco de gestión en materia de seguridad de la

información para las organizaciones. Los rangos de numeración reservados por ISO van de

la 27000 a 27019 y de 27030 a 27044.

Debido a la relevancia internacional de la serie 27000, se presentaran con mayor detalle

sus características, además, como referente en materia de seguridad, resulta de sumo

interés tener las prácticas recomendadas que pueden ser aplicadas tanto a un centro de

datos tradicional como a uno en el que se proyecte implementar una nube. Dentro de la

familia 27000 se han publicado recientemente dos normas específicas para la nube y sobre

ellas se hará un particular análisis.

Figura 6. Relación entre el SGSI y la familia de estándares ISO [4, p. 21].

La Figura 5 muestra la estructura de los estándares que hacen parte de la serie ISO 27000

y su asociación con el Sistema de Gestión de Seguridad de la Información. A continuación

se hace una descripción de su composición.

39


Vocabulario Estándar

El primer nivel comprende solamente la ISO 27000, su primera versión fue publicada el 1°

de mayo de 2009, posteriormente tuvo versiones en 2012 y 2014. La actual versión fue

publicada en febrero de 2016. En ella se define el vocabulario estándar empleado en la

familia 27000 (definición de términos y conceptos), se hace una introducción a los Sistemas

de Gestión de Seguridad de la Información y una descripción general de los estándares de

la serie 27000

Estándares que especifican requisitos

De este grupo hacen parte la ISO 27001, 27006 y 27009, en ellas los diferentes requisitos

para la implementación de un SGSI, auditoria de certificación del SGSI e inclusión de

requisitos adicionales a la 27001 respectivamente. Es de destacar la importancia de la ISO

27001, por ello se procede a ampliar su información.

4.2.2.1 ISO/IEC 27001:2013 Su primera versión fue publicada en Octubre de 2005, reemplazó el estándar BS7799-2, su

versión más reciente fue publicada en el año 2013. Esta norma “específica los requisitos

para establecer, implementar, operar, monitorear, revisar, mantener y mejorar los sistemas

de gestión de seguridad de la información (SGSI). También se indican los controles de

seguridad de la información a medida de las organizaciones” [4, p. 22]. Todo lo anterior

orientado a implantar un SGSI certificable, este es el único estándar certificable de la familia

ISO 27000.

Normas que describen directrices generales

Este grupo de estándares se caracteriza por brindar información o directrices sobre temas

específicos y está conformado las normas presentadas a continuación, de las cuales se

hace una breve descripción basada en la ISO 27000:

• ISO/IEC 27002: Proporciona lista de objetivos de control y mejores prácticas de

seguridad de la información.

• ISO/IEC 27003: Brinda información para implementación de SGSI enfocado a

procesos.

• ISO/IEC 27004: Ofrece orientación para evaluar la eficacia del SGSI.

40


• ISO/IEC 27005: Da directrices para la gestión de riesgos de seguridad.

• ISO/IEC 27007: Proporciona información sobre realización de auditorías del SGSI.

• ISO/IEC TR 27008: Es un informe técnico que orienta sobre la implementación de

controles.

• ISO/IEC 27013: Brinda orientación sobre la integración de la norma ISO/IEC 27001

y la norma ISO/IEC 20000-1.

• ISO/IEC 27014: Ofrece información relacionada con principios y procesos para

gestión de la seguridad de la información.

• ISO/IEC TR 27016: Informe técnico que proporciona información sobre cómo

establecer el valor de los activos de información.

De los anteriores estándares, se destaca el ISO/IEC 27002, del que se hace un mayor

análisis a continuación debido.

4.2.3.1 ISO/IEC 27002 Los controles de seguridad descritos en ISO/IEC 27002 resaltan las características

generales que deben abordarse y a qué técnicas específicas se pueden aplicar. A diferencia

de la ISO/IEC 27001, este estándar no es certificable, sin embargo, la ISO/IEC 27002

presenta las directrices para cumplir con las recomendaciones del anexo A de la ISO/IEC

27001.

Normas que describen directrices en sectores específicos

En este grupo se encuentran normas ISO de seguridad que están dirigidas a sectores muy

específicos. A continuación se presenta la lista de tales normas y una corta definición según

la ISO 27000:

• ISO/IEC 27010: Esta norma se orienta a la seguridad de la información en las

comunicaciones inter-organizacionales e inter-sectoriales.

• ISO/IEC 27011:

• ISO/IEC TR 27015: Proporciona información para aplicación de controles en

organizaciones de telecomunicaciones.

• ISO/IEC 27017: Esta norma resulta de sumo interés debido a que está orientada al

tema desarrollado en la presente investigación, porque proporciona directrices para

los controles de seguridad de la información aplicables en la nube.

41


• ISO/IEC 27018: Esta norma, igual que la 27017 trata el tema de la nube, pero se

enfoca especialmente a proteger la información de identificación personal (PII) de

acuerdo con los principios de privacidad en la norma ISO / IEC 29100 para el entorno

de computación de nube pública.

• ISO/IEC 27019: Esta norma brinda información sobre controles de seguridad de la

información en procesos de la industria de servicios públicos.

4.2.4.1 ISO/IEC 27017: Esta norma es un código de buenas prácticas para la aplicación de controles de seguridad

de información en sistemas o servicios basados en computación en nube basada en la ISO

27002, a la vez que proporciona controles para proveedores y clientes de servicios en la

nube. Los controles adicionales se relacionan con:

• ¿Quién es responsable de lo que ocurre entre el proveedor del servicio cloud y el

cliente de la nube?

• La eliminación/devolución de activos cuando un contrato se resuelve.

• Protección y separación del entorno virtual del cliente.

• Configuración virtual de la máquina.

• Operaciones y procedimientos administrativos relacionados con el entorno de la

nube.

• Seguimiento de la actividad de clientes en la nube

• Alineación del entorno de la red virtual y cloud.

4.2.4.2 ISO/IEC 27018:2014 Esta norma es un estándar internacional sobre seguridad en la nube, en la que entre otras

cosas protege el derecho a la privacidad de la información de los usuarios y obliga a las

empresas proveedoras a informar sobre el tratamiento que le dan a los datos de sus

clientes.

La norma pretende ser “una referencia para la selección de los controles de protección

información de carácter personal en el proceso de implementación de un sistema de gestión

de seguridad de información basado en la norma ISO / IEC 27001 para un sistema cloud,

42


o como un documento de orientación para las organizaciones para la implementación de

los controles de protección de PII comúnmente aceptados”.

4.3 National Institute of Standards and Technology (NIST)

NIST es una agencia del Departamento de Comercio de los EE.UU, su misión es promover

la innovación en Estados Unidos y la competitividad industrial mediante el avance en la

medición de estándares y tecnología de forma que mejoren la seguridad económica y la

calidad de vida [2, p. 1]. Lo anterior lo hace con la publicación de normas, directrices y

recomendaciones orientadas al área de la seguridad por medio de las siguientes series

técnicas.

Figura 7 . Documentación publicada por el NITS – Clasificación de series técnicas. Autoría propia.

Teniendo presente la figura anterior se procede a hacer una breve explicación de las

publicaciones del NITS y se determinará cuáles son las de mayor interés para una nube

privada orientada a investigación.

Federal Information Processing Standards (FIPS):

“Las normas de procesamiento de información federal son normas expedidas para sistemas

informáticos federales, luego de la aprobación del secretario de comercio de Estados

Unidos. NIST desarrolla estos estándares cuando son solicitados por el gobierno federal y

no existen estándares o soluciones industriales aceptables” [19].

43


NIST Special Publications (SPs):

Las publicaciones especiales del NIST son directrices de seguridad y privacidad,

recomendaciones y materiales de referencia [20].

Information Technology Laboratory (ITL) Bulletins:

Los boletines de información del Laboratorio de Tecnologías de la Información (ITL por sus

siglas en inglés), son resúmenes mensuales de publicaciones de seguridad y privacidad del

NIST.

NIST Special Publication

El NIST utiliza tres subseries conocidas como NIST Special Publication para hacer

publicaciones relacionadas con seguridad de equipo/cibernética/información y directrices,

recomendaciones y materiales de referencia, que según se menciona en [21] tienen los

siguientes enfoques:

4.3.4.1 SP 800 SP 800, Seguridad informática (diciembre 1990-presente): “Es el modo primario de

publicaciones de seguridad de equipo/cibernética/información, directrices,

recomendaciones y materiales de referencia” [21]. Esta serie contiene más de 130

documentos. Dentro de los documentos más destacados se encuentran el Guide for

Conducting Risk Assessments SP 800-30, así mismo los documentos Summary of NIST

SP 800-53 Revision 4, Computer security Incident Handling Guide SP 800-61 y Security

and Privacy Controls for Federal Information Systems and Organizations SP-800-53.

4.3.4.2 SP 1800 SP 1800, Guías prácticas de ciberseguridad NIST (2015-presente): Es una subserie creada

para complementar el SP 800; en ella se tratan objetivos específicos de retos de

ciberseguridad en los sectores público y privado.

4.3.4.3 SP 500 SP 500, Tecnología de sistemas informáticos (enero de 1977 - presente): esta es una

subserie general de TI más ampliamente utilizada por el Information Technology Laboratory

(ITL).

44


Las responsabilidades del NIST en materia de seguridad, fueron designadas por la

legislación FISMA (Federal Information Security Management Act), que es una ley de

estados unidos del año 2002, promulgada con el fin de producir normas y directrices

orientadas a la seguridad de la información. El NIST ha utilizado específicamente la serie

800 para trabajar sobre este tema, en su documentación se destaca la guía “Risk

Management Guide for Information Technology Systems – Recommendations of the

National Institute of standards and Technology” publicado en el año 2002, en él se exponen

medidas para la gestión de riesgo, sin embargo en la documentación del CSRC (Computer

Security Resource Center) se indica que este documento ha sido sustituido y actualmente

está disponible únicamente con fines históricos. Así mismo se menciona que el documento

vigente es Guide for Conducting Risk Assessments, también conocido como Publicación

Especial 800-30 del NIST, publicado en el año 2012, cuyo propósito es proporcionar una

guía para la realización de evaluaciones de riesgo de los sistemas de información federales

y organizaciones, ampliando la orientación dada en la Publicación Especial 800-39 o

Managing Information Security Risk.

NIST Special Publication - Cloud

El Programa de Cloud Computing NIST fue lanzado formalmente en noviembre de 2010

para apoyar el esfuerzo del gobierno federal de Estados Unidos con el fin de incorporar la

computación en nube como un sustituto o mejora de sistema de información tradicional y la

aplicación de modelos en su caso. “El NITS, junto con otros organismos fue designado por

el Director de Información de Estados Unidos para desarrollar actividades orientadas a la

adopción del modelo Cloud. En el marco de estas actividades, el NIST ha venido

desarrollando una serie de publicaciones especiales entre las que se encuentran” [22]:

4.3.5.1 NIST SP 500-291: Cloud Computing Standards Roadmap: Este documento de guía de normas de Cloud Computing fue desarrollado por un grupo de

trabajo (participantes de la industria, gobierno, voluntarios) que compiló normas relevantes

para Cloud Computing y que tienen que ver con asuntos de interoperabilidad, rendimiento,

portabilidad, seguridad y estándares de accesibilidad. La versión actual es resultado de una

tarea continua de revisión. El grupo de trabajo identificó algunas lagunas en diferentes

normas y prioridades de normalización para el entorno Cloud.

45


4.3.5.2 NIST SP 500-292: NIST Cloud Computing Reference Architecture: “Es un documento del NIST que presenta la Arquitectura de Referencia de la Cloud (Cloud

Computing Reference Architecture) y la taxonomía que expone los componentes y

servicios. Los fundamentos para la elaboración del documento fueron, en primer lugar,

desarrollar una arquitectura independiente del proveedor, y segundo, desarrollar una

solución que no impida la innovación mediante la definición de una solución técnica

prescrita”. [23]. En el documento se exponen los elementos centrales del Cloud Computing

para directores de programas de TI y relacionados con cargos afines.

4.3.5.3 NIST SP 500-293: US Government Cloud Computing Technology Roadmap Volume 1, High-Priority requirements to Further USG Agency Cloud Computing Adoption

Este documento es una iniciativa colaborativa del NIST diseñado según [24] para:

• Fomentar la adopción de la computación en nube por las agencias federales y el

apoyo del sector privado.

• Reducir la incertidumbre mediante la mejora de la información disponible para la

toma de decisiones.

• Facilitar un mayor desarrollo del modelo de computación en la nube.

La versión completa del documento consta de tres volúmenes. Este primer volumen es una

hoja de ruta sobre, primero, las prioridades estratégicas y requisitos tácticos que deben

cumplir las agencias del gobierno de Estados Unidos USG (United States Government) para

el modelo Cloud; en segundo lugar, la Interoperabilidad, portabilidad y estándares de

seguridad, directrices y tecnología que debe existir para satisfacer estos requisitos. El

segundo y tercer volumen aún están en versión borrador (Draft) y se están elaborando para

quienes trabajan activamente en estrategia e iniciativas tácticas de cloud computing y guía

para quienes están planeando e implementando soluciones de cloud computing.

46


4.3.5.4 NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing:

El objetivo de este documento es proporcionar una visión general de la nube pública y los

retos en seguridad y la privacidad que supone. “En él se analiza las amenazas, riesgos

tecnológicos y medidas de seguridad para entornos de nube pública y proporciona la visión

necesaria para tomar decisiones relacionadas con tecnología de la información y su

tratamiento” [25].

4.3.5.5 NIST SP 800-145: The NIST Definition of Cloud Computing: En esta publicación especial se realiza una contextualización inicial de la computación en

la nube, encontrándose de forma sucinta, una definición concreta y ampliamente aceptada

de Cloud Computing, así mismo se explican sus principales características, los modelos (o

niveles) de servicio y los modelos de despliegue.

4.4 Cloud Security Alliance (CSA)

El CSA (Cloud Security Alliance) es “una organización sin ánimo de lucro que promueve el

uso de mejores prácticas para proporcionar garantía de seguridad en Cloud Computing y

brindar educación sobre los usos de Cloud Computing para ayudar a asegurar todas las

otras formas de informática.” [26]. La CSA está integrada por un grupo de profesionales de

la industria, las corporaciones, asociaciones y otros actores

En el foro de ISSA (Information Systems Security Association) CISO en Las Vegas, en

noviembre de 2008, nació el concepto de Cloud Security Alliance. Desde allí, Jim Reavis y

Nils Puhlmann esbozaron la estrategia y misión inicial de la CSA. Una serie de reuniones

organizativas con líderes de la industria a principios de diciembre de 2008 terminaron

formalizando la Fundación de la CSA.

El CSA opera un popular certificado de seguridad en la nube, el Security, Trust & Assurance

Registry (STAR) de CSA, un programa de aseguramiento de tres niveles de autoevaluación,

auditoría y monitoreo continuo [27]. Además el CSA lanzó la primera certificación de

seguridad en la nube de la industria en 2010. El Certificate of Cloud Security Knowledge

(CCSK) o Certificado de Conocimiento en Seguridad en la Nube.

47


La versión actual del documento emblema del CSA en seguridad se denomina Security

Guidance For Critical Areas Of Focus In Cloud Computing V4.0. Este documento consiste

de un conjunto de dominios que contienen recomendaciones de las mejores prácticas de

seguridad para Cloud Computing.

Ante la variedad de opciones de despliegues de Cloud y sus combinaciones “ningún

conjunto de controles de seguridad pueden cubrir cualquier tipo de circunstancias. Por ello

las organizaciones deberían adoptar una estrategia de migración a Cloud basada en

análisis de riesgos” [28, p. 8].

Dominio 1: Cloud Computing Architectural Framework

El contenido de este dominio “Marco de Referencia de Arquitectura para Cloud Computing”

se focaliza en una descripción de Cloud computing específicamente adaptada a la

perspectiva concreta de los profesionales de seguridad y de redes TI [29, p. 15].

En este dominio también se hace clara referencia a definiciones del NIST relacionadas con

el entorno cloud, se plantean requisitos de arquitectura, los riesgos de seguridad que

pueden estar vinculados con el concepto de multi-tenancy y presenta un modelo de

referencia donde se identifican varios servicios y arquitecturas cloud a través de una

taxonomía cloud propuesta.

Dominio 2: Governance and Enterprise Risk Management

En este dominio se destaca la referencia que se hace a las estructuras organizativas y a

los procesos para el Gobierno y Gestión de Riesgo Corporativo en Cloud Computing, dentro

de los procesos se concibe por ejemplo la necesidad de procesos de seguridad de la

información escalables, así mismo se resalta la importancia de los acuerdos entre el

proveedor y el usuario para el uso de los servicios, y en general en la forma de administrar

y comunicar el riesgo a los usuarios para entornos cloud públicos especialmente. Se hace

mención del tráfico de información en el apartado que se indica que ”las organizaciones

deben también garantizar una seguridad de la información razonable a lo largo de los flujos

de información, incluyendo a sus proveedores, clientes de sus servicios Cloud y aquellos

socios de negocio con los que trabajen en cualquier modelo de despliegue Cloud [29, p.

32].

48


Dominio 3: Legal Issues: Contracts and Electronic Discovery

Este dominio “trata de facilitar un marco general de aspectos legales que pueden surgir al

trasladar datos a Cloud, algunos aspectos dignos de consideración en los contratos de

prestación de servicios Cloud y las problemáticas específicas que se derivan del eDiscovery

en la legislación occidental” [29, p. 39]

En general, y asociado con la transferencia de datos personales a la nube, en este dominio

se indica la adaptación de medidas legales en el área de seguridad para garantizar la

responsabilidad por parte de las entidades en el manejo de los datos personales de los

usuarios. Por ejemplo se habla de las medidas de protección adoptadas en la región Asia-

Pacífico, en Europa y América, permitiendo conocer que las “normas” que se establecen en

el mundo se adaptan a ubicaciones geográficas y poblaciones que tienen características

comunes.

Dominio 4 Compliance and Audit Management

Este dominio denominado Cumplimiento Legal y Gestión de Auditoría, hace referencia a la

asimilación por parte de administradores de TI y auditores para interpretar las diferentes

legislaciones y su alcance para entornos cloud, de tal forma que se genere la confianza

necesaria que permita acceder a servicios externos. Por ello se indica que los

clientes/usuarios de la nube, deben tener la posibilidad de validar con el proveedor la

seguridad con que cuenta su información.

Resulta interesante la forma en que se expone en [29, p. 49] que son múltiples las

jurisdicciones legales cuando se habla de Cloud (en especial cuando se trata de nubes

públicas), y debido a que parte de las tareas del gobierno corporativo se enfocan en dirigir

sus actividades al cumplimiento legal, este debe revisar que sus procesos y políticas no

entren en conflicto con la parte legal asociada a los servicios del proveedor. Inclusive la

Cloud puede facilitar el Gobierno y cumplimiento legal cuando por ejemplo, se accede a

servicios de una nube pública a los que otras organizaciones más grandes han accedido,

de esta forma se podría tener el mismo nivel de cumplimiento que estas entidades.

49


Dominio 5: Information Management and Data Security

En el dominio de Gestión de la Información y de la Seguridad de los Datos [29, p. 52] se

describe cómo las arquitecturas basadas en cloud han motivado el desarrollo de

alternativas para proteger la información, ya que este modelo involucra el manejo de datos

que no fueron contemplados en el modelo tradicional. Se indica que la gestión de la

información y la seguridad de los datos en la era Cloud demanda tanto estrategias como

arquitecturas técnicas nuevas.

El dominio también proporciona referencias sobre el almacenamiento en las arquitecturas

de información en la nube, mejores prácticas para gestión de información, incluyendo un

ciclo de vida de seguridad de los datos y los controles específicos de seguridad de los datos

y su uso.

En el dominio se presentan las fases del ciclo de vida de la seguridad de los datos, que

tiene las siguientes fases: creación, almacenamiento, uso, compartición, archivado, y

destrucción. Este ciclo de vida, tiene notable importancia cuando se tiene en cuenta la

localización y el acceso de los datos, ya que para el caso del modelo Cloud, ciclos de vida

más pequeños que deben ser tenidos en cuenta para proyectar la gestión de seguridad.

Por ello se incorpora el tema del gobierno de la información, que incluye políticas y

procedimientos para gestionar el uso de la información y en el que se distinguen

características como: clasificación de la información, políticas de gestión de la información,

autorizaciones, entre otras.

Dominio 6: Interoperability And Portability

En este aparte, denominado dominio de Interoperabilidad y Portabilidad, se exponen las

características de la nube en materia de escalabilidad y movimiento de datos o aplicaciones.

En el documento de la CSA, la Interoperabilidad se define como “el requisito necesario para

que los componentes de un ecosistema de Cloud Computing trabajen juntos a fin de

alcanzar el resultado deseado…la Interoperabilidad exige que dichos componentes puedan

ser reemplazados por nuevos o distintos componentes de diferentes proveedores de forma

transparente, sin que el trabajo se vea afectado, como también debería poder realizarse el

intercambio de datos entre sistemas” [29, p. 67].

50


La Portabilidad y la Interoperabilidad resultan por tanto, factores a tener en cuenta cuando

se evalúe la migración a la nube. En este sentido, es de destacar la cumbre de Openstack

realizada en Vancouver en 2015, donde su director ejecutivo, Jonathan Bryce, informó de

los esfuerzos que se están realizando para mejorar la interoperabilidad, y se refleja en el

hecho de que las nuevas versiones de Openstack están orientadas a cumplir esta

característica. Además indicó que se tendrá en cuenta el cumplimiento de los criterios de

interoperabilidad de Openstack para la asignación del logo Openstack Powered.

Dominio 7: Traditional Security, Business Continuity, and Disaster Recovery

En este dominio, denominado Seguridad Tradicional, Continuidad de Negocio y

Recuperación de Desastres, se indica que uno de los objetivos es “... aportar a los CSP

(Cloud Service Provider) un entendimiento común de la seguridad tradicional (seguridad

física) en los servicios de Cloud. La seguridad tradicional puede ser definida como las

medidas tomadas para garantizar la seguridad de la información, personal y material contra

robo, espionaje, sabotaje u otros daños.” [29, p. 77]. Así mismo se destaca la mención de

temas relacionados con seguridad física, asignación de responsabilidades, sistemas de

detección, autenticación, control de acceso de personal, localización de la infraestructura,

análisis de riesgo, planes de contingencia, documentación técnica, continuidad del negocio,

recuperación de desastres y la posibilidad de los clientes para evaluar estos aspectos.

Dominio 8: Data Center Operations

Este dominio hace referencia a las actividades en el CPD (Centro de Proceso de Datos) o

Data Center. Se indica que el proveedor debe llevar el Data Center más allá del uso de la

virtualización y adaptarlo para el uso de la nube. También se presentan algunos controles

de seguridad los cuales recomiendan que estén asociados a la misión de la organización,

se hace mucho énfasis en la función de las aplicaciones que se ejecutan en el Data Center

con el fin de adoptar medidas de seguridad adecuada que protejan estas aplicaciones.

Dominio 9: Incident Response

El dominio de respuesta a incidentes indica que “El Cloud computing no necesita un nuevo

marco conceptual para la respuesta ante incidentes; sino que requiere que la organización

adapte adecuadamente sus programas, procesos y herramientas de respuesta ante

51


incidentes existentes al entorno operativo específico que va a abrazar” [29, p. 96]. Por tal

razón en el capítulo se menciona cuáles son los retos en esta área, debido a la agrupación

de recursos en el modelo Cloud como pueden ser la detección de los incidentes o el análisis

forense en un ambiente tan dinámico.

Dominio 10: Application Security

Este dominio dedicado a la seguridad de aplicaciones tiene mucho que ver con los modelos

de servicio de PaaS y SaaS, centrándose en la rigurosidad de la seguridad para desarrollar

aplicaciones, por tal razón se tratan temas como: buenas prácticas para el ciclo de vidad

de desarrollo de aplicaciones, arquitectura de seguridad de aplicaciones cloud, gestión de

autorización de aplicaciones, monitorización de aplicaciones cloud, entre otros

relacionados.

Dominio 11: Encryption and Key Management

En este dominio, relacionado con el cifrado y la gestión de claves se trata de identificar en

qué casos se debería cifrar la información, teniendo en cuenta la complejidad que tiene los

recursos de la nube, así mismo se revisan los procesos asociados con e cifrado y la gestión

de claves.

Dominio 12: Identity, Entitlement, and Access Management

El domino trata los temas de identidad, asignación de derechos y gestión de accesos en el

entorno cloud, donde las múltiples fuentes de identidad llevan a tener algunas

consideraciones para la administración de estos elementos. El dominio cubre aspectos

como la arquitectura de la identidad para Cloud, nivel de confianza con identidades y

atributos, aprovisionamiento de cuentas en sistemas Cloud, la identidad y protección de

datos, entre otros.

Dominio 13: Virtualization

En este dominio se la importancia de la virtualización para el concepto de Cloud y se

mencionan las recomendaciones para proteger los problemas de seguridad que se

encuentran en el sistema operativo que se ejecuta, los de la capa del hipervisor, y los demás

52


problemas de seguridad inherentes a la virtualización. También se hace referencia a la

administración y migración de máquinas virtuales, y algunos ataques conocidos los cuales

deben tenerse presentes para la protección de la nube.

Dominio 14: Security as a Service

El domino de seguridad como servicio menciona como la nube ha llevado a la centralización

de los recursos de seguridad, también se indica la importancia de elaborar los Acuerdos de

Niveles de Servicio (ANS) con el fin de compromisos claros entre el proveedor y el cliente

en relación con los servicios ofrecidos. Otro tema que se trata es el SecaaS (Security as a

Service), concepto que está asociado con la prestación de servicios para empresas desde

la nube.

53


5 Propuesta de Modelo de seguridad

El modelo general propuesto se basa en el ciclo PHVA (Planear-Hacer-Verificar-Actuar) que

se ajusta a los lineamientos del estándar ISO/IEC 27001:2013. El planteamiento de este

modelo se completa con las especificaciones de la ISO/IEC 27018, ISO/IEC 27019, los

dominios establecidos por la CSA y el NIST, conforme a lo indicado en 4.1.

La propuesta incluye un modelo para evaluar los controles de seguridad seleccionados en

el proceso con el fin de estimar la distancia de un estado ideal de seguridad de la nube

privada en términos de controles de seguridad. En el siguiente capítulo se hará un caso de

estudio aplicado en el CECAD de la Universidad Distrital.

Considerando la constante verificación y actualización de normas, recomendaciones y

buenas prácticas de seguridad informática publicadas por las organizaciones

internacionales, es preciso indicar que la selección de controles puede ser adaptada o

ampliada siguiendo el mismo procedimiento descrito en la metodología propuesta en el

proyecto.

5.1 ¿A quiénes va dirigido?

El modelo de seguridad planteado está dirigido principalmente a organizaciones que hayan

decidido implementar una nube privada con infraestructura propia y necesiten identificar los

requisitos mínimos de seguridad de la información para sus servicios ofrecidos. Así mismo

resultará de interés para aquellas organizaciones en las que se haya implementado una

nube privada sin tener en cuenta los factores de seguridad necesarios para este entorno.

Debido a que el presente proyecto se enfoca a plataformas colaborativas de investigación,

se hace mayor énfasis en controles y ejemplos relacionados con la protección de

información asociada a proyectos de investigación que se desarrollan en nubes privadas.

54


La propuestas es válida para dos enfoques; uno en el que se asume que la organización

ha definido un modelo de servicio cloud pero no lo ha implementado (este proyecto no

consiste en la definición del modelo cloud, sino en su protección), y el otro escenario en el

que la nube ya se encuentre en producción.

5.2 Disposición del entorno y preparación

Esta etapa involucra la sensibilización de los altos cargos con respecto de la importancia

de contar con un modelo de seguridad que genere confianza en los usuarios de la nube

privada. Los directivos deben estar conscientes de que no solamente se debe invertir

recursos en infraestructura y servicios, sino que es indispensable contemplar capital para

su protección. De nada serviría por ejemplo que un investigador utilizara los recursos de la

nube durante meses si es alto el riesgo de pérdida, adulteración o sustracción de datos

obtenidos en su investigación durante este periodo. Descuidando estos aspectos, la

organización se puede exponer a la afectación de su imagen, a pérdidas económicas por

demandas u otros problemas legales, e inclusive podría estar perdiendo el reconocimiento

que le podría representar un importante resultado de investigación obtenido a partir de los

servicios prestados en sus instalaciones.

Para la implementación del modelo de seguridad es indispensable contar con algunos

perfiles o roles que desempeñarán tareas específicas en la consecución de este objetivo.

Los perfiles aquí propuestos son los perfiles comúnmente recomendados por distintas

organizaciones para temas de seguridad informática. Debido a su tamaño, en algunas

organizaciones no se cuenta con la cantidad de personas que pueda ser asignado a los

diferentes roles sugeridos, en tal caso se deberá determinar un/unos responsables que

puedan asumir más de una tarea. La siguiente gráfica representa los principales perfiles y

su estructura:

55


Figura 8 . Perfiles de seguridad informática en las organizaciones. Autoría propia.

La gráfica anterior es una representación típica de la estructura presente en organizaciones

robustas en términos administrativos, técnicos y económicos; sin embargo, se recomienda

para organizaciones de menor envergadura tener asignadas las funciones de al menos los

tres primeros perfiles de la estructura, como se presenta en la siguiente tabla y cuyas

funciones principales se han recopilado de diferentes fuentes, entre ellas el MinTIC de

Colombia.

Perfil

Funciones principales Comité de seguridad informática o Director ejecutivo/ Chief Executive Officer (CEO)

• Vigilar el desarrollo, documentación e implementación del

programa de seguridad en la nube.

• Determinar e integrar los procesos de seguridad con otros

procesos estratégicos de la organización.

• Verificar el cumplimiento de los requerimientos de seguridad.

• Proponer estrategias y soluciones específicas para la

instauración de los controles de seguridad.

• Supervisar la implementación de las políticas de seguridad

informática establecidas.

56


Director de Información / Chief Information Officer (CIO)

• Desarrollar las políticas y controles de seguridad.

• Planificar, organizar, coordinar que el programa de seguridad

se mantenga

• Apoyar el cumplimiento de los requerimientos de seguridad

aplicables.

• Aprobar las estrategias para el tratamiento de riesgos.

Jefe de seguridad de la información / CSO

• Evaluar los riesgos de forma periódica y su impacto

• Desarrollar planes que proporcionen seguridad en redes y

sistemas

• Apoyar la capacitación en temas de seguridad a usuarios de la

nube

• Evaluar periódicamente las políticas de seguridad

establecidas.

• Aplicar la debida respuesta al tratamiento de incidentes.

• Verificar el avance de la implementación de tratamientos de

control y tratamiento de riesgos.

Tabla 3. Perfiles básicos para implementación de modelo de seguridad. Autoría propia.

5.3 Establecer situación inicial

Antes de iniciar con el ciclo PHVA se debe tener claras las siguientes etapas que permitirán

tener una visión general de la organización: Reconocimiento de la estructura

organizacional, verificación de políticas existentes y entrevistas o encuestas a los

encargados de la infraestructura y seguridad.

57


Figura 9. Etapas para determinar la situación inicial de seguridad en la organización. Autoría propia

Reconocimiento de la estructura organizacional

La claridad en la estructura organizacional permitirá establecer con mayor facilidad los roles

y responsabilidades dentro del Sistema de Gestión de Seguridad de la Información, así

como también definir la ubicación del “gobierno de seguridad de la información” dentro de

la estructura. Para facilitar la revisión de la estructura de la organización se debe

inspeccionar su organigrama, donde deberían visualizarse los departamentos existentes,

las relaciones y jerárquicas.

Dentro de los aspectos que se deben considerar para determinar o asignar los roles de

seguridad dentro de la organización, se encuentra su tamaño y el presupuesto para el

personal que se hará cargo de la implementación del SGSI, de aquí la importancia de

demostrar la necesidad de proteger la información a los cargos directivos.

Verificación de políticas y controles de seguridad existentes

“La comprensión de las políticas, procedimientos y controles técnicos utilizados por un

proveedor de la nube es un requisito previo para evaluar los riesgos de seguridad y

privacidad involucrados” [25]. Lo más común es que una organización cuente con unas

políticas de seguridad establecidas, sin embargo, si la infraestructura de su(s) centro(s) de

58


datos se basan en el modelo tradicional, y se decide migrar a un modelo cloud, estas

políticas pueden estar omitiendo factores de riesgo inherentes a los nuevos servicios que

se ofrecerían. Así mismo una política que en el modelo tradicional puede parecer idónea,

podría limitar los mismos servicios. Si la organización es por ejemplo es una institución de

educación superior, no es de extrañar que cuente ya con unas políticas en las que se limiten

o restrinjan en su totalidad el acceso y asignación de permisos privilegiados sobre los

recursos de cómputo a estudiantes y docentes investigadores, en otros casos el acceso a

esto recursos puede requerir de largos trámites y aprobaciones. En todo caso las anteriores

características entran en discordancia con el modelo cloud, la organización (proveedor)

tiene obviamente serias responsabilidades con la seguridad, pero el usuario debe tener

facilidades para hacer uso de los servicios, por ello también deben quedar claras las

responsabilidades en temas de seguridad asociadas a los privilegios que obtiene el usuario.

La revisión de los controles de seguridad debe tener en cuenta estos aspectos y, si se hace

compleja la verificación de las políticas y controles existentes, la organización puede optar

por definir unas políticas y controles de seguridad específicas para la infraestructura que

será utilizada en la nube privada y para los servicios ofrecidos.

5.3.2.1 Recopilación de documentación Toda documentación de controles, políticas, auditorías y en general cualquier documento

de la organización relacionado con seguridad de la información debe ser revisado en busca

de datos relevantes que permitan establecer su situación actual en esta área. Esto ayudara

a tomar decisiones en la instauración de los controles y del modelo de seguridad en

general.

Realización de encuestas

Una forma de conocer el estado y uso de la infraestructura consiste en la realización de

entrevistas o encuestas al grupo de personas encargadas del funcionamiento del Centro de

Datos. Si la nube aún no se ha implementado, las encuestas permitirán establecer el

conocimiento que tienen del proyecto los administradores y su rol en la implantación; por

otro lado, si las encuestas se realizan al personal de una nube ya implementada, con ellas

se tendrá una primera aproximación para identificar fortalezas y falencias existentes. Las

siguientes son las temáticas propuestas para las encuestas:

59


• Información básica de red: Es necesario obtener una visión general del

funcionamiento de la red, su diseño, por esta razón se recomienda realizar

preguntas a los administradores de red en aspectos relacionados con diagramas de

red, políticas de conectividad, uso del firewall, métodos de conexión remota,

opciones para transferencia de datos, etc.

• Autenticación: Se debe indagar sobre el sistema de autenticación de usuarios

internos y externos para la administración o el uso de la infraestructura, así mismo

se debe tener claridad y completo control sobre el proceso llevado a cabo para dar

acceso a los usuarios a los servicios de la nube y los permisos que obtienen.

• Control y monitoreo: Se debe identificar cuáles son las herramientas de monitoreo

utilizadas e indagar sobre su administración y las acciones que se pueden

desencadenar a partir de los reportes generados.

• Formación y conocimiento: Se debe verificar si existen o se proyectan programas

de divulgación y capacitación en temas de seguridad de la información, tanto al

personal que administra la nube, como a los usuarios finales que hacen uso de

los servicios provisionados. Así mismo se debe indagar a todos los usuarios

sobre su conocimiento acerca de las políticas o directrices de seguridad

existentes.

5.4 Definir el alcance

La organización deberá definir el alcance del SGSI y preparar un plan de acción para

implementarlo. El alcance debe contemplar procesos, ubicación, tecnología y activos de

la organización. Adicionalmente su objetivo debe ser definir la información que se protegerá.

Una de las razones más importantes para definir el alcance adecuado para el SGSI es que

si a futuro se desea optar por una certificación, el auditor verificará que todo lo planteado

en el alcance del SGSI se cumple. Por tal razón el alcance definido debe ser un alcance

viable.

60


5.5 Análisis de riesgos y vulnerabilidades

El análisis de riesgos es “una aproximación metódica para determinar el riesgo siguiendo

unos pasos pautados “[30]. En este proyecto se utilizó la metodología MAGERIT

(Metodología de Análisis y Gestión de Riesgos de IT), elaborada por el Consejo Superior

de Administración Electrónica de España, cuyo uso facilita el estudio de los riesgos de los

sistemas de información, es un documento de carácter público y su aplicación ha sido

ampliamente extendida y aceptada.

Identificación y valoración de activos

En esta etapa se busca conocer los activos que hacen parte de la infraestructura sobre la

que está implementada o se implementará la nube privada y su valor; este valor no

necesariamente está asociado al tema económico, por ello se manejan los conceptos de

valoración cuantitativa y valoración cualitativa. Para realizar estas evaluaciones es

necesario hacer un inventario de equipos y en algunos casos el registro de software y los

principales servicios que disponibles. Vale la pena aclarar que esta etapa se basa en el

procedimiento de un caso de estudio previo [36] como guía.

El primer punto de este análisis consiste en generar una tabla de calificación para evaluar

cada activo, estas tablas se elaboran conforme a los criterios de cada organización.

Para la valoración cualitativa se sugieren los valores representados en la Tabla 4.

Valoración Cualitativa Sugerida Escala de Valoración Valor Descripción

MB: Muy Bajo 1 Irrelevante B: Bajo 2 Baja Importancia

M: Medio 3 Importante A: Alto 4 Altamente importante

MA: Muy alto 5 De vital importancia Tabla 4. Valoración cualitativa de activos. Autoría propia

Basados en los ítems de la Tabla 4, y con la lista de activos del Centro de Datos, se

determina con el equipo de trabajo cual es el valor que mejor se ajusta a cada uno de los

activos.

61


Por otro lado, la valoración cuantitativa que correspondiente a la Tabla 5 consiste en

establecer unos rangos que contemplan el valor de los activos. En este caso queda bajo el

criterio de la organización establecer el rango de valores. Los valores en pesos publicados

en la tabla son solamente a manera de ejemplo:

Valoración Cuantitativa Sugerida Escala de Valoración Valor Valor en pesos $ MB: Muy Bajo 1 0 a 5.000.000 B: Bajo 2 5.000.001 a 10.000.000 M: Medio 3 10.000.001 a 20.000.000 A: Alto 4 20.000.001 a 40.000.000 MA: Muy alto 5 40.000.001 o más

Tabla 5. Valoración cuantitativa de activos. Autoría propia

Posteriormente se hace una valoración total que corresponde a la ponderación de la

valoración cualitativa y la cuantitativa, con porcentajes sugeridos del 70% y 30%

respectivamente. En todo caso el porcentaje se deja a criterio del proveedor, pero se

recomienda dejar siempre con mayor porcentaje la valoración cualitativa. Con los datos

obtenidos se procede a identificar cuáles son los activos más importantes. En la Tabla 6 se

observa el formato recomendado y algunos valores de ejemplo

ACTIVOS MAS VALORADOS ACTIVO VALORACIÓN

CUALITATIVA VALORACIÓN

CUANTITATIVA VALORACIÓN

TOTAL Activo 1 5 5 5.0 Activo 2 5 5 5.0 Activo 3 4 5 4.4 Activo 4 4 5 4.4 Activo 5 4 3 3,6

Tabla 6. Valoración total de activos

Análisis de riesgos

Uno de los procedimientos estipulados en la Metodología Magerit más destacados es la

realización de una matriz de riesgos por activo. Con la información obtenida en el paso

anterior respecto a la Identificación y Valoración de Activos se procede a realizar un Análisis

de Riesgos de cada uno de estos activos, para ello se establecen las vulnerabilidades de

los activos Centro de Cómputo y las potenciales amenazas sobre ellos.

62


5.5.2.1 Valoración de riesgos El valor de los riesgos dependerá en primer lugar del valor de la Vulnerabilidad (probabilidad

de ocurrencia de la amenaza) y en segundo lugar del valor del Impacto (magnitud del daño)

sobre los activos de la organización o centro de datos.

La vulnerabilidad de los activos es la probabilidad de ocurrencia de una amenaza y toma

valores entre 0 y 1. Estos valores son estimados considerando principalmente el tipo de

amenaza, el interés por parte de los individuos externos, la percepción de los

administradores de los sistemas de información y los incidentes que se hayan presentado

con anterioridad.

CRITERIOS DE VALORACIÓN DE VULNERABILIDAD

Valor Criterio

0 a 0,25 Baja probabilidad de que se presente incidentes en la nube, lejana la

posibilidad de que la amenaza se haga efectiva.

0,26 a 0,5 Mediana probabilidad de que se presenten incidentes, la amenaza es

latente.

0,51 a 0,75 Mediana probabilidad de que se presenten incidentes; alguna vez se ha

llegado a presentar el incidente o es muy probable que se presente.

0,76 a 1 Alta probabilidad de que se presenten incidentes o los incidentes se

presentan muy frecuentemente y no existen controles en la

organización.

Tabla 7. Criterios de Valoración de vulnerabilidades. Autoría propia.

Con el fin de facilitar la evaluación, se recomienda que los criterios para la valoración del

Impacto en la infraestructura de la nube tengan valores entre 1 y 5. Con estos elementos

definidos (valores de vulnerabilidad y de impacto) se puede definir la valoración de riesgos

mostrados en la Tabla 8. Se debe tener presente que el riesgo se define de la siguiente

forma: 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 = (𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑅𝑅𝑉𝑉𝑉𝑉𝑉𝑉𝑅𝑅𝑉𝑉𝑅𝑅𝑉𝑉𝑉𝑉𝑉𝑉)(𝐼𝐼𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼𝑅𝑅)

63


VALORACIÓN DE RIESGOS

RIESGO VULNERABILIDAD

0,25 0,5 0,75 1

IMPACTO

5 1,25 2,5 3,75 5

4 1 2 3 4

3 0,75 1,5 2,25 3

2 0,5 1 1,5 2

1 0,25 0,5 0,75 1

Tabla 8. Valoración de riesgos

Al obtener el valor del Riesgo se ha determinado con color rojo el rango de riesgos con

estado Crítico, con color amarillo los de estado Grave, con color verde los de riesgo

Moderado y con color blanco los Tolerables. La asignación de estos estados se acuerda

junto con el equipo encargado de la administración del centro de cómputo.

ESTADOS Y VALORES DE RIESGO

Clase Valoración Cualitativa

Valoración Cuantitativa

Critico Muy Alto 2,6 a 5 Grave Alto 1,6 a 2,5

Moderado Medio 0,76 a 1,5 Tolerable Bajo 0,25 a 0,75

Tabla 9. Estados y valores del riesgo

64


5.5.2.2 Matriz de riesgos Luego de definir estos criterios básicos, se procede a realizar la matriz de riesgos, que

consiste en evaluar los riesgos en los activos del centro de datos que soporta la nube.

MATRIZ DE RIESGOS POR ACTIVO

ACTIVO AMENAZA VULNERABILIDAD

Prob

abili

dad

de O

curr

enci

a (P

O)

IMPACTOS

Valo

r to

tal d

el im

pact

o

Va

lor d

el ri

esgo

Tipo de Riesgo

Técnico Organizacional

Perd

ida

de C

onfid

enci

alid

ad

Perd

ida

de In

tegr

idad

Pe

rdid

a de

Dis

poni

bilid

ad

Perd

idas

Eco

nóm

icas

Afe

ctac

ión

de Im

agen

Activo 1 Amenaza

identificada Vulnerabilidad identificada

Crítico, grave,

moderado, tol

Activo 2 Amenaza

identificada Vulnerabilidad identificada

Crítico, grave,

moderado, tol

… … … .. .. . . … … … … …

Tabla 10. Matriz de riesgo por activo – Autoría propia

La matriz propuesta en la Tabla 10 toma valores de la Tabla 7, y la Tabla 8. Se establece

el impacto que tendría de hacerse efectiva la amenaza en criterios técnicos y

organizacionales; con el promedio de ellos se determina el valor total de impacto y, a partir

de este podrá obtenerse el valor de riesgo, así como su clasificación verificando su rango.

5.6 Modelo propuesto para determinación de controles de seguridad y gestión de riesgos

Se propone un modelo para seleccionar controles de seguridad idóneos para una nube

privada, estos controles estarán basados en estándares y recomendaciones de

organizaciones internacionales reconocidas en publicar documentación sobre seguridad de

la información. Los controles serán evaluados a partir de las respuestas a preguntas

relacionadas con los criterios de seguridad seleccionados, teniendo presente

características relevantes para e-ciencia.

65


Determinación de controles de seguridad basados en normas internacionales para una nube privada.

Existe una amplia variedad de organizaciones con autoridad reconocida en la elaboración

de estándares, normas o patrones para determinar unas mínimas pautas en la realización

de actividades o la elaboración de productos, y cuya adopción por parte de las empresas o

entidades permite identificar con mayor facilidad criterios de implementación o desarrollo

en un área específica. En temas de TI también se destacan varias organizaciones que

publican estándares reconocidos, sin embargo, como se indica a continuación, la “fama” de

un estándar no necesariamente lo hace siempre aplicable.

En relación con temas de legislación contractual en [3, p. 37] se hace referencia a que

ocasionalmente entran en conflicto planes desarrollados en materia privacidad y protección

de datos diferentes países. Por ello se recomienda no solo en lo que concierne a la

protección de datos, sino también a otros controles que se desee implementar, verificar que

se cumple con la legislación del territorio. Para una nube privada esto no resulta tan crítico

como para una nube pública, ya que en una nube pública el proveedor puede estar en un

país externo en el cual se permite hacer determinado uso de los datos de los clientes que

no necesariamente estarán permitidos en sus países de origen. Sin embargo es bueno

tener presente lo anterior para nube privada orientada a temas de investigación, debido a

que seguramente se presentarán casos en los cuales haya transferencia de datos de

investigación a otros países. Esto resultaría mucho más preocupante si los datos de

investigación involucran por ejemplo datos sensibles de una población o conjunto de

personas que hagan parte de la investigación. En conclusión, los controles que se

seleccionen siguiendo este modelo propuesto deben tener presentes los requisitos legales

aplicables que variarán enormemente en función de las distintas jurisdicciones, entidades

jurídicas y marcos involucrados.

Los siguientes son los casos en los que se debe identificar requisitos legales a tener en

cuenta para validar la aplicabilidad de controles o normas.

66


Figura 10. Jurisdicciones, entidades jurídicas o marcos involucrados en la aplicabilidad de requisitos legales [3, p. 37]

En los últimos años, en el área de Cloud Computing han surgido (y continúan

actualizándose), una gran cantidad de normas, recomendaciones y especificaciones

publicadas por diferentes organizaciones que divulgan estándares técnicos reconocidos.

Ello se refleja en el lanzamiento en el año 2012 de la iniciativa Cloud Standardization

Coordination (CSC), impulsada por la Comisión Europea (CE) y el Instituto Europeo de

Normas de Telecomunicaciones (ETSI). A esta iniciativa se vincularon diferentes actores

de la industria de la nube y diferentes organizaciones interesadas en trabajar en la

consolidación de informes relacionados con la estandarización en Cloud Computing. De los

resultados de su segunda fase, realizada en el año 2015, se presenta a continuación la lista

de 16 organizaciones consideradas relevantes para la elaboración de normas y

certificaciones de Cloud Computing.

Organización Nombre ATIS Alliance for Telecommunications Industry Solutions CSA Cloud Security Alliance

DMTF Distributed Management Task Force ETSI European Telecommunications Standards Institute

GICTF Global Inter-Cloud Technology Forum IEC International Electrotechnical Commission IEEE Institute for Electrical and Electronics Engineers ISO International Organization for Standardization

ITU-T ITU Telecommunications Standardization Sector NIST National Institute for Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards ODCA Open Data Center Alliance

67


OGF Open Grid Forum SNIA Storage Networking Industry Association TIA Telecommunication Industry Association

TMF TeleManagement Forum Tabla 11. Organizaciones relevantes en desarrollo de normas y certificaciones Cloud [31].

De esta tabla, y según lo determinado en 4.1 se toman los controles y recomendaciones de

normas de la ISO 27000, publicaciones del NITS y del documento principal del CSA.

La ISO 27001 aunque está diseñada para crear la estructura de la seguridad de la

información, no es un documento suficientemente robusto en cuanto a la conceptualización

de los controles presentes en ella, por ello existe la ISO 27002, documento que contiene

los mismos controles del Anexo A de la ISO 27001, pero con mayor especificación y

precisión de su implementación. En la ISO 27001 tampoco se tiene claridad sobre el grado

de “profundidad” a la hora de trabajar en un control determinado, y es que no se trata

solamente de aplicar un control con el fin de cumplir con la norma, se puede ser estricto o

no a la hora de hacerlo. En este sentido el uso de las publicaciones del NIST y su

metodología pueden brindar mayor coherencia con el grado de rigurosidad de los controles.

5.6.1.1 Categorización de la información del Centro de Datos La primera labor consiste en categorizar el tipo de información que se utiliza en el Centro

de Datos, para ello se hace uso del FIPS 199 que nos ofrece un método para la realizar

esta tarea. Esta norma del NIST define tres niveles de potencial impacto en las

organizaciones en caso de una eventual violación de la seguridad que afecte la integridad,

disponibilidad o confidencialidad de la información.

En la norma se considera que puede existir un impacto “bajo” cuando se afecta la Integridad,

Disponibilidad o Confidencialidad (CIA por sus siglas en inglés) de la información de forma

limitada en las operaciones de la organización, activos organizacionales o individuos; es

decir, cuando la adversidad podría causar daños menores reduciendo la eficacia de las

funciones. Por otro lado se considera que el impacto es “medio” cuando se determina que

la vulneración en cualquier aspecto de la CIA puede afectar seriamente en las operaciones

de la organización, activos organizacionales o individuos, reduciendo considerablemente el

desempeño de las funciones de la organización u ocasionando pérdida financiera

significativa. Finalmente se determina que existe impacto “alto” cuando cualquier afectación

negativa en la CIA podría implicar un efecto grave o catastrófico en la organización o los

68


individuos, dentro de lo que se encuentran situaciones como la incapacidad de que la

organización desempeñe sus funciones principales, daños en sus bienes, pérdida financiera

importante o daños graves o catastróficos a las personas.

La categoría de seguridad o Security Category (SC) estará asociada al tipo de impacto en

la confidencialidad, integridad y disponibilidad, representándose de la siguiente forma:

𝑺𝑺𝑺𝑺 𝑅𝑅𝑉𝑉𝑖𝑖𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝐼𝐼𝑅𝑅𝑅𝑅𝑉𝑉 𝐼𝐼𝑡𝑡𝐼𝐼𝑅𝑅 = {(𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒊𝒊𝒊𝒊𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼)}

Donde los valores aceptables para el impacto potencial son: bajo, medio, alto y NA;

aclarando que el único criterio que puede tomar el valor de no aplicable es 𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄.

Este método establecido por el NIST contempla que se determinen los valores de impacto

para la confidencialidad, integridad y disponibilidad de todos los sistemas de información

de una organización, no obstante, teniendo en cuenta que estos valores pueden no ser los

mismos, se dará prioridad al nivel más alto de todos los sistemas de información evaluados.

En definitiva, para establecer el nivel de impacto y la línea base de control “se considera un

sistema de bajo impacto a aquel en el que los tres objetivos de seguridad son bajos;

moderado o medio cuando al menos uno de los objetivos de seguridad es moderado y

ningún objetivo de seguridad es mayor que moderado; y finalmente, un sistema de

información se considera de alto cuando al menos un objetivo de seguridad es alto” [32].

Este método no es aplicable únicamente para sistema de información. En [5, p. 3] se indica

que la categoría de seguridad de un tipo de información puede asociarse tanto a la

información del usuario como a la información del sistema, y que el establecimiento de una

categoría de seguridad apropiada de un tipo de información requiere esencialmente

determinar el impacto potencial para cada objetivo de seguridad asociado al tipo de

información particular. La presente propuesta de modelo de seguridad tiene un enfoque

orientado a investigación, por tal razón la categorización se debe hacer hacia información

investigativa, quedando expresado de la siguiente forma:

69


𝑺𝑺𝑺𝑺 𝑅𝑅𝑉𝑉𝑖𝑖𝑅𝑅𝑅𝑅𝐼𝐼𝑅𝑅𝑅𝑅𝑉𝑉𝐼𝐼𝑅𝑅𝑖𝑖𝑅𝑅 𝑅𝑅𝑉𝑉𝑖𝑖𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝐼𝐼𝑅𝑅𝑅𝑅𝑉𝑉

= {(𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒊𝒊𝒊𝒊𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼)}

Evaluando los criterios se tiene:


= {(𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄,𝐻𝐻𝐼𝐼𝐻𝐻𝐻𝐻), (𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒊𝒊𝒊𝒊𝒄𝒄𝒄𝒄𝒄𝒄,𝐻𝐻𝐼𝐼𝐻𝐻𝐻𝐻), (𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄,𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑅𝑅𝑀𝑀𝑀𝑀𝑀𝑀)}

De lo anterior se obtiene que el nivel de la categoría de seguridad es “alto” y será la pauta

a tener como referencia en los siguientes pasos del proceso de determinación de controles

necesarios para mitigar los riesgos que se hayan identificado.

5.6.1.2 Selección de controles de seguridad para la nube privada

Para una organización la gestión de los recursos en la nube requieren de cierto

conocimiento y esfuerzo, por ejemplo si una organización utiliza una nube pública,

designará a personas con conocimiento en el área para administrar los recursos y delegará

al proveedor gran parte de la responsabilidad, mientras que en una nube privada la

organización debe asumir el mantenimiento y salvaguardia de toda la infraestructura,

comenzando por los recursos físicos que la conforman, lo que implica a su vez la

contratación de personal que se dedique a ello y personal especialmente capacitado para

la administración y mantenimiento de la nube. Por tal razón dentro dela selección de

controles basados en las normas propuestas (ISO, NIST, CSA), se toman varios controles

destacados, ya sea por su evidente relevancia o porque coinciden en más de una norma.

De hecho la seguridad de una nube privada tiene como base una buena implementación

de la seguridad tradicional en lo referente a seguridad física de los recursos que la soportan,

que viene a ser reforzada por controles de seguridad que se especializan en las

características de la nube. El planteamiento propuesto se representa en la siguiente

imagen:

70


Figura 11. Composición de los controles de seguridad seleccionados. Autoría propia

Con base en lo anterior, los siguientes serían los aportes de cada norma seleccionada para

la seguridad de la nube privada:

Controles ISO 27001

La ISO 27001 es un estándar de seguridad ampliamente reconocido, en su versión del año

2013, período en el que ya el concepto de la Cloud estaba consolidado, se presentaron

cambios en el número de controles y dominios con respecto a la versión del año 2005 (de

11 dominios aumentó a 14 y de 133 controles se redujo a 114), sin embargo su enfoque

continúo siendo general y a la fecha tanto para la seguridad en ambientes tradicionales

como en entornos Cloud su certificación continúa siendo garantía para la confianza de los

usuarios, no obstante en el año 2014 la ISO publicó las normas ISO/IEC 270017 e ISO/IEC

27018 que detallan controles sobre servicios Cloud y protección de datos personales. Por

esta razón se seleccionaron los controles y recomendaciones más importantes de estas

normas para una nube privada (ver Anexo A).

Controles ISO 27001

Dominos CSAControles NIST SP 800-53

Seguridad Nube

Privada

71


Buenas prácticas del CSA

Como se ha indicado en 4.4, el “Security Guidance For Critical Areas Of Focus In Cloud

Computing” es el documento insignia de la Cloud Security Alliance (CSA) en la que se

encuentran catorce dominios de seguridad con recomendaciones tanto para Cloud pública

como para Cloud privada. Este documento en conjunto con los controles de seguridad de

la ISO 27001 conducen a una herramienta robusta para la determinación de la seguridad

de una nube privada, el reto está en la elección adecuada de las recomendaciones y

controles que se puedan enfocar a una nube privada, debido a una organización la puesta

en marcha de un entorno Cloud en su infraestructura puede estar limitada en recursos para

adoptar la totalidad de criterios presentes en diferentes normas (Ver Anexo B).

Controles del NITS

En tercer lugar se encuentra el NITS, cuyos controles relevantes pueden reaccionarse con

los de la ISO. En [33, p. 408] y en el Anexo C se encuentra una tabla que permite mapear

los controles de la ISO 27001 con los del NIST, lo que permite revisar y unificar controles

coincidentes seleccionados de las dos normas, pero además brinda la oportunidad de tomar

como referencia la categoría de seguridad (SC) analizada previamente y a partir de ella

determinar en qué nivel de seguridad en que se encuentra el Centro de Datos de acuerdo

a las líneas base de control para bajo medio y alto impacto propuestos por el NIST.

Los controles del NIST SP 800-53 están divididos en dieciocho familias que se pueden

observar en la Tabla 14, diecisiete de las cuales están alineadas con los requisitos mínimos

de seguridad publicados por el NIST y que sirven para estimar las deficiencias de

seguridad que se tienen o para proyectar metas en la instauración de controles de

seguridad. La única familia que no cuenta con determinación de requisitos mínimos es la

familia PM (Program Management), ya que esta proporciona controles de seguridad a nivel

de la organización y cuenta con su propia guía de implementación.

ID Familia ID Familia

AC Access Control MP Media Protection

AT Awareness and Training PE Physical and Environmental Protection

AU Audit and Accountability PL Planning

CA Security Assessment and Authorization PS Personnel Security

CM Configuration Management RA Risk Assessment

72


CP Contingency Planning SA System and Services Acquisition

IA Identification and Authentication SC System and Communications Protection

IR Incident Response SI System and Information Integrity

MA Maintenance PM Program Management Tabla 12. Identificadores y nombres de controles de seguridad del NIST [33, p. 9]

La estructura de control de seguridad consta de los siguientes componentes: (i) una sección

de control; ii) una sección de orientación suplementaria; (iii) una sección de mejoras de

control; (iv) una sección de referencias; y (v) una sección de asignación de prioridades y de

línea de base.

5.6.1.3 Líneas Base de Control Las líneas base de control son una referencia que sirve para determinar los controles a

instaurar en el Centro de Datos. La selección de una línea base (bajo, medio, alto) es

resultado del proceso de categorización que evalúa el nivel de impacto según el FIPS 200

del NIST [32]. Es decir que la línea base de control que se toma en este proyecto

corresponde a la calificación “alta” la cual se obtuvo al utilizar el método indicado por el

NIST previamente.

Para entender mejor las características de las líneas base de control se debe conocer que

los controles de los cuales se desprenden las familias de control del NIST, tienen a su vez

unos controles de mejora que son los que hacen la diferencia entre una línea base y otra.

Cada control principal tiene un número de controles de mejora específico, pero el NIST

determinó para cada control un número mínimo de controles de mejora como referencia

para establecer si se cumple o no con los requisitos de seguridad esperados para una

determinada línea base. En el Anexo D los controles de mejora se identifican frente a cada

control principal, bajo las líneas base de control (bajo, moderado y alto) y el título de

“MEJORAS”, mientras que en la tabla D-2 del NIST se visualizan entre paréntesis frente a

cada control principal; se caracteriza porque se representa mediante un número que hace

alusión a un control de mejora en específico; así mismo por cada línea base se puede

observar la cantidad de controles de mejora.

Para mayor claridad sobre las líneas base de seguridad del NIST, en las siguientes gráficas

se hace una representación de estas, donde la altura de las barras indica la presencia de

un mayor número de controles de mejora.

73


Las gráficas están elaboradas con base en la tabla del Anexo D, donde se encuentran los

controles del NIST SP 800-53. Aunque el NITS cuenta con 224 controles, no todos son de

obligatorio cumplimiento, sino que están sujetos a la categoría de seguridad de la

información o sistema que deseamos proteger. Así por ejemplo, la cantidad de controles

mínimos para la línea base de seguridad de bajo impacto, tiene un total de 114 controles y

tan solo 9 controles de mejora. Estos se representan en la siguiente gráfica.

Figura 12 . Línea base de seguridad para la categoría de seguridad "baja". Autoría propia.

La gráfica representa en su eje horizontal los controles de seguridad del Anexo D, los

controles que no aplican se encuentran con el valor de 0 con respecto al eje vertical, cuando

un control es requisito mínimo, se indica con una unidad, mientras que cada control de

mejora de determinado control incrementará en una unidad su valor.

La siguiente gráfica tiene los mismos fundamentos, pero representa la cantidad mínima de

controles de seguridad para un “sistema” de mediano impacto, y se puede observar sin

necesidad de recurrir a la tabla del anexo D, que el número de controles y controles de

mejora aumenta considerablemente. En este caso el número de controles es de 158 y el

número de controles de mejora es de 102.

0123456789

10

1 9 17 25 33 41 49 57 65 73 81 89 97 105

113

121

129

137

145

153

161

169

177

185

193

201

209

217

Cant

idad

de

Cont

role

s

ID de Control

Línea Base de Seguridad - Categoría baja

74


Figura 13 . Línea base de seguridad para la categoría de seguridad "media". Autoría propia.

Por último se presenta la gráfica de seguridad de alto impacto, para sistemas con

información crítica según lo establecido en el FIPS 199 del NIST. Es de resaltar el hecho

de que la cantidad de controles mínimos para esta línea base es de 169 controles y 172

controles de mejora.

Figura 14 . Línea base de seguridad para la categoría de seguridad "alta". Autoría propia.

La siguiente gráfica muestra la diferencia entre los niveles base de seguridad

0123456789

101 9 17 25 33 41 49 57 65 73 81 89 97 105

113

121

129

137

145

153

161

169

177

185

193

201

209

217

Cant

idad

de

cont

role

s

ID de Control

Líneas Base de Seguridad - Categoría media

0123456789

10

1 9 17 25 33 41 49 57 65 73 81 89 97 105

113

121

129

137

145

153

161

169

177

185

193

201

209

217

Cant

idad

de

cont

role

s

ID de Control

Líneas Base de Seguridad - Categoría alta

75


Figura 15 . Comparación de líneas base de seguridad. Autoría propia.

5.6.1.4 Seguridad de la nube privada aplicando controles de líneas Base de Seguridad

Verificación total de controles (Opción 1)

El NIST cuenta con 223 controles de seguridad y con 664 controles de mejora. La

evaluación total de esta cantidad de controles básicos y controles de mejora de seguridad

para instaurarlos en una nube privada, se conciben como una tarea poco práctica y de difícil

realización. Proteger la información no se trata de tomar una lista tan amplia y comenzar a

instaurar controles al azar, la implementación de un solo control puede llevar mucho tiempo

y podría no resultar indispensable para el objeto de la organización. Por lo tanto esta

estrategia de verificación e implementación total de controles se descarta.

02468

101214161820

1 9 17 25 33 41 49 57 65 73 81 89 97 105

113

121

129

137

145

153

161

169

177

185

193

201

209

217

Cont

role

s de

Mej

ora

ID del Control

Comparación de Líneas Base de Control

Bajo Medio Alto

76


Estimación de controles críticos con base en criterios específicos y análisis de riesgos (Opción 2)

Determinar cuáles controles se deben seleccionar para implementar en la nube privada es

la tarea de interés en esta etapa, y por ello, considerando el análisis previo referente a lo

poco viable de tomar los 224 controles y 664 controles de mejora del NIST para ser

implementados, se procede a fijar los elementos que pueden facilitar la selección de los

controles prioritarios.

Hasta este punto se cuenta con la selección de la Línea Base de Control que corresponde

a “Alta”, la cual reduce los 664 controles de mejora a 114, debido a que este valor

corresponde a la mínima cantidad de controles de mejora que se deben cumplir con la Línea

Base de Control “Alta”. Así mismo se tienen unos controles de seguridad que aplican a la

nube privada a partir de los estándares de la ISO 27000, el NIST y las buenas prácticas de

la CSA, y por último se tiene como guía los resultados del análisis de riesgos basados en

la metodología Magerit V3.0. Con estos elementos se pueden consolidar los controles

necesarios, pero más allá de tener un conjunto de controles dispersos de diferentes normas,

lo que se busca es a través de un grupo de preguntas evaluar la existencia de controles y

el muchos casos el porcentaje de su implantación.

Figura 16 . Etapas para la selección de controles de seguridad de la nube privada. Autoría propia.

77


Clasificación de controles por recursos de interés

La selección de controles críticos y la posibilidad de estimar su grado de cumplimiento

tomando la línea base de seguridad del NIST como referencia, facilita la definición de las

actividades a realizar para proteger el entorno de la nube privada, sin embargo, puede

resultar de interés para el proveedor determinar cuáles controles inciden en recurso

específicos que se consideren de mayor relevancia.

Existe libertad para determinar cuáles serían los recursos de interés, es decir la forma de

clasificar la seguridad para evaluar el control. Bien podría dividirse en seguridad física,

técnica y administrativa, o simplemente controles de seguridad física y seguridad lógica.

En este proyecto se definió la clasificación de los controles en controles de seguridad

física, seguridad de red y seguridad de datos; así mismo se categorizarán por tipo de

modelo de servicio de la nube. De esta forma la implantación del modelo podrá centrarse

en la ejecución de controles que realmente contribuyen a la protección de los servicios

ofrecidos. La estructura se presenta de la siguiente forma:

Control o criterio de seguridad

Tipo de seguridad Modelo de servicio Pregunta asociada a criterio de seguridad FÍSICA DATOS RED IAAS PAAS SAAS

Tabla 13. Estructura de la tabla de categorización y evaluación de controles para la nube privada. Autoría propia.

La Tabla 13 presenta los ítems principales tenidos en cuenta para la evaluación de los

controles de seguridad. Existen al menos tantas filas como controles de seguridad

seleccionados (113), a continuación se hace una descripción de cada columna:

• Control o criterio de seguridad: En este campo se enuncian los lineamientos o

buenas prácticas básicas de organizaciones internacionales seleccionadas en la

etapa anterior. Las demás columnas se evalúan con base en este control. En

algunas ocasiones el control podría aparecer más de una vez, debido a la

inviabilidad de evaluar su concepto con una sola pregunta en la columna final.

78


• Tipo de seguridad (Física, Datos, Red): Tanto en el campo de la seguridad física,

como la de datos y la de red, se marcan con una “X” cuando el control de seguridad

que corresponde a la fila los impacta. Algunos controles de seguridad tienen una

clara afectación sobre uno de estos tres aspectos, sin embargo, algunas veces es

más difícil establecer su impacto, pero siempre al menos uno de los tres debe estar

marcado y esto se justifica con la identificación de un impacto indirecto, también

sucede que algunos controles afecten los tres elementos.

• Modelo de servicio (IAAS, PAAS, SAAS): Se debe marcar una “X” en el modelo de

servicio que corresponda cuando se identifique una asociación con el control

evaluado y, al igual que en el ítem anterior, se puede presentar que los tres modelos

se deban marcar. Se destaca el hecho de que el modelo SAAS en los controles

evaluados para este proyecto siempre debió ser seleccionado y esto se debe a que

en el modelo SAAS el proveedor asume casi la totalidad de responsabilidades en

seguridad. Por lo tanto resultaría normal que al aplicar este modelo se obtenga la

misma característica.

• Pregunta asociada a criterio de seguridad: Se elaboró una pregunta cuyo fin es

indagar sobre el cumplimiento del criterio de seguridad en la organización. Las

preguntas se deben elaborar de tal forma que su respuesta se pueda expresar

porcentualmente, como se explicó en un apartado anterior.

5.6.1.5 Elaboración de preguntas Con base en los controles seleccionados y ya con una clasificación definida de ellos, se

elaboran preguntas orientadas a la verificación de la instauración de tales controles en el

Centro de Datos que soporta la nube privada. Las preguntas se elaboran de tal forma que

las respuestas puedan ser presentadas porcentualmente, y a mayor porcentaje se

entenderá que mayor será el cumplimiento del criterio evaluado. Se proponen dos tipos de

pregunta, una de respuesta corta donde el porcentaje será de 0% o 100% dependiendo de

si la respuestas es negativa o afirmativa, y otro tipo de pregunta donde se indica

explícitamente que la respuesta se debe expresar en porcentaje, esto es indispensable para

aplicar el método propuesto. En la Tabla 14 se presenta un ejemplo para la elaboración de

preguntas.

79


Tipo Pregunta Criterio Pregunta

Pregunta de respuesta corta

A.6.1.1 Seguridad de la información Roles y Responsabilidades: Se deben definir y asignar todas las responsabilidades de la seguridad de la información.

¿Se han definido perfiles y responsabilidades relacionadas con la seguridad de la información?

Pregunta de respuesta en porcentaje

A.8.1.1 Inventario de Activos. Se deben identificar los activos con información e instalaciones de procesamiento de información, y se debe elaborar y mantener un inventario de estos Activos.

¿En qué porcentaje estima que se encuentra documentado el inventario de equipos?

Tabla 14 . Ejemplo de preguntas para la valoración de controles de seguridad. Autoría propia.

Es importante que las preguntas garanticen: primero que se encuentran basadas en los

criterios de seguridad seleccionados previamente, y segundo que para las preguntas de

porcentaje se oriente o proponga una fórmula para calcularlo. En el caso de la pregunta del

ejemplo, el porcentaje de inventario documentado de equipos corresponderá a:

𝑃𝑃𝑅𝑅𝑉𝑉𝐼𝐼𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝑃𝑃𝑅𝑅𝐼𝐼𝑉𝑉𝑖𝑖𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝑉𝑉𝑅𝑅𝑅𝑅𝑀𝑀𝑅𝑅𝐼𝐼𝑉𝑉𝐼𝐼𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝑉𝑉𝑅𝑅 =𝑀𝑀𝐸𝐸𝑉𝑉𝑅𝑅𝐼𝐼𝑅𝑅𝑅𝑅𝑀𝑀𝑉𝑉𝐼𝐼𝑉𝑉𝑖𝑖𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝑉𝑉𝑅𝑅𝑅𝑅

𝑀𝑀𝑅𝑅𝐼𝐼𝑉𝑉𝑉𝑉𝑀𝑀𝐸𝐸𝑉𝑉𝑅𝑅𝐼𝐼𝑅𝑅𝑅𝑅

5.6.1.6 Nivel de seguridad - Valoración de respuestas y controles

La valoración del estado de seguridad del centro de datos implica dos actividades; por un

lado la valoración dada por el usuario a las respuestas del cuestionario, y por otro la

valoración de los controles a partir de estas respuestas. A continuación se presenta de

forma más detalla las actividades.

Valoración de respuestas

Esta actividad la debe realizar el jefe de seguridad de la información o quien haga sus veces.

El objetivo es evaluar las respuestas porcentualmente y para ello se tendrá presente que

las preguntas con respuesta corta (si o no) indicarán que el criterio se cumple cuando la

respuesta sea afirmativa (100%), y habrá ausencia total del mismo cuando sea negativa

(0%). La valoración de las respuestas tendrá por tanto las siguientes reglas:

80


• Pregunta de respuesta corta: cuando la respuesta es afirmativa, su valoración

corresponde al 100% y cuando es negativa corresponde al 0%.

• Pregunta de respuesta en porcentaje: La valoración de la respuesta corresponderá

al porcentaje diligenciado por el responsable de seguridad.

Valoración de controles

La valoración de las preguntas no siempre representará el valor del control. Se presentarán

casos en los que la evaluación de un control requerirá de la elaboración de más de una

pregunta, para ello se deben tener las siguientes consideraciones:

• Una pregunta por control: Cuando una pregunta es suficiente para evaluar un

control, el porcentaje de la respuesta representará el porcentaje del control.

• Dos o más preguntas por control: La valoración del control estará dada por el

promedio de los porcentajes de las respuestas que corresponden al control.

Caso Control Valoración de respuestas Valoración de Controles

Una pregunta para evaluar un control 𝒙𝒙 𝒄𝒄 𝑽𝑽𝒙𝒙 = 𝒄𝒄

Dos o más preguntas para evaluar un control

𝒙𝒙 𝒄𝒄𝟏𝟏

𝑽𝑽𝒙𝒙 = 𝟏𝟏𝒄𝒄∑ 𝒄𝒄𝒄𝒄𝒄𝒄=𝒄𝒄𝒄𝒄=𝟏𝟏 𝒄𝒄𝟐𝟐

𝒄𝒄𝟑𝟑 𝒄𝒄𝒄𝒄

Tabla 15. Criterios para la valoración de los controles de seguridad. Autoría propia.

Las preguntas en este caso están orientadas a controles de la ISO 27001, el CSA y el NIST.

Al contar con la valoración de todos los controles, se podrá realizar la verificación con el

estado ideal que corresponde para cada uno de ellos.

5.6.1.7 Selección de controles y plan de mejoramiento

La última etapa consiste en contrastar la línea base de control contra la valoración obtenida

de todos los controles. Se recomienda realizar una gráfica comparativa con el fin de tener

percepción del distanciamiento entre el estado ideal representado por la línea base control

contra el estado actual del centro de datos.

81


En la diferencia entre la línea base de seguridad y el estado de seguridad obtenido se

encuentran los controles a instaurar. Es decir que los controles son conseguidos con la tan

pronto concluya la aplicación del método propuesto.

El plan de mejoramiento estará basado en los resultados obtenidos, ya que se conocerá

cuáles serán los controles de seguridad que se instaurarán.

5.7 Implantación del SGSI

Con los controles definidos y conociendo las políticas a implantar, se procede a ejecutar el

plan proyectado, se ejecutan los controles definidos para cumplir con los objetivos de

proteger la información de la nube privada.

5.8 Monitorización y revisión

Esta es una etapa de evaluación, en ella se analiza los resultados luego de realizar la

instauración de controles y la creación o actualización de políticas de seguridad informática

necesarias.

La monitorización incluye revisiones periódicas y análisis de los riesgos residuales y

aceptables. También es importante en esta etapa contar con auditorías internas y externas

que ayuden a identificar posibles falencias.

5.9 Mantenimiento y mejora

Esta es la última etapa del ciclo, en ella se realizan acciones correctivas para alcanzar los

resultados esperados, en caso de que resultados obtenidos indiquen que deban ejecutarse,

también se analizar resultados de auditorías con el fin de medir el rendimiento del SGSI.

82


6 Caso de estudio: Modelo de Seguridad para la nube privada del CECAD de la Universidad Distrital Francisco José de Caldas

6.1 Centro de Computación de Alto de Desempeño (CECAD)

El caso de estudio se desarrolló en la nube privada del Centro de Computación de Alto

Desempeño (CECAD) de la Universidad Distrital Francisco José de Caldas, universidad

pública de Bogotá, Colombia. El objetivo fue poner en práctica el modelo de seguridad

propuesto para fortalecer los controles con que contaba el centro de datos. Se destaca el

hecho de que esta nube privada lleva en funcionamiento alrededor de tres años y que

anterior a esto su infraestructura tenía un enfoque tradicional.

El CECAD se creó en la Universidad Distrital en el año 2010 con el fin de “potenciar las

áreas de investigación de los estudiantes de Doctorado, Postgrado y Pregrado en todas las

áreas de la ciencia que requirieran de una herramienta con alta capacidad de cálculo y de

almacenamiento de información.” [34]. Durante el año 2014, luego de analizar la

infraestructura con que contaba y el uso de los recursos por parte de los investigadores de

la institución, se decide adaptar el CECAD a un modelo cloud, dando inicio a la nube

privada de la Universidad Distrital. Un estudio interno permitió seleccionar a OpenStack

como la plataforma en la que sería implementada [35].

Al tomar el CECAD como objeto de estudio, existe coherencia con el tipo de organización

al cual es dirigido el modelo de seguridad propuesto, ya que la infraestructura tecnológica

que lo conforma se encuentra en una de las sedes de la Universidad Distrital y

adicionalmente los proyectos desarrollados en este centro de datos están orientados a

investigación.

83


6.2 Disposición del entorno y preparación

En esta etapa se definió el contexto en el que se desarrollaría el modelo de seguridad,

posteriormente se evalúo el interés de los altos cargos en fortalecer las estrategias de

seguridad y sus beneficios, por último se estableció la distribución de labores entre el

personal del centro de datos que acompañaría la implementación del modelo de seguridad.

Contexto del modelo cloud en el CECAD

El CECAD de la Universidad Distrital ha implementado una nube privada bajo el modelo

de servicio IaaS, con alrededor de 3 años de uso y administrado técnicamente por 3

personas. Los usuarios prioritarios de los servicios del CECAD son estudiantes del

Doctorado en Ingeniería, aunque docentes, estudiantes de maestría de pregrado que

requieran recursos de cómputo para sus investigaciones pueden acceder a ellos con una

evaluación previa de sus requerimientos.

Sensibilización de los altos cargos

La sensibilización se refiere a la presentación de argumentos que generen conciencia a los

altos cargos con respecto a la protección de la información de investigación almacenada y

procesada en la nube privada, para ello es necesario conocer la estructura jerárquica de la

organización con el fin de llamar la atención sobre este tema a personas que tengan poder

de decisión. En este caso de estudio se especifica que el CECAD de la Universidad Distrital,

al hacer parte del Doctorado en Ingeniería está sujeto a las directrices del coordinador del

doctorado y a las decisiones de su comité; adicionalmente se reconoce la asesoría del

director del Grupo de Investigación GICOGE, quien también hace aportes para su gestión.

En definitiva, estas son las instancias que establecen las pautas del uso apropiado de la

infraestructura de la nube privada y centro de datos en general.

Como parte de la sensibilización a los altos cargos, el administrador de la nube presenta

informes periódicos de uso y de los proyectos de investigación que se desarrollan en ella,

por otro lado, en cuanto a la protección de los datos que son resultado de los proyectos de

investigación, el director del grupo GICOGE consciente de su relevancia ha promovido la

presente investigación incluyendo el caso de estudio en el CECAD. El mensaje que se ha

84


transmitido es que no se debe esperar a que exista un hallazgo o calamidad en materia de

seguridad en el CECAD para tomar la decisión de revisar, evaluar y fortalecer su seguridad.

Personal y roles para la implementación

Este punto tenía que ver con la asignación de los roles mínimos sugeridos en la Tabla 3

para realizar el acompañamiento y las tareas necesarias que permitieran implementar el

modelo de seguridad, a continuación se recuerdan los roles referidos:

• Comité de seguridad informática o Director ejecutivo/ Chief Executive Officer (CEO)

• Director de información / Chief Information Officer (CIO).

• Jefe de seguridad de la información/ Chief Security Officer (CSO).

Con respecto al comité de seguridad informática, aunque la Universidad Distrital cuenta con

este órgano desde el año 2014 y está integrado por las áreas denominadas Red de Datos,

Oficina Asesora de Sistemas, PlanesTIC, entre otras; aún no existe un documento formal

expedido por tal comité en materia de seguridad. Este comité está trabajando actualmente

en la elaboración del SGSI, así como también en otras iniciativas orientadas a la protección

de la información de la universidad, por ello en el CECAD siempre se ha tomado la iniciativa

para aplicar medidas de protección de su información, independientemente de la

consolidación de estos proyectos. La totalidad de decisiones que se toman en relación con

el CECAD, son atendidas y orientadas por el director de doctorado, y esta ha sido la

instancia que ha proyectado el uso de su infraestructura comúnmente, en este sentido se

puede afirmar, que el director del doctorado con apoyo de su comité, asume las actividades

del comité de seguridad informática para el CECAD.

Considerando lo mencionado en 6.2 “disposición del entorno y preparación” donde se indica

el reducido número de personas que hacen parte del equipo de administración técnica de

la nube privada del CECAD (tres personas), se reitera que los roles propuestos solamente

son sugeridos y en el caso de estudio aunque no se puede establecer con claridad cómo

podrían adaptarse teniendo en cuenta el limitado personal existente, se hace una

sugerencia para ello. Los roles principales del equipo que administra el CECAD son:

administrador de la nube privada, administrador de red y técnico eléctrico, cada uno de los

cuales de los encargados aporta a la seguridad del área que le corresponde, pero resulta

inviable asignar un cada rol una persona. Por tal razón el acompañamiento y la mayor

cantidad de responsabilidades las ha asumió el administrador de la nube privada, quien

85


tiene claro conocimiento de la arquitectura de la nube, las características de los servicios y

el impacto de los controles que se puedan implantar.

6.3 Situación actual del CECAD

Estructura Organizacional

Organigrama de la Universidad Distrital Francisco José de Caldas

Figura 17 . Organigrama general de la Universidad Distrital Francisco José de Caldas. Fuente página web Universidad Distrital.

86


Organigrama del CECAD de la Universidad Distrital Francisco José de Caldas

Figura 18 . Organigrama del CECAD de la Universidad Distrital Francisco José de Caldas. Autoría propia.

Consejo Superior Universitario

Rectoría

Vicerrectoría académica

Facultad de ingeniería

Doctorado en ingeniería

Centro de Computación de Alto Desempeño (CECAD)

87


Controles de seguridad existentes en la organización

En la Universidad Distrital Francisco José de Caldas, el rector, como máxima autoridad de

la institución, expidió mediante resolución administrativa No 678 del año 2011, la “Política

para la seguridad Informática de la Universidad Distrital”. La aplicación de esta Política

abarca a todas las personas que presten sus servicios en la universidad (funcionarios,

docentes, contratistas y visitantes), así mismo aplica para todas las dependencias de la

institución y sus procesos vinculados. En el caso de la responsabilidad de los estudiantes

en el uso de los recursos de TI, la política indica que estos deben aceptar un acuerdo al

momento de realizar su matrícula del semestre, mientras que sus procesos y sanciones

disciplinarias deben estar contempladas en el estatuto estudiantil.

La política toca puntos como la seguridad física, la administración de comunicaciones,

gestión de acceso, y en general temas relacionados con seguridad informática para

entornos tradicionales, que no incluye muchas de las características inherentes a los

servicios de la nube privada y, aunque es un documento oficial, está basado en referencias

válidas pero que ya son obsoletas, como es el caso del ISO 27001:2005 y la ISO 14001.

Vale la pena destacar que actualmente el Comité de Seguridad Informática está elaborando

las directrices para una nueva normatividad y la implantación del SGSI de la Universidad

Distrital. El CECAD se acoge a los lineamientos y se acogerá a futura la política, sin

embargo para la prestación de los servicios ofrecidos en la nube privada maneja directrices

adicionales que no se contemplaron en la política vigente. En todo caso para este tipo de

ambigüedades se ha recomendado hacer diferenciación entre políticas de TI misionales y

políticas de TI para investigación.

88


6.4 Alcance del SGSI para el CECAD

Teniendo en cuenta los recursos de cómputo del CECAD para el desarrollo de

investigaciones, se propuso el siguiente alcance para su SGSI.

“El SGSI planteado debe ser aplicado en todos los activos del Centro de Computación de

Alto Desempeño (CECAD),ubicado en Bogotá, con el fin de salvaguardar la información de

investigación, los procesos de asignación de recursos de cómputo y demás servicios

ofrecidos a los investigadores”

6.5 Análisis de riesgos y vulnerabilidades del CECAD

El objetivo de esta etapa es obtener la matriz de riesgos, la cual permite identificar los

riesgos más relevantes en materia de seguridad. Para la elaboración de la matriz de riesgos

del CECAD, inicialmente se debe realizar la identificación y valoración de activos. Esta

actividad se realizó de forma general basados en una investigación previa [36], en caso de

realizar el mismo ejercicio para otros proyectos se recomienda hacerlo con mayor

rigurosidad

Identificación y valoración de activos del CECAD

La primera parte consistió en la identificación de activos, por ello, y con el fin de facilitar las

evaluaciones cualitativa y cuantitativa, los recursos del CECAD se agruparon de acuerdo

a los servicios o funciones que desempeñan en la puesta en marcha de la nube privada.

La siguiente tabla presenta esta agrupación.

Tipo Referencia No Función Características

Servidor Dell R710 1 Nodo de red RAM: 64GB CPU: 16 Almac.:67GB

Servidor Dell R610 5 Nodos Controladores RAM: 16GB CPU: 16 Almac.:67GB

Servidor Dell R610 6 Almacenamiento (Ceph) RAM: 16GB CPU: 16 Almac.:67GB

Servidor Dell R610 36 Nodos de Computo RAM: 16GB CPU: 16 Almac.:67GB Servidor HP DL160 8 Ambiente Pruebas RAM: 24/36 CPU: 2/4 Almac.: 2TB (total)

Servidor IBM HS22 5 Almacenamiento (Swift) RAM: 16GB CPU:4 Almac.:10TB(total)

SAN DS5020 1 Sistema de respaldo Almacenamiento: 100 TB

89


Switch IBM 2498-B24 SAN 1 Switch de SAN Active ports Fibre Channel 16x 8Gbps, brocade 300

Switch DELL PCN 6248 2 Switch-Red Dell Power Connect 6248

Switch DELL N2048 1 Switch-Red 48 ports - managed - rack-mountable

Firewall Cisco ASA 5520 1 Firewall-Seguridad Capacidad Peers VPN IPSec : 750 Sesiones

concurrentes: 280000 Peers VPN SSL : 2 Conexión/cantidad de usuarios : ilimitado Interfaces

virtuales (VLAN) : 150

Firewall Fortiget 1000d 1 Firewall-Seguridad Maximum Number of FortiTokens 5,000

Maximum Number of Registered Endpoints 20,000 IPS Throughput 2 9 Gbps

Concurrent Sessions (TCP) 11 Million Tabla 16. Activos del CECAD que hacen parte de la nube. Autoría propia.

Equipos que hacen parte de la nube privada del CECAD

Figura 19. Servidor en rack PowerEdge R610 [37]

Figura 20. Servidor PowerEdge R710 [38]

Figura 21. PowerEdge R900

Figura 22. HP DL160 G6 [39]

Figura 23. BladeCenter S 8886 [40]

Figura 24. Blade HSS 22 [41].

Tabla 17. Imágenes de equipos que hacen parte de la nube privada

90


Luego de tener la lista de activos, se procede a realizar las valoraciones desde el punto de

vista cualitativo y cuantitativo. Para la valoración cualitativa del CECAD se tendrá presente

los siguientes criterios y valores:

Valoración Cualitativa - Activos CECAD Escala de Valoración Valor Descripción

MB: Muy Bajo 1 Irrelevante B: Bajo 2 Baja Importancia

M: Medio 3 Importante A: Alto 4 Altamente importante

MA: Muy alto 5 De vital importancia Tabla 18. Tabla de Valoración Cualitativa del CECAD. Autoría Propia.

La valoración cuantitativa de los activos se basará en la siguiente tabla:

Valoración Cuantitativa – Activos CECAD Escala de Valoración Valor Valor en pesos $ MB: Muy Bajo 1 0 a 5.000.000 B: Bajo 2 5.000.001 a 10.000.000 M: Medio 3 10.000.001 a 20.000.000 A: Alto 4 20.000.001 a 40.000.000 MA: Muy alto 5 40.000.001 o más

Tabla 19. Tabla de Valoración Cuantitativa del CECAD. Autoría Propia.

Por último, para establecer la valoración total, se hace una ponderación de la valoración

cualitativa y la cuantitativa, con porcentajes del 80% y 20% respectivamente. Los resultados

de las valoraciones se presentan se resumen en la siguiente tabla:

Valoración de activos Activo/Referencia No Función Val.

Cualitativa Val.

Cuantitativa Valoración Total Dell R710 1 Nodo de red 5 1 4,2 Dell R610 5 Nodos

Controladores 5 1 4,2

Dell R610 6 Almacenamiento (Ceph)

5 1 4,2

Dell R610 36 Nodos de Computo 5 1 4,2 HP DL160 8 Ambiente Pruebas 4 1 3,2 IBM HS22 5 Almacenamiento

(Swift) 5 1 4,2

DS5020 1 Sistema de respaldo

4 1 3,2

IBM 2498-B24 SAN 1 Switch de SAN 5 1 4,2 DELL PCN 6248 2 Switch-Red 5 1 4,2 DELL N2048 1 Switch-Red 5 1 4,2 Cisco ASA 5520 1 Firewall-Seguridad 5 1 4,2 Fortiget 1000d 1 Firewall-Seguridad 4 1 3,2

Tabla 20. Valoración de activos del CECAD. Autoría propia.

91


Análisis de riesgos del CECAD

6.5.2.1 Valoración de riesgos Con la identificación de activos realizada, se procede a hacer una verificación de los riesgos

asociados a estos activos, para ello se debe estimar el valor de la vulnerabilidad

(probabilidad de ocurrencia de la amenaza) y el valor impacto que tendría un incidente en

el CECAD en caso de materializarse una amenaza. La vulnerabilidad, debido a que es una

probabilidad, como se indicó en la Tabla 7 tendrá valores entre 0 y 1 de acuerdo a

determinados criterios. Para la estimación en este caso de estudio, se tendrán presentes

los mismos criterios, que en resumen a continuación:

• 0-0,25: Baja probabilidad de incidentes, lejana la posibilidad de amenaza efectiva

• 0,26-0,5: mediana probabilidad de que se presenten incidentes, la amenaza es

latente.

• 0,51-0,75: mediana probabilidad de incidentes, existen antecedentes o es muy

probable que se presente.

• 0,76-1: Alta probabilidad de que se presenten incidentes o los incidentes se

presentan muy frecuentemente y no existen controles en la organización.

Los valores del impacto por otro lado, se encuentran en un rango entre uno (bajo impacto)

y cinco (alto impacto).

La matriz de riesgos se podrá realizar teniendo presente las anteriores valoraciones y la

aplicación de la fórmula para calcular el riesgo:

𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 = (𝑃𝑃𝑉𝑉𝑅𝑅𝑉𝑉𝑉𝑉𝑉𝑉𝑅𝑅𝑉𝑉𝑅𝑅𝑉𝑉𝑉𝑉𝑉𝑉 𝑉𝑉𝑅𝑅 𝑀𝑀𝐼𝐼𝑉𝑉𝑉𝑉𝑉𝑉𝑅𝑅𝑉𝑉𝐼𝐼𝑅𝑅𝑉𝑉)(𝐼𝐼𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼𝑅𝑅)

Sintetizando la Tabla 8 y la Tabla 9, la valoración de cada riesgo para los activos del CECAD

será interpretada conforme a las siguientes pautas:

Clase Rango de valores del riesgo calculado

Critico 2,6 a 5 Grave 1,6 a 2,5

Moderado 0,76 a 1,5 Tolerable 0,25 a 0,75

Tabla 21. Rangos de valores para la determinación de tipos de riesgo.

6.5.2.2 Matriz de riesgos del CECAD

MATRIZ DE RIESGOS POR ACTIVO

ACTIVO AMENAZA VULNERABILIDAD

Prob

abili

dad

de O

curr

enci

a (P

O)

IMPACTOS

Valo

r to

tal d

el im

pact

o

Va

lor d

el ri

esgo

Rie

sgo

Tipo de Riesgo

Técnico Organizacional

Perd

ida

de C

onfid

enci

alid

ad

Perd

ida

de In

tegr

idad

Perd

ida

de D

ispo

nibi

lidad

Perd

idas

Eco

nóm

icas

Afe

ctac

ión

de Im

agen

Dell R710 – Nodo de red Ataques externos Apertura injustificada de puertos 0,2 1 4 4 2 3 2,8 0,56 Tolerable Dell R610 – Nodos Controladores

Ataques externos Apertura injustificada de puertos 0.2 1 1 4 2 3 2,2 0,44 Tolerable

Dell R610 Almacenamiento (Ceph) Ataques externos Apertura injustificada de puertos 0,2 3 2 1 1 3 2,0

0,40

Tolerable

Dell R610 Nodos de Computo

Ataques externos Apertura injustificada de puertos 0,2 2 1 1 1 3 1,6 0,32 Tolerable

HP DL160 Ambiente Pruebas


IBM HS22 Almacenamiento (Swift) Ataques externos Sniffers 0,2 3 2 1 1 3 3,5 0,57 Tolerable

DS5020 Sistema de Respaldo


IBM 2498-B24 SAN Ataques externos Apertura injustificada de puertos 0,2 1 1 1 2 3 3,2 0,56 Tolerable

DELL PCN 6248 Switch Red

Ataques externos Sniffer 0,2 1 1 1 1 2 2,5 0,35 Tolerable

93


DELL N2048 Switch Red Ataques externos sniffers 0,2 1 4 4 2 4 0,3 0,3 Tolerable

Cisco ASA 5520 Firewall

Ataques externos Apertura injustificada de puertos 0.2 1 1 4 2 4 2,4 0,54 Tolerable

Cisco ASA 5520 Firewall Ataques externos Apertura injustificada de puertos 0,2 3 2 1 1 3 2,1

0,36 Tolerable

Fortigae 1000d Firewall Ataques externos Apertura injustificada de puertos 0,2 1 1 4 2 4 2,4 0,54

Tolerable

Tabla 22 . Matriz de riesgos del CECAD. Autoría propia.

6.6 Determinación de controles de seguridad y gestión de riesgos – aplicación del modelo propuesto

Categorización de la información del CECAD

Como se indicó en el capítulo anterior, la categoría de seguridad o Security Category (SC)

se calcula mediante la siguiente fórmula:

𝑺𝑺𝑺𝑺 𝑅𝑅𝑉𝑉𝑖𝑖𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝐼𝐼𝑅𝑅𝑅𝑅𝑉𝑉 𝐼𝐼𝑡𝑡𝐼𝐼𝑅𝑅 = {(𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒊𝒊𝒊𝒊𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼), (𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄, 𝑅𝑅𝐼𝐼𝐼𝐼𝑉𝑉𝐼𝐼𝐼𝐼)}

Donde el impacto hace referencia a la afectación en la confidencialidad, integridad y

disponibilidad de la información. En la siguiente tabla se resume el tipo de impacto

considerado de acuerdo al FIPS 199 del NIST:

Impacto Características Bajo - Low • se afecta la Integridad, Disponibilidad o Confidencialidad de

forma limitada en las operaciones de la organización, activos organizacionales o individuos

• La adversidad podría causar daños menores

Medio - Moderate • La vulneración en cualquier aspecto de la CIA puede afectar seriamente en las operaciones de la organización, activos organizacionales o individuos, reduciendo considerablemente el desempeño de las funciones de la

• Pérdida financiera significativa.

Alto - High • Cualquier afectación negativa en la CIA podría implicar un efecto grave o catastrófico en la organización o los individuos.

• Pérdida financiera importante • Daños graves o catastróficos a las personas.

Tabla 23 . Categorías de seguridad según el NIST - FIPS 199.

Teniendo en cuenta los anteriores criterios, para el CECAD la fórmula se representa de la

siguiente forma:


= {(𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄,𝑯𝑯𝑯𝑯𝑯𝑯𝑯𝑯), (𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒊𝒊𝒊𝒊𝒄𝒄𝒄𝒄𝒄𝒄,𝑯𝑯𝑯𝑯𝑯𝑯𝑯𝑯), (𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒂𝒂𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄𝒄,𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴)}

Con lo anterior se reitera que la categoría de seguridad (SC) es alta, debido a que se

cumple la regla que indica que si al menos uno de los criterios es alto, el resultado de la

valoración global será alta. En este caso se ha considerado que cualquier eventualidad en

95


materia de seguridad que afecte la confidencialidad o integridad de la información del

CECAD implicaría un impacto alto. Esta categoría de seguridad se tomó como referencia

para a partir de algunos cálculos que se expondrán más adelante y que permitirán

determinar los controles de seguridad necesarios para esta nube privada.

Determinación de línea base de control para la nube privada

Esta fase tuvo presente los controles de seguridad seleccionados de la familia ISO 27000

(ver Anexo A) y de la CSA (ver Anexo B). A partir de este grupo de controles y la categoría

de seguridad “Alta” del NIST obtenida en el paso anterior, se procedió a elaborar la línea

base de control. Esta línea base de control no es la misma línea base de control que se

expuso en la sección 5.6.1.3 pero se obtuvo a partir de ella.

Figura 25 . Determinación de línea base de control para la nube privada del CECAD. Autoría propia.

6.6.2.1 Elaboración de preguntas para la valoración de los controles Tanto los controles seleccionados del Anexo A como los del Anexo B debieron ser

evaluados, y para ello, con base en lo indicado en 5.6.1.5 se realizó un conjunto de

preguntas que se puede observar en la tabla del anexo E.

La elaboración de las preguntas, como se indicó en el capítulo anterior, se plantearon con

el fin de obtener un porcentaje en la respuesta que represente el nivel de cumplimiento del

control evaluado.

96


Es importante destacar que también se realizó una clasificación de las preguntas por

modelos de servicio y recursos de interés. La distribución por modelos de servicio (IaaS,

PaaS, SaaS) tuvo por objeto permitir en la encuesta la selección de las preguntas que

realmente se relacionaran con el tipo de nube privada que se estaba evaluando, por ello,

para el caso de estudio del CECAD se seleccionaron solamente las preguntas que tienen

que ver con el modelo IaaS, que es el que se encuentra implementado; de esta forma se

evita evaluar requisitos de seguridad que no se están ofreciendo y también se evitan

resultados erróneos al realizar el proceso de evaluación. El modelo IaaS es el modelo que

incluye menos preguntas del cuestionario, para un modelo PaaS el cuestionario tendría en

cuenta algunas preguntas adicionales, mientras que para un modelo SaaS se tendría

presente el mayor número de preguntas debido a que es un modelo de servicio en el que

el proveedor asume todas las responsabilidades en materia de seguridad. Por otro lado, la

distribución por recursos de interés es una categorización opcional en la que se asocian

temas relevantes para el proveedor. En el CECAD, por ejemplo, se encontró interés por un

análisis de seguridad en términos de seguridad física, datos y red. Este requerimiento se

tuvo presente y se incluyó en la tabla de evaluación el cual se ve representado en la

siguiente figura.

Figura 26 . Clasificación de preguntas para evaluación de controles de seguridad. Autoría propia.

97


Con las anteriores consideraciones se diseñó la estructura de la tabla del cuestionario de

seguridad que se presenta a continuación:

RECURSOS MODELO DE SERVICIO Fuente Pregunta Rspta

(%) F D R I P S

X X X X X X ISO/IEC 2007:2013

NA X X NA NA X ISO/IEC 2018:2014

X NA NA NA X X CSA Dominio 2

Tabla 24 . Estructura de la tabla para la elaboración de controles de seguridad. Autoría propia.

Las columnas de recursos representan la seguridad física (F), de datos (D) y red (R), por

su parte los modelos de servicio representan los modelos IaaS (I), PaaS (P) y SaaS (S). La

“X” sobre alguno de ellos indica que el criterio de seguridad evaluado con la pregunta los

afecta, en caso contrario aparecerá un No Aplica (NA). Se puede presentar un criterio de

seguridad que impacte todos los recursos o todos los modelos de servicio, esto ocurre con

algunos criterios de seguridad muy generales que de una u otra forma inciden sobre estos

elementos. La columna “Fuente” tiene el nombre de la norma de la cual es tomado el criterio,

en la columna “Pregunta” obviamente se encuentra redactado el interrogante basado en un

control o buena práctica de seguridad y, por último, en el campo “Respuesta” se presenta

el valor asignado a la correspondiente pregunta por el jefe de seguridad o quien haga sus

veces.

En resumen, para modelo de servicio IaaS y clasificando por seguridad física, de datos y

red, el número de preguntas presentadas en el anexo E que se tendrán presentes en el

caso de estudio se puede observar en la siguiente tabla:

Tipo de pregunta para la nube privada del CECAD Cantidad

Modelo de servicio IaaS 96

Seguridad física 45

Seguridad de datos 87

Seguridad de red 44 Tabla 25 . Número de preguntas por tipo de pregunta para el CECAD.

98


6.6.2.2 Controles de seguridad a partir de la ISO/IEC 27001 y el CSA La tarea de realizar el mapeo de las normas de la ISO/IEC 27001 con los controles del

NIST, requirió utilizar la tabla del Anexo C, así mismo se utilizó una matriz del CSA que

permitió realizar el mismo proceso, obteniéndose los resultados presentados en la siguiente

tabla.

Norma N° Controles N° Controles posterior al mapeo con el NIST

ISO 27001 38 78

CSA 44 140 Tabla 26 . Cantidad de preguntas por norma y por mapeo al NIST.

Teniendo en cuenta que las normas coinciden en 66 controles, la cantidad de controles

que se debieron tomar para la línea base fueron:

𝐶𝐶𝑉𝑉𝑉𝑉𝐼𝐼𝑅𝑅𝑉𝑉𝑉𝑉𝑉𝑉𝑀𝑀𝑅𝑅𝐼𝐼𝑉𝑉𝑉𝑉𝐶𝐶𝑅𝑅𝑉𝑉𝐼𝐼𝑉𝑉𝑅𝑅𝑉𝑉𝑅𝑅𝑅𝑅𝑠𝑠𝑅𝑅𝑉𝑉𝑅𝑅𝑉𝑉𝑠𝑠𝑉𝑉𝑅𝑅𝑅𝑅 = (78 − 66) + (144 − 66) + 66 = 152

Es decir que en total son 152 controles del NIST los controles que se tomen de la línea

base original. La selección de estos controles se puede observar en el Anexo F.

6.6.2.3 Graficas de línea base Las siguientes son las gráficas de línea base con los 152 controles para determinar en qué

estado se encuentra la seguridad del CECAD, siendo la línea de seguridad de categoría

alta, la referencia a seguir para alcanzar el estado ideal.

99


Figura 27. Línea base de seguridad para el CECAD - Categoría ALTA. Autoría propia.

Los espacios en la gráfica representan controles seleccionados que no son obligatorios,

mientras que los picos son controles de mejora sobre determinado control; es decir son

controles adicionales que se deben evaluar para un determinado control y son tomados del

anexo F del NIST. Las líneas base de las categorías media y baja que se presentan a

continuación, permitirán a partir de la línea base de seguridad obtenida del CECAD, estimar

a primera vista como se encuentra su nivel de seguridad.

Figura 28 .Línea base de seguridad para el CECAD - Categoría MEDIA. Autoría propia.

0123456789

101 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

TítC

ontr

oles

de

mej

ora

ID del control

Linea base de seguridad para el CECAD Categoría de seguridad ALTA

0123456789

10

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

Cntr

oles

de

mej

ora

ID de control

Linea base de seguridad para el CECAD Categoría de seguridad MEDIA

100


Figura 29 .Línea base de seguridad para el CECAD - Categoría BAJA. Autoría propia.

6.6.2.4 Nivel de seguridad general del CECAD A partir de las respuestas consolidadas en el cuestionario para evaluar la seguridad del

CECAD y los 152 controles descritos anteriormente, se tuvo el material para evaluar el

determinar el estado de seguridad del Centro de Cómputo.

El administrador de la nube del CECAD respondió el cuestionario que se encuentra en el

Anexo E, donde se pueden apreciar los porcentajes asignados a las respuestas en la última

columna. Las respuestas marcadas como NA son aquellas que están relacionadas con

modelos de servicio diferente al IaaS, es decir PaaS o SaaS, que no aplicaban para el caso

de estudio.

El número de preguntas no necesariamente representa el total de controles evaluados, en

algunos casos dos más preguntas se requirieron para evaluar un control y el porcentaje

total del control correspondía al promedio de estos. A continuación se presentan como

ejemplo dos de estas situaciones presentadas en el caso de estudio.

0123456789

101 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

Cont

role

s de

mej

ora

ID del control

Línea base de seguridad para el CECAD Categoría de seguridad BAJA

101


Criterio Pregunta Respuesta A.6.1.1 Seguridad de la información Roles y Responsabilidades. Se deben definir y asignar todas las responsabilidades de la seguridad de la información.

¿Se han definido perfiles y responsabilidades relacionadas con la seguridad de la información?

0

A.9.2.6 Cancelación o ajuste de los derechos de acceso. Los derechos de acceso de todos los empleados y de usuarios externos a la información y a las instalaciones de procedimiento de información se deben cancelar al terminar su empleo, contrato o acuerdo, o se deben ajustar cuando se hagan cambios.

¿En qué porcentaje se han cancelado los derechos de acceso a los empleados cuyo contrato, acuerdo o vínculo con la organización ha culminado?

90

¿En qué porcentaje están ajustados los derechos de acceso de usuarios de acuerdo a sus funciones

20

Tabla 27 . Evaluación de controles

La Tabla 27 presenta un par de preguntas del cuestionario, se deduce a partir de ella que

el control A.6.1.1 tendrá valoración de cero, mientras que el control A.9.2.6 tendrá una

valoración de 55 al obtener el promedio entre las dos respuestas. En general la valoración

de todas las respuestas se efectuó de esta manera.

En el siguiente paso las respuestas de la ISO 27001 fueron mapeadas a los controles de

seguridad de las diferentes familias del NIST y esto se puede apreciar en las los Anexos

G. Por ejemplo el control A.6.1.1 que se muestra en la Tabla 27 y cuya valoración es 0 se

ve reflejado en los Anexos G, donde se muestra como el valor afecta los controles del NIST

de los cuales se extrae la gráfica; lo mismo ocurre con el valor 55 del control A.9.2.6 que

solamente afecta un control del NIST representado en el Anexo G.1

EL anexo H por su parte presenta el mapeo de las respuestas de los dominios del CSA a

los controles del NIST. Cada dominio, al no estar dividido en controles ni tener un área

específica de asignación, abarca muchos más controles del NIST porque se evalúan en

conjunto sus recomendaciones.

Los valores de la gráfica del estado general de seguridad del CECAD se obtiene por lo tanto

de a partir de los controles del NIST que han sido valorados mediante los anexos G y H.

102


Figura 30 . Estado general de seguridad del CECAD. Autoría propia.

En la gráfica anterior se observa que el CECAD, aunque en su estado general de seguridad

se encuentra alejado del estado de la categoría de seguridad alta (estado mínimo ideal),

por lo menos está por encima de la categoría de seguridad baja. Se hace claridad en que

los controles de mejora fueron seleccionados con base también en el anexo F de la norma

800-53 del NIST, y aquellos que definitivamente no eran viables de aplicación, se dieron

por satisfechos con el fin de no reducir el nivel de seguridad del CECAD injustificadamente.

Ahora bien, la gráfica apunta a que se deben seleccionar algunos controles de seguridad

que lleven al estado óptimo de seguridad y trazar un plan para su instauración. Tales

controles serán indicados más adelante.

6.6.2.5 Nivel de seguridad del CECAD por recursos de interés Para el desarrollo del caso de estudio en el CECAD, se tuvo interés en conocer el estado

en materia de seguridad física, de red y de datos. En las siguientes gráficas se presentan

los resultados de estas valoraciones, junto con el estado ideal. El procedimiento que se

realizó corresponde al mismo utilizado para obtener el estado general de seguridad.

0123456789

101 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

Conr

oles

de

mej

ora

ID del Control

Estado de seguridad del CECAD

103


• Seguridad física

Figura 31 . Línea base de seguridad física del CECAD - Estado ideal. Autoría propia.

Figura 32 . Estado real de la seguridad física del CECAD. Autoría propia.

Las anteriores gráficas reflejan el panorama de la seguridad en el CECAD, se identifican

por tanto a partir de ella algunos controle que se deben mejorar. Aunque no se encuentra

la gráfica categoría de seguridad media y baja, la evaluación realizada arrojó que se

encuentra por encima del nivel bajo y cerca del nivel medio. La gráfica es un elemento de

ayuda para que los encargados de la nube dimensionen con rapidez las falencias en materia

de seguridad.

0123456789

10

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

Cont

role

s de

mej

ora

ID del control

Línea base de seguridad física del CECAD - Estado ideal

0123456789

10

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

Cont

role

s de

mej

ora

ID del control

Estado real de la seguridad física del CECAD

104


• Seguridad de datos

Figura 33 . Línea base de seguridad de datos del CECAD - Estado ideal. Autoría propia.

Figura 34 . Estado real de la seguridad de datos del CECAD. Autoría propia.

0123456789

10

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

Cont

role

s de

mej

ora

ID del control

Línea base de seguridad de datos del CECAD - Estado ideal

0123456789

10

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

Cont

role

s de

mej

ora

ID del control

Estado real de la seguridad de datos del CECAD.

105


• Seguridad de red

Figura 35 . Línea base de seguridad de red del CECAD - Estado ideal. Autoría propia.

Figura 36 . Estado real de la seguridad de datos del CECAD. Autoría propia.

0123456789

10

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88

Cont

role

s de

mej

ora

ID del control

Línea base de seguridad de red para el CECAD - Estado ideal

0123456789

10

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88

Cont

role

s de

mej

ora

ID del control

Estado real de la seguridad de datos del CECAD

106


6.6.2.6 Controles de seguridad a instaurar en el CECAD A partir de los resultados obtenidos se puede trazar un plan mejora que involucre los

controles evaluados y no satisfechos. Las gráficas de seguridad por tipo de recursos

servirán de orientación sobre las áreas de mayor prioridad. En el caso del CECAD, al ser

una nube privada orientada a investigación, se ha establecido que los recursos de mayor

prioridad son los datos, por tal razón se sugiere iniciar con la instauración de los controles

asociados a este recurso. Estos controles se presentan a continuación:

Principales controles a instaurar Elaborar acuerdos de niveles de servicio con los usuarios que hacen uso de la nube del CECAD

Establecer una política de seguridad para el traslado y la eliminación de datos personales.

Establecer un proceso de autorización para utilizar los datos fuera de las instalaciones.

Los derechos de acceso de todos los empleados y de usuarios externos a la información y a las instalaciones de procedimiento de información se deben cancelar al terminar su empleo, contrato o acuerdo, o se deben ajustar cuando se hagan cambios.

Se deben definir y asignar todas las responsabilidades de la seguridad de la información.

Se recomienda la supervisión periódica, las pruebas y la evaluación de los servicios, a fin de garantizar que se están utilizando las medidas de seguridad y privacidad necesarias, y se siguen los procesos y las políticas

Los acuerdos contractuales con empleados y contratistas deben establecer sus responsabilidades y las de la organización en cuanto a seguridad de la información.

Se deben establecer las responsabilidades y procedimientos de gestión para asegurar una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.

Las partes de un contrato de servicios en la nube deberían asegurarse de que el contrato se anticipa a los problemas relacionados con la recuperación de los datos del cliente una vez finalizada su relación contractual

Los proveedores de IaaS deben proporcionar a sus clientes de servicios Cloud un control de acceso y auditoría unificados.

La eliminación de datos de un proveedor Cloud, ya sea debido a la expiración del contrato o cualquier otra razón, se debe cubrir en detalle en la creación del ANS. Esto debe abarcar la eliminación de cuentas de usuario, la migración o la eliminación de datos desde el almacenamiento primario/redundante, entrega de claves, etc

107


Se debe contar con un proceso formal y comunicado para emprender acciones contra empleados que hayan cometido una violación a la seguridad de la información.

se debiera registrar la fecha y la hora de entrada y salida de los visitantes, y todos los visitantes debieran ser supervisados a no ser que su acceso haya sido previamente aprobado; sólo se les debiera permitir acceso por propósitos específicos y autorizados y se debieran emitir las instrucciones sobre los requerimientos de seguridad del área y sobre los procedimientos de emergencia

Almacenar un registro de fallos, supuestos o reales, y del mantenimiento preventivo y correctivo.

Registro de eventos. Se debe elaborar, conservar y revisar regularmente los registros de eventos acerca de actividades del usuario, excepciones, fallas y eventos de seguridad de la información.

Registro de eventos. Se debe elaborar, conservar y revisar regularmente los registros de eventos acerca de actividades del usuario, excepciones, fallas y eventos de seguridad de la información.

Elaborar un plan de restauración del servicio que incluya detalle de las diferentes prioridades en el proceso de restauración

Se deberían identificar, revisar regularmente y documentar los requisitos para los acuerdos de confidencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información

Se deben identificar, revisar regularmente y documentar los requisitos para los acuerdos de confidencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información.

La organización deberá determinar sus requisitos para la seguridad de la información y la continuidad del negocio en situaciones adversas, por ejemplo durante crisis o desastres.

Los acuerdos contractuales con empleados y contratistas deben establecer sus responsabilidades y las de la organización en cuanto a seguridad de la información.

Se deben definir y asignar todas las responsabilidades de la seguridad de la información.

Se debe contar con un proceso formal y comunicado para emprender acciones contra empleados que hayan cometido una violación a la seguridad de la información.

Se deben identificar, revisar regularmente y documentar los requisitos para los acuerdos de confidencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información.

Tabla 28 . Principales Recomendaciones/Controles de seguridad para el CECAD

La selección adecuada de los controles de seguridad contribuye a que el plan de

implementación se oriente principalmente a los temas críticos de seguridad de la

organización. En la etapa de implementación se deberá reaizar la gestión de los riesgos

identificados mediante la aplicación de los controles obtenidos; esto a través de políticas,

108


procedimientos, procesos, soluciones de seguridad, ente otras medidas, con un

cronograma definido que permita hacer seguimiento su avance. Para el caso de estudio del

CECAD, la investigación estaba orientada a proponer una metodología que permitiera

identificar los controles de seguridad para la nube privada. Estos controles prioritarios

identificados se dejan como base para el proceso de implementación.

También se debe contemplar un proceso de verificación de los controles que se

implementen, lo cual incluye comprobación de su impacto, así mismo es recomendable

una verificación periódica de los riesgos residuales. Tal proceso de verificación permitirá

utilizar nuevamente la metodología de seguridad, lo que conduce al ciclo que garantizará la

mejora continua y una adecuada gestión de la seguridad de la información.

109


7 Conclusiones

El modelo de seguridad propuesto facilita la evaluación de seguridad en Centros de Datos

que implementes nubes privadas, especialmente si están orientados a investigación.

La elección de los controles de seguridad de normas publicadas por organizaciones

internacionales y su orientación específicamente a la nube privada proporciona mayor

facilidad en la determinación de los controles de seguridad a instaurar.

La metodología desarrollada puede ser ampliada e incluir normas o estándares que se han

omitido. El proceso de selección y evaluación de controles de seguridad que involucra es

robusto pero flexible y adaptable a otros entornos cloud.

La elaboración de las líneas base o las categorías de seguridad permitió tener una visión

general del estado de seguridad de la nube privada. Esta estrategia facilitó la toma de

decisiones para la elaboración de un plan de mejora basado en los controles seleccionados.

La propuesta basada en el cumplimiento normativo de normas de seguridad siempre

brindará mayores garantías en la protección de los datos, ya que estas normas se basan

en estudios y análisis de alto nivel.

La protección de los datos de investigación debe ser prioridad para las organizaciones que

tienen servicios de cómputo orientados a esta área.

Otras organizaciones o instituciones educativas similares a la Universidad Distrital que

estén interesadas en implementar una nube privada en sus centros de datos, puede usar

este proyecto como guía para tomar unos criterios básicos de seguridad.

La evaluación de la seguridad de la nube privada del CECAD y el caso de estudio para

determinar los controles a implementar, permitirá a medida que se instauren las

recomendaciones planteadas, generar mayor confianza a los investigadores que

desarrollar sus proyectos de investigación.

110


8 Trabajos futuros

Con el convencimiento de la necesidad del estudio de la seguridad informática y teniendo

en cuenta la amplitud de temas que esta abarca, se ponen a consideración las siguientes

propuestas de trabajos que se pueden desarrollar en áreas mucho más específicas y que

con seguridad ofrecerían aportes a la protección de datos asociados con resultados de

proyectos de investigación en temas que están en boga.

• Seguridad de aplicaciones desarrolladas para Cloud.

• Seguridad de aplicaciones para Internet ofThings (IoT).

• Seguridad y control en sistemas de almacenamiento y redundancia en la nube.

• Desarrollo de herramienta para pentest utilizando recursos de la nube.

• Diseño de estrategias y procedimientos de respaldo de información en centros de

cómputo.

• Análisis en forense sobre plataformas Cloud.

• Análisis de seguridad de Blockchains.

• Implicaciones del Big Data para la seguridad de la información de resultados de

investigación.

9 Anexos

9.1 Anexo A - lista de Controles ISO 27001/27017/27018

Norma Control ISO

27001:2013 A.6.1.1 Seguridad de la información Roles y Responsabilidades. Se deben definir y asignar todas las responsabilidades de la seguridad de la información.

ISO 27001:2013

A.7.1.2 Términos y condiciones de empleo. Los acuerdos contractuales con empleados y contratistas deben establecer sus responsabilidades y las de la organización en cuanto a seguridad de la información.

ISO 27001:2013

A.7.2.3 Proceso Disciplinario. Se debe contar con un proceso formal y comunicado para emprender acciones contra empleados que hayan cometido una violación a la seguridad de la información.

ISO 27001:2013

A.8.1.1 Inventario de Activos. Se deben identificar los activos con información e instalaciones de procesamiento de información, y se debe elaborar y mantener un inventario de estos Activos.

ISO 27001:2013

A.11.1.4 Protección contra amenazas externas y ambientales. Se debe diseñar y aplicar protección física contra desastres naturales, ataques maliciosos o accidentes

ISO 27001:2013

A.8.3.3 Transferencia de medios de soporte físicos. Los medios que contienen información se deben proteger contra acceso no autorizado, uso indebido o corrupción durante el transporte.

ISO 27001:2013

A.8.3.3 Transferencia de medios de soporte físicos. Los medios que contienen información se deben proteger contra acceso no autorizado, uso indebido o corrupción durante el transporte.

ISO 27001:2013

A.9.1.1 Política de Control de Acceso. Se debe establecer, documentar y revisar una política de control de acceso con base en los requisitos del negocio y de seguridad de la información.

ISO 27001:2013

A.9.1.2 Acceso a redes y a servicios en red. Solo se debe permitir acceso de los usuarios a la red y a los servicios de red para los cuales hayan sido autorizados específicamente.

ISO 27001:2013

A.9.2.1 Registro y cancelación del registro de usuarios. Se debe implementar un proceso formal de registro y de cancelación del registro para posibilitar la asignación de los derechos de acceso.

ISO 27001:2013

A.9.2.6 Cancelación o ajuste de los derechos de acceso. Los derechos de acceso de todos los empleados y de usuarios externos a la información y a las instalaciones de procedimiento de información se deben cancelar al terminar su empleo, contrato o acuerdo, o se deben ajustar cuando se hagan cambios.

ISO 27001:2013

A.9.4.2 Procedimiento de Conexión Segura. Cuando lo requiere la política de control de acceso, el acceso a sistemas y aplica ciones se debe controlar mediante un proceso de conexión segura.

ISO 27001:2013

A.11.1.1 Perímetro de Seguridad Física. Se deben definir y usar perímetros de seguridad, y usarlos para proteger áreas que contengan información confidencial o crítica, e instalaciones de manejo de información.

ISO 27001:2013

A.11.1.2 Controles Físicos de Entrada. Las áreas seguras se deben proteger mediante controles de entrada apropiados para asegurar que solamente se permite el acceso a personal autorizado.

ISO 27001:2013

A.11.2.3 Seguridad del cableado. El cableado y la potencia y de telecomunicaciones que porta datos o brinda soporte a los servicios de información se debe proteger contra interceptaciones, interferencia o daño.

ISO 27001:2013

A.11.2.4 Mantenimiento de equipos. Los equipos se deben mantener correctamente para asegurar su disponibilidad e integridad continuas.

ISO 27001:2013

A.11.2.4 Mantenimiento de equipos. Los equipos se deben mantener correctamente para asegurar su disponibilidad e integridad continuas.

112


ISO 27001:2013

A.11.2.5 Retiro de Activos. Los equipos, información o software no se deben retirar de su sitio sin autorización previa.

ISO 27001:2013

A.12.1.1 Procedimientos documentados. Los procedimientos operativos se deben documentar y poner a disposición de todos los usuarios que lo necesiten.

ISO 27001:2013

A.12.1.1 Procedimientos documentados. Los procedimientos operativos se deben documentar y poner a disposición de todos los usuarios que lo necesiten.

ISO 27001:2013

A.12.1.4 Separación de los ambientes de desarrollo, pruebas y producción. Esto permitirá reducir riesgos de acceso o cambios no autorizados en el ambiente de producción.

ISO 27001:2013 167 -CSA

A.12.1.4 Separación de los ambientes de desarrollo, pruebas y producción. Esto permitirá reducir riesgos de acceso o cambios no autorizados en el ambiente de producción.

ISO 27001:2013

A.12.3.1 Copias de respaldo de la información. Se deben realizar copias de respaldo de la información, software e imágenes de los sistemas y ponerlas a prueba regularmente de acuerdo con una política de copias de respaldo acordadas.

ISO 27001:2013

A.12.4.1 Registro de eventos. Se debe elaborar, conservar y revisar regularmente los registros de eventos acerca de actividades del usuario, excepciones, fallas y eventos de seguridad de la información.

ISO 27001:2013

A.12.4.4 Sincronización de relojes. Los relojes de todos los sistemas de procesamiento de información pertinentes dentro de una organización o ámbito de seguridad deben sincronizar con una única fuente de referencia de tiempo.

ISO 27001:2013

A.12.6.2 Restricciones sobre la instalación de Software. Se debe establecer e implementar el reglamento de instalación de software por parte de los usuarios.

ISO 27001:2013

A.12.6.2 Restricciones sobre la instalación de Software. Se debe establecer e implementar el reglamento de instalación de software por parte de los usuarios.

ISO 27001:2013

A.13.1.1 Controles de redes. Las redes se deben gestionar y controlar para proteger la información en sistemas y aplicaciones

ISO 27001:2013

A.13.1.3 Separación en las redes. Los grupos de servicios de información, usuarios y sistemas de información se deben separar en las redes.

ISO 27001:2013

A.6.1.5 Se deberían identificar, revisar regularmente y documentar los requisitos para los acuerdos de confidencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información

ISO 27001:2013

A.13.2.4 Acuerdos de confidencialidad o de no divulgación. Se deben identificar, revisar regularmente y documentar los requisitos para los acuerdos de confidencialidad o no divulgación que reflejen las necesidades de la organización para la protección de la información.

ISO 27001:2013

A.16.1.1 Responsabilidades y procedimientos. Se deben establecer las responsabilidades y procedimientos de gestión para asegurar una respuesta rápida, eficaz y ordenada a los incidentes de seguridad de la información.

ISO 27001:2013

A.16.1.3 Informe de debilidades de seguridad de la información. Se debe exigir a todos los empleados y contratistas que usan los servicios de la organización, que observen e informen cualquier debilidad de seguridad de la información observada o sospechosa en los sistemas o servicios.

ISO 27001:2013

A.16.1.5 Respuesta a incidentes de seguridad de la información. Se debe dar respuesta a los incidentes de seguridad de la información de acuerdo a procedimientos documentados.

ISO 27001:2013

A.17.1.1 Planificación de la continuidad de la seguridad de la información. La organización deberá determinar sus requisitos para la seguridad de la información y la continuidad del negocio en situaciones adversas, por ejemplo durante crisis o desastres.

ISO 27001:2013

A.17.2.1 Disponibilidad de instalaciones de procesamiento de información. Las instalaciones de procesamiento de información se deben implementar con redundancia suficiente para cumplir con los requisitos de disponibilidad.

113


ISO 27001:2013

A.18.1.1 Identificación de los requisitos de legislación contractuales aplicables. Se deben identificar todos los requisitos legislativos, estatutarios, de reglamentación y contractuales pertinentes, y el enfoque de la organización para cada sistema de información y la organización misma.

ISO 27001:2013

A.18.1.2 Derechos de Propiedad Intelectual. Se deben implementar procedimientos apropiados para asegurar el cumplimiento de los requisitos legislativos, de reglamentación y contractuales relacionados con los derechos de propiedad intelectual y el uso de productos de software licenciados.

ISO 27018:2014

En relación con los fines del tratamiento, el proveedor debe velar por el cumplimiento del tratamiento a los únicos usos descritos al cliente en el momento de la contratación del servicio, en particular garantizando que los datos no serán utilizados para fines distintos de los especificados por el cliente, ni para el propósito de marketing directo o publicitario, a menos que haya consentimiento explícito, consenso de que, en cualquier caso, nunca será un requisito establecido por el proveedor para la función del servicio.

ISO 27018:2014 Eliminar los archivos temporales.

ISO 27018:2014

Salvo que exista una prohibición establecida por la ley, la solicitud de divulgación de los datos personales por parte de las autoridades administrativas o judiciales será notificada sin demora al consumidor de servicios de nube

ISO 27018:2014 Grabar todas las revelaciones de los datos personales.

ISO 27018:2014

Revelar la información sobre todos los contratistas utilizados para procesar los datos personales.

ISO 27018:2014 Notificar al cliente inmediatamente en caso de que se produzca una violación de los datos.

ISO 27018:2014 Establecer una política de seguridad para el traslado y la eliminación de datos personales.

ISO 27018:2014 Será necesario contar con una autorización para utilizar los datos fuera de las instalaciones.

ISO 27018:2014 Deshabilitar la utilización de las identificaciones de los usuarios en caso de que caduquen.

ISO 27017:2014

Los proveedores deben disponer de funcionalidades que permitan a los clientes administrar, controlar y monitorear las funcionalidades por sí mismos, sin depender de la intervención del proveedor (por ejemplo, definir la clasificación de la información, administrar usuarios y supervisar el desempeño de los recursos).

114

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing 9.2 Anexo B - Lista de controles CSA

Dominio Control

Dominio 2 Los clientes de Cloud Services deben preguntar si su propia administración ha definido las tolerancias de riesgo con respecto a los servicios en la nube y ha aceptado cualquier riesgo residual de utilizar servicios en la nube.

Dominio 2

El entorno de la nube no es estático. Evoluciona, y las partes deben adaptarse. Se recomienda la supervisión periódica, las pruebas y la evaluación de los servicios, a fin de garantizar que se están utilizando las medidas de seguridad y privacidad necesarias, y se siguen los procesos y las políticas

Dominio 3

El entorno de la nube no es estático. Evoluciona, y las partes deben adaptarse. Se recomienda la supervisión periódica, las pruebas y la evaluación de los servicios, a fin de garantizar que se están utilizando las medidas de seguridad y privacidad necesarias, y se siguen los procesos y las políticas

Dominio 3

La preservación puede requerir que se retengan grandes volúmenes de datos durante períodos prolongados. ¿Cuáles son las ramificaciones de esto bajo el acuerdo de nivel de servicio ("SLA")? ¿Qué sucede si los requisitos de preservación duran más que los términos del SLA? Si el cliente conserva los datos en su lugar, ¿quién paga el almacenamiento ampliado y a qué costo?

Dominio 3 Las partes de un contrato de servicios en la nube deberían asegurarse de que el contrato se anticipa a los problemas relacionados con la recuperación de los datos del cliente una vez finalizada su relación contractual

Dominio 5 Cifre volúmenes con información delicada en IaaS para limitar la exposición debida a los snapshots o acceso no autorizado por administradores

Dominio 5 Cifre los datos delicados en el almacenamiento de objetos, generalmente con agente cifrado de archivo/carpeta.

Dominio 5 Cifre los datos delicados en las aplicaciones PaaS y el almacenamiento

Dominio 5

La eliminación de datos de un proveedor Cloud, ya sea debido a la expiración del contrato o cualquier otra razón, se debe cubrir en detalle en la creación del ANS. Esto debe abarcar la eliminación de cuentas de usuario, la migración o la eliminación de datos desde el almacenamiento primario/redundante, entrega de claves, etc

Dominio 6 Es necesario documentar la arquitectura de seguridad y la configuración de los controles individuales de seguridad de los componentes para que se puedan soportar las auditorías internas

Dominio 6 Es necesario entender como las imágenes de las máquinas virtuales pueden ser capturadas y trasladadas a nuevos proveedores de Cloud que usan diferentes tecnologías de virtualización. Por ejemplo Distributed Management Task Force (DMTF) Open Virtualization Format (OVF).

Dominio 6 La infraestructura privada local del usuario debería ser capaz de trabajar con los proveedores de Cloud externos. Un escenario común es el de la proliferación de Clouds donde una empresa comparte la carga con proveedores de Cloud externos para satisfacer los picos de demanda

115


Dominio 7 Comprobar si todos los documentos están vigentes y actualizados. Estos documentos deben ser revisados por el CSP al menos una vez al año. La fecha de revisión y la firma por parte de la Dirección deben ser incluidas y validadas como evidencia de la revisión interna

Dominio 7 asegurarse que los empleados reciben formación adecuada en materia de concienciación de seguridad como mínimo una vez al año

Dominio 7 Verificar los informes de auditoría interna y obtener evidencia de las acciones correctoras llevadas a cabo sobre las deficiencias

Dominio 7

Las instalaciones de los CSP deberían proteger tanto al personal como a los activos mediante la implementación de controles que protejan el entorno de peligros medioambientales. Estos controles pueden incluir, entre otros, los siguientes: controles de temperatura y humedad, detectores de humo y sistemas de supresión de incendios.

Dominio 7 Permitir únicamente al personal de mantenimiento llevar a cabo las reparaciones necesarias

Dominio 7 Pruebas de BCP/DR Dominio 7 Pruebas de BCP/DR

Dominio 10 La protección de los datos a lo largo de todo su ciclo de vida. Esto incluye tránsito, procesado y almacenamiento

Dominio 10 las organizaciones deben adoptar un conjunto de buenas prácticas de desarrollo

Dominio 10 Se ha establecido una política de seguridad y privacidad para las aplicaciones en cloud que cumple los requisitos de cumplimiento legal alineados con las necesidades de negocio y las obligaciones de regulación de la organización

Dominio 10 Se realizan evaluaciones del riesgo para la seguridad y la privacidad de todas las aplicaciones para asegurar que los requisitos están definidos correctamente

Dominio 10 Los comentarios deberían de ser eliminados del código en producción, y se debería de evitar incluir nombres y otro tipo de información personal

Dominio 10

Un test de intrusión o pentest es una metodología de pruebas de seguridad que ofrece al examinador una visión de la fortaleza de la seguridad de la red objetivo, simulando el ataque de un intruso empleando sus mismas tácticas y herramientas. El proceso implica un análisis activo del sistema Cloud en busca de cualquier vulnerabilidad potencial causada por una configuración pobre o deficiente del sistema, fallos conocidos y/o desconocidos del hardware/software y debilidades operacionales en los procesos o en las contramedidas técnicas

Dominio 10

Uno de los principales objetivos de las pruebas de interoperabilidad es la detección de problemas entre distintas aplicaciones Cloud antes de que éstas sean puestas en producción. Para poder realizar las pruebas de interoperabilidad es necesario que gran parte de la aplicación esté terminada.

Dominio 10 Realizar tests de intrusión de aplicaciones web con regularidad, revisando el Top10 de vulnerabilidades de OWASP.

Dominio 10 Test de multipropiedad (una extensión de la escalada de privilegios Dominio 10 OWASP en su “Guía de Test OWASP V3.0” recomienda nueve categorías de test activos de

seguridad: Dominio 11 las claves no deberían ser almacenadas en Cloud sino que deberían ser mantenidas por la

organización cliente

Dominio 11 No olvidar proteger aquellos ficheros que habitualmente se pasan por alto, pero que frecuentemente contienen información sensible. Por ejemplo, ficheros de log y metadatos pueden ser vías a través de las cuales se originen pérdidas de datos.

Dominio 12 El proceso de asignación de derechos (concesión de autorización) debería enfocarse en producir Reglas que sean simples y mínimas, y diseñadas usando el principio de mínimo privilegio

Dominio 12 Capa de sistema. Las reglas de asignación de derechos pueden definir los protocolos que se permiten para acceder y modificar sistemas, como por ejemplo servicios de terminal o web.

116


Dominio 12 Los Servicios y aplicaciones Cloud deben soportar la capacidad de consumir autenticación de una Fuente autoritativa mediante SAML.

Dominio 12

Donde sea necesario que los logs se integren en un sistema mayor (posiblemente remoto, como ejemplo un sistema de detección de fraude o de análisis de segregación de tareas) se garantice que la disponibilidad, actualización, formato y seguridad de la transmisión del log son las adecuadas

Dominio 12 Los clientes deben ser conscientes que los logs que contienen PII o SPI son susceptibles de ser objeto de las leyes de protección de datos.

Dominio 12 minimizar el uso y almacenamiento de PII o SPI Dominio 13 Los implementadores deberían cifrar las imágenes de máquinas virtuales cuando no estén en

uso.

Dominio 13

Los implementadores deberían estudiar la eficacia y la viabilidad de la segregación de VM y la creación de zonas de seguridad por tipo de uso (por ejemplo, escritorio frente a servidor), la etapa de producción (por ejemplo, desarrollo, producción y pruebas), y la delicadeza de los datos mediante componentes de hardware físicamente separados tales como servidores, almacenamiento, etc.

Dominio 13 Los implementadores deberían considerar el parchear las imágenes de máquinas virtuales en reposo o proteger las nuevas hasta que se puedan parchear.

Dominio 13 Los usuarios deben validar el pedigrí y la integridad de cualquier imagen o plantilla de VM procedente de cualquier tercero, o mejor aún, crear sus propias instancias de VM.

Dominio 14 Los Gestores de Información y Eventos de Seguridad (SIEM) centralizan (ya sea en modo pull o en modo push) logs y otros registros de eventos, generados por redes, aplicaciones y sistemas reales y virtuales

Dominio 14 Los proveedores de IaaS deben proporcionar a sus clientes de servicios Cloud un control de acceso y auditoría unificados.

117

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing 9.3 Anexo C - Mapeo ISO/IEC 27001 a NIST SP800-53

ISO/IEC 27001 CONTROLS NIST SP 800-53 CONTROLS Note: An asterisk (*) indicates that the ISO/IEC control does not fully satisfy the intent of the NIST control.

A.5 Information Security Policies

A.5.1 Management direction for information security

A.5.1.1 Policies for information security All XX-1 controls

A.5.1.2 Review of the policies for information security All XX-1 controls

A.6 Organization of information security

A.6.1 Internal organization

A.6.1.1 Information security roles and responsibilities All XX-1 controls, CM-9, CP-2,PS-7, SA-3, SA-9, PM- 2, PM-10

A.6.1.2 Segregation of duties AC-5

A.6.1.3 Contact with authorities IR-6

A.6.1.4 Contact with special interest groups SI-5, PM-15

A.6.1.5 Information security in project management SA-3, SA-9, SA-15

A.6.2 Mobile devices and teleworking

A.6.2.1 Mobile device policy AC-17, AC-18, AC-19

A.6.2.2 Teleworking AC-3, AC-17, PE-17

A.7 Human Resources Security

A.7.1 Prior to Employment

A.7.1.1 Screening PS-3, SA-21

A.7.1.2 Terms and conditions of employment PL-4, PS-6

A.7.2 During employment

A.7.2.1 Management responsibilities PL-4, PS-6, PS-7, SA-9

A.7.2.2 Information security awareness, education, and training AT-2, AT-3, CP-3, IR-2, PM-13

A.7.2.3 Disciplinary process PS-8

A.7.3 Termination and change of employment

A.7.3.1 Termination or change of employment responsibilities PS-4, PS-5

A.8 Asset Management

A.8.1 Responsibility for assets

A.8.1.1 Inventory of assets CM-8

A.8.1.2 Ownership of assets CM-8

A.8.1.3 Acceptable use of assets PL-4

A.8.1.4 Return of assets PS-4, PS-5

A.8.2 Information Classification

A.8.2.1 Classification of information RA-2

A.8.2.2 Labelling of Information MP-3

A.8.2.3 Handling of Assets MP-2, MP-4, MP-5, MP-6, MP-7, PE-16, PE-18, PE- 20, SC-8, SC-28

A.8.3 Media Handling

A.8.3.1 Management of removable media MP-2, MP-4, MP-5, MP-6, MP-7

A.8.3.2 Disposal of media MP-6

118


A.8.3.3 Physical media transfer MP-5

A.9 Access Control

A.9.1 Business requirement of access control

A.9.1.1 Access control policy AC-1

A.9.1.2 Access to networks and network services AC-3, AC-6

A.9.2 User access management

A.9.2.1 User registration and de-registration AC-2, IA-2, IA-4, IA-5, IA-8

A.9.2.2 User access provisioning AC-2

A.9.2.3 Management of privileged access rights AC-2, AC-3, AC-6, CM-5

A.9.2.4 Management of secret authentication information of users IA-5

A.9.2.5 Review of user access rights AC-2

A.9.2.6 Removal or adjustment of access rights AC-2

A.9.3 User responsibilities

A.9.3.1 Use of secret authentication information IA-5

A.9.4 System and application access control

A.9.4.1 Information access restriction AC-3, AC-24

A.9.4.2 Secure logon procedures AC-7, AC-8, AC-9, IA-6

A.9.4.3 Password management system IA-5

A.9.4.4 Use of privileged utility programs AC-3, AC-6

A.9.4.5 Access control to program source code AC-3, AC-6, CM-5

A.10 Cryptography

A.10.1 Cryptographic controls

A.10.1.1 Policy on the use of cryptographic controls SC-13

A.10.1.2 Key Management SC-12, SC-17

A.11 Physical and environmental security

A.11.1 Secure areas

A.11.1.1 Physical security perimeter PE-3*

A.11.1.2 Physical entry controls PE-2, PE-3, PE-4, PE-5

A.11.1.3 Securing offices, rooms and facilities PE-3, PE-5

A.11.1.4 Protecting against external and environmental threats CP-6, CP-7, PE-9, PE-13, PE-14, PE-15, PE-18, PE- 19

A.11.1.5 Working in secure areas SC-42(3)*

A.11.1.6 Delivery and loading areas PE-16

A.11.2 Equipment

A.11.2.1 Equipment siting and protection PE-9, PE-13, PE-14, PE-15, PE-18, PE-19

A.11.2.2 Supporting utilities CP-8, PE-9, PE-10, PE-11, PE-12, PE-14, PE-15

A.11.2.3 Cabling security PE-4, PE-9

A.11.2.4 Equipment maintenance MA-2, MA-6

A.11.2.5 Removal of assets MA-2, MP-5, PE-16

A.11.2.6 Security of equipment and assets off-premises AC-19, AC-20, MP-5, PE-17

A.11.2.7 Secure disposal or reuse of equipment MP-6

A.11.2.8 Unattended user equipment AC-11

A.11.2.9 Clear desk and clear screen policy AC-11, MP-2, MP-4

119


A.12 Operations security

A.12.1 Operational procedures and responsibilities

A.12.1.1 Documented operating procedures All XX-1 controls, SA-5

A.12.1.2 Change management CM-3, CM-5, SA-10

A.12.1.3 Capacity management AU-4, CP-2(2), SC-5(2)

A.12.1.4 Separation of development, testing, and operational environments

CM-4(1)*, CM-5*

A.12.2 Protection from malware

A.12.2.1 Controls against malware AT-2, SI-3

A.12.3 Backup

A.12.3.1 Information backup CP-9

A.12.4 Logging and monitoring

A.12.4.1 Event logging AU-3, AU-6, AU-11, AU-12, AU-14

A.12.4.2 Protection of log information AU-9

A.12.4.3 Administrator and operator logs AU-9, AU-12

A.12.4.4 Clock synchronization AU-8

A.12.5 Control of operational software

A.12.5.1 Installation of software on operational systems CM-5, CM-7(4), CM-7(5), CM-11

A.12.6 Technical vulnerabilitymanagement

A.12.6.1 Management of technical vulnerabilities RA-3, RA-5, SI-2, SI-5

A.12.6.2 Restrictions on software installation CM-11

A.12.7 Information systems audit considerations

A.12.7.1 Information systems audit controls AU-5*

A.13 Communications security

A.13.1 Network securitymanagement

A.13.1.1 Network controls AC-3, AC-17, AC-18, AC-20, SC-7, SC-8, SC-10

A.13.1.2 Security of network services CA-3, SA-9

A.13.1.3 Segregation in networks AC-4, SC-7

A.13.2 Information transfer

A.13.2.1 Information transfer policies and procedures AC-4, AC-17, AC-18, AC-19, AC-20, CA-3, PE-17, SC-7, SC-8, SC-15

A.13.2.2 Agreements on information transfer CA-3, PS-6, SA-9

A.13.2.3 Electronic messaging SC-8

A.13.2.4 Confidentiality or nondisclosure agreements PS-6

A.14 System acquisition, development and maintenance

A.14.1 Security requirements of information systems

A.14.1.1 Information security requirements analysis and specification PL-2, PL-7, PL-8, SA-3, SA-4

A.14.1.2 Securing application services on public networks AC-3, AC-4, AC-17, SC-8, SC-13

A.14.1.3 Protecting application services transactions AC-3, AC-4, SC-7, SC-8, SC-13

A.14.2 Security in development and support processes

A.14.2.1 Secure development policy SA-3, SA-15, SA-17

A.14.2.2 System change control procedures CM-3, SA-10, SI-2

120


A.14.2.3 Technical review of applications after operating platform changes

CM-3, CM-4, SI-2

A.14.2.4 Restrictions on changes to software packages CM-3, SA-10

A.14.2.5 Secure system engineering principles SA-8

A.14.2.6 Secure development environment SA-3*

A.14.2.7 Outsourced development SA-4, SA-10, SA-11, SA-12, SA-15

A.14.2.8 System security testing CA-2, SA-11

A.14.2.9 System acceptance testing SA-4, SA-12(7)

A.14.3 Test data

A.14.3.1 Protection of test data SA-15(9)*

A.15 Supplier Relationships

A.15.1 Information security in supplier relationships

A.15.1.1 Information security policy for supplier relationships SA-12

A.15.1.2 Address security within supplier agreements SA-4, SA-12

A.15.1.3 Information and communication technology supply chain SA-12

A.15.2 Supplier service deliverymanagement

A.15.2.1 Monitoring and review of supplier services SA-9

A.15.2.2 Managing changes to supplier services SA-9

A.16 Information security incident management

A.16.1 Managing of information security incidents and improvements

A.16.1.1 Responsibilities and procedures IR-8

A.16.1.2 Reporting information security events AU-6, IR-6

A.16.1.3 Reporting information security weaknesses SI-2

A.16.1.4 Assessment of and decision on information security events AU-6, IR-4

A.16.1.5 Response to information security incidents IR-4

A.16.1.6 Learning from information security incidents IR-4

A.16.1.7 Collection of evidence AU-4*, AU-9*, AU-10(3)*, AU-11*

A.17 Information security aspects of business continuity management

A.17.1 Information security continuity

A.17.1.1 Planning information security continuity CP-2

A.17.1.2 Implementing information security continuity CP-6, CP-7, CP-8, CP-9, CP-10, CP-11, CP-13

A.17.1.3 Verify, review, and evaluate information security continuity CP-4

A.17.2 Redundancies

A.17.2.1 Availability of information processing facilities CP-2,CP-6, CP-7

A.18 Compliance

A.18.1 Compliance with legal and contractual requirements

A.18.1.1 Identification of applicable legislation and contractual requirements

All XX-1 controls

A.18.1.2 Intellectual property rights CM-10

A.18.1.3 Protection of records AC-3, AC-23, AU-9, AU-10, CP-9, SC-8, SC-8(1), SC-13, SC-28, SC-28(1)

A.18.1.4 Privacy and protection of personal information Appendix J Privacy controls

121


A.18.1.5 Regulation of cryptographic controls IA-7, SC-12, SC-13, SC-17

A.18.2 Information security reviews

A.18.2.1 Independent review of information security CA-2(1), SA-11(3)

A.18.2.2 Compliance with security policies and standards All XX-1 controls, CA-2

A.18.2.3 Technical compliance review CA-2

122

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing 9.4 Anexo D - Guía de controles y líneas base del NIST

N° ID CTRL NOMBRE DEL CONTROL

BAJO MODERADO ALTO

Ctrl MEJORAS Ctrl MEJORAS Ctrl MEJORAS

1 AC-1 Access Control Policy and Procedures AC-1 AC-1 AC-1

2 AC-2 Account Management AC-2 AC-2 1 2 3 4 AC-2 1 2 3 4 11 12 13

3 AC-3 Access Enforcement AC-3 AC-3 AC-3

4 AC-4 Information Flow Enforcement NA AC-4 AC-4

5 AC-5 Separation of Duties NA AC-5 AC-5

6 AC-6 Least Privilege NA AC-6 1 2 5 9 10 AC-6 1 2 3 5 9 10

7 AC-7 Unsuccessful Login Attempts AC-7 AC-7 AC-7

8 AC-8 System Use Notification AC-8 AC-8 AC-8

9 AC-9 Previous Logon (Access) Notification NA NA NA

10 AC-10 Concurrent Session Control NA NA AC-10

11 AC-11 Session Lock NA AC-11 1 AC-11 1

12 AC-12 Session Termination NA AC-12 AC-12

13 AC-14 Permitted Actions Without Identification Or Authentication

AC-14 AC-14 AC-14

14 AC-16 Security Attributes NA NA NA

15 AC-17 Remote Access AC-17 AC-17 1 2 3 4 AC-17 1 2 3 4

16 AC-18 Wireless Access AC-18 AC-18 1 AC-18 1 4 5

17 AC-19 Access Control for Mobile Devices AC-19 AC-19 5 AC-19 5

18 AC-20 Use of External Information Systems AC-20 AC-20 1 2 AC-20 1 2

19 AC-21 User-based Collaboration and Information Sharing NA AC-21 AC-21

20 AC-22 Publicly Accessible Content AC-22 AC-22 AC-22

21 AC-23 Data Mining Protection NA NA NA

22 AC-24 Access Control Decisions NA NA NA

23 AC-25 Reference Monitor NA NA NA

24 AT-1 Security Awareness and Training Policy and Procedures

AT-1 AT-1 AT-1

25 AT-2 Security Awareness AT-2 AT-2 2 AT-2 2

26 AT-3 Security Training AT-3 AT-3 AT-3

27 AT-4 Security Training Records AT-4 AT-4 AT-4

28 AU-1 Audit and Accountability Policy and Procedures AU-1 AU-1 AU-1

29 AU-2 Auditable Events AU-2 AU-2 3 AU-2 3

30 AU-3 Content of Audit Records AU-3 AU-3 1 AU-3 1 2

31 AU-4 Audit Storage Capacity AU-4 AU-4 AU-4

32 AU-5 Response To Audit Processing Failures AU-5 AU-5 AU-5 1 2

33 AU-6 Audit Review, Analysis, and Reporting AU-6 AU-6 1 3 AU-6 1 3 5 6

34 AU-7 Audit Reduction and Report Generation NA AU-7 1 AU-7 1

123


35 AU-8 Time Stamps AU-8 AU-8 1 AU-8 1

36 AU-9 Protection of Audit Information AU-9 AU-9 4 AU-9 2 3 4

37 AU-10 Non-repudiation NA NA AU-10

38 AU-11 Audit Record Retention AU-11 AU-11 AU-11

39 AU-12 Audit Generation AU-12 AU-12 AU-12 1 3

40 AU-13 Monitoring for Information Disclosure NA NA NA

41 AU-14 Session Audit NA NA NA

42 AU-15 Alternate Audit Capability AU-16 NA NA NA

43 AU-16 Cross-Organizational Auditing NA NA NA

44 CA-1 Security Assessment and Authorization Policies and Procedures

CA-1 CA-1 CA-1

55 CA-2 Security Assessments CA-2 CA-2 1 CA-2 1 2

46 CA-3 Information System Connections CA-3 CA-3 5 CA-3 5

47 CA-5 Plan of Action and Milestones CA-5 CA-5 CA-5

48 CA-6 Security Authorization CA-6 CA-6 CA-6

49 CA-7 Continuous Monitoring CA-7 CA-7 1 CA-7 1

50 CA-8 Penetration Testing NA NA CA-8

51 CA-9 Internal System Connections CA-9 CA-9 CA-9

52 CM-1 Configuration Management Policy and Procedures CM-1 CM-1 CM-1

53 CM-2 Baseline Configuration CM-2 CM-2 1 3 7 CM-2 1 2 3 7

54 CM-3 Configuration Change Control NA CM-3 2 CM-3 1 2

55 CM-4 Security Impact Analysis CM-4 CM-4 CM-4 1

56 CM-5 Access Restrictions for Change NA CM-5 CM-5 1 2 3

57 CM-6 Configuration Settings CM-6 CM-6 CM-6 1 2

58 CM-7 Least Functionality CM-7 CM-7 1 2 4 CM-7 1 2 5

59 CM-8 Information System Component Inventory CM-8 CM-8 1 3 5 CM-8 1 2 3 4 5

60 CM-9 Configuration Management Plan NA CM-9 CM-9

61 CM-10 Software Usage Restrictions CM-10 CM-10 CM-10

62 CM-11 User-Installed Software CM-11 CM-11 CM-11

63 CP-1 Contingency Planning Policy and Procedures CP-1 CP-1 CP-1

64 CP-2 Contingency Plan CP-2 CP-2 1 3 8 CP-2 1 2 3 4 5 8

65 CP-3 Contingency Training CP-3 CP-3 CP-3 1

66 CP-4 Contingency Plan Testing and Exercises CP-4 CP-4 1 CP-4 1 2

67 CP-6 Alternate Storage Site NA CP-6 1 3 CP-6 1 2 3

68 CP-7 Alternate Processing Site NA CP-7 1 2 3 CP-7 1 2 3 4

69 CP-8 Telecommunications Services NA CP-8 1 2 CP-8 1 2 3 4

70 CP-9 Information System Backup CP-9 CP-9 1 CP-9 1 2 3 5

71 CP-10 Information System Recovery and Reconstitution CP-10 CP-10 2 CP-10 2 4

72 CP-11 Alternate Communications Protocols NA NA NA

73 CP-12 Safe Mode NA NA NA

74 CP-13 Alternative Security Mechanisms NA NA NA

124


75 IA-1 Identification and Authentication Policy and Procedures

IA-1 IA-1 IA-1

76 IA-2 Identification and Authentication (Organizational Users)

IA-2 1 12 IA-2 1 2 3 8 11 12 IA-2 1 2 3 4 8 9 11 12

77 IA-3 Device Identification and Authentication NA IA-3 IA-3

78 IA-4 Identifier Management IA-4 IA-4 IA-4

79 IA-5 Authenticator Management IA-5 1 11 IA-5 1 2 3 11 IA-5 1 2 3 11

80 IA-6 Authenticator Feedback IA-6 IA-6 IA-6

81 IA-7 Cryptographic Module Authentication IA-7 IA-7 IA-7

82 IA-8 Identification and Authentication (Non-organizational Users)

IA-8 1 2 3 4 IA-8 1 2 3 4 IA-8 1 2 3 4

83 IA-9 Service Identification and Authentication NA NA NA

84 IA-10 Adaptive Identification and Authentication NA NA NA

85 IA-11 Re-authentication NA NA NA

86 IR-1 Incident Response Policy and Procedures IR-1 IR-1 IR-1

87 IR-2 Incident Response Training IR-2 IR-2 IR-2 1 2

88 IR-3 Incident Response Testing and Exercises NA IR-3 2 IR-3 2

89 IR-4 Incident Handling IR-4 IR-4 1 IR-4 1 4

90 IR-5 Incident Monitoring IR-5 IR-5 IR-5 1

91 IR-6 Incident Reporting IR-6 IR-6 1 IR-6 1

92 IR-7 Incident Response Assistance IR-7 IR-7 1 IR-7 1

93 IR-8 Incident Response Plan IR-8 IR-8 IR-8

94 IR-9 Information Spillage Response NA NA NA

95 IR-10 Integrated Information Security Analysis Team NA NA NA

96 MA-1 System Maintenance Policy and Procedures MA-1 MA-1 MA-1

97 MA-2 Controlled Maintenance MA-2 MA-2 MA-2 2

98 MA-3 Maintenance Tools NA MA-3 1 2 MA-3 1 2 3

99 MA-4 Non-local Maintenance MA-4 MA-4 2 MA-4 2 3

100 MA-5 Maintenance Personnel MA-5 MA-5 MA-5 1

101 MA-6 Timely Maintenance NA MA-6 MA-6

102 MP-1 Media Protection Policy and Procedures MP-1 MP-1 MP-1

103 MP-2 Media Access MP-2 MP-2 MP-2

104 MP-3 Media Marking NA MP-3 MP-3

105 MP-4 Media Storage NA MP-4 MP-4

106 MP-5 Media Transport NA MP-5 4 MP-5 4

107 MP-6 Media Sanitization MP-6 MP-6 MP-6 1 2 3

108 MP-7 Media Use MP-7 MP-7 1 MP-7 1

109 MP-8 Media Downgrading NA NA NA

110 PE-1 Physical and Environmental Protection Policy and Procedures

PE-1 PE-1 PE-1

111 PE-2 Physical Access Authorizations PE-2 PE-2 PE-2

112 PE-3 Physical Access Control PE-3 PE-3 PE-3 1

125


113 PE-4 Access Control for Transmission Medium NA P3-4 PE-4

114 PE-5 Access Control for Output Devices NA PE-5 PE-5

115 PE-6 Monitoring Physical Access PE-6 PE-6 1 PE-6 1 4

116 PE-8 Access Records PE-8 PE-8 PE-8 1

117 PE-9 Power Equipment and Power Cabling NA PE-9 PE-9

118 PE-10 Emergency Shutoff NA PE-10 PE-10

119 PE-11 Emergency Power NA PE-11 PE-11 1

120 PE-12 Emergency Lighting PE-12 PE-12 PE-12

121 PE-13 Fire Protection PE-13 PE-13 3 PE-13 1 2 3

122 PE-14 Temperature and Humidity Controls PE-14 PE-14 PE-14

123 PE-15 Water Damage Protection PE-15 PE-15 PE-15 1

124 PE-16 Delivery and Removal PE-16 PE-16 PE-16

125 PE-17 Alternate Work Site NA PE-17 PE-17

126 PE-18 Location of Information System Components NA NA PE-18

127 PE-19 Information Leakage NA NA NA

128 PE-20 Asset Monitoring and Tracking NA NA NA

129 PL-1 Security Planning Policy and Procedures PL-1 PL-1 PL-1

130 PL-2 System Security Plan PL-2 PL-2 3 PL-2 3

131 PL-4 Rules of Behavior PL-4 PL-4 1 PL-4 1

132 PL-7 Security Concept of Operations PL-8 NA NA NA

133 PL-8 Information Security Architecture NA NA NA

134 PL-9 Central Management NA NA NA

135 PS-1 Personnel Security Policy and Procedures PS-1 PS-1 PS-1

136 PS-2 Position Categorization PS-2 PS-2 PS-2

137 PS-3 Personnel Screening PS-3 PS-3 PS-3

138 PS-4 Personnel Termination PS-4 PS-4 PS-4 2

139 PS-5 Personnel Transfer PS-5 PS-5 PS-5

140 PS-6 Access Agreements PS-6 PS-6 PS-6

141 PS-7 Third-party Personnel Security PS-7 PS-7 PS-7

142 PS-8 Personnel Sanctions PS-8 PS-8 PS-8

143 RA-1 Risk Assessment Policy and Procedures RA-1 RA-1 RA-1

144 RA-2 Security Categorization RA-2 RA-2 RA-2

155 RA-3 Risk Assessment RA-3 RA-3 RA-3

146 RA-5 Vulnerability Scanning RA-5 RA-5 1 2 5 RA-5 1 2 4 5

147 RA-6 Technical Surveillance Countermeasures Survey NA NA NA

148 SA-1 System and Services Acquisition Policy and Procedures

SA-1 SA-1 SA-1

149 SA-2 Allocation of Resources SA-2 SA-2 SA-2

150 SA-3 Life Cycle Support SA-3 SA-3 SA-3

151 SA-4 Acquisitions SA-4 10 SA-4 1 2 9 10 SA-4 1 2 9 10

152 SA-5 Information System Documentation SA-5 SA-5 SA-5

153 SA-8 Security Engineering Principles NA SA-8 SA-8

126


154 SA-9 External Information System Services SA-9 SA-9 2 SA-9 2

155 SA-10 Developer Configuration Management NA SA-10 SA-10

156 SA-11 Developer Security Testing NA SA-11 SA-11

157 SA-12 Supply Chain Protection NA NA SA-12

158 SA-13 Trustworthiness NA NA NA

159 SA-14 Critical Information System Components NA NA NA

160 SA-15 Development Process, Standards, and Tools NA NA SA-15

161 SA-16 Developer-Provided Training NA NA SA-16

162 SA-17 Developer Security Architecture and Design NA NA SA-17

163 SA-18 Tamper Resistance and Detection NA NA NA

164 SA-19 Component Authenticity NA NA NA

165 SA-20 Customized Development of Critical Components NA NA NA

166 SA-21 Developer Screening NA NA NA

167 SA-22 Unsupported System Components NA NA NA

168 SC-1 System and Communications Protection Policy and Procedures

SC-1 SC-1 SC-1

169 SC-2 Application Partitioning NA SC-2 SC-2

170 SC-3 Security Function Isolation NA NA SC-3

171 SC-4 Information In Shared Resources NA SC-4 SC-4

172 SC-5 Denial of Service Protection SC-5 SC-5 SC-5

173 SC-6 Resource Priority NA NA NA

174 SC-7 Boundary Protection SC-7 SC-7 3 4 5 7 SC-7 3 4 5 7 8 18 21

175 SC-8 Transmission Integrity NA SC-8 1 SC-8 1

176 SC-10 Network Disconnect NA SC-10 SC-10

177 SC-11 Trusted Path NA NA NA

178 SC-12 Cryptographic Key Establishment and Management SC-12 SC-12 SC-12 1

179 SC-13 Use of Cryptography SC-13 SC-13 SC-13

180 SC-15 Collaborative Computing Devices SC-15 SC-15 SC-15

181 SC-16 Transmission of Security Attributes NA NA NA

182 SC-17 Public Key Infrastructure Certificates NA SC-17 SC-17

183 SC-18 Mobile Code NA SC-18 SC-18

184 SC-19 Voice Over Internet Protocol NA SC-19 SC-19

185 SC-20 Secure Name / Address Resolution Service (Authoritative Source)

SC-20 SC-20 SC-20

186 SC-21 Secure Name / Address Resolution Service (Recursive Or Caching Resolver)

SC-21 SC-21 SC-21

187 SC-22 Architecture and Provisioning for Name / Address Resolution Service

SC-22 SC-22 SC-22

188 SC-23 Session Authenticity NA SC-23 SC-23

189 SC-24 Fail In Known State NA NA SC-24

127


190 SC-25 Thin Nodes NA NA NA

191 SC-26 Honeypots NA NA NA

192 SC-27 Operating System-independent Applications NA NA NA

193 SC-28 Protection of Information At Rest NA SC-28 SC-28

194 SC-29 Heterogeneity NA NA NA

195 SC-30 Virtualization Techniques NA NA NA

196 SC-31 Covert Channel Analysis NA NA NA

197 SC-32 Information System Partitioning NA NA NA

198 SC-34 Non-modifiable Executable Programs NA NA NA

199 SC-35 Honeyclients NA NA NA

200 SC-36 Distributed Processing and Storage NA NA NA

201 SC-37 Out-of-Band Channels NA NA NA

202 SC-38 Operations Security SC-39 NA NA NA

203 SC-39 Process Isolation NA SC-39 SC-39

204 SC-40 Wireless Link Protection SC-41 NA NA NA

205 SC-41 Port and I/O Device Access NA NA NA

206 SC-42 Sensor Capability and Data NA NA NA

207 SC-43 Usage Restrictions NA NA NA

208 SC-44 Detonation Chambers NA NA NA

209 SI-1 System and Information Integrity Policy and Procedures

SI-1 SI-1 SI-1

210 SI-2 Flaw Remediation SI-2 SI-2 2 SI-2 1 2

211 SI-3 Malicious Code Protection SI-3 SI-3 1 2 SI-3 1 2

212 SI-4 Information System Monitoring SI-4 SI-4 2 4 5 SI-4 2 4 5

213 SI-5 Security Alerts, Advisories, and Directives SI-5 SI-5 SI-5 1

214 SI-6 Security Functionality Verification NA NA SI-6

215 SI-7 Software and Information Integrity NA SI-7 1 7 SI-7 1 2 5 7 14

216 SI-8 Spam Protection NA SI-8 1 2 SI-8 1 2

217 SI-10 Information Input Validation NA SI-10 SI-10

218 SI-11 Error Handling NA SI-11 SI-11

219 SI-12 Information Output Handling and Retention SI-12 SI-12 SI-12

220 SI-13 Predictable Failure Prevention NA NA NA



223 SI-16 Predictable Failure Prevention NA SI-16 SI-16


128

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing 9.5 Anexo E - Lista de preguntas para evaluación de controles

RECURSOS MODELO DE SERVICIO Fuente Pregunta Rspta

(%) F D R I P S

X X X X X X ISO 27001:2013

¿Se han definido perfiles y responsabilidades relacionadas con la seguridad de la información? 0

X X X X X X ISO 27001:2013

¿Se encuentran estipuladas las responsabilidades asociadas a la seguridad de la información en los acuerdos/contratos de los empleados?

0

X X X X X X ISO 27001:2013

¿Existe algún proceso disciplinario para los empleados que cometan alguna violación a la seguridad de la información? 0

X NA NA X X X ISO 27001:2013

¿En qué porcentaje estima que se encuentra documentado el inventario de equipos? 75

X NA NA X X X ISO 27001:2013

¿El Centro de datos se encuentra ubicado en una estructura sismorresistente? 0

X X NA X X X ISO 27001:2013

Al momento de transportar medios físicos que contienen información ¿qué porcentaje de ellos han contado con medidas de protección contra el acceso no autorizado?

25

X X NA X X X ISO 27001:2013

Al momento de transportar medios físicos que contienen información ¿qué porcentaje de ellos han contado con medidas de protección contra corrupción de la información?

25

X X NA X X X ISO 27001:2013

¿Existe alguna directriz o política de seguridad relacionada con el Control de Acceso al Centro de Datos? 100

NA X X X X X ISO 27001:2013

¿En qué porcentaje estima la posibilidad de que únicamente usuarios autorizados puedan acceder a los segmentos de red que hacen parte de la nube?

75

X X NA X X X ISO 27001:2013

¿Se cuenta con un proceso de registro y cancelación de usuarios para controlar los derechos de acceso al Centro de Datos? 100

5 X NA X X X ISO 27001:2013

¿En cuánto estima el porcentaje de usuarios (empleados, visitantes, etc.) cuyo ingreso al Centro de Datos ha sido debidamente autorizado y supervisado?

100

X X NA X X X ISO 27001:2013

¿En qué porcentaje se han cancelado los derechos de acceso a los empleados cuyo contrato, acuerdo o vínculo con la organización ha culminado?

90

X X NA X X X ISO 27001:2013

¿En qué porcentaje están ajustados los derechos de acceso de usuarios de acuerdo a sus funciones 20

NA NA X X X X ISO 27001:2013

¿Qué porcentajes de usuarios externos utilizan procedimientos de conexión segura para acceder a los servicios? 100

NA NA X X X X ISO 27001:2013

¿Qué porcentajes de usuarios internos utilizan procedimientos de conexión segura para acceder a los servicios? 100

X X NA X X X ISO 27001:2013

¿En qué porcentaje las áreas donde se encuentran los recursos de información cuentan con barreras contra accesos no autorizados? 50

X X NA X X X ISO 27001:2013

¿Existen controles en las entradas del Centro de Datos que permitan acceso solamente a personal autorizado? 100

129


X NA NA X X X ISO 27001:2013

Considerando los siguientes factores de autenticación: Factor 1 - Algo qué conoce: contraseñas, PIN, Códigos, etc. Factor 2 - Algo qué tiene: token, tarjeta, USB, etc. Factor 3 - Algo que es: uso de dispositivos biométricos ¿Qué porcentaje de ellos se utiliza para acceder al Centro de Datos?

100

X NA NA X X X ISO 27001:2013 ¿Se lleva registro de visitantes que ingresan al centro de datos? 0

X NA NA X X X ISO 27001:2013

¿Se lleva registro de personal de mantenimiento que ingresa al centro de datos? 0

X NA NA X X X ISO 27001:2013

¿Qué porcentaje de equipos del Centro de Datos están protegidos contra fallas de potencia y otras interrupciones que se puedan originar por problemas con los servicios públicos de soporte?

0

X NA X X X X ISO 27001:2013

¿El cableado de redes está protegido contra interceptaciones y daños? 0

X NA NA X X X ISO 27001:2013

¿Qué porcentaje de los equipos del Centro de Datos reciben mantenimiento preventivo? 50

X NA NA X X X CSA V3 Dominio 7

¿Se lleva un registro detallado de los mantenimientos preventivos realizados? 100

X NA NA X X X ISO 27001:2013

¿Qué porcentaje de equipos del Centro de Datos NO ha necesitado mantenimiento correctivo? 10


¿Se lleva un registro detallado de los mantenimientos correctivos realizados? 100

X NA NA X X X ISO 27001:2013 ¿Qué porcentaje de los equipos cuentan con garantía? 10

X NA NA X X X ISO 27001:2013 ¿Porcentaje de equipos/software retirados con autorización previa? 5

X X X X X X ISO 27001:2013

¿En qué porcentaje están definidos y documentados los procedimientos operativos? 50

X X X X X X ISO 27001:2013

¿La documentación de procedimientos está a disposición de todos los usuarios que lo necesiten? 100

NA X X X X X ISO 27001:2013

Para la implementación de los servicios ofrecidos en la nube ¿se cuenta con un ambiente de Desarrollo? 100

NA X X X X X ISO 27001:2013

Para la implementación de los servicios ofrecidos por la nube ¿se cuenta con un ambiente de Pruebas? 100

NA x NA X X X ISO 27001:2013

De acuerdo a la política de backups o procedimientos establecidos ¿Qué porcentaje de los backups realizados se han sometido a pruebas para verificar su integridad?

5

NA X X X X X ISO 27001:2013 ¿Existe un registro de ocurrencia de las fallas presentadas? 0

NA X X X X X ISO 27001:2013 ¿Se cuenta con un registro de actividades de usuario? 0

NA X X X X X ISO 27001:2013

Para evitar desfases de tiempo ¿Están sincronizados los relojes de los sistemas de procesamiento de información con única fuente de referencia de tiempo?

100

NA X NA X x X ISO 27001:2013

¿Existe alguna reglamentación para la instalación de software por parte de los usuarios en los servicios ofrecidos? 100

NA X NA X x X ISO 27001:2013

¿Qué porcentaje del personal interno sigue la reglamentación establecida para la instalación de software en los equipos del Centro de Datos?

50

NA NA X X X X ISO 27001:2013 ¿Existe control y monitoreo de las redes? 100

130


NA NA X X X X ISO 27001:2013

¿Se encuentran separadas las redes de usuarios, sistemas de información y demás redes dedicadas a actividades específicas e independientes?

100

NA X NA X x X ISO 27001:2013

¿Con qué porcentaje de los empleados/contratistas del Centro de Datos existen acuerdos de confidencialidad? 0

NA X NA X x X ISO 27001:2013

¿Los acuerdos de confidencialidad y no divulgación se actualizan periódicamente? 0

X X X X X X ISO 27001:2013

¿En qué porcentaje están definidas las responsabilidades y los procedimientos a ejecutar durante los incidentes de seguridad de la información?

5

NA X X X X X ISO 27001:2013

¿Se exige a los empleados/contratistas del Centro de Datos y a los usuarios de los servicios, reportar cualquier debilidad o anomalía relacionada con la seguridad de la información que identifiquen?

100

X X X X X X ISO 27001:2013

¿En qué porcentaje está definido un procedimiento de respuesta a incidentes en el Centro de Datos? 5

X X X X X X ISO 27001:2013

¿En qué porcentaje está definido un Plan de Continuidad del negocio para hacer frente a desastres o interrupciones críticas de los servicios? (objeto, alcance, responsables, actividades)

0

X X X X X X CSA V3 Dominio 7

¿En qué porcentaje se encuentra definido un Plan de Recuperación de Desastres? (objeto, alcance, responsables, actividades) 40


De los servicios ofrecidos ¿qué porcentaje cuenta con un plan de restauración del servicio que incluya las diferentes prioridades del proceso de restauración?

70

X X X X X X ISO 27001:2013

¿Qué porcentaje de la infraestructura del Centro de Datos cuenta con una arquitectura redundante? 50

X X X X X X ISO 27001:2013

¿Se tiene conocimiento y documentación de los requisitos normativos y contractuales en materia de seguridad de la información para el Centro de Datos?

0

NA x NA X X X ISO 27001:2013

De los servicios ofrecidos en el Centro de Datos ¿A qué porcentaje se le han establecido procedimientos para el cumplimiento de requisitos legales asociados con derechos de propiedad intelectual y el uso de productos de software originales?

15

NA x NA X X X ISO 27018:2014

¿El tratamiento de la información personal se limita a lo acordado con el usuario sin que se utilice para marketing u otros propósitos que requieren de su consentimiento explícito?

100

NA X NA X X X ISO 27018:2014

¿Se eliminan archivos temporales que puedan tener información personal de los usuarios? 0

NA X NA X X X ISO 27018:2014

A menos que exista alguna prohibición determinada por la ley ¿Se tiene establecido que cualquier solicitud de divulgación de datos personales por parte de una autoridad, debe ser notificada de inmediato al usuario de servicios en la nube?

100

NA X NA X X X ISO 27018:2014

¿Se ha establecido que cualquier revelación de datos personales admitida debe ser grabada y documentada? 0

NA X NA X X X ISO 27018:2014

En caso de uso o procesamiento de información personal por parte de contratistas, ¿los usuarios cuentan con Información de los contratistas que hacen uso de sus datos personales y especificaciones del uso de sus datos?

0

131


NA X NA X X X ISO 27018:2014

¿Existe algún procedimiento para notificar de inmediato a los usuarios cuando se produzca una violación de los datos? 100

NA X NA X X X ISO 27018:2014

¿Existe una política para el traslado y eliminación de datos personales? 0

NA X NA X X X ISO 27018:2014

¿El uso de datos fuera de las instalaciones debe contar con una autorización de los usuarios? 0

NA X NA X X X ISO 27018:2014

¿La totalidad de identificaciones de usuario que han caducado se han deshabilitado? 0

NA X X X X X ISO 27017:2014

Con el fin de brindar a los usuarios autonomía en el uso de funcionalidades y servicios ofrecidos en la nube ¿Qué porcentaje de usuarios de la nube cuenta con herramientas para administrar sus recursos y conocimiento o documentación para utilizarlos?

5

NA X X X X X ISO 27017:2014

¿Qué porcentaje de usuarios de la nube cuentan con herramientas para administrar usuarios? 0

NA X X X X X ISO 27017:2014

¿Qué porcentaje de usuarios de la nube cuentan con herramientas para monitoreo de recursos y conocimiento o documentación para interpretarlas?

5


¿Qué porcentaje de los usuarios/clientes tienen conocimiento de que asumen algún riesgo de seguridad residual con la administración de sus servicios en la nube?

100

NA NA X X X X CSA V3 Dominio 2

¿Qué porcentaje de los servicios de red se someten a pruebas periódicas de seguridad? 50

NA X NA X X X CSA V3 Dominio 3

¿Qué porcentaje de los servicios de almacenamiento se someten a pruebas periódicas de seguridad? 0

NA x NA X X X CSA Dominio 3

La preservación de información puede requerir que se retengan grandes volúmenes de datos durante períodos prolongados. ¿En los SLA se tiene en cuenta pautas para la preservación de esta información?

0


¿Se incluye en el contrato o acuerdo de servicios en la nube, de qué forma serán recuperados los datos que el usuario o cliente almacenaron durante la prestación del servicio?

0

NA X NA X NA NA CSA V3 Dominio 5

Los volúmenes que contienen información delicada son cifrados para evitar exposición de snapshots y acceso no autorizado 10

NA X NA X X X CSA V3 Dominio 5 ¿Se cifran los datos delicados en el almacenamiento de objetos? 100

NA X NA NA X NA CSA V3 Dominio 5

Si el modelo de servicio es PaaS ¿Se cifran en él los datos delicados de las aplicaciones? NA


¿En el SLA está detallada la eliminación de datos por parte del proveedor? 0


En qué porcentaje se encuentra documentada la arquitectura de la nube 100


¿En qué porcentaje de los controles documentados se encuentran instaurados? 0


¿Se cuenta con una metodología para trasladar máquinas virtuales a otros anfitriones o proveedores Cloud? 0

NA X X X X X CSA V3 Dominio 6

En cuanto a escalabilidad ¿qué porcentaje de los servicios ofrecidos podrían vincularse con otras nubes? 100

132



¿Se verifica al menos una vez al año que la documentación de políticas se encuentre vigente y actualizada? 100


¿Qué porcentaje de los procedimientos cuentan con una verificación de su documentación al menos una vez al año? 15


¿Qué porcentaje de los empleados reciben capacitación en materia de seguridad al menos una vez al año? 0

X X X X X X CSA V3 Dominio 7 ¿Se realizan auditorías internas de seguridad informática? 0


Teniendo en cuenta los siguientes controles ambientales: Controles de temperatura Controles de humedad Detectores de humo Sistemas de supresión de incendios ¿qué porcentaje de ellos se implementan en el Centro de Datos?

20


¿En qué porcentaje las reparaciones necesarias de los equipos son realizadas únicamente por el personal de mantenimiento? 100

X X X X X X CSA V3 Dominio 7 ¿Se realizan pruebas al Plan de Recuperación de Desastres? 0

X X X X X X CSA V3 Dominio 7 ¿Se realizan pruebas al Plan de Continuidad del Negocio? 0

NA X X NA NA X CSA V3 Dominio 10

En relación con los datos y su ciclo de vida (tránsito, procesado y almacenamiento) ¿qué porcentaje de estas etapas tienen controles para la protección de datos durante el desarrollo de aplicaciones cloud?

NA

NA X X NA NA X CSA V3 Dominio 10

¿Se identifica, implementa y comparte un conjunto de buenas prácticas de desarrollo? NA

NA X NA NA X X CSA V3 Dominio 10

¿Se ha establecido una política de seguridad y privacidad para las aplicaciones en cloud? NA


¿A qué porcentaje de las aplicaciones se les realiza evaluaciones de riesgo para la seguridad y privacidad? NA

NA X NA NA NA X CSA V3 Dominio 10

En el código de los desarrollos que pasan a Producción en la nube ¿se eliminan los comentarios e información personal? NA

NA X X NA X X CSA V3 Dominio 10

¿Se realizan test de intrusión o pentest con el fin de determinar la robustez en seguridad de la nube? NA


¿Se realizan pruebas de interoperabilidad para identificar problemas en las aplicaciones Cloud al intercambiar datos con otros componentes o aplicaciones?

NA


En las aplicaciones web desarrolladas ¿qué porcentaje de los riesgos reportados por la organización OWASP en su top 10 anual se tienen presentes para los test de intrusión?

NA


¿Se realiza Multi-Tenancy Testing para identificar vulnerabilidades de escala de privilegios de los servicios? NA


En la guía de pruebas OWASP 4.0 del año 2014 se recomiendan 11 categorías de test. ¿Qué porcentaje de estas pruebas se realizan en el Centro de Datos que soporta la nube?:

NA


¿Se recomienda a los usuarios (clientes/organizaciones) evitar almacenar claves en la nube? 100


¿Se protegen archivos de logs y metadatos a través de los cuales se pueden originar pérdidas de datos? 0

133


NA NA X X X X CSA V3 Dominio 12

¿La gestión de acceso aplicada a la capa de red incluye reglas de asignación que permite únicamente a los usuarios específicos ver el sistema cloud? (por ejemplo ping o route)

100


¿Para la gestión de acceso se aplican reglas de asignación de derecho a los servicios web? 0

NA X X NA X X CSA V3 Dominio 12

¿Los servicios y aplicaciones Cloud cuentan con la capacidad para utilizar la autenticación SAML? NA


En caso de necesitar guardar o transferir los logs a un sistema remoto ¿se puede garantizar que su disponibilidad y seguridad de transmisión son adecuadas?

0


¿Se comunica a los usuarios/clientes que sus datos de carácter personal y demás información personal sensible es susceptible de las leyes de protección de datos?

0


¿Los datos personales y demás información sensible almacenada corresponden estrictamente a información necesaria para la asignación del servicio?

100


¿Qué porcentaje de las imágenes de las máquinas virtuales se cifran cuando no están en uso? 100

NA X X X X X CSA V3 Dominio 13

¿Se realiza segregación de VM por zonas de seguridad de acuerdo tipo de uso? Por ejemplo etapa de producción, sensibilidad de los datos, componentes de hardware, almacenamiento, etc.

0


¿Se realizan actualizaciones periódicas de las imágenes máquinas virtuales? 100


¿En qué porcentaje las imágenes o plantillas de máquinas virtuales de la nube son creadas desde cero y no descargadas de un tercero? 25


¿Se cuenta con un Gestor de Información y Eventos de Seguridad (SIEM) para centralizar logs y otros registros de eventos? 0


¿Se brinda a los usuarios/clientes, servicios o herramientas para control de auditoría? 0

134


9.6 Anexo F - Lista de controles consolidados

ID Control ID Control ID Control ID Control ID Control 1 AC-1 36 CA-5 71 IR-5 106 PS-1 141 SC-22 2 AC-2 37 CA-6 72 IR-6 107 PS-2 142 SC-23 3 AC-3 38 CA-7 73 IR-7 108 PS-4 143 SC-24 4 AC-4 39 CM-1 74 IR-8 109 PS-5 144 SC-28 5 AC-5 40 CM-2 75 MA-1 110 PS-6 145 SI-1 6 AC-6 41 CM-3 76 MA-2 111 PS-7 146 SI-2 7 AC-7 42 CM-4 77 MA-3 112 PS-8 147 SI-3 8 AC-8 43 CM-5 78 MA-4 113 RA-1 148 SI-4 9 AC-9 44 CM-6 79 MA-5 114 RA-2 149 SI-5

10 AC-11 45 CM-7 80 MA-6 115 RA-3 150 SI-7 11 AC-14 46 CM-8 81 MP-1 116 RA-5 151 SI-8 12 AC-16 47 CM-9 82 MP-2 117 SA-1 152 SI-12 13 AC-17 48 CM-10 83 MP-3 118 SA-2 14 AC-18 49 CM-11 84 MP-4 119 SA-3 15 AC-19 50 CP-1 85 MP-5 120 SA-4 16 AC-20 51 CP-2 86 MP-6 121 SA-5 17 AC-21 52 CP-3 87 MP-8 122 SA-8 18 AC-22 53 CP-4 88 PE-1 123 SA-9 19 AT-1 54 CP-6 89 PE-2 124 SA-10 20 AT-2 55 CP-7 90 PE-3 125 SA-11 21 AT-3 56 CP-8 91 PE-4 126 SA-12 22 AT-4 57 CP-9 92 PE-5 127 SC-1 23 AU-1 58 CP-10 93 PE-9 128 SC-3 24 AU-3 59 IA-1 94 PE-10 129 SC-4 25 AU-6 60 IA-2 95 PE-11 130 SC-5 26 AU-7 61 IA-3 96 PE-12 131 SC-7 27 AU-8 62 IA-4 97 PE-13 132 SC-8 28 AU-9 63 IA-5 98 PE-14 133 SC-10 29 AU-10 64 IA-6 99 PE-15 134 SC-12 30 AU-11 65 IA-7 100 PE-16 135 SC-13 31 AU-12 66 IA-8 101 PE-17 136 SC-16 32 AU-14 67 IR-1 102 PE-18 137 SC-17 33 CA-1 68 IR-2 103 PE-19 138 SC-19 34 CA-2 69 IR-3 104 PL-1 139 SC-20 35 CA-3 70 IR-4 105 PL-4 140 SC-21

135


9.7 Anexo G – Evaluación ISO- NIST

Anexo G.1 – Evaluación ISO/IEC 27001 – NIST AC

136


Anexo G.2 - Evaluación ISO/IEC 27001 – NIST AT, AU

137


Anexo G.3 - Evaluación ISO/IEC 27001 – NIST CA-CM

138

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing Anexo G.4 - Evaluación ISO/IEC 27001 – NIST CP-IA

139


Anexo E.G Evaluación ISO/IEC 27001 – NIST IR-MA

140


Anexo G.6 Evaluación ISO/IEC 27001 – NIST MP-PL-PS-RA

141


Anexo G.7 Evaluación ISO/IEC 27001 – NIST PE

142


Anexo G.8 Evaluación ISO/IEC 27001 – NIST SA

143


Anexo G.9 Evaluación ISO/IEC 27001 – NIST SC-SI

144

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing 9.8 Anexo H – Evaluación CSA – NIST

CONTROL AC-1 AC-2 AC-3 AC-4 AC-5 AC-6 AC-7 AC-8 AC-9 AC-10 AC-11 AC-12 AC-14 AC-16 AC-17 AC-18 AC-19 AC-20 AC-21 AC-22 AC-23 AC-24 AC-25DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3DOMINIO 5 33,33 33,33DOMINIO 6DOMINIO 7

ACCESS CONTROL (CONTROL DE ACCESO)

CONTROL AT-1 AT-2 AT-3 AT-4 AU-1 AU-2 AU-3 AU-4 AU-5 AU-6 AU-7 AU-8 AU-9 AU-10AU-11AU-12AU-13AU-14AU-15AU-16DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3 0 0DOMINIO 5 33,33DOMINIO 6DOMINIO 7

AWARENESS TRAINING AUDIT AND ACCOUNTABILITY

CONTROL CA-1 CA-2 CA-3 CA-5 CA-6 CA-7 CA-8 CA-9 CM-1 CM-2 CM-3 CM-4 CM-5 CM-6 CM-7 CM-8 CM-9 CM-10CM-11DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3 0 0 0 0 0DOMINIO 5 33,33 33,33 33,33 33,33DOMINIO 6DOMINIO 7 34,5 34,5 34,5 34,5 34,5 34,5

SECURITY ASSESSMENT AND AUTHORIZATION CONFIGURATION MANAGEMENT

CONTROL CP-1 CP-2 CP-3 CP-4 CP-6 CP-7 CP-8 CP-9 CP-10 CP-11 CP-12 CP-13 IA-1 IA-2 IA-3 IA-4 IA-5 IA-6 IA-7 IA-8 IA-9 IA-10 IA-11DOMINIO 2 75 75 75 75 75 75 75 75 75 75DOMINIO 3DOMINIO 5 33,33 33,33 33,33 33,33 33,33DOMINIO 6DOMINIO 7 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5

CONTINGENCY PLANNING IDENTIFICATION AND AUTHENTICATION

CONTROL IR-1 IR-2 IR-3 IR-4 IR-5 IR-6 IR-7 IR-8 IR-9 IR-10 MA-1 MA-2 MA-3 MA-4 MA-5 MA-6DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3DOMINIO 5DOMINIO 6DOMINIO 7 34,5 34,5 34,5 34,5 34,5

INCIDENT RESPONSE MAINTENANCE

CONTROL MP-1 MP-2 MP-3 MP-4 MP-5 MP-6 MP-7 MP-8 PL-1 PL-2 PL-4 PL-7 PL-8 PS-1 PS-2 PS-3 PS-4 PS-5 PS-6 PS-7 PS-8 RA-1 RA-2 RA-3 RA-5DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3 0 0 0 0DOMINIO 5 33,33 33,33 33,33 33,33 33,33 33,33 27,5DOMINIO 6DOMINIO 7 34,5

PLANNING PERSONNEL SECURITY RISK ASSESSMENTMEDIA PROTECTION

145


CONTROL PE-1 PE-2 PE-3 PE-4 PE-5 PE-6 PE-8 PE-9 PE-10 PE-11 PE-12 PE-13 PE-14 PE-15 PE-16 PE-17 PE-18 PE-19 PE-20DOMINIO 2 75DOMINIO 3DOMINIO 5 33,33 33,33DOMINIO 6DOMINIO 7 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5 34,5

PHYSICAL AND ENVIROMENTAL PROTECTION

CONTROL SA-1 SA-2 SA-3 SA-4 SA-5 SA-8 SA-9 SA-10 SA-11 SA-12 SA-13 SA-14 SA-15 SA-16 SA-17 SA-18 SA-19 SA-20 SA-21 SA-22DOMINIO 2 75 75 75 75 75DOMINIO 3 0DOMINIO 5 33,33DOMINIO 6DOMINIO 7 34,5 34,5 34,5 34,5 34,5 34,5 34,5

SYSTEM AND SERVICES ACQUISITION

CONTROL SC-1 SC-2 SC-3 SC-4 SC-5 SC-6 SC-7 SC-8 SC-10 SC-11 SC-12 SC-13 SC-15 SC-16 SC-17 SC-18 SC-19 SC-20 SC-21 SC-22 SC-23 SC-24 SC-28DOMINIO 2 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75DOMINIO 3DOMINIO 5DOMINIO 6DOMINIO 7

SYSTEM AND COMMUNICATIONS PROTECTION

CONTROL SI-1 SI-2 SI-3 SI-4 SI-5 SI-6 SI-7 SI-8 SI-10 SI-11 SI-12 SI-13 SI-14 SI-15 SI-16 SI-17DOMINIO 2 75 75 75 75 75 75 75DOMINIO 3DOMINIO 5 33,33DOMINIO 6DOMINIO 7

SYSTEM AND INFORMATION INTEGRITY

146


10 Bibliografía

[1] P. Mell y T. Grance, “The NIST definition of cloud computing - SP 800-145”, NIST Spec. Publ., vol. 145,

p. 7, 2011.

[2] W. Bumpus, “NIST Cloud Computing Standards Roadmap - SP 500-291”, NIST Cloud Comput. Stand.,

p. 113, 2013.

[3] CSA, “Security guidance for critical areas of focus in cloud computing v4.0”, Cloud Security Alliance.

pp. 1–152, 2017.

[4] ISO, “INTERNATIONAL STANDARD ISO / IEC Information technology- 27000 - Security techniques

— Information security management systems — Overview and vocabulary”, vol. 2016, 2016.

[5] NIST, “FIPS PUB 199: Standards for Security Categorization of Federal Information and Information

Systems”, Fips, vol. 199, núm. February 2004, p. 13, 2004.

[6] W. Stallings, M. Bauer, y E. M. Hirsch, COMPUTER SECURITY PRINCIPLES AND PRACTICE Third

Edition, Third Edit. 2013.

[7] M. E. Whitman y H. J. Mattord, Principles of information security, Fourth Edi. 2012.

[8] J. M. Stewart, M. Chapple, y D. Gibson, CISSP - Certified Information Systems Security Professional

STUDY GUIDE Sixth Edition, Sixth Edit. 2012.

[9] E. Conrad, S. Misenar, y J. Feldman, CISSP Study Guide. 2010.

[10] S. Nepal y M. Pathan, Eds., Security, Privacy and Trust in Cloud Systems, 2014a ed. Springer, 2014.

[11] A. Alshammari, S. Alhaidari, A. Alharbi, y M. Zohdy, “Security Threats and Challenges in Cloud

Computing”, 2017 IEEE 4th Int. Conf. Cyber Secur. Cloud Comput., pp. 46–51, 2017.

[12] K. H. Alotaibi, “Threat in Cloud- Denial of Service ( DoS ) and Distributed Denial of Service ( DDoS )

Attack , and Security Measures”, J. Emerg. Trends Comput. Inf. Sci., vol. 6, núm. 5, pp. 241–244, 2015.

[13] “Seguridad en la Nube - Amazon Web Services (AWS)”. [En línea]. Disponible en:

147

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing https://aws.amazon.com/es/security/. [Consultado: 18-dic-2016].

[14] “Security Microsoft”. [En línea]. Disponible en: https://www.microsoft.com/en-

us/TrustCenter/Security/default.aspx#Secure_identity. [Consultado: 18-nov-2016].

[15] “Centro de confianza de Microsoft Azure | Azure”. [En línea]. Disponible en:

https://azure.microsoft.com/es-es/support/trust-center/. [Consultado: 18-ene-2017].

[16] M. Zapata-ros, “La investigación y la edición científica en la web social : La web social”, RED Docencia

Univ. en la Soc. del Conoc., vol. 3, núm. 3, 2011.

[17] “ISO Standards - ISO”. [En línea]. Disponible en: http://www.iso.org/iso/home/standards.htm.

[Consultado: 08-ene-2017].

[18] “Relevant Standards Setting Organizations in Cloud Computing”. [En línea]. Disponible en:

http://csc.etsi.org/phase1/organizations.html. [Consultado: 08-ene-2017].

[19] “FIPS General Information | NITS”, 2013. [En línea]. Disponible en: https://www.nist.gov/information-

technology-laboratory/fips-general-information. [Consultado: 01-oct-2016].

[20] “Publicaciones del NIST”, 2015. [En línea]. Disponible en: http://csrc.nist.gov/publications/.

[Consultado: 19-oct-2016].

[21] “NIST Computer Security Publications”, 2016. [En línea]. Disponible en:

http://csrc.nist.gov/publications/PubsSPs.html.

[22] F. Liu, J. Tong, J. Mao, y R. Bohn, “NIST Cloud Computing Security Reference Architecture”, NIST

Spec. …, vol. 500, núm. 299, pp. 1–204, 2013.

[23] F. Liu, J. Tong, J. Mao, R. B. Bohn, J. V Messina, M. L. Badger, y D. M. Leaf, “Nist Cloud Reference

Architecture 500-292”, Natl. Inst. Stand. Technol. Spec. Publ. 500-292, núm. 6, pp. 1–35, 2011.

[24] R. B. Bohn, “NIST Sp - 500-293 US Government Cloud Computing Technology Roadmap - Volume I”,

Nist Spec. Publ., vol. I; II, p. 85, 2014.

[25] W. Jansen y T. Grance, “Guidelines on Security and Privacy in Public Cloud Computing - SP 800-144”,

NIST Spec. Publ. 800-144, p. 80, 2011.

[26] “About CSA - Cloud Security Alliance”. [En línea]. Disponible en:

148

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing https://blog.cloudsecurityalliance.org/about-cloud-security-alliance/.

[27] “About: CSA Cloud Security Alliance”. [En línea]. Disponible en:

https://cloudsecurityalliance.org/about/.

[28] C. secyrity Alliance, P. Simmonds, C. Rezek, A. Reed, y C. secyrity Alliance, “Security guidance for

critical areas of focus in cloud computing v3. 0”, Cloud Secur. Alliance, p. 176, 2011.

[29] C. Hoff y P. Simmonds, “Guías de seguridad de áreas críticas en cloud computing v3.0”, pp. 0–186,

2011.

[30] Ministerio de Hacienda y Función Pública, “MAGERIT v.3 : Metodología de Análisis y Gestión de

Riesgos de los Sistemas de Información”, Administracionelectronica.Gob.Es, 2012.

[31] CSC, “Relevant Standards Setting Organizations in Cloud Computing”, 2015. [En línea]. Disponible en:

http://csc.etsi.org/phase2/snapshot2/StandardsOrganizations.html. [Consultado: 08-abr-2017].

[32] C. M. Guitierrez, W. Jeffrey, y C. M. Furlani, “FIPS PUB 200: Minimum Security Requirements for

Federal Information and Information Systems”, Nist, núm. FIPS PUB 200, 2006.

[33] J. T. T. I. FORCE, “Security and privacy controls for federal information systems and organizations -

NIST SP 800-53”, NIST Spec. Publ., vol. 800, p. 53, 2013.

[34] “CECAD - Quiénes Somos”. [En línea]. Disponible en: http://cecad.udistrital.edu.co/index.php/quienes-

somos. [Consultado: 29-ene-2017].

[35] R. A. C. Ospino, P. F. P. Arteaga, y ..., “Lessons learned in the design and implementation of a private

cloud for high-performance computing using OpenStack in existing university infrastructure”, pp. 558–

567, 2015.

[36] P. G. Pachón, M. Á. Torres, y P. julio Vargas, “Modelo de Seguridad Perimetral de la Información para

Centros de Cómputo de Alto Desempeño”, Universidad Distrital Francisco José de Caldas, 2012.

[37] “Detalles del PowerEdge 11G R610 | Dell Colombia”. [En línea]. Disponible en:

http://www.dell.com/co/empresas/p/poweredge-r610/pd. [Consultado: 02-mar-2017].

[38] “Detalles del PowerEdge 11G R710 | Dell Colombia”, Detalles del PowerEdge R710. [En línea].

Disponible en: http://www.dell.com/co/empresas/p/poweredge-r710/pd. [Consultado: 20-mar-2017].

149

Modelo de Seguridad para plataformas colaborativas de e-ciencia sobre Cloud Computing [39] “HP Proliant SE316M1 (DL160) G6 2 x L5520 Quad-Core Server”. [En línea]. Disponible en:

https://www.etb-tech.com/hp-proliant-se316m1-g6-1x8-2-x-l5520-2-26ghz-quad-core-8gb-smart-

array-p410.html#.WNADjvnfq1s. [Consultado: 20-mar-2017].

[40] “BladeCenter 8886”. [En línea]. Disponible en:

http://bladecenter.lenovofiles.com/help/index.jsp?topic=%2Fcom.lenovo.bladecenter.8886.doc%2Fdw

1fs_c_overview_welcome.html. [Consultado: 20-feb-2017].

[41] “BladeCenter HS22 > Lenovo Press”. [En línea]. Disponible en: https://lenovopress.com/tips0822-

bladecenter-hs22. [Consultado: 20-mar-2017].

Modelo de seguridad para plataformas colaborativas de e...

Documents

Transcript of Modelo de seguridad para plataformas colaborativas de e...